Mobility Emulator for DTN and MANET Applications

Hayoung Yoon
Gwangju Institute of Science and Technology (GIST) Gwanju, 500-712, Korea

JongWon Kim
Gwangju Institute of Science and Technology (GIST) Gwanju, 500-712, Korea Maximilian Ott
National ICT Australia Sydney, Australia Thierry Rakotoarivelo
National ICT Australia Sydney, Australia ABSTRACT
Repeatable experiments to study the performance or behavior of wireless mobile adhoc network (MANET) systems such as a delay (or disruption) tolerant network (DTN) are challenging tasks. One approach to do this is to build a realistic mobile testbed, on which the mobile devices and test applications or network protocols can be deployed. This testbed approach, however, often results in expensive management and setup costs. Therefore, most of algorithms and applications considering device mobility as a critical parameter have been tested using trace-based analysis and computer simulations. However, these evaluation methods are not sufficient to reflect various natures of mobile wireless networks. This paper presents the design and implementation of an On/Off-based mobility emulation method, which virtually migrates applications over a static-grid testbed to mimic the device mobility. This emulation method assists DTN and MANET developers to evaluate their work in repeatable ways on the labscale static-grid testbed. Through extensive experimental analysis and a case study using two different testbeds, we show that the proposed emulation method can successfully recreate important characteristics of mobility trace data, such as contact and inter-contact time distributions. 1. INTRODUCTION
Many research contributions in the wireless networking area propose to apply solutions from DTN [8] problems to MANET-related issues [7, 25, 4, 21, 24, 13, 11, 22, 12]. These researches exploit contact opportunities between two mobile nodes (or a mobile node and infrastructure) to maintain better end-to-end connectivity [7, 4] and to distribute contents efficiently [24, 13, 11, 22, 12] in a hostile mobile wireless environment, where exists intermittent wireless infrastructures and irregular bandwidth . In DTN, mobile nodes may establish on and off connectivity with their neighbors who are located within a radio range. One of the mostly studied routing algorithm in DTN is two-hop relay [6]. A source node sends a message (or a series of packets) to its neighbors. The message is carried by neighbors and relayed its destination node when they are in a contact. The period between the time that message is originated and the time that the message is delivered to the destination node is considered as an end-to-end delay. This is one of the important performance measures in DTN. There is a measure of the characterization of device mobility called inter-contact time, the time period between two successive contacts of same mobile nodes. Earlier studies revealed that inter-contact time highly relates to the end-to-end delay performance in DTN [19]. Therefore, recently developed DTN and modern MANET applications are simulated and evaluated under various mobility scenarios capturing different inter-contact time distributions [10, 20]. While simulation-based experiments are easy to manage and reproduce experimental environments, it is getting clear that they are not able to capture various aspects from mobile computing environments as they make inherent models to be simplified. Supporting repeatable experimental evaluations for DTN and modern MANET applications are quite challenging. Building and using a realistic mobile testbeds provides the most realistic results [21, 25]. However, it is extremely costly to setup and hard to maintain because it requires someone or something to actually carry the devices along the planned trajectories. In fact, most analysis and evaluations in this research area are based on small-scale toy scenarios [24, 22, 11] and computer simulations [13, 24, 10, 20]. Unfortunately for the DTN and MANET application developers, there is lack of evaluation process in the middle of unrealistic

Categories and Subject Descriptors
C.2.2 [Network Protocols]: Protocol Verification; C.4 [Performance of Systems]: Design Studies

General Terms
Algorithms, Design, Experimentation, Measurements

DTN, MANET, emulation, mobility, testbed, repeatability, and measurement.

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. WiNTECH’09, September 21, 2009, Beijing, China. Copyright 2009 ACM 978-1-60558-740-0/09/09 ...$5.00.


Signaling /Initiation

Neighbor Discovery Failure


Signaling or Discovery

time Inter-Contact Duration

Contact Duration

Link-broken/ Time-over/ Finish

Communica tion



Figure 1: The illustration of a) DTN/MANET applications operation and b) its modeling.




Cross-layer Interactable



Figure 2: The mobility emulation in a) conventional and 2) proposed methods. computer simulations and hardly manageable real testbedbased experiments. This paper proposes an emulation approach to unrealistic emulations and expensive mobile testbed-based experiments. The proposed emulation is based on mobility emulations over a stationary-grid wireless testbed. Specifically, we design and implement an On/Off-based mobility emulation that virtually migrates applications over waypoints (i.e., a sequence of static-grid nodes sampled from the movement trajectory) on the testbed. The proposed emulation method is done by a series of processes: 1) taking a snapshot of a running application, 2) turning-off the application, and 3) relaunching the application which resumes the earlier snapshot at another static-grid node. By consecutively conducting these processes at each waypoint, the proposed emulation method virtually migrates the tested application along its movement trajectory. It enables applications to maintain tight interactions with underlying networking stack like MAC/PHY while they are moving over the static-grid testbed. Through extensive experimental analysis and a case study using two different testbeds, we have verified the this approach successfully regenerates important characteristics of mobility trace data such as contact and inter-contact time distribution. This paper is organized as follow. In Section 2, we review related work and discuss the motivation of this work. In Section 3, we outline the design of proposed On/Off-based mobility emulator. We then present the its realization, the measurement results using this approach, and analyze them in Section 4. The case study using mobile p2p application is described in Section 5. Section 6 concludes this paper giving directions for future work .



