Ad-hoc Storage Overlay System (ASOS): A Delay-Tolerant Approach in MANETs
←
→
Page content transcription
If your browser does not render page correctly, please read the page content below
Ad-hoc Storage Overlay System (ASOS): A Delay-Tolerant Approach in MANETs Guang Yang1 , Ling-Jyh Chen2 , Tony Sun1 , Biao Zhou1 and Mario Gerla1 1 Computer Science Department, UCLA {yangg, tonysun, zhb, gerla}@cs.ucla.edu 2 Institute of Information Science, Academia Sinica, Taiwan {cclljj}@iis.sinica.edu.tw Abstract— Mobile Ad-hoc NETworks (MANETs) quickly. On the other hand, MANETs often oper- are most useful in unprepared emergencies where crit- ate in an adverse environment and are far less reli- ical applications must be launched quickly. However, able than wired or infrastructure-based wireless net- they often operate in an adverse environment where works. Nodes in a MANET can crash, lose power, end-to-end connectivity is highly susceptible to disrup- be blocked, or move out of the communication range tion. Adjusting the motion of existing nodes or deploy- ing additional nodes can improve the connectivity un- of its neighbors, etc. It is very difficult to guarantee der some circumstances, but for scenarios where con- continuous end-to-end connectivity in MANETs. nectivity cannot be immediately improved, disruption Researchers have been looking at maintaining must be coped with properly. In this paper we propose connectivity in MANETs for years. For exam- the Ad-hoc Storage Overlay System (ASOS). ASOS is ple, routing protocols employ redundancy and lo- a self-organized overlay of storage-abundant nodes to cal repair to minimize the chance of path break- jointly provide distributed and reliable storage to data flows under disruption. ASOS is a Delay-Tolerant Net- age [11][17]. This alleviates the problem by find- working (DTN) approach that significantly improves ing an alternative path faster but only when such the applicability of MANETs in practice. a path exists. Others have looked at bridging dis- Index Terms—Mobile Ad-hoc Networks, Delay Tol- connected network partitions with additional nodes. erant Networking, Overlay, Storage [14] studied how to reconnect a partitioned network by deploying as few additional nodes as possible. [23][27] proposed using additional mobile nodes to I. I NTRODUCTION relay messages between network partitions. These Mobile Ad-hoc NETworks (MANETs) are a type methods, when applicable, can improve connectiv- of wireless networks that can be set up rapidly ity fast. However, there still exist situations where without pre-deployed infrastructure. They are ideal additional nodes cannot be deployed as needed. where timely deployment of network infrastructure We believe disruption should be properly toler- is impractical, e.g. on a military battlefield or in dis- ated if it is unavoidable. Simple methods could aster recovery. Vehicular networks are also amongst save the data at the source node or some centralized the recent advances in MANETs that provide flexible server. They would obviously suffer various scala- data communications as alternative to infrastructure- bility and robustness issues. A more sophisticated based services. MANETs are most useful in un- scheme should involve replication and distributed prepared situations where tasks must be fulfilled storage for better reliability and performance. In our This material is based upon work supported in part by the Na- proposed solution, named the Ad-hoc Storage Over- tional Science Foundation (NSF) under Grant No. 0520332, and lay System (ASOS), storage is handled by a peer-to- in part by the Office of Naval Research (ONR) under Grant No. N00014-01-C-0016. Any opinions, findings, and conclusions or peer (P2P) overlay of memory-abundant nodes that recommendations expressed in this material are those of the au- are part of the original MANET. These nodes, called thor(s) and do not necessarily reflect the views of NSF or ONR. ASOS peers, jointly provide reliable data storage un- 1-4244-0507-6/06/$20.00 ©2006 IEEE 296
der disruption. When an end-to-end flow is affected, B. Design Principles ASOS receives data from the source node, stores it ASOS aims to extend the end-to-end transport across the overlay, and delivers it to the original des- model with the following design principles: tination when connectivity is restored. ASOS is self- P RINCIPLE 1: safe and robust storage. Data must organized and complements the aforementioned ex- be stored in a distributed manner with redundancy, isting approaches. It is a Delay Tolerant Network- and survive small-scaled failures. ing (DTN) approach [4] specifically designed for P RINCIPLE 2: immediate availability. ASOS MANETs, and can be integrated as part of the DTN must solely rely on the collaboration of existing reference framework [4]. nodes and be available as soon as disruption occurs. The rest of the paper is organized as follows. Sec- P RINCIPLE 3: efficient storage and easy delivery. tion II illustrates application scenarios of ASOS and ASOS storage should be managed efficiently and fa- discusses its design principles. Section III proposes cilitate future data delivery. the ASOS design, focusing on overlay maintenance P RINCIPLE 4: friendly interface. ASOS should and service interfacing. Probabilistic data replication provide a friendly interface of its storage utility both is studied in Section IV under our mobility model. source and destination nodes. Section V presents simulation results to assess the efficacy and performance of ASOS. Related work is III. T HE ASOS A RCHITECTURE summarized in Section VI. Finally Section VII con- A. Initialization and Maintenance of ASOS cludes the paper. II. A PPLICATION S CENARIOS AND D ESIGN P RINCIPLES A. Application Scenarios ASOS is designed for Delay-Tolerant applications running in a heterogenous MANET environment. Most conventional applications such as file trans- fer are considered as delay tolerant; some multime- dia applications are also (partially) delay tolerant as illustrated shortly. Heterogeneity means although some nodes in the MANET may operate with limited Fig. 1. ASOS architecture. When the destination is discon- energy or storage, there exist powerful nodes with nected from the source (1), data is submitted to ASOS for stor- abundant resources, e.g. motor vehicles. age (1’). Stored data is delivered to the destination (2’) after it Assume a MANET is deployed for reconnais- is reconnected (2). sance in a large area. A number of mobile nodes, humans and vehicles, are equipped with video cam- 1) Selecting ASOS peers: As illustrated in Fig- eras. Distributed across the area, these nodes capture ure 1, ASOS is a self-organized P2P overlay of ex- useful data and send back to the control center. In the isting nodes; every node in the MANET could be an ideal case, all data is promptly received. In reality, ASOS peer. Practically, it is desirable to designate part of the data may not be delivered to the control only a set of powerful nodes with abundant storage center in time due to connectivity disruptions. The as ASOS peers. We assume these nodes are pre- control center can still reconstruct images from par- configured. Other regular nodes must understand the tially received data in real time at a reduced quality. ASOS interface to access the storage utility. ASOS will store the undeliverable data in a robust 2) Peer and file IDs: A number of P2P sys- way, and deliver it to the control center later to re- tems generate location-independent hash IDs for construct the complete images. In this way ASOS both peers and files; a file is stored at peers whose does not improve the connectivity instantly, but pro- IDs best match the file ID [21][24]. This method au- vides a mechanism to save data that will eventually tomatically spreads files uniformly across geograph- contribute to the usefulness of the application. ical locations, a desirable feature for large-scale file 297
sharing. This uniformity, however, is undesirable larger than the refresh interval of HELLO messages. in ASOS, of which the primary goal is to deliver Expiration of a timer means that HELLO messages a file1 to its original destination. We need an ID- have not been heard from the particular ASOS peer independent algorithm to select storage locations for recently, indicating the peer may have become un- data, which will be studied in detail later in this pa- reachable. The associated entry is then deleted from per. For now, we assume every node has a unique the lookup table. ID. Files can be uniquely identified by hashing from source/destination IDs and other information. B. ASOS Interface 3) Initialization and maintenance: ASOS is ini- 1) Advertising of ASOS peers: Regular nodes in tialized shortly after deployment. All ASOS peers a MANET must know the existence of nearby ASOS form a multicast group, of which the address is peers. Due to the broadcast nature of wireless me- known a priori by all peers. Discussion on alterna- dia, the HELLO messages exchanged between ASOS tive methods is beyond the scope of this paper. Each peers could also be used for advertising. By enabling ASOS peer multicasts periodic HELLO messages to the promiscuous mode, regular nodes could look initialize and maintain the overlay. HELLO messages at the HELLO messages to learn about the nearby are sent to all ASOS peers, so that every peer can ASOS peers and stored files. Overhead is a seri- hear from all other reachable peers and know which ous drawback of this scheme, in which HELLO mes- files are stored in ASOS and where they are. sages from all ASOS peers must be sent to all reg- ular nodes. Aggregation on HELLO messages could alleviate the problem, but then would intervene with ASOS maintenance. We decide to decouple the task of advertising from maintenance, and introduce a new type of ADVERTISE messages. Each ASOS peer periodically aggregates its knowledge of reachable peers and stored files, and broadcasts an ADVERTISE message to all nodes. Since regular nodes do not participate in ASOS Fig. 2. Format of a HELLO message. maintenance, fields such as remaining capacity and peer location are not included in ADVERTISE mes- Essential fields of a HELLO message is illustrated sages. More importantly, ADVERTISE messages in Figure 2. First, seqno is a peer-specific sequence only contain file IDs rather than the detailed loca- number incremented every time a new HELLO mes- tions of each file. This significantly reduces the size sage is sent. A new message with a higher se- of the message. To suppress excessive broadcasting, quence number supersedes previous messages from one node only forwards the first fresh ADVERTISE the same peer. Remaining capacity and peer location message it receives. This also guarantees that a reg- are used for data management in ASOS. Stored files ular node receives ADVERTISE messages from its are the meta data of the files, e.g. the file ID, start closest ASOS peer. offset, file size, etc. We will explain them shortly. 2) Disruption detection and data submission: To keep track of peers and files, each ASOS peer We design ASOS as a backup scheme when end-to- maintains a lookup table of reachable neighbors. end connectivity is disrupted. Disruption is usually Entries in the table contain similar fields as in the detectable at the routing layer. For example, popu- HELLO messages. Each entry corresponds to one lar ad-hoc routing protocols [11][17] use RERR mes- peer and is refreshed when a new HELLO message sages to report route errors. Receipt of an error mes- from that peer is heard. Each entry is also associ- sage is good indication of disruptions in connectiv- ated with an expiration timer that is reset when the ity. Note that many routing protocols perform local entry is refreshed. The initial value of the timer is repair before notifying the application. ASOS ac- 1 For simplicity, hereafter in this paper we assume that data in commodates such efforts and will only intervene af- ASOS is managed as files. ter local repair fails. 298
files for it. The push mode is applicable when an original destination node is seen by an ASOS peer, e.g. appearing in the peer’s routing table. C. Data Management 1) Probabilistic selection of storage locations: After the source node submits data to its ASOS agent, the agent becomes the first ASOS peer to hold a copy of the data. To increase storage reliability, data is also replicated to other ASOS peers. In- tuitively, it is desirable to store data near the des- Fig. 3. Two methods to switch an end-to-end flow to the ASOS mode: by the source node or an intermediate ASOS peer. tination. We assume that nodes in the MANET know their (relative) locations. If not available, geo- information can be substituted by other metrics such Upon disruption detection, there are two meth- as the hop count. ods to switch an end-to-end flow to the ASOS mode. First, the source node can initiate the switch- ing by contacting its ASOS agent (known from ADVERTISE messages). Alternatively, an ASOS peer on the path of the flow, once seeing an RERR message, can initiate the switching immediately. See Figure 3 for an illustration. We treat the entire data of an end-to-end flow as a file. Due to disruptions, transmission of the file may be divided into several chunks. Therefore, the start Fig. 5. Probabilistic replication of data. Node B has a lower offset in the file and the size of the chunk are critical but non-zero probability of holding a copy. Nodes C and D have comparable probabilities. None of them deterministically information in the local lookup table. See Figure 4 hold a copy. for an illustration. A naive way to replicate data is to greedily push the data towards its destination. This method has a drawback: replicas will be geographically close to each other and vulnerable to clustered failures. More sophisticated is the probabilistic replication across the overlay. The ASOS agent selects among its reachable peer neighbors K − 1 locations to repli- cate the data to, K being a configurable parame- Fig. 4. Distributed storage of a file in ASOS. The first 200 data ter. With the assumption that pairwise distances be- units of File 1 are delivered to the destination. The next 150 tween nodes can be measured, storage locations are units are stored at an earlier ASOS agent A. The current ASOS selected based on the following guidelines (also see agent is B with 50 units stored. Figure 5): i) A peer closer to the destination node should 3) Data retrieval from ASOS: In terms of which have a higher probability to be selected, party initializes the retrieval process, data can be ei- ii) A peer further away from other ASOS peers that ther pushed to the destination node by ASOS, or have been selected as storage locations should pulled by the destination node itself. The pull model have a higher probability to be selected, and is applicable when a destination node, by receiving iii) A peer less heavily loaded should have a higher ADVERTISE messages, learns that ASOS has stored probability to be selected. 299
The issue of probabilistic data replication will be studied in further detail in the next section. 2) Other data transfer between ASOS peers: In addition to the probabilistic data replication, an ASOS peer may also dynamically transfer stored data to another peer. This can happen when a peer is running short of power or storage space. A peer may replicate data when it detects that a former peer holding a replica has recently failed. A third situa- tion is when the design parameter K, the number of Fig. 6. The Virtual Track mobility model. copies of the data, needs to be increased. 3) Data deletion and replacement: ASOS sup- ports both implicit and explicit data deletion and B. ASOS Peer Deployment and Probabilistic Loca- replacement. In the explicit scheme, the original tion Selection under the VT Mobility Model source or destination deletes data from ASOS by messaging its ASOS agent, when the data is suc- All three types of nodes, i.e. static, individual and cessfully delivered or has lost its usefulness. The grouped, can be ASOS peers. Initially, each group source node ID, destination node ID, and file ID are contains a certain number of ASOS peers. These required to identify the file to be removed. The agent in-group peers respond fast when storage is needed. disseminates this message to all ASOS peers that Due to splitting, a group may temporarily have zero hold a copy of the data, which will then delete the ASOS peers. In this case regular nodes turn to ASOS data from their local storage. In the implicit scheme, peers in nearby groups, or to static/individual peers ASOS can accommodate storage scarcity with pri- within reach. oritized storage management, such as the Least Re- Under the VT model, it is difficult to predict fu- cently Used (LRU) and First-in-First-out (FIFO) al- ture connectivity or the distance between two nodes: gorithms. ASOS removes data deemed less impor- the number of possible paths grows exponentially as tant to make storage space for more valuable data. nodes traverse across switch stations. Our approach is to use the current positions and velocities of ASOS IV. P ROBABILISTIC DATA R EPLICATION peers to determine the replication locations. These values are disseminated in the latest HELLO mes- Probabilistic data replication in ASOS can be for- sages. We assume that the current position and ve- mulated as an optimization problem. Due to space locity of the destination node are also known. From limit we do not discuss the generic problem in this such information, the next switch station where an paper; please refer to [25] for more details. We now ASOS peer or the destination node will arrive can be turn to a specific mobility model for a concrete loca- determined. We use the distance between two switch tion selection algorithm. stations where two nodes will arrive, respectively, as A. Virtual Track Mobility Model the distance between these two nodes. The probabilistic location selection algorithm is The Virtual Track (VT) mobility model [28] tar- shown in Table I. The weight wp meets all three gets the MANET scenario where mobility of the guidelines proposed in the previous section. grouped nodes is constrained. It defines a set of “switch stations” and “tracks”. Grouped nodes can V. E VALUATION only move on the tracks. Nodes belonging to the same group have the same group velocity; each node A. Simulation Setup then has its own internal velocity with respect to the We have implemented ASOS as an application group. Groups may split and/or merge at a switch module in QualNet [18]. We select the UCLA cam- station. Other than grouped nodes, there are also pus map as the basis of our simulation scenario. static and individual nodes in the VT model. Figure Seven campus landmarks are identified as switch sta- 6 illustrates the concepts of the VT model. tions of the VT mobility model. A total of 30 nodes 300
a: ASOS agent z: original destination node P: set of reachable peers from a S: selected peers as storage locations, S ⊆ P K: number of data copies (assumed as pre-configured) STp : next switch station where p will arrive dp,q : distance between STp and STq cp : remaining capacity of peer p random(r1 , r2 ): uniform random number generator on [r1 , r2 ) begin S←Φ if (|P| < K) S←P else repeat for each p ∈ P do dmin ← min{dp,q |q ∈ S} wp ← (cp · dmin )/dp,z rp ← random(0, wp ) enddo S ← S ∪ {p|p ∈ P, rp = max{rq |q ∈ P}} Fig. 7. Screen snapshot of the simulation topology in QualNet. P ← P \ {p|p ∈ P, rp = max{rq |q ∈ P}} until (|S| = K − 1) endif end B. Delivery Ratio We first compare the instantaneous throughput in TABLE I non-ASOS and ASOS scenarios. Hereafter in this A LGORITHM OF PROBABILISTIC SELECTION OF paper, the non-ASOS scenario means data is al- REPLICATION LOCATIONS AMONG ASOS PEERS . ways delivered end-to-end, while the ASOS scenario means data is normally delivered end-to-end but will switch to ASOS when connectivity is disrupted. Figure 8 shows the instantaneous throughput mea- are deployed in the 1600 m × 1600 m square area: 5 sured every minute at the destination node. Ideally, static, 5 individual and 20 grouped. Mobility of indi- this throughput should be 67 Kbps, the aggregate vidual nodes follows the Random Way-Point (RWP) sending rate from all sources, for the first 10 minutes. model; grouped nodes are divided into 4 groups of Due to disruption however, throughput in the non- 5 nodes each. The screen snapshot from QualNet is ASOS scenario is consistently below the ideal value. shown in Figure 7. Nodes 1 to 5 are static, 6 to 10 ASOS does not instantly improve connectivity, but are individual, 11 to 30 are grouped. temporarily stores data and resumes delivery when Node 30 is the destination where all data traf- connectivity is restored. Clearly reflected in the fig- fic is directed. Five flows are set up from differ- ure, at the 8th minute the instantaneous throughput is ent source nodes, including one static, one individ- well above 67 Kbps. This includes both fresh data ual and three grouped nodes, none of which be- produced during the minute, and previously stored long to the same group with node 30. Each source data. After the 10th minute when all flows have generates a periodic constant-bit-rate (CBR) flow, at stopped, some data can still be delivered to the des- the rate of 80 Kbps, for 10 seconds every minute. tination, e.g. at the 11th and 17th minute. Figure Communication between nodes is IEEE 802.11b at 9 shows the cumulative amount of data delivered to 2 M bps, with an effective transmission range of ap- the destination. At the end of the simulation, ASOS proximately 280 m. Each simulation runs 20 min- is able to deliver about twice as much data as deliv- utes. Data traffic stops at the 10th minute; ASOS, if ered in the non-ASOS scenario. We have repeated enabled, has an additional 10 minutes to exploit node the simulation with different random seeds, seeing mobility and deliver data to the destination. Simula- the similar trend. tion parameters are summarized in Table II. Figure 10 shows how individual flows benefit 301
topology 1600m × 1600m ASOS 5 Non ASOS simulation time 20 min Ideal 30 Delivered Data (MBytes) total number of nodes number of static nodes 5 4 number of individual nodes 5 number of groups 4 3 number of nodes in each group 5 number of static nodes as ASOS peers 2 2 number of ind. nodes as ASOS peers 2 number of ASOS peers in each group 2 1 (excluding the group with node 30) number of replicas 3 0 2 4 6 8 10 12 14 16 18 20 interval between HELLO messages 10 sec interval between ADVERTISE messages 10 sec Time (min) expiration time of entries in lookup tables 30 sec Fig. 9. Cumulative amount of data delivered to the destination RWP model min speed 0 m/sec as time proceeds. RWP model max speed 10 m/sec VT model group min speed 0 m/sec VT model group max speed 10 m/sec proved the least. This is because static nodes lack VT model internal min speed 0 m/sec the ability to move and actively meet other nodes. VT model internal max speed 1 m/sec VT model max track length 750 m Individual nodes can move, but their territory can be VT model group split prob. 0.25 much larger than the grouped nodes. Grouped nodes nominal 802.11b data rate 2 M bps only move on the tracks; this effectively reduces approx. transmission range 280 m their territory and increases the chance of meeting number of flows 5 average per-flow data rate 13.33 Kbps each other. Therefore, we have observed the best de- start time of flows 0th min livery ratio improvement on grouped nodes. stop time of flows 10th min TABLE II C. Messaging Overhead S UMMARY OF SIMULATION PARAMETERS IN Q UAL N ET. Both HELLO and ADVERTISE messages in ASOS incur overhead, with HELLO messages being the heavier source as they are generally larger. In 120 Figure 11 we plot the cumulative distribution func- ASOS Non ASOS tion (CDF) of the size of HELLO messages. Over 100 Ideal 70% of the HELLO messages are less than 200 bytes Throughput (Kbps/sec) 80 long, with a maximum of 460 bytes only. In our sim- ulation, the control traffic is merely 1.6 Kbps, neg- 60 ligible compared to the data traffic. 40 20 D. Impact of ASOS Parameters Two key parameters in ASOS are the number of 0 2 4 6 8 10 12 14 16 18 20 ASOS peers deployed in the MANET, and the num- Time (min) ber of data copies, i.e. K. So far they have been Fig. 8. Instantaneous throughput measured at the destination fixed at 10 and 3, respectively. We now vary these node. numbers and study the impact on ASOS. First we vary the number of ASOS peers from 5 to 20; the results are shown in Figure 12. At the be- from ASOS: one from a static node (left), one from ginning, the delivery ratio increases with the number an individual node (center), and one from a grouped of ASOS peers. This is obvious since more ASOS node (right). The delivery ratio for the grouped node peers provide better availability. However, the in- has improved the most, while the static node has im- creasing delivery ratio quickly reaches the peak and 302
1.2 1.2 1.2 ASOS ASOS ASOS Non ASOS Non ASOS Non ASOS 1 Ideal 1 Ideal 1 Ideal Delivered Data (MBytes) Delivered Data (MBytes) Delivered Data (MBytes) 0.8 0.8 0.8 0.6 0.6 0.6 0.4 0.4 0.4 0.2 0.2 0.2 0 0 0 2 4 6 8 10 12 14 16 18 20 2 4 6 8 10 12 14 16 18 20 2 4 6 8 10 12 14 16 18 20 Time (min) Time (min) Time (min) Fig. 10. Delivery ratios of data generated in each minute. Three flows are shown, one from a static node (left), one from an individual node (center), one from a grouped node (right). 1 We then fix the number of ASOS peers at 10 and CDF vary the number of copies from 1 to 5, results shown 0.8 in Figure 13. At the beginning, the delivery ratio grows with the number of copies, but quickly hits the 0.6 plateau; further increasing the number has little im- CDF 0.4 pact on the delivery ratio. This is different from what we have observed in Figure 12. The reason is that 0.2 increasing the number of ASOS peers leads to more HELLO and ADVERTISE messages, while increas- 0 ing the number of data copies leads to larger HELLO 0 100 200 300 400 500 Size of HELLO messages (Bytes) and ADVERTISE messages. Since these messages are relatively small in our scenario, increase in the Fig. 11. Cumulative distribution function (CDF) of the size of HELLO messages. number of messages has larger impact on the traffic load than increase in the message size. 100 then starts to decline as more ASOS peers are added. Delivery Ratio This is mainly due to the fact that excessive ASOS 80 peers incur significantly more messaging overhead, Delivery Ratio (%) which negates the marginal gain brought by these 60 additional ASOS peers. 40 100 20 Delivery Ratio 80 0 Delivery Ratio (%) 1 2 3 4 5 60 Number of Copies Fig. 13. Delivery ratio vs. number of replicated data copies. 40 Deliver ratios are the overall values of all flows directed to the destination. 20 0 Figures 12 and 13 indicate that choosing the ap- 5 10 15 20 Number of ASOS Peers propriate number of ASOS peers and number of data copies has big impact on the ASOS performance. It Fig. 12. Delivery ratio vs. number of ASOS peers. Deliver ra- depends on a number of factors such as the topology, tios are the overall values of all flows directed to the destination. mobility and traffic patterns. We do not intend to ex- 303
plore an optimal solution in this paper and leave it and ad-hoc routing. Mobile Information Retrieval for future study. (IR) is studied in [7]. It splits, indexes and replicates a given database probabilistically across all mobile VI. R ELATED W ORK nodes, and a node only contacts its 1-hop neigh- The DTN Research Group (DTNRG) [4] is ded- bors to answer a query. PAN [15] is another prob- icated on providing inter-operable communications abilistic storage system in MANETs. In PAN, small in challenged networks [5][9][10], which has en- data objects are replicated to multiple servers and lightened us on developing ASOS to cope with the can be dynamically updated. To control overhead, frequent connectivity disruptions in MANET scenar- PAN “lazily” updates data such that inconsistency ios. Among other DTN efforts for MANETs, [8] may temporarily exist. It is difficult to apply Mo- proposes using controlled flooding in sparse mobile bile IR and PAN directly to ASOS for two reasons. networks for packet delivery when end-to-end paths First, the database in mobile IR is static, while in do not exist. [13] studies several different oppor- ASOS data is produced in real time. Second, both tunistic forwarding strategies using mobile routers mobile IR and PAN replicate data to improve chance (similar to the mobile ferries [27]) in vehicular ad- of access from all nodes; this is unnecessary and un- hoc networks. Adaptive routing for intermittently desirable in ASOS. connected MANETs is investigated in [16]. Our Cooperative caching has also been studied for work differs from these efforts and can be integrated MANETs. [12] proposes adding an application man- as an added feature in MANETs where the above ager component between the network layer and ap- schemes are already implemented. plications. The application manager will switch to P2P overlay storage is widely studied on the In- a better data source if the QoS provided by the cur- ternet. Cooperative File System (CFS) has been pro- rent one is degrading. This requires that at least one posed in [3]; PAST [20] is another P2P storage util- data source is available at any time, which cannot ity. These systems are good paradigms on P2P stor- be guaranteed in our target scenarios. [22] and [26] age; however, our target problem is different. CFS have investigated mechanisms of caching popular and PAST aim to provide fast file access to all po- data among ad-hoc nodes, such that when the origi- tential users on the Internet. Files are likely to be nal source is not available, data can be obtained from replicated geographically to many distant locations, nearby nodes. These studies have revealed valuable a desirable property for robust file sharing. On the insight into distributed data storage in MANETs; contrary, ASOS aims to extend the conventional end- however, they do not target the problem of extend- to-end delivery model where stored data is to be de- ing end-to-end flows to survive disruptions. livered to the intended original destination only. In sensor networks, Data Centric Storage (DCS) VII. C ONCLUSION [19] is proposed to save all data of the same type at a designated storage server, such that data queries In this paper we have proposed the Ad-hoc Stor- are directed only to the server. The basic DCS is age Overlay System (ASOS) that extends end-to-end extended with local refreshes and structured repli- data transport in MANETs when connectivity is dis- cation for better data robustness and system scala- rupted. ASOS is a DTN approach to tolerate in- bility. Resilient DCS (R-DCS) [6] further improves evitable disruptions in MANETs, by storing undeliv- the robustness and scalability by replicating data at erable data reliably in an overlay of storage-abundant strategic locations. DCS/R-DCS share many com- nodes and delivering it later when connectivity is re- monalities with the idea of ASOS; the main differ- stored. We have implemented the ASOS in QualNet, ences are: 1) DCS/R-DCS use geographic informa- and shown that it can significantly increase the over- tion mostly for routing while ASOS uses it for loca- all data delivery ratio in disrupted MANET scenar- tion selection, and 2) data replication is deterministic ios. in DCS/R-DCS but probabilistic in ASOS. In the future, we plan to investigate effective inte- In the context of MANETs, [2] has proposed to gration of ASOS with the DTN reference implemen- provide better interaction between P2P addressing tation [4]. We also plan to address a few open issues. 304
First, we have only considered pre-configured ASOS [12] W. Lau, M. Kumar and S. Venkatesh, “A Cooperative peers in this paper. Alternatively ASOS peers can be Cache Architecture in Support of Caching Multimedia Ob- jects in MANETs”, ACM WoWMoM’02, Atlanta, GA, Sept dynamically elected, e.g. when no ASOS peers are 2002. within the reach of regular nodes. Second, in order [13] J. LeBrun, C. N. Chuah and D. Ghosal. “Knowledge Based to better support multicast applications, the current Opportunistic Forwarding in Vehicular Wireless Ad Hoc data management and interface in ASOS need to be Networks”, IEEE VTC Spring 2005, Stockholm, Sweden, May 2005. revised. Erasure codes can also be incorporated into [14] N. Li, and J. C. Hou, “Improving Connectivity of Wire- ASOS to improve data reliability. Also, data encryp- less Ad-Hoc Networks”, UIUC DCS Technical Report tion, user authentication and intrusion detection are UIUCDCS-R-2004-2485, Oct 2004. needed when ASOS operates in a hostile environ- [15] J. Luo, J-P Hubaux and P. T. Eugster, “PAN: Providing ment against malicious attackers. Finally there exist Reliable Storage in Mobile Ad Hoc Networks with Proba- bilistic Quorum Systems”, ACM MobiHoc 2003, Annapo- “soft disruptions” where end-to-end connectivity is lis, MD, Jun 2003. not totally lost but can be maintained at a reduced [16] M. Musolesi, S. Hailes and C. Mascolo, “Adaptive Rout- effective capacity. We are interested in upgrading ing for Intermittently Connected Mobile Ad Hoc Net- ASOS for such scenarios. works”, IEEE WoWMoM 2005, Taormina, Italy, Jun 2005. [17] C. E. Perkins, E. M. Belding-Royer and I. Chakeres, “Ad Hoc On Demand Distance Vector (AODV) Rout- ing”, IETF Internet draft, draft-perkins-manet-aodvbis- R EFERENCES 00.txt, Oct 2003. [18] QualNet, http://www.qualnet.com/. [1] S. Chessa and P. Maestrini, “Dependable and Secure Data [19] S. Ratnasamy, D. Estrin, R. Govindan, B. Karp, Storage and Retrieval in Mobile, Wireless Networks”, S. Shenker, L. Yin and F. Yu, “Data-Centric Stor- DSN’03, San Francisco, CA, Jun 2003. age in Sensornets”, http://lecs.cs.ucla.edu/ [2] M. Conti, E. Gregori and G. Turi, “Towards Scalable P2P Publications/papers/dht.pdf. Computing for Mobile Ad Hoc Networks”, IEEE PerCom [20] A. Rowstron and P. Druschel, “Storage management and Workshops 2004, Orlando, FL, Mar 2004. caching in PAST, a large-scale, persistent peer-to-peer stor- [3] F. Dabek, M. F. Kaashoek, D. Karger, R. Morris and I. age utility”, ACM SOSP 2001, Banff, Canada, Oct 2001. Stoica, “Wide-area cooperative storage with CFS”, ACM [21] A. Rowstron and P. Druschel, “Pastry: Scalable, decentral- SOSP 2001, Banff, Canada, Oct 2001. ized object location and routing for large-scale peer-to-peer [4] Delay Tolerant Networking Research Group, http:// systems”, IFIP/ACM Middleware 2001, Heidelberg, Ger- www.dtnrg.org. many, Nov 2001. [5] K. Fall, “A Delay-Tolerant Network Architecture for Chal- [22] F. Sailhan and V. Issarny, “Cooperative Caching in Ad lenged Internets”, ACM SIGCOMM 2003, Karlsruhe, Ger- Hoc Networks”, The 4th International Conference on Mo- many, Aug 2003. bile Data Management (MDM), Jan 2003. [6] A. Ghose, J. Grossklags and J. Chuang, “Resilient data- [23] R. Shah, S. Roy, S. Jain and W. Brunette, “Data MULEs: centric storage in wireless ad-hoc sensor networks”, The Modeling a Three-tier Architecture for Sparse Sensor Net- 4th International Conference on Mobile Data Management works”, Intel Research Technical Report, IRS-TR-03-001, (MDM), Jan 2003. Jan 2003. [7] K. M. Hanna, B. N. Levine and R. Manmatha, “Mobile Dis- [24] I. Stoica, R. Morris, D. Karger, M. F. Kaashoek and H. tributed Information Retrieval For Highly-Partitioned Net- Balakrishnan, “Chord: A Scalable Peer-to-peer Lookup works”, IEEE ICNP 2003, Atlanta, GA, Nov 2003. Service for Internet Applications”, ACM SIGCOMM 2001, [8] K. Harras, K. Almeroth and E. Belding-Royer, “Delay San Diego, CA, Aug 2001. Tolerant Mobile Networks (DTMNs): Controlled Flood- [25] G. Yang, L-J. Chen, T. Sun, B. Zhou and M. Gerla, “Ad- ing Schemes in Sparse Mobile Networks”, IFIP Netwoking hoc Storage Overlay System (ASOS): A Delay-Tolerant 2005, Waterloo, Canada, May 2005. Approach in MANETs”, UCLA CS Technical Report [9] S. Jain, K. Fall and R. Patra, “Routing in a Delay Toler- 050030, Jul 2005. ant Networking”, ACM SIGCOMM 2004, Portland, OR, [26] L. Yin and G. Cao, “Supporting Cooperative Caching Aug/Sept 2004. in Ad Hoc Networks”, IEEE Infocom 2004, Hong Kong, [10] S. Jain, M. Demmer, R. Patra and K. Fall “Using Redun- China, Mar 2004. dancy to Cope with Failures in a Delay Tolerant Network”, [27] W. Zhao, M. Ammar and E. Zegura, “A Message Ferry- to appear in ACM SIGCOMM 2005, Philadelphia, PA, Aug ing Approach for Data Delivery in Sparse Mobile Ad Hoc 2005. Networks”, ACM MobiHoc 2004, Roippongi, Japan, May [11] D. B. Johnson, D. A. Maltz and Y.-C. Hu, “The Dy- 2004. namic Source Routing Protocol for Mobile Ad Hoc Net- [28] B. Zhou, K. Xu and M. Gerla, “Group and Swarm Mobil- works (DSR)”, IETF Internet draft, draft-ietf-manet-dsr- ity Models For Ad Hoc Network Scenarios Using Virtual 09.txt, Apr 2003. Tracks”, MILCOM 2004, Monterey, CA, Oct/Nov 2004. 305
You can also read