Cooperative caching in mobile ad hoc networks based on data utility

Cooperative caching, which allows sharing and coordination of cached data among clients, is a potential technique to improve the data access performance and availability in mobile ad hoc networks. However, variable data sizes, frequent data updates, limited client resources, insufficient wireless bandwidth and client’s mobility make cache management a challenge. In this paper, we propose a utility based cache replacement policy, least utility value (LUV), to improve the data availability and reduce the local cache miss ratio. LUV considers several factors that affect cache performance, namely access probability, distance between the requester and data source/cache, coherency and data size. A cooperative cache management strategy, Zone Cooperative (ZC), is developed that employs LUV as replacement policy. In ZC one-hop neighbors of a client form a cooperation zone since the cost for communication with them is low both in terms of energy consumption and message exchange. Simulation experiments have been conducted to evaluate the performance of LUV based ZC caching strategy. The simulation results show that, LUV replacement policy substantially outperforms the LRU policy.


Introduction
Recent explosive growth in computer and wireless communication technologies has led to the development of Mobile Ad hoc NETworks (MANETs) that are constructed only from mobile hosts.The interest in developing mobile wireless ad hoc networking solutions has been due to their flexibility, ease of deployment and potential applications such as battlefield, disaster recovery, outdoor assemblies, etc.Most of the previous researches [1][2][3][4][5] in MANETs focus on the development of dynamic routing protocols that can improve the connectivity among mobile hosts which are connected to each other by one-hop/multi-hop links.Although routing is an important issue in ad hoc networks, other issues such as data access are also very important since the ultimate goal of using such networks is to provide information access to mobile hosts [6].One of the most attractive techniques that improve data availability is caching.In general caching results in (i) enhanced QoS at the clients -i.e., lower jitter, latency and packet loss, (ii) reduced network bandwidth consumption, and (iii) reduced data server/source workload.In addition, reduction in bandwidth consumption infers that a properly implemented caching architecture for a MANET environment can potentially improve battery life of mobile clients.
Caching has been proved to be an important technique for improving the data retrieval performance in mobile environments [15][16][17][18].With caching, the data access delay is reduced since data access requests can be served from the local cache, thereby obviating the need for data transmission over the scarce wireless links.However, caching techniques used in one-hop mobile environment (i.e., cellular networks) may not be applicable to multi-hop mobile environments since the data or request may need to go through multiple hops.As mobile clients in ad hoc networks may have similar tasks and share common interest, cooperative caching, which allows the sharing and coordination of cached data among multiple clients, can be used to reduce the bandwidth and power consumption.
Cache management in mobile ad hoc networks, in general, includes the following issues to be addressed: 1.The cache discovery algorithm that is used to efficiently discover, select, and deliver the requested data item(s) from neighboring nodes.In a cooperative architecture, the order of looking for an item follows local cache to neighboring nodes, and then to the original server.2. Cache admission control -this is to decide on what data items can be cached to improve the performance of the caching system.3. The design of cache replacement algorithm -when the cache space is sufficient for storing one new item, the client places the item in the cache.Otherwise, the possibility of replacing other cached item(s) with the new item is considered.4. The cache consistency algorithm which ensures that updates are propagated to the copies elsewhere, and no stale data items are present.
In this paper, we investigate the data retrieval challenge of mobile ad hoc networks and propose a novel scheme, called Zone Cooperative (ZC) for caching that exploits data utility value for cache replacement.The goal of ZC is to reduce the caching overhead and provide optimal replacement policy.Mobile clients belonging to the neighborhood (zone) of a given client form a cooperative cache system for this client since the cost for communication with them is low both in terms of energy consumption and message exchanges.In ZC caching, each mobile client has a cache to store the frequently accessed data items.The cache at a client is a nonvolatile memory such as hard disk.The data items in the cache satisfy not only the client's own requests but also the data requests passing through it from other clients.For a data miss in the local cache, the client first searches the data item in its zone before forwarding the request to the next client that lies on a path towards server.We also develop an analytical model for the ZC caching system to evaluate its performance.To improve the efficiency of ZC caching, a Least Utility Value (LUV) based replacement policy has been developed.Simulations prove that ZC caching with LUV achieves higher performance than ZC based on LRU replacement.
The rest of the paper is organized as follows.Section 2 reviews the related work.The network model and system environment are presented in Section 3. Section 4 describes the proposed ZC caching scheme for data retrieval.Section 5 describes the LUV cache replacement policy.Section 6 presents an analytical model of ZC.Section 7 is devoted to performance evaluation and presents detailed simulation results.Section 8 concludes the paper and discusses future work.