Modern MANET applications [24, 13, 11, 4, 22] exploit the contact opportunity amongst mobile devices carried by humans for the P2P contents sharing [13, 22, 4] and

distribution [24, 11]. Their behavior can be separated into two cases as illustrated in Figure 1(a). When mobile devices have no contact, they keep probing to discover appropriate neighbors by either passively listening or actively polling. Upon finding a neighbor to communicate with, they initiate communication link and exchange a message (or a series of packets). The duration of such data transfer is often restricted below certain predefined thresholds [24, 11, 13] to make it resilient to link breaks due to the device mobility. Thus, the communication link for message transfer may be reestablished even though the two mobile nodes are still in a contact. This behavior of the DTN and MANET application can be modeled by a state-machine, as illustrated in Figure 1(b). The state-machine shows 3 finite states for the application, i.e., idle, discovery/initiation, and message transfer. Some of modern MANET applications [24, 11] and DTN testbeds [7, 21] interact with underlying MAC/PHY and network layers to maximize the utilization of the contact duration by effetively sensing neighboring devices and quickly switching their device’s operational mode. For instance, Carbernet [7] introduces QuickWiFi that reduces connection initiation time including association/athentication, IP address inquiring, and connection assessment processes done at the separate network stacks. QuickWiFi integrates those processes into the single process at the user level application leveraging interaction with underlying MAC/PHY and network layers. Bluetorrent [11] and MOVi (mobile opportunistic video-on-demand) [24] switches wireless interface from infrastructure to adhoc modes upon discovering peers to exchange data with. There are a few existing studies mobility emulation over the static-grid topology [17, 9, 15]. The main idea is to connect the mobile nodes to the testbed, map the generated traffic from a mobile application to grid nodes via network tunnels (over high-speed link such as gigabit Ethernet) and transfer the traffic from wireless network interface at grid nodes. As depicted in Figure 2(a), the mobility of application is emulated by switching the tunneled static node along the mobility trajectory. Unfortunately, tunneling and spatial switching approaches are not favorable to study DTN and modern MANET applications, as they make it hard for applications to interact with underlying network stacks. Examples of such interactions across network stacks could be either by polling layer-specific measurement data (for example, the received signal strength indicator (RSSI) information with access points (APs)) or triggering to change the operational mode of the layers. Those interactions are usually done via OS (operating system) supported system calls such as ioctl and /proc file systems interfaces [24, 14, 5]. These cross-layer interactions can not be implemented efficiently when using the emulation methods proposed by [17, 9, 15], which separate the application and underlying network stacks on different physical nodes. We have designed an On/Off-based mobility emulator which migrates a user application running over different nodes at different times. Instead of the previous tunneling and switching method, in the proposed scheme, mobility is emulated by migrating running instance of applications along waypoints of the mobility path as illustrated in Figure 2(b). Our approach allows applications to maintain tight interactions with underlying networking stack like


at T0 APP1 on Node1 at T1 APP1 on Node2

T Emulator Server




1 Turn-Off T 1: APP1


3 1:

APP1 Snapshot (APP1) Snapshot/ Off Emulator Client Node1 T
2 1:

On/ Resume Snapshot (APP1)

Emulator Client

Node2 APP1

Relay Snapshot (APP1)

Figure 3: The operational procedure of proposed On/Off-based mobility emulator. MAC/PHY, while they are moving over the static-grid testbed.



