Smart Contracts for Mobile Network Operator Bandwidth Sharing

THOMAS SANDHOLM, Next-Gen Systems, CableLabs, USA

SAYANDEV MUKHERJEE, Next-Gen Systems, CableLabs, USA
We propose a new way to share licensed spectrum bandwidth capacity in mobile networks between operators, service
providers and end-users using blockchain-based smart contracts. We discuss the foundational building blocks in the contract
as well as various extensions to support more advanced features such as bulk purchases, and future reservations. Furthermore,
we demonstrate how the system can be implemented with an open-source, permissioned enterprise blockchain, Hyperledger
Sawtooth. We show that our smart contract implementation can improve blockchain transaction performance, by approxi-
mately four orders of magnitude compared to serial transactions and one order of magnitude compared to parallel transactions,
by using PKI-driven bulk purchases of mobile access grants, paving the way for fully automated, eicient, and ine-grained
roaming agreements. We conclude with a discussion of lessons learned from two end-to-end use cases we implemented to
validate our distributed ledger design.
CCS Concepts: · Networks → Network economics; Mobile networks.

1 INTRODUCTION
We know from economics that markets are an eicient method to allocate resources in a way that makes both
buyers and sellers satisied with the value they receive from transactions in such a market. Wireless spectrum is
presently mostly spoken for due to long-term licenses that exempliied the market for a scarce resource (spectrum)
with the government as the seller and mobile network operators (MNOs) as the buyers. However, this is not a
dynamic market because transactions (i.e., license auctions) occur infrequently and licenses are allocated for ixed
blocks of spectrum for durations of several years. Instead, one can conceive of a diferent, much more dynamic
market, namely one where the end-user is the buyer, the seller is any entity that can allocate a ine-grained
amount of bandwidth to the buyer for a short interval that may be just a few seconds or minutes long, and
transactions between sellers and buyers are fast and frequent. In this market, the rapid turnover in use of any
given band of spectrum ensures that spectrum resources are fully utilized. Although the sellers of spectrum are
initially going to be the incumbent holders of spectrum licenses (i.e., the MNOs who acquired that license in a
spectrum auction), it is conceivable that in the long run the method of spectrum allocation via long-term licenses
goes away and the seller of spectrum is the government, which will sell spectrum for short durations (ranging
from seconds to minutes) directly to other entities that may not necessarily be service providers themselves (see
below).
To maximize the eiciency of spectrum allocation and usage we believe there are three key dimensions where
granularity needs to be reduced:
• Time. Provide shorter-term contracts. Not years, weeks, or even days, but hours, minutes or seconds.
• Location. Provide contracts for smaller geographic regions. Not national, state, or county, but radio range,
or street block.
Authors’ addresses: Thomas Sandholm, Next-Gen Systems, CableLabs, USA; Sayandev Mukherjee, Next-Gen Systems, CableLabs, USA.

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that
copies are not made or distributed for proit or commercial advantage and that copies bear this notice and the full citation on the irst page.
Copyrights for components of this work owned by others than the author(s) must be honored. Abstracting with credit is permitted. To copy
otherwise, or republish, to post on servers or to redistribute to lists, requires prior speciic permission and/or a fee. Request permissions from
[email protected].
© 2023 Copyright held by the owner/author(s). Publication rights licensed to ACM.
2769-6472/2023/11-ART $15.00
https://doi.org/10.1145/3630168

Distrib. Ledger Technol.

2 • Thomas Sandholm and Sayandev Mukherjee

• Spectrum chunks. Provide more lexibility in the bandwidth allocated in each contract. An operator
may have a license for 100 MHz but could then dole that out to consumers in any amount from 1 MHz to
100 MHz based on demand.
Our goal is not simply to design an open market of spectrum bandwidth exchange based on smart contracts, but
to design it in such a way that operators, service providers as well as end-users have an incentive to participate,
at the same time making it as easy as possible for them to do so, all without requiring massive investment in
infrastructure beyond what is already deployed in the ield, and without requiring protocol changes that would
deprecate all current devices. Furthermore, we would like to facilitate operator-to-operator, operator-to-service
provider, operator-to-end-user, as well as service provider-to-end-user exchanges of spectrum bandwidth, backed
by a readily usable mobile network.

