Interest Propagation In Named Data MANETs - Network Research Lab

17 downloads 13690 Views 167KB Size Report
Computer Science Dept,. UCLA ... performs well in single-consumer data retrieval scenario, ..... methods for heavy-load data services for named data MANETs.
Interest Propagation In Named Data MANETs Yu-Ting Yu1, Raheleh B. Dilmaghani2, Seraphin Calo2, M. Y. Sanadidi1, and Mario Gerla1 2 Computer Science Dept, IBM T. J. Watson Research Center, UCLA, Los Angeles, CA 90095, USA Yorktown Heights, NY, USA [email protected], {rbdilmag, scalo}@us.ibm.com, {gerla, medy}@cs.ucla.edu

Abstract—Named Data MANETs (NDM) is a recently emerging research area. The in-network chunk-based caching feature of NDN is beneficial in coping with the mobility and intermittent connectivity challenges in MANETs. In this paper, we conduct both simulation and emulation study of NDM forwarding designs: NDN Forwarding (NDNF), Listen-First, Broadcast-Later (LFBL), and the proposed Neighborhood-Aware Interest Forwarding (NAIF). NAIF aims for reducing the bandwidth usage induced by indiscriminate interest flooding in NDNF. It decreases the interest traffic by letting eligible relays work cooperatively, each forwards only a fraction of interest packets. The results show that NAIF achieves the best performance in multi-consumer scenarios. In particular, compared to NDNF, NAIF reduces bandwidth usage by up to 54%, shortens response time in low-mobility scenarios, and achieves high completion ratio. Index Terms—Named-Data Networks, MANETs

I. INTRODUCTION Mobile Ad-Hoc Network (MANET) is an infrastructureless network architecture constituted by mobile devices. The main advantage of MANET is that it can be formed at low cost in response to temporary needs, and thus is often used in battlefield and disaster-recovery networks. The major challenges in MANET are mobility and intermittent connectivity. Nodes are assumed to move at varying speeds, resulting in fast-changing topologies and extreme packet losses, and consequently high overhead for route construction and maintenance costs. Moreover, the performance may suffer from temporary network partitioning. Named Data Networks (NDN) [1], a network architecture that uses the data names instead of host addresses to locate data, is a natural fit to MANET data retrieval. Every NDN data chunk has a uniquely identified name. This uniquely identified chunk naming enables the chunk-based in-network caching. The NDN architecture strictly assumes pull-based forwarding and one-interest-one-data principle. To initiate a data transfer, a data consumer must send an Interest Packet (IntP) to request the corresponding Data Packet (DatP). All nodes cache the data chunks they relay and become servers of the cached chunks. With distributed caches, a data retrieval failure arising from intermittent connectivity can be quickly recovered and the scalability and efficiency data propagation can be improved. Furthermore, the name-based forwarding is compatible with multi-path forwarding and thus is potentially more robust than host-based routing in MANET. In [1], NDN nodes select on which interface(s) to broadcast the IntP. The corresponding DatP follows the breadcrumb trail of the IntP back to the data consumer. This design assumes

multiple interfaces at a node. However, in typical MANET deployment where a node uses only one interface, the interfaceselecting design results in all nodes flooding all IntPs they received. The flooding traffic will cost extreme bandwidth and energy consumption. One solution is to construct an overlay network on top of IP layer as in CCNx [2]. However, implementing overlay NDN is costly in MANET because (1) end-to-end route construction and maintenance between overlay nodes induce high control overhead and (2) the overlay design ends up performing point-to-point transmission without exploiting the broadcasting nature of wireless channel. Another challenge in MANET NDN is cached fragment phenomenon. That is, although the complete data object may reside in a single physical node, the caches are likely to hold only partial data objects. Therefore, existing single-path routing algorithms that keep sending packets to the first found location may end up re-flooding most IntPs due to the inability to predict the connectivity and chunk completion state of the IntP destination. As a result, efficient forwarding designs in NDM are of significant interests. In this paper, we investigate the performance of three NDM forwarding designs: the original NDN forwarding (NDNF) [1], the proposed NeighborhoodAware Interest Forwarding (NAIF), and the representative of single-path ad-hoc routing, Listen-First, Broadcast Later (LFBL) [3]. Our results show that although LFBL, which provides low response time and bandwidth utilization, performs well in single-consumer data retrieval scenario, NDNF and NAIF are more robust in multi-consumer scenarios. Furthermore, NAIF achieves significant improvements over NDNF. The bandwidth consumption is reduced nearly by half in intermittently connected scenarios. The organization of this paper is as follows. Section II discusses the related work. We briefly introduce the NDM forwarding approach in Section III. In Section IV, the detailed NAIF algorithm is presented. The experiment results are reported in Section V. We conclude this paper in Section VI. II. RELATED WORK NDM routing can best relate to opportunistic forwarding, which is widely used in delay-tolerant networks, in which it is difficult to obtain full topology information. Most routing protocols in such environments are variations of Epidemic Routing (ER) [4]. ER diffuses messages into networks in a similar way as diseases using the cache-and-forward technique. To reduce the overhead and delay of ER, MV routing [5] opportunistically selects messages to forward to encountered nodes. Follow-up work [6][7] utilize mobility patterns or

