SSUM: Smart Server Update Mechanism

for Maintaining Cache Consistency

in Mobile Environments
Khaleel Mershad and Hassan Artail, Senior Member, IEEE
AbstractThis paper proposes a cache consistency scheme based on a previously proposed architecture for caching database data
in MANETs. The original scheme for data caching stores the queries that are submitted by requesting nodes in special nodes, called
query directories (QDs), and uses these queries to locate the data (responses) that are stored in the nodes that requested them, called
caching nodes (CNs). The consistency scheme is server-based in which control mechanisms are implemented to adapt the process of
caching a data item and updating it by the server to its popularity and its data update rate at the server. The system implements
methods to handle disconnections of QD and CN nodes from the network and to control how the cache of each node is updated or
discarded when it returns to the network. Estimates for the average response time of node requests and the average node bandwidth
utilization are derived in order to determine the gains (or costs) of employing our scheme in the MANET. Moreover, ns2 simulations
were performed to measure several parameters, like the average data request response time, cache update delay, hit ratio, and
bandwidth utilization. The results demonstrate the advantage of the proposed scheme over existing systems.
Index TermsData caching, cache consistency, invalidation, server-based approach, MANET.

1 INTRODUCTION
I
N a mobile ad hoc network (MANET), data caching is
essential as it reduces contention in the network,
increases the probability of nodes getting desired data,
and improves system performance [1], [5]. The major issue
that faces cache management is the maintenance of data
consistency between the client cache and the server [5]. In a
MANET, all messages sent between the server and the
cache are subject to network delays, thus, impeding
consistency by download delays that are considerably
noticeable and more severe in wireless mobile devices.
All cache consistency algorithms are developed with the
same goal in mind: to increase the probability of serving
data items from the cache that are identical to those on the
server. A large number of such algorithms have been
proposed in the literature, and they fall into three groups:
server invalidation, client polling, and time to live (TTL).
With server invalidation, the server sends a report upon
each update to the client. Two examples are the Piggyback
server invalidation [19] and the Invalidation report [31]
mechanisms. In client polling, like the Piggyback cache
validation of [20], a validation request is initiated according
to a schedule. If the copy is up to date, the server informs
the client that the data have not been modified; else the
update is sent to the client. Finally, with TTL algorithms, a
server-assigned TTL value (e.g., T) is stored alongside each
data item d in the cache. The data d are considered valid
until T time units pass since the cache update. Usually, the
first request for d submitted by a client after the TTL
expiration will be treated as a miss and will cause a trip to
the server to fetch a fresh copy of d. Many algorithms were
proposed to determine TTL values, including the fixed TTL
approach [17], adaptive TTL [11], and Squids LM-factor
[29]. TTL-based consistency algorithms are popular due to
their simplicity, sufficiently good performance, and flex-
ibility to assign TTL values for individual data items [4].
However, TTL-based algorithms, like client polling algo-
rithms, are weakly consistent, in contrast to server invalida-
tion schemes that are generally strongly consistent.
According to [11], with strong consistency algorithms,
users are served strictly fresh data items, while with weak
algorithms, there is a possibility that users may get
inconsistent (stale) copies of the data.
This work describes a server-based scheme implemen-
ted on top of the COACS caching architecture we proposed
in [2]. In COACS, elected query directory (QD) nodes cache
submitted queries and use them as indexes to data stored
in the nodes that initially requested them (CN nodes). Since
COACS did not implement a consistency strategy, the
system described in this paper fills that void and adds
several improvements: 1) enabling the server to be aware of
the cache distribution in the MANET, 2) making the cached
data items consistent with their version at the server, and
3) adapting the cache update process to the data update
rate at the server relative to the request rate by the clients.
With these changes, the overall design provides a complete
caching system in which the server sends to the clients
selective updates that adapt to their needs and reduces the
average query response time.
Next, Section 2 describes the proposed system while
Section 3 analyzes its performance using key measures.
Section 4 discusses the experimental results, and Section 5
778 IEEE TRANSACTIONS ON MOBILE COMPUTING, VOL. 9, NO. 6, JUNE 2010
. The authors are with the Electrical and Computer Engineering Depart-
ment, American University of Beirut, PO Box 11-0236, Riad El-Solh,
Beirut 1107-2020, Lebanon. E-mail: {kwm03, hartail}@aub.edu.lb.
Manuscript received 27 Mar. 2009; revised 15 Sept. 2009; accepted 12 Oct.
2009; published online 11 Jan. 2010.
For information on obtaining reprints of this article, please send e-mail to:
tmc@computer.org, and reference IEEECS Log Number TMC-2009-03-0102.
Digital Object Identifier no. 10.1109/TMC.2010.18.
1536-1233/10/$26.00 2010 IEEE Published by the IEEE CS, CASS, ComSoc, IES, & SPS
Authorized licensed use limited to: muthu m. Downloaded on June 27,2010 at 05:45:28 UTC from IEEE Xplore. Restrictions apply.
reviews some previous cache consistency techniques before
concluding the paper in Section 6.
2 SMART SERVER UPDATE MECHANISM (SSUM)
SSUM is a server-based approach that avoids many issues
associated with push-based cache consistency approaches.
Specifically, traditional server-based schemes are not
usually aware of what data items are currently cached, as
they might have been replaced or deleted from the network
due to node disconnections. Also, if the server data update
rate is high relative to the nodes request rate, unnecessary
network traffic would be generated, which could increase
packet dropout rate and cause longer delays in answering
node queries. SSUM reduces wireless traffic by tuning the
cache update rate to the request rate for the cached data.
2.1 Basic Operations
Before detailing the operations of SSUM, we list in Table 1
the messages used in the COACS architecture as we refer to
them in the paper. Given that no consistency mechanism
was implemented in COACS, it was necessary to introduce
four additional messages.
In SSUM, the server autonomously sends data updates to
the CNs, meaning that it has to keep track of which CNs
cache which data items. This can be done using a simple
table in which an entry consists of the id of a data item (or
query) and the address of the CN that caches the data. A
node that desires a data item sends its request to its nearest
QD. If this QD finds the query in its cache, it forwards the
request to the CN caching the item, which, in turn, sends
the item to the requesting node (RN). Otherwise, it
forwards it to its nearest QD, which has not received the
request yet. If the request traverses all QDs without being
found, a miss occurs and it gets forwarded to the server
which sends the data item to the RN. In the latter case, after
the RN receives the confirmation from the last traversed QD
that it has cached the query, it becomes a CN for this data
item and associates the address of this QD with the item
and then sends a Server Cache Update Packet (SCUP) to the
server, which, in turn, adds the CNs address to the data
item in its memory. This setup allows the server to send
updates to the CNs directly whenever the data items are
updated. Fig. 1 illustrates few data request and update
scenarios that are described below.
In the figure, the requesting nodes (RNs) submit queries
to their nearest QDs, as shown in the cases of RN
1
, RN
2
, and
RN
3
. The query of RN
1
was found in QD
1
, and so the latter
forwarded the request to CN
1
, which returned the data
directly to the RN. However, the query of RN
2
was not
found in any of the QDs, which prompted the last searched
(QD
1
) to forward the request to the server, which, in turn,
replied to RN
2
that became a CN for this data afterward.
The figure also shows data updates (key data pairs) sent
from the server to some of the CNs.
MERSHAD AND ARTAIL: SSUM: SMART SERVER UPDATE MECHANISM FOR MAINTAINING CACHE CONSISTENCY IN MOBILE... 779
TABLE 1
Packets Used in COACS After Integrating SSUM into It
Fig. 1. Scenarios for requesting and getting data in the COACS
architecture.
Authorized licensed use limited to: muthu m. Downloaded on June 27,2010 at 05:45:28 UTC from IEEE Xplore. Restrictions apply.
2.2 Dealing with Query Replacements and Node
Disconnections
A potential issue concerns the server sending the CN
updates for data that have been deleted (replaced), or
sending the data out to a CN that has gone offline. To avoid
this and reduce network traffic, cache updates can be
stopped by sending the server Remove Update Entry Packets
(RUEPs). This could occur in several scenarios. For
example, if a CN leaves the network, the QD, which first
tries to forward it a request and fails, will set the addresses
of all queries whose items are cached by this unreachable
CN in its cache to 1, and sends an RUEP to the server
containing the IDs of these queries. The server, in turn,
changes the address of that CN in its cache to 1 and stops
sending updates for these items. Later, if another node A
requests and then caches one of these items, the server,
upon receiving an SCUP from A, will associate A with this
data item. Also, if a CN runs out of space when trying to
cache a new item i
i
, it applies a replacement mechanism to
replace i
d
with i
i
and instructs the QD that caches the query
associated with i
d
to delete its entry. This causes the QD to
send an RUEP to the server to stop sending updates for i
d
in
the future.
If a caching node CN
d
returns to the MANET after
disconnecting, it sends a Cache Invalidation Check Packet
(CICP) to each QD that caches queries associated with
items held by this CN. A QD that receives a CICP checks
for each item to see if it is cached by another node and then
sends a Cache Invalidation Reply Packet (CIRP) to CN
d
containing all items not cached by other nodes. CN
d
then
deletes from its cache those items whose IDs are not in the
CIRP but were in the CICP. After receiving a CIRP from all
QDs to which it sent a CICP and deleting nonessential data
items from its cache, CN
d
sends a CICP containing the IDs
of all queries with data remaining in its cache to the server
along with their versions. In the meanwhile, if CN
d
receives a request from a QD for an item in its cache, it
adds the request to a waiting list. The server then creates a
CIRP and includes in it fresh copies of the outdated items
and sends it to CN
d
, which, in turn, updates its cache and
answers all pending requests.
Finally, and as described in [2], QD disconnections and
reconnections do not alter the cache of the CNs, and hence,
the pointers that the server holds to the CNs remain valid.
2.3 Adapting to the Ratio of Update Rate and
Request Rate
SSUM suspends server updates when it deems that they are
unnecessary. The mechanism requires the server to monitor
the rate of local updates, 1
n
, and the rate of RN requests,
1
i
, for each data item d
i
. Each CN also monitors these
values for each data item that it caches. Whenever a CN
receives an update from the server, it calculates 1
n
,1
i
and
compares it to a threshold . If this ratio is greater than or
equal to , the CN will delete d
i
and the associated
information from its cache and will send an Entry Deletion
Packet (EDP) to the QD (say, QD
d
) that caches query
i
. The
CN includes in the header of EDP a value for 1
n
, which tells
QD
d
that d
i
is being removed due to its high update-to-
request ratio. Normally, when a QD gets an EDP, it removes
the cached query from its cache, but here, the nonzero value
of 1
n
in the EDP causes QD
d
to keep the query cached, but
with no reference to a CN. Next, QD
d
will ask the server to
stop sending updates for d
i
. Afterward, when QD
d
receives
a request from an RN node that includes
i
, it forwards it to
the server along with a DONT_CACHE flag in the header
to be later passed in the reply, which includes the results, to
the RN. Under normal circumstances in COACS, when an
RN receives a data item from the server in response to a
query it had submitted, it assumes the role of a CN for this
item and will ask the nearest QD to cache the query. The
DONT_CACHE flag instructs the RN to treat the result as if it
were coming from the cache and not become a CN for it.
Now, at the server, each time an update for
i
occurs and a
new 1
n
,1
i
is computed, if this ratio falls below a second
threshold, ( < ), the server will reply to the RN with a
DREP that includes the CACHE_NEW flag in the header.
Upon receiving the DREP, the RN sends a QCRP with the
CACHE_NEW flag to its nearest QD. If this QD caches the
query of this item (with 1 as its CN address), it sets its
address to its new CN, else it forwards the request to its
own nearest QD. If the QCRP traverses all QDs without
being processed (implying that the QD caching this item
has gone offline), the last QD at which the QCRP arrives
will cache the query with the CN address.
By appropriately selecting the values of and , the
system can reduce unnecessary network traffic. The proces-
sing time of
i
will suffer though when 1
n
,1
i
is above
after it had passed since QD
d
will be sending
i
to the
server each time it receives it. However, the two thresholds
allow for favoring bandwidth consumption over response
time, or vice versa. This makes SSUM suitable for a variety
of mobile computing applications: a large may be used
when disconnections are frequent and data availability is
important, while a low could be used in congested
environments where requests for data are infrequent or
getting fresh data is not critical. Fig. 2 summarizes the
interactions among the entities of the system.
2.4 Accounting for Latency in Receiving Server
Updates
Given the different processes running at the server and since
it sends the updates to the CNs via unicasts, there may be a
time gap between when an update occurs and when the CN
actually receives the updated data item d. Hence, if the CN
gets a request for d during this time, it will deliver a stale
copy of d to the RN. Our design uses the time stamp that the
server sends with each update in an attempt to mitigate this
issue. To explain this, suppose that the time stamp sent with
d is t
:
and the time of receiving d by the CN is t
c
. Upon
getting an update, the CN checks if it had served any RN a
copy of d from its cache in the past t
:
-t
c
milliseconds. If it is
the case, the CN sends a new DREP to the RN, but now it
includes the fresh copy of d.
The above solution assumes that the clocks of the nodes
in the MANET and that of the server are synchronized. This
assumption is realistic given that node clock synchroniza-
tion is part of the MAC layer protocol, as specified by the
IEEE 802.11 standards [15]. In particular, IEEE 802.11
specifies a Timing Synchronization Function (TSF) through
which nodes synchronize their clocks by broadcasting their
timing information using periodic beacons. Since the Access
780 IEEE TRANSACTIONS ON MOBILE COMPUTING, VOL. 9, NO. 6, JUNE 2010
Authorized licensed use limited to: muthu m. Downloaded on June 27,2010 at 05:45:28 UTC from IEEE Xplore. Restrictions apply.
Point (AP) is considered a node in the MANET and it can
synchronize its clock with that of the server asynchronously
with respect to the MANET through the wired network, it
will be possible to synchronize the clocks of the mobile
nodes with that of the server at almost a zero cost to them
(no protocol besides the MAC layers TSF is needed).
The suitability of TSF for SSUM depends on its effective-
ness. It was shown in [33] that using TSF, the maximumclock
offset in the case of 500 nodes is 700 js. Several approaches
were proposed to reduce this error. The Automatic Self-time
Correcting Procedure (ASP) [27] reportedly reduced the
maximumoffset to 300 js, while the Multihop Adaptive TSF
(MATSF) method [33] cut it down to 50 js, but at the expense
of adding 8 bits to the IEEE 802.11 frame. In Section 2.6, we
show that SSUM is best characterized by the delta consis-
tency model [21], where the upper bound for the delta
MERSHAD AND ARTAIL: SSUM: SMART SERVER UPDATE MECHANISM FOR MAINTAINING CACHE CONSISTENCY IN MOBILE... 781
Fig. 2. Detailed operations of the entities of SSUM using pseudocode.
Authorized licensed use limited to: muthu m. Downloaded on June 27,2010 at 05:45:28 UTC from IEEE Xplore. Restrictions apply.
between the time of the servers update and the time the RN
gets a fresh copy is in tens of milliseconds. It follows that TSF
will virtually not increase this delta, especially in small to
moderately sized networks.
2.5 Overhead Cost
When a node joins the network, the server will know about
it when it first gets a query from it in a DRP that is
forwarded by one of the QD nodes. Each data item at the
server that is cached in the network is associated with a
query id, a request rate, an update rate, and the address of
the CN caching it. This additional information could cost
the server about 16 bytes of extra storage per record. Hence,
from a storage perspective, this cost may be deemed
insignificant when considering the capabilities of modern
servers. In terms of communication cost, the server
communicates with the CNs information about the rates
using header information in the exchanged packets, and
uses control packets (RUEP, SCUP, CICP, and CIRP) to
manage the updating process. Here, it suffices to state that
the simulation results (Section 4.10) indicate that the overall
overhead traffic (including other packets that do not
concern the server) is a small portion of the data traffic.
Finally, from a processing load point of view, the server is
only required to manipulate the update rate when appro-
priate. In conclusion, the server will not incur any notably
additional load due to its role in this architecture. Hence,
the system should be able to scale to a large number of
cached items.
A similar argument can be made for the CNs, although
the main concern here is the impact on the cache space and
replacement frequency. Using the same value of 5 KB for the
average data item size (as in the simulations of Section 4),
with caching capacity of 200 KB, a CN can cache about
40 data items. The additional overhead required for storing
the request and update rates of one single data item is
8 bytes, and therefore, the overhead for storing the request
and update rates at the CN is less than 0.16 percent of the
available space. It follows that the space for caching at the
CNs is minimally impacted by this additional information.
Also, the frequency of cache replacements will not increase
in a major way because of this.
2.6 Consistency Model
From the characteristics of SSUM described above, we may
relate it to the delta consistency model [21]. Assuming the
RN always requires a fresh copy of item d, a CN may end
up sending two copies of d to an RN in case the CN serves a
copy of d from its cache shortly before receiving a server
update for it. First, we emphasize that from the perspective
of the RN, d will be considered fresh only if it is a duplicate
of the servers version at the time it is received (i.e., the
server has not updated it just yet). We now define two
boundary situations in which the RN gets a stale copy of d.
In the first one, immediately after the server updates d at t
:
and sends it into the network, the RN receives a copy of it
from the CN based on a request it had sent. In the second
one, right after the CN serves the RN a copy of d, it receives
an updated version from the server. Assuming that when
the server updates d, it immediately sends it out, and that it
is connected to the MANET via an access point in the corner
of the network, we can now compute an interval for the
maximum delta between t
:
and the time the RN gets a
fresh copy of it. To do this, we borrow some definitions
from our work in [2] in relation to the average number of
hops. The top two definitions below are used here while the
other two are used in Section 3, but all are detailed in
Appendices A, B, and C:
. H
C
is the average number of hops between the
corner of the topology and a random node in the
MANET. It applies when a packet is sent between
the server and the random node.
. H
1
is the expected number of hops between any two
randomly selected nodes.
. H

