Peer-Based Collaborative Caching and Prefetching in Mobile Broadcast - Advanced Operating Systems and Kernel Applications - page 251

records the timestamp, and when the data object
is replaced, it calculates the time the object is
in cache and records it. The recorded keeping
time of D is used to predict how long D will be
in cache this time.
If the first decision is “yes”, the mobile peer
decides whether to send out an announcement by
checking the following inequality.

A mobile peer that receives more announce-
ment messages for D means it can rely more on
its neighbors for D , since the chance that all of
t h e m m o v e b e y o n d t h e m o b i l e p e e r 's c o m m u n i c a -
tion range is lower and it is more possible for the
mobile peer to get D from its neighbors. Thus in
our scheme, the total reliance the mobile peer can
put on its neighbors for D is g* n .

keeping time
Tinterval

When D is broadcast, each mobile peer makes
its final prefetching decision for D as follows.

≥

δ

Here δ is a threshold parameter greater than
zero, and Tinterval is the time between two
consecutive broadcasts of the data object. If the
inequality is satisfied, the mobile peer sends out
an announcement, otherwise it does not. The in-
tuition is: when an announcement for D is made,
the neighbors know that the mobile peer may
keep D longer than Tinterval *δ, so they may have
confidence to rely on the mobile peer for D .
Note that δ is a parameter that can be tuned.
Also note that a mobile peer whose first decision
for D is “yes” should count the number of the
announcement messages for D it receives.

• If the first decision is “no”, the final decision

is “no”.

• If the first decision is “yes” and the mobile

peer did not send out announcement for D ,
then check whether the following inequality
is satisfied.

PT d (1 - g* n ) > PT c

• If the inequality is satisfied, the final deci-

sion is “yes”, otherwise it is “no”.

• If the first decision is “yes” and the mobile

peer has sent out an announcement for D ,
then if g* n is smaller than 1, the final deci-
sion is “no”, else (g* n is greater than 1) the
mobile peer generates a random number p
between 0 and 1, if p is bigger than 1/(g* n ),
the final decision is “no”, else the final deci-
sion is “yes”.

Making Final Decision

In ACP, a mobile peer's final prefetching decision
for D is determined by the following factors:

1. PT d , the PT value of D ;
2. PT c , the PT value of the replace candidate (the
cached object with the lowest PT value);
3. g, the reliance parameter;
4.

The intuition of the final decision process is:
a) If the first decision is “no”, D is not important
for the mobile peer, so the mobile peer should not
prefetch D . b) If the first decision is “yes” but the
mobile peer did not send out an announcement, D
is not very important to the mobile peer, and the
mobile peer's neighbors will not rely on the mobile
peer for D , so the mobile peer is free to decide
whether to prefetch D based on the total reliance
it can put on its neighbors. It checks whether it is
still beneficial to prefetch D after considering the
possibility that it can get D from its neighbors. c)

, the number of announcement messages
for D the mobile peer received.

Here g(0 < g≤ 1) is a parameter modeling
the extent of reliance a mobile peer can put on a
neighbor who sent out an announcement for D . In
other words, g models the probability that when
the mobile peer has a query for D the neighbor
still has D and is within the mobile peer's com-
munication range.