2 RELATED WORK
An early work on cognitive radios and Dynamic Spectrum Access (DSA) [2] argued for the spectrum market
to evolve to support commercial use in addition to ongoing technical advances to support DSA. This analysis
pre-dated, but predicted and recommended, the regulatory frameworks that later appeared in the FCC Citizen
Broadband Radio Service (CBRS) regulations [1]. In another early work [13], the authors proposed a secondary
market auction design for base stations to share spectrum (as channel holdings) in order to leverage temporal,
spatial and channel variation in user demand. The subsequent regulatory framework of CBRS [1] allows primary,
secondary and incumbent spectrum owners to share bandwidth dynamically through a Spectrum Access System
(SAS) [11] that interacts with environment sensing services as well as base stations requesting spectrum to
mitigate interference on both licensed and unlicensed bands. Incumbents are typically federal radar applications
along the US coastlines. Blockchains are proposed in [14] to help with the CBRS use case in terms of building
trust, consensus and reducing transaction cost, while [7] discusses the use case of primary spectrum sharing
among competing operators and proposes a game theoretic algorithm to avoid free-riding. Simulations show
how larger providers can determine which proportion of resources to share to avoid siphoning users to smaller
providers.
Our approach is more end-user focused in that we allow a spectrum operator who already has obtained the
license to operate and provide cellular licensed band service to admit non-subscribers to their network. This is
similar to how roaming occurs across mobile networks today, but governed by an open bandwidth market.
We ofer an end-user device and (bulk) aggregator smart contract model that allows spectrum and bandwidth
sharing beyond traditional spectrum trading restricted to transactions between MNOs [3ś5, 12].

3 DESIGN OF A BLOCKCHAIN PLATFORM FOR SMART BANDWIDTH CONTRACTS

This section describes the high-level design of a smart contract used to sell and purchase mobile network bandwidth
contracts that grant the holder access to a network on the speciied bands with the speciied bandwidth for some
given time in a given location.

3.1 Fundamental Building Blocks

We expect a permissioned blockchain to be used so only certain trusted or certiied actors like MNOs can post
ofers on the blockchain. Anyone with a large enough budget may buy bandwidth according to the rules of the
smart contract. The blockchain processing nodes can be hosted by any trusted 3rd-party, although for eiciency
we recommend it is hosted in or close to the mobile operators’ core networks. Entry into this market is expected
to be governed by trusted Exchanges capable of exchanging real currency into the smart contract currency and
approving or certifying both seller and buyer accounts.
The smart contract is deined in the following terms, all described in more detail below:

Distrib. Ledger Technol.

 Smart Contracts for Mobile Network Operator Bandwidth Sharing • 3

(a) System architecture. (b) Action definitions.

Fig. 1. Transaction actions.
• Actions What actions are allowed to modify the blockchain ledger.
• Payload What ields and values may be submitted to perform certain actions
• Processor The processor is where all the smartness or logic of the contract is deined. E.g. which actions
and what ields and values may be submitted to perform certain actions, and what is the resulting state
given a previous state in the ledger.
• Ledger State The record that represents the current state of the ledger for a bandwidth ofer. The state
determines how actions result in new states.
3.1.1 Transaction Actions. We deine the following actions that can be submitted against the bandwidth blockchain:
create, deposit, withdraw, transfer, ofer, allocate. A network architecture showing who calls these actions, and
action deinitions are shown in Figure 1.
3.1.2 Transaction Payload. The ields that need to be transmitted in the payload of a transaction request to the
transaction processor depends on the action performed. Note that some ields are shared across actions.
• action One of the actions deined above.
• provider In the case of an allocation, deposit, or withdrawal the provider is the public key or account
name of the target (e.g., the MNO in the case of an allocation).
• price This is used by all actions except the create action to specify the number of Bandcoins that pertains
to the action. For an ofer it would be the unit price. An allocation must specify a price that matches the
ofer price targeted, as a safety measure for a consumer so they don’t get any unsuspecting charges. For
deposit, withdrawal and transfer it is the amount involved in the transaction.
• epoch Ofers are immutable in that each new ofer results in a new epoch. The irst ofer will be given
epoch 1. All subsequent ofers will bump up the epoch with one. In an allocate request, the consumer or a
service provider can hence match the ofer listing epoch with the requested contract to make sure they
get the posted contract, or their request is reject if a new ofer has been posted to replace the old one in
the meantime. The epoch ield may also be used for future reservations. Even in this case there must be a
matching future reservation ofer for that epoch for the allocation to succeed.
• from_frequency Lower frequency of the band ofered.
• to_frequency Upper frequency of the band ofered.
• bandwidth Bandwidth ofered within the band. Must be less than or equal to to_frequency minus from_frequency.
• max_allocations Used in the ofer action to set the number of units that may be sold (in the current
epoch).
• volume_discount A value between 0 and 1 denoting the level of discount for bulk purchases. The �th
item beyond the irst is charged ����� × ������_�������� � .
• reservation_discount A value between 0 and 1 denoting the level of discount for purchases in advance.
Making a purchase � periods in advance costs ����� × �����������_�������� � . Note that the price can difer
between diferent epochs in the future.
• reservations A dictionary keyed by epoch with ields given by price and capacity. If the epoch exists as a
reservation state in the ledger it will be updated; if the capacity is 0, the previous reservation in that epoch
will efectively be deleted. All other cases lead to merges of reservations ofered. The capacity is honored