contact history to improve the performance. However, these host-based protocols cannot be applied to NDN directly. Mobile NDN is a recently emerging research area. In [8], Wang et al. propose an NDN-based data collection system for vehicular infrastructure networks. Lee et al. propose a proxybased scheme for increasing efficiency of mobile retrievals [9]. As for MANETs, in [10], Oh et al. propose a tactical NDM approach using OLSR and Pastry and study its feasibility. In [11], Varvello et al. compare the performance of reactive flooding, proactive flooding, and Geographic Hash Table (GHT) in NDM analytically. Their results show that the reactive flooding approach outperforms the other two. III. NDM FORWARDING DESIGNS A. NDNF The original forwarding design in [1], which we call NDNF, first broadcasts (floods) IntPs, while DatPs follow the breadcrumb trails of the IntPs back to the data consumer. The advantage of this approach is its robustness under mobility and intermittent connectivity, and cached fragment phenomenon. The widespread DatPs are beneficial for data in high demand since the consumers are likely to encounter desired cached chunks in their proximity. However, NDNF causes large overhead in ad-hoc networks due to redundant data propagation. B. Neighborhood-Aware Interest Forwarding (NAIF) Being aware of the excessive overhead of NDNF, we propose an adaptive IntP propagation mechanism, NAIF, which aims at reducing the flooding overhead while maintaining the robustness. As in NDNF, NAIF transmissions are all broadcast and neither IntPs nor DatPs are explicitly routed. The rationale of NAIF is that instead of selecting a node to forward the IntP to, relays cooperatively propagate IntPs between the consumer and potential data sources. Relays sending duplicate IntPs may cause collisions and congestion, in particular if the senders are hidden from each other. NAIF mitigates hidden terminal superfluous forwarding by controlling transmissions based on node forwarding statistics, which are then used to adjust forwarding rate. The forwarding rate is the fraction of packets a node should forward for the given name prefix. A relay locally decides to broadcast or to drop the received IntPs based on the forwarding rate. The intuition of forwarding rate adjustment is: the more DatPs of the same name prefix a node overhears from its neighbors, the more IntPs corresponding to that name prefix it can drop as it judges them to be superfluous. In NAIF, a node gradually lowers its forwarding rate if it hears its neighbors sending the DatPs corresponding to the IntPs it dropped. Conversely, when a node detects it has dropped too many IntPs , it increases its forwarding rate to compensate. In this way, the relays cooperatively forward the IntPs without congestion. We will describe detailed NAIF control algorithm in Section IV. C. LFBL LFBL [3] is a low-overhead forwarding protocol for Named Data MANETs aiming at constructing single paths to data providers. It is designed as a NDN replacement. In LFBL, each