3.1 Proposed Emulator Overview
Figure 3 illustrates the operation of the proposed emulator. There are two logical entities in our mobility emulator design. Emulator Server (ES) reads the trace file which tells the latest location for each application and then triggers Turn-off/Snapshot, Relay, and Launch/Resume operations. Emulator Clients (ECs), running at the current and next waypoints of each application, perform those operations. As soon as EC receives a Turn-off/Snapshot message from ES, EC forwards it to the application running on the same node. The application itself then takes a Snapshot by encoding internal application status, packetize it, transfer it to EC, and turn-off itself. When EC receives the Snapshot, it simply relays it to ES. ES then forwards it to the EC at the next location of the application with the command to launch application which resumes the relayed Snapshot. The reality performance of the proposed mobility emulation highly depends on the migration speed. The shorter the migration latency, the higher the degree of reality performance. Normally, migration latencies are application specific. If applications tested in mobility emulations have too long latency to be launched and the volume of the Snapshot is too large to be relayed for short time, they might not be properly evaluated by the proposed method. For example, an application downloads a large size file may require to keep the incompletely downloaded file across migrations. Thus, it might take long time to relay Snapshot including the incomplete piece of file. As another example, video streaming applications may accompany a video player that normally takes non-trivial startup latency. However, these applications can be simplified for the emulation experiments as long as developer can track both performance and operation of tested applications during experiments. For the former downloading application case, the Snapshot could include progress indicator of file downloads instead of entire incomplete data file. If the downloading file is indexed as p2p file-sharing applications, including the index of each chunk stored local cache enables developers to track the progress of file downloading. For the latter video streaming application case, there is well known performance evaluation methods to estimate videoplayout quality without an actual video playout [24]. In addition, one may minimize the latency to turn-off and

Algorithm 1 Mobility emulation procedure at ES. 1: AppCnt[] ⇐ 0 2: OriginalT race[] ⇐ getTrace() 3: ApproxT race[] ⇐ doApproximation(OriginalT race) 4: L ⇐ sizeof(ApproxT race) 5: sortInTime(ApproxT race) 6: for i = 1 to L do 7: Tnow ⇐ getCurrentTime() 8: AppID ⇐ getAppID(ApproxT race(i)) 9: Tmig ⇐ getMigrationTime(AppID) 10: LOCnext ⇐ getNextLoc(AppID) 11: doSleepFor(Tmig − Tnow ) 12: if AppID is NOT new then 13: LOCcurr ⇐ getCurrentLoc(AppID) 14: DestoryApp(AppID, LOCcurr ) 15: Decrement AppCnt[LOCcurr ] 16: end if 17: if AppCnt[LOCnext ] is NOT 0 then 18: LOCnext ⇐ reLoad(Tmig , AppID, OriginalT race) 19: end if 20: LaunchApp(AppID, LOCnext ) 21: Increment AppCnt[LOCnext ] 22: end for

relaunch application by replacing them respectively to pause and resume operations.

3.2 Design of On/Off-based Mobility Emulator
3.2.1 Mobility trace approximation
Suppose there are traces containing N mobile devices’ mobility trajectory for experiment time T . Each has a series of 3-tuple record <t, i, (x, y)>, where t ∈ (0, T ) indicates time, i ∈ (1, N ) is a unique id of device (or application) and (x, y) is the coordinate of i. The mapping is approximating the coordinates of each record for all N and entire T to the predefined static-grid topology <(Xm, Y m), (Dx, Dy)>, where (Xm, Y m) is the size of territory and (Dx, Dy) is the dimension of concentration. For the simplicity, we assume that the topology is uniform static-grid so Xm = Y m = M and Dx = Dy = D. We also note that D is decided by the positive integer approximation factor A as D = M/A 1 . The coordinate approximation (¯, y) of (x, y) is done as x ¯ D + (n − 1)D, and 2 D + (n − 1)D if (n − 1)D ≤ y < nD, then y = ¯ 2 for all n = 1, ..., A. if (n − 1)D ≤ x < nD, then x = ¯

3.2.2 Handling concurrent applications
While the proposed emulator migrates applications over a set of waypoints, it might be happen to put more than one applications on the same waypoint. It is common for DTN and MANET application developers to assume that their developing applications will not operate on the same node simultaneously because they would rather be interested and focused on how contacted mobile devices

The choice of optimal A is out of scope in this paper.

[1,11] 1 meter [1,1]

1 meter [11,11]


11 nodes

Figure 4: ORBIT topology used in experiments. interact with each other. Though static-grid testbeds may provide multiple wireless networking interfaces to each node, the communication between applications running on the same node is not very natural. Thus, we restrict that more than one applications shall not be located at the same node concurrently. When it happens, we relocate the application to the next closest waypoint which does not carry any application on it. The emulation procedure including this relocation executed at ES is briefed in Algorithm 1.

Both ORBIT and NORBIT are powered by the cOntrol and Management Framework (OMF) [2] that is a suite of software components, which provides control, measurement, and management tools & services to users and operators of networking testbeds. We obtained human mobility trace from Levy-walk model trace generator introduced in [18]. This model has claimed that the generated traces can sufficiently keep the nature of human walk such as heavy-tail inter contact time distribution reported in [19]. We have prepared the scenario for experiments as 1) 1000 x 1000 territory (M = 1000), 2) Cr (contact range) = 250m, 3) 10 mobile nodes and 4) 1000 sec duration. We keep the mobility model specific parameters as default such as α = 0.99 and scalef actor = 10 [18]. It is noted that the trace contains 10 human-driven mobile nodes which has movement speed at around 1 m/sec in average.

