MobiREAL Simulator Evaluating MANET Applications in Real Environments

Transcription

1 MobiREAL Simulator Evaluating MANET Applications in Real Environments Kazuki Konishi, Kumiko Maeda, Kazuki Sato, Akiko Yamasaki, Hirozumi Yamaguchi, Keiichi Yasumoto, Teruo Higashino Graduate School of Information Science and Technology, Osaka University 1-3 Machikaneyamacho, Toyonaka, Osaka , Japan {k-konisi, k-maeda, kz-satou, a-yamasaki, h-yamagu, Graduate School of Information Science, Nara Institute of Science and Technology Abstract In this paper, we present a new methodology to model and simulate realistic mobility of nodes for accurately evaluating performance of MANET applications. We have designed and developed a network simulator called MobiREAL based on the proposed methodology. We adopt a probabilistic rule-based model to describe behavior of mobile nodes. The proposed model allows us to describe how mobile nodes change their destinations, routes and speeds/directions based on their positions, surroundings (obstacles and neighboring nodes), information obtained from applications, and so on. Our MobiREAL simulator can simulate any protocols and applications on mobile ad-hoc networks composed of mobile nodes with realistic movements. Through several case studies, we show the importance to simulate MANET applications in realistic environments, and the usefulness of MobiREAL for such a purpose. 1 Introduction Mobile Ad-hoc Networks (MANETs) are expected to be very useful and important infrastructure for achieving future ubiquitous society. Designing MANET protocols and applications is a very complicated task since it is hardly possible to build large-scale and realistic testbeds in real world for performance evaluation. Thus there are always demands for the testbeds which allow us to design, analyze, and validate the applications in simple and inexpensive ways. Nowadays network simulators are mainly used for such a purpose. Recently, in the MANET simulation, reality of simulation especially mobility models of mobile nodes, is considered to be a very important factor and several research groups have made efforts to reproduce realistic mobility of nodes [1 3]. In this paper, we present a new method to model and simulate (near) real movement and behavior of nodes in mobile ad hoc network simulation. In the proposed method, we adopt a rule-based model to describe movement/behavior patterns of mobile nodes. In our model, mobile nodes are classified into multiple groups depending on their behavior patterns. For each group of mobile nodes, a rule-based description is specified where dynamic and realistic behavior of nodes such as visiting favorite shops in shopping, avoiding congested routes and receiving/distributing publicity information through network systems can be specified. Then node objects are instantiated with the initial parameters according to a simulation scenario. Based on the proposed methodology, we have developed a network simulator called MobiREAL which is composed of two parts called MobiREAL behavior simulator and MobiREAL network simulator. The behavior simulator simulates mobile nodes behavior, and network simulator simulates data exchange among mobile nodes, obtaining the latest positions, speeds and directions of nodes from the behavior simulator. The network simulator has been developed by adding several dynamicity support to an existing network simulator GTNetS [4]. MobiREAL also has an animator which visualizes packet propagation, logical topology of MANETs, node positions/movements and so on. Through case studies, we show the effectiveness of our model as well as the performance metrics of MobiREAL simulator. This paper is organized as follows. Section 2 gives detailed investigation of related work as well as our motivation to this work, and our contribution compared with the existing work. Section 3 overviews the proposed technique for realistic MANET simulation, and Section 4 gives our framework to model realistic mobility of nodes. Section 5 describes the design and implementation of our MobiREAL simulator. Section 6 gives experimental results, and Section 7 concludes the paper. 1

2 2 Related Work We usually use simple mobility models such as the Random Way Point (RWP) model [5] without any obstacles, for simulating MANET protocols. This is because such simple mobility models can commonly be available in many simulators and also they can be used for traffic modeling and performance evaluation by specifying mobility metrics such as density and average speed. Several variants of RWP which enhanced the mobility model are proposed in Refs. [1, 6]. Recently, several research groups are trying to define more realistic mobility models from (1) the real trace of users [7 1], or from (2) theoretical insights [11 16]. Refs. [1 3] well categorize/summarize the existing approaches. In the first category, user behavior patterns were analyzed by collecting traces of users in a campus-wide wireness network [7,8], a metropolitan area wireless network [9], and the SIGCOMM21 conference place [1], respectively. They have found interesting characteristics in traffic patterns depending on time and locations. These research efforts aim at getting knowledge for capacity planning and AP arrangement on future large-scale mobile network infrastructure. In the second category, Ref. [11] introduces obstacles (i.e., buildings) and realistic pathways between them in a simulation space. Ref. [12] proposes a macroscopic mobility model for wireless metropolitan area networks, where a simulation space is divided into multiple zones with different attributes such as workplace, commercial, and recreation zones. Also, each mobile node has an attribute of resident, worker, consumer or student. Given trips with destinations for user nodes, an existing urban transportation planning technique is used to estimate the user density of each zone. Ref. [13] presents WWP (Weighted Way Point) model. WWP model defines a set of crowded regions such as cafeteria and buildings at a university. Given a distribution of pause times of nodes for each region, it uses a Markov model to model nodes movement between these regions. For vehicular ad hoc networks, Ref. [14] proposes a technique to reproduce realistic mobility of vehicles in ns-2. Group-based mobility models also capture some aspects of realistic movement. Ref. [15] proposes a group-based mobility model based on social networks of each individual user. Also, Ref. [16] proposes several group-based mobility models. Although these methods can reproduce rather realistic mobility of user nodes, they aim mainly at estimating the node density and/or delivery ratio of packets at a specified zone and time. Among these existing research efforts, our goal is to achieve performance evaluation of higher layer and large-scale MANET protocols or applications under (near) real environments and (near) real movement of pedestrians. Trace-based mobility models [7 1] would not be suitable for the purpose, since they are mainly used for specific design of infrastructure or applications and it will not be easy to apply the best pattern obtained for one target system to other systems or applications. On the other hand, macroscopic mobility like Refs. [12, 13] is useful for reproducing realistic mobility of nodes. However, they do not consider microscopic behavior, i.e. how each node changes its behavior dynamically, depending on its surroundings, information obtained from network systems, time and so on. In our proposed framework, we model behavior of a node by a set of executable rules where the behavior is affected by the surroundings of the node, network systems and so on. With the rule-based model, (1) we can specify a simulation scenario with node generation/disappearance rates at each point as well as a set of initial destinations of nodes and so on, from macroscopic point of view, and (2) realistic movement/behavior can be reproduced for each mobile node. Another important contribution is that we provide a simulator called MobiREAL based on the framework. MobiREAL simulator is a very powerful simulator. Simulation of physical, MAC and transport layers in MobiREAL relies on an enhanced version of GTNetS (Georgia Tech. Network Simulator) [4]. We have developed a behavior simulator based on the proposed framework, which co-works with the network simulator. They together simulate the target network system as well as the behavior of users (nodes) which use the network system. The animator is the most powerful part of MobiREAL simulator components that can elegantly visualize packet propagation, logical topology of MANETs, node types and obstacles. 3 MobiREAL Simulator Overview Fig. 1 shows the architecture of MobiREAL simulator. MobiREAL simulator is composed of two parts called MobiREAL behavior simulator and MobiREAL network simulator. We have extended the network simulator GTNetS [4] developed in Georgia Institute of Technology where dynamic node generation and deletion are supported and node positions, speeds and directions can be updated from the behavior simulator. For simulation of network and MAC layer protocols, our MobiREAL network simulator relies on GTNetS where DSR, AODV and NVR (wireless form of Nix-Vector routing) are supported in the network layer and the standard IEEE82.11 DCF (CSMA/CA) with RTS/CTS is supported in the MAC layer. We have enhanced the signal propagation model in the original GTNetS so that obstacles are taken into account. It has a similar propagation model to Ref. [11] where ground reflection is considered as zero propagation and line-of-sight is considered. For our MobiREAL behavior simulator, each simulator user must give (i) a simulation field model, (ii) a set of behavior models of mobile nodes and (iii) a simulation scenario for generating mobile node objects. These are translated into the corresponding C++ 2

3 MANET Applications Behavior Simulator Animator Network Simulator Figure 1. Architecture of MobiREAL Simulator. Node A CPE model α Node B CPE model α Node C CPE model β Simulation Scenario Simulation Field AO P,V,AI Output from Application (AO) Simulation Manager Class Simulation Manager Class Behavior SImulator User Input to Application (AI) Position (P) of nodes Velocity (V) of nodes P,V, AO AI Node A Application Protocols Node B Application Protocols Node C Application Protocols Simulation Field Link Network Simulator Figure 2. MobiREAL simulator overview. classes using pre-defined library functions. For MobiREAL network simulator, the simulator user must also give C++ simulator codes of network applications and user-specific protocols used in the simulation. The behavior and network simulators are two independent programs that periodically exchange necessary data through a TCP channel. When they are initialized, they hold the simulation field and node objects independently. The behavior simulator calculates the latest positions, directions and speeds of nodes, and send them to the network simulator. Exchanging messages among nodes are also sent to the network simulator. The node objects in the network simulator hold their positions, directions and speeds. The network simulator conducts network simulation and packet exchange among those node objects is simulated based on the mobile nodes signal propagation model. Data exchanges between the users (nodes) and the network system (application) are also Data exchange between the behavior simulator and network simulator is periodically carried out. 4 Our Mobility Model In this section, we present our framework for describing real movement of nodes. 4.1 Simulation Field Simulation fields are modeled as follows. Polygons are used to represent buildings, parks and so on. Circles are approximated by polygons with many points. Each polygon has an attribute that indicates whether the region is accessible or not and whether 3

4 A B C D F E G H I K L J M N O Q Figure 3. Modeling simulation field. signal penetrates the boundary or not. If it is accessible, it may have some points on its boundary to represent entrances of the region. The rest of the simulation field is regarded as free space such as a street. However, this structure obviously makes the route calculation process of mobile nodes complex. Therefore, we allow to specify a set of points on streets or intersections and connects them to represent road structures (see Fig. 3). 4.2 Mobile Node Behavior in CPE Model Our policy to specify the behavior of nodes (mainly pedestrians in city sections with hand-held wireless devices) is following. (i) We first classify the types of mobile nodes by their behavior. (ii) Then for each type of mobile nodes, we specify their behavior in CPE (Condition-Probability-Event) model introduced later. Each CPE description corresponds to a class of mobile node objects that have similar behavior. Thus, the destination and route of each mobile node object, which moves based on a CPE description, are represented as variables in the CPE description, and their concrete values are assigned when the object is instantiated in a simulation scenario. (iii) Finally, we describe a simulation scenario that instantiates the objects (mobile node objects) with specifying their initial positions, destinations and so on. Here, the key point to model the behavior of mobile nodes simply and with high fidelity is how we can extract the factors that actually affect the behavior of people. In general, nodes visit places according to their roughly scheduled plans. They usually choose shortest paths to the first destinations, estimating time to reach there. Then these plans are dynamically changed or updated due to time, mind (mental states), newly obtained information from their devices or their surroundings. Some examples of such information are, (i) shop information recommended by other users through MANETs, and (ii) road congestion known by their sight. From the observation above, we introduce a Condition-Probability-Event model (CPE model) to describe the behavior of mobile nodes. We present our CPE modeling of pedestrian behavior in city sections in Fig. 4. The CPE model consists of a list of rules, and internal and external variables. The external variables can be accessed (and updated) from the outside of the CPE model, and they include simulation clock T, surroundings information E of the node, output data AO from the network system to the node, input data AI of the node to the network system, current position P and velocity vector V of the node. Each rule is a tuple of a condition, probability and action. Logical formula using the variables can be specified as a condition, and a value [,1] or a probability function can be specified as a probability. As an action, a set of substitution statements which update values of the variables is specified. The model works as follows. The simulation clock T is increased automatically from the outside of the CPE model, and for each increment, an executable rule is searched from the top of the list, and a rule that satisfies its condition and probability is selected to be executed. This search ends if it executes a rule, otherwise reaches the bottom of the list. In Fig. 4, an internal variable dst is a structure which represents a destination and has the following members; p (destination point), r (a sequence of points (route) to reach the destination point p), t (estimated arrival time) and s (stay time at the destination (pause time)). Dlist keeps a list of dst s which will be visited later. Functions in the rules are pre-defined or user-defined and we omit the details. In Rule E1, the value of logical formula crowded becomes true if the node finds crowded region ahead. Then the rule may be selected depending on the probability. In this rule, the probability function, which depends on simulation time, returns a probability value so that the rule can be selected every 5 minutes on average, with maximum 3 minutes variations (these variations follow a normal distribution). Therefore, once the node executes E1, this rule is not selected again until 5 minutes passes on average. This prevents too much (unnecessary) frequent execution of the same rule. If the rule is selected, dst.r, the route to the destination dst.p, is re-calculated by detour path to detour the region. If E1 is not selected, then E2 is checked. The value of the condition of E2 becomes true if the node recognizes that it cannot arrive at the destination until the estimated arrival time dst.t but may be able to arrive in time with a higher speed. In this case, it changes the velocity vector V appropriately. We note that, the vector calculation functions slow, norm and f ast in this example calculate the velocity to the nearest point in route dst.r from P. For example, in Fig. 3, if a node sets point E to dst.p (destination) and if it resides on the street between 4

5 node [CPE Description] Condition Prob. Action E1 crowded(p,v,e) norm dist(5.min,±3.min) dst.r=detour path(p,e,dst.p); V=norm(P,V,E,dst); front region is crowded detour crowded region E2 late(p,v,t,dst) 1. V=fast(P,V,E,dst); in time if hurries up speed up E3 miss(p,v,t,dst).2 V=fast(P,V,E,dst); dst.t+=1min; not in time even if hurries up add 1 minutes to expected arrive time and speed up E4 miss(p,v,t,dst) 1. dst=pop(dlist); dst.r=shortest path(p,dst.p); V=norm(P,V,E,dst); not in time even if hurries up give up going to the current destination and go to the next destination E5 receive from net(ao,new dest).5 put(new dest,dlist); V=norm(P,V,E,dst); acquiring information from the system add a destination obtained from the system to a destination list E6 staying overstaying reach(p,dst.p) 1. sst=t; staying=true; V=; arrived at destination record arrival time and set staying true E7 staying (T sst) dst.s.8 staying=false; dst=pop(dlist); dst.r=shortest path(p,dst.p); V=norm(P,V,E,dst); expected staying time has passed go to the next destination E8 staying (T sst) dst.s 1. staying=false; overstaying=true; dst.s+=rand(5*min, 1*MIN); expected staying time has passed extend staying time E9 overstaying (T sst) dst.s 1. send to net(ai,dst.p); overstaying=false; dst=pop(dlist); dst.r=shortest path(p,dst.p); V=norm(P,V,E,dst); expected staying time has passed during overstaying input the present destination to the system and go to the next destination [Internal Variables] dst.p = J dst.r = {H, I, J} dst.t = 3:1 dst.s = 3 min Dlist = {dst2, dst3,...} staying, overstaying = false sst = AO (from network), T (simulation clock), E (surroundings of node) P (position), V (velocity vector), AI (to network) Figure 4. CPE Modeling of Pedestrian Behavior in City Section G and H, dst.r keeps the route {H,I,K,C,D,E} (this is calculated by function shortest path in some rules). In this case, the vector calculation function uses the current position P of the node and the nearest point H in dst.r to calculate vector V. We also note that people sometimes walk zig-zag to avoid others approaching, or to avoid local small obstacles. By such collision avoidance among neighboring persons, velocity vectors may deviate temporally, and after a while it is regulated. By realizing such location deviation, we present some library functions that can be used in the velocity vector calculation functions. The function for waiting a signal to change to green can be also described. We have other rules up to E9 in Fig. 4. For example, rules E5 and E9 represent the behavior to use the network system. Here we have assumed that the network system is implemented on each node s terminal with a short range wireless device such as IEEE82.11, and these terminals communicate with each other in an ad hoc manner to exchange the stored information such as recommended shops, ads and so on. Rule E5 represents that if the node receives information (e.g. recommended shop information nearby) from its terminal and if the node is interested in the point (probability is.5), then it adds the point to its list Dlist of destinations. Explanations of other rules are described in Fig Simulation Scenario For each type of mobile nodes, a CPE model is specified. In the simulation scenario, we have to give those models the initial values of external variables P (position) and V (vector) and internal variables (e.g. a set Dlist of destination) to instantiate objects (entities) of the model. In the scenario, how these nodes are generated is specified. Fig. 5 shows an example scenario. In this scenario, in the upper and lower parts, objects of customer and worker are generated from the corresponding CPE models, respectively. In the scenario, P, V, and Dlist are determined with some randomized 5

6 //customer V = RandomV(1.,1.8); if( rand() <=.3 ) P=A; else P=Q; if(rand()<=.5){ tdst.p=e; tdst.t=t+req_time(p,e); tdst.s=3min; } else{ tdst.p=j; tdst.t=t+req_time(p,j); tdst.s=3min; } add(dlist,tdst); tdst.t=tdst.t+3min+req_time(dst.p,p); tdst.p=p; tdst.s=; add(dlist,tdst); if( norm_dist(15sec,1sec) ) customer.gen(v,p,dlist); //worker V = RandomV(1.5,2.); P = F; tdst.p=m; tdst.t=t+req_time(p,m); tdst.s=; add(dlist,tdst); if( norm_dist(8sec,1sec) ) worker.gen(v,p,dlist); Figure 5. Simulation scenario factors. The scenario can be specified using a pseudo code (actually it is a C++ code in MobiREAL). 5 MobiREAL Simulator Design In this section, we state design and development of MobiREAL. Due to space limitation, we omit detailed implementation aspects. Instead, we just address essential part of design and implementation in this section. Since the main framework of MobiREAL behavior simulator has been already explained in the previous section, here, we focus on the design and implementation of MobiREAL network simulator and animator. 5.1 MobiREAL Network Simulator As described earlier, we have modified GTNetS simulator so that it can efficiently cooperate with the MobiREAL behavior simulator. Hereafter, we describe the essence of this modification. The key features for the cooperation between the behavior simulator part and the network simulator part are (i) runtime generation and deletion of nodes, and (ii) update of node positions, speeds and directions. Runtime Generation and Deletion of Nodes GTNetS and many other simulators are originally designed for the simulation of wired networks where movement of nodes is bounded by boundaries, or node moving through a boundary appears from the boundary of the other side. This means that the number of nodes is known at the initialization phase of the simulator. On the other hand, our mobility of nodes requires dynamic generation and deletion of nodes, since our simulation scenarios can specify various ways of node generation and node deletion, for example, nodes which have finished their objectives disappear. GTNetS uses array-based data structure to manage node objects. In our MobiREAL network simulator, we have modified code segments related to this structure so that hash-based data structure is used to accept dynamic number of nodes. This modification can be applied to other simulators which have similar data structures. 6

7 Figure 6. MobiREAL animator snapshot. Position, Speed and Direction Update of Nodes Usually, wireless network simulators including GTNetS have a mobility class, in which behavior of mobile nodes is described. We have enhanced the mobility class of GTNetS so that the network simulator can replace the speeds and directions of nodes with the latest ones received from the behavior simulator. Once the network simulator receives this information, it updates the positions of nodes with this information until it receives new information from the behavior simulator. Note that there may be some errors of positions between the behavior simulator and the network simulator, since the network simulator receives the real speed and direction of each node only periodically (e.g., once per second). The shorter this period is, the positions of nodes in the network become more precise. However, communication overhead between two simulator components may increase. We will later evaluate the relationship among the update period, execution time of simulation and precision of simulation results. 5.2 MobiREAL Animator Visualization of simulation results is one of the most important facilities for network simulators. In particular, visualizing mobility of nodes is mandatory to convince simulator users that the realistic behavior of mobile nodes is achieved, for example, by observing how the information diffusion affects the destinations of mobile nodes. Our MobiREAL animator provides powerful and smooth visualization functionalities (Fig. 6). It works on the Microsoft Windows platforms, and has been developed using DirectX 9. As shown in Fig. 6, the MobiREAL animator gives bird s-eye view of the simulation field. Each mobile node is represented as a small circle, and a semi-transparent concentric circle represents its radio range. Packet transmission is animated by concentrically growing circles with colors. Also, obstacles are drawn as polygons in the background image. One of the features of the MobiREAL animator is that it allows us to select the layers to be displayed to make the visualization more comprehensive. In addition, the current version of the animator has the following functions: (1) any node IDs and colors can be assigned to specific nodes in each application (for example, we can change the color of only the nodes which obtain some specific information from the application); (2) different colors can be assigned links that are actually used in the network layer and overlay links with packet transmission in the application layer, respectively; (3) any color (including invisible color) can be assigned to all the potential links between two nodes (in the data link layer). In the MobiREAL web page [17] the graphical demos and snapshots are provided. 6 Experimental Results In order to validate the efficiency of our framework, we present performance evaluation of two typical MANET applications using MobiREAL. For the evaluation, we have modeled a real 5m 5m region including buildings and pedestrians with 7

8 (a) scenario A (north-south) (b) scenario B (east-west) Figure 7. Snapshots of two simulation scenarios for the end-to-end communication example. typical behavior patterns in downtown Osaka city. Then we present the results of performance evaluation of MobiREAL simulator such as execution time of simulations. 6.1 End-to-End Real-time Communication on MANET As the first example, we consider end-to-end real-time communication on MANETs. We consider the following situation. In this application, we focus on the performance of the routing protocol. We will show that the performance of the routing protocol such as end-to-end delay and the number of route breaks, are largely affected by the locations of end users. This is because in our target field of downtown Osaka, we have a big landmark (the central station) in the north area. We also have several big buildings in the south area and big streets connecting the north and south areas. Since we have set the destinations of the pedestrians according to the sizes of the landmarks in the simulation scenarios, several major convective flows of mobile nodes were formed from north to south and vice versa (this is a real situation in downtown Osaka). Obviously, if an end-to-end path for packet transmission is established from north to south (or vice versa), the path follows pedestrian flows on a street and is expected to be more stable than that established in east and west direction. According to this observation, we have prepared two scenarios A and B. These scenarios are different only in the locations of end users (application users) who do not move during the simulation. In scenario A, two end users are in the north and south areas, respectively, while in scenario B two end users are in the east and west areas, respectively. There are several big streets between the two users in scenario B. In both scenarios, the physical distances between the application users are the same. Snapshots generated by our animator for the both scenarios are shown in Fig.7. We have used two types of mobile nodes (shopping customers and workers). Usually, workers move between landmarks (buildings and stations). For the shopping customers, we have set major landmarks as their destinations. The ratios of the workers and the shopping customers to the whole mobile nodes are.8 and.2, respectively. The simulation time was 72 seconds. The communication was done by UDP from time 24 sec to time 72 sec. The initial speed of mobile nodes is 2 m/s, and the average density of the nodes is.48 person/m 2. DSR is used as the routing protocol, and after the connection is established, 1 kbps traffic is generated interactively between the two users to simulate interactive real-time communication. We have used IEEE DCF (CSMA/CA with RTS/CTS option). The radio range is 1 meters. Experimental Results Fig. 8 shows the simulation results. Fig. 8(a) shows the end-to-end delay distribution (along with accumulated distribution using the right-hand-side Y-axis). Here, the end-to-end-delay of a (received) packet is the time duration taken by the packet to reach the receiver after the sender sends the packet. In the figure, the packets which did not reach the receiver are not counted. Fig. 8(b) shows the packet arrival ratios. Obviously, in scenario B, the delay of packets are relatively longer than that in scenario A (since the accumulated ratio in scenario B grows slower than scenario A), and data packet arrival ratio is lower than that in scenario A. As we estimated, this is because they had a lot of route breaks and thus the corresponding repair procedures were executed. The results in Fig. 8(c) and Fig. 8(d) endorse our estimation. They show the accumulative number of route breaks (we also show the ratio of the number of local recoveries to the number of route breaks) and the accumulative number of control packets (RREQ and RERR packets) during the simulation time (from time 24 sec. to 72 sec.), respectively. We can clearly see that scenario B has much larger numbers of route breaks and control packets, compared with scenario A. 8

9 ratio to all the received packets scenario A scenario B scenario A accumulation scenario B accumulation accumulated ratio to all the received packets # trans. packets # rcv. packets ratio scenario A 9,6 8, scenario B 9,6 6, end-to-end delay (ms) (a) End-to-end delay distribution. number of route breaks route refresh ratio (scenario B) route refresh ratio (scenario A) route breaks (scenario B) route breaks (scenario A) route refresh ratio to all the route breaks (b) Data packet arrival ratio (ave.). number of control packets scenario A scenario B ERR of scenario B REQ of scenario B ERR of scenario A REQ of scenario A (c) Simulation time vs. the accumulative number of route breaks. The accumulative ratio of the number of local recoveries to the number of route breaks is also shown using the right-hand-side Y-axis (d) Simulation time vs. the accumulative number of control packets (Route REQuest (RREQ) and Route ERRor (RERR)). Figure 8. Experimental results of end-to-end communication example. (a) Base station A (b) Base station B Figure 9. Snapshots indicating the locations of base stations and mobile node distribution in information diffusion example. 9

10 A 2-A 3-A 1-B 2-B 3-B A 2-A 3-A 1-B 2-B 3-B accumulated # nodes received 15 1 accumulated # packets sended (a) Simulation time vs. information diffusion ratio A(R) 2-A(R) 3-A(R) 1-B(R) 2-B(R) 3-B(R) (b) Simulation time vs. the number of transmitted packets A(R) 2-A(R) 3-A(R) 1-B(R) 2-B(R) 3-B(R) accumulated # nodes received 15 1 accumulated # packets sended (c) Simulation time vs. information diffusion ratio. (Random cases) (d) Simulation time vs. the number of transmitted packets. (Random cases) Figure 1. Experimental results of information diffusion example. 6.2 Information Diffusion on MANET The second example is a simple location-aware application that diffuses the information of a specific area such as event notifications and shop commercials through MANET. If a mobile node executing this application receives information broadcasted by short-range base stations or neighboring nodes, it caches the information. After that, for every 15 seconds, it checks whether it should broadcast the cached information to its neighbors or not, according to the predefined probability function P rob(p, S) where P and S denote the positions of the node and base station, respectively. The mobile node discards the cached information after 6 seconds or once it broadcasts the information. Therefore, each node has at most 4 chances to broadcast messages. The probability function Prob is called diffusion policy hereafter. Of course we can consider many diffusion policies, and application developers may want to evaluate which policy is better to archive higher information diffusion ratio with smaller number of packets for efficient utilization of MANET resources. Also the information source may want to evaluate which base station is better to use. Therefore MobiREAL can be used to evaluate the information diffusion ratio and the number of control packets, under various realistic environments where the application is actually used. In each scenario, we have used one of the following three diffusion policies P rob i (i = 1, 2, 3). 1. P rob 1 (P, S) = d max d(p,s) d max where d(p, S) is Euclid distance between P and S and d max is the maximum Euclid distance of the field (in our simulation field d max = 5 2). This diffusion policy indicates that if the node is located closer to the base station, it broadcasts the information with higher probability. 2. P rob 2 (P, S) = d(p,s) d max. This is the opposite of the diffusion policy P rob 1. 1

11 .7.6 case 1-A (E) case 1-A case 1-A (R).5 density of the nodes Simulation time vs. node density near information goal. Figure 11. Experimental result of information diffusion example (node density). 3. P rob 3 (P, S) =.5 C(d(P, S) d const ). The value of C(t) is 1 only if the condition t is true, otherwise. We have set d const = 15m. This diffusion policy means that the node broadcasts the information with probability.5 if the distance d(p, S) is no longer than 15m. We have used either one of the two base stations A or B. The base station A is located near the center of the field, and the base station B is located in the south area. We have had 6 scenarios by the combinations of the diffusion policies and base stations. We name the scenario for the pair of a diffusion policy i and a base station x as scenario i-x. For each scenario i-x, we have also had the corresponding scenario named scenario i-x(r) that uses random mobility, in order to see the effectiveness of our mobility model. The simulation time is 6 seconds, and the application was executed between time 18sec and 6sec. Any other setting basically follows the first example. The animator snapshots that show the locations of the base stations and distribution of mobile nodes are shown in Fig. 9. Here a scenario is said to be effective if it achieves a good balance between the information diffusion ratio and the number of transmitted packets. We can expect that scenario 1-A or scenario 2-B is the most effective since, as we can see from Fig. 9, the areas around the base stations A and B are sparse and dense, respectively, and scenarios 1-A and 2-B are expected to diffuse the information in their sparse areas with high probability. Experimental Results Fig. 1 shows the simulation results. As we expected, Fig. 1(a) shows that scenario 1-A achieved the highest information diffusion ratio, however from Fig. 1(b), it also needs the largest number of packets. On the other hand, in scenario 2-B, the information diffusion ratio is high with less number of packets. Using MobiREAL, we can obtain the expected results, and also more detailed analysis between scenarios. It is interesting to see that in random scenarios in Fig. 1(c) and Fig. 1(d), the difference between scenarios is not so large. 6.3 Influence of Diffused Information Finally, in order to confirm the effectiveness of the main feature of our MobiREAL simulator, we have used the same settings and application as the previous experiment, but we have enhanced mobility models so that nodes set their destinations to the point where the diffused information indicates if they receive the information. This point is called information goal hereafter. For each original scenario i-x, we denote its enhanced scenario by scenario i-x(e). Experimental Results We have evaluated the node density in front of the information goal. The results for scenarios 1-A, 1-A(R) and 1-A(E) are shown in Fig. 11. As clearly seen from the figure, the node density of 1-A(E) is the highest. This is essential since in scenario 1-A(E), nodes which received the information change their current destinations to the information goal. The above experiments have shown the usefulness of MobiREAL simulator. 11

12 2 18 MobiREAL simulator MobiREAL behavior simulator 2 18 MobiREAL simulator execution time (sec.) MobiREAL behavior simulator execution time (sec.) number of nodes Figure 12. Running Time of MobiREAL Simulator interaction period running time (sec.) interaction time (sec.) interaction time ratio (%) Figure 13. Time for interaction between network and behavior simulators. 6.4 Performance Evaluation of MobiREAL Simulator Finally, we evaluate the performance of MobiREAL simulator. We have used a consumer PC (Intel Xeon CPU 3.6GHz and 2GB memory) to execute MobiREAL simulator. We have used the scenario of end-to-end communication example (example 1), but we have varied the number of nodes. Running Time Fig. 12 shows the actual running time of MobiREAL simulator with interaction between the behavior simulator and the network simulator (Y-axis of the left-hand side) and the actual running time of MobiREAL behavior simulator itself (Yaxis of the right-hand side) to execute the scenario, varying the number N of nodes. The running time of the behavior simulator increases linearly and is very short, while that of MobiREAL simulator increases more quickly. Usually network simulators take O(N 2 ) time to compute neighboring nodes and many complicated computation compared with the behavior simulator. Therefore the result in Fig. 12 is very natural, and the overhead of introducing our mobility model to the network simulation time is very small. From the viewpoint of scalability, MobiREAL simulator can execute scenarios with over 2, nodes. We believe that the capability to handle a few thousands of nodes, is enough for simulating large-scale MANET applications. Time for Interaction between Network and Behavior Simulators Fig. 13 shows the running time of MobiREAL simulator and time needed for interaction between the network and behavior simulators, varying the interaction period. We have used the scenario used in Section 6.1. As the period becomes longer, the errors of node positions between the behavior and network simulators become larger. From the result, we know that the interaction time is very short. Therefore, we can use small period like 1. or 2. for simulations with accurate positions of nodes. 7 Conclusion In this paper, we have proposed a new mobility model where near real movement of nodes can be easily reproduced. We have also developed a network simulator MobiREAL based on the proposed method. Until now, we have developed the main functions of the simulator. Several simulation scenarios we have used to evaluate example MANET applications and the corresponding animations are shown on MobiREAL WWW pages [17]. The appropriateness of the specified mobility models can be shown, to a certain extent, by tracking positions of (a part of) mobile nodes executing applications in the real world and by comparing the obtained results with the simulation results obtained 12

13 by our MobiREAL simulator. This is part of our ongoing work. References [1] Christian Bettstetter. Mobility modeling in wireless networks: Categorization, smooth movement, and border effects. ACM SIGMOBILE Mobile Computing and Communications Review, 5(3):55 67, July 21. [2] S. Basagni, Marco Conti, Silvia Giordano, and Ivan Stojmenovic, editors. Mobile Ad Hoc Networking in Section 14; Simulation and Modeling of Wireless, Mobile, and Ad Hoc Networks. IEEE Press, 24. [3] T. Camp, J. Boleng, and V. Davies. A survey of mobility models for ad hoc network research. Wireless Communications & Mobile Computing (WCMC): Special issue on Mobile Ad Hoc Networking: Research, Trends and Applications, pages , 22. [4] G. F. Riley. The Georgia Tech network simulator. In Proc. of the ACM SIGCOMM Workshop on Models, Methods and Tools for Reproducible Network Research, pages 5 12, 23. [5] J. Broch, D.A. Maltz, D.B. Johnson, Y.-C. Hu, and J. Jetcheva. A performance comparison of multi-hop wireless ad hoc network routing protocols. In Proc. of ACM/IEEE Mobicom, pages 85 97, [6] Jungkeun Yoon, Mingyan Liu, and Brian Noble. Sound mobility models. In Proc. of ACM/IEEE Mobicom, 23. [7] D. Kotz and K. Essien. Analysis of a campus-wide wireless network. In Proc. of ACM/IEEE Mobicom, pages , 22. [8] T. Henderson, D. Kotz, and I. Abyzov. The changing usage of a mature campus-wide wireless network. In Proc. of ACM/IEEE Mobicom, pages , 24. [9] D. Tang and M. Baker. Analysis of a metropolitan-area wireless network. Wireless Networks, pages 17 12, 22. [1] A. Balachandran, G. M. Voelker, P. Bahl, and P. V. Rangan. Characterizing user behavior and network performance in a public wireless lan. ACM SIGMETRICS Performance Evaluation Review, pages , 22. [11] A. Jardosh, E. M. Belding-Royer, K. C. Almeroth, and S. Suri. Towards realistic mobility models for mobile ad hoc networks. In Proc. of ACM/IEEE Mobicom, pages , 23. [12] M. Hollick, T. Krop, J. Schmitt, H.-P. Huth, and R. Steinmetz. Modeling mobility and workload for wireless metropolitan area networks. Computer Communications, pages , 24. [13] Wei jen Hsu, Kashyap Merchant, Haw wei Shu, Chih hsin Hsu, and Ahmed Helmy. Weighted waypoint mobility model and its impact on ad hoc networks. ACM SIGMOBILE Mobile Computing and Communications Review, pages pp , 25. [14] Amit Kumar Saha and David B. Johnson. Modeling mobility for vehicular ad-hoc networks. In Proc. of the 1st ACM Workshop on Vehicular Ad Hoc Networks (VANET 24), pages pp , 24. (poster paper). [15] M. Musolesi, S. Hailes, and C. Mascolo. An ad hoc mobility model founded on social network theory. In Proc. of ACM/IEEE MSWiM, pages 2 24, 24. [16] X. Hong, M. Gerla, G. Pei, and C. Chiang. A group mobility model for ad hoc wireless networks. In Proc. of ACM/IEEE MSWiM, pages 53 6, [17] MobiREAL web page. 13