Related work
Caching is an important technique to enhance the performance of both wired and wireless network.A number of studies have been conducted to improve the caching performance in wireless mobile environment [15][16][17][18].Jayaputera and Taniar [25] have proposed to use an invalidation report mechanism in conjunction with caching of a CORBA (Common Object Request Broker Architecture) object in a mobile environment.The approach caches CORBA object by value and is capable to keep the object updated in a client side during disconnection.Client mobility hampers the caching performance in a mobile environment.It is found that as mobile clients move from one cell to another they experience increasing delay when accessing data items from their home location caches [26].Lai et al. [26] have proposed two techniques to improve the performance of existing cache relocation methods for mobile networks.The first technique, 2PR, compensates for poor path prediction by temporarily moving data items to a common parent node prior to a handover.Items are moved to the correct destination once the client's new location has been confirmed.The second technique, ROLP, reduces the traffic overhead associated with cache relocation by ensuring duplicate items are not relocated and relocation of items are performed only from the nearest node to the destination.
Cooperative caching has been studied in the Web environment, but little work has been done to efficiently manage the cache in MANETs.Due to mobility and constrained resources (i.e., bandwidth, battery power and computational capacity) in wireless networks, cooperative cache management techniques designed for wired networks may not be applicable to ad hoc networks.
In the context of ad hoc networks, it is beneficial to cache frequently accessed data not only to reduce the average query latency but also to save wireless bandwidth.Hara [14] proposed several replica allocation methods to increase data accessibility and tolerate network partitions in MANETs.In these schemes, the replicated data are relocated periodically based on access frequency and overall network topology.Although replication can improve data accessibility, the overhead for relocating replicas periodically is significantly high.Due to updates at the server, the cost of maintaining the consistent copy of replicas is quite high.Papadopouli et al. [12] suggested the 7DS architecture, in which a couple of protocols are defined to share and disseminate information among users.It operates either on a prefetch mode, based on the information and user's future needs or on an on-demand mode, which searches for data items in a one-hop multicast basis.Depending on the collaborative behavior, a peer-to-peer (P2P) and serverto-client mode are used.Unlike our approach, this strategy focuses on data dissemination, and thus the cache management including cache admission control and replacement is not well explored.Sailhan and Issarny [20] proposed a cooperative caching scheme to increase data accessibility by P2P communication among mobile clients, when they are out of bound of a fixed infrastructure.It is implemented on top of Zone Routing Protocol (ZRP).The authors proposed a fixed broadcast range based on the underlying routing protocol.However, the mobile users' location, data popularity and network density often change in a real mobile environment, so the fixed broadcast scheme is hard to adapt to real mobile applications.
Lau et al. [13] proposed a cooperative caching architecture for supporting continuous media proxy caching.They introduced an application manager to transparently perform data location and session migration of continuous media streams among all proxy caches.Nuggehalli et al. [11] addressed the problem of optimal cache placement in ad hoc wireless networks and proposed a greedy algorithm, called POACH, to minimize the weighted sum of energy expenditure and access delay.S. Lim et al. [22] proposed cache invalidation techniques for Internet based MANETs (IMANETs).However, due to broadcast nature, the cost of maintaining strong cache consistency is very high in ad hoc networks as compared to cellular mobile networks.Authors in [2] proposed a cooperative caching scheme for IMANETs.A broadcast based simple search scheme is proposed to establish cooperation among all clients in the network to share cached data items.Although the broadcast based data search scheme can locate the nearest required data item, the energy and bandwidth cost of the flooding search is significantly high for a mobile ad hoc network.Shen et al. [8] proposed a broadcast based cooperative caching scheme for hybrid networks where a client shares the caches of clients lying in its proximity.Bandwidth and energy consumption to locate a client having cached the requested data is very high due to flooding of the messages.
Yin and Cao [6,7,23] designed and evaluated three caching algorithms (CacheData, CachePath and Hybrid) to support data access in ad hoc networks.These algorithms mainly focus on the problem of choosing data item or data path for caching in the limited cache space of mobile nodes.The problem with CacheData approach is that it could take a lot of caching space with forwarding clients.The recording path could become obsolete in CachePath and this scheme could introduce extra processing overhead.Hybrid cache decides when to use which of the two schemes based on the properties (size and time-to-live (TTL)) of the passing-by data and requires that the forwarding clients will keep record of which data is more important.Since the forwarding clients can move to somewhere else in the next second, statistics collected by the forwarding clients does not help much.In [23], the authors also proposed a cache replacement policy based on data item size and popularity.But, the policy ignored the important factors such as TTL and distance of the requester from the cache/source satisfying the request.Zang et al. [9] talked of security concerns for cooperative caching in ad hoc networks.
Du and Gupta [24] proposed a cooperative caching scheme called COOP for MANETs with the aim to improve data availability and access efficiency.For cache resolution, COOP uses flooding based approach.As part of cache management, it uses the inter-category and intra-category rules to minimize caching duplications between neighboring nodes.Disadvantage of the scheme is that flooding incurs high discovery overhead and it does not consider factors such as size and consistency during replacement.