11 nodes

4.2 Emulator Realization and Verification Scenario
We have developed a simple DTN and MANET application nullApp using C and the modification of MadWiFi [1] and configured with EC and ES implementations. Each nullApp is mapped to each mobile from the generated trace and moved over static-grid topology until the experiment finishes. Both emulator and nullApp were established as an experiment on top of OMF. The nullApp periodically (at every 400 msec) broadcasts link-layer probing messages. The message includes the IP address of application, source MAC address and applicationlevel unique ID. For every received probing message at the MAC-layer, the list of neighboring nullApp is updated into 4-tupule <SIN R, M ACaddr, IP addr, AppU ID>, where the SINR (signal-to-noise ratio) value is calculated from received probing message. The nullApp periodically (at every 200msec) gathers the list from MAC-layer via IOCT L and forward to the central measurement repository point connected with gigabit ethernet cable to each static-grid node. Thus, central measurement repository can have realtime link-quality map over entire of nullApp. The following is the list of measurement metrics that we are interested here for the analysis. 1. Mobility trajectories: We measure the mobility trajectories for four cases 1) Orig which is use of pure trace, 2) Apprx which is use of approximated trace, 3) Sim which is approximated and resolves two applications in the same node events, and 4) Emul which is the output movement trace containing impacts caused by delayed migrations and relocations. 2. Snapshot relaying and launch latency: This is the summation of both latencies to relay the Snapshot and to launch new applications. We vary the volume of Snapshot and observe the latency variation. The volume size is set to as multiple of Ethernet maximum transmission unit (MTU) size (i.e., 1500 bytes). We observe more than 5,000 samples of migration for each configuration. For each sample, we measure the time that the first Snapshot packet is received at ES (TRelayStart) from current waypoint and the time that ACK received at ES (TACK ) from next waypoint. The latency is calculated by subtracting TRelayStart from TACK .

3.2.3 Delayed migration
Suppose that we happen to migrate an application, which is in the middle of message transfer (i.e., the application in the Communication state; see Figure 1(b) in Section 2). If the next waypoint is still in a range of valid contact, carrying application status from one to another is not enough even though the migration has quickly done. To keep the transparency, it is indeed required to configure the MAC/IP address exactly same as the one located before. Configuring network interfaces at each migration is not suitable for our case because it takes order of seconds to configure and raises other troubles such as address conflicts. If we only allow applications to migrate at the IDLE states (see Figure 1(b) in Section 2), however, we can use different MAC/IP address for the same application while it keeps transparency by relaying application status including a unique ID configured at the application layer. This delayed migration is seen by neighbors as the one neighboring device disappeared after the data transfer and new neighboring device owns same application status with disappeared one contacted.



In this section, we introduce the experimental results and those analysis performed in two grid testbeds. We first brief the experimental setup and show how the proposed mobility emulator generates the human mobility trace over static-grid testbed.

4.1 Testbeds and Mobility Trace
We use two different testbeds for experiments. The one is ORBIT [3], a 20x20 static-grid and uniformly installed wireless testbed hosted at Winlab, Rutgers University [16]. Since the ORBIT users are competing to reserve their experiment time slots, the allowance for us is bounded to a few hours for a day. To handle the testbed easily within a limited experimental time slot, we only utilize 11x11 subset of nodes The other testbed is NORBIT, non-uniformly installed wireless testbed at NICTA. The NORBIT is composed with 40 static nodes spread over 3 floors of NICTA building in Sydney.

average delay of status message relay (msec)

N1-Orig N10-Orig

N1-Apprx N10-Apprx

55 50 45 40 35 30 25 20 15 10


N1-Sim N10-Sim

N1-Emul N10-Emul

4.5 10.5 16.5 22.5 28.5 34.5 40.5 46.5 52.5 58.5 64.5 70.5 size of status message (Kbytes)

Figure 6: Summation of the Snapshot relaying and relaunch latency.
100 100

P (X>x)


P (X>x) Orig Apprx Sim Emul 101 102 inter contact time (sec) 103




Figure 5: Trajectories of mobile node movement over 1000 x 1000 field for 1000 sec from (a) original from Levy walk model, (b) grid-mapped, (c) simulation and (d) experiment.






Orig Apprx Sim Emul 101 102 contact duration (sec) 103




3. Contact & Inter-contact time distribution: The contact and inter-contact time distribution are the key parameters affecting to the performance of DTN and MANET applications [19]. We measure the contact and inter-contact time distribution for four cases above. For the case 4) Emul, we also conduct the SINR-based contact and inter-contat time distribution measurement. It is more realistic for the running application’s point of view.

Figure 7: The CDF of a) inter-contact time and b) contact time from 10 nodes Levy-model trace with spatial contact evaluations.

