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