node maintains distances to known data object names and node names. If the data object distance is unknown, the IntP is flooded. Otherwise, the IntP is broadcast but propagated to the nearest data holder via implicitly chosen shortest paths using opportunistic routing [12] based on the destination distances estimated by relays. DatPs are propagated via the shortest path back to the consumer in the same way. The estimated distances to the endpoints are refreshed at the relays along the shortest paths when the relays hear new packets. LFBL achieves lower bandwidth usage due to its path selection nature. However, a potential problem lies in the accuracy of distance estimation. Moreover, the passive best path selection process alone does not protect LFBL from the cached fragment phenomenon. The object location found by the first IntP can actually be a cache holding only part of the data object. Hence, in the worst case, following the path to the same destination results in continuous re-flooding of individual IntPs for the missing chunks. In addition, LFBL requires significant modifications of current NDN. IV. NAIF FORWARDING CONTROL The two-pass NAIF algorithm is applied only to interest forwarding at relay nodes. At the first pass, ineligible forwarders are filtered out. The eligibility of a relay node is decided by its data retrieval rate for the given name prefix and its distance to the data consumer. In other words, the relays which cannot reach any potential forwarders pruned themselves from the forwarding set. If the data retrieval rate is low or the node is too far away from the data consumer, the incoming IntP will be discarded locally. In order to handle temporary network partitions, the relay with low data retrieval rate probes the network every TPROBE seconds to recover the forwarding statistics. At the second pass, the eligible forwarder probabilistically drops the incoming IntP based on the updated smoothed forwarding rate, F% , of its name prefix. The forwarding rate update process is described below. The NAIF forwarding control is based on two local forwarding parameters at relay nodes: the data retrieval rate R, which is the ratio of the number of DatPs successfully retrieved to the number of IntPs sent; and the forwarding rate F, which is the fraction of incoming IntPs that a given node will forward. The forwarding parameters are periodically adjusted based on the forwarding statistics. Four forwarding statistics for each name prefix are collected during an update interval: the number of distinct IntP sent sint, the number of distinct DatP received rdata, the number of distinct IntP cleared c, which is increased by one when an PIT entry is cleared, and the number of distinct non-cached IntP received rint. A non-cached IntP is defined as an IntP requesting a DatP that is not cached at the given node. Nodes passively collect forwarding statistics by monitoring IntPs and DatPs forwarded by itself and one-hop neighbors. Periodically, the retrieval rate and the forwarding rate for each name prefix are updated periodically, then the forwarding statistics are reset. The data retrieval rate is used to measure the effectiveness of a node in retrieving a DatP for a name prefix. At the end of an update interval t, the data retrieval rate is computed by

Rt = c sint

(1)

Note that we use c instead of rdata because a node may receive DatPs which it had not requested since all packets are broadcast. The forwarding rate is defined as the fraction of IntP sent by a node. At the end of an update interval t, the actual forwarding rate during t is (2) Ft = sint rint The main idea of forwarding rate adjustment is, to acquire a DatP of interest, nodes in a neighborhood can share the forwarding workload for a data object. As the neighborhood is retrieving the DatPs of the node’s interest successfully, the node may reduce its own forwarding rate. When a node drops an IntP and relies on its neighbors to send it, this IntP is considered missed if the retrieval of the corresponding DatP is unsuccessful. Assuming the number of missed IntPs, δ, is known. The forwarding rate is adjusted by  min ( sint − 1 rint , F%t −1 − α ) if δ t − β = L =δ t −1 = δ t = 0 (3) F%t =  ( sint + δ t ) rint otherwise  If there is no missed IntP in the previous β intervals, the node gradually reduces its forwarding rate. Otherwise, the node adjusts its forwarding rate upwards based on δ. Each node locally estimates δ. If a node received an IntP and dropped it, and the node does not overhear the corresponding DatP later, the IntP may have been missed. Therefore, the number of missed IntPs is obtained by (4) δ = ( rint − sint ) − ( rdata − c ) Exponential averaging is used to smooth the variations in the forwarding parameters. The smoothed average retrieval rate R% and forwarding rate F% are reset to initial value if the known data prefix is not heard for a configurable period of time. V. PERFORMANCE EVALUATION A. Application Design For validation purpose, a name-based file transfer application is implemented. Each data object is segmented into m segments. Each segment is named file/1, file/2, …, file/m, respectively. The file transfer application can be executed in two modes: Constant Bit Rate (CBR) mode or window mode. In CBR mode, the IntPs are sent in a constant rate. In window mode, the data consumer initially sends a batch of IntPs. A fixed-size moving window called the interest window controls the set of outstanding IntPs. The process is similar to TCP with a fixed window size. If DatPs are received out-of-order, the interest window is advanced to the next segment it had not requested or received yet. B. Metrics and Experiment Settings The experiments are conducted via both simulation and emulation. Our simulation is done with QualNet 4.5. The emulation is run on a Lenovo T61 laptop with Common Open Research Emulator (CORE) [13]. We measure four metrics: response time, number of transmissions, completion time, and completion ratio. The response time is the time interval from the moment a data