is the expected number of hops to traverse all the

QDs in the system, which usually occurs in the case
of a cache miss.
. H
1
is the expected number of hops to reach the QD
which holds the reference to the requested data, in
the case of a hit.
Hence, if T
ii
is the transmission delay between two
neighboring nodes in the wireless network and T
ont
is the
delay inthe wirednetwork to/fromthe server, thenthe delay
until the RN gets a fresh copy of d in the first situation is
T
ont
H
C
T
ii
H
1
T
ii
, while in the second situation, it
is simply H
1
T
ii
. Using the values of H
C
and H
1
in [2], we
can deduce that the maximum delta will be expressed as

ior
2 0.52T
ii
o,i0. T
ont
1.29T
ii
o,i0, where o is the side
length of the square topography and i
0
is the wireless
transmission range. Taking o as 1,000 m, i
0
as 100 m, T
ii
as
5 ms, andT
ont
as 40 ms,
ior
will be in the range of 25-105 ms.
3 ANALYSIS
We evaluate our scheme in terms of bandwidth and query
response time gains. These are the differences between the
corresponding measures when no cache updating is in
place and when SSUM is employed. Requests for data in the
ad hoc network and data updates at the server are assumed
to be random processes and may be represented by
exponential random variables, as was suggested in [4] and
[25]. We use `
1
to denote the rate of requests and `
l
the
rate of updates. The probability density functions of
requests and updates are thus given:
1
1
t `
1
c
`
1
t
. 1
l
t `
l
c
`
l
t
. 1
Both the bandwidth gain G/ and response time gain Gt are
influenced by the number of data requests issued by
requesting nodes relative to the number of data updates
that occur at the server. In the remainder of the paper, we
refer to no cache updating as NCU.
We nowconsider twocases: `
l
,`
1
< 1 (C1) and`
l
,`
1
! 1
(C2). C2, in turn, comprises two scenarios: after `
l
,`
1
!
and then while `
l
,`
1
! (C2S2), where updates are sus-
pended by the server, and the remaining scenario (C2S1),
where updates are sent by the server (illustrated in Fig. 3).
Finally, the average update andrequest rates canbe relatedas
follows: In the first case (i.e., C1), `
1
``
l
. ` 1, while in
the first scenario of C2 (i.e., C2S1), `
l
``
1.
1 ` < .
782 IEEE TRANSACTIONS ON MOBILE COMPUTING, VOL. 9, NO. 6, JUNE 2010
Authorized licensed use limited to: muthu m. Downloaded on June 27,2010 at 05:45:28 UTC from IEEE Xplore. Restrictions apply.
Starting with C2S2, SSUM suspends the server updates
to the RN, thus, acting like NCU and resulting in a zero
bandwidth gain. The cache entry would have been outdated
upon getting the RNs next request, thus causing a cache
miss. This causes a traversal of all QDs, then a transmission
to and from the server, a transmission back to the
requesting node, and then a packet sent to a QD asking it
to cache the query. In C2S1, where `
l
,`
1
! 1 and the
updates are sent to the RNs, the requests are served from
the cache. To compute the gain, we take a time period that
includes 1 update periods such that 1 `. The cache
entry will be updated, and hence, an update packet is sent
to the CN from the server, plus the request sent from the
RN to the QD caching the query and then forwarded to the
CN holding the data, and finally, the reply from the CN.
Thus, the bandwidth gains for C2S1 and C2S2 are stated as
shown in (2):
G/
C2o1
1,`o
1
H

