Collaborative caching discovery management in mobile ad hoc networks environments

Related works

There is a number of studies focusing in the area of mobile computing particularly in collaborative caching. This is in addition to the fact that there are a number of recent research studies still investigating the current performance and future possibilities of collaborative caching technologies in MANETs to enhance queries severing (Artail et al., 2008; Yin & Cao, 2005; Du, Gupta & Varsamopoulos, 2009; Safa, Deriane & Artail, 2011). Serving queries on mobility environments is an important topic of this research. The query is mostly processed on locally at the node the initiated the query. This allowing for real-time updates while lowering the burden on database servers.

Effective cache resolution techniques were developed to resolve the cached data request which uses a split table approach (Joy & Jacob, 2013) and copies of data packet using replication mechanism to improve data availability and packet loss during network traffic (Sridevi, Komarapalayam & Kamaraj, 2020). The main objective of these approaches is to reduce latency, to lessen flooding and network traffic, and to avoid the drawback of group maintenance by having a distributed approach. Zone Cooperative (ZC) approach is proposed to consider the progress of data discovery (Umamaheswari & Radhamani, 2015). In this approach, the nodes at the same cluster range form a collaborative caching since a zone transmission range is formed based on a set of one hop neighbors (Elfaki et al., 2019). Each node consisted of a local cache to store frequency access data not only for own request satisfaction, but also for other nodes data request satisfaction that go over it. Once the data on the server side is updated, the cached copies on the nodes become invalid. If a data miss in the local cache, the node first checks the requested data items in its zone before forwarding the request to the next node that lies on a path towards server (Elfaki et al., 2019). However, the latency may become longer if the requested data item is missed at intermediate neighbor’s nodes. Moreover, there are also a number of research studies developed a cooperative caching strategy to improve data access, data availability, and information retrieval in MANETs (Artail et al., 2008; Yin & Cao, 2005; Du, Gupta & Varsamopoulos, 2009; Wang et al., 2022) propose two strategies: CacheData and CachePath, as well as a hybrid strategy that combines the two techniques to increase the performance by utilizing both strategies meanwhile taking into consideration their drawbacks and limitations. Cache resolution and cache management are designed by Du, Gupta & Varsamopoulos (2009) to increase the data availability and the access efficiency. For management issues, eliminating caching replicas is applied within the collaborative range where many data diversities are accommodated. For cache resolution, two measurements are used to evaluate the performance: average latency and energy cost per-query (Du, Gupta & Varsamopoulos, 2009). However, flooding is a drawback of the strategy, as it adds extra cache discovery overhead (Kumar et al., 2010). El Khawaga, Saleh & Ali (2016) developed an adaptive cooperative caching strategy (ACCS) approach to minimize pending and query delay in MANETs. The originality of this approach is to concentrate on cache replacement and prefetching policies. ACCS is build based on table driven routing strategy without additional penalties. This approach involves gathering routing information during cluster formation and then populating the routing tables accordingly, such behavior significantly minimizing the query delay. However, this approach concerning more about prefetching policies rather than cache discovery which it works with real time requests.

The scheme proposed by Fiore, Casetti & Chiasserini (2011) aims to consider all the information of each group zone of the MANET as a whole. Their scheme investigates both cases of nodes with large and small cache sizes. In this scheme, nodes are allowed to decide which documents to cache and for how long this document will be cached. In Ting & Chang (2013), a group-based cooperative caching scheme (GCC) is achieved. Basically, this scheme is based on the concept of group caching where each mobile host and its k-hop neighbors are allowed to form a group. Each mobile host maintained a directory of cached data items. Each mobile node (MN) broadcasts message in the group to obtain the directories of its k-hop group members. However, in this technique the overhead might be generated by mobile host’s requests (Larbi, Bouallouche-Medjkoune & Aissani, 2018).