consumer first sends an IntP to the time when the data consumer receives the first corresponding DatP. The number of transmissions includes all the transmissions in the system. The completion time is the time during which all file transfers are completed. The completion ratio is the fraction of chunks successfully received by the data consumer out of all chunks. LFBL is sensitive to the distance metrics. The most intuitive distance metric is hop count, which has been widely used in routing protocols. It was reported that the received signal strength RXPOWER is the best metric [3]. Thus, we present the results of both hop count and RXPOWER. To investigate the impact of cached fragment phenomenon, we study two versions of LFBL: LFBL-A distinguishes cache copies by indicating the full name of the cached chunk (e.g. /john/presentation/1) as prefix. LFBL-B does not distinguish between cache copies and producer copies, and always carry the file prefix (e.g. /john/presentation) as source name in DatP. We keep most of the setting used in [3] for LFBL and use identical settings for all corresponding parameters for NDNF and NAIF. Unless otherwise stated, the simulation consists of 50 nodes initially uniformly distributed in a 1000m×1000m area, moving based on random waypoint model. 50% of the data chunks are uniformly distributed to relay caches in advance. The physical layer is IEEE 802.11b. CBR applications that initiate two IntPs per second are used. The simulation time is 600 seconds. The data chunk size is 128 bytes. All experiments are run ten times with different random seeds and the average results are reported. The retransmission limit (RLIMIT) is 4. The retransmission interval (TRTX) is 1 second. For NAIF, TPROBE is 2 seconds, the update interval is 1 second, R* is 30%, α is 0.05, and β is 1. C. Experiment 1: Single Consumer In this experiment, one data consumer downloads a file from one data producer. Figure 1 presents the completion ratio. NDNF and NAIF both achieve almost perfect completion ratios. The results of LFBL protocols are consistent with the results reported in [3]: the distance metric RXPOWER performs much better than HOP-COUNT. LFBL-B performs worse than LFBL-A due to its inability to identify cached copies. The reason is that LFBL-B data consumer frequently sends its IntPs to a cache node that only has partial file. This impact is more pronounced in static networks. Interestingly, LFBL-B performance is much improved with mobility. The reason is that as nodes move, the data consumer is more likely to reach cached chunks if the IntPs were not sent to the data producer. The response time and number of transmissions are presented in Fig. 2 and Fig. 3. LFBL-based protocols maintain low response time and transmissions since they usually select only one forwarding path. In contrast, NDNF and NAIF broadcast more redundant packets, resulting in relatively higher response time and transmissions. However, compared to NDNF, NAIF reduces the number of transmissions by about 25%, albeit at slightly higher response times. D. Experiment 2: Multiple Consumers In this experiment, three data consumers download the same file in parallel. The completion ratio is reported in Fig. 4.

oi100.00% t 80.00% ar 60.00% n 40.00% oi 20.00% te 0.00% l p m o C NAIF

x20000 15000 T l10000 at 5000 o 0 T 0

10

20

NDNF

LFBL-A (RXPOWER)

LFBL-B (RXPOWER)

LFBL-B (HOP-COUNT)

(

20

30

Mobility (m/s)

0

10

20

NAIF

NDNF

LFBL-A (RXPOWER)

LFBL-B (RXPOWER)

LFBL-A (HOP-COUNT)

LFBL-B (HOP-COUNT)

Fig. 3. Experiment 1: Number of transmissions 100.00%

Fig. 1. Experiment 1: Completion ratio 0.4 0.3 0.2 )c0.1 se 0

10

Mobility (m/s)

LFBL-A (HOP-COUNT)

e m it es n o p se R

0

30

30

Mobility (m/s)

oi 80.00% t a 60.00% R40.00% n oi 20.00% te 0.00% l p m o C

0

10

20

30

Mobility (m/s)

NAIF

NDNF

LFBL-A (RXPOWER)

NAIF

NDNF

LFBL-A (RXPOWER)

LFBL-B (RXPOWER)

LFBL-A (HOP-COUNT)

LFBL-B (HOP-COUNT)

LFBL-B (RXPOWER)

LFBL-A (HOP-COUNT)

LFBL-B (HOP-COUNT)

Fig. 2. Experiment 1: Response time