Network model
This work assumes that an ad hoc network comprises a group of mobile clients communicating through omni-directional antennas with the same transmission range.The topology of an ad hoc network is thus represented by an undirected graph G = (V, E), where V is the set of mobile clients MH 1 , MH 2 , . . ., and E⊆V×V is the set of links between clients.The existence of a link (u, v)∈E also means (v, u)∈E, and that clients u and v are within the transmission range of each other, in which case u and v are called one-hop neighbors of each other.The set of one-hop neighbors of a client MH i is denoted by MH 1  i and forms a cooperation zone.The combination of clients and transitive closure of their one-hop neighbors forms a MANET.Two clients that are not connected but share at least one common one-hop neighbor are called two-hop neighbors of each other.
As clients can physically move, there is no guarantee that a neighbor at time t will remain in the zone at later time t + τ .The devices might be turned off or on at any time, so the set of live clients varies with time and has no fixed size.

System environment
The system environment is assumed to be an ad hoc network where mobile clients access data items held as originals by other mobile clients.A mobile client that holds the original value of a data item is called data server/source/center.A data request initiated by a client is forwarded hop-by-hop along the routing path until it reaches the data source and then the data source sends back the requested data.Each mobile client maintains local cache in its hard disk.To reduce the bandwidth consumption and query latency, the number of hops between the data source/cache and the requester should be as small as possible.Most mobile clients, however, do not have sufficient cache storage and hence the caching strategy is to be devised efficiently.We also make the following assumptions: -The system has total of M hosts and MH i (1 i M) is a unique host identifier.The set of one-hop neighbors of a host MH i is denoted by MH 1 i and forms a zone.-The set of all data items is denoted by D = {d 1 , d 2 , . . ., d N }, where N is the total number of data items and d j (1 j N) is a data identifier.D i denotes the actual data of the item with id d i .Size of data item d i is s i .The original of each data item is held by a particular data source.-Each mobile host has a cache space of C bytes.
-Each data item is periodically updated at data source.After a data item is updated, its cached copy (maintained on one or more hosts) may become invalid.