Advance collaborative caching is developed by Artail et al. (2008) to address the constraints of the technique proposed by Yin & Cao (2005). The initiated queries are indexing to help in locating the needed data items according to Artail et al. (2008), Lilly Sheeba & Yogesh (2011), Sheeba & Yogesh (2020), Lilly Sheeba & Yogesh (2017) and Sheeba & Yogesh (2020) studies. In a cooperative and adaptive system (COACS) which is developed by Artail et al. (2008), nodes can play one of the two roles: caching node (CN) or query directory (QD). CN is in charge of caching data items (responses to requests), whereas QD is in charge of caching requests provided by requesting mobile nodes. In the COACS methodology, there are two methods for locating data objects. First, if the query is not served locally within the system, the query goes across number of QDs before being forwarded to the database server. Second, before matching one of these QDs’ nodes, the request traverses the list of QD nodes. Although COACS solves the limitations and drawbacks of the approach which described by Yin & Cao (2005), an ideal approach to optimize request processing is still needed. Once the number of requests traversed inside the QDs grows in COACS (Safa, Deriane & Artail, 2011), and the quires failed to be served in the system, the latency and bandwidth consumption increase too. As a result, this technique is ineffective, particularly for requests that require immediate attention and response. Therefore, the majority of the previous approaches are relaying on broadcasting messages, flooding, and hop-by-hop discovery for fetching the required data items rather than increasing the cooperation at the local cache level. Furthermore, requesting data items using broadcasting messages, flooding, and hop-by-hop add penalties on the scattered bandwidths which may increase the delay for fetching the required data items and increase the number of pending for the required data items (Elfaki et al., 2019).

The proposed collaborative caching discovery management (CCD)

The proposed CCD approach was build-up based on five possible scenarios which are identified in Elfaki et al. (2014) and described in Fig. 1. The load balancing algorithm has taken place to increase the number of replied queries and decreased the number of pending one. This algorithm also plays an important role for serving queries since there are more than data sources possible which are described via the following scenarios. In CCD, a requested node (RN) submits a query based on two classifications either priority or normal, as determined by RN. The first scenario occurs when the data item is not locally available at RN’s cache. The RN checks its recent priority table (RPT) and retrieves the required data if it is available within neighbouring nodes. The data item is retrieved from the neighbour node, which can be discovered by referring to RN’s RPT. If the cached data item information is not found in the RN’s RPT, the query will be sent to the cluster header (CH) if the query is priority. The second scenario occurs when the data item and its cached information are not found in the local cache and the RPT of the requested node respectively. Therefore, the RN refers to its CH and retrieves the required data item. In the third scenario, the query is sent to the CH of RN when the data item is not found in the RN’s local cache and its information is not indexed in the RN’s RPT as well as is not found at the RN’s CH. The CH forwards the query to the node having the data item within the cluster range which is known as cluster’s cache hit. When RN initiated a priority query and the required data item not cached locally or in the cluster, the CH of RN directs the query to the database server, which it turns response directly to the RN in the fourth scenario. In the fifth scenario, RN initiated a normal query where the requested data item is not found at the cluster zone. The query is sent to the database server along with the RN address and the required data item is sent to the RN that if the required data item is missed at neighbour’s CH level and all CHs visited.

In MANETs, serving query is a critical issue, since it may require to travel from one end of the network to reach the source node, where the required data item is send back over the network to the RN (Artail et al., 2008; Idris, Artail & Safa, 2005). This increases the number pending queries, and average query latency. Therefore, the proposed CCD implement minimum distance packet forwarding (MDPF) algorithm which similar algorithm that is used in Artail et al. (2008) and Idris, Artail & Safa (2005). This algorithm is basically designed to explore and determine the nearest neighbour nodes. To minimize the travelling in serving queries in MANET’s environment, the proposed CCD approach classified the query either priority or normal as some queries require immediate response. As well as, nodes within same cluster share their cached data information. Thus, the CH and cache node (CN) are able to index more information of cached data within the cluster range. This facilitates in determining the destination of the query. Furthermore, a list of visited destination is maintained with the traversed packet to avoid misdirection a query to a node which has been visited already in case if the query is normal. This also plays an important role for minimizing the number of pending queries and increasing the number of replying queries with less average delay. This is because of increasing the level of collaboration at the local cache among the neighbour nodes that are located in the same cluster zone. The mobile nodes are allocated geographically adjacent into the same cluster according to some rules that are distance and similar interests. This research did not develop a new cluster algorithm but applied the existing cluster algorithms as in Chatterjee, Das & Turgut (2002), Younis & Fahmy (2004) and Yu & Chong (2005).

CCD system model