4.3 Verification Results
4.3.1 Mobility trajectories
Figure 5(a) to Figure 5(d) show the mobility trajectories for selected two nodes (only intended for the better graphical representation) from the Levy-walk model. By comparing Figure 5(a) to Figure 5(d), we can find the major perceptual differences in the shape of trajectories caused by the approximation step. Similar degree of perceptual distortion in trajectories from both Figure 5(c) and Figure 5(d) respectively is compared to Figure 5(b) and Figure 5(c). But the loss is not as much as high for the approximation step. We have conducted the same measurements for RWP (random waypoint)-model trace case, and they show the same tendency (α = 0 generates RWP trace [18]). It is noted that the average migration interval for each mobile node is measured about 50 sec given human mobility traces from Levy-walk model. For RWP trace, more diffusive than Levywalk trace, the average migration interval for each mobile node is measured around 18 sec.

Kbytes one is about double. It indicates that the relaying and launch latency is not highly sensitive to the size of Snapshot. Since the Snapshot is relayed via 1Gbit ethernet link, the latency is mainly due to the link propagation delay and launching/resuming a new nullApp. The maximum size of Snapshot is set to 70.5 Kbytes used in the experiments. It may not be enough to carry the whole internal status of an emulated application. For the mobile p2p applications, for instance, the cached data volumes may easily excess 70.5 Kbytes. However, relaying whole cached data is waste for the emulation experiments (see Section 3. If we encode the storage status into the bitmap and assume that the unit of transfer is a1420 bytes size packet, 70.5 Kbytes (in a bitmap) Snapshot can represent about 800 Mbytes (1420 × 8 × 70.5k) data [24].

4.3.3 Contact & Inter-contact time distribution: Spatial contact evaluation
Figure 7(a) and Figure 7(b) show the measurement of inter-contact and contact time distributions, respectively. The evaluation of contact is done by spatial contact threshold. Note that we have randomly chosen one mobility trace, conducted measurements via computer simulations, and then interpolated them to draw CDF for the Orig, Apprx and Sim cases. The measurement for Emul case is obtained from 15 rounds of experiments using nullApp at ORBIT. Similar to the movement trajectory cases, the major loss in inter-contact and contact time distribution happens in the approximation step. The Apprx, Sim and Emul cases all show similar distributions. It indicates that the delayed migrations and relocations (see Section 3) do not have much affect.

4.3.2 Snapshot relaying and launch latency
Figure 6 shows the summation of both latencies to relay the Snapshot and to launch new applications with respect to the volume of Snapshot. This measurement indicates that the latency increases as the volume of Snapshot increases. The latency increment for 70.5 Kbytes case compared to 4.5



Table 1: 5, 25, 50, 75 and 95 percentiles of intercontact (ICT) time depicted in Figure 7(a) and contact time (CT) depicted in Figure 7(b). ICT-percentiles 5 25 50 75 95 Orig 20.0 63.5 124.5 413.5 634.0 Apprx 3.25 17.5 49.0 196.5 608.0 Sim 3.25 18.0 49.5 205.5 645.0 Emul 5.0 17.0 50.0 207.0 646.0 CT-percentiles 5 25 50 75 95 Orig 14.5 40.5 111.5 284.0 394.5 Apprx 4.25 27.5 65.0 191.5 369.5 Sim 3.25 22.0 50.5 191.5 467.0 Emul 6.25 20.0 66.5 181.5 467.0
50 45 40 SINR (dB) 35 30 25 20 15 1 2 3 distance 4 5 ([i, j], [i+hops, j]) ([i, j], [i, j+hops]) ([i, j], [i+hops, j+hops])

P (X>x)


P (X>x) Sim Emul (Cr=30 dB) 101 102 inter contact time (sec) 103


10-2 100

10-2 100

Sim Emul (Cr=30 dB) 101 102 contact duration (sec) 103



Figure 9: The CDF of a) inter-contact time and b) contact time from 10 nodes Levy-model trace with SINR-based contact evaluations. Table 2: 5, 25, 50, 75 and 95 percentiles of intercontact time depicted in Figure 9(a) and contact time depicted in Figure 9(b). ICT-percentiles 5 25 50 75 95 Sim 3.25 18.0 49.5 205.5 645.0 Cr = 30dB 7.0 32.5 74.25 208.0 708.25 CT-percentiles 5 25 50 75 95 Sim 3.25 22.0 50.5 191.5 467.0 Cr = 30dB 6.0 15.25 33.75 58.5 181.25