Distrib. Ledger Technol.

4 • Thomas Sandholm and Sayandev Mukherjee

for advance purchases made any number of epochs in advance. If the epoch becomes the current epoch the
spot capacity, i.e., what’s deined in max_allocations, becomes the units available for sale. Note, like with
any other types of modiication to the ofer the epoch is bumped each time a new reservation epoch is
added or modiied.
• allocation_duration The time a grant is valid, in seconds.
• epoch_to In an allocate request the issuer may request a whole series of consecutive future allocations in
one transaction. Note, all epochs must be available for reservation.
• consumers For bulk allocations or for allocation by a 3rd party, public keys may be speciied for who is
allowed to consume the allocation. The private keys may be mapped to actual users after the transaction
has completed.
3.1.3 Transaction Processor. The transaction processor deines how a current ledger state is transformed into
a new state and what payloads are needed for the transaction to succeed. The transaction processor also
cryptographically veriies the issuer of the transaction using PKI. For instance, an ofer can only be posted by the
account owner as per the public key of the issuer. We only list the rules for the ofer and allocate actions here as
the other actions just perform simple transfers between accounts as you would expect from any banking-like
transaction. An account balance cannot go below 0 as a general rule. In terms of the transfer the veriied issuer
needs to match the account the funds are transferred from.
• ofer All ields mentioned above need to be speciied except provider (assumed to be issuer), epoch(_to)
as it is bumped up by the processor, and consumers (as it is for the purchaser to restrict who can access
the grant). In practice only trusted MNOs would be allowed to post ofers. Note that setting an ofer with
max_allocations to 0 is essentially turning of the ofer and not allowing any more allocations. Whenever
an ofer is posted, the allocations left in the state (see below) is reset to max_allocations
• allocate An allocation must specify a provider target that must match an ofer. The price and band info must
also match the current ofer as a safety check, but most crucially the epoch must match. The consumers
ield may be illed out to delegate the allocation to someone except the issuer, and should also be used
for bulk purchases. In the case of reservation and advanced purchases, the price needs to match the total
computed cost for the full purchase not the spot price in the ofer. This again veriies that the issuer and
the transaction processor are using compatible pricing algorithms and there are no surprises in what is
charged to the issuer account. The issuer account will get this amount withdrawn if there are suicient
funds and the target account will be credited with this amount. The number of allocations requested needs
to be equal to or less than allocations left in the ledger state.
3.1.4 Ledger State. On completion of a successful transaction the ledger state is updated and the payload that
was submitted is recorded in the transaction log atomically and with consensus veriication in the blockchain.
The following state is recorded and available for veriication of current ofers and account balances:
• name Public key in hex of the account holder.
• balance Current account balance in Bandcoins.
• allocations_left Allocation units that are left in current ofer.
• epoch Current epoch for current ofer.
• from_frequency Lower frequency band in current ofer.
• to_frequency Upper frequency band in current ofer.
• bandwidth Bandwidth of current ofer.
• price (Spot) Price of current ofer.
• volume_discount Volume discount of current ofer.
• reservation_discount Reservation discount of current ofer.

