Smart Contracts for Mobile Network Operator Bandwidth Sharing

1 INTRODUCTION

We know from economics that markets are an efficient method to allocate resources in a way that makes both buyers and sellers satisfied with the value they receive from transactions in such a market. Wireless spectrum is presently mostly spoken for due to long-term licenses that exemplified 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 fixed blocks of spectrum for durations of several years. Instead, one can conceive of a different, much more dynamic market, namely one where the end user is the buyer, the seller is any entity that can allocate a fine-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 the following).

To maximize the efficiency of spectrum allocation and usage, we believe there are three key dimensions where granularity needs to be reduced:

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, and 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 field, 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, and 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 [2] argued for the spectrum market to evolve to support commercial use in addition to ongoing technical advances to support dynamic spectrum access. This analysis pre-dated, but predicted and recommended, the regulatory frameworks that later appeared in the FCC Citizens 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) 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 U.S. coastlines. Blockchains are proposed in the work of Yrjölä [14] to help with the CBRS use case in terms of building trust, consensus, and reducing transaction cost, whereas Rahman [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 offer 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, 4, 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 specified bands with the specified 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 certified actors like MNOs can post offers 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 third party, although for efficiency we recommend that 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 defined in the following terms, all described in more detail in the following:

–	Actions: What actions are allowed to modify the blockchain ledger.
–	Payload: What fields and values may be submitted to perform certain actions.
–	Processor: The processor is where all the smartness or logic of the contract is defined—for example, which actions and what fields 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 offer. The state determines how actions result in new states.

3.1.1 Transaction Actions.

We define the following actions that can be submitted against the bandwidth blockchain: create,deposit,withdraw,transfer,offer,allocate. A network architecture showing who calls these actions and action definitions are shown in Figure 1.

Fig. 1.

View Figure

3.1.2 Transaction Payload.

The fields that need to be transmitted in the payload of a transaction request to the transaction processor depends on the action performed. Note that some fields are shared across actions:

–	action: One of the actions defined previously.
–	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 offer, it would be the unit price. An allocation must specify a price that matches the offer price targeted, as a safety measure for a consumer so they do not get any unsuspecting charges. For deposit, withdrawal, and transfer, it is the amount involved in the transaction.
–	epoch: Offers are immutable in that each new offer results in a new epoch. The first offer will be given epoch 1. All subsequent offers will bump up the epoch by 1. In an allocate request, the consumer or a service provider can hence match the offer listing epoch with the requested contract to make sure they get the posted contract, or their request is reject if a new offer has been posted to replace the old one in the meantime. The epoch field may also be used for future reservations. Even in this case there must be a matching future reservation offer for that epoch for the allocation to succeed.
–	from_frequency: Lower frequency of the band offered.
–	to_frequency: Upper frequency of the band offered.
–	bandwidth: Bandwidth offered within the band. Must be less than or equal to to_frequency minus from_frequency.
–	max_allocations: Used in the offer 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 nth item beyond the first is charged \(price \times {volume\_discount}^n\).
–	reservation_discount: A value between 0 and 1 denoting the level of discount for purchases in advance. Making a purchase n periods in advance costs \(price \times {reservation\_discount}^n\). Note that the price can differ between different epochs in the future.
–	reservations: A dictionary keyed by epoch with fields 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 effectively be deleted. All other cases lead to merges of reservations offered. The capacity is honored for advance purchases made any number of epochs in advance. If the epoch becomes the current epoch, the spot capacity (i.e., what is defined in max_allocations) becomes the units available for sale. Note that like with any other types of modification to the offer, the epoch is bumped each time a new reservation epoch is added or modified.
–	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 specified 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 defines 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 verifies the issuer of the transaction using PKI (Public Key Infrastructure). For instance, an offer can only be posted by the account owner as per the public key of the issuer. We only list the rules for the offer 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 verified issuer needs to match the account the funds are transferred from:

–

offer: All fields mentioned previously need to be specified 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 offers. Note that setting an offer with max_allocations to 0 is essentially turning off the offer and not allowing any more allocations. Whenever an offer is posted, the allocations left in the state (see the following) is reset to max_allocations.

–

allocate: An allocation must specify a provider target that must match an offer. The price and band info must also match the current offer as a safety check, but most crucially the epoch must match. The consumers field may be filled 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 offer. This again verifies 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 sufficient 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 verification in the blockchain. The following state is recorded and available for verification of current offers 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 the current offer.
–	epoch: Current epoch for the current offer.
–	from_frequency: Lower frequency band in the current offer.
–	to_frequency: Upper frequency band in the current offer.
–	bandwidth: Bandwidth of the current offer.
–	price: (Spot) Price of the current offer.
–	volume_discount: Volume discount of the current offer.
–	reservation_discount: Reservation discount of the current offer.
–	allocation_duration: Allocation duration of the current offer.
–	reservations: Dictionary keyed by epoch of future reservations that may currently be purchased.

Note that only name and balance are relevant for a consumer account that is not also a provider.

4 IMPLEMENTATION NOTES

We have implemented¹ the design proposed in the previous section using the Hyperledger Sawtooth Core² 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 Buffer³ serialized Transaction and Batch encapsulations according to the Sawtooth protocol⁴ and are then base64 encoded in JSON fields 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.

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, Saleor⁵ and Braintree⁶ (see the work of Sandholm and Mukherjee [8] for more details).

4.1 Decision Performance

Allowing fine-grained, fast decisions on the 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 significant,⁷ but with multiple (e)SIM slots a new network can be provisioned before the old one is disconnected, allowing for instant⁸ switches, transparent to the end users. Now, the remaining overhead to offer fast decisions relies on the time it takes to create entries in the blockchain ledger that can be verified 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 confirming transactions, and the cryptographic routines used to secure all ledger writes also bring overhead. Sawtooth offers 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 different consumers, distinguished by different public keys, may be purchased in a single Sawtooth transaction. See Section 3 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 different bulk sizes and different 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.

Fig. 2.

View Figure

In summary, we can improve the throughput of allocation agreements settled by four orders of magnitude (from about .5 to 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 from 1 to 10,000. Submitting allocation transactions for multiple providers concurrently is not as efficient of a mechanism to improve throughput as bulk allocations, as seen by the fact that 3 to 6 parallel transactions (providers) only reach a peak throughput of about 1,000 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 satisfied, which is likely a function of the number of parallel transactions and overall system resource contention, and again points to the efficiency of our bulk allocation mechanism. The 5-node network achieves higher throughput with lower 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.

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 offers through a background app and purchase short-term contracts that enable and disable the eSIM profile. A distributed ledger is helpful here as a proof of purchase and to decouple purchasing, offering as well as efficient verification of bandwidth contracts on local third-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 specific task. See the work of Sandholm and Mukherjee [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 beneficial for the reasons mentioned in the previous use case, and additionally allows for simplification 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 the work of Sandholm and Mukherjee [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, efficient, and fine-grained roaming agreements.