emulation of radio access networks to facilitate the

Emulation of Radio Access Networks toFacilitate the Development of Distributed

ApplicationsTim Seipold

[email protected] of Computer Science 4, RWTH Aachen University of Technology, Germany

Abstract— Emulation of Radio Access Networks is a valu-able tool for the development of distributed applicationsincorporating mobile terminals. The network simulator ns–2provides mechanisms to route live network traffic throughits simulation and thus emulate a network in real-time.However, it lacks certain core features for the emulationof networks with mobile terminals: roaming of terminalsacross base stations, dynamic addressing of nodes, andthe export of these changes to the outside application toevaluate its capabilities in dealing with these consequencesof terminal mobility. To enable this, a new set-up foremulation is proposed and implemented using ns–2. Aninfrastructure routing protocol (INFRA) is presented, as wellas an additional TAP network object and a TAP agentthat were required to unleash the full potential of thenew routing protocol. The results of several experimentsapplying these new components expose the added value ofthe new emulation setup for the evaluation of distributedapplications.

Index Terms— network emulation, Radio Access Networks,wireless, roaming, DHCP, ns–2

I. INTRODUCTION

With the dawn of affordable and ubiquitously availableRadio Access Networks (RANs) the inclusion of wirelessterminals in distributed applications became a logicalextension of existing distributed systems. Especially in thebusiness environment this is an attractive development,since it allows the integration of participants into thebusiness process that have been excluded beforehand. Us-ing RANs mobile entities can be completely incorporatedinto an Enterprise Resource Planning System (ERPS)or similar distributed applications and have continuousaccess to the up-to-date information within the system.The same way the status of the mobile entities can bekept up-to-date within the system, thus allowing betterplanning of the mobile entities’ tasks. This is especiallyinteresting for enterprizes, where mobile entities consti-tute a core domain of the business operations: cargo haul,on-site customer service etc. Fig. 1 provides a systematicoverview of such a system.

This paper is based on “Improving emulation of wireless accessnetworks in ns–2” by Tim Seipold, which appeared in the Proceedingsof the 3th IEEE Conference on Wireless Mobile Computing (ICWMC),Guadeloupe, France Caribbean, March 2007. c© 2007 IEEE.

This work was supported in part by the Bundesministrium furForschung und Bildung (BmBF) under the project code 01ISC25

corporatenetwork 1

ERPS

corporatenetwork 2

RAN

RAN

providercore network

accessnetwork

Internet

Figure 1: Overview of a distributed application incorporating mobileusers connected by RANs

For like applications it is not feasible to implementa company owned RAN but buying transport servicesfrom communication providers. Covering a wide areathis usually implies data transport via GPRS, UMTSetc. Those networks operate opaque to the user and theeffects of the RAN are only indirectly visible to theuser buying transport services. However, at the factorypremises company operated RANs like WiFi or Tetraare a necessity, as they increase network performance,minimize transportation cost and make the RAN’s statusaccessible to the user’s application. Obviously, in such anenvironment the terminals are exposed to several issuescreated by the availability of several wireless networks:there may be none or several transport networks of differ-ent quality and cost available, and switching access pointswithin a network (hand-over) or even between differentnetworks (hand-off) vastly affects the data transport.

While some of these issues can be addressed on theOperating System (OS) level, other issues need to behandled within the application. Especially decisions in-volving a quality-cost-tradeoff can not be made by theOS, as the required information is only available to theapplication. Both levels of decision need testing andtuning of parameters to reach a sufficient performance.This is, however, not as trivial as one initially supposes.

Real tests involving the effects of RANs require, besidereal hardware and an existing software, real networks andreal mobility. Most RANs operate on a regulated spectrumand thus forbid the implementation of a test bed, evenif the necessary funding would be available. Thus, thetest have to be done using the commercial providers’networks, which generates costs for the date transport,introduces cross traffic into any measurements, restricts

JOURNAL OF COMMUNICATIONS, VOL. 3, NO. 1, JANUARY 2008 1

© 2008 ACADEMY PUBLISHER

access to network internal data and limits the test set-upto a given infrastructure. Further, generating the terminalmobility for real tests consumes significant resources, asall terminals need to be physically moved and generatinga sufficient amount of hand-over/hand-off events takestime. Last but not least the control over and thus thereproducibility of a scenario in case of real tests is verylimited. Therefore, real tests are no means that can be usedduring application development but only suitable for thefinal verification steps before deployment.

Another method of application evaluation is mathemat-ical modelizing. Using Petri nets, queue networks or othermodelizing techniques a representation of the applica-tion’s behaviour is generated that is solved for certainparameters using mathematical methods. This approach’sresults are usually obtained rather quick, as tools canbe used to solve the models. However, with increasingrealism of the model its complexity and thus the time tocompute a solution increases as well.

A minor drawback of this approach is the necessityof maintaining a model synchronous to the actual ap-plication. Expertise in modelizing is required, and mustbe continuously applied during the development cycle toupdate or refine the model, creating an overhead. Hencethe major drawback emerges once third-party componentsare used for the application, as e.g. middleware systems.The internals of these components affect the applicationperformance, but the modelizing can be based on aneducated guess only, as these internals are usually hidden.This results in poor models of critical aspects of thesystem delivering coarse results and leads to a limitedapplicability of this approach as a tool in the developmentcycle. As mathematical modelizing neither requires theactual hardware nor the actual software, it has its valueas a tool for roughly assessing the viability of a solutionbefore any real development has been done.

Simulation as an evaluation method is rather similarto mathematical modelizing. However, instead of a math-ematical model of the system, program objects with asimplified version of the real components’ behaviour arecombined to resemble the real system. This so-calledsimulation scenario is executed within a simulator andthe modeled components interact the same way as thereal components would. These interactions are loggedwith time stamps and allow a subsequent analysis of thecombined system’s and thus the application’s behaviour.

As with mathematical modelizing, simulation lacksprecision as soon as third-party components are involved,as their details can be modeled by educated guess only.On the other hand simulation requires significantly lessadditional expertise than mathematical modelizing, as theobjects’ behaviour is programmed rather than describedby mathematical abstractions, and scenarios are composedthe same way as the real systems are. This way simulationis much more accessible to the average developer thanmathematical modelizing. Further, in most cases a simu-lation model can be constructed from reusable predefinedcomponents that are common between many applications,

