It requires three basic functions: collaboration, multiplexing, and indirection.
1) Collaboration Among Mobile Hosts: The mobile community requires users to collaborate
by sharing/pooling their communication channels. However, what are the incentives for
users to collaborate? When only one host or a small set of members want to receive the
contents at others’ expenses, will the other members be willing to contribute their
bandwidths to enable the small set of members to achieve statistical multiplexing gains?
A somewhat related debate is underway with regard to forwarding incentives in ad hoc
network routing. In ad hoc networks, the communication between end points outside of the
radio transmission range relies on intermediate nodes on the path to forward packets for
them. Some researchers suggest use of credit-based, or reputation-based, schemes to
stimulate cooperation. Game-theoretic arguments have been used to show that collaboration
on packet forwarding among all participating nodes maximizes network throughput.
Forwarding in ad hoc networks, however, is somewhat different from the collaboration we
consider here. In ad hoc networks, nodes rely on each other to communicate amongst
themselves. In a mobile community, nodes rely on each other, not for basic connectivity
but for performance improvements.A node completely controls access to its shared
communication resources, and revokes access if its communication needs are not met by the
community. Ultimately, it is the ability to opt-in to achieve better performance and the
ability to opt-out when necessary, making link sharing a viable option. Nonetheless,
communities are more likely to be formed within domains where a pre-existing trust
(or cost-sharing) relationship exists. For example, an individual with multiple devices
(e.g., cell phone, PDA, laptop) interconnected with a personal area network can benet
from resource sharing, as in the case of teams of people working together.
2) Multiplexing: Given shared links, how can the mobile community aggregate link bandwidths
for a higher throughput? An inverse-multiplexer is a popular approach that aggregates
individual links to form a virtual high-rate link. For example, an inverse multiplexer
stripes the trafc from a server over multiple wireless links of the community members, each
of which then forwards the trafc to the receiver. Finally, the forwarded packets are merged
and assembled in the receiver at the aggregate rate. An important issue is then where to put
the inverse multiplexer. The inverse multiplexer can be placed at (1) a performance
-enhancing proxy (PEP) by a network access provider, a wireless telecommunication service
provider, or a content distribution network operator for downstream communications,
and (2) one of community members for upstream communications.
Within a proxy or a host, the multiplexer can be placed at the network layer as a routing
component with an efcient trafc ltering function as in the Network Address Translation (NAT)
service. Or, the inverse multiplexer might run as an application like in an overlay network.
However, multiplexing inherently requires responsive network state information, and additional
packet-processing overheads at the application layer limit the performance of the inverse multiplexer.
3) Indirection: Trafc from an inverse multiplexer to community members is tunneled via Generic
Routing Encapsulation (GRE). The inverse multiplexer encapsulates the trafc via GRE and routes
it to the community members’ WWANs. Upon its reception, each member de-capsulates the tunneled
trafc, and forwards it to a destination via WLAN. Since the destination is oblivious to which
member forwarded the data packets, no additional data reassembly functionality is required at
the receiver. Furthermore, because GRE tunneling is supported by most operating systems
(e.g., Linux, FreeBSD, the Windows), no system modication of mobile hosts is required.