Figure 8: The average link quality measurement in SINR between a pair of nodes in ORBIT. Table 1 summarizes the results by taking 5th, 25th, 50th (median), 75th and 95th percentiles of distributions. Mainly the loss is due to the over-generated short-term contacts and inter-contacts after the approximation of the original trace. For 5th percentile, the approximation shortens the intercontact time 4 times less and contact time 3 times less. For 50th and 75th percentiles, the differences are reduced to around 2 times less for both cases. For 95th percentile, the inter-contact and contact time differences respectively fall into 10% and 20% range.

4.3.4 Contact & Inter-contact time distribution: SINR-based contact evaluation
For real DTN and MANET applications, the evaluation of contact is done by comparing the received probing packet’s SINR value with predefined threshold Cr. If SINR is larger than Cr, the sender nullApp and receiver nullApp have a contact. To decide appropriate Cr in SINR, we measure the link quality in terms of SINR over all pairs of N hop (physical distance) in ORBIT. Figure 8 shows the link quality in SINR measured by nullApp. The horizontal axis represents the physical distance between two nodes on arbitrary links on the testbed. The measured SINR for the links, for example, [(1, 2), (1, 3)] and [(10, 9), (10, 10)] are dealt into same category as [(i, j), (i, j+hops)], wher hops equals to 1. The measurement results show that SINR decreases as the distance between two nodes increases. For both [(i, j), (i, j+hops)] and [(i, j), (i+hops, j)] cases, the measured average SINR drops in almost similar tendency as the distance increases. The measured average SINRs over [(i, j), (i+hops, j+hops)] links are always smaller than the one of both [(i, j), (i, j+hops)] and [(i, j), (i+hops, j)]. The reason is that the

distance between [(i, j), (i+hops, j+hops)] is always longer than for link [(i, j), (i+hops, j)] or [(i, j), (i+hops, j)] in the ORBIT. Thus, the received signal strength of probing packet for [(i, j), (i+hops, j+hops)] links is likely smaller than for links [(i, j), (i+hops, j)] or [(i, j), (i+hops, j)]. Figure 9(a) and Figure 9(b) depict the measurement of inter-contact time and contact time distributions, respectively. We have set Cr to 30 dB so that the two nullApps located within 3 hops apart can get a contact (see Figure 8). Note that this Cr configuration is also intended to separate the grid topology similar to spatial contact evaluation case that partitions 1000mx1000m territory with 250m contact range. As summarized in Table 2, the intended inter-contact time distribution from Sim is successfully regenerated in the experiments. For 75th and 95th percentiles, the difference between Sim and Emul falls into 10 % range. For 5th, 25th and 50th, the inter-cntact time of Emul case is about two times longer than Sim case. Unlike to the inter-contact distribution, Emul case achieves much less contact-duration compared to the Sim case all over the percentiles except 5th one. We have found that this shorter contact time duration is due to the link SINR variation. Even though the two nullApps spatially contacted, the measured SINR between them occasionally falls down less than Cr for short time period. This indeed increases the number of short-termed inter-contact time while reduces the number of long-termed contact time.

In this section, we introduce the case study to verify how the proposed emulation method combines with the real applications. Note that the results in this case study might be specific to the tested applications and not be generalized for the other types of applications.

20 m
avrage contact duration (sec)

10 9

avrage number of P2P segment transfer


22 20 18 16 14 12 10 8 6 4 2 real


1 meter

MC1 1 meter/sec

[1, 1]

[1, 20]

8 7 6 5 4 3 2 1




Figure 10: The scenario for evaluation of a) actual movement and b) emulation.

0 real EM1 EM2 EM3 EM4 EM5 EM6 EM7


avrage successful P2P transfer ratio (%) STDV 100 1 0.9 0.8 98 P(X>x) 0.7 0.6 0.5 0.4 94 0.3 0.2 92 0.1 50 real EM1 EM2 EM3 EM4 EM5 EM6 EM7 100