as e.g. network models (physical, link, and transportlayer), routing models etc. The application behaviouritself needs still to be modeled, and it needs to be keptconsistent with the actual application. This creates anoverhead during the development process, and as with themathematical modelizing the quality of the model is deci-sive for the quality of the results gained by this approach.Widely used network simulators with focus on wirelessnetworks are ns–2 [1], OPNET [2] and Glomosim [3].There are some approaches to automatize the generationof simulation models of new protocols by using specialframeworks for the implementation. This way, a suitablesimulation model may be generated immediately fromthe real implementation of the protocol, thus reducingthe overhead in the development process. However, thisprocess limits the protocol development to the featuressupported by the framework, as any advanced featureswould nullify the automated translation into a simulationmodel.

Some simulation tools provide another function; insteadof relying on application models to initiate action, theyallow the injection of live network data from outsidesources into the simulation. If data may as well beemitted from the simulation to an outside application, thesimulation may be integrated into a system and emulatea component’s behaviour. Using this emulation method,the existing simulation components can be used to forma scenario that can be integrate into a test environmentand emulate a sub-systems behaviour in such a way thatthe outside system can be tested.

Applied to the domain of distributed applications, theemulated sub-system would be the transport networkincluding the terminals’ mobility, as far as RANs areinvolved. The applications’ data is routed through theemulation that mimics the effects of the RANs allowing athroughout evaluation of the distributed system. How thiscan be done in detail and what peculiarities have to beenconsidered will be presented in the next section.

II. NETWORK EMULATION

The emulation of the transport network for evaluationpurposes may technically be accomplished in differentways, each of which has its own merits. Since a soundunderstanding of these methods is required in order toimprove their capabilities, a short description of theiroperation is presented next.

The simple real scenario involving a RAN as depictedin fig. 2a will be used as an example. A mobile terminalexecutes a component of the distributed application, sub-sequently called client, and is connected using a RAN toa wired, but basically opaque transport network which inturn connects to a machine executing another part of thedistributed application, subsequently called server. Theclient uses a real Network Interface Card (NIC) for thedata transport that immediately connects to the RAN onthe physical layer, the terminal itself is mobile and hencegenerates changes in the RAN access. These changesaffect the NIC in terms of addressing, routing, available

2 JOURNAL OF COMMUNICATIONS, VOL. 3, NO. 1, JANUARY 2008


networks etc. and may trigger a reaction by the OS orthe client application. In terms of network quality thewired networks are in orders of magnitude better thanRANs1, and the RAN as the weakest link dominates theconnection to an extend that allows to ignore the influenceof the wired networks.

The most common approach to network emulation isthe black-box method as shown in fig. 2b. Client andserver are connected by wired networks to a device thatemulates the transport network, hence called emulator.This may be either another computer running emulationsoftware or a dedicated emulation hardware, but in bothcases the data transport through the emulator happenscompletely transparent to the application – besides theemulated networks’ effect on the data transport in termsof bandwidth, packet loss, delay, jitter etc. As far as theevaluated application is concerned, the data link throughthe black box can not be discerned from the direct linkusing a NIC. NIST [4] and dummynet [5] are examples forlike emulators. The quality of the emulator determines thecorrespondence of the overall results with measurementstaken using a a real network.

The quality of the emulator is not only decided bythe realism of its models or of the used scenario, butheavily influenced by its performance. The device mustbe capable of processing the data passed to it that fast,that any delay etc. is the delay that is introduced dueto the current emulation scenario. This basically impliesthat the emulator must operate under real-time constraints.Network emulators are usually implemented as discrete-event discrete-time simulation engines with a real-timescheduler. While a simulator advances the simulation timeto the start of the next event after processing an event,an emulator stalls operation until an appropriate timehas passed in the real world. Depending on the timeit takes to process the events and the event intensity,the emulator may not be able to process an event fastenough to complete it before the next event is due —the emulator starts to lag compared to the real time,because the reaction to an event happens after it wouldhave happened in a real network. Once lag sets in, theemulation will not deliver reliable results anymore, even ifit happens to catch up the lag later on. Thus, lag detectionis a must, and any emulation results produced with lagoccurring must be carefully considered and, depending onquality and quantity of the lag, eventually discarded.

The black box approach using a dedicated system asan emulator allows it to dimension the emulator in such away that it performance allows operation in the absenceof any lag. However, this approach is somewhat limitedwhen it comes to scalability. A separate machine andconnection is required for every terminal involved in ascenario, increasing the required hardware and networkconnectivity.

With the ascend of virtualization and the wide availabil-ity of sufficiently powerful computers, it became applica-

1i.e. bandwidth IEEE 802.11n 150Mbit/s (mode 7) vs. IEEE802.3an/aq 10Gbit/s

ble to network emulation as well, as lag-free operation ofthe emulator became possible for an increasing number ofapplications and scenarios. Using a single host computer,several Virtual Machines (VMs) are created that run theclient or the server application, see fig. 2c. These VMsare connected through an emulator also run on the hostcomputer, whether in its own VM or as a simple processis of no importance. Compared to black box emulation,no external networking is involved and only the copyperformance of the host machine limits the throughputthrough the emulator.

While virtualization eliminates the need for additionalhardware and connection infrastructure from the blackbox approach, the demands on the host machine arehowever high, as any emulation must still be conductedin a lag-free manner. This applies to the VMs runningthe application components as well, it is not feasibleto starve the applications of computing power in favourof the emulator, as lag here would as well negativelyaffect the quality of the results. However, as mobileterminals usually have very limited resources comparedto desktop computers, while this limits the number ofpossible client VMs in a simulation scenario this approachis still applicable to many evaluation tasks.

These methods of emulation deal only with effects thatthe intermediate networks have on the data flow betweenclient and server and are sufficient to investigate theapplications’ performance. However, the use of a RANon the client side and running it on a mobile terminalintroduces new effects that can not be evaluated with thesemethods. Using a RAN, the connection’s quality varies inmore aspects than just bandwidth, delay and error rate.

The terminal’s mobility causes it to roam betweenAccess Points (APs) and RANs causing the terminal’saddress to change. These changes have extensive effectson the communication, as the application needs to adjustits used address according to the changes to keep theconnection between client and server established. Usingabove methods, these effects happen within the emulator,thus are invisible to the application being evaluated. Inorder to evaluate applications dealing with these effectsthe address changes have to be exported from the emulatorand made visible to the application, which could beimplemented in several ways.