o
1
H
C
o
1
H
C
o
1
H
1

1o
1
H
C
1,`o
1
H
1
o
1
H
1
o
1
H
1

1,`o
1
H

o
1
H
C
1 `o
1
H
C
o
1
H
1
o
1
H
1
.
G/
C2o2
0.
2
where o
1
denotes the size of a request packet (in bytes) and
o
1
the size of a data packet.
For the first case (C1), we can develop a similar
expression as follows:
G/
C1
1o
1
H

o
1
H
C
o
1
H
C
o
1
H
1

1` 1o
1
H
1
o
1
H
1
o
1
H
1

1o
1
H
C
`o
1
H
1
o
1
H
1
o
1
H
1

1o
1
H

o
1
H
C
o
1
H
1
o
1
H
1
.
3
Note that if we make `
l
`
1
(i.e., ` ` 1), both of the
above expressions yield the same result. Also, although
H

H
1
and H
C
H
1
, G/ may be negative if the larger
size of the result compared to the size of the request (o
1
versus o
1
) outweighs the gain in the number of hops.
Next, to compute the response time gain, we consider the
transmission delay measures T
ii
and T
ont
, which were
defined in Section 2.6. We also note that since the updates
are issued by the server in the background, they do no
impact the query response time.
The response time gain for C2S2 is also zero, while in
C2S1, each request generates a miss in NCU and a hit in
SSUM. Using the above description of request processing,
we have
Gt
C2o1
T
ii
H

T
ii
H
C
T
ont
T
ii
H
C

T
ii
H
1
T
ii
H
1
T
ii
H
1

T
ont
T
ii
H

2H
C
H
1
2H
1
.
Gt
C2o2
0.
4
For Case 1, we account for the average of one miss and
` 1 hits in the case of NCU:
Gt
C1
1,`T
ii
H

T
ii
H
C
T
ont
T
ii
H
C

` 1T
ii
H
1
T
ii
H
1
T
ii
H
1

T
ii
H
1
T
ii
H
1
T
ii
H
1

T
ont
,` T
ii
,`H

