MoB: A Mobile Bazaar for Wide-area
Wireless Services
Rajiv Chakravorty
Sulabh Agarwal
Suman Banerjee
U. of Wisconsin-Madison
Ian Pratt
U. of Cambridge
Presented by Nir Peer
University of Maryland
Introduction
 Growing usage of mobile devices
 various types and form factors, e.g., PDAs, smartphones,
portable PCs
 Increased availability of wireless data networks
 Higher bandwidth cellular data networks
 802.11 WLAN hotspots
 Intermittent Internet connectivity
 WLAN coverage is spotty, more so for public hotspots
 Cellular coverage also not ubiquitous
 often suffers from high latency, low bandwidth, link stall, etc.
2
Introduction
 Leads to poor performance of networked
applications on mobile devices
3
Introduction
 Solution: Mobile Bazaar (MoB)
 Architecture to improve data services for wide-area wireless
users
 Open market, collaborative
 New model for data services
 Decoupling of infrastructure providers from services
providers
 Fine-grained competition over provisioning
 Service interactions of arbitrary timescales
 Flexible composition of services
4
Fine-grained competition
 Coarse-grained competition
 User chooses one cellular provider
 Signs a long-term contract (in the order of hours to years)
 Exercises choice with large time gaps
 User might not be able to access the Internet
 in regions where his provider has poor coverage
 In MoB, fine-grained competition
 Choose and change providers at arbitrarily small timescales
 Can choose the current “best” provider
 Can temporarily choose multiple providers simultaneously
5
Fine-grained competition
 Users can resell unused resources
 e.g., idle cell-phone resells bandwidth to nearby laptop experiencing a
slow connection
 Micropayments system supports resource trades
 Advantages
 Ad-hoc purchase of additional resources from nearby users
 a way to boost application performance on demand
 Infrastructure provider is no longer the service provider
 Users no longer limited to services and rates offered by their
infrastructure provider
 Greater competition like in long-distance telephone services
6
Services in MoB
customer
traders
 Goal of MoB: enable incentive-induced service
collaboration between independent mobile
devices.
 Example: bandwidth aggregation service
7
Services in MoB
 Example, in detail
 Customer device is a wireless user (C1)
that is stationary in either
 static public environment (e.g., coffee shop or shopping mall)
 mobile environment (e.g., moving bus or train)
 Typically surrounded by other networked devices (e.g.,
cellphones, laptops, PDAs)
 3G-enabled cellphone (T1)
 PDA with an 802.11 wireless interface (T2)
 C1 discovers nearby T1,T2,T3. Then connects to a subset
T1,T3 and purchases their available bandwidth.
8
Services in MoB
 Possible services to trade
 High-bandwidth connectivity
 Location determination
 PDA equipped with navigational tool but without GPS
 Can purchase location info. from any in-range MoB trader
 Time synchronization
 Mobile game-console participates in a multi-player game
 Needs accurate time synchronization
 Network Time Protocol (NTP) can be fairly expensive
 Can buy global time info. from a nearby cellphone trader
9
Services in MoB
 Possible services to trade (cont’d)
 Web proxy caching
 User browsing the web over a slow and expensive cellular link
 Can buy cached copies from its wireless vicinity (proxy ondemand)
 Bandwidth aggregation for media streaming
 GPRS user wants to receive high-quality video stream
 Can buy spare bandwidth from multiple nearby 3G cellphones
 Use app.-level proxy to intelligently stripe stream over these
connections
10
Services in MoB
 Possible services to trade (cont’d)
 Peer-to-peer data search
 User conducting legal filesharing through Gnuetalla or KaZaA
 May have to deal with loss of connectivity and high-costs
 Can try first to look for data available in the local environment
 Like in Microsoft’s Zune
 Traffic filtering
 A resource-constrained wireless device
 In addition to buying bandwidth, can pay for malicious content
filtering
11
Services in MoB
 Services are advertised and
discovered using the Service
Location Protocol (SLP, RFC2608)
 Difficulties of managing multi-hop paths
 Cost distribution
 Accountability in case of failure
 In MoB all interactions are pairwise (single-hop)
 Anyway multi-hop interactions will be relatively rare
 Composed service interactions are also treated
