Mohammad Al-Fares UC San Diego
Martin Johnsson Ericsson Research
Per Johansson Calit2
Amin Vahdat UC San Diego
Why ?
Compensation heterogeneity of wireless access operators and technologies. ◦ Devices with multiple bands/protocols (GSM/wi-fi/
bluetooth/etc.) ◦ Coverage is nearly universal, but access is not
Goal: Provide network composition/peering regardless of access technology. ◦ Network operators share each other’s networks ◦ Users can use resources of any network, while
preserving compensation fairness
Compensation heterogeneity of wireless access operators and technologies. ◦ Devices with multiple bands/protocols (GSM/wi-fi/
bluetooth/etc.) ◦ Coverage is nearly universal, but access is not
Goal: Provide network composition/peering regardless of access technology. ◦ Network operators share each other’s networks ◦ Users can use resources of any network, while
preserving compensation fairness
Common reservation and compensation system ◦ Establish on-the-fly roaming agreements Instead of n2 roaming agreements
◦ Consolidate usage “plan” from one home provider
◦ Control-plane should be global, open: the Internet
Adapt and implement a unified resource allocation mechanism. ◦ Evolution of SHARP’s global resource
federation system for PlanetLab using bartering
◦ Tickets and leases: Promises and rights to control certain resources at certain times
Fu, Y., Chase, J., Chun, B., Schwab, S., and Vahdat, A. SHARP: An Architecture for Secure Resource Peering. SOSP 2003.
◦ Resources fully described by RSpec
◦ Introduce tokens: abstract carriers of value Crypto-signed objects, unique, and used once
Legally binding to exchange with $
Allow common valuation and trading of different classes of resources
!"#$"%&%'(
)*%*+&,(
-.'&(
)*%*+&,(
/0&,(
1%'&,2*3&(
4&0"5,3&(
6,"7&,(
!"
#"
$"
Site Manager (SM): ◦ Manages resources and user accounts at a given site ◦ “Donates” resources to RB for tokens
!"#$"%&%'(
)*%*+&,(
-.'&(
)*%*+&,(
/0&,(
1%'&,2*3&(
4&0"5,3&(
6,"7&,(
!"
#"
$"
User Interface (UI): ◦ Stores tickets and tokens, manages resource discovery
◦ Enables resource requests from the Resource Broker
!"#$"%&%'(
)*%*+&,(
-.'&(
)*%*+&,(
/0&,(
1%'&,2*3&(
4&0"5,3&(
6,"7&,(
!"
#"
$"
Resource Broker (RB): ◦ Clearinghouse for resources; Matches requests to donations ◦ Verifies users’ token authenticity and given back a ticket for the
requested resource.
!"#$"%&%'(
)*%*+&,(
-.'&(
)*%*+&,(
/0&,(
1%'&,2*3&(
4&0"5,3&(
6,"7&,(
!"
#"
$"
Component Manager (CM): ◦ Honors tickets for previously SM donations
◦ Gives user access to resource
Localize RB, SM, CM at router Open network; access
managed using firewall rules: ◦ Allow control traffic to new users
SM donates “access-hour” ◦ Specifying rate, available BW, etc.
in RSpec
User ‘buys’ ticket from RB ◦ Tokens are checked (issuer sign.),
cancelled on usage
User presents ticket to CM ◦ Access is granted
!"#
$%#
&"#
'()*++#$,-./0#
122/33#4,56.#
76./06/.#
!/0852/#40,859/0#
:7# :7#
UI as an app on USIM SM+CM at BSC/RNC ◦ Donate unused capacity at
regular intervals
Common RB at Core Network ◦ Implementation network-
dependent, only require RB Internet access to check tokens
!"#$
%&'()&('$
*+$
*,$ -,$
./'/$
!012($
#3$
-,4+$
5,*$ ,6,+$
66,+$7"#$65,*$
3,,$ #+,$
#8+$
,5$
*5$
3,*$
34,$ 34,$
,5$
*5$
#+*$
+09($3$
5,$
:,%5;$
<%$ <=$
:<,%5;$
<%$
+09($3$
Discovery: UI broadcasts “seeking coverage” request with RSpec
BSC/RNCs in range advertise availability: rates/BW/etc ◦ UI would “attach” to best ◦ Remaining steps same: give
tokens to RB, get ticket, present to CM
!"#$
%&'()&('$
*+$
*,$ -,$
./'/$
!012($
#3$
-,4+$
5,*$ ,6,+$
66,+$7"#$65,*$
3,,$ #+,$
#8+$
,5$
*5$
3,*$
34,$ 34,$
,5$
*5$
#+*$
+09($3$
5,$
:,%5;$
<%$ <=$
:<,%5;$
<%$
+09($3$
Implemented web-based prototype of RA system ◦ In Java, using Apache XML-RPC framework ◦ Including signature verification of tickets and tokens,
average computational overhead to call setup time < 50ms
Designed system testbed using ModelNet ◦ Map GSM and WLAN network architecture to ModelNet
topologies: Dimensioning of network links based on realistic topos
Observe control overhead in terms of BW and latency
Incorporate mobility and continuation automatically triggering resource requests Observe optimal donation window granularity, etc.
Extend UI to switch services automatically depending on signal strength/BW/price/etc.
Use anonymized traffic traces to: ◦ Observe realistic traffic patterns and dynamically
set donation rates/prices and granularity. ◦ Find optimal investment in infrastructure based on
composition with competitors.
Questions?
Site Manager (SM): ◦ Manages user accounts: addition/removal, balance mgmt
◦ “Sells” resources to RB for tokens
User Interface (UI): ◦ Stores tickets and tokens, requests tickets
Resource Broker (RB): ◦ Clearinghouse for resources. Gives users tickets for
tokens after verification.
Component Manager (CM): ◦ Honors tickets for SM donations, gives access to resource