is based on mobile ad-hoc networks (MANET), a network type lacking fixed ... tion costs of an application that runs on a wired network are radically different from ..... cation cost that the maintenance of the forwarding scheme implies, because ...
Core Services in a Middleware for Mobile Ad-hoc Networks Marco Avvenuti, Davide Pedroni, Alessio Vecchio email: m.avvenuti, d.pedroni, a.vecchio @ing.unipi.it Dip. di Ingegneria dell’Informazione, Universit`a di Pisa Via Diotisalvi 2, I-56126 Pisa, Italy
Abstract
Lookup service to allow applications to query peers in order to discover and locate content and services. Such services can greatly contribute to increase system performance and functionalities provided they are carefully designed to make a scarce use of communication. XXXCAMBIAREXXX In this paper, we discuss how logical mobility can increase system performance, e.g. reduce the overall cost of communication, and describe an algorithm for service discovery that reduces the probability of incurring in the hidden node or the exposed node problem [10].
1 Introduction The evolution of wireless communication and information technologies is pushing the tendency of computing to become pervasive, ubiquitous and mobile. In the near future, users will be able to access information while roaming and to interact with the surrounding environment through zero-configuration software. An emerging communication support for this scenario is based on mobile ad-hoc networks (MANET), a network type lacking fixed infrastructure. In these networks, using link-layer technologies such as IEEE 802.11b or Bluetooth, a multi-hop connectivity allows each host to reach hosts beyond the radio range through the use of routing provided by neighboring hosts. Thus, MANETs are able to provide impromptu communication in a highly mobile and changing environment. The highly dynamic nature of MANETs together with the scarceness of capabilities and resources of mobile devices give rise to challenging application design problems: As the environment changes, applications must be able to interact with previously unknown software and devices, and to adapt their behavior to available resources and runtime conditions. In this paper we focus on two services that, in our opinion, should be included in a middleware for a MANET setting in order to achieve application flexibility and adaptability. The core services are:
2 Logical mobility Logical mobility has been indicated as a powerful solution to the many issues of mobile computing [3]: Bandwidth saving, asynchronous interaction, and easy management of disconnections are just some of the many advantages attributed to this programming style. However, despite some years spent by researchers in looking for proof-of-concept applications and scenarios, few of the benefits attributed to logical mobility been thoroughly validated. We believe that the definition of migration patterns can foster the adoption of mobility-based programming. The same way design patterns describe simple, elegant, and reusable solutions to specific and recurring problems [4], migration patterns may illustrate simple and reusable strategies that can be used to face some specific problems through mobility. More in detail, a migration pattern should illustrate which components of an application should move, and where they should migrate to achieve a given goal. Obviously, the definition of an effective mobility strategy mainly depends on the model of the application and on the environment where the application is executed. For example, a peer-to-peer application where each node can communicate with all other nodes is intrinsically different from a client-server system where communication is always
Support to logical mobility that is the ability for an application to dynamically reconfigure itself by moving software components, such as code and/or objects, from a node to another. 1
mediated by a centralized entity. Analogously, communication costs of an application that runs on a wired network are radically different from those of an application that operates over a wireless network, leading to different mobility strategies. In the following we illustrate some migration patterns and validate experimentally the effectiveness of one of them. These patterns assume the following model for the application and the environment: Application The application is made of server and clients. The purpose of the application is general: clients need to communicate with the server and viceversa. Many existing application fit into this model: A messaging system and a distributed whiteboard are only two among the many applications that share the necessity of exchanging information in a similar way. Middleware The programming model is distributed object based. The middleware allows communication between objects living on different hosts. It also supports logical mobility by providing primitives to move code and objects from a host to another. Additional mechanisms ensure communication between mobile objects, allowing objects to remain reachable while on the move. Our previous work on MobileRMI, an extended version of Java RMI, fulfills these requirements [2]. Network The application operates on a completely ad-hoc network: all nodes move freely within a given bidimensional area, and communicate with each other exploiting the routing facility offered by neighbors. Each node hosts a client, and one of them also hosts the server. The server is the only logically mobile component and moves to achieve one of the following goals. More efficient communication The purpose of this migration strategy is to reduce the overall communication cost of the application. In a MANET the communication cost depends on the distance between the source and the destination node. As the number of hops increases communication becomes more expensive, both in terms of latency, since packets must be retransmitted several times, and bandwidth occupation, since the medium is shared by all nodes and retransmissions reduce the bandwidth available to the others. Assuming that the link-layer communication parameters are uniform in the whole network, we define as the cost of communication, in terms of hops, between node and node . The basic idea is that, since the cost of end-toend communication between two application components
depends on the position of the physical nodes, the application level communication can use more efficiently the underlying network layer by repositioning the server. Practically, the server periodically determines its position with respect to all other nodes, and migrates towards the node that is closer to the physical barycenter of the network. If the center of gravity changes due to the movement of hosts, the server migrates again. For example, let us consider a network that, at a given time, has the topology shown in Figure 1. All nodes can communicate with each other either directly (as nodes 1 and 2, 2 and 3, etc.) or indirectly (as nodes 1 and 7 that can communicate thanks to packet routing performed by nodes 2, 4 and 6, and so on). It is clear that communication from 1 to 7 is more expensive than from 1 to 4 ( versus ). Let us suppose that the system has no support for logical mobility and that the server is on node 1, a mobile host on the edge of the network. Communicating with the server has the following costs: , , ! , and " # . The overall communication cost is %$'&($) *,+ . In the presence of logical mobility, the server relocates itself on node 4, the nearest to the barycenter of the network. Communication cost for clients is: -% -% , . / # . The overall communication cost is $'&($ 10 . The effects of the reduction of overall communication costs are: 1. the application consumes a smaller fraction of the aggregate bandwidth of the network, since each communication is subject to a smaller number of hops; 2. communication latency decreases; 3. overall energy consumption becomes lower because of the smaller number of hops. We did not take into account costs associated with migration, that mainly depends on the footprint of the server. Since migration is usually expensive, a basic enhancement to the migration strategy makes the server move to another node only if that node remains the closest to the center of gravity for a given amount of time. Improved application availability A migration strategy similar to the previous one can be also used to improve the server availability. If the node that runs the server moves towards the borders of the network, communication becomes less reliable. By migrating towards the center, the server avoids to be isolated from the rest of the network and its availability increases. Migration can be triggered when crossing a given threshold: when the server distance from the center is greater than
1. Sends a message to the server; 2. Sleep for a time . 1
On receiving a message from a client, the server 2
5
3
4
1. Sends concurrently the received message to all other clients. 2. Waits for another message.
6
7
Figure 1. Example of a MANET a given radius, as the one containing a specified percentage of the hosts, migration occurs. Power management Mobile nodes suffer of limited autonomy since they are battery operated. The amount of traffic generated by a node is one of the causes that determine a node’s lifetime. The first migration pattern reduces energy consumption as a side effect of the increased efficiency in communication. In other cases, could be more important to take into account the energy consumption directly into the migration decision algorithm. A possible power-aware migration strategy is to move the server away from a host when its energy fall below a given threshold. This ensures 1. server availability even when the hosting node is going out of power; 2. fair energy consumption among all nodes.
2.1 Experimental validation To validate the migration patterns and assess the assumed benefits of mobility, an experimental evaluation is required. To this purpose we built a testbed that we used to compare the performances of a test application both when it is able to relocate itself and when it is completely static (from the logical point of view). 2.1.1 The Application The application under test is client-server and adopts the first migration pattern presented previously to improve its communication efficiency. Each client executes a cycle with the following two actions:
In our implementation, communication from clients to server and vice-versa is achieved through remote method invocation. The server exports a deliver() method that is invoked remotely by clients to pass a message to the serverside. In turn, each client exports a receive() method that is called by the server to ship a message to the clientside. Since remote method invocation is synchronous, and since message delivery to clients must occur concurrently, the server to carry out its task starts simultaneous method invocations towards all clients, except the one that initially sent the message. The server sample the position of all nodes every second, then if a node is the optimal one, i.e. the closest to the barycenter of the network, for more than 10 seconds, the server migrates to that node. 2.1.2 Experimental setup and Scenario Experiments have been carried out using a simulated experimental testbed. A network emulator takes care of introducing bandwidth limitation, delay, packet loss, disconnection as if hosts were actually moving and they were connected by a MANET protocol. We run our experiments by using the emulation and simulation facility of the NS/VINT network simulator. NS is fed with a description of the movement pattern of the MANET’s hosts, and with other configuration parameters such as transmission power, initial energy, type of antenna for a mobile node, routing protocol, etc. The experimental setup is summarized in Table 1. In [6], the authors present the same emulation testbed applied to the evaluation of the Coda [9] file-system when operating on ad-hoc networks. By using the emulator, they highlighted some weak points of the software system under test and improved its performance. The nodes’ movement scenario is manually generated and comprises four nodes that moves as follows. For seconds all nodes maintain their initial positions, then Node1 starts moving towards Node0, i.e. towards the barycenter of the network, with a speed of + . At time , Node0 starts moving towards the initial position of Node1. The same way, after a while, Node1, that is now in the middle, changes its position with Node2. The movement scenario ends with Node2 going towards the position
Radio Propagation Model Antenna Link Bandwidth Network Interface MAC Protocol Routing Protocol
Two Ray Ground Reflection Approximation Omni-Directional
Lucent WaveLAN IEEE 802.11 Dynamic Source Routing (DSR)
Table 1. Experimental setup.
Node3
Static Mobile
Mean Value 40.422 ms 36.932 ms
Standard Deviation 1.855 ms 2.252 ms
300 m
Table 2. Mean method invocation delay.
Node0
173 m
Node1
Node2
Figure 2. Initial host positions for the test experiment
of Node3 and vice-versa. Basically, in turn each external node exchanges its position with the central node. Each mobile node hosts a client, and Node0 also initially executes the server. Each client invokes the deliver() method of the server with a pause time of 4 seconds ( ), sending a message with size 50 Bytes. Clients also keep track of the time needed to complete the method invocation, i.e. the time needed to deliver the message to all other clients. To have a fine-grained resolution on this measure, the operating system of all physical machines (FreeBSD) has been customized with a timer resolution, instead of default . In the static case, the server never moves, i.e. it remains on Node0 for all the time (remember that Node0 after about 270 seconds from the experiment beginning reach the initial position of Node1, and remains there for the rest of the time). The total run time for the experiment is 1400 seconds. Figures 3 and 4 show the method invocation delay as a function of time for both the static and the mobile case. More in detail, each Figure shows the method invocation latency as seen by all application clients. In the static case, the client that has the mean lower delay is Client0. The reason is that communication between Client0 and the server is local since they are executed on the same mobile node and the server never migrates. All other clients exhibit greater delay values. When is near to + , the node that hosts both Client0 and the server becomes so distant from other nodes that communication becomes multi-hop (i.e. it changes from 1 hop to 2 hop). This increases the communi-
cation latency among application nodes. In Figure 3, this is shown by the step nearby ) 1 + . In the mobile case, the server migrates three times. The first at , the second at , and the last at , . In Figure 4, migrations can be identified as the three peak groups corresponding to migration times (there are also some spurious peaks). Until the first migration, the client with the lowest delay is Client0 since it is the one that is executed on the same host of the server. Then the server migrates to Node1, and as expected, the client with the lowest delay becomes Client1. Finally the server migrates other two times, on Node2 and Node3, and this explain the two regions where Client2 and Client3 perform better than the other clients. Also, it is important to notice that the mobile system is characterized by more symmetry than the static case: in the mobile system, there is always a client that communicates with the server locally while the other clients communicate with the server through 1 hop. In the static application, a client is on the the same node of the server, another client communicates through 1 hop, while the remaining two clients communicate with the server through 2 hops (the node in the center of gravity routes their packets). Since the testbed is partially real (the application and the middleware) and partially emulated it is necessary to repeat the experiment a given number of times in order to reduce the essentially non-deterministic behavior, when analyzed with fine-grained resolution, of general purpose computing systems [8]: all machines that execute application nodes are real PCs, so they are subject to many asynchronous events as interrupt generated by disks, etc. For this reason, the experiment has been repeated 20 times for the static and the mobile application.
500 client0s client1s client2s client3s
450 400
Method invocation delay
350 300 250 200 150 100 50 0 0
200
400
600
800
1000
1200
1400
Figure 3. Method invocation delay (in milliseconds) experienced by clients for the static case as a function of time (in seconds).
500 client0m client1m client2m client3m
450 400
Method invocation delay
350 300 250 200 150 100 50 0 0
200
400
600
800
1000
1200
1400
Figure 4. Method invocation delay (in milliseconds) experienced by clients for the mobile case as a function of time (in seconds).
Static Mobile
Application level 2.01169e+06 Bytes 2.07172e+06 Bytes
MAC level 9.44482e+06 Bytes 7.17234e+06 Bytes
Table 3. Traffic generated at the application and MAC layer by the system under test (mean values).
2.1.3 Results Table 2 shows the mean value and the standard deviation of method invocation latency for both cases. The mobile application exhibits a better behavior than the static one of about 8.6%. The slightly greater value for the standard deviation of the mobile case is probably due to the larger values of delay experienced during server migrations (the peaks). Table 3 shows the mean values of the traffic generated by the system under test at the application level and at the MAC level. The logically mobile system generates more traffic, at the application level, than the static system. Server migration and reference updating are responsible for this traffic overhead. Anyway, the impact of the logically mobile system on the underlying network is better than the one of the static application, as its traffic at the MAC level is lower of about 24%.
3 Lookup service Users roaming ad-hoc networks are likely to enter various intelligent environments, to have access to locationdependent services, and to join different communities. So a Core Service for Middleware for ad hoc network is a Service Discovery system. Differences between Service Discovery for traditional distributed system and MANETs, are important and relay in abstractions provided to applications and user, and to the system architecture. It is not possible to relay on a fixed centralized solution, because in a MANET neither the existence nor moreover the connectivity to a server can be granted. So a lookup service for MANET has to be based on the Peer-to-Peer paradigm, which fits well to the MANET routing model, in which every node of the network acts like a router. In this way the lookup service itself is a distributed system and there is the need to evaluate accurately its impact on network performance. In particular, our evaluation of network impact regards MAC layer of the ISO/OSI architecture, evidencing some characteristics of IEEE802.11 protocol and using metrics that fits the multi-hop communication model. number of hops the minimum number of forwarding needed to reach the destination node; we define
hop communications as communications between two nodes that are in radio range (in a multihop scenario a single point to point communication involves a number of adjacent communications equal the number of hops between nodes) contemporaneity of communications the probability to have one or more devices trying to transmit while another one is yet transmitting, or is starting to transmit. Our goal is to design a lookup service with good performance in terms of hop communications needed for a lookup to be committed and requiring a low amount of contemporaneity of communications As evidenced in [1], Peer-to-Peer architectures based on broadcast, introducing an high amount of contemporaneity of communications, tends to solicit the hidden node and the exposed node problems. These problems concern the collision avoidance mechanism of the IEEE 802.11 protocol, and may arise when two or more nodes, that are in a distance between one and two times the radio range, start transmitting simultaneously [10]. This could lead to a great number of collisions and cause a significant performance degradation. For this reason lookup services based on broadcasts, like Gnutella and others, don’t fit well in MANETs. We propose a solution based on the idea of build an overlay network, which has to be followed by lookups, that has peculiarity of corresponding to the physical node disposition, in order to have an efficient use of communication infrastructure. We argue that, other than be constrained to the bonds formerly described, there are other requirements that a lookup service for MANETs has to fulfill due to the high degree of dynamism of this scenario. We state that the performance evaluation of a lookup scheme in an ad hoc scenario has to consider not only the lookup speed, but also the communication cost that the maintenance of the forwarding scheme implies, because the number of nodes is limited and the conditions that require the participation of the maintenance system are very likely. Finally summarize the characteristics that a lookup service require to be well suited for a MANET environment. Peer-to-Peer organization No use of broadcast Scarce use of communication for lookup activity Scarce use of communication for configuration and maintenance activity Correspondence between overlay and physical network
1
15
0
14
1
13
2
12
3
11
4
10
0
1
2
3
15
14
5
4
12
13
6
7
11
10
9
8
5
6
9 8
7
(a) Ring
(b) Grid
Figure 5. Ring structure, logical 5(a), mapped in physical space 5(b)
3.1 The Protocol A protocol, that fulfills some but not all previous characteristics, is CHORD [11], so we designed a protocol based on its structure that is more MANET compliant because the overlay network is forced to be related to physical nodes disposition, in order to satisfy reconfigurations and lookup activities with good performances in terms of hop communications. Chord is based on consistent hashing............, each node is assigned an unique identifier (ID) chosen by hashing, for example, the node’s IP address. Nodes are organized in a virtual ring ordered by their IDs. Each node stores a portion of an index which associates resource names to their location, it stores index for resources whose hashed name is between its hashed ID and the one of its successor. Lookup operations are carried out by following the ring until the appropriate node is reached (i.e., the one that manages the portion of the index that contains the name of the resource to be found). The protocol requires that each node only knows the addresses of its successor and its predecessor. To accelerate lookups, each node can maintain additional routing information, consisting in the addresses of nodes whose distance is one half, one quarter, one eighth and so on in the identifier ring. These routing informations are collected in a finger table, and are used when forwarding lookup messages: Knowing the addresses of nodes, where is the number of nodes in the ring, the complexity of lookups re duces to . Moreover, to increase robustness to disconnections each nodes store informations about some other nodes following its successor collected in a so called successor list. This kind of protocol doesn’t use broadcasts and, because a lookup is forwarded at one node at time, it doesn’t introduce any kind of contemporaneity of communications.
Furthermore the presence of finger tables it is necessary only for performance increase, instead to let the protocol work, it is indispensable that a node keeps informations about only other two nodes, in such a way that the maintenance cost of the ring is very low. In [11], performance of Chord are evaluated on networks of about nodes. In a typical MANET, instead, the number of nodes is not bigger than one hundred, and a network number of about thirty nodes is very likely. Moreover in MANET the cost of the maintenance of the finger table is more demanding, because disconnections and joins of nodes are strongly expected. For these reasons we propose a protocol without finger tables, accepting the degradation of complexity to On the other hand, Chord is network oblivious: the physical distance between nodes and, consequently, the cost of communication is not considered. In order to make Chord network-aware, we designed a version of the protocol that strives to minimize the communication cost by making neighbors in the identifier ring be neighbors in the physical network. We modified the way node identifiers are generated. One node’s identifier is built by prefixing to the hashed node ID a number representing that node’s location. This number is determined dividing the physical space in a grid and assigning to each zone a proper zone identifier(ZI), see figure 5(b). Also the virtual ring can be considered divided into zones( see figure 5(a). Figure 5 shows the virtual ring (fig. 5(a) and how it is deformed, in the physical space in order to cross every zone of the grid (fig. 5(b), small crosses representing nodes in the physical space.
3.2 Communication cost Settled of not using the finger table due to its costs of maintenance, we claim that the protocol with location dependent node identifiers, makes better use of the underlining physical network,thus reducing the overall cost of communication. The disposition of ZI, in order to deform the ring to cross zones, implies that adjacent zones in the virtual ring are as well physically adjacent. Lookup operations are carried out forwarding messages between logically adjacent nodes. With the proposed way of choice for ZIs, two nodes can be logically adjacent only if they share the same physical zone or they are placed in adjacent zones. So, the cost of each communication, in terms of number of hops, is the average cost of communication of two nodes placed in adjacent zones. Zones can be dimensioned such a way that two nodes belonging of two adjacent zones are in radio range, in order to have the cost of communication of each lookup message to be 1 as number of hops. If zones are dimensioned to be bigger than that, their number decreases and the communi-
cation cost of number of hops needed for each search message is the average number of hops between nodes belonging to two adjacent zones. Using a standard hash function to assign the node identifiers we can consider the cost of each message int terms of number of hops to be the average number of hops in the network. Another positive effect of our protocol is noticed analyzing the operations exploited by a node for joining the ring. The joining node has to discover one node belonging to the ring to which ask its joining position. Determining the joining position imply a lookup for the joining node’s immediate successor, based on its ID. The number of request to be forwarded on the network depends on how logically far this successor node is from the discovered one. In standard Chord this logical distance is completely aleatory, while with our protocol it depends on the physical distance between these two nodes. On the rational hypothesis that the discovered node is near the joining one, the joining position of the latter will be logically near to the discovered node’s one; so the number communications for discovering the joining position will be reduced with our protocol This structure is robust to disconnection of nodes, that is a very frequent event, due to the presence of the successor list and the fact that reconfiguration of the ring is a local activity, and involving only few near nodes.
3.3 Conclusions In this part of the paper we presented problematics of lookup service in a MANET environment that are common to middleware in general [7] [5]. We put particular attention to networking problematics, proposing a protocol that doesn’t use broadcast and is efficient in terms of number of hops to exploit a lookup. This result has been obtained an overly network between nodes that is lightweight to maintain, and it linked to the physical disposition of nodes on the MANET. In future works we want to examine how this overlay network can be used to accomplish other Middleware service, The particular we are thinking to use it to forward event notification. The physical space in which nodes can be thought to be bi-dimensional, so it can be interesting to investigate alteration to our architecture to make also the We will also analyze the possibility to use other topologies for the overlay network that are bi-dimensional in such a way to better map the physical disposition.
4 Conclusion The mobility patterns described above are simple, especially because the only requirement for the application is to know the position of mobile nodes. This information can be provided by a global position system. More sophisticated patterns could use routing information: appropriate
APIs between the application and the transport layer could support the migration policy using the content of routing tables. This information is likely to be more accurate and can lead to more efficient communication.
References [1] A.Fox, S. Gribble, Y. Chetawe, E. Brewer, and P.Gauthier. The broadcast storm problem in a mobile ad hoc network . In In IEEE International symposium on Personal, Indoor and Mobile Radio Communications (PIMRC), September 1999. [2] M. Avvenuti and A. Vecchio. Embedding Remote Object Mobility in Java RMI. In Proceedings of the 8th IEEE Workshop on Future Trends of Distributed Computing Systems (FTDCS’01), Bologna, Italy, October 2001. IEEE Press. [3] A. Fuggetta, G. P. Picco, and G. Vigna. Understanding Code Mobility. IEEE Transactions on Software Engineering, 24(5):342–361, May 1998. [4] E. Gamma, R. Helm, R. Johnson, and J. Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, 1995. [5] A. L. M. G.P. Picco and G.-C. Roman. The Future of Software Engineering, invited contribution Software Engineering for Mobility: A Roadmap, pages 241–258. ACM Press, 2000. [6] Q. Ke, D. A. Maltz, and D. B. Johnson. Emulation of multihop wireless ad hoc networks. In Proceedings of the Seventh International Workshop on Mobile Multimedia Communications (MOMUC 2000), Tokyo, Japan, October 2000. IEEE Communications Society. [7] W. E. Licia Capra and C. Mascolo. Middleware for mobile computing. Technical report, Universty College of London, july 2001. [8] L. Rizzo. Dummynet: a simple approach to the evaluation of network protocols. Computer Communication Review, 27, January 1997. [9] M. Satyanarayanan, J. Kistler, P. Kumar, M. Okasaki, E. Siegel, and D. Steere. Coda: A Highly Available File System for a Distributed Workstation Environment. IEEE Transaction on Computers, pages 447–459, April 1990. [10] T. S. Shugong Xu. Does the IEEE 802.11 MAC Protocol Work Well in Multihop Wireless Ad Hoc Network? IEEE Communications Magazine, pages 130–137, June 2001. [11] I. Stoica, R. Morris, D. Liben-Nowell, D. Karger, M. F. Kaashoek, and F. Dabek. Chord: A Scalable Peer-to-peer Lookup Service for Internet Applications. In ACM SIGCOMM 2001, pages 149–160, August 2001.