independently
 A nearby Italian restaurant recommendation
12
Services in MoB
 Service interactions are implemented in the
application layer
 Suppose C2 is performing P2P file d/l from T3 via X
 Two independent TCP connections, one for each hop
 All multi-hop interactions are composed of multiple singlehop app.-layer service interactions
 Conversely, in ad-hoc networks an on-demand
network-layer end-to-end path is used
13
Pricing and Reputation
 MoB is an open market with no regulation on
advertised services or prices (think eBay)
 Market forces will probably govern pricing
 This has to be supported by




A reputation and trust management system
A billing and accounting system
Can potentially be offered as third-party services
In this paper, implemented as one system called Vito
14
Applicable environments
 An environment with many opportunities of collaboration
between in-range devices
 A study of resource sharing opportunities
 How long a user stays in a coffee-shop?
 Two different measurement techniques
 Time-sheet at the counter, sign-in and sign-out
 On site observer monitoring for two hours
 Results
 More than 2/3 spent more than 2 minutes
 At least 50% spent 10+ minutes
 A significant fraction spent over 30 minutes
 Conclusion: significant opportunities of long-lived MoB interactions
15
Salient features
 Open market architecture




Any device can autonomously advertise services
Supports separate service level agreements with traders
Each SLA can potentially last over small timescale
Flexibility to resell idle resources
 Better performance through Wirless Diversity




Technologies (cellular: CMDA, GPRS, WLAN: 802.11b/g)
Networks (Sprint, AT&T, Boingo)
Channels (transmission frequencies)
Can mix-and-match the “best” local links to improve performance
16
Salient features
 Incentive-based Collaboration
 Traders provide services in return for monetary benefits
 Customization and Support for Diverse
Applications
 Supports on-demand customization
 Examples:
 Utilize cache only when surfing the web
 Obtain location info. for navigation only when driving
 Aggregate bandwidth resources for a specific file transfer
17
MoB Architecture
MoB architecture
Internet
Networking
infrastructure
Mobile devices
3rd party services for
accounting and billing,
reputation and trust
management
19
MoB architecture
 Modes of operations
 Incentive-based
 Service provided in exchange for financial incentive
 With no trust assumptions
– Both parties use a central reputation system (like Vito)
Derive trust from past trade histories
 With trust assumptions
– Mutual trust between trade parties
e.g., due to multiple successful interactions in the past
 Altruistic
 Perfect trust and no financial incentives
e.g., within a friend’s network
20
Vito Design
 An eBay like reputation system
 Centralized 3rd party service in the wired Internet
 Design
 Each registered user obtains a timestamped reputation certificate
 this certificate records both successful and unsuccessful transaction
 During trade, customer and trader examine each other’s reputation
certificate. May reject old certificates.
 After transaction, they upload feedback scores to Vito
 Multiple reputation management systems may coexist
21
Operations in MoB
User A
 User A registers using
its public key, KA+
 Vito issues a reputation
certificate RA
Vito
User B
Register KA+
Accept
RA:[TS1, ScoreA, KA+]KVito−
Register KB+
Accept
RB:[TS2, ScoreB, KB+]KVito−
A and B independently register with Vito
Vito’s private key, KVito−
 This certificate is signed using
 It includes a timestamp TS1
 Contains positive and negative feedback counts for A, ScoreA
 Vito does not keep state for A
 Equipped with the reputation certificate, A can engage
in trades with other users
22
Operations in MoB
User A
 Services are discovered
and advertised using
the Service Location
Protocol (SLP)
 To request a service
in its wireless vicinity A
multicasts a Service Request
to 239.255.255.253:427
Vito
User B
SLP Srv Req RA, [TS3]KA−
SLP Srv Resp
RB, [TS3, TS4, Price]KB−
Token
T: [TS4, TS5, A, B, Price]KA−
Service interactions
A and B interact, no need to access Vito
 TTL is chosen to be 1, since in MoB service interactions are pairwise