While NDNF and NAIF achieve almost perfect completion ratios, LFBL-A (RXPOWER), which is the best performing one among all LFBL versions, achieves less than 70% completion ratio. The reason is that in LFBL, once the distance to the data producer is obtained by initial flooding, the distances are only refreshed at the relays along the initial shortest path. Therefore, the distance updates from two different paths may frequently mess each other up. An example is shown in Fig. 5. C1 and C2 are two data consumers requesting the same file from file. C1 sends its IntPs via the path C1-R2-R1-file; C2 receives it DatPs via file-R3-R4-C2. For simplicity, we use HOP-COUNT as the distance metric. Note that the distance metric does not affect the issues described below. R1’s correct distance to file is 1 and R2’s distance is 2. There are two potential issues in the forwarding process. First, suppose the producer sends a DatP via R3 destined to C2 while R2 is sending an IntP to R1, since R2 and the file producer are hidden to each other, it is very likely that R1 will lose the IntP. C1 may fix this failure by re-initiating the same IntP. However, distance update interference may happen before the re-initiation. Suppose R3 first broadcasts the DatP destined to C2. Since this DatP carries destDist=1 in its header and the information is newer than previous distance updates at R1, R1 updates its distance to 2. Note that R1 does not propagate its new distance to R2 because it is not an eligible forwarder for C2’s packets. R1 and R2 then both believe their distances to the producer are 2. Thus, R1 stops forwarding the subsequent IntPs it received from R2 because its distance is not shorter than R2’s. This state persists until the distance at C1 expires or R1 corrects its distance when it hears new DatPs from file. This situation causes many IntP losses when multiple consumers send their IntPs to the same node. The current LFBL design cannot identify this situation and hence cannot fix the broken path in a timely manner. The response time and the total number of transmissions are presented in Fig. 6 and Fig. 7. We find that when the network is static, LFBL protocols have longer response time in multiconsumer scenario as the hidden terminal and distance update interference lead to more retransmissions. This issue is more pronounced for LFBL-A protocols since they direct all IntPs to the same producer while LFBL-B protocols may direct some to different cache nodes. Although NDNF and NAIF have larger

Fig. 4. Experiment 2: Completion ratio

Fig. 5. Distance interference in multi-consumer data retrieval