The CCD simulation model setup contains a number of clusters, C = {c1, c2, …, cn} and every cluster has a CH, a database server where each CH has a direct link to it via an access point, and a number of mobile nodes, MN = {MN1, MN2, …, MNm} where some nodes act as requested nodes (RNs) or cache nodes (CNs), while others act as RN and CN simultaneously. There are two main modules in the simulation model, namely: MN module and CH module as illustrated in Fig. 2. In MN, there are five subcomponents which are: (1) query classifier. This subcomponent is responsible to differentiate the service of a requested node’s query based on the query classification. Hence, queries are coordinated to a particular data source. (2) Node profile stores the node address which is used as an identifier of a node, node type, and node capacity. (3) Local cache, which is used to cache the node owns data items. (4) RPT, which is responsible to record the information of the cached data item for neighbouring nodes. (5) Data item stage locater, which is used to discover the required data items at a particular data source.

On the other hand, the CH module consists of: (1) query coordinator, which is responsible for coordinating and controlling the forwarding requests based on their classifications. (2) Cluster header profile, stores the cluster header address which is used as an identifier of a cluster header and its capacity. (3) Local cache, which is used to cache the cluster header owns data items. (4) Index table, which is used to track nodes entering and leaving a cluster range for updating purposes. (5) Neighbour’s cluster cached information table, which records the neighbour clusters cached data item information to determine the next hop to forward queries. (6) Cache nodes table, which is utilized to allow CH to index nodes’ addresses and their cached data item information within a cluster range. (7) Data item stage locater, which is used to locate the required data items via cluster header.

Cluster header

The cluster header is a reasonable of coordinating nodes within the same cluster range, which is known as intra-cluster coordination. The cluster header is also in charge of communicating with other clusters and the external network on behalf of the cluster members. Furthermore, the cluster header is in charge of deciding whether to direct and coordinate queries to a specific data source, particularly if the requested data item is missing within the cluster. The decision to direct queries to a specific data source is dependent on the query classification, which is priority or normal, as well as the availability of the requested data item at the local cache or the availability of cached data item information at RPT and CH (Elfaki et al., 2014). Furthermore, by include an index in each node and cluster header, information is shared across mobile nodes within the same cluster as well as between clusters. This can reduce cache discovery overheads, decrease pending requests, and increase the replied one as well as the level of collaboration among neighbor nodes.

Cluster member

A cluster member is a regular node that is not a cluster header node. Each mobile node broadcasts a hello message to other nodes in the same cluster, including its ID and cached data item metadata. Each mobile node collects topology information for its cluster using this hello message. In the proposed approach, each mobile node has a local cache area and an RPT for indexing the cached data item information of its neighbors, and it is directly connected to the cluster header (Elfaki et al., 2014).

Database server

A database server is a location where original data items are recorded and organized. The database server is implemented as a fixed node in the proposed framework. Cluster headers able to access the database server via an access point (Elfaki et al., 2014).

Wireless connection

The wireless component is used in the module to serve as a communication link between mobile nodes and the entire network. As a result, mobile nodes connect with one another over a variety of wireless channels (Elfaki et al., 2014).

Data item stage locater

The stage of locating a required data items in the proposed approach is illustrated in Fig. 3. The required data item is checked first at the node local cache. In case the required data item is missed locally, the RPT is checked for required data item information. If a match is found at the RPT, the query is forwarded to the particular neighbor’s node. When the required data item is missed locally and also at the RPT, the query is directed to the CH. The CH coordinates and redirects the query to an exact data source according to the query classification either normal or priority. This is performed when the request is missed at the CH’s cache. The data source can be a mobile node within the cluster zone, CH of the requested mobile node, a mobile node in the neighbor cluster or a database server.

Figure 4 shows an example of a cached data discovery in CCD. In this figure, nodes are grouped in cluster based on the same interest and distance. As mentioned in the previous section, each node cached its own data items along with the indexed data items information of its neighbor nodes at the RPT. In Fig. 4, N1 holds data items D2 and D3; N2 requests for D2 and D2 is not available at its cache, but N2 knows that N1 has D2 since N1 and N2 have shared their cached data item information earlier during the neighborhood formation. Since D2 is cached by N1, which is one (1) hop distance from N2, then N2 stores a copy of D2 from N1. If N6 requests a normal request for D7, which is located in a different cluster, the cluster header CH2 will request the D7 from its neighbor cluster.