23
Operations in MoB
User A
Vito
 Consider the scenario
SLP Srv Req RA, [TS3]KA−
 A multicasts a Service
Request for a 30Kbps
forwarding service
SLP Srv Resp
RB, [TS3, TS4, Price]KB−
Token
T: [TS4, TS5, A, B, Price]KA−
 It includes A’s reputation
 SLP Service Agent B responds
with a service description (25Kbps)
and a price quote
User B
Service interactions
A and B interact, no need to access Vito
 It includes B’s reputation
 A sends a Service Acceptance Notification to each of his chosen traders
 It includes a timestamp and payment amount
 B starts operating as a NAT device for A
24
Operations in MoB
User A
Vito
 Scenario (cont’d)
Encash T, [TS6, B]KB−
 B presents token T to Vito
Token encashed
[TS6]KVito−
 Vito charges A
 Vito credits B
 This is counted as a
positive feedback for B from A
 B is charged a transaction fee
for the gained positive reputation
User B
Feedback
[TS7, B, A, Score]KB−
Reputation (updated)
RA
Reputation (updated)
RB
Nightly reputation and billing updates
 Once B receives credit it’ll typically report a positive feedback for A
 If A was dissatisfied, it’ll explicitly report negative feedback for B
25
Design Decisions
 Trader (B) uploads its own positive feedback
 Positive trader feedback benefits itself in future trades
 Thus, beneficiary is responsible for uploading feedback
 Trader uploads positive customer (A) feedback





Positive customer feedback contingent upon encashing of the token
The service token indicates the trade price and is signed by A
Vito will check A’s balance and inform B
Based on this response, B rates A
Studies show that expectation of a reciprocal positive rating encourages
voluntary feedback
26
Design Decisions
 Customer uploads negative feedback for trader
 Obviously trader has no incentive to reduce its positive
reputation
 Trader has no recourse if malicious customer always reports
negative feedback
 Same shortcoming in eBay
 Mitigating assumption: customers may be selfish but not
malicious
 When they received good service will not rate negatively
27
Design Decisions
 Customer pays prior to receiving service
 If we had let the customer pay after receiving service
 He might default the payment
 The trader wouldn’t have a proof of the transaction and no
further recourse (recall, the token is the payment)
 If customer pays first
 If trader encashes the service token, it in fact claims to having
provided the service
 If trader defaults in provisioning, customer can provide
negative feedback
28
Design Decisions
 Transaction fee charge
 A transaction fee is an incentive for the reputation service
provider
 Also implies no one can build up reputation for free
 Otherwise, construct multiple colluding identities
 Perform transactions between these identities
 Report positive feedback
29
Evaluation of the Reputation
Management Model
 For a reputation system to work in practice
 There has to be an expectation of future interaction between
entities; have to be long-lived
 Historical feedback is maintained and made available
 Past feedback guides buyer decisions
30
Evaluation of the Reputation
Management Model
 Challenges to making a reputation system really
robust
 Sybil attacks: a user with bad reputation acquires a fresh
identity
 Newcomers are always distrusted
 Unless they paid their dues, e.g. registration fee
 Alternative, require use of real names or prevent acquisition of
multiple pseudonyms
 Collusions: a group of users collaborate and rate each other
positively
 Avoid by using a transaction fee for reputation reporting
31
Evaluation of the Reputation
Management Model
 Challenges to making a reputation system really
robust (cont’d)
 Decentralized reputation management
 Current centralized solution might not scale
 Also may be desirable in many scenarios to decentralize
 Some approaches have been proposed in the context of P2P
networks
– they exploit pre-trusted peers
32
Implementation
Implementation
 MoB is implemented over Linux
 Clients include single and multiple wireless
interfaces
 Local wireless connectivity (e.g., Bluetooth)
 Global wireless connectivity (e.g., 3G)
 Installed on each MoB device as a middleware