Distrib. Ledger Technol.

 Smart Contracts for Mobile Network Operator Bandwidth Sharing • 5

• allocation_duration Allocation duration of current ofer.

• reservations Dictionary keyed by epoch of future reservations that may currently be purchased.
Note, only name and balance are relevant for a consumer account that is not also a provider.

3.2 Discovery and Location Awareness

As one of our key goals is to allow more local, ine-grained geographical area allocations, we have designed a
meta-data service where providers can publish their ofers in geolocations and allow searches up to a maximum
distance from a ixed point (speciied by latitude and longitude). Beyond geographical coordinate, meta data for
a publication also includes: market_server, the endpoint of the blockchain API service, provider name, name of
provider, provider_key, public key used in the blockchain for the provider’s ofers, plmn_preix, preix of PLMN
which allows a mobile client to map an eSIM proile to an ofer. A smart phone would obtain its GPS coordinate,
query the discovery service for blockchain markets nearby, then query the ofers available in the blockchain
for the entries that match eSIM proiles on the phone. Alternatively the discovery service could also be used to
download eSIM proiles. The phone would purchase a contract for an ofer, then enable its eSIM and start sending
and receiving data on the new network.
More details on the protocol including an auction design can be found in [8].

3.3 Privacy, Security and Confidentiality

The security of our proposed solution relies on PKI (Public Key Infrastructure) certiicates. The blockchain does
not allow any operations from any party without public key veriication. The operations are tunnelled and
exposed via a HTTPS REST API for transport level conidentiality with TLS. The same keys may be used for
end-to-end encryption although the results of operations need to be veriiable by any party with access to the
blockchain. Key issuers may be restricted to trusted certiicate authorities. The blockchain design ensures a ledger
that cannot be tampered with and only the public keys of the parties modifying the blocks are revealed allowing
for anonymity and privacy as well.

4 IMPLEMENTATION NOTES
We have implemented1 the design proposed in the previous section using the Hyperledger Sawtooth Core2
blockchain.
The blockchain state as well as the payloads are encoded as JSON objects. Our implementation interacts with
Sawtooth mainly through the REST API, via SDKs. One of the key reasons we picked Sawtooth, apart from having
an easy-to-deploy development environment based on Docker, was the multi language support. It was easy to
integrate with our Python backends, as well as our Android clients.
We provide a Transaction Processor that registers with the validator, and a client library, both implemented in
Python3. All our services are implemented with Python Flask REST APIs using JSON payloads as well.
Transactions may be tunneled using Protocol Bufer3 serialized Transaction and Batch encapsulations according
to the Sawtooth protocol4 and are then base64 encoded in JSON ields for our APIs. This design is mainly used
for our auction protocol.
All Sawtooth and custom services are hosted in Docker containers and interact within a private docker network.
The services may be distributed with something like Docker Swarm or Kubernetes, but for testing they all run
locally using docker-compose and the developer mode blockchain.
1 https://github.com/cablelabs/bandcoin
2 https://www.hyperledger.org/use/sawtooth
3 https://developers.google.com/protocol-bufers
4 https://sawtooth.hyperledger.org/docs/core/releases/latest/ _autogen/txn_submit_tutorial.html

Distrib. Ledger Technol.

6 • Thomas Sandholm and Sayandev Mukherjee

(a) Devmode single node. (b) PBFT 5-node network.

Fig. 2. Transaction throughput with diferent bulk sizes and concurrent providers. Bulk allocation 1 can be seen as an
approximate latency measurement.
The transaction processor implementation allows a public key to be set with Exchange privileges. That means
that whoever can prove they have the private key corresponding to that public key may perform the privileged
operations such as injecting or removing funds with the deposit and withdraw actions. The service that owns the
Exchange private key is the point of integration with payment gateways. We have implemented two payment
gateway integrations, Saleor5 and Braintree6 (See [8] for more details).

4.1 Decision Performance