Black box emulation could be augmented by adding anagent on every client machine that is connected via a sidechannel to the black box and reproduce any effects to theNIC within the emulator on the NIC of the terminal. Thisapproach either requires additional infrastructure for theside channel or accepts the possible interference of theside channel data with the emulation data if a shared linkis used. Two qualitative issues are more severe than thesequantitative issues. Firstly, this necessitates the additionalagent to be installed and configured on every terminal.The agent needs to be implemented for every client OSand configured for every client system, so the big ‘plugand emulate’ advantage of the black box approach issignificantly reduced. Further the installation of the agent



terminal server

application application

network

A-NIC

(a) scenario w/o emulation

terminal emulator server


wired network wired network

A-NIC

E-NIC

(b) black-box emulation

virtual machine

terminal

host machine

emulator server

application

virtual machine

application

virtual network virtual network

E-NIC

V-NIC

(c) virtualisation

host machine

emulator

server


real network

E-NIC

V-NIC

(d) virtual NIC

Figure 2: Emulation methods

on the terminal may interfere with the application, thusdisturb the system and distort the results. Second, due tothe propagation of the effects from the emulator to theclients over the side channel, there is a delay betweenthe incidence in the emulator and the reproduction of theincidence at the terminal. During this time, the NIC at theterminal and the corresponding endpoint in the emulatorare out of sync, and all data in transport will be handleddifferently in the emulation than the client applicationinitially expected it to be. This fact severely limits theapplicability of an augmented black box emulation, asit hinders the applications to react immediately on theeffects of an address change and may seriously distortthe emulation results.

Transferring this approach to virtualization minimizesthe delay between emulation and clients, as no physicalnetwork is involved in the side channel. Still, an agent isneeded inside each VM to reproduce the effects happeninginside the emulator at the local interface, as the informa-tion needs to moved across the VMs’ border. Thus, thesimple transfer of the emulation setup on a single hostcomputer does mitigate the effects, but not solve the issue.

Considering the challenges for the emulation of RANsbeyond the plain data transfer, and the use of VMs tofacilitate the emulation process, the idea to use someof the techniques used to implement VMs directly forsimulation purposes was born. Each VM creates virtualnetwork devices, short V-NICs, that the host OS uses topass network traffic to and from the VM as if it wasa machine connected to a real NIC. The VM then usessome proprietary mechanism to relay the data to its guestOS, usually done by providing a virtual version of acommon, real network device that can be accessed bythe corresponding device drivers of the guest OS. Byintegrating this technique into the emulator, the emulatoritself would be able create V-NICs that could be usedto inject into and export data from the emulation. Thiscan obviously be combined with virtualization or theseparation of components as in the black box method.

This so called V-NIC emulation method is depicted infig. 2d, where as an example the server application isplaced on a separate machine to reduce the load on theemulation host.

Every V-NIC is under the complete control of theemulator, and no additional means are necessary to conveychanges made by the emulator to the NIC. All toolsand interfaces the OS provides to access real networkdevices are available to inspect and manipulate the V-NIC. Those clients that can be run on the same OS asthe emulator can be run natively on the emulation hostand use the V-NIC instead of a real NIC without anydifference. Obviously they are immediately exposed toany changes made to the V-NIC’s status by the emulator,which warrants accurate emulation results. Further, forthose clients no additional overhead for the use of a VM isrequired, reducing the load on the emulation host. Generalinterference between the emulator and clients running onthe same host, i.e. without the separation in individualVMs, is limited to resource consumption. Therefore thereshould be no difference to the virtualization method,where no VM, regardless of client or emulator, was tobe starved from memory or processing power. Clientsthat can not be run on the same OS can still be placedinside a VM and connected to the emulator, but with thepreviously described limitations.

The V-NIC approach trades the flexibility of usingVMs off for the improved performance and the easy andsynchronous export of effects inside the emulator to theoutside. The next section describes the additions to ns–2that have been made to facilitate the emulation of RANfor the use as a tool in the development cycle of mobilityaware applications.

III. EXTENDING ns–2

ns–2 is a network simulator that doubles as a networkemulator. It implements a real-time event scheduler aswell as components for network traffic injection fromoutside sources. Specifying these components as user



agents and scheduler in a simulation scenario results in anemulation scenario. Hence, simulation and emulation arenearly identical, and every issue with network simulationlikewise affects the network emulation.

To simulate wired-cum-wireless scenarios, ns–22 uses ahierarchical address space, in use and notation similar toIP addresses, but with three parts instead of four, denotingdomain, cluster and node level. The wired and wirelessworld is usually separated at the domain level, every APis located as well in the wired as a wireless domain,usually defining its own wireless cluster. All mobile nodesare configured at set up time with the address of theirrespective AP, called base station in ns–2. Since therouting algorithm for hierarchical routing uses the firstnode it encounters to connect across clusters, it is notfeasible to have several APs serving the same wirelesscluster, as all wired nodes will try to route data to allnodes in that cluster using a single static AP. Thus, mobilenodes outside of that AP’s range, but within the rangeof another AP of the same cluster will not be reachedsince all data is routed to the wrong AP. The other wayround, the mobile nodes are not able to send data oncethey leave the range of their configured AP, since allpackets are addressed to that particular AP. Using thens–2 components for Mobile Internet Protocol (MIP) cancircumvent that issue at the cost of the additional overheadthat MIP introduces.

To accommodate this, a DHCP-like [6] protocol calledINFRA was implemented for ns–2. INFRA differs slightlyfrom DHCP, as can be seen in fig. 3a and 3b. WhileDHCP is usually triggered by an external source, as e.g.changes on the link layer, this was not possible in ns–2,as the ns–2 channel model and IEEE 802.11 layer donot provide for SSID handling etc. Therefore appropriateadjustments had to be made for INFRA.

As DHCP, INFRA implements a client and a servermode. A server agent, located at the AP, provides ad-dresses to clients from a given address pool. However, tocompensate for the lack of link layer events, APs peri-odically broadcast their presence using so-called beacon-packets, a procedure usually implemented in the IEEE802.11 layers. Based on the incoming beacons the clientagent selects, usually based on the highest signal strength,an AP and requests an address from it. Supposed thereare free addresses in its pool, the selected AP offers anaddress via broadcast to the client, which the client installsand acknowledges, now using a unicast packet with validsource and destination addresses. The client nodes’ statesduring their lifetime are shown in fig. 3c.