5.1 Mobile P2P Video Streaming: study setup
We have performed case study using MOVi [24] (Mobile Opportunistic Video-on-demand), a mobile p2p video streaming application that selectively utilizes downlink path (AP→STA) and p2p path (STA→STA) for data delivery. MOVi comprises of two logical components: a mobile client node called MOVi Client (MC) and a network of servers in the back-haul known collectively as MOVi Server (MS). MOVi Server maintains three key functions. It derives a connectivity map of link quality between MCs (i.e., the relative ‘location’ of MCs), schedules the direct transfer of content segments between pairs of MCs based on the map, and tracks the content delivery and caching status of all MCs within its domain. In contrast, MC maintains two key functions. It serves as a temporal cache to help content diffusion inside the MOVi network, and acts as a channel state monitor by periodically observing link quality to its neighboring MCs. MCs implement the former function at the user-level application running in general Linux environments while perform the latter function at the device driver level by modifying MadWiFi [1]. The application part of MC periodically updates the observed link quality to its neighbors. When the p2p transfer is scheduled by MS, MCs trigger iDLS [23] (inter-BSS directlink setup) to smoothly change their WiFi device’s operation mode to transfer data directly to the neighboring MC without help of AP. We conduct experiments that compares the behavior of MOVi under the real human-driven mobility with the one under the emulated mobility. We have customized MOVi to interact with EC. Specifically, we modified MOVi implementation [24] so that it can take a Snapshot and resume with relayed Snapshot. We install and launch MS (configured as AP) to one of the node and two MCs on two of nodes in ORBIT and hire two student volunteers at Winlab, Rutgers University who carry them and move along the predefined path over the ORBIT testbed at the speed of 1 meter/sec as depicted in Figure 10. Both departs at both ends of a row and move toward to the other ends and have a contact in the middle. Once they reach to the other end, the experiment finished. One MC has downloaded the contents completely and stored it at the local cache before the beginning of the experiment. Thus, MS can schedule p2p transfer as soon as they contact. Cr is set to 30 dB which is the same as the previous experiments in Section 4. The unit of transfer is a segment which is 200 number packets, and each packet size is 1400 bytes. We configure the MOVi specific parameters to restrict each p2p transfer can not be continued no more than 150 msec. If there is no data reception for last 200 msec, MCs request data transfer to MS. MCs broadcast probing messages at every 200 msec for the neighbor discovery. MCs










migration latency (msec)



Figure 11: The measurement from the case study a) average contact duration, b) average number of p2p segment transfer, c) average successful p2p transfer ratio and d) CDF of migration latency (average = 140msec and median = 102msec). regard neighbors as contacted neighbors if the link quality to them is more than Cr and they have sensed at least one time for last 500 msec. If there is no valid contacted neighbor, a segment transfered via the downlink path (AP→STA). We observe the behavior of MOVi and measure especially when and how many p2p transfers happen. We then regenerate the same scenario on the same route using the proposed emulator. We measure the same set of indicators with respect to the different granularity of emulation. Given the setup described above, the best granularity emulation, called EM 1, is achieved by moving MC over one-hop distance neighbors for example [1,1]→[1,2]→[1,3]→...→[1,20] at 1 sec. We have also prepared the lower granularity emulations EM N that migrates MC at every N -hop neighbors as [1,1]→[1,1+N ]→[1,1+2N ]→...→[1,20] at every N sec. We note that the following results are obtained from 20 rounds of experiments.

5.2 Mobile P2P Video Streaming: Measurement Results
Figure 11(a) depicts the average contact duration from both real mobility and emulation experiments. The contact duration is the time difference between the first and last p2p transfers. For the real mobility experiments, both MCs have contacts for 7 sec out of 20 sec of experiment time. For EM 1, the measured contact duration is less than 2 sec. The reason is due to too fast and frequent application migrations. As depicted in Figure 11(d), the migration latency takes 140 msec in average, and about 30% of migration take more than 140 msec delay mostly due to the non-restricted downlink segment transfer from AP. Since MC is moved to next waypoint at every 1 sec, the expected time to run MC is about 860 msec for each migration. From the measurement, we confirm that almost every neighbor discovery has failed in EM 1 case. For EM 2 case, the average contact duration is almost the same with real mobility case. However, the

number of segment transfered is 15% smaller than the real mobility case as it is shown in Figure 11(b). This is also caused by the migration latency. Since it is impossible to make a p2p transfer during the migration, the utilization of contact duration for data transfer is limited. The average contact duration is decreasing as the granularity decreases until EM 5. The interesting thing, however, is that the number of p2p data transfer increased for EM 3 and EM 4 cases. The reason is that both EM 3 and EM 4 enable MCs to do p2p transfers for the entire contact duration. For real mobility case, as seen from Figure 11(c), the p2p transfer suffers around 5% packet loss within a segment transfer which reduces the utilization of the contact duration. For EM 6 and EM 7 cases, we confirm that most contacts happen between relatively longdistanced pair of nodes (4 hopes, 6 hops and rarely 8 hops). The measurements report that those long distanced contacts suffer some packet losses during p2p transfer as depicted in Figure 11(c). For all emulations, the average successful p2p transfer ratio achieve more than 99% while it is around 94.7% and even highly varying in real mobility case. The major source of higher packet loss for real mobility case is due to the impact of link-retransmission. We have observed that some of packets are not recovered by the link-layer retransmission. Even though the link-layer retry secure the reliability, the delay produced makes the p2p transfer can not be finished within 150msec boundary so dropped at the p2p source. For emulation case, those impact due to the channel variation caused by mobility can not be regenerative because we discretize the mobility so all p2p transfer happen to be between two static nodes.

As a part of our future work, we are planning to emulate various mobility models and patterns over larger scale grid testbed configuration (20x20) with different types of applications. We will also design and evaluate more efficient approximation algorithm to reduce the gap between emulation and real-world environments.

