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

channel. As in (Wu, 2005), we call this kind of
schemes cooperative prefetching schemes.
In (Hara, 2002), the author proposed two co-
operative schemes for mobile peers in push-based
broadcast systems, namely GOP (Global OPtimal)
and SOP (Stable group OPtimal). The author calls
them cooperative caching schemes. They are
classified as cooperative prefetching schemes in
this chapter because their behaviors of caching
are triggered by the broadcast rather than data
accesses. In GOP, the mobile peers construct an
ad-hoc network and cooperate through multi-hop
communication. The idea is to exchange informa-
tion of access interests and cached objects among
all connected mobile peers each time when a data
object is broadcast, and then one of the mobile
peers collects this information and decides glob-
ally which mobile peer(s) should cache the data
object according to the network topology. Finally
the decision is flooded to all mobile peers and
every one conducts a behavior according to the
decision. GOP is not practical when the number
of mobile peers is large, because large amount
of control information and long computational
time are needed for every caching decision. In
SOP (Stable group OPtimal), data objects are
cooperatively cached in stable groups of mobile
peers. SOP works better than GOP because limit-
ing the cooperation in a stable group guarantees
data availability and reduces communication
overhead.

highly dynamic. Second, they consider the data
availability from neighbors but fail to consider the
data availability on the broadcast channel. Third,
they require synchronization of a lot of information
in a group, such as cache summary and access
interests. This will incur high communication
cost (and power consumption), because the cache
summary of neighbors need to be updated quite
frequently.
We identify two challenges for the mobile peers
to manage caching cooperatively in a broadcast
environment. The first is to handle the dynamics
of the neighborhoods (topology). The second is
to consider data objects' multiple availabilities
in the system.
The dynamics of peer's neighborhood is due
to the movement of the peers. The changes of
neighborhoods make it infeasible to take the cache
spaces of the mobile peers in a neighborhood as
a whole and manage it for the benefit of all the
involved mobile peers. Managing cache space in a
neighborhood as a whole imposes several require-
ments: 1) a clear division of peers to neighborhoods
(or groups); 2) synchronization of access interests
in a neighborhood; 3) agreement on which peer
should cache what data objects. The movement
of peers makes these requirements very difficult
and expensive to achieve, because

• There is no agreement on which

neighborhood(s) a mobile peer belongs to--
a mobile peer has one neighborhood but
belongs to many neighborhoods at the same
time. Take the mobile peers in Figure-1 as an
example. M a belongs to the neighborhoods of
M b , M c , and M d . Which neighborhood shall
it participate in? And who shall coordinate
the neighborhood?

iSSueS, controVerSieS,
problemS

The aforementioned cooperative schemes have
several common drawbacks. First, they all try to
find stable groups of mobile peers (i.e. group of
peers that are within each other's communication
range for certain amount of time). Because of this,
they are only suitable for environments where
groups of mobile peers do exist, and cannot be
applied to scenarios where the mobile peers are

• Even though methods are used to divide

the mobile peers into neighborhoods and
to select a leader, the neighborhoods are
changing frequently. This may incur a lot
of information exchange, because each
time a neighbor leaves or a new neighbor