As soon as more than a single AP is in range andmultiple beacons are received, the INFRA needs to choosewhich AP to connect to. A simple decision algorithmbased on the euclidian distance between AP and mobileterminal is used. The distance is used as a simple ap-proximation for the signal power of the correspondingAP to simplify the calculation. INFRA however does

2All modifications presented in this paper where done using ns–2version ns-2.29.3.

not simply choose the nearest/strongest AP in reach, butapplies a dampening algorithm, see fig. 4, in order tominimize AP hopping that may occur if APs are placedvery close together. The algorithm uses two parametersfor its operation. The first parameter T specifies a signalpower above which a change of APs will unlikely resultin increased performance, so if the current AP’s signalis stronger, no change will be performed. The secondparameter G ∈ R, G > 1 specifies a minimum increase insignal power (and subsequently expected in performance)that must be gained by a change of APs; if the gain islower, the current AP is retained.

The parameters T and G may be tuned, the defaultvalues where chosen as 85% of the maximum signalpower and 10% required gain (G := 1.1). With this set-ting, no AP hopping occurred during the tests. This maybe replaced by a more sophisticated decision procedureas required. The implementation of the exact procedureused by IEEE 802.11 is also possible, but overkill for theintended emulation purposes.

When switching between APs the client enters theroaming state indicating that it is still connected to oneAP, but awaiting an address assignment from another.This state is left if either a new address is assigned, therequest is declined, or a timeout occurs. In the latter casesthe client stays connected to its current AP, while in thefirst case it gracefully returns its current lease to the oldAP and assigns the new address. Obviously situationsarise in which clients can not hand back their lease, e.g. byfailure or simply leaving the AP’s range. To cope with likesituations, every AP has a watchdog timer for each leasethat is reset with every activity of a terminal. Once thetimer is triggered, the entry is purged from the leases’ listand the address is free to be assigned to another node. Thisagain is similar to DHCP, but instead of using explicitlease renewals this is accomplished implicitly. As defaulta timer of 5min is used, which is more than sufficientas the mobile terminals display usually nearly-continuousactivity.

Compared to DHCP, the number and the complexityof messages is unchanged, but their order is reversed.Nevertheless, the periodically broadcasted beacons addan overhead to the channel. IEEE 802.11 sends beaconsevery .1s, the INFRA has a default period of .5s toreduce its overhead. DHCP operates client initiated, whileINFRA operates server initiated. Without a beacon, noINFRA-client will try to request an address, as opposed to

Input: current AP, other AP consideredOutput: the ‘better’ AP of the two

if sigPower(current AP) >T thenreturn current AP ;

if sigPower(other AP) >G * sigPower(current AP) thenreturn other AP ;

elsereturn current AP ;

Figure 4: Dampening algorithm of INFRA



DHCP Server DHCP Client

discover (B)

offer addr (B)

request addr (B)

ACK addr (B)

(a) DHCP

Base station Mobile node

beacon (B)

request addr (B)

send addr (B)

ACK addr (U)

(b) INFRA

unassigned

requested

assigned roaming

(c) Node states in INFRA

Figure 3: Dynamic address assignment; (B = broadcast packet, U = unicast packet)

DHCP-clients. In a nutshell, the INFRA is an equivalentreplacement of DHCP for simulation purposes with anidentical message complexity — as long as the periodicalbroadcasts by every server can be neglected. Assumingthe default period, a generous packet size of 500B anda bandwidth of 10MB/s, this sums up to 1

.5s ∗ 500B =1000B/s or approximately 1h of the total bandwidth perAP in the region, and is thus negligible.

A notable challenge during the development was thefact that the ns–2 packet generation mechanism createsnew packets with the source address set to the node’s set-up address instead of its current address. As any AP forobvious reasons does not forward packets received on thewireless interface with a source address outside its locallymanaged address space, all packets are dropped unlessfurther action is taken. To solve this problem, the INFRAagent at the client rewrites the source address of everysent packet, unless its broadcast/unknown, to the node’scurrent address. While this warrants the desired behaviourin all examined cases, this could still be a source forunexpected effects depending on the emulation scenarioand especially the use of third-party components.

Any association and therefore address changes of anode are important events in terms of network emulation,as they widely effect the data transport. To forward theseeffects to other ns–2-agents, the INFRA has an eventnotification service based on the observer-pattern. Anycomponent subscribing to the service is notified of addresschanges and may thus react accordingly. Notification onloss of connectivity could be implemented using the samemechanism but has not by now, as it was not required forour purposes and the discrimination between a transient(and thus ignorable) or permanent loss of link is non-trivial.

This mechanism is directly meshed with a new networkobject that was designed to provide V-NICs from withinns–2. Network objects are the components in ns–2 re-sponsible for the injection and export of network data intoand from the emulator. Inspired by Mahrenholz et.al. [7]work that enabled ns–2 to successfully access the V-NICsprovided by virtual machines and thus introduced emu-lation using virtualization to ns–2, the inverse approachwas taken here. A new network object was implementedallowing ns–2 to create virtual network interfaces based

on the vtun-facility of the Linux kernel [8]. These V-NICsmay be used like any real NIC by an application, howeverinstead of sending the data over a real network, the datais passed to the application creating the V-NIC — ns–2.Using the NIC level as an interface, the network emulationis performed completely transparent to the application,while the emulator may still control the NIC.

Currently, the TAP network object controls the IPsettings of the V-NIC. Configured with an IP addressrange, it reacts to every “new association” event signalledby the INFRA on that node by cycling the V-NIC’saddress to the next in the range thus exposing any outsideapplication to the challenge of dynamic addresses. Dueto the internal structure of the TAP network object, theinternal and external address change happen completelysynchronous, eliminating any delay between the internaland external effect.

Within ns–2, so called agents are used to simulate thehighest level of events, i.e. application or user behaviour.For emulation purposes, special network agents comple-ment the network objects situated at the nodes. Theyreceive data packets from the network object, wrap it fortransmission across the simulated network, and forwardthe contents of any encapsulated packets received fromthe simulation to the network object. Network agents arecommonly pairwise associated with one another; eachagent forwards the encapsulated data to the node hostingits associated agent. Dynamic node address assignmentand thus mutating addresses of the mobile nodes directlyresults in lost connections between the network agents, asthe target’s node address is stored during the set-up phase.The effects of changing addresses are the same within thesimulation as in the real world.