Zone cooperative caching scheme
This section describes our Zone Cooperative (ZC) caching scheme for data retrieval in MANETs.The design rationale of the ZC caching is that it is advantageous for a client to share cached data with its neighbors lying in the zone (i.e., mobile clients that are accessible in one hop).Mobile clients belonging to the zone of a given client then form a cooperative cache system for this client since the cost for communicating with them is low both in terms of energy consumption and message exchange.Figure 1 shows the behavior of ZC caching strategy for a client request.For each request, one of the following four cases holds: Case 1: Local hit.When copy of the requested data item is stored in the cache of the requester.If the data item is valid, it is retrieved to serve the query and no cooperation is necessary.
Case 2: Zone hit.When the requested data item is stored in the cache of one or more one-hop neighbors of the requester.Message exchange within the home zone of the requester is required during the cache discovery.
Case 3: Remote hit.When the data is found with a client belonging to a zone (other than home zone of the requester) along the routing path to the server.
Case 4: Global hit.Data item is retrieved from the server.

Cache discovery process
A cache discovery algorithm is needed to determine if and where the requested item is cached when the requester does not have knowledge of the destination.When a data request is initiated at a client, it first looks for the data item in its own cache.If there is a local cache miss, the client broadcasts request packet to check if the data item is cached in other clients within its home zone.When a client receives the request and has the data item in its local cache (i.e., a zone cache hit), it will send an ack packet to the requester to acknowledge that it has the data item.In case of a zone cache miss, the request is forwarded to the neighbor along the routing path.Before forwarding a request, each client along the path searches the item in its local cache or zone as described above.If the data item is not found on the zones along the routing path (i.e., a remote cache miss), the request finally reaches the data source.When a client receives an ack packet, it sends a confirm packet against first ack packet.The ack packets for the same item received from other clients are discarded without further processing.When a client/server receives a confirm packet, it responds back with the actual data value to the requester.To demonstrate the above idea, we present a cache discovery example in Fig. 2 to determine the data access path to the client having the requested cached data or to the data source.Let us assume that MH i sends a request for a data item d x and MH k is located along the path through which the request travels to the data source MH s , where k∈{a, c, d}.The discovery process is described as follows: 1.When MH i needs d x , it first checks its own cache.If the data item is not available in its local cache (i.e., a local cache miss), it broadcasts a request packet to the mobile hosts in its zone (i.e., to MH j and MH a ).After MH i broadcasts the request, it waits for an acknowledgement.If it does not get any acknowledgement within a specified timeout period, it fails to get d x within home zone (i.e., zone cache miss).In case of any MH

Cache admission control
When a client receives the requested data, a cache admission control is triggered to decide whether it should be brought into the cache.Inserting a data item into the cache might not always be favorable because incorrect decision can lower the probability of cache hits [7].For example, replacing a data item that will be accessed soon with an item that will not be accessed in the near future degrades performance.In ZC, the cache admission control allows a host to cache a data item based on the distance of data source or other host that has the requested data.If the host or data source is ∆ hops away from the requesting host, then it does not cache the data; otherwise it caches the data item.For example, if the origin of the data item resides in the same zone of the requesting client i.e., ∆ = 1, then the item is not cached, because it is unnecessary to replicate data item in the same zone since cached data can be used by closely located hosts.In general, same data items are cached at least ∆ hops away.
A tradeoff exists between query latency and data accessibility.With a small ∆, the number of replicas for each data item is high and access delay for this data item is low.On the other hand, with a larger ∆, each data item has a small number of replicas, and the access delay can be little longer.Advantage is that mobile clients can cache more distinct data items and still serve requests when the data source is not accessible.However, if a network partition exists, many clients might not be able to access this data.

Cache consistency
Cache consistency issue must be addressed to ensure that clients only access valid states of the data.Problems related to cache consistency have been studied in many other systems such as multi-processor architectures, distributed file systems, distributed shared memory, and client-server database systems.Two widely used cache consistency models are the weak consistency and the strong consistency model.In the weak consistency model, a stale data might be returned to the client.In the strong consistency model, after a update completes, no stale copy of the modified data will be returned to the client.
Recently, we have done some work [15,16] on maintaining strong cache consistency in the one-hop based mobile environment.However, due to bandwidth and power constraints in ad hoc networks, it is too expensive to maintain strong consistency, and the weak consistency model is more attractive [6,7,9].The ZC caching uses a simple weak consistency model based on the time-to-live (TTL), in which a client considers a cached copy up-to-date if its TTL has not expired.The client removes the cached data when the TTL expires.A client refreshes a cached data item and its TTL if a fresh copy of the same data passes by.

