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

bile peer makes its final decision on whether
to prefetch D according to the importance of
D to it, the number of announcement mes-
sages it received, and some random factor.
If the final decision is still “yes”, the mobile
peer prefetches D ; otherwise, the mobile
peer does not prefetch it.

A simple application of this idea can be
dangerous. First, a prefetched data object may
be replaced by a more valuable data object soon
after it was prefetched. Telling neighbors that it
will prefetch data object D does not tell how long
D will be kept in its cache. Accordingly, simply
knowing that some neighbors will prefetch D , a
mobile peer does not know the extent of reliance
it can put on its neighbors. Second, if all mobile
peers choose not to prefetch a data object because
they think that their neighbors are prefetching it,
no one prefetches the data object. They both result
in a situation where some neighbors claimed to
prefetch a data object but it is not available when
someone wants to access the data object.
These problems are solved by enforcing the
following two rules in the cooperation scheme:
1) a mobile peer informs its neighbors that it will
prefetch a data object only when it will keep the
data object in cache for certain time; 2) random-
ization is applied to let at least one of the mobile
peers (that showed intention to prefetch the data
object) prefetch the data object.
Considering these factors, ACP strategy is
designed as follows:

That is, when a mobile peer decides to prefetch
D and believes it will cache D for a quite long
time, it sends out an announcement message to
its neighbors; a mobile peer's final prefetching
decision for D is based on both the importance of
D and the number of neighbors who will prefetch
D . The objective of the announcement is to affect
the neighbors' prefetching decisions. Note that
the announcement should be made before the
broadcast of D , but the mobile peers need not
make announcement at the same time. To reduce
the chance that a peer makes an announcement
but moves away from its neighbors, a peer should
send out the announcement close to the time the
associated object will be broadcast.
There are two details of ACP to be addressed:
1) How to predict the time D will be in cache
and whether it deserves an announcement? 2)
How should the neighbors' announcements for
D , if any, affect a mobile peer's final prefetching
decision for D ?

• Before a data object D is broadcast (we

assume broadcast index is available so that
the mobile peers know when each data ob-
jects will be broadcast), every mobile peer
decides whether to prefetch D based on the
PT heuristic, and we call this the first deci-
sion .
○

Deciding Whether to Send Out
Announcement

If the first decision is “yes” then the
mobile peer further predicts how long
D will be in cache.
 If it predicts that D will be in its
cache for a long time, then the mo-
bile peer broadcasts an announce-
ment message to its neighbors.

Each mobile peer makes its first decision for D
with the PT individual prefetching scheme. If
there is empty cache space, the first decision is
“yes”; if the cache space is full, the mobile peer
checks the cached objects and see whether there
is a cached object whose PT value is lower than
the PT value of D , if so, the first decision is “yes”,
otherwise, the first decision is “no”.
In ACP, every mobile peer records how long
a data object was kept in its cache the last time:
when a data object is prefetched, the mobile peer

• Each mobile peer whose first decision is

“yes” counts the number of announcement
messages for D it receives.

• When D appears on the channel, every mo-