For the purpose of emulation it is not desired to havethe emulation deal with these effects, but only the outsideapplication. Inside the emulation this problem was solvedby implementing a modified TAP agent, that forwards thedata not to the address its associated node was givenduring set-up, but to its current address. Solving thisissue in a real network requires some dedicate protocol,however in the simulation this can be simply done usingan artifice. ns–2 nodes are identified by a network addressas well as an internal node ID. A modified TAP agent wasimplemented that stores its associated node’s ID instead



of its address and simply uses the ID to look up thenode on the internal node list and retrieve its currentaddress. This way, the agents will continuously forwardthe encapsulated packets to the appropriate node withoutfacing any effects caused by the address changes.

For testing purposes, the ping agent was modified toaddress its replies not to the stored address, but to thesource address of the request packet, which is a muchmore realistic behaviour than its current implementation.Further, this way a single ping agent can respond torequests from multiple sources. Using the ping agent incombination with INFRA the effects of dynamic address-ing can be observed and evaluated in pure simulationmode, which was used during the development of INFRA.

For pure emulation purposes it would have been easierto skip the mutation of the addresses of any nodes within the emulation but only to export the effect to theoutside V-NIC interface. However, this would neitherallow proper routing within the emulation to mobile nodesroaming across APs, nor would the system be reusable forsimulation purposes to evaluate protocols dealing withdynamic addresses within ns–2. The additional effortnecessary for the detailed implementation thus pays ofin the long term.

IV. USAGE AND EVALUATION

In order to demonstrate and evaluate the new compo-nents, a very simple scenario is created for emulation.It consists of two APs connected via wired networksto a server node and a single mobile terminal. Thepositioning is shown in fig. 5, the APs are arranged insuch manner that their communication regions overlap.The simulated area is assumed to be plain and free ofobstacles. The server’s position is arbitrarily chosen for anice arrangement, as it has no influence on the simulatednetwork. The APs are connected to the sever over a120Mbit/s wired link without delay, so that this link willnot influence the emulation.

The wired domain uses addresses starting with 0, andboth APs are given their own domain as well in orderto have the hierarchical routing of ns–2 computing theproper routes. Within their domain, the APs have nodeaddress 0 for their wireless interface and hand out nodeaddresses starting with 1 up to 19. The address rangesare chosen rather small to keep the hierarchical routing’srouting tables at bay, as they are quadratic in the numberof nodes per cluster. As ns–2 is very sensitive to faulty ad-dresses, it is important to correctly synchronize the setupof the hierarchical addresses with the INFRA agents, ashaving these hand out illegal addresses will at best causethe emulation to simply crash, or at worst silent faultyrouting due to routing table overflows that unknowinglyfalsify the emulation results.

During the development of the ns–2 extensions thisscenario was used in combination with the modified pingagent for verifying the new components’ behaviour. As inall tests, the active agent is located at the mobile terminalwhile the agent located at the server merely reacts to

0.0.0

1 2

mobil terminal

server

base station

transmission range

terminal path

2.0.01.0.0

� 1.0.1 1.0.1 2.0.1

2.0.1 �1.0.2

Figure 5: Example scenario

Link bandwidth [Kbit/s]Distance [m]

1

10

100

1000

10000

100000

TCP throughput [Kbit/s]

Emulated wireless link throughput vs. speed and distance

emul. bandwidththroughput

10 100 1000 10000 100000

1 10

100 1000

TCP throughput [Kbit/s]

Figure 6: Wireless calibration measurements, note logarithmic axes

incoming requests. After these tests rendered the INFRAfunctional, the emulation extensions where evaluated us-ing the same setup, but with a real ping being send fromthe mobile terminal to the server. The components wherearranged as shown in fig 2d, with terminal and emulatorbeing hosted on one machine and the server on another.Host and server machine are stock PCs using an AMDAthlon 64 3200+ CPU with 1GB RAM and connected bya dedicated 100Mbit/s Ethernet line undisturbed by crossand control traffic. The separation helps balancing theload, and simplifies the routing on the host machine, as theLinux kernel transports data packets between local NICsthrough the kernel. Rerouting these through the emulatoris rather complicated and error-prone.

The following test were performed using ns–2’s IEEE802.11 network model using two-ray-ground radio propa-gation model. While the stock IEEE 802.11 model is notup to date with the current extension of the standard3,we still stick with it for its widespread use. In order tosimulate higher bandwidths, the data rate, bandwidth, andbasic rate parameters are simply increased with a datarate equalling the bandwidth and a basic rate of a quarterof the bandwidth. Under this assumptions, calibrationmeasurements of the emulation where performed usingbandwidths of 9.6kbit/s (GPRS) up to 108Mbit/s (IEEE802.11n) in distances of 1m up to 400m using iperf [9]as a measurement tool. The measurement is the averagethroughput over a period of 15s. The results are shownin fig. 6 are as expected; for all bandwidths the measured