Cache replacement policy
A cache replacement policy is required when a client wants to cache a data item, but the cache is full, and thus it needs to victimize a suitable subset of data items to evict from the cache.Cache replacement policies have been extensively studied in operating systems, virtual memory management and database buffer management.However, these algorithms might be unsuitable for ad hoc networks for several reasons [7]: -The data item size may not be fixed in ad hoc environment, the used replacement policy must handle data items of varying sizes.-The data item's transfer time might depend on the item's size and the distance between the requesting client and the data source (or cache).Consequently, the cache hit ratio might not be the most accurate measurement of a cache replacement policy's quality.-The replacement algorithm should also consider cache consistency, that is, data items that tend to be inconsistent earlier should be replaced earlier.

Utility based replacement
We have developed Least Utility Value (LUV) based cache replacement policy, where documents with the lowest utility are those that are removed from the cache.Four factors are considered while computing utility value of a data item at a client: Popularity.The access probability reflects the popularity of a data item for a host.An item with lower access probability should be chosen for replacement.At a host, the access probability A i for data item d i is given as Where a i is the mean access rate to data item d i .a i can be estimated by employing sliding window method of last K access times [29].We keep a sliding window of K most recent access timestamps (t 1 i , t 2 i , . . ., t K i ) for data item d i in the cache.The access rate is updated using the following formula: where t c is the current time and t K i is the timestamp of oldest access to item d i in the sliding window.When fewer than K samples are available, all the samples are used to estimate a i .To reduce the computational complexity, the access rates for all cached items are not updated during each replacement, rather the access rate for an item is updated only when the item is accessed.K can be as small as two or three to achieve the best performance [29].During simulation experiments, we have used K = 2, thus the spatial overhead to store recent access timestamps is relatively small.
Distance.Distance (δ) is measured as the number of hops between the requesting client and the responding client (data source or cache).This policy incorporates the distance as an important parameter in selecting a victim for replacement.The greater the distance, the greater is the utility value of the data item.This is because caching data items which are further away, saves bandwidth and reduces latency for subsequent requests.
Coherency.A data item d i is valid for a limited lifetime, which is known using the TTL i field.An item which is valid for shorter period should be preferred for replacement.
Size (s).A data item with larger data size should be chosen for replacement, because the cache can accommodate more data items and satisfy more access requests.
Based on the above factors, the utility i function for a data item d i is computed using the following expression: The idea is to maximize the total utility value for the data items kept in the cache.For a cache of size C such that the size s i of each data item d i is very much less than C, the principle of optimality implies that the mobile client MH x should always retain a set C x of data items in its cache such that is maximized subject to The optimization problem defined by the objective functions Eqs (3) and ( 4) is termed as ad hoc caching problem.

NP-Hardness
Here we will prove that ad hoc caching problem is NP-hard.

Definition 1. ADCACHE (ad hoc caching problem)
Instance: Given a set of data items D such that for each item d i ∈D, a size s i > 0 and utility utility i > 0. Also given that cache capacity of each client is C.
Question: Find a cache set C x ⊂D for client MH x that maximizes Proof.The proof follows transformation from 0/1 Knapsack problem [28] that is known as NPcomplete problem.The instance and question of 0/1 Knapsack are presented as follows: Definition 2. KNAPSACK (0/1 Knapsack problem) Instance: Given a set of items Itemset = {item 1 , item 2 , . . ., item n }, such that each item item i is associated with a value v i > 0 and weight w i > 0.
Question: Select a set of items from Itemset (denoted by Selectset) that maximizes The KNAPSACK can be transformed into ADCACHE by mapping W to C, Itemset to D, Selectset to C x , v i to utility i and w i to s i .By solving ADCACHE, we get utility i and the size of items in the cache Therefore, the KNAPSACK can be solved by solving ADCACHE.Hence, the ADCACHE is NP-hard.