The decision of classifying a query as priority or normal is specified by the requested node which is N6 in the example. The CH2 forwarded the N6′s query to its neighbor cluster header which is CH1. The CH1 checks its index for the corresponding data item for N6′s query. If the required data item is found, the CH1 forwards the query along with N6 address to the node that cached the corresponding data item which is N3 in the provided example. On the other hand, if the query is priority and the required data item is not found within the cluster of the requested node say N5, the CH2 redirects the query to the database server to serve the query to avoid any delay. Furthermore, by enabling a query to be served according to its classification, cache discovery overhead will be reduced, since a query is guided to a particular data source.

The load balancing algorithm in serving queries

To reduce the number of pending queries and increase the number of answering queries, a load balancing algorithm is developed to distribute sending queries across multiple data sources. Since there are more than one data sources to serve queries with the required data items, an objective would be to reduce the number of pending queries that is handled by each node without affecting the performance of the proposed approach. In the proposed approach, queries are initiated randomly and forwarded to multiple data sources. These queries are initiated by any node in the network, which is called RN. An RN has a list of neighbour nodes to forward queries. These neighbour nodes are located one hop farther from the RN. At the cluster header level, MDPF is used to discover the nearest CH to serve the query. Tables 1 and 2 provide the symbols and the functions, respectively which are used in the load balancing algorithm that is presented in algorithm 1. In the figure, each neighbour node i for a particular RN is scan (line 2). This is followed by checking the information of each data item d that is cached in a neighbour node i (line 3). If the information of the data item d that is listed in the neighbour node i matched with the information of the initiated query R (line 4), the neighbor node i is added to the list of the neighbor nodes, that having the required data item (line 5). This is followed by incrementing the number of neighbour nodes that having the required data item (line 6). Furthermore, once the neighbour nodes having the required data item are determined (line 10), a neighbour node is randomly selected to serve the query R (line 11), using division and counting functions. Once the selection is made, the query R is sent to the selected neighbour node to serve the query R with the data item d (line 12), and the process is ended (line 13).

Performance evaluation

The NS-2 simulator software along with the Carnegie Mellon University (CMU) wireless extension (https://www.isi.edu/nsnam) was used to implement the proposed CCD and COACS (Artail et al., 2008) approaches. The destination sequenced distance vector (DSDV) is used as the primary routing protocol. For wireless bandwidth and transmission range, 2 Mbps and 100 m, are used respectively in this study. The mobile nodes are distributed randomly following the random way point model (RWP) movement. Moreover, the proposed CCD approach’s simulation implementation area is 1,000 m ×1,000 m, and the link to the external source is established via the assess point (AP). The simulation setting is established in the way nodes initially are randomly dispersed, whereby each node has a random destination that moves at a random speed towards the data sources locations. The nodes speeds are set to 0.01 m/s and 2.00 m/s for lowest and highest respectively, and the pause time is set to 100s in the simulation configuration. However, as a caused of network high mobility, this study shows a scenario with a maximum velocity of 20 m/s and an average velocity of 13.8 m/s. The data source link’s latency is set to 40 m/s, which is a relatively low speed according to Curran and Duffy’s criteria (Artail et al., 2008). Table 3 lists the remaining simulation parameters, along with their corresponding values. These are the same parameters as are used in COAC approach.

The simulation square is divided into 25 clusters, each measuring 200 m ×200 m. The number of clusters is dynamic, which is consistent with the same QDs number setting in COACS (Artail et al., 2008). Zipf pattern access and offset values are used for nodes within the cluster and out of it, respectively. If a node in cluster x made a Zipf-like to required data item ID, the new ID would be (ID+ nq mod (x)) mod (nq), where nq is the database size, ID is a unique ID for a specific data item, and x is the cluster range (Artail et al., 2008). This access pattern is used to ensure that nodes in the same range have similar interests, even if their access patterns are different. Each node is set to wait for a specified amount of time, which is equal to one second, before sending the same query again under the time out policy. After 10 s, a node sends a fresh query, if it has not received the needed data. Moreover, the CCD technique used applied algorithms called least Recently Used (LRU) to replaces old data items with new requested data items if there isn’t enough capacity to cache the new one. Furthermore, time-to-live (TTL) is taken into account in this study to determined expired data items to be eliminated and replaced with new one.