Allowing ine-grained, fast decisions on mobile network provider to use depends on end-user local context, such
as which apps are used and the GPS reading, as well as the time it takes to authenticate and switch the radio
and network stack over to a new network. Due to the 4G/5G AKA authentication protocol [6], the overhead of
initial network setup can be signiicant7 , but with multiple (e)SIM slots a new network can be provisioned before
the old one is disconnected allowing for instant8 switches, transparent to the end-users. Now, the remaining
overhead to ofer fast decisions relies on the time it takes to create entries in the blockchain ledger that can be
veriied by the operators.
Transaction processing time both in terms of latency and throughput matters when it comes to the granularity
of contracts we can support in the time domain. The original blockchain protocol is notorious for being slow at
conirming transactions, and the cryptographic routines used to secure all ledger writes also bring overhead.
Sawtooth ofers some optimizations in terms of transaction parallelism but if you are writing to the same state
the parallelism that is possible is limited. As a result, we introduced bulk allocations, where multiple allocations
to diferent consumers, distinguished by diferent public keys, may be purchased in a single Sawtooth transaction.
See the design section for details on how this is implemented in the protocol and the smart contract. To test the
limits and the improvement of bulk allocations we tested diferent bulk sizes and diferent concurrent provider
purchases with the same consumer account in a single node network and a 5-node network controlled by the
PBFT consensus algorithm. Both experiments ran on a single machine in a docker virtual network. The results
can be seen in Figure 2.
In summary, we can improve the throughput of allocation agreements settled by four orders of magnitude
(from about .5-1 allocation transactions per second to 10,000-13,000 transactions per second) for a single provider
with a bulk size up to 50,000. We see that bulk sizes over 10,000 do not improve performance much but that there
is a linear increase for bulk sizes 1-10,000. Submitting allocation transactions for multiple providers concurrently
is not as eicient of a mechanism to improve throughput as bulk allocations, as seen by the fact that 3-6 parallel
transactions (providers) only reaches a peak throughput of about 1000 allocations per second. The drop of higher
parallelism with small bulk sizes could be seen as an experiment setup artifact, where previous large bulk sizes
impact the restart of the experiment run. It also highlights the general strain on the system of increased transaction
parallelism. Another interesting phenomenon is the drop at the high end, where throughput is satisied, which is
likely a function of the number of parallel transactions and overall system resource contention, and again points
to the eiciency of our bulk allocation mechanism. The 5-node network achieves higher throughput with lower

5 https://saleor.io/
6 https://www.braintreepayments.com/
7 close to a second
8 within milliseconds

Distrib. Ledger Technol.

 Smart Contracts for Mobile Network Operator Bandwidth Sharing • 7

bulk sizes and does not allow for bulk sizes as large as the single node network before resources are saturated,
but other than that the results are comparable to the single node experiment.

4.2 Consensus Algorithms

Given that we use a permissioned blockchain and expect a few number of trusted, highly available nodes to
host the blockchain in a local geographic market, the typical failure protection to ensure inality, as well as the
overhead and general complexity of consensus known from massive open proof-of-work ledgers can be avoided.
Sawtooth ofered PBFT, PoET and RAFT consensus at the time of our implementation, and any of them should be
suicient for our scenario. Note that local market blockchains do not need to coordinate with each other to reach
consensus.

5 USE CASES AND CONCLUDING REMARKS

We have implemented two practical use cases of Bandcoin-based roaming agreement negotiations, end-user
eSIM provider selection and virtual network operator reservations. Any platform that supports eSIMs can take
advantage of our solution, although we have implemented and tested it on Android devices.
End-User eSIM Provider Selection. In this use case we have integrated an eSIM enabled mobile core provider
with Bandcoin so smart phones can discover and learn the best provider bandwidth ofers through a background
app and purchase short term contracts that enables and disables the eSIM proile. A distributed ledger is helpful
here as a proof of purchase and to decouple purchasing, ofering as well as eicient veriication of bandwidth
contracts on local 3rd party markets. The purchasing decisions are made on the phone based on (locally) measured
performance with each provider and a (locally run) contextual bandit algorithm determining which provider is
best at any given time and location for a speciic task. See [9] for more details.
Virtual Network Operator Reservations. In this use case a virtual network operator (Cloud) service
purchases Bandcoin contracts in bulk and ahead of time and then distributes them to its users as multi-provider
long-term contracts. A distributed blockchain is beneicial for the reasons mentioned in the previous use case, and
additionally allows for simpliication of end-device contract negotiations as well as reduction in overhead thanks
to bulk operations. The key to this use case is that the smart contract allows delegation of use, so the purchaser
does not need to also consume the contract resources and furthermore the end consumer of the contract does not
need to be known at the time of purchasing the contract. In that sense the smart contract works like a gift card.
Whoever can present this contract to an MNO is allowed to consume resources. See [10] for more details.
Concluding Remarks. We proposed and evaluated a blockchain-based smart contract for bulk purchases
of mobile access grants from spectrum license holders to support fully automated, eicient and ine-grained
roaming agreements.