Implementation issues
Maximizing the objective function defined by Eqs (3) and ( 4) implies a minimization of the response time per reference.The task of LUV is to make this optimal decision for every replacement.When the data size is relatively small compared to the cache size [28], we can use heuristics to obtain sub-optimal solutions.The heuristic we use is: through out the cached data item d i with the minimum utility i /s i value until the free cache space is sufficient to accommodate the incoming data.A binary min-heap [28] data structure is used to implement the LUV policy.The key field for the heap is the utility i /s i value for each cached data item d i .When the events of cache replacement occur, the root item of the heap is deleted.This operation is repeated until sufficient space is obtained for the incoming data item.Let N c denotes the number of cached items and N v the victim set size.Every deletion operation has a complexity of O(logN c ).An insertion operation also has a O(logN c ) complexity.Thus the time complexity for every cache replacement operation is O(N v logN c ).In addition, when an item's utility value is updated, its position in the heap needs to be adjusted.The time complexity for every adjustment operation is O(logN c ).In most of the cases, the maximum value of N v is three.Therefore, the overall time complexity of LUV is O( logN c ).

Analytical model
To analyze the performance of the proposed ZC caching technique, we develop an analytical model.The performance is measured with the following metrics: 1.Average number of hops a request is expected to travel before it reaches the data cache/source.Reducing the hop count can reduce the query latency, bandwidth and the power consumption since fewer clients are involved in the query process [6].Reduction in the hop count can also alleviate the load at data source since some of the requests are satisfied by the cache.2. Average query latency is the time elapsed between the query is sent and the data is transmitted back to the requester averaged upon all the successful queries.
Table 1 shows the symbols and notations used in the analysis.For each client request, four cases (local hit, zone hit, remote hit or global hit) are possible to retrieve the requested data item as described in Section 4. To compute the number of hops L j and query latency T j for retrieving the data item d j by client MH i , the probability of data hit for each case along with number of hops is shown below: So, L j is given as The Eq. ( 5) above can be explained as follows.When there is a local cache hit, the requested data item d j can be retrieved locally (0 hops) at client MH i with a probability P ij .In case of zone hit (1 hop distance from the requester) the access probability is 1 − (1 − P ij ) ρπr 2 −1 .When there is a remote data hit, the item is retrieved from a client lying on a zone (other than home zone of the requester) along the routing path at a distance of k hops from the requester with a probability If none of the clients has cached the requested item d j , it is retrieved from the data server (global hit) with a probability (1 To simplify the model, assume that P is the probability that a data item is cached by an MH.The average number of hops (L avg ) is given as This equation is an approximation of L avg since in practice P may differ for different data items.
If there is no cooperation within a zone i.e., a client does not share caches with its one-hop neighbors, then ρπr 2 = 1.The average number of hops becomes The Eq. ( 7) above is same as developed for CacheData scheme in [6,23].Query latency is given as follows: Similar to the explanation of Eq. ( 5) described above, the Eq. ( 8) can be justified.
The effect of data popularity, node density and transmission range can be studied by varying the values of P, ρ and r respectively in Eqs ( 6) and (9).

Performance analysis
In this section, we evaluate the performance of ZC caching through simulation experiments under LUV and LRU replacements.

Simulation model
During the simulation AODV [5] has been used as underlying routing algorithm.The node density is changed by choosing the number of nodes between 50 and 100 in a fixed area.The wireless bandwidth is assumed to be 2 Mbps with transmission range of 250 m.

Client model
The time interval between two consecutive queries generated from each client follows an exponential distribution with mean T q .Each client generates a single stream of read-only queries.After a query is sent out the client does not generate new query until the pending query is served.Each client generates accesses to the data items following Zipf distribution [27] with a skewness parameter θ.In Zipf distribution, the access probability of the i th (1 i N) data item is represented as follows If θ = 0, clients uniformly access the data items.As θ is increasing, the access to the data items becomes more skewed.Similar to other studies [6,8] we chose θ to be 0.8.
The simulation area is assumed of size 1500 m × 1500 m.The clients move according to the random waypoint model.Initially, the clients are randomly distributed in the area.Each client selects a random destination and moves towards the destination with a speed selected randomly from [v min , v max ].After the client reaches its destination it pauses for a period of time and repeats this movement pattern.
The access pattern of mobile clients can be location dependent, that is, clients that are around the same location tend to access similar data.In order to model this kind of access pattern, the whole network area is equally divided into 5 × 5 square grids.These grids are named grid 1, 2, . . ., 25 in a column wise fashion as shown in Fig. 3.The clients in the same grid have the same Zipf data popularity and clients in different grids have different shift values for the Zipf pattern.For a client in grid i, the id of data access is shifted by i so that id = (id + i)mod N.This access pattern ensures that clients in neighboring grids have similar, although not same, access pattern.

Server model
The data server is placed at center of network area i.e., at location (750 m, 750 m).There are N data items at the server.Data item sizes vary from s min to s max such that size s i of item d i is, (s max − s min + 1) , i = 1, 2, . . .N, where random( ) is a random function uniformly distributed between 0 and 1.The data are updated only by the server.The server serves the requests on FCFS (first-come-first-serve) basis.When the server sends a data item to a client, it sends the TTL value along with the data.The TTL value is set exponentially with a mean value.After the TTL expires, the client has to get the new version of the data item either from the server or from other client (having maintained the data item in its cache) before serving the query.
The system parameters are given in Table 2.During the simulation, the parameters are changed to study their impacts.

Simulation metrics
We evaluate two performance parameters here: average query latency (T avg ), and cache hit ratio including local cache hit (H local ), zone cache hit (H zone ) and remote cache hit (H remote ).The average query latency (T avg ) is the time elapsed between the query is sent and the data is transmitted back to the requester.Hit ratio is used as a measure of the efficiency of the cache management.
If n local , n zone and n remote denotes the number of local hits, zone hits and remote hits respectively out of total n total requests, then H local = n local /n total × 100%, H zone = n zone /n total × 100%, and H remote = n remote /n total × 100%

Simulation results
Here we examine the impact of different workload parameters such as cache size, query generate time, node density and ∆ on the performance of proposed ZC caching strategy.To demonstrate the effectiveness of LUV policy, we compare the ZC scheme under LUV replacement and LRU based replacement.

Effects of cache size
Figure 4 shows the effect of cache size on the hit ratio and query latency by varying the cache size from 200 KB to 1400 KB.The cache hit comprises of local hit, zone hit and remote hit. Figure 4a shows that the local cache hit increases with the increasing cache size because with large cache size more data can be shared locally.The local hit ratio for LRU policy is always lower.LUV policy considers the data size during replacement therefore more items may be cached thus improving the hit ratio.As the cache size increases, the improvement of LUV over LRU becomes more significant.This implies that LUV can utilize the cache space more efficiently.Due to sharing of data among one-hop neighbors, the zone hit and remote hit also improve with the cache size.From Fig. 4b, we can see that the proposed LUV policy performs much better than LRU policy.As the cache size increases more data can be found in local + zone cache, thus, the need for accessing the remote and global cache alleviated.Because the hop count of zone data hit is one and is lower than the average hop count of remote/global data hit, the query latency decreases.As the cache size is large enough, the MHs can access most of the required data items from local and zone cache, so it reduces query latency.
Comparing these two policies, we can see that LUV performs much better than LRU.Because of high overall hit ratio, LUV achieves the best performance compared to LRU at all cache sizes.

Effects of query generate time
Figure 5 shows the effect of mean query generate time T q .At small T q , more queries are generated and hence more cache replacements take place.Higher number of cache replacements at lower T q increases the number of cache misses at a client.This results in low cache hit ratio at small T q .The LUV based replacement behaves better than LRU as LUV is more realistic for ad hoc environment.The cache hit ratio improves with an increase in T q because of lower number of generated queries and hence number of replacements decreases.At very large value of T q , the cache hit ratio is low because query generate rate is so low that the number of cached data is small and many cached data items are not usable because their TTL have already expired before queries are generated for them.Figure 5a verifies this trend.
Figure 5b shows the average query latency as a function of the mean generate time T q .At small value of T q , the query generate rate is high and system workload is more.This results in high value of average query latency.When T q increases, less queries are generated and average query latency drops.If T q keeps increasing, the average query latency drops slowly or even increases slightly due to decrease in  cache hit ratio.Under extreme high T q , most of the queries are served by the remote data server and both the replacement policies perform similarly.

Effects of node density
We vary the number of mobile nodes from 50 to 100 in network area to study the performance under different node densities.As shown in Fig. 6a, the LUV based replacement has better local hit ratio than LRU policy at all the node densities.When the node density is high, the number of MHs in a cooperation zone increases which leads to an improvement in zone hit ratio and remote hit ratio.LUV also performs better than LRU in terms of zone and remote hit under different node densities.
Figure 6b shows the average query latency as a function of the node density.As node density increases, the latency increases because more nodes compete for limited bandwidth.The query latency for LRU ∆ (hops) policy increases much faster than LUV.This can be explained by the fact that LUV considers various factors to make more intelligent replacement decision.

Effects of admission control
In this subsection, we evaluate the replacement policies in terms of admission control.We examine the effect of parameter ∆ that determines which data item can be cached.Although a high ∆ value enables more data items to be distributed over the MANET, so that more distinct items will be cached, the average query latency will increase.Figure 7b verified this trend.
In Fig. 7a, local cache hit ratio decreases with increase in ∆ because an item will be cached at a client only if no neighbor of the client at distance lower than ∆ hops have cached it.Due to caching of distinct items by neighboring clients, there is improvement in zone and remote cache hit with increasing ∆.The decrease in local cache hit ratio causes higher average query latency with increasing ∆.

Conclusions
This paper presents LUV based replacement policy for ZC caching scheme in mobile ad hoc networks.The ZC scheme enables clients in a zone to share their data which helps alleviate the longer average query latency and limited data accessibility problems in ad hoc networks.An analytical model of ZC is also developed.The LUV policy considers several factors such as access probability, distance between the requester and data source/cache, coherency and data size, and thus is more realistic for cooperative caching in ad hoc networks.A simulation based performance study was conducted to evaluate the ZC scheme under LUV and LRU policies.Results show that the ZC caching scheme with LUV policy performs better in terms of cache hit ratio and average query latency in comparison with LRU policy.Our future work includes development of a cooperative caching scheme where each client has cache state information within a zone so that replacement is performed on unified zone cache rather than single local cache.

Fig. 1 .
Fig. 1.Service of a client request by ZC caching strategy.

Fig. 2 .
Fig. 2. A request packet from client MHi is forwarded to the data source MHs.

Theorem 2 .
If P is the probability of cache hit at a client, then the probability of cache hit in a cooperation zone is 1 − (1 − P ) ρπr 2 −1 .Proof.Area of a cooperation zone = πr 2 Number of nodes in a cooperation zone, N zone = ρπr 2 Number of nodes contributing for zone hit (i.e., number of one-hop neighbors of a node) = ρπr 2 − 1 Probability of cache miss for a node = (1 − P ) Probability of cache miss in a zone = (1 − P ) ρπr 2 −1 Probability of cache hit in a cooperation zone = 1 − (1 − P ) ρπr 2 −1

Fig. 5 .Fig. 6 .
Fig. 5. Effect of mean query generate time on cache hit ratio and average query latency.

Fig. 7 .
Fig. 7. Effect of ∆ on cache hit ratio and average query latency.
1 i (MH j or MH a ) has the data item d x , it sends ack packet to MH i .2.When MH k receives a request packet, it broadcasts the packet to MH 1 k (i.e., mobile hosts in the zone of MH k ) if it does not have d x in its local cache.When MH k receives an ack packet, it sends a confirm packet to the ack packet sender.There may be additional ack packets received by MH k from other hosts in its zone and are discarded as it has already received an ack packet from a host closer to it.3.When MH 1i /MH 1 k /MH s receives a confirm packet, it sends the reply packet to the requester.The reply packet containing item id d x , actual data D x and TTL x , is forwarded hop-by-hop along the routing path until it reaches the original requester.

Table 1
Symbols used in the analysis