3There are several projects working on this problem, i.e. MathieuLacage (see http://yans.inria.fr/ns-2-80211/).



throughput is lower due to protocol overhead. For highbandwidths the difference grows, as the protocol partsusing the lower basic rate and the constant synchroniza-tion times affect the results adversely. The throughputdrops with higher distances, as more bit errors etc. occur.For low bandwidths at high distances the throughputis so low that iperf was not even able to conduct theTCP three-way-handshake and hence produced no mea-surements. During these test, the emulator reported nosingle occurrence of lag. This results prove that TAPnetwork object and TAP agent operate as designed, thatthe performance of the ns–2 emulation even on stockhardware is sufficient to route even current WLAN trafficand that the practical throughput of an 108Mbit/s linkis lower than the bandwidth of the dedicate link betweenthe emulation machines.

The next function to be scrutinized is the export of em-ulator internal address changes to the V-NIC. In its currentimplementation, this process stops the emulator during theexport in order to guarantee synchronous behaviour ofinside and outside interfaces. For measuring a modifiedversion of the TAP network object was implemented thatsimply times the export process and aborts the simulation.Repeated runs of this procedure resulted in an export timeof 3.90± 0.02ms, which is small compared to the delaysintroduced into by the emulation and therefore promisesemulations without lag.

In order to test the INFRA three mobility patterns forthe mobile terminal are used. In all cases, the terminalvelocity was assumed to be 5m/s. The first pattern is amovement on the axis connecting the two APs startingat the edge of AP 1’s transmission range and ending onAP 2’s range. Using this pattern, the behaviour of theINFRA with a ‘normal’ handover was verified, includingthe delaying effects of the dampening algorithm. Thesecond pattern is a linear movement on the perpendicularbisector of that axis. As the terminal is now constantlyequidistant from both nodes, this stresses the dampeningalgorithm. It behaves as expected, once an AP is selectedit is retained. At higher terminal velocity the AP maybe changed depending on the interleaving of the beaconsemitted by the APs. For the third mobility model, themobile terminal moves on a path that exposes it to all fourpossible states of RAN availability: no access, access toAP 1 only, access to both APs, and access to AP 2 only.Afterwards, the triangular part of the path is cycled. Thispath combined with the (initial) address states along it isshown in fig. 5. This simple setup is useful to examine thebehaviour of protocols with focus on the exact momentsof changed availability. For long term evaluation, a setupusing a hexagonal pattern of APs on a rectangular planeis more useful. Depending on the ration between APspacing and AP range, as well full coverage of the areawith a varying degree of overlapping of the transmissiondomains as incomplete coverage can be simulated. Whilethis is a synthetic scenario, the right spacing parameters incombination with a suitable mobility generator producesquite accurate long-term results, as real world RANs

expose a similar structure.Increasingly often applications are using multiple con-

current RANs on a single mobile terminal, i.e. GPRS,UMTS and WiFi. This addition to ns–2 is also suitablefor such scenarios, however the application is not straight-forward. Using multiple interfaces on a single ns–2 nodewill cause ns–2 to select an interface internally, butusually this is exactly the decision that should be made bythe tested application. For such scenarios, a multiple ns–2nodes must be used to represent a single mobile terminal.Every node of this group has a single RAN uplink repre-senting one of the composed terminal’s interfaces. Beinglocated on separate nodes, ns–2’s internal mechanismswill not interfere with the choice of the currently usedRAN. Obviously all nodes of the group need to maintainthe same position with in the simulation’s topology andbe move synchronously. That however is an easy tasksince it simply involves using the same movements for allnodes of a cluster. Further, the cluster sizes are expectedto be in the range of single-digit numbers, as in practicethe number of concurrently used RANs is limited by thedevice’s size and power consumption. Considering thatthe number of emulated mobile terminals is anticipatedto be reasonably low, the overhead introduced by using agroup of nodes to represent a single mobile terminal willtherefore be acceptable.

V. APPLICATION

The V-NIC emulation approach using the ns–2 exten-sions was used to evaluate middleware performance ifused from a terminal connected via a RAN. As describedin section I, the comparison of middleware platformsusing simulation is rather time consuming, as modelsfor every platform and application need to be generated.Hence network emulation is especially attractive for theevaluation of middleware applications and a good exam-ple application of the enhanced ns–2 emulation facilities.

For the evaluation, a simple middleware componentcalled loadserver was created with an interface as shownin fig 7. The loadserver simply accepts requests con-taining an arbitrary number data bytes as parameters,delays time ms ms to emulate processing of the requestand returns a result with resultsize B of dummy data.There are two modes of operation, the naive synchronousapproach that blocks the caller while processing, and anasynchronous approach that requires explicit retrieval of aresult by the caller using a token that has been returned ondispatch of every request. Results and tokens are providedwith a local time stamp to support timing of calls onthe client side. Depending on the client implementationvarious middleware applications can be emulated usingthe loadserver.

Selecting ORBit2 as ORB [10], the naive approach, andthe emulation scenario depicted in fig. 5 a client was usedto make 16B sized requests with no computation timeand a result size increasing from 16B to 1MB. 25 passeswere made and the data shown in fig. 8 collected. Theoverall outcome is not as interesting as the two significant



mavericks at pass (2kB/20) and (4kB/9). Both readingsare several orders of magnitude higher than the readingsof the other passes. This is an effect of dynamic NICaddresses on the clients side. Due to the interleaving atexactly this two points an address change occurs in sucha manner, that the TCP connection between client andserver has been established but is idle. During the idleperiod, caused by data processing on the client or theserver side, the address change occurs. The NIC receivesa new address and all data destined to the old addressis discarded by the OS. This way the call makes noprogress and stalls until a timer ends the connection, inthis experiment the duration equals nearly a completemovement cycle. During this period all further changes gounnoticed, and any chances to reestablish the connectionare not used.

This property of TCP has a severe effect on theperformance when used over RAN. The two interruptionsare below 1% of the calls, but have a combined runtimeof 20% of the total runtime of this experiment. Up untilVersion ORBit2.17.3 of the ORB, released early in 2007,there was no parameter to influence the hold time for idlelinks and the user had to implement his own timeouts tobe able to mitigate this problem. This obviously showsthat the effects of RANs in distributed applications arefar beyond the direct effects on the channel, namingbandwidth, delay, jitter, and packet error rate.

Similar experiments where conducted using JAVA RMIand web services, which was due to the emulation setupmerely a question of implementing the appropriate clientand server application. The network emulation had notto be changed, nor will it need to be changed for anyfuture application. The performance of other middlewaresystems differs from CORBA’s performance, especiallywith web services as XML data encoding is much lessefficient than the binary representations of CORBA andJAVA RMI. However, the general behaviour is the same;the mavericks caused by address changes have a differentextend due to different timeouts, but still occur.

To improve the performance of middleware applica-tions in RANs, a sensor architecture was designed and

i n t e r f a c e l o a d s e r v e r {s t r u c t s t r u c t D a t a {

sequence<o c t e t > b u f f e r ;long t imes t amp ;

} ;s t r u c t s t r u c t T o k e n {

long i d ;long t imes t amp ;

} ;s t r u c t D a t a work ( in long t ime ms ,

in s t r u c t D a t a workdata , in long r e s u l t s i z e ) ;

s t r u c t T o k e n work async ( in long t ime ms ,in s t r u c t D a t a workdata , in long r e s u l t s i z e ) ;

s t r u c t D a t a r e s u l t a s y n c ( in s t r u c t T o k e n t o k e n ) ;} ;

Figure 7: simplified loadserver interface definition

0.001

0.01

0.1

1

10

100

16 64

256 1024

4096 16384

65536 262144

1.04858e+006 0

5

10

15

20

25

0.001

0.01

0.1

1

10

100

time [s]

Result [Bytes]

Pass

time [s]

Figure 8: Results of CORBA experiment; 16B requests, 0msprocessing time, 11Mbit/s RAN

16 64 256 1024 4096 16384 65536 262144 1.04858e+006

0

5

10

15

20

-8-7-6-5-4-3-2-1 0 1

time [s]

0 planedt (monitoring-naive)

Result [Bytes]

Pass

time [s]

Figure 9: Comparison of naive and monitoring CORBA application

implemented that continuously monitors the NIC at theterminal and notifies the application of any significantchanges. Upon i.e. a new network address the applica-tion can immediately take appropriate action, as cancelpending calls and repeat them using the new networkaddress. Obviously, testing is vital for such applications,as the overhead for the monitoring must be balancedagainst the delay before changes are detected. Testingthis using an identical emulation set up as for the naiveCORBA application results by chance with mavericks atthe same positions as the CORBA experiment, facilitat-ing the comparison widely. Fig. 9 shows the differencebetween the results of the naive implementation and theimplementation with monitoring. Overall, the implemen-tation with monitoring is a little slower than the naiveimplementation due the monitoring etc. overhead. At thepoint of the address changes however, the monitoring im-plementation recovers much faster than the naive imple-mentation. While the overall runtime is roughly the samefor both approaches, there is obviously much less jitterin the response times of the monitoring implementation,making it much more suitable for interactive or other timesensitive applications.

The effects of call density versus terminal speed andtherefore the average time spend at the same AP arealso very notable. These influences can be evaluated bysetting different topologies and node mobility patternsup within the emulation. All outside components donot require adjustment. This makes e.g. automatic nodemovement generation via e.g. CANU [11] possible and



the use of discretionary RANs in application testing.Again, this could be tested without any changes to theemulator, the setup or the application to accommodatethe emulation setting. This demonstrates the power ofnetwork emulation implementing V-NICs as a tool forthe development of distributed applications.

VI. FURTHER DEVELOPMENT

The Linux kernel’s vtun device is designed to behavelike a virtual NIC to a wired network and was intended tofacilitate network data tunneling using user space applica-tions, e.g. openVPN featuring data encryption. Thereforeonly wired networks’ properties are reflected by the driverand exported to tools and applications. The kernel usesthe so-called Wireless Extensions (WE) [12] for access toand managing of wireless NICs. Thus, to export wirelessproperties from within ns–2 , an enriched version of thevtun interface is required, a wtun4 device that implementsthe WE API. This way all existing tools and proceduresfor the management of wireless links may be used onlinks emulated by ns–2, and allow an universal use of theemulator as tool not only for application but also for OStool development.

The vtun device driver has basically two interfaces.First, a network device interface that is used to createthe virtual device and used by outside applications, andsecond a character device interface that is used by theapplication creating the virtual interface for reading andwriting data. The vtun device driver simply passes thedata between these two interfaces. To handle the statusinformation that is provided by the WE, the wtun driveruses some local data for every device instance to storethe complete status information. The WE interface merelyaccesses this information in in way that hardly differsfrom the access to real wireless NICs. While a realwireless NIC collects the status information handled backduring its operation, the wtun device extends the vtundriver’s control interface on the character side with getand set operations to all wireless status information. Thisis done using driver-specific ioctl-calls and gives theapplication creating the virtual device complete controlover the network side’s appearance to tools and applica-tions.

The implementation of the wtun device driver is notcompleted by now, as functions are implemented on aneed-to-have basis. The WE interface implementationis finished in all major aspects, however the completeencryption functionality has been skipped as it deemsunnecessary for emulation purposes — and a virtual in-terface that has no physical layer that would allow eaves-dropping to begin with. Notable not implemented, butdesirable is the capability to monitor the signal strengthof every designated node in range instead of just theAP. The WE API is evolving to make more informationand functionality available, and limiting the functionality

4’w ≡ v++’

of the wtun device driver to the most commonly usedfunctions becomes necessary.

The development of the wtun device driver progressesin parallel to the development of the ns–2 TAP networkobject , which is to use the new facilities to export moreinformation about the emulation status to the outsideworld. The WE in the TAP network object may beturned on or off by parameter, so the TAP network objectmay be still be used to emulate wired links without theoverhead of maintaining the wireless status. There areseveral design issues that need to be solved for an easyand efficient export of the WE status. While returning thecurrent signal quality, nodes in reach etc. is a rather simpletask on a real device driver, getting it from the emulatoris not as easy. The wtun device driver has no means todirectly access the TAP network object and thus ns–2 toretrieve the information. This means either a push or a pullapproach needs to be implemented. An update for everypacket send or received by the TAP network object isthe straight-forward push solution, however consisting ofnumerous ioctl-calls it imposes a significant overheadand does not update the information without any networkactivity. Currently the TAP network object is implementedin a way that it periodically, every .5s by default, pushesthe current virtual status into the wtun device. This causesobviously a small overhead if the status information is notneeded and a delay of up to .5s between the data and thereal status due to the update period. This defeats the ideaof synchrony that initial drove the idea of incorporatingV-NICs into the emulation. Should the tradeoff for thesake of efficiency not be acceptable for an emulationsetup, it requires next to none effort to additionally triggeran update for every packet transmitted and combine itwith the timer. This way, in periods with high activitythe status is updated constantly providing the desiredprecision, while periodic updates during idle time improveefficiency.

A pull approach using a signal handler could be im-plemented. Triggered by a request to the V-NIC, it wouldpull that current information from the ns–2 TAP networkobject and deliver it to the application hence createno overhead and always deliver the latest information.However, this is difficult to implement and it is unsure,whether signal handlers may be used within ns–2 withoutinterfering with other components, so for now the pushapproach is sufficient.

The TAP network object can gather the diverse infor-mation about the simulated wireless link using severalmethods from within the emulator. Some information,e.g. SSID, have no direct equivalent in ns–2, but can bemodeled by other means, e.g. the channel concept withinns–2. Additions to the TAP network object translate thisns–2 internal concepts into data compatible with thewireless extensions, in this case using the name of thechannel object as SSID.

The integration of the INFRA with other ns–2 compo-nents, especially user designed extensions, has its pitfalls.Experiments using the contributed GPRS link layer [13]



and the UMTS link layer [14], [15] failed as theselayers use the nodes’ addresses to reassemble packets.Reassembly and thus packet transport fails as soon asthese addresses change, rendering these extensions incom-patible with INFRA. These issues may be solved after thecurrent overhaul of ns–2 leading to ns–3.

VII. CONCLUSION

Only by removing the need for real RANs and real ter-minal mobility test runs can become a feasible step in thedevelopment cycle of distributed applications. This can beaccomplished by network emulation making it an impor-tant tool for the development of distributed applications.Terminals connected by RANs require active componentsto mitigate the effects of ever changing connectivity,which may be part of theOS or the distributed applicationitself. In order to evaluate these components, the plainclassical black box approach to network emulation isno longer sufficient, as information about the emulatednetwork’s status must be made available to the outsideapplication. This can be accomplished by the use of V-NICs created by the emulator.

The ns–2 software was enhanced by several com-ponents. The INFRA simulates a DHCP-like dynamicaddress assignment, the TAP network object creates andmanages the virtual NICs and the TAP agent ensuresproper routing of data through the emulator in presenceof dynamic addresses. TAP network object and INFRAcombined export the internal changes to the externallyvisible V-NIC. Internal and external effects happen syn-chronously, ensuring precise and predictive behaviourof the emulator. Tests confirmed these dynamics didnot affect the emulator’s performance to an extend thatwould introduce lag into the emulation process and thusinvalidate any results. However, the use of dynamic nodeaddresses is not compatible with all ns–2 components,especially extensions provided by other users.

Since the Linux kernel’s device driver for virtual NICs,vtun, only exposes the APIs for NICs to wired networks,an extended device driver called wtun was implementedthat includes the WE API as well. Using this driver and anappropriately enriched TAP network object inside ns–2,all major status information of an emulated RAN insidethe emulation is accessible on the V-NIC as well. Whilenot all information is currently available, i.e. the completecryptography functionality was excluded, the wtun driverand the TAP network object can easily be extended ondemand.

Several experiments involving middleware applicationswhere presented as an example application of networkemulation using V-NICs during the development cycle ofdistributed applications. The results show the influenceof the exported RAN effects on the application. Theirinfluences on the data transmission is major, and could notbe observed without the new export facilities. Networkemulation using V-NICs allows an easy evaluation ofdistributed applications using adaptive algorithms and

complex middleware without the overhead of model con-struction that would be required for simulation.

REFERENCES

[1] K. R. Fall, “Network emulation in the vint/NS simulator,” in ISCC.IEEE Computer Society, 1999, pp. 244–250. [Online]. Available: http://csdl.computer.org/comp/proceedings/iscc/1999/0250/00/02500244abs.htm

[2] X. Chang, “Network simulations with opnet,” in WSC ’99: Proceedings ofthe 31st conference on Winter simulation. New York, NY, USA: ACMPress, 1999, pp. 307–314.

[3] X. Zeng, R. Bagrodia, and M. Gerla, “Glomosim: A library for parallelsimulation of large-scale wireless networks,” in Proceedings of the12th Workshop on Parallel and Distributed Simulation (12th PADS’98),B. Unger and A. Ferscha, Eds. Banff, Alberta, Canada: ACM/Societyfor Simulation (SCS), San Diego, May 1998, pp. 154–161. [Online].Available: http://doi.acm.org/10.1145/278008.278027

[4] M. Carson and D. Santay, “NIST net: a linux-based network emulationtool,” Computer Communication Review, vol. 33, no. 3, pp. 111–126,2003. [Online]. Available: http://doi.acm.org/10.1145/956993.957007

[5] L. Rizzo, “Dummynet: A simple approach to the evaluation of networkprotocols,” ACM Computer Communication Review, vol. 27, no. 1,pp. 31–41, Jan. 1997. [Online]. Available: http://www.iet.unipi.it/∼luigi/dummynet.ps.gz

[6] R. Droms, “Dynamic Host Configuration Protocol,” RFC 2131 (DraftStandard), Mar. 1997, updated by RFCs 3396, 4361. [Online]. Available:http://www.ietf.org/rfc/rfc2131.txt

[7] D. Mahrenholz and S. Ivanov, “Adjusting the ns-2 emulation mode toa live network,” in Kommunikation in Verteilten Systemen (KiVS), 14.ITG/GI-Fachtagung Kommunikation in Verteilten Systemen (KiVS 2005)Kaiserslautern, 28. Februar - 3. Marz 2005, ser. Informatik Aktuell,P. Muller, R. Gotzhein, and J. B. Schmitt, Eds. Springer, 2005, pp. 205–217.

[8] R. Breen, “VTun,” Linux Journal, vol. 2003, no. 112, pp. 6–6, Aug. 2003.[9] A. Tirumala, “End-to-end bandwidth measurement using iperf,” in SC’2001

Conference CD. Denver: ACM SIGARCH/IEEE, Nov. 2001, nationalLaboratory for Applied Network Research (NLANR). [Online]. Available:http://dast.nlanr.net/Projects/Iperf

[10] G. Foundation, “Orbit2 – a corba 2.4-compliant object request broker,”online, 2002. [Online]. Available: http://www.gnome.org/projects/ORBit2/

[11] I. Stepanov, J. Hahner, C. Becker, J. Tian, and K. Rothermel,“A meta-model and framework for user mobility in mobilenetworks,” in Proceedings of the 11th International Conferenceon Networking 2003 (ICON 2003), Sydney, Australia, September28 - October 1, 2003. New York: IEEE Press, Sept. 2003, pp.231–238. [Online]. Available: ftp://ftp.informatik.uni-stuttgart.de/pub/library/ncstrl.ustuttgart fi/INPROC-2003-15/INPROC-2003-15.pdfurl:http://canu.informatik.uni-stuttgart.de/mobisim

[12] J. Tourrilhes, “Wireless tools for linux,” online, Feb. 2007. [Online]. Avail-able: http://www.hpl.hp.com/personal/Jean Tourrilhes/Linux/Tools.html

[13] R. Jain, “Extending the ns2 simulator for GPRS support,” 2001. [Online].Available: http://www.it.iitb.ac.in/∼sri/students/richa-thesis.pdf

[14] A. Bjrsson, “Simulation analysis of RLC/MAC for UMTS in networksimulator version 2,” Dec. 2003. [Online]. Available: http://www.ep.liu.se/exjobb/isy/2003/3399/

[15] F. Eng, “New modules for ns-2,” 2004. [Online]. Available: http://www.control.isy.liu.se/∼frida/nsmodules

Tim Seipold is currently a doctoral (∼ Ph.D.) candidate atRWTH Aachen University of Technology Aachen, where hecompleted his Diplom (∼ Msc.) degree in informatics 2001.He worked as research staff and project manager on severalprojects during 2001-2006. His research interests distributedapplications and P2P technology in RANs.



emulation of radio access networks to facilitate the

Documents