response times and bandwidth consumptions, they are robust enough to maintain high completion ratios. In other words, the extra bandwidth consumption is sacrificed in exchange of higher reliability. In particular, NAIF maintains perfect completion ratios while reducing NDNF’s bandwidth consumption by approximately 20%. E. Experiment 3:Intermittent Networks In this experiment, the scenario consists of two groups of nodes with speeds 5 to 15 m/s, each containing ten nodes uniformly placed in an 1000m×1000m area. The two group areas are adjacent, forming two intermittently connected partitions. One data producer and one data consumer are placed in the first group. Two data consumers are placed in the other. All relay caches are empty when the simulation starts. Window-mode application with window size 10 is used since it prevents all IntPs being retransmitted during partitioning. The simulation results are presented in Fig. 8. In Fig. 8(a), NAIF significantly reduces the number of transmissions at all node-traveling speeds, and consequently saves bandwidth. The reason is that NAIF detects when the data holders are unreachable and thus reduce unnecessary transmissions. Fig. 8(b) shows that NAIF achieves comparable completion time as NDNF does. NAIF achieves shorter average response time at low mobility, as shown in Fig. 8(c). NAIF’s ability of learning data unreachability also contributes its shorter response time at low mobility. When nodes move at higher speeds, NAIF responds slightly slower because it takes a short time period to recover transmissions when the sub-networks are reconnected. In summary, NAIF saves 30%-54% in number of transmissions. F. Emulation Results We conducted emulation and present the performance of NAIF and NDNF under the intermittently-connected scenario.

)c0.6 es ( 0.4 e im0.2 T0 es n o p es R NAIF

TABLE I. EMULATION RESULTS

0

10

20

Number of Tx Completion time Average response time

30

Mobility (m/s)

LFBL-B (RXPOWER)

NDNF

LFBL-A (RXPOWER)

LFBL-A (HOP-COUNT)

LFBL-B (HOP-COUNT)

Fig. 6. Experiment 2: Response Time

0 10

20

30

Mobility (m/s)

NAIF

NDNF

LFBL-A (RXPOWER)

LFBL-B (RXPOWER)

LFBL-A (HOP-COUNT)

LFBL-B (HOP-COUNT)

Fig. 7. Experiment 2: Number of transmissions s) 70 d 60 n as 50 u 40 o 30 h (t 20 x 10 lT 0 at o T

20

30 40 50 Mobility (m/s) NDN

ce) 250 s( 200 e 150 m ti 100 n o tie 50 l p 0 m o C

60

20

NAIF

NDN

(a)Number of transmissions )s 2000 m ( 1600 e 1200 m ti 800 es 400 n 0 o sp e R

20

30

30 40 50 Mobility (m/s)

60

NAIF

(b)Completion time

40 50 Mobility (m/s)

NDN

NAIF 51868 99.73% 250.32 ms

ACKNOWLEDGMENT This paper is based on work supported by the National Science Foundation under Grant No. CNS-1205757, Singapore DSO National Labs under Grant No. DSCCO10350, and the U.S. Army Research Laboratory (ARL) and the U.K. Ministry of Defence under Agreement Number W911NF-06-3-0001.

25000

x20000 T l 15000 ta10000 o T 5000 0

NDNF 93649 100% 236.94 ms

60

NAIF

(c)Response time Fig. 8. Experiment 3 results

In the emulation, the two groups of nodes each contains five nodes uniformly placed in a 450x400 area. The other settings are the same as that in the simulation. The emulation results are compiled in Table I. The completion time of NAIF is presented relatively to the completion time of flooding. The result shows that NAIF reduces the number of transmissions by about 45% compared to those of NDNF. Meanwhile, NAIF achieves comparable completion time and average response time. VI. CONCLUSIONS We propose NAIF, a NDM forwarding protocol aiming at reducing the high overhead of NDN forwarding design, in this paper. We evaluate the performance of NAIF along with the existing NDM forwarding mechanisms, NDNF and LFBL. NDNF and NAIF generally utilize all useful relays, while LFBL implicitly selects one path between a consumer and a data holder. Our results show that NDNF and NAIF achieve 30-60% higher completion ratio in multi-consumer data retrieval scenarios than LFBL. NAIF significantly reduces bandwidth usage by up to 54% while maintaining completion time and average response time comparable to NDNF in both simulation and emulation. Therefore, NAIF can be viewed as a starting point to design reliable name-based forwarding methods for heavy-load data services for named data MANETs.

REFERENCES [1] V. Jacobson, D. K. Smetters, J. D. Thornton, M. F. Plass, N. H. Briggs, and R. L. Braynard, "Networking named content," in CoNEXT 2009, 5th international conference on Emerging networking experiments and technologies, Dec. 2009, pp. 1-12. [2] Project CCNxTM, Sep. 2009, http://www.ccnx.org [3] M. Meisel, V. Pappas, and L. Zhang, "Ad hoc networking via named data," in Proceedings of the fifth ACM international workshop on Mobility in the evolving internet architecture, New York, NY, USA: ACM, 2010, pp. 3-8. [4] A. Vahdat and D. Becker, “Epidemic Routing for Partially Connected Ad Hoc Networks,” Tech. Rep. CS-200006, Department of Computer Science, Duke University, Durham, NC, 2000. [5] B. Burns, O. Brock, and B. N. Levine, "MV routing and capacity building in disruption tolerant networks," in Proceedings IEEE 24th Annual Joint Conference of the IEEE Computer and Communications Societies., vol. 1. IEEE, 2005, pp. 398-408. [6] P. Mundur and M. Seligman, "Delay tolerant network routing: Beyond epidemic routing," in 2008 3rd International Symposium on Wireless Pervasive Computing. IEEE, May 2008, pp. 550-553. [7] E. C. R. de Oliveira and C. V. N. de Albuquerque, "NECTAR: a DTN routing protocol based on neighborhood contact history," in Proceedings of the 2009 ACM symposium on Applied Computing, New York, NY, USA: ACM, 2009, pp. 40-46. [8] J. Wang, R. Wakikawa, and L. Zhang, "DMND: Collecting data from mobiles using named data," in 2010 IEEE Vehicular Networking Conference. IEEE, Dec. 2010, pp. 49-56. [9] J. Lee, D. Kim, M.-W. Jang, and B.-J. Lee, "Proxy-based mobility management scheme in mobile content centric networking (CCN) environments," in 2011 IEEE International Conference on Consumer Electronics (ICCE), pp. 595-596. [10] S. Y. Oh, D. Lau, and M. Gerla, "Content centric networking in tactical and emergency MANETs," in Wireless Days (WD), 2010 IFIP. IEEE, Oct. 2010, pp. 1-5. [11] M. Varvello, I. Rimac, U. Lee, L. Greenwald, and V. Hilt, "On the design of content-centric MANETs," in Eighth International Conference on Wireless On-Demand Network Systems and Services (WONS), IEEE, Jan. 2011, pp. 1-8. [12] S. Biswas and R. Morris, "Opportunistic routing in multi-hop wireless networks," SIGCOMM Comput. Commun. Rev., vol. 34, no. 1, pp. 69-74, Jan. 2004. [13] Jeff Ahrenholz, Claudiu Danilov, Thomas R. Henderson, and Jae H. Kim. 2008. CORE: A real-time network emulator. In Proceedings of the 27th military communication conference (MILCOM ’08). IEEE

Suggest Documents