34
Implementation
Accepts connections from MoB applications
passing them to the MoB manager
Checks local cache manager
for the requested object
In a cache miss, initiates a connection
setup with neighboring MoB device
Request/response are correlated using
URLs. Updates cache on response
At the receiving MoB device, a response handler
consults the local cache, or contacts other MoB
devices
May also retrieve object from the Internet if it has a
wide-area access interface, e.g., a 3G-1x/EvDO PC
card
35
Implementation
Regulates block-based app.-level data
striping of large data objects from
neighboring MoB devices
During download, changes block size, # of
parallel TCP connections, and their types
(e.g., persistency) to adapt to variable
degrees of user churn
Also, performs load-balancing
Part of the content processing engine.
Optionally performs compression, traffic
filtering, etc.
May downgrade image fidelity over slower
links
36
Implementation
Neighbor discovery using link-specific mechanisms
provided by different wireless interfaces.
In 802.11 a specific channel is allocated for
neighbor discovery. Periodically, the MoB device
goes into a promiscuous mode to discover other
devices.
In Bluetooth, the device initiates a scan procedure
to detect other in-range devices. It can connect to
its neighbor using dial-up networking (DUN). Then
it can establish an IP connection using point-topoint protocol (PPP) over a serial RFCOMM
channel (emulation of a serial port over Bluetooth).
37
Evaluating MoB Applications
Experimental Setup
 A prototype MoB system was implemented
 Experiments with




File-transfer applications
Web browsing
Media streaming
Location determination
 Communication
 Between customers and traders - Bluetooth, 802.11a/b
 Traders
 3G EvDO (2.4Mbps d/l and 153Kbps u/l)
 3G 1xRTT (144Kbps d/l and 64Kbps u/l)
39
File-transfer applications
 Data transfer from specific Internet location




FTP-like transfer of a large file
Customer requests a sequence of moderate sized blocks
Close to completion of one block transfer, requests the next
If new traders are available, will simultaneously download
blocks through them
40
File-transfer applications
 Data transfer from specific Internet location (cont’d)
Customer C uses Bluetooth
Trader T1 uses CDMA 1xRTT
Trader T2 uses CDMA EvDO
At t0 = 0, only T1 is in range of C
so C only downloads from it.
 T2 moves in-range of C at t1 = 12 and
is detected by C at t2 = 14
 T1 starts to move out-of-range of C around t3 = 45 and stays connected
until time 70 sec
 Between t2 and t3 C downloads from both. The aggregate throughput is
327.2Kbps




41
File-transfer applications
 Data location and retrieval
 Gnutella and KaZaA-style P2P data search and retrieval
 Study impact of different levels of churn on performance
 High: each potential trader stays in-range for 10-20 sec
 Medium: stays for 40-60 sec
 Low: stays 60-120 sec
 None: no trader mobility, serves as the base case
 In typical coffee-shop scenarios expect low or no churn
42
File-transfer applications
 Data location and retrieval (cont’d)





Customer locates nearby trader that has the queried object
Starts block-based download
We assume here it uses only one trader at a time
Searches for alternate trader only when it losses the current
Interaction is through the Bluetooth interface
43
Discussion
 Security
 MoB provides integrity of reputation certificates
 It does not address data security and integrity
 A user downloading sensitive data, should probably use
Secure Sockets Layer (SSL) to provide end-to-end security
 In some scenarios, providing security is not straightforward
 In distributed location determination, a malicious trader may
provide incorrect location information
 This info. can be cross-checked against other traders
 If a mismatch is detected, this can lead to negative feedback
44
Discussion
 Security
 Individual clients may employ different security mechanisms
 Based on their prior experience
 Based on their faith in behavior of others
 They can rely on the reputation system to provide useful
historical log
 They can choose to accept data from any trader, only those
with “reasonable” reputation, or just those they directly trust
45
Discussion
 Legal aspects
 Many services are traded between only two entities
 However, many times a client acts as a reseller
 This may raise legal issues
For example, 3G cellphone resells bandwidth to nearby laptop
Many ISPs prohibit reselling bandwidth
This is because they have no financial incentive
This may be solved by providing incentive-sharing techniques between
MoB participants
 An compensation agreement between the cellphone user and the 3G
network operator may be negotiated
 May be hard to enforce




46