2H
C
H
1
2H
1
.
5
With the above expressions, we can make two observations:
when `
l
`
1
(i.e., ` 1), both expressions give the same
result, and the response time gains are always positive.
We now turn our attention to calculating the probabil-
ities of the three possible scenarios. Since we are dealing
with two independent processes, we use double integrals,
as follows:
1
1
C1 1
1
`
l
< `
1

_
1
0
_
1
t1
1
1
t
1
1
l
t
l
dt
l
dt
1

_
1
0
_
1
t
1
`
1
c
`
1
t
1
`
l
c
`
l
t
l
dt
l
dt
1
`
l
`
1
_
1
0
c
`1t1
_
1
tl
c
`ltl
dt
l
dt
1
`
l
`
1
_
1
0
c
`1t1
c
`ltl
`
l
_ _
1
t
1
dt
1
`
1
_
1
0
c
`
1
t
1
c
`
l
t
1
dt
1
`
1
_
1
0
c
`
l
`
1
t
1
dt
1
`
1
c
`
l
`
1
t
1
`
l
`
1
_ _
1
0

`
1
`
l
`
1
.
6
MERSHAD AND ARTAIL: SSUM: SMART SERVER UPDATE MECHANISM FOR MAINTAINING CACHE CONSISTENCY IN MOBILE... 783
Fig. 3. Illustration of the behavior of SSUM as `
l
,`
1
changes (`
1
is shown fixed).
Authorized licensed use limited to: muthu m. Downloaded on June 27,2010 at 05:45:28 UTC from IEEE Xplore. Restrictions apply.
1
1
C2o2 1
1
`
l
! `
1
1
1
`
1
< `
l
`
1

^ 1
1
l
`
1
t
l
1
1
l
`
1

_
1
0
_
1
t
l
1
1
t
1
1
l
t
l
dt
l
dt
1

_
ln`1,`l,`l
ln`
1
,`
l
,`
l
_
tl
t
l
1
1
t
1
1
l
t
l
dt
l
dt
1

`
l
`
l
`
1
1 `
1
,`
l

_
`
l
`
1
`
l
_ _
`
1
,`
l

_
`
l
`
1
`
l
__

`
l
`
l
`
1
`
1
,`
l

_
`
l
`
1
`
l
_ _
`
1
,`
l

_
`
l
`
1
`
l
__
1
1
C2o1 1
1
`
l
! `
1
1
1
C2o2

`
l
`
l
`
1
1
1
C2o2.
7
With respect to the above expression, we note that if the
server is permitted to send updates to the clients at all times
(i.e., without regard to the and parameters), then the
probability of Case 2 (i.e., there will be no distinct scenarios
in this situation) will be `
l
,`
l
`
1
.
With the above, the average gains of the system can now
be computed:
1G/ G/
C1
1
1
C1 G/
C2o1
1
1
C2o1
G/
C2o2
1
1
C2o2.
8
1Gt Gt
C1
1
1
C1 Gt
C2o1
1
1
C2o1
Gt
C2o2
1
1
C2o2.
9
The gain expressions indicate that the wireless band-
width gain may be negative, but the response time gain is
always positive. This may form a reasonable trade-off,
especially when bandwidth can be sacrificed in order to
speed up the query response time.
Fig. 4 confirms the above observations and illustrates
the average bandwidth and response time gains under
two situations: when SSUM is applied as described and
with a modified version that lets the server send updates
to the RNs at all times (i.e., without considering and ).
Before analyzing the graphs, we note that several factors
play a role in determining the gain values, most
importantly the number of QDs, the `
l
,`
1
ratio, and
the data packet size (o
d
) relative to the request packet size
(o
i
). The effect of the number of QDs is intuitive because
with more QDs, more data will be cached in the network,
and therefore, both the bandwidth and response time
gains will increase. Next, as the o
d
,o
i
ratio increases, the
bandwidth gain will decrease while the response time
gain will generally not be affected.
The graphs of Fig. 4 generally show that as `
1
increases,
the bandwidth gain improves, while normally, the response
time gain suffers. The explanation is intuitive as additional
784 IEEE TRANSACTIONS ON MOBILE COMPUTING, VOL. 9, NO. 6, JUNE 2010
Fig. 4. Bandwidth and response time gains versus update and request rates in two cases.
Authorized licensed use limited to: muthu m. Downloaded on June 27,2010 at 05:45:28 UTC from IEEE Xplore. Restrictions apply.
requests will be served from the cache with consistent data
(versus going to the server for each request as in NCU).
Given this characteristic, SSUM is most beneficial in
environments with high user activity (high request rate)
and relatively low data volatility (low server update rate).
Moreover, these graphs illustrate the influence of the
selective updating mechanism that SSUM employs (left
graphs) versus the all-time updating version (right graphs).
Clearly, selective updating saves bandwidth consumption
at the moderate expense of response time.
Before leaving this section, we point out that in
Appendix D, we proved that the effect of QD disconnec-
tions on bandwidth consumption and response time in
SSUM is insignificant. Moreover, since QD disconnections
is a network issue and applies to both SSUM and NCU, the
extra delay and bandwidth do not contribute to the gain
expressions presented above.
4 PERFORMANCE EVALUATION
We used the ns2 software to implement the SSUM system,
and to also simulate the Updated Invalidation Report
(UIR) mechanism [10] in addition to a version of it that is
implemented on top of COACS so that a presumably
fairer comparison with SSUM is done. To start with, we
list the default values of the main simulation parameters
in Table 2.
4.1 Network and Cache Simulation Parameters
A single database server is connected to the wireless
network through a fixed access point, while the mobile
nodes are randomly distributed. The client cache size was
fixed to 200 Kb, meaning that a CN can cache between 20
and 200 items, while the QD cache size was set to 300 Kb,
and therefore, a QD can cache about 600 queries. We used
the least recently used (LRU) cache replacement policy
when the cache is full and a data item needs to be cached.
Each scenario started with electing one QD, but more were
elected when space was needed. Each scenario lasted for
2,000 seconds and repeated 10 times with the seed of the
simulation set to a new value each time, and the final result
was taken as the average of the 10 runs.
The SSUM system was implemented as a new C++ agent
in ns2 that gets attached to the node class in the tcl code at
simulation runtime. This implementation includes a cache
class that defines and sets the needed data items as well as
the operations of the caching methods that were described.
Also, the routing protocols in ns2 were modified to process
the SSUM packets and to implement the functions of the
MDPF algorithm used for traversing the QD system [3].
Other changes to the ns2 C++ code included modifying the
packet header information which is used to control the
cache update process. After implementing the changes in
the C++ code, tcl scripts were written to run the various
described scenarios.
4.2 The Query Model Parameters
The client query model was chosen such that each node in
the network generates a new request every T

seconds.
When the simulation starts, each node generates a new
request, and after T

seconds, it checks if it has not received

a response for the request it generated in which case, it
discards it and generates a new request. We chose a default
value for T

equal to 20 seconds, but in order to examine the

effect of the request rate on the system performance, we
simulated several scenarios with various request rates. The
process of generating a new request followed a Zipf-like
access pattern, which has been used frequently to model
nonuniform distributions [34]. In Zipf law, an item ranked
i1 i i

is accessed with probability1,i

0

/1
1,/
0
,
where 0 ranges between 0 (uniform distribution) and 1
(strict Zipf distribution). The default value of the zipf
parameter 0 was set to 0.5.
Every second, the server updates a number of randomly
chosen data items, equal to a default value of 20. The default
values of and were set to 1.25 and 0.75, respectively,
while the default number of node disconnections is 1 every
two minutes with a period of 10 seconds, after which the
node returns to the network. However, in the experiments
that we present below, the above parameters values are
varied to study their effects on performance.
4.3 Compared Systems
In addition to SSUM, we simulated two other systems: UIR
and C_UIR. C_UIR is a version of UIR [10] that we
implemented on top of COACS (with the parameters
values given above). It should be noted though that several
differences between the implementation of UIR in our
simulation environment and that used in [10] exist. This
resulted in producing different results than those reported
in [10]. Some of the differences are: the number of data
items at the server was set to 1,000 in [10] and 10,000 in our
simulations. The used value for the zipf 0 parameter was 1
in [10] and 0.5 in our case. We did not divide the database
into hot and cold subsets, but instead, we relied on Zipf to
naturally determine the access frequency of data. The size of
the data item was randomly varied in our simulations
between 1 and 10 KB, while in [10], it was fixed to 1 KB.
Also, we set the IR interval 1 to 10 s and replicated the UIR
four times within each IR interval, while in [10], 1 was set to
MERSHAD AND ARTAIL: SSUM: SMART SERVER UPDATE MECHANISM FOR MAINTAINING CACHE CONSISTENCY IN MOBILE... 785
TABLE 2
Summary of Simulation Parameters Values
Authorized licensed use limited to: muthu m. Downloaded on June 27,2010 at 05:45:28 UTC from IEEE Xplore. Restrictions apply.
20 s. Hence, the simulation parameters in our environment
put more stress on the network and are more realistic.
We analyze the performance of SSUM, UIR, and C_UIR
from four different perspectives. The first two are the query
delay and the update delay. In this regard, it is important
to note that in SSUM, the server unicasts the actual data
items to the CNs, while in UIR and C_UIR, it broadcasts
the IDs of the updated items, not their contents. Another
major difference is that in C_UIR, if the CN receives the
request from the RN after the update takes place at the
server but before the CN receives the update report, the RN
will receive a stale copy of the data item, while, as was
explained in Section 2.4, SSUM implements a provision
that fixes this issue. We stress that the update delay of UIR
and C_UIR as presented in Sections 4.4-4.8 is the delay
until the items ID reaches the node, not the item itself. If
we were to incorporate the delay of fetching the data item
from the server, the update delay will greatly increase. The
third performance measure is the hit ratio, and finally, the
fourth measure is the average bandwidth consumption per
node. The latter was computed by recording the total
number of messages of each packet type issued, received,
or passed by a node, multiplying it by the respective
message size, and then divided by the number of nodes
and the simulation time.
In the following sections, we vary some of the key
parameters of the simulation environment and observe the
effects on the performance of the three systems.
4.4 Varying the Number of Nodes
This section presents the effects of varying the node density
in the fixed network area. Fig. 5a shows that the query delay
of UIR is much greater than that of SSUM and C_UIR. The
reason for this is that an issued query in SSUM does not
have to wait for any report from the server, as it is always
served directly after it is issued, whereas in UIR, it must
wait for the next UIR to arrive from the server before getting
processed. Moreover, in the event of a local cache miss in
UIR, the data item must be fetched from the server, but in
COACS and C_UIR, the data are next searched for in the
QD system for possible network cache hit. Fig. 5b shows
that the update delays of UIR and C_UIR are less than that
of SSUM when there are less than 100 nodes, simply
because updates in UIR are broadcasted. But, when the
number of nodes increases, congestion starts to buildup,
which why the hit ratio of this scheme drops rapidly and its
traffic increases as shown in Figs. 5c and 5d.
Finally, we reiterate the fact that the presented update
delay for UIR and C_UIR is not the total delay since it
measures the time until the items ID reaches the RN/CN,
whereas for SSUM, it is the entire delay since it is the time
until the data item itself reaches the CN.
4.5 Varying the Query Request Rate
When the request rate is increased, the query delay of
SSUM rises as shown in Fig. 6a due to queuing more
packets in the nodes, while the update delay decreases
initially and then settles down because as more items are
cached, new CNs are set up. This increases the probability
of having more CNs closer to the access point, which, in
turn, results in smaller number of hops, on average, for the
update packets to reach their destinations.
Unlike SSUM, the update delay of C_UIR increases due
to the increase in network traffic as seen in Fig. 6d. This
large traffic, which is the cumulative result of requests,
update reports, and control packets, can result in congestion
that delays the query and update packets of C_UIR. It can
also lead to more unsuccessful requests, which, in turn,
decreases the hit ratio. In contrast, the hit ratio of SSUM
keeps increasing as the request rate increases for two
reasons: first, the number of cached queries increases, and
786 IEEE TRANSACTIONS ON MOBILE COMPUTING, VOL. 9, NO. 6, JUNE 2010
Fig. 5. Query and update delay, hit ratio, and bandwidth usage versus number of nodes.
Authorized licensed use limited to: muthu m. Downloaded on June 27,2010 at 05:45:28 UTC from IEEE Xplore. Restrictions apply.
second, the network is not overcome by congestion as in the
other two schemes. The query delay of UIR drops as its hit
ratio increases while its update delay is generally un-
affected due to the broadcasting of updates.
4.6 Varying the Data Update Rate
The results of varying the update rate are shown in Fig. 7.
We notice that the query delay of SSUM remains almost
unchanged as the update rate increases since its traffic
(Fig. 7d) increases slightly. On the other hand, its hit ratio
drops quickly (Fig. 7c) since as the request rate is held
constant, more data items will be fetched from the server
(their 1
n
,1
i
ratio will exceed ). The update delay of
SSUM worsens (Fig. 7b) since with increased server
updates, more contention will occur at the Access Point,
which will be busier forwarding more requests to the
server. The update delay and hit ratio of UIR and its
variant remain almost unchanged, but they induce more
traffic due to larger update reports.
MERSHAD AND ARTAIL: SSUM: SMART SERVER UPDATE MECHANISM FOR MAINTAINING CACHE CONSISTENCY IN MOBILE... 787
Fig. 7. Query and update delay, hit ratio, and bandwidth usage versus data update rate.
Fig. 6. Query and update delay, hit ratio, and bandwidth usage versus query request rate.
Authorized licensed use limited to: muthu m. Downloaded on June 27,2010 at 05:45:28 UTC from IEEE Xplore. Restrictions apply.
4.7 Varying the Node Velocity
The mobility pattern of nodes in a MANET can vary
anytime and unexpectedly. Here, we study the effect of
varying the node speed from 0 to 20 m/sec and show the
result in Fig. 8.
We notice from the results in Fig. 8 that the delay of the
three systems increases with increased speed, while their hit
ratios decrease, which is normal for most mobile systems: as
nodes move faster, the network topology changes, and
connections between nodes are maintained for shorter
periods of time. The traffic of UIR and C_UIR increases
while that of SSUM generally remains unchanged. This may
be because the CNs and QDs can move closer or farther
from each other and from the AP, thus, resulting in a
minimum net effect. It is noted that although the traffic of
C_UIR increases, it still follows the trend of SSUM, which is
understandable since both schemes are built on the same
caching system.
4.8 Varying the Node Disconnection Rate
We now examine the effect of another property of the
dynamic environment of MANETs, namely nodes discon-
necting and reconnecting. The period of disconnection was
fixed at 10 seconds but we varied the number of nodes
disconnecting per minute between 0.1 and 20.
Fig. 9 illustrates that the delays of UIR and C_UIR are
more affected than that of SSUM, while the hit ratio and
traffic of SSUM are more affected. The hit ratios of SSUM,
C_UIR, and UIR drop to 11, 9, and 6 percent, respectively,
as the disconnection rate increases. The traffic of SSUM
increases over the traffic of UIR at high disconnection rates,
a phenomenon that may be attributed to having no recovery
mechanism in UIR, since the node that reconnects to the
network either waits for the next UIR to invalidate its cache
if it has gone offline for less than a given number of seconds
[10], or drops its entire cache. On the other hand, the
recovery process for reconnections in SSUM requires extra
overhead as was discussed in Section 2.2, but keeps the
increase in the response time under control.
4.9 Varying and
As described in Section 2.3, when the ratio 1
n
,1
i
of a data
item reaches , the item is fetched from the server whenever
requested until the ratio drops below , then the request is
cached again. The values of and were set to 1.5 and 0.75,
respectively, but here, we analyze the effects of varying
between 0.5 and 4, while setting to ,5. We ran simulations
for three different 1
n
values: 0.1, 20, and 50 updates per
second (which, respectively, represent the minimum, aver-
age, and maximum values of the update rate presented in
Section 4.6), while fixing 1
i
to 0.1 requests per second. The
results in Fig. 10 indicate that for low update rate values, the
performance of SSUM is not affected in a major way, but for
high update rates, the query delay decreases as and
increase because less packets are fetched from the server
directly, whichproduces higher hit ratios andsmaller delays.
We also note in Fig. 10a that when 1
n
20, the query
delay decreases significantly as changes from 1 to 2, but
settles afterward. The explanation for this is that the further
increase in will keep the 1
n
,1
i
ratio for all data items less
than . On the other hand, when the update rate was set to
50, the query delay kept decreasing as increased, although
it is expected that it will stabilize at some value, as was
the case when the update rate was set to 20. As for the
update delay, it increases because more update packets are
sent, and this, in turn, increases the traffic. The hit ratio also
increases because as increases, less data items are fetched
from outside the MANET. In conclusion, we learn that
increasing and allows for favoring query delay and hit
ratio over update delay and network traffic, or vice versa.
788 IEEE TRANSACTIONS ON MOBILE COMPUTING, VOL. 9, NO. 6, JUNE 2010
Fig. 8. Query and update delay, hit ratio, and bandwidth usage versus node velocity.
Authorized licensed use limited to: muthu m. Downloaded on June 27,2010 at 05:45:28 UTC from IEEE Xplore. Restrictions apply.
The results of Fig. 10 can be used to configure the
values of and when certain characteristics about the
data and the client application are known. If the applica-
tion requires quick access to the data, then large values of
and should be chosen. On the other hand, if there is
contention in the network and/or if the mobile devices
want to conserve battery power, then relatively small
values can be selected. Now concerning the difference in
value between and , we use it to extend the data
update suspension period. One possible scenario is when
the database at the server has certain volatile data that are
changing generally rapidly (like the price of an actively
traded stock), while at the same time, the mobile users are
regularly checking for the price. In this case, the difference
between and may be widened to latch onto the
general behavior of the data update frequency. In general
though, the closer the values of and are, the more
updates will reach the network and the longer the cache
will remain valid (i.e., before expiring). This will, in turn,
reduce the query delays.
MERSHAD AND ARTAIL: SSUM: SMART SERVER UPDATE MECHANISM FOR MAINTAINING CACHE CONSISTENCY IN MOBILE... 789
Fig. 10. Query and update delay, hit ratio, and bandwidth usage versus the threshold .
Fig. 9. Query and update delay, hit ratio, and bandwidth usage versus disconnection rate.
Authorized licensed use limited to: muthu m. Downloaded on June 27,2010 at 05:45:28 UTC from IEEE Xplore. Restrictions apply.
4.10 Data and Overhead Traffic
In this set of experiments, we separated the produced traffic
into data traffic, which includes the requests plus forwarding
and reply packets, and overhead traffic generated by CSP,
CIP, SCUP, CICP, CIRP, and update packets. The graphs in
Fig. 11 show that the overhead traffic in SSUM makes up
between 2 and 25 percent of the total traffic when the request
rate is varied, and between 15 and 25 percent when the data
update rate is changed. In all, it is shown that SSUMdoes not
generally produce substantial overhead traffic.
4.11 System Considerations
We discuss in this section some considerations for the
implementation of SSUM that we derive from the system
design and the simulation results. The first concerns node
disconnections: Section 4.8 demonstrated that node dis-
connections led to major increases in bandwidth consump-
tion. Note that the scenarios in Section 4.8 included
disconnections of random nodes that include QDs (in such
cases, new QDs are elected). The major limitation which we
point out is that an implementation of SSUM in a MANET
where all nodes have short battery lifetime will not be
efficient since this will result in frequent disconnections,
and could lead to situations where no more nodes are
qualified for becoming QDs. Hence, the requirement is that
at any time, a portion of the nodes in the network must have
sufficient energy to take on QD roles (in our simulations,
the average number of QD nodes considered was 7 out of
100 nodes). This requirement though should be satisfied in
most current MANETs since major technological improve-
ments have been made to mobile device batteries, including
those of cell phones. As an example, a survey of some recent
cell phone models, including Nokia N86, Nokia N97, Sony
Ericsson XPERIA X2, and Samsung I8000 revealed an
average battery capacity of 430 hours in standby mode
and 9 hours in talk time.
Another issue is the network size. Similar to most server-
based consistency schemes, SSUM will not be efficient in
very large networks with thousands of nodes, where routing
paths from the server to distant nodes could be lengthy, and
more nodes will disconnect from and reconnect to the
network. In these conditions, maintaining information about
data items at all caching nodes will be expensive for the
server. One of the possible solutions for such networks is the
implementation of clustering in the MANET and adding
more Access Points. Clustering can reduce overhead at the
server since clusterheads can be used to represent the CNs
within their clusters and act as single points of contact with
the server. Additional APs will serve to reduce contention at
the connections of the MANET to the wired network.
5 LITERATURE REVIEW
Several cache consistency (invalidation) schemes have been
proposed in the literature for MANETS. In general, these
schemes fall into three categories: 1) pull- or client-based,
where a caching node (CN) asks for updates from the
server, 2) push- or server-based, where the server sends
updates to the CN, and 3) cooperative, where both the CN
and the server cooperate to keep the data up-to-date. In
general, pull-based strategies achieve smaller query delay
times at the cost of higher traffic load, whereas push-based
strategies achieve lower traffic load at the cost of larger
query delays. Cooperative-based strategies tend to be
halfway between both ends. In this section, we restrict our
literature survey to server-based strategies so as to provide
a comparative study in relationship to the approach of our
proposed system.
5.1 Invalidation Reports
Server-based approaches generally employ invalidation
reports (IRs) that are periodically broadcasted by the server.
An IR normally carries the IDs of the updated data items
and the time stamps of the updates. When a query is
generated, the node waits for the periodic IR to invalidate
its cache (if connected) and answer the query if it has a valid
item. If the requested item is invalid, it usually waits for the
periodic IR, or as in some proposed schemes, like the
Modified Time Stamp (MTS) mechanism of [23], it broad-
casts a request packet that gets forwarded to the server
without waiting for the periodic IR. Such schemes generally
suffer from large average delays due to waiting for the
periodic IR or from high traffic in case broadcasts are
employed when misses occur and the request rate is high.
Most research in this area has focused on reducing the time
intervals between updates or making the process of sending
update reports less static. In the improved IR technique that
was presented by Cao [10] and which we implemented to
compare SSUM to, the time between two consecutive IRs
was divided into intervals. At the beginning of each
interval, the server broadcasts a UIR, which contains the
IDs of data items updated since the last IR. This UIR
reduces the query latency time since a node that needs to
answer a query only waits until the next UIR to see whether
the item has been updated instead of waiting until the next
IR (the UIR interval may be adjusted dynamically according
to the average request rate of the network). This approach
can also decrease generated traffic by making the server
790 IEEE TRANSACTIONS ON MOBILE COMPUTING, VOL. 9, NO. 6, JUNE 2010
Fig. 11. Data and overhead traffic of SSUM versus the request and update rates.
Authorized licensed use limited to: muthu m. Downloaded on June 27,2010 at 05:45:28 UTC from IEEE Xplore. Restrictions apply.
save a list of the submitted requests to each item after which
it broadcasts this list followed by the updated data items.
This approach may be best suited to high update rate
situations because it does not overwhelm the network with
updates immediately upon their occurrence. Another
improvement over the basic IR approach was proposed by
Li et al. [22]. The basic idea is for each node to cache the last
1 reports that are broadcasted by the server, and for the
server to store the IRs for future use. Using the time stamps
of the IRs it caches, when a node goes offline and comes
back online, it determines the IRs that it missed and pulls
them from the server to validate its cache. If the node misses
more than 1 IRs, it drops the entire cache.
Several approaches attempted to make the process of
sending reports dynamic [11], [12], [18], [32]. Yuen et al. [32]
proposed a scheme by absolute validity interval (AVI) that
is calculated dynamically by the server based on the update
rate. A client considers an item invalid after its AVI expires
and may drop or update it from the server. The server
periodically broadcasts an IR that contains the changes to
AVIs of items to make clients caching these items update the
cached AVI with its new value in the IR. Thus, the size and
interval of the IR could be improved. This approach,
however, still exhibits access delays introduced by periodic
broadcasts. Similarly, Kai and Lu [18] proposed to broadcast
the reports dynamically based on the updating frequency of
the data items. Chung and Hwang [12] took this concept
further by adapting the broadcast of reports to the update
pattern and data locality on the server. A serious issue,
however, arises with the above approaches when the
frequency of updates at the server is high, which could
overload the clients with update reports.
5.2 Energy-Efficient Cache Invalidation
A different approach was taken by Cai and Tan [8] in
proposing three energy-efficient selective cache invalidation
schemes based on the group invalidation method in which a
separate IR is broadcasted for each group of items. These
strategies allow clients to selectively tune to the portions of
the invalidation report that are of interest to them, while
returning to sleep or idle modes during the rest of the IR.
This can be done by including at the beginning of the IR an
index of the rest of the remaining data in the report. This
technique produces good results when the update rate is
high, but makes the size of the IR quite large.
5.3 Cache Invalidation Using Bit Sequences
In order to reduce the size of the IR, Jing et al. [16] proposed
using bit sequences (BSs), according to which the data
server broadcasts a sequence of bits with a time stamp,
where each bit represents a data item, and its position in the
sequence represents an index to its corresponding item. The
clients get the mapping of bits to the names of data items
from the server. A value of 1 in the BS means that the
corresponding item has been updated since the last IR, and
a value of 0 indicates otherwise. The authors improved on
the BS algorithm in [13] through a multidimensional bit
sequence. The granularity of each bit in the BS was varied
according to the size of the database at the server. For
example, for an 8 GB database, each bit can represent an
8 MB data block, which allows for representing the database
with a BS of 1,024 bits. The client retrieves data from the
database as data pages and updates each cached item that
contains at least one page from an updated block (with
corresponding bit equal to 1 in the BS). Moreover, the
granularity of each bit was dynamically adjusted according
to the popularity of the corresponding block of the database
that it represents (whether it is hot or cold). All the BS
algorithms perform best when the update rate is low, but
suffer from drawbacks when the update rate is high, as was
stated by the authors.
5.4 Selective Data Push
Huang et al. present in [14] a Greedy Walk-Based Selective
Push (GWSP) method that attempts to reduce the redun-
dancy in conventional push mechanisms by pushing
updates only if the CN is expected to serve queries and if
there are no more data updates before the Time-to-Refresh
(TTR) expires. This is done by maintaining the state of the
cached data at the data server, which stores the TTR value
and the query rate associated with cached data. Based on
this state information, the server selects the CNs to send the
updates to and creates a push set that contains the CNs that
should receive updates. This method is compared with a
dynamic pull-mechanism in which the CN maintains a TTR
for the cached data and pulls updates accordingly.
Reported results show that GWSP exhibits lower generated
traffic load and lower query latency at low query rates, but
tends to have similar delays at larger rates.
5.5 Consistency Based on Location
The consistency of location-dependent data was studied in
[30], which proposes methods to validate and update
information that change their values depending on the
location of the client, like traffic reports and parking
information. In this context, not only the temporal
consistency but also the location-dependent consistency
(due to client mobility) is taken into consideration. A data
item can have different values for different locations: when
a mobile host caching an item moves from one of the cells
to another, the value of the item may become obsolete and
needs to be updated. One of the methods proposed by the
authors is the Implicit Scope Information (ISI) scheme in
which the client stores the valid scopes of each item and
the server periodically broadcasts the changes of validity
of each data item.
Finally, we conclude that besides the latency issue that is
associated with the push-based techniques, their basic
problem is that the IR or UIR reports typically contain
information that is not of interest to a large number of nodes,
thus costing them wasted processing time and bandwidth.
Even cooperative-based mechanisms, which try to combine
the advantages of push and pull strategies, also inherit their
disadvantages halfway. For example, the simulation results
of the scheme in[9] showthat boththe query delay andtraffic
load fall between the measures of pure push and pull
strategies. To our knowledge, no existing scheme actually
adapts the frequency of update reports to both the rate of
updates at the server and that of data requests by the clients,
to render a truly dynamic system. Our work addresses both
of the above two issues, which is made in part possible by the
architecture of COACS.
MERSHAD AND ARTAIL: SSUM: SMART SERVER UPDATE MECHANISM FOR MAINTAINING CACHE CONSISTENCY IN MOBILE... 791
Authorized licensed use limited to: muthu m. Downloaded on June 27,2010 at 05:45:28 UTC from IEEE Xplore. Restrictions apply.
Table 3 summarizes the key systems that we presented.
All systems are push-based except RPCC, which is coopera-
tive, and all are stateless except GWSP, which is stateful.
6 CONCLUSIONS AND FUTURE WORKS
In this paper, we presented a novel mechanism for
maintaining cache consistency in a Mobile Ad hoc Network.
Our approach was built on top of the COACS architecture
for caching data items in MANETs and searching for them.
We analyzed the performance of the system through a gain-
loss mathematical model and then evaluated it while
comparing it with the Updated Invalidation Report me-
chanism. The presented results illustrated the advantage of
our proposed system in most scenarios.
The evaluation results confirmed our analysis of the
scalability of the system (Section 2.5). That is, they indicate
that even when the node density increases or the node
request rate goes up, the query request delay in the system
is either reduced or remains practically unaffected, while
the cache update delay experiences a moderate rise. Yet,
even if a higher update delay means that the probability of
nodes getting stale data increases, the proposed system
includes a provision for keeping track of such nodes and
supplying them with fresh data within a delta time limit,
as described in Section 2.6. Hence, it can be concluded that
the system can scale to a moderately large network even
when nodes are requesting data frequently. Moreover, the
increase in the node speed and disconnection rate also
only affected the cache update delay, and to a lesser
extent, the traffic in the network. This reflects on the
robustness of the architecture and its ability to cope with
dynamic environments.
For future work, we propose investigating the effects of
other cache placement strategies and cache replication on
performance. The COACS system, and its successor,
SSUM, did not implement cache replication: Only one
copy of the version at the server is maintained in the
MANET. By adding replication to the design, the query
delay is expected to go down but the overhead cost will
surely go up. Concerning cache placement, as was
described in [2], the node that first requests a data item
not found in the network becomes the CN for it. This
simple strategy may not necessarily be optimal, but if it is
more likely for that same node or other neighboring nodes
to request the same data item in the future, then our
strategy could be advantageous. In any case, other
strategies, like trying to distribute the cache data as
uniformly as possible in the network, could be studied.
Another important topic for future consideration is the
security of the system. The design we presented in this
paper did not take into consideration the issues of node and
network security. Since nodes in SSUM need to cooperate
with each other in order to answer a query, it is important
that they trust each other. Also, since QDs are the central
component of the system, they could be the target of
malicious attacks. For this reason, we present some ideas
that improve the security of the system and leave their
implementation to a future paper.
In [2], we focused on the fact that each QD to be elected
must have a sufficiently high score that is computed as a
combination of resources available to the node. Just like we
have focused on the resources of the QDs, we should also
focus on their trustworthiness. For this, a node that is to be
considered a candidate QD must have a high enough trust
value. In this regard, several works such as [7], [26], and
[28] have proposed different solutions to ensure trust
between nodes. For our system, we can, for example, adopt
the method in [28] when electing a new QD. It is based on
the notion of having multiple nodes jointly monitor a
particular node to ensure its trustworthiness by cooperating
to compute a certain trust value for the monitored node.
Therefore, the additional condition that a node must meet in
order to be considered by the QD election process is for its
trust value to be above a certain threshold.
Although applying a trust-based scheme as in [28] helps
in detecting the behavior of malicious nodes and preventing
792 IEEE TRANSACTIONS ON MOBILE COMPUTING, VOL. 9, NO. 6, JUNE 2010
TABLE 3
Summary of the Discussed Consistency Methods
Authorized licensed use limited to: muthu m. Downloaded on June 27,2010 at 05:45:28 UTC from IEEE Xplore. Restrictions apply.
them from performing further damage, it will not be able to
avoid the initial damage that could be inflicted by such
nodes. Moreover, some attacks are very dangerous and
should be prevented before they succeed (like performing a
Denial of Service (DoS) on a QD, or submitting fake
requests to learn if and where particular sensitive data are
cached in the network). In order to prevent such attacks,
tight security schemes must be deployed. For example, the
approach in [7] proposes a distributed firewall mechanism
for detecting and recovering from DoS and flooding attacks.
The approach in [26], on the other hand, ensures data
confidentiality, integrity, and availability by establishing a
security association (SA) between each two end-to-end
communicating nodes. Both approaches were discussed
and evaluated in [24] from which we can deduce that [7] is
better suited since it satisfies many security requirements,
while [26] introduces much overhead as it requires data
redundancy. For our future work, we will do a thorough
investigation of the possible threats that could disrupt the
operations of SSUM and devise security mechanisms that
safeguard it by either building on existing approaches, like
[7] and [28], and/or developing new ones.
APPENDIX A
EXPECTED NUMBER OF HOPS TO A RANDOMLY
SELECTED NODE
We assume a rectangular topology with area o / and
uniform distribution of nodes. Two nodes can form a direct
link if the distance A between them is less than or equal to
i
0
, where i
0
is the maximum node transmission range.
Using stochastic geometry, the probability density function
of A is given in [6] as follows:
1r
4r
o
2
/
2

2
o/ or /r 0.5r
2
_ _
0 r < / < o.
It is concluded that if two nodes are a distance r
0
from each
other, the number of hops between them, when there are
sufficient number of nodes to form a connected network,
would tend toward r
0
,i
0
. Hence, H
1
, the expected
minimum number of hops between any two nodes in the
network, is equivalent to dividing 1A, the expected
distance, by i
0
. It should be noted that the value of H
1
represents a lower bound because when nodes are sparse in
the network, the number of hops will inevitably increase
due to having to route through longer distances to reach a
certain node. When o /, the expected number of hops as is
depicted in [6] is H
1
0.521o,i
0
.
APPENDIX B
EXPECTED NUMBER OF HOPS TO THE EXTERNAL
NETWORK
Assuming an o o topography filled with a sufficient
number of nodes that are uniformly distributed, the
expected distance to the AP, assumed to be at the corner, is
1A
1

_
o
0
_
o
0
1
o
2

r
2
y
2
_
drdy.
This seemingly trivial problem has a complex solution
which is the outcome of using tables of integration and the
Mathematica software:
1A
1

1
o
2
_
o
0
1
2
_
r

r
2
y
2
_
log
_
r

r
2
y
2
_
_
o
0
_
dy

1
o
2
_
o
0
1
2
_
o

o
2
y
2
_
log
_
o

o
2
y
2
_
_
log jyj
_
dy

1
2o
2
_
2
3
oy

o
2
y
2
_

1
3
y
3
logy

1
3
y
3
log
_
o

o
2
y
2
_
_

1
3
o
3
log
_
y

o
2
y
2
_
_
o
0
_

1
2o
2
_
2
3
o
2

2o
2
p

1
3
o
3
logo
2
3
o
3
log
_
o

2o
2
p
_
_

1
2
_
2
3
o
3
logo
_

_
1
3

2o
2
p

1
3
o logo
1
3
o log
_
o

2o
2
p
_
_

1
3
_
o

2
p
o logo o log o
_
1

2
p _
_

1
3
_

2
p
log
_
1

2
p _
_
o 0.7652o.
After dividing the result by the transmission range, i
0
, we
get the expected number of hops H
C
which is equal to
H
C
1o
1
,i
0
0.7652o,i
0
.
APPENDIX C
EXPECTED NUMBER OF HOPS TO THE QD WITH DATA
AND TO THE LAST QD
Referring to the probability density function 1r in
Appendix A, the probability of the distance being greater
than a value i is 1
ri
i
_
1
r
1rdr. The minimum
distance routing is about selecting the minimum from the
set of multiple independent random variables. Given `
Q1
random variables, we can represent this by a vector of
random variables A r
1
. r
2
. r
3
. . . . r
`
o1
. The random
variables are iid with pdf 1r, and the pdf of selecting
the minimum of A is
1
minA
i

`Q1
i1
1
A
r
i
i j r
,
i. 8, 6 i

`
Q1
i1
1r
i
i

`
Q1
,1.,6i
1
r
,
i
i
_ _

`
Q1
i1
_
1r
i
i1
ri
i
`
Q1
1
_

`
Q1
i1
1r
i
i1
ri
i
`
Q1
1
`
Q1
1r
i
i1
ri
i
`
Q1
1
.
MERSHAD AND ARTAIL: SSUM: SMART SERVER UPDATE MECHANISM FOR MAINTAINING CACHE CONSISTENCY IN MOBILE... 793
Authorized licensed use limited to: muthu m. Downloaded on June 27,2010 at 05:45:28 UTC from IEEE Xplore. Restrictions apply.
Hence, the expected distance to the nearest QD given `
Q1
choices is
11
minA

_
1
0
i1
minA
idi
`
Q1
_
1
0
i1i
_
1
i
1idi
_ _
`
Q1
1
di.
Assuming a sufficiently large number of nodes in the
network, the expected number of hops to the nearest QD is
11
minA
divided by i
0
:
1H
Q1icoic:t

`
Q1
i
0
_
1
0
i1i
_
1
i
1idi
_ _
`
Q1
1
di.
To calculate the average number of hops to get to the QD
with the desired data, we multiply the probability 1
i
that
QD
i
has the data with the average number of hops to
contact each QD and then take the sum. Hence, the
expected number of hops to get to the QD with the data is
1H
Q1
1oto

`
Q1
i1
1
i
1H
i
Q1icoic:t
.
where the superscript i was used to signify that the number
of QDs is i when computing the expected number of hops
1H
Q1
icoic:t
inside the summation.
Finally, we calculate the average number of hops to get
to the last-traversed QD. This is simply the sum of the
expected number of hops when there are `
Q1
choices, then
`
Q1
1 choices, and so on until we have one choice left.
This is expressed below:
1H
Q1
1o:t

`
Q1
i1
1H
i
Q1icoic:t
.
APPENDIX D
EFFECT OF QD DISCONNECTIONS ON NETWORK
TRAFFIC AND RESPONSE TIME
As was explained in Section 2.2, when a QD disconnects
from the network, a new QD is elected and the CNs that
cache data items whose queries were stored in the
disconnected QD cooperate to build the cache of the new
QD. This process affects both the response time and the
bandwidth consumption of the system. In [2], we derived
the expected node disconnection rate in the network,
1`
di:c
, and showed that for o 1.000 m, i
0
100 m,
100 nodes, and an average speed of 2 m/s, we get 1`
di:c

0.067 disconnections per second. We now compute the
resultant response time and traffic overhead.
Suppose that the average number of queries held by a
QD is i
Q1
, the total number of data items cached in the
server is i, the number of QDs is `
Q1
, and the total number
of nodes is `, then the extra delay T

that is attributed to
QD disconnections in a one second time period is
T

i
Q1
i
1`
di:c

`
Q1
`
T
ii
H

T
ii
H
C
T
ont
T
ii
H
C
.
The above expression reflects the fact that a request for a
query that was cached on the departed QDwill be forwarded
to the server the first time it is submitted after the
disconnection. As a realistic scenario, if we take ` 100,
`
Q1
7, i 10.000, i
Q1
250, and the default values of
T
ii
, T
ont
, H
C
, and H

as we considered in [2] (T
ii
5 ms,
T
ont
40 ms, H
C
5.21 hops, and H

21 hops), then T

will be equal to0.023 ms. This value is insignificant compared

to the average response time of the system(70 ms as shown in
the simulations).
Similarly, the extra bandwidth consumed due to QD
disconnections can be shown to be
1\

1`
di:c

`
Q1
`
1
Q1c|cct
`
C`
o
1
H
C
.
where 1
Q1c|cct
is the extra traffic required to elect a new QD,
`
C`
is the average number of CNs that cache data items
whose queries are cached in the disconnected QD, and o
1
is
the size of the packet sent by a CN to the new QD to help it
build its cache. Since the QD election packet traverses all
nodes sequentially (see [2] for details), then 1
Q1c|cct
can be
computed as (` 1 o
1
o

), where o
1
is the size of the
election packet, o

is the size of the QD assignment packet,

and `
C`
can be approximated by `
C`
`,`
Q1
. Again, if
we consider the default values of o
1
, o
1
, and o

as in [2]
(o
1
2 Kb, o
1
1 Kb, and o

1 Kb) with the same value

of `
Q1
, `, H
C
as above, then 1\

becomes 1.12 Kb/sec.

From Section 4, the average bandwidth consumption of
SSUM is normally around 10 Kb/sec. Hence, the extra traffic
is much smaller than the total bandwidth consumption (a
fact that we prove in Section 4.10).
REFERENCES
[1] S. Acharya, R. Alonso, M. Franklin, and S. Zdonik, Broadcast
Disks: Data Management for Asymmetric Communications
Environments, Proc. ACM SIGMOD, pp. 199-210, May 1995.
[2] H. Artail, H. Safa, K. Mershad, Z. Abou-Atme, and N. Sulieman,
COACS: A Cooperative and Adaptive Caching System for
MANETS, IEEE Trans. Mobile Computing, vol. 7, no. 8, pp. 961-
977, Aug. 2008.
[3] H. Artail and K. Mershad, MDPF: Minimum Distance Packet
Forwarding for Search Applications in Mobile Ad Hoc Net-
works, IEEE Trans. Mobile Computing, vol. 8, no. 10, pp. 1412-
1426, Oct. 2009.
[4] O. Bahat and A. Makowski, Measuring Consistency in TTL-
Based Caches, Performance Evaluation, vol. 62, pp. 439-455, 2005.
[5] D. Barbara and T. Imielinski, Sleepers and Workaholics: Caching
Strategies for Mobile Environments, Proc. ACM SIGMOD, pp. 1-
12, May 1994.
[6] C. Bettstetter and J. Eberspacher, Hop Distances in Homoge-
neous Ad Hoc Networks, IEEE Proc. 57th IEEE Semiann. Vehicular
Technology Conf., vol. 4, pp. 2286-2290, Apr. 2003.
[7] N.A. Boudriga and M.S. Obaidat, Fault and Intrusion Tolerance
in Wireless Ad Hoc Networks, Proc. IEEE Wireless Comm. and
Networking Conf. (WCNC), vol. 4, pp. 2281-2286, 2005.
[8] J. Cai and K. Tan, Energy-Efficient Selective Cache Invalidation,
Wireless Networks J., vol. 5, no. 6, pp. 489-502, Dec. 1999.
[9] J. Cao, Y. Zhang, L. Xie, and G. Cao, Consistency of Cooperative
Caching in Mobile Peer-to-Peer Systems over MANETs, Proc.
Third Intl Workshop Mobile Distributed Computing, vol. 6, pp. 573-
579, 2005.
[10] G. Cao, A Scalable Low-Latency Cache Invalidation Strategy for
Mobile Environments, IEEE Trans. Knowledge and Data Eng.,
vol. 15, no. 5, pp. 1251-1265, Sept. 2003.
[11] P. Cao and C. Liu, Maintaining Strong Cache Consistency in the
World-Wide Web, IEEE Trans. Computers, vol. 47, no. 4, pp. 445-
457, Apr. 1998.
794 IEEE TRANSACTIONS ON MOBILE COMPUTING, VOL. 9, NO. 6, JUNE 2010
Authorized licensed use limited to: muthu m. Downloaded on June 27,2010 at 05:45:28 UTC from IEEE Xplore. Restrictions apply.
[12] Y. Chung and C. Hwang, Transactional Cache Management with
Aperiodic Invalidation Scheme in Mobile Environments, Ad-
vances in Computing Science, pp. 50-61, Springer, 1999.
[13] A. Elmagarmid, J. Jing, A. Helal, and C. Lee, Scalable Cache
Invalidation Algorithms for Mobile Data Access, IEEE Trans.
Knowledge and Data Eng., vol. 15, no. 6, pp. 1498-1511, Nov. 2003.
[14] H. Jin, J. Cao, and S. Feng, A Selective Push Algorithm for
Cooperative Cache Consistency Maintenance over MANETs,
Proc. Third IFIP Intl Conf. Embedded and Ubiquitous Computing, Dec.
2007.
[15] IEEE Standard 802.11, Wireless LAN Medium Access Control (MAC)
and Physical Layer (PHY) Specification, IEEE, 1999.
[16] J. Jing, A. Elmagarmid, A. Helal, and R. Alonso, Bit-Sequences:
An Adaptive Cache Invalidation Method in Mobile Client/Server
Environments, Mobile Networks and Applications, vol. 15, no. 2,
pp. 115-127, 1997.
[17] J. Jung, A.W. Berger, and H. Balakrishnan, Modeling TTL-Based
Internet Caches, Proc. IEEE INFOCOM, Mar. 2003.
[18] X. Kai and Y. Lu, Maintain Cache Consistency in Mobile
Database Using Dynamical Periodical Broadcasting Strategy,
Proc. Second Intl Conf. Machine Learning and Cybernetics, pp. 2389-
2393, 2003.
[19] B. Krishnamurthy and C.E. Wills, Piggyback Server Invalidation
for Proxy Cache Coherency, Proc. Seventh World Wide Web
(WWW) Conf., Apr. 1998.
[20] B. Krishnamurthy and C.E. Wills, Study of Piggyback Cache
Validation for Proxy Caches in the World Wide Web, Proc.
USENIX Symp. Internet Technologies and Systems, Dec. 1997.
[21] D. Li, P. Cao, and M. Dahlin, WCIP: Web Cache Invalidation
Protocol, IETF Internet Draft, http://tools.ietf.org/html/draft-
danli-wrec-wcip-01, Mar. 2001.
[22] W. Li, E. Chan, Y. Wang, and D. Chen, Cache Invalidation
Strategies for Mobile Ad Hoc Networks, Proc. Intl Conf. Parallel
Processing, Sept. 2007.
[23] S. Lim, W.-C. Lee, G. Cao, and C.R. Das, Performance
Comparison of Cache Invalidation Strategies for Internet-Based
Mobile-Ad Hoc Networks, Proc. IEEE Intl Conf. Mobile Ad-Hoc
and Sensor Systems, pp. 104-113, Oct. 2004.
[24] M.N. Lima, A.L. dos Santos, and G. Pujolle, A Survey of
Survivability in Mobile Ad Hoc Networks, IEEE Comm. Surveys
and Tutorials, vol. 11, no. 1, pp. 66-77, First Quarter 2009.
[25] H. Maalouf and M. Gurcan, Minimisation of the Update
Response Time in a Distributed Database System, Performance
Evaluation, vol. 50, no. 4, pp. 245-266, 2002.
[26] P. Papadimitratos and Z.J. Haas, Secure Data Transmission in
Mobile Ad Hoc Networks, Proc. ACM Workshop Wireless Security
(WiSe 03), pp. 41-50, 2003.
[27] J.P. Sheu, C.M. Chao, and C.W. Sun, A Clock Synchronization
Algorithm for Multi-Hop Wireless Ad Hoc Networks, Proc. 24th
Intl Conf. Distributed Computing Systems, pp. 574-581, 2004.
[28] W. Stallings, Cryptography and Network Security, fourth ed. Prentice
Hall, 2006.
[29] D. Wessels, Squid Internet Object Cache, http://www.
squid-cache.org, Aug. 1998.
[30] J. Xu, X. Tang, and D. Lee, Performance Analysis of Location-
Dependent Cache Invalidation Schemes for Mobile Environ-
ments, IEEE Trans. Knowledge and Data Eng., vol. 15, no. 2,
pp. 474-488, Feb. 2003.
[31] L. Yin, G. Cao, and Y. Cai, A Generalized Target Driven Cache
Replacement Policy for Mobile Environments, Proc. Intl Symp.
Applications and the Internet (SAINT 03), Jan. 2003.
[32] J. Yuen, E. Chan, K. Lain, and H. Leung, Cache Invalidation
Scheme for Mobile Computing Systems with Real-Time Data,
SIGMOD Record, vol. 29, no. 4, pp. 34-39, Dec. 2000.
[33] D. Zhou and T.H. Lai, An Accurate and Scalable Clock
Synchronization Protocol for IEEE 802.11-Based Multihop
Ad Hoc Networks, IEEE Trans. Parallel and Distributed Systems,
vol. 18, no. 12, pp. 1797-1808, Dec. 2007.
[34] G. Zipf, Human Behavior and the Principle of Least Effort. Addison-
Wesley, 1949.
Khaleel Mershad received the BE degree with
high distinction in computer engineering and
informatics from Beirut Arab University, Leba-
non, in 2004, and the ME degree in computer
and communications engineering from the
American University of Beirut (AUB) in 2007.
He is currently working toward the PhD degree
at AUB, where he is doing research in the area
of data availability in mobile ad hoc networks.
Hassan Artail received the BS and MS degrees
in electrical engineering with high distinction
from the University of Detroit in 1985 and 1986,
respectively, and the PhD degree in electrical
and computer engineering from Wayne State
University in 1999. He is currently an associate
professor at the American University of Beirut
(AUB) and is doing research in the areas of
Internet and mobile computing, mobile ad hoc
networks, and vehicle ad hoc networks. During
the past six years, he has published more than 80 papers in top
conferences and reputable journals. Before joining AUB in 2001, he was
a system development supervisor at the Scientific Labs of Daimler-
Chrysler, where he worked for 11 years in the field of software and
system development for vehicle testing applications. He is a senior
member of the IEEE.
> For more information on this or any other computing topic,
please visit our Digital Library at www.computer.org/publications/dlib.
MERSHAD AND ARTAIL: SSUM: SMART SERVER UPDATE MECHANISM FOR MAINTAINING CACHE CONSISTENCY IN MOBILE... 795
Authorized licensed use limited to: muthu m. Downloaded on June 27,2010 at 05:45:28 UTC from IEEE Xplore. Restrictions apply.