This research was sponsored by GIST Technology Initiative. We appreciate Murium and Yuriy from WINLAB for helping us to do mobile experiments. We also thanks to anonymous reviewers for their valuable comments.

[1] [2] [3] [4]



This paper proposes a novel approach to emulate mobility of DTN and MANET applications over static-grid testbed. This method virtually emulates mobility by migrating applications along the waypoints of their actual movement trajectories. This approach allows realistic evaluations for the DTN and modern MANET applications, which requires transparent interactions to the underlying MAC/PHYlayers. The proposed method has evaluated through extensive experiments conducted over two different static-grid testbeds at Rutgers university (US) and National ICT Australia. This evaluation allows us to conclude that: • The proposed method maintains the tendency of intercontact time distribution from the input mobility trace for both spatial and SINR-based contact evaluations. The tendency of contact time distribution is hardly regenerative in the SINR-based contact evaluation (see Section 4.3.4). • The channel quality variation due to the device mobility can not be properly emulated by the proposed approach (see Section 5.2). • There is a tradeoff between the granularity of the mobility emulation and the realism of the obtained result. Higher the granularity produces more realistic results. However, emulations with too high granularity may disturb to operate tested applications due to frequent migrations (see Section 5.2).

MADWiFi. Website. OMF. Website. ORBIT. Website. B. Aruna et al. Enhancing interactive web application in hybrid networks. in Proc. ACM Mobicom, October 2008. [5] M. Bandholz, J. Riihij¨rvi, and P. M¨h¨nen. Unified layer-2 a a o triggers and application-aware motifications. In in Proc. ACM IWCMC, April 2006. [6] S. Diggave et al. Even one-dimensional mobility increases the capacity of wireless network. in IEEE Transaction of Information Theory, November 2005. [7] J. Eriksson, H. Balakrishnan, and S. Madden. Cabernet: Vehicular content delivery using wifi. in Proc. ACM Mobicom, October 2008. [8] K. Fall. A delay-tolerant network architecture for challenged internets. in Proc. ACM SIGCOMM, June 2003. [9] E. Hernandez et al. Ramon: rapid-mobility network emulator. in Proc. IEEE LCN, November 2002. [10] S. Hong et al. Routing performance analysis of human-driven delay tolerant networks using the truncated levy walk model. in Proc. ACM Workshop on MMNR, June 2008. [11] S. Jung et al. Bluetorrent: Cooperative content sharing for bluetooth users. in Proc. IEEE PerCom, March 2007. [12] K. Lee et al. First experience with cartorrent in a real vehicular ad hoc network testbed. in Proc. IEEE MOVE, May 2007. [13] L. McNamara, C. Mascolo, and L. Capra. Media sharing based on colocation prediction in urban transport. in Proc. ACM Mobicom, October 2008. [14] S. Mohapatra et al. DYNAMO: A cross-layer framework for end-to-end QoS and energy optimization in mobile handheld devices. in Jounal. IEEE SAC, May 2007. [15] J. Ott, D. Kutscher, and C. Dwertmann. Integrating DTN and MANET routing. in Proc. of ACM Challenged Networks, CHANTS, September 2006. [16] M. Ott et al. ORBIT testbed software architecture: Supporting experiments as a service. Feb. 2005. [17] K. Ramachandran, S. Kaul, S. Mathur, M. Gruteser, and I. Seskar. Ramon: rapid-mobility network emulator. in ACM MobiSys Demo, June 2005. [18] I. Rhee, M. Shin, S. Hong, K. Lee, and S. Chong. On the levy-walk nature of human mobility. in Proc. IEEE INFOCOM, May 2009. [19] J. Scott et al. Impact of human mobility on the design of opportunistic forwarding algorithms. in Proc. IEEE INFOCOM, April 2006. [20] M. Shin, S. Hong, and I. Rhee. DTN routing strategies using optimal search patterns. in Proc. of ACM Challenged Networks, CHANTS. [21] H. Soroush et al. DOME: A diverse outdoor mobile testbed. UMass Technical Report UM-CS-2009-23, University of Massachusetts Amherst, May 2009. [22] J. Su et al. Haggle: Seamless networking for mobile applications. in Proc. ACM Ubicomp, April 2007. [23] H. Yoon et al. idls: Inter-bss direct link setup in ieee 802.11 wlans. in Proc. IEEE ISCIT, October 2007. [24] H. Yoon, J. Kim, F. Tan, and R. Hsieh. On-demand video streaming in mobile opportunistic networks. in Proc. IEEE PerCom, March 2008. [25] X. Zhang et al. Study of a bus-based disruption tolerant network: Mobility modeling and impact on routing. in Proc. ACM Mobicom, September 2007.

Sign up to vote on this title
UsefulNot useful