REFERENCES
[1] [n. d.]. FCC: 16-55: The Second Report and Order and Order on Reconsideration inalizing rules for innovative Citizens Broadband
Radio Service in the 3.5 GHz Band (3550-3700 MHz). https://apps.fcc.gov/edocs_public/attachmatch/FCC-16-55A1.pdf. 2016.
[2] John M Chapin and William H Lehr. 2007. Cognitive radios for dynamic spectrum access-the path to market success for dynamic
spectrum access technology. IEEE Communications Magazine 45, 5 (2007), 96ś103.
[3] Zhiyang Cheng, Yifei Liang, Youping Zhao, Shuo Wang, and Chen Sun. 2023. A Multi-Blockchain Scheme for Distributed Spectrum
Sharing in CBRS System. IEEE Transactions on Cognitive Communications and Networking 9, 2 (2023), 266ś280.
[4] Qiwei Hu and Tao Jiang. 2022. A Smart Contract based Spectrum Trading System for Elastic Virtual Optical Networks. In 2022 IEEE 96th
Vehicular Technology Conference (VTC2022-Fall). IEEE, 1ś5.
[5] Zuguang Li, Wei Wang, Qihui Wu, and Xianbin Wang. 2022. Multi-operator dynamic spectrum sharing for wireless communications: a
consortium blockchain enabled framework. IEEE Transactions on Cognitive Communications and Networking 9, 1 (2022), 3ś15.
[6] Yi Qian, Feng Ye, and Hsiao-Hwa Chen. 2022. UMTS Security. (2022).

Distrib. Ledger Technol.

8 • Thomas Sandholm and Sayandev Mukherjee

[7] Mostaizur Rahman. 2018. A game-theoretic model for regulating freeriding in subsidy-based pervasive spectrum sharing markets. Ph. D.
Dissertation. University of Central Florida.
[8] Thomas Sandholm and Sayandev Mukherjee. 2021. Bandcoin: Using Smart Contracts to Automate Mobile Network Bandwidth Roaming
Agreements. arXiv preprint arXiv:2104.02780 (2021).
[9] Thomas Sandholm and Sayandev Mukherjee. 2021. A Multi-Armed Bandit-based Approach to Mobile Network Provider Selection. arXiv
preprint arXiv:2012.04755v2 (2021).
[10] Thomas Sandholm and Sayandev Mukherjee. 2021. SCNO: smart city network operator. In Proceedings of the 1st Workshop on Artiicial
Intelligence and Blockchain Technologies for Smart Cities with 6G. 1ś6.
[11] Munawwar M Sohul, Miao Yao, Taeyoung Yang, and Jefrey H Reed. 2015. Spectrum access system for the Citizen Broadband Radio
Service. IEEE Communications Magazine 53, 7 (2015), 18ś25.
[12] Qihui Wu, Wei Wang, Zuguang Li, Bo Zhou, Yang Huang, and Xianbin Wang. 2023. SpectrumChain: a disruptive dynamic spectrum-
sharing framework for 6G. Science China Information Sciences 66, 3 (2023), 130302.
[13] Hong Xu, Jin Jin, and Baochun Li. 2010. A secondary market for spectrum. In 2010 Proceedings IEEE INFOCOM. IEEE, 1ś5.
[14] Seppo Yrjölä. 2017. Analysis of blockchain use cases in the citizens broadband radio service spectrum sharing concept. In International
Conference on Cognitive Radio Oriented Wireless Networks. Springer, 128ś139.

Distrib. Ledger Technol.