Bandcoin: Using Smart Contracts to AutomateMobile Network Bandwidth Roaming Agreements

Thomas Sandholm and Sayandev MukherjeeNext-Gen Systems, CableLabs

ABSTRACTWe propose a new way to share licensed spectrum band-width capacity in mobile networks between operators,service providers and consumers using blockchain-basedsmart contracts. We discuss the foundational buildingblocks in the contract as well as various extensions tosupport more advanced features such as bulk purchases,future reservations, and various auction mechanisms.Furthermore, we demonstrate how the system can be im-plemented with an open-source, permissioned Enterpriseblockchain, Hyperledger Sawtooth. We show that oursmart contract implementation can improve blockchaintransaction performance, by approximately four ordersof magnitude compared to serial transactions and oneorder of magnitude compared to parallell transactions,using PKI-driven bulk purchases of mobile access grants,paving the way for fully automated, efficient, and fine-grained roaming agreements.

1 INTRODUCTION1.1 The challenge of efficient spectrum

allocationMobile cellular network providers today face increasingchallenges when it comes to acquiring licenses to op-erate on dedicated frequency bands in large coverageareas. Winning a license in national auctions typicallyalso comes with strings attached to build out networkinfrastructure and show a high level of utilization toserve the general public. The high cost of provisioningthe network is translated into more expensive and rigidcontracts to lock in consumers or long-term partnershipswith service providers, as well as limited competitionand innovation.

The end-result is poor quality of experience for con-sumers, in particular highly mobile ones, and inefficientresource utilization. The additional spectrum bandwidth

Permission to make digital or hard copies of part or all of thiswork for personal or classroom use is granted without fee providedthat copies are not made or distributed for profit or commercialadvantage and that copies bear this notice and the full citation onthe first page. Copyrights for third-party components of this workmust be honored. For all other uses, contact the owner/author(s).© 2021 Copyright held by the owner/author(s).

introduced in newer specifications such as 5G, exacer-bate rather than mitigate this problem as the existingroaming and bandwidth sharing mechanisms are not upto the task of sharing the new opportunities efficiently,mostly due to the rigid contractual setup of roamingagreements.

There is a trend to design more dynamic databasemediated allocations of spectrum as evident in effortslike CBRS SAS [11]. However, even in that work there isa centralized mediator which allows long term spectrumlicenses to be acquired in smaller scale spectrum auctions(e.g. county level), and most of the dynamic coordinationis focused on letting unlicensed traffic use up incumbentand licensed bands if not in use, as opposed to redesign-ing the actual license acquisition process. Thus it inheritsmany of the inefficiencies of the national spectrum auc-tions, just on a smaller scale.

1.2 Markets for efficient allocation ofscarce spectrum

We know from economics that markets are an efficientway to allocate resources in such a way that both buy-ers and sellers are satisfied with the value they receivefrom transactions in such a market. Wireless spectrum ispresently mostly spoken for due to long-term licenses thatexemplified the market for a scarce resource (spectrum)with the government as the seller and mobile networkoperators (MNOs) as the buyers. However, this is not adynamic market because transactions (i.e., license auc-tions) occur infrequently and licenses are allocated forfixed blocks of spectrum for durations of several years.Instead, one can conceive of a different, much more dy-namic market, namely one where the end-user is thebuyer, the seller is any entity that can allocate a fine-grained amount of bandwidth to the buyer for a shortinterval that may be just a few seconds or minutes long,and transactions between sellers and buyers are fast andfrequent. In this market, the rapid turnover in use of anygiven band of spectrum ensures that spectrum resourcesare fully utilized. Although the sellers of spectrum areinitially going to be the incumbent holders of spectrumlicenses (i.e., the MNOs who acquired that license in aspectrum auction), it is conceivable that in the long runthe method of spectrum allocation via long-term licensesgoes away and the seller of spectrum is the government,

arX

iv:2

104.

0278

0v1

[cs

.NI]

6 A

pr 2

021

which will sell spectrum for short durations (rangingfrom seconds to minutes) directly to other entities thatmay not necessarily be service providers themselves (seebelow).

To maximize the efficiency of spectrum allocation andusage we believe there are three key dimensions wheregranularity 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 geographicregions. Not national, state, or county, but radiorange, or street block.

∙ Spectrum chunks. Provide more flexibility in thebandwidth allocated in each contract. An operatormay have a license for 100MHz but could thendole that out to consumers in any amount from1 MHz to 100 MHz based on demand.

It is a consequence of a dynamic market that there isa role to play for an intermediary between the “owners”of spectrum (the MNOs today) and the end-users of thatspectrum. This intermediary plays the role of the serviceprovider to the end-users, but is a bulk customer of thespectrum owners (the MNOs). There is a role for thisintermediary because MNOs would prefer not to have todeal with millions of transactions representing sales toindividual end-users every few seconds or minutes, andnor would the end-users necessarily prefer dealing withmultiple MNOs in order to procure bandwidth to usefor a short duration.

Note that each use by an end-user of a block of li-censed spectrum with the permission of the licenseecorresponds to a “contract” wherein the licensee givesthat end-user access to the bandwidth corresponding tothat block of spectrum in return for a payment fromthat end-user either directly or indirectly via a serviceprovider which collects payment from a number of end-users. Addressing the additional flexibility of a marketsupporting all the above makes it apparent that contractnegotiation, establishment, accounting, and verificationall need to be automated in order to handle the highvolume of transactions that will be generated in such adynamic market. Such contracts, validation, billing, ac-counts payable/receivable etc. can all be automated usingthe technology of “smart contracts,” which can thereforebe used to handle all transactions in such a market. To-day, such smart contracts are usually implemented ona blockchain platform and are used in everything fromonline shopping to house mortgage lending.

1.3 Outline of this paperOur goal is not simply to design an open market ofspectrum bandwidth exchange based on smart contracts,but to design it in such a way that operators, serviceproviders as well as users have an incentive to partici-pate, at the same time making it as easy as possible forthem to do so, all without requiring massive investmentin infrastructure beyond what is already deployed inthe field, and without requiring protocol changes thatwould deprecate all current devices. Furthermore, wewould like to facilitate operator-to-operator, operator-to-service provider, operator-to-consumer, as well as serviceprovider-to-consumer exchanges of spectrum bandwidth,backed by a readily usable mobile network.

The rest of the paper is organized as follows: we dis-cuss related work, the current roaming mechanism, andblockchain fundamentals. We then describe the basicbuilding blocks of our implementation as well as exten-sions for more sophisticated auction mechanisms. Finally,we present details about our implementation and con-clude with lessons learned.

2 RELATED WORK2.1 Cognitive RadioIn [4], in the context of cognitive radios and DynamicSpectrum Access (DSA), the authors argue that althoughtechnical advances have been achieved to enable DSA,the spectrum market also needs to evolve to support com-mercial use. Their problem formulation is different fromthe present work in that in [4], the market governingspectrum licenses is intended for multiple spectrum oper-ators to coordinate usage dynamically, i.e. base stationsdeciding on which band is best to operate on consideringother interfering base stations. Our approach is more end-user focused in that we allow a spectrum operator whoalready as obtained the license to operate and providecellular licensed band service to admit non-subscribersto their network, similar to how roaming is done, gov-erned by an open bandwidth market. Nevertheless, theiranalysis on why DSA and wireless spectrum markets arebeneficial applies to our approach as well. The authorsargue that more spectrum sharing leads to cheaper spec-trum access that in turn enables increased competitionamong mobile communication services, which necessi-tates more innovation and allows smaller operators tothrive, and ultimately leads to overall more affordablemobile services. Driving down transaction cost is statedas a primary challenge, and it is also the focus of ourwork. The analysis by [4] pre-dated but predicted, and

2

recommended the regulatory frameworks that later ap-peared in the FCC CBRS (Citizen Broadband RadioService) regulations.

In [15], the authors propose a secondary market auc-tion design for base stations to share spectrum (as chan-nel holdings) in order to leverage temporal, spatial andchannel variation in user demand. A dynamic doubleauction, akin to the stock market and similar to ourproposed Vickrey auction, is applied. The authors fur-thermore analytically prove the truthfulness and asymp-totic efficiency in maximizing spectrum utilization. Ourmarket is different due to end-users, not base stations,participating directly in the auctions. Our market is alsomore of a bandwidth market as we sell not only a leaseto be licensed to operate on a spectrum but a full grantto access a mobile network as your home-PLMN over alimited time.

2.2 CBRSThe regulatory framework of Citizen Broadband RadioService (CBRS) [1] allows primary, secondary and incum-bent spectrum owners to share bandwidth dynamicallythrough a Spectrum Access System (SAS) [11] that in-teracts with environment sensing services as well as basestations requesting spectrum to mitigate interferenceon both licensed and unlicensed bands. Incumbents aretypically federal radar applications along the US coast-lines. In [16], the author argues that blockchains couldhelp with the CBRS use case in terms of building trust,consensus and reducing transaction cost. One interestingaspect of CBRS is that the FCC allows and encouragesPriority Access License (PAL) holders to resell and leaseout their spectrum rights on secondary markets. Keybenefits offered by blockchains include reduced transac-tion cost, which we recall was one of the promises ofDSA. A large variety of CBRS use cases of blockchainsare proposed in [16]. The CBSD (CBRS device, i.e. basestation) access network and SAS use cases proposed areconceptually similar to our work. Small start-up cost andgrowth-aligned transaction costs, scalability, exchangesof assets among non-trusting co-opetitive stakeholders,and regulatory reporting and tracking inherent in theblockchain model, are argued to be beneficial to CBRS.Akin to the Cognitive Radio work discussed above, CBRSis mainly focussed on base stations negotiating spectrumcontracts (with SAS) as opposed to the end-user device,i.e. phone, tablet, laptop etc, as in our work. Stretchingout the market to the deep edge puts an extra burdenon simplifying the interactions, but has the benefit ofincreased privacy, as all the context to make contractdecisions can be maintained locally on the device. Like

in our case, the CBRS blockchain analysis recommendshybrid or private blockchains for all their use cases toreduce transaction time, mainly thanks to simplifiedconsensus algorithms.

2.3 Primary Network SpectrumSharing

Rahman [9], discusses the use case of primary spectrumsharing among competing operators and proposes a gametheoretic algorithm to avoid free-riding. Simulations showhow larger providers can determine which proportion ofresources to share to avoid siphoning users to smallerproviders. The free-riding problem does not arise inour model since end-users purchase bandwidth directlyin micro-contracts, as opposed to traditional roamingagreements. However, similar methods may be employedin our system by providers to determine the optimal (interms of short term and long term revenue) capacityshare to give to visiting versus home-PLMN subscribers.

2.4 IoTZhou et. al. in [17] propose to make use of underutilizedhuman-to-human spectrum frequencies for machine-to-machine use cases in heterogeneous networks. Privacy,incentive-compatibility and spectrum efficiency are goalsthat led the authors to a blockchain-based solution. Intheir model, the human users relinquish spectrum to thebase station in exchange for payments, and the base sta-tion then utilizes this spectrum for machine-to-machinecommunication. Blockchain payments are used to give(human-to-human) users an incentive to share privateinformation (such as demand) to the base stations tomake better resource allocation decisions. The decentral-ized nature of blockchains is also used as an argumentfor increased security by not exposing single points offailure. The two-party market of primary and secondaryusers is akin to the cognitive radio approaches. In ourwork there is no difference between spectrum users. Thebase stations as an extension of their core networks andthe operator simply offers bandwidth that can be pur-chased by anyone. Then anyone who can prove theypurchased the access grant is let on as a primary homesubscriber on the mobile network. Note the operatormay still want to employ something like network slicingor other constraints to separate long-term subscribersfrom these new type of subscribers. Furthermore, in ourwork the primary users or subscribers of the networkare not involved in the market directly, but indirectly,where the operator is likely to slice the share and set theprices on the market based on their usage and demand atany given time. The authors also opt for a permissioned

3

ledger, which they refer to as a consortium blockchainwhere the base stations act as authorized nodes, andminers in the proof-of-work based protocol, to write intothe ledger. A stark difference between their approach andours is that we consider a competitive multi-operatorenvironment as opposed to a single-provider market.

2.5 AuctionsKatobi and Bilen in [6], propose an alternative to theAloha medium access method to share spectrum moreefficiently amongst competing or interfering cognitiveradios. They design an auction mechanism [7], as well asintroduce a virtual currency, specoins that can be earnedthrough mining to incentivize writing into the blockchain,and thus target permissionless deployments. In theirmodel, anyone can purchase access on the blockchainand there is no central entity authorizing either ledgernodes or transaction participants. The currency is ex-changed between primary users owning the spectrumand secondary users who want to lease it. Note that allusers are cognitive radio base stations in this context.Apart from earning specoins to afford purchases of spec-trum not owned by mining, base stations may also usean exchange to trade real currency for specoins. In orderto avoid multiple-round auctions to slow down transac-tions and increase the complexity of the exchange, theauthors propose a puzzle mechanism, akin to what isused in the blockchain ledger update mechanism to as-sign the winning bidder. The winning bidder who solvesthe puzzle is then in a second step entitled to pay therequired specoins to get the spectrum grant. Althoughsimulations show that throughput can improve, the factthat both transaction ledger updates and auction partic-ipation requires processing means that the base stationenergy and power consumption may be increased. Thespectrum winner is hence like in the Aloha model ran-dom to some degree. In contrast, our auction is more likea traditional auction where the highest bidder wins, orthe bid is proportional to the share gained, in order tohelp owners of spectrum or bandwidth capacity (in ourcase mobile network operators) determine the optimalprice based on demand. Instead of a single winner wealso allow multiple winners that share the capacity inresource block shares. Given the random nature of theauction proposed in [6] it may be considered more of acollision avoidance mechanism than a true open marketauction. The one benefit of their approach comparedto the Aloha protocol is that placing a bid and gettingaccess requires spending of local resources, in this caseCPUs and in that sense it is harder for a rogue player to

gain access. In our case we rely on the fact that spendingcurrency is enough of a detractor to gain rogue access.

2.6 Access to charging stations forelectric vehicles (EVs)

The fundamentals of a market for a scarce resource, withtransactions handled via smart contracts implementedon a blockchain platform, hold for more scenarios thanjust spectrum. The use of a blockchain to ensure accu-rate measurements of the amount of power drawn by acharging electric vehicle (EV) and the accurate billingthereof by the operator of the charging station was con-sidered in [5]. A full marketplace design on a blockchainplatform with the operators of fleets of charging stationshandling transactions with EV owners who use thesecharging stations via an application on their smartphoneswas proposed in [2]. Their marketplace for EV access tocharging stations is analogous to our proposed market-place for end-user access to bandwidth, with the ownersof the charging stations being analogous to MNOs in ourmarketplace. Like in our work, the blockchain implemen-tation in [2] is also an open-source ledger implementationwithin the Hyperledger 1 program.

3 ROAMINGIn the US, the FCC mandates that commercial mo-bile radio services provide automatic roaming to otherproviders on “commercially reasonable terms and condi-tions”2. In practice this typically means that a providerallows roaming to other non-competing networks in areaswhere they do not have a license to operate, like acrossnational borders.

Below we describe the basic architecture of roamingin a 3GPP standardized LTE network 3.

An operator of a Public Land Mobile Network (PLMN),also known as a cellular carrier, has some subscribers thatpay the operator for their service according to (typicallylong-term) contracts. The PLMN that the subscriberpays its bills to is typically referred to as the Home-PLMN. When a subscriber roams onto another networkthe new network is referred to as the Visited-PLMN.

The core network (in LTE called EPC, Evolved PacketCore), is comprised of a set of standardized componentsto offer mobile services to subscribers, such as mobil-ity management, subscriber management, charging, androuting packets to and from the Internet. A roaminguser would connect to the eNodeB (the radio or tower

1https://www.hyperledger.org/2https://www.fcc.gov/wireless/bureau-divisions/competition-infrastructure-policy-division/roaming-mobile-wireless35G roaming is conceptually similar.

4

front-end) that is connected to the EPC of the Visited-PLMN. The mobility management component in theVisited-PLMN can then interact with the subscriberdata base of the Home-PLMN to verify the subscrip-tion of the user. The Visited-PLMN may connect theuser to the packet data network gateway (P-GW) of theHome-PLMN to allow the subscriber to access mobileservices from its home network, while being connectedto the eNodeB of the Visited-PLMN. The P-GW is alsotypically responsible for routing packets to and from theInternet.

Now, to charge for traffic used by a visiting subscriber,the visited network creates call detail records (CDRs)that are converted to a Transferred Account Procedures(TAP) file that is sent to the home network for billingvia a clearing house service.

The home network subscriber verification, traffic rout-ing, and billing processes will only proceed successfullyif there is a pre-established bilateral roaming agreementbetween the home network and the visited network.Those contracts are established manually over long timespans behind closed doors, and they are not standard-ized. Furthermore, they are typically not established ifthere is competition in the same region between the twoproviders. Hence traditional roaming cannot be fully uti-lized to load balance or fail over between providers in thesame region, or to allow users a choice which providerto use at any given time unless they purchase two homenetwork contracts and have multiple SIM slots on theirphones. In other words, traditional roaming was designedto extend coverage rather than maximize performance.

There are new types of mobile virtual network oper-ator (MVNO) services starting to relax some of theserestrictions, such as GoogleFi 4, where a custom corenetwork is built to allow switching between multiplenetworks that the MVNO has established roaming agree-ments with. Apart from building a new core network,the manual closed-door bilateral roaming agreementsstill need to be set up, which typically means only a verylimited set of pre-established providers can be used ineach region.

4 TRANSACTIONS ON ASPECTRUM MARKET

4.1 Smart contracts to handletransactions

A spectrum market may have an owner of spectrum(i.e., a licensee in the form of an MNO, or maybe thegovernment in the future) selling access to fine-grained

4https://fi.google.com/about

blocks of bandwidth for short durations directly to end-users. In this scenario, the traditional contracts coveringbilling and usage may be turned into smart contractsin a straightforward way, so that the smart contractsmay now be handled in a fully automated fashion by theblockchain platform. However, there are other, richer,scenarios that arise when the owners of spectrum donot sell access directly to the end-users and instead sellbandwidth in bulk to an intermediary, which then turnsaround and sells the bandwidth to end-users.

In the latter scenario, the intermediary, which we shallcall the aggregator since it purchases bandwidth in bulkfrom the spectrum owners, is the service provider to theend-users. We have already mentioned earlier that end-users are unlikely to want to deal with multiple MNOsdirectly, thereby providing a niche for such an intermedi-ary, which charges a fixed monthly subscription fee fromthe end-users who use its services. Moreover, MNOs donot want to handle the volume of short-duration small-denomination transactions that are required to supportlots of end-users directly on such a spectrum market,choosing instead to deal with a few large aggregatorswho purchase in bulk from these MNOs. Indeed, we ex-pect the MNOs will even incentivize such aggregatorsby offering them a volume discount for bulk purchases,coupled with a reservation discount for purchases madein advance of use (the earlier the purchase, the greaterthe discount). Although we will not delve into the de-tails here, we will state that smart contracts can handlethe transactions between MNOs and aggregators andbetween aggregators and end-users on such a market.

We note here that the kinds of transactions we havedefined above are not the only transactions possibleon such spectrum markets. For example, the MNOsmay sell bandwidth access directly to end-users but useaggregator-like entities as sales channels, analogous tohotel chains in the hospitality industry. In this scenario,the aggregators do not make purchases (either in ad-vance, or in bulk) from the MNOs, but merely send theirsubscribers (to whom they are the providers of service)directly to the spectrum market to purchase bandwidthaccess from the MNOs. As already stated above, this isnot attractive to the end-users, as they are unlikely towant to deal individually with multiple MNOs, and noris it attractive to the MNOs, who need to maintain theability to sell (and more importantly, provide after-salesservice and support) to end-users directly on the mar-ket. (This problem does not arise in the hotel industrybecause each hotel chain already allows customers tobook rooms directly using the reservation system of thathotel chain.) However, smart contracts can handle thisscenario as well.

5

Yet another kind of financial arrangement on such aspectrum market is one where the billing or pricing is notby the bandwidth (MHz), but rather by the throughputwhen that bandwidth is used (MB). Although billingbased on data usage is the norm in the cellular industrytoday, and is even seen in the pricing tiers of an advancedMVNO-like service like GoogleFi ($10 for every 10GBafter the first 10 GB), we argue that such billing practicesare the consequence of the present illiquid semi-staticspectrum allocation mechanism and will not be sustainedin a dynamic market for spectrum. The reason is that theactual scarce quantity is bandwidth and not throughput.Bandwidth and throughput are related in the sense thatlarge bandwidth allows potentially large throughput, andconversely, large throughput cannot be achieved over anarrow bandwidth. However, once a certain amount ofbandwidth has been assigned to a given end-user forits use, it costs the network operator only negligiblymore5 to support the maximum possible data rate overthe allocated bandwidth than to support a lower datarate. Thus a dynamic market for spectrum will aim toachieve efficient allocation of the actual scarce resource,namely bandwidth, which means that the most directpricing structure will be that which applies directly tobandwidth rather than indirectly to bandwidth via thethroughput when the bandwidth is in use. Nevertheless,we mention in passing that even this scenario can behandled by smart contracts.

4.2 Blockchains to implement smartcontracts

In late 2008 the white paper [8], under the presumedpseudonym Satoshi Nakamoto, was distributed on acrypto mailing list. It proposed a novel peer-to-peer elec-tronic cash system. Just a few months later Bitcoin wasborn based on the algorithms presented. The algorithm,which today is commonly referred to as the originalblockchain algorithm, describes a new currency wheretransactions are recorded in a decentralized public ledgerwithout central control from any banking organization.Anyone may access the ledger and confirm the validityof both historical transactions as well as the currentlatest transaction state. Although the ledger is public,the identity of the transacting parties is anonymous. Inorder to write into the ledger, i.e. write the next blockor transaction into the transaction history, a distributedconsensus protocol is used to ensure that only a singleverified trace of transactions may exist. In the originalBitcoin paper Proof-of-Work (POW) was used to ensure

5The greater cost comes from increase power consumption totransmit more data.

this property and to incentivize hosting of the ledgerand moving the ledger forward. POW relies on mining,or solving complex mathematical problems, where theproblems are defined using random hash functions insuch a way that their solution necessarily involves tryingpossibilities one by one until a solution is found. Findinga solution is therefore like winning a lottery, and earnsthe winner the right to write the next block into theblockchain and in the process receive a small amount ofthe cryptocurrency (hence the name “mining”).

Since the original algorithm, two flavors of blockchainshave emerged, permissioned and permissionless. In apermissionless blockchain (like the one in Bitcoin) anyonefollowing the POW rules may write into the ledger, whichis fully public.

In a permissioned blockchain only a pre-defined setof nodes have access rights to, and may write into, theledger. Since it is popular in private Enterprise settings,it is sometimes also called a private or an Enterprisetype blockchain. The main benefit over the permission-less blockchain is that a permissioned blockchain mayreach consensus quicker and thus increase the rate oftransactions that may be supported. Moreover, permis-sioned blockchains may assume that all (or nearly all)nodes are up and running all the time (unlike in per-missionless blockchains, where miners may leave or jointhe network at any time). This makes it possible forpermissioned blockchains to use older Byzantine FaultTolerance (BFT) consensus protocols which yield a prop-erty called finality (i.e., non-reversibility of transactionsat a certain depth in the blockchain) that is not availablein, say, a permissionless blockchain like Bitcoin6.

Smart Contracts are a form of self-executing agree-ment between buyers and sellers originally proposed in[12]. The terms of the agreement are encoded in a com-puter program responsible for executing, controlling, anddocumenting all events that pertain to the contract. Al-though this idea predated the Bitcoin paper by morethan a decade, today smart contracts , typically andhere, refers to programs that are hosted and documenttheir transactions in a blockchain network.

Non Fungible Tokens (NFTs) are yet another blockchain-related invention where digital asset ownership as well astransfers of ownership are recorded on a public blockchain.The concept was popularized and gained mainstreamprominence in the CryptoKitties game 7. The verifiablyunique asset when minted can define the scarcity andmap its digital version to a physical counterpart. Art,6The probability of reversal of a transaction in a block buried deepenough in the Bitcoin blockchain decreases exponentially with thedepth of the block, but is never exactly zero.7https://www.cryptokitties.co/

6

sport video clips, digital sport cards and game artifactshave all thrived as NFT assets.

Short transaction execution times, independently veri-fied transactions, self-contained cryptographically signedstandard transaction payloads, unique assets with flexi-ble scarcity arrangements, and automatically executingagreements between sellers and buyers are all propertieswe borrow from in our Bandcoin proposal.

5 DESIGN OF A BLOCKCHAINPLATFORM FOR SMARTBANDWIDTH CONTRACTS

This section describes the high level-design of a smartcontract used to sell and purchase mobile network band-width contracts that grant the holder access to a networkon the specified bands with the specified bandwidth forsome given time in a given location.

5.1 Fundamental Building BlocksWe expect a permissioned blockchain to be used so onlycertain trusted or certified actors like MNOs can postoffers on the blockchain. Anyone with a large enoughbudget may buy bandwidth according to the rules of thesmart contract.

The smart contract is defined in the following terms,all described in more detail below:

∙ Actions what actions are allowed to modify theblockchain ledger.

∙ Payload what fields and values may be submittedto perform certain actions

∙ Processor the processor is where all the smartnessor logic of the contract is defined. E.g. which actionsand what fields and values may be submitted toperform certain actions, and what is the resultingstate given a previous state in the ledger.

∙ Ledger State The record that represents the cur-rent state of the ledger for a bandwidth offer. Thestate determines how actions result in new states.

5.1.1 Transaction Actions. We define the followingactions that can be submitted against the bandwidthblockchain:

∙ create Both MNOs offering bandwidth and any-one purchasing allocations like consumers or serviceproviders must create an account with the publickey of their private key being the unique accountname, before performing any transactions. At cre-ation time the account has a 0 balance.

∙ deposit To fund accounts with the bandwidth cur-rency, here called Bandcoins, an Exchange needs

to deposit some units of Bandcoins into an ac-count. An Exchange is a trusted super user onthe blockchain that can ingest currency like a cen-tral bank. In practice the Exchange is simply theback-end of a payment gateway. We will discussthis process in more detail in the implementationsection below.

∙ withdraw An MNO will be paid in Bandcoins andmay want to exchange that into another currency.The trusted exchange that is allowed to deposit isalso similarly allowed to withdraw funds from theblockchain back to another currency via a paymentgateway credit.

∙ transfer Anyone with an account with a non-zerobalance, may transfer parts or all of that balanceto another account. Note, for actual purchases andsale of bandwidth funds are transferred atomicallyso does not have to be done with the transfer ac-tion. The transfer action is useful to decentralizefunding into accounts. The top-level root exchangemay inject funds into the system, and other ac-counts may then trickle those funds into individualaccounts. There may also be some out-of band, cus-tom service that one account wants to pay anotheraccount for, e.g. a periodic release of funds like asalary

∙ offer The offer action is used to create a bandwidthoffer by a trusted MNO. The offer specifies thebandwidth, the frequency band, the number ofunits available for sale, the price per unit, durationof access, and various discounts for bulk purchasesand future reservations. Note the offer only hasthe minimal required meta data about the offerthat are contractually binding and written to theledger. Other meta data may be stored in discoveryservices.

∙ allocate The allocate action is used to purchaseindividual units of an offer. If the transaction goesthrough, e.g. requester has sufficient funds andthere are units available for sale, a transactionrecord will be written to the ledger that can beused by the receiver to prove its bandwidth grant.The allocate action may also be issued by a 3rdparty such as a service provider to purchase grantsfor others. In that case, the action would includethe public keys of the holders of the private keysthat are intended to use the allocations. Note, theprivate keys may not be mapped to actual con-sumers at the time of purchase. If no public keysare included, the issuer (transaction submitter) ofthe action is assumed to be the consumer as well.

7

5.1.2 Transaction Payload. The fields that need to betransmitted in the payload of a transaction request to thetransaction processor depends on the action performed.But some fields are shared across actions.

∙ action one of the actions defined above.∙ provider In the case of an allocation, deposit,

withdrawal the provider is the public key or accountname of the target, e.g. the MNO for allocations.

∙ price This is used by all actions except the createaction to specify the number of Bandcoins thatpertains to the action. For an offer it would bethe unit price. An allocation must specify a pricethat matches the offer price targeted, as a safetymeasure for a consumer so they don’t get any un-suspecting charges. For deposit, withdrawal andtransfer it is the amount involved in the transac-tion.

∙ epoch Offers are immutable in that each new offerresults in a new epoch. The first offer will be givenepoch 1. All subsequent offers will bump up theepoch with one. In an allocate request, the con-sumer or a service provider can hence match theoffer listing epoch with the requested contract tomake sure they get the posted contract, or theirrequest is reject if a new offer has been posted toreplace the old one in the meantime. The epochfield may also be used for future reservations. Evenin this case there must be a matching future reser-vation offer for that epoch for the allocation tosucceed.

∙ from_frequency Lower frequency of the bandoffered.

∙ to_frequency Upper frequency of the band of-fered.

∙ bandwidth Bandwidth offered within the band.Must be less than or equal to to_frequency minusfrom_frequency.

∙ max_allocations Used in the offer action to setthe number of units that may be sold (in the currentepoch)

∙ volume_discount A value between 0 and 1 de-noting the level of discount for bulk purchases.The 𝑛th item beyond the first is charged 𝑝𝑟𝑖𝑐𝑒×𝑣𝑜𝑙𝑢𝑚𝑒_𝑑𝑖𝑠𝑐𝑜𝑢𝑛𝑡𝑛.

∙ reservation_discount A value between 0 and1 denoting the level of discount for purchases inadvance. Making a purchase 𝑛 periods in advancecosts 𝑝𝑟𝑖𝑐𝑒 × 𝑟𝑒𝑠𝑒𝑟𝑣𝑎𝑡𝑖𝑜𝑛_𝑑𝑖𝑠𝑐𝑜𝑢𝑛𝑡𝑛. Note thatthe price can differe between different epochs inthe future..

∙ reservations A dictionary keyed by epoch withthe fields, price, and capacity. If the epoch exists asa reservation state in the ledger it will be updated,if the capacity is 0, the previous reservation in thatepoch will effectively be deleted. All other caseslead to merges of reservations offered. The capacityis honored for advanced purchases any numberof epochs in advance. If the epoch becomes thecurrent epoch the spot capacity, i.e. what’s definedin max_allocations becomes the units available forsale. Note, like with any other types of modificationto the offer the epoch is bumped each time a newreservation epoch is added or modified.

∙ allocation_duration The time a grant is valid,in seconds

∙ epoch_to In an allocate request the issuer mayrequest a whole series of consecutive future alloca-tions in one transaction. Note, all epochs must beavailable for reservation.

∙ consumers. For bulk allocations or for allocationby a 3rd party, public keys may be specified forwho is allowed to consume the allocation. Theprivate keys may be mapped to actual users afterthe transaction has completed.

5.1.3 Transaction Processor. The transaction proces-sor defines how a current ledger state is transformedinto a new state and what payloads are needed for thetransaction to succeed. The transaction processor alsocryptographically verifies the issuer of the transactionusing PKI. For instance, an offer can only be posted bythe account owner as per the public key of the issuer.We only list the rules for the offer and allocate actionshere as the other actions just perform trivial transfersbetween accounts as you would expect from any bankinglike transaction. An account balance cannot go below0 as a general rule. In terms of the transfer the veri-fied issuer needs to match the account the funds aretransferred from.

∙ offer all fields mentioned above need to be specifiedexcept 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 accessthe grant, with the exception of auctions as we willsee below). In practice only trusted MNOs wouldbe allowed to post offers. Note that setting an offerwith max_allocations to 0 is essentially turningoff the offer and not allowing any more allocations.Whenever an offer is posted, the allocations left inthe state (see below) is reset to max_allocations

∙ allocate An allocation must specify a provider tar-get that must match an offer. The price and band

8

info must also match the current offer as a safetycheck, but most crucially the epoch must match.The consumers field may be filled out to delegatethe allocation to someone except the issuer, andshould also be used for bulk purchases. In the caseof reservation and advanced purchases, the priceneeds to match the total computed cost for thefull purchase not the spot price in the offer. Thisagain verifies that the issuer and the transactionprocessor are using compatible pricing algorithmsand there are no surprises in what is charged tothe issuer account. The issuer account will getthis amount withdrawn if there are sufficient fundsand the target account will be credited with thisamount. The number of allocations requested needsto be equal to or less than allocations left in theledger state.

5.1.4 Ledger State. On completion of a successfultransaction the ledger state is updated and the pay-load that was submitted is recorded in the transactionlog atomically and with consensus verification in theblockchain. The following state is recorded and availablefor 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

current offer.∙ epoch current epoch for current offer.∙ from_frequency Lower frequency band in cur-

rent offer.∙ to_frequency Upper frequency band in current

offer.∙ bandwidth bandwidth of current offer.∙ price (spot) price of current offer.∙ volume_discount volume discount of current of-

fer.∙ reservation_discount reservation discount of cur-

rent offer.∙ allocation_duration allocation duration of cur-

rent offer.∙ reservations dictionary keyed by epoch of future

reservations that may currently be purchased.Note, only name and balance are relevant for a consumeraccount that is not also a provider.

5.2 Interacting with the BlockchainGiven that the payloads, processing, and state are alldefined, the processors may run and be hosted by anyand all nodes making up the blockchain infrastructure.Below we will show the basic means by which externalparties interact with this blockchain.

5.2.1 Transaction Client. A transaction client libraryis provided capable of packaging transaction requestswith the correct payloads for the actions available. Italso handles local key management and signing, encap-sulation and serialization of transactions. Transactionsmay be submitted in batches by 3rd parties, i.e. doesnot have to be submitted by the entity signing individ-ual transactions in the batch. Offer creation may berestricted to authorized users such as trusted and certi-fied MNOs. The transaction client also uses blockchainAPIs to retrieve the current state of accounts, includingaccount balances and current offers, as well as listingtransactions for verification.

5.2.2 Transaction Tunneling. Given that all transac-tion requests are signed by the issuer, the requests may betunneled easily in routers and transported through differ-ent 3rd parties such as service providers or auctioneers aswe shall see below. We may also tunnel the transactionsthrough RF links such as LTE NAS. The transactionswhen executed are logged in the public ledger togetherwith the resulting state for anyone to verify, so there isno inherent need to encrypt the payload. Transactionreplay is not possible by virtue of the payload signaturedesign, and should multiple transaction processor try toexecute the request concurrently only one will succeedto write into the consensus approved ledger. However, a3rd party or middleman may delay or stop a transactionrequest from being executed, again something that isleveraged in the auction design below.

5.2.3 Payment Gateway Exchange. As we alluded toin the actions section above deposits and withdrawalsare used to exchange other currencies for Bandcoins inthe blockchain. Trusted exchanges will integrate witha payment system in the form of an online store or apayment server, which upon verification of payment fromanother currency will deposit funds into the bandwidthblockchain. The reverse is also possible where the ex-change can pay into another currency if the requester canprove they own a Bandcoin account in the blockchain,e.g. if a MNO wants a payout in traditional currency.Each exchange will thus also define the exchange rate.One could also imagine deposits being made as an in-centive of an external action, such as signing up for asubscription for another service, and of course an Ex-change could give bulk discounts for transferring Bitcoinsinto the blockchain as well, like minutes on a call plan.Yet another use case is some service provider that de-cides to transfer credits into its subscribers’ accounts ona periodic basis or as needed.

9

5.3 Blockchain consensus protocoldesign

Unlike the blockchain networks for public cryptocur-rencies like Bitcoin and Ethereum (which was designedto support smart contracts), the “nodes” running theblockchain network that supports the smart contractsfor the proposed spectrum market may be assumed tohave cleared scrutiny and hence be trusted. This is be-cause the nodes are components of a cellular wirelessnetwork where such authentication, validation, and en-forcement/checking of trust are built into the existingsystem.

Recall, a blockchain network running on a vettedset of nodes is called a permissioned blockchain (asopposed to Bitcoin, for example, which is an exampleof a permissionless blockchain network). The use of apermissioned blockchain does not eliminate the needfor security – in particular, the property of ByzantineFault Tolerance (BFT) to ensure security in the cryp-tographic sense against an intelligent adversary whomay hack/hijack/bribe a certain fraction of the nodes.However, the permissioned blockchain allows for the useof consensus protocols like PBFT [3] that also providethe benefits of finality (i.e., a smart contract cannotbe voided in the future by an adversary forcing theblockchain to switch to a different fork that does not con-tain the block with that smart contract) along with lowlatency (i.e., a smart contract can be finalized quickly),neither of which holds for a permissionless blockchainlike Bitcoin. Low latency is important because smartcontracts involving allocation of bandwidth blocks toend-users need to be finalized before the epoch whenthat bandwidth block will be used by the end-user.

5.4 Auction DesignWith the basic smart contract in place, providers andconsumers can exchange access right, but one obstacleremains for providers to participate: -how should theprice be set to meet the demand?

Here, we propose a mechanism that integrates thetrust features of a distributed blockchain with the func-tionality of a clearing house you would normally see ina traditional auction.

The blockchain provides distributed smart contractsthat may be verified by any party at the time of provision-ing the resources, and it also takes care of atomic mone-tary transfer of funds between consumers and providers.The auction clearing house is responsible for solicitingprospective consumer demand by mediating pendingblockchain transactions and finding matching bids and

offers, and ultimately setting the clearing price and exe-cuting the winning transactions.

In terms of the basic blockchain mechanism we add onecomponent to the ledger state, a consumers dictionarywith public keys of consumers with the following fields:

∙ allocated a boolean indicating whether the con-sumer has claimed this allocation

∙ allocations number of allocations granted to theconsumer

∙ price the price the consumer must pay for theallocation

The network provider will pass in this dictionary inan offer to indicate a settled auction allocation and mayassign different shares and prices to different consumers.Only consumers with matching keys in this dictionarymay then purchase the allocations specified with thegiven price.

5.4.1 Auctioneer Clearing House. The clearing house isintended to mediate between entities that offer and pur-chase smart contracts on the blockchain. If the blockchainis used directly by consumers and providers it could beseen as a posted-price spot or on-demand market. Suchmarkets may be efficient when providers have enoughinformation to set the price that correctly match sup-ply with demand, but soliciting such information withvarying offers over time would be inefficient, in particu-lar in the use case of interest of automated short-termmicro-contracts for cellular spectrum resources.

A feature of blockchain transactions is that the inputmay be cryptographically signed and put on hold beforeexecuted by a 3rd party against the transaction processorfor ledger recording and verification. That means thatwe can submit the purchase transactions before the offertransactions and keep them in a pending state in theclearing house until a price is determined, at whichtime an offer is generated and the winning bid(s) is(are)executed as a normal purchase transaction(s).

By allowing providers insight into the pending bids,they may set an offer price that is more in line with thecurrent demand. Conversely, the consumer could revealtheir true preferences in a sealed bid without being takenadvantage of with higher-than-demand pricing.

For different clearing mechanisms, what informationis revealed and exposed to the consumer (bidder) andprovider (offer generator) may vary. We give examplesof Vickery and Proportional share auctions below.

The consumer must however be able to, at a minimum,query the state of their bid to be able to determine if theyhad a winning bid that got executed, so they can exercisethe allocation and use the cellular network bandwidthpurchased.

10

The successful execution of a transaction submitted bya consumer (as a bid) relies on the provider creating anoffer that matches and that is only possible to purchaseby that one consumer.

In case of second bid auctions this may provide a chal-lenge as the final price is not the price the consumeragreed to pay but the price submitted by the secondhighest bid. In that case we propose a price refund mech-anism, where the first price transaction is submitted andthe provider then refunds the consumer the difference.

The clearing house needs to support the protocol inTable 1 and the provider the protocol in Table 2. Theprovider protocol is needed so the clearing house can askthe provider to sign a cleared offer configuration intoan offer on the blockchain. The clearing house will thenexecute the offer transaction on behalf of the provider,so the provider does not need to have direct access tothe blockchain. This design would allow delegation ofgranting different trusted providers access to enter offers.The auctioneers need to be trusted and then whoeverthey trust as providers may effectively also be trustedon the blockchain.

Next, we detail two examples of using this protocol forrunning two different kinds of auctions: Vickrey auctionsand Proportional Share auctions.

5.4.2 Vickrey Auctions. The Vickrey Auction [13] isan auction where the bidders submit their bids withoutknowing the bids of others in the auction, and the highestbidder wins but the price is the second highest bid. Theinteractions are depicted in Figure 1

Figure 1: Vickrey Auction interactions.

(1) Provider creates an auction with type VICKREYto ensure bids are sealed.

(2) Prospective Bidders get information about the bidwith ListAuctions and GetAuction operations.

(3) The Consumer who wants to submit a bid createsan allocate Transaction that can be executed on

the blockchain with its bid price targeted for theprovider Offer (which does not exist yet)

(4) The clearing house verifies that the bid is valid(can be executed on the blockchain)

(5) After the clearing_time of the auction passed theauction will stop accepting bids and the clearinghouse will call the offer_callback requesting anoffer to be created with the winning bidder(s) asthe targeted purchaser in the consumers dictionary.The offer will have the winning bid price, but a re-fund transaction is also requested with the amountof the winning bid – second highest bid.

(6) The provider will generate offer and transfer blockchainrequests matching the info from the clearing house.

(7) The clearing house will execute the offer transac-tion, the allocate transaction(s) of the winning bid-der(s), and the refund transaction in that order andupdate the winning bid(s)’ status to EXECUTED.All other losing bids will have their status changedfrom PENDING to CANCELLED.

(8) The consumer will query its bid and note it gotexecuted at which point it may request the spec-trum allocation from the provider and query thetransaction for proof from the blockchain.

5.4.3 Proportional Share Auctions. A Proportional Shareauction [14] is an auction where each bidder receives ashare of the resource proportional to the bid over allother bids on the same resource. It is commonly used asan alternative to second bid sealed-bid auctions as it isefficient to implement and known to converge quickly inpractice.

Only steps 1 and steps 6 change compared to theVickrey auction example above. In step 1 the auctiontype is set to PROPSHARE. In step 6 the followingprocessing is done to clear the auction:

(1) The sum of all bids is computed - > bid_sum(2) For each bidder an allocation size is computed as

𝑏𝑖𝑑_𝑝𝑟𝑖𝑐𝑒× 𝑚𝑎𝑥_𝑎𝑙𝑙𝑜𝑐𝑎𝑡𝑖𝑜𝑛𝑠𝑏𝑖𝑑_𝑠𝑢𝑚

(3) A consumers dictionary is created with all bidswith at least 1 allocation in step 2, setting theallocations to the computed value in step 2 andthe price to the price bid by that bidder

(4) The offer_callback is called to generate the offer(5) The offer transaction received from the callback is

executed(6) If the offer transaction is successful execute all bids

with an allocation greater than 0(7) Change the status of all successfully executed trans-

actions to EXECUTED and the others to CAN-CELLED (if allocations is 0) or ERROR (if thetransaction failed)

11

Table 1: Clearing house protocol.

CreateAuction The operation is invoked by the provider to create auctions.

IN auction_type [𝑉 𝐼𝐶𝐾𝑅𝐸𝑌 |𝑃𝑅𝑂𝑃𝑆𝐻𝐴𝑅𝐸]IN max_allocations max allocations of offerIN provider public key of signer of offerIN clearing_time absolute time in epochs when the auction should be cleared

and winning bid(s) executedIN from_frequency offer from_frequencyIN to_frequency offer to_frequencyIN bandwidth offer bandwidthIN epoch current offer epoch + 1IN min_price all bids need to be at least this priceIN offer_callback will be called by clearing house when auction is cleared to

generate offer and refund transactionsOUT auction_id uniquely generated auction ID

ListAuctions The operation may be invoked both by the consumer to showdetails about auctions to place a bid, or for providers to getinformation about bids. Bids may or may not be revealeddepending on whether it is a sealed bid auction or not.

IN auction_id optional to filter the results by auction_idfor each listing:OUT auction_id auction idOUT offer_details info from CreateAuction callOUT bid_details info about current bids (unless sealed)OUT status [𝐴𝐶𝑇𝐼𝑉 𝐸|𝐼𝑁𝐴𝐶𝑇𝐼𝑉 𝐸]

Bid The operation is invoked by the consumer. It embeds ablockchain allocation request.

IN auction_id auction ID to bid is forIN bid encoded serialized and signed blockchain allocation including

bid priceOUT status [𝑃𝐸𝑁𝐷𝐼𝑁𝐺|𝐸𝑋𝐸𝐶𝑈𝑇𝐸𝐷|𝐶𝐴𝑁𝐶𝐸𝐿𝐿𝐸𝐷|𝐸𝑅𝑅𝑂𝑅]OUT bid_id public key used to sign bid

GetBid The operation is invoked by the consumer to retrieve statusof bid.

IN auction_id auction ID bid is forIN bid_id bid IDOUT status [𝑈𝑁𝐾𝑁𝑂𝑊𝑁 |𝑃𝐸𝑁𝐷𝐼𝑁𝐺|𝐸𝑋𝐸𝐶𝑈𝑇𝐸𝐷|

𝐶𝐴𝑁𝐶𝐸𝐿𝐿𝐸𝐷|𝐸𝑅𝑅𝑂𝑅]

6 IMPLEMENTATION NOTESWe have implemented the design proposed in the pre-vious section using the Hyperledger Sawtooth Core 8

blockchain.

8https://www.hyperledger.org/use/sawtooth

The blockchain state as well as the payloads areencoded as JSON objects. Our implementation inter-acts with Sawtooth mainly through the REST API, viaSDKs. One of the key reasons we picked Sawtooth, apartfrom having an easy-to-deploy development environmentbased on docker, was the multi language support. It was

12

Table 2: Provider (callback) protocol.

GenerateOffer Used by the clearing house to generate offers and refundswhile clearing an auction.

IN price offer priceIN refund refund amountIN from_frequency offer from_frequencyIN to_frequency offer to_frequencyIN bandwidth offer bandwidthIN consumers Consumer specific allocations and pricing to be put in offer (optional)

to restrict who can make purchasesIN max_allocations offer max allocationsOUT offer encoded serialized and signed blockchain offer transactionOUT refund encoded serialized and signed blockchain transfer transaction

easy to integrate with our Python backends, as well asour Android clients.

We provide a Transaction Processor that registers withthe validator, and a client library, both implemented inPython3. All our services are implemented with PythonFlask REST APIs using JSON payloads as well.

The tunneled transactions use Protocol Buffer 9 serial-ized Transaction and Batch encapsulations according tothe Sawtooth protocol 10 and are then base64 encodedin JSON fields for our APIs.

All sawtooth and custom services are hosted in Dockercontainers and interact within a private docker network.The services may be distributed with something likeDocker Swarm or Kubernetes, but for testing they allrun locally using docker-compose and the developer modeblockchain.

The transaction processor implementation allows apublic key to be set with Exchange privileges. Thatmeans that whoever can prove they have the privatekey corresponding to the public key may perform theprivileged operations such as injecting or removing fundswith the deposit and withdraw actions. The service thatowns the Exchange private key is the point of integra-tion with payment gateways. We have implemented twointegrations, Saleor and Braintree, discussed next.

6.1 Saleor Payment IntegrationSaleor 11 is an open-source, customizable e-commerceshopping cart solution, where popular credit cards can beused to pay for items. We added custom product itemsthat allows you to purchase Bandcoins in different chunks,9https://developers.google.com/protocol-buffers10https://sawtooth.hyperledger.org/docs/core/releases/latest/_autogen/txn_submit_tutorial.html11https://saleor.io/

such as 100, 200, 500, 1000 Bandcoins at different USDprices. At checkout of any of these items the public key ofthe blockchain account you want to transfer Bandcoinsinto has to be specified. The person making the paymentdoes not need to own the private key necessarily as it canfund anyone’s account with this mechanism. As the ordergoes from pending to cleared by the payment system,our Exchange service checks the Saleor order databaseto detect new finalized orders where payments havebeen confirmed. When the order is deemed finalized,the Exchange service pulls the number of Bandcoinsspecified in the order and creates and executes a deposittransaction with that amount on the blockchain.

Saleor supports a dummy payment provider that is con-venient for development but also many other providersthrough payment gateways, including Braintree (see be-low).

Saleor is a great tool for getting started quickly with aWeb portal to fund blockchain accounts with traditionalcurrency. The process of entering the public key to fundand going through all the steps of searching for productand adding them to the shopping cart is however a bittedious, in particular from mobile phones where you maywant to perform fund operations to be able to purchasemobile access. Therefore we also provide a mobile APIimplemented in Android, using the Braintree paymentgateway system, described below.

6.2 Braintree Payment IntegrationBraintree 12 is a payment gateway service that handlesintegration with most popular payment providers suchonline wallets, credit and debit cards.

12https://www.braintreepayments.com/

13

Its Android API is very easy to integrate into yourown app with a few calls to a service you need to imple-ment to handle payment processing. The service needsto be registered in your Braintree account online, butthen a python Flask REST API server can easily beimplemented to interact with your app and Braintree.This server runs in our Exchange service and will oncompletion of payment processing credit the blockchainaccount of the Android phone with the correspondingnumber of Bandcoins that was bought.

This allows the phone to easily replenish Bandcoinsspent without leaving the app. For the end-user it alsoprovides a one or two-click solution, as a credit card thathas been used once can be reused from the same appwith a single click to buy additional Bandcoins.

The backend of this solution is also more reliable thanthe Saleor integration as our custom payment server canget notified directly when a payment has been completedand does not have to poll orders for status.

6.3 QoS ExtensionsThe payload structure for allocations and offers is en-coded in JSON and thus lends itself well to extensionsand customizations. One set of extensions that may beof interest is QoS levels. The provider may post differentoffers at different prices and with different custom QoSlevels, which later can be enforced in the mobile core,for example by using network slicing or usage account-ing. Many mobile plans today are not only restricted byaccess time but also capped by data usage. So we couldadd in a GB limit as a QoS level, and be able to chargemore for the same contract with a higher cap. We note,though, that capping in this way is less critical than intraditional contracts given that they are by design onlyintended for short periods of time when the customeractually wants to use the network.

Similarly, some post-payments may be desirable forthe providers, based on usage, i.e. if that data cap isexceeded. This feature could again be specified in acontract extension and enforced post-contract based onaccounting information as well as making use of thetransfer blockchain action to pay for additional services.Again, shorter time spans, and the ability for consumersto simply switch to another provider if QoS is not met,makes these post-payment plans less fundamental thanin a traditional roaming setup.

To allow for these extensions to be passed into offersand recorded on the blockchain ledger they could beencapsulated in a well-known qos dictionary field.

6.4 Transaction ProcessingPerformance

Transaction processing time both in terms of latency andthroughput matters when it comes to the granularityof contracts we can support in the time domain. Theoriginal blockchain protocol is notorious for being slow atconfirming transactions, and the cryptographic routinesused to secure all ledger writes also bring overhead. Saw-tooth offers some optimizations in terms of transactionparallelism but if you are writing to the same state theparallelism that is possible is limited. As a result, weintroduced bulk allocations, where multiple allocationsto different consumers, distinguished by different publickeys, may be purchased in a single Sawtooth transac-tion. See the design section for details on how this isimplemented in the protocol and the smart contract. Totest the limits and the improvement of bulk allocationswe tested different bulk sizes and different concurrentprovider purchases with the same consumer account. Theresults can be seen in Figure 2.

Figure 2: Transaction throughput with differentbulk sizes and concurrent providers.

In summary, we can improve the throughput of allo-cation agreements settled by four orders of magnitude(from about .5-1 allocations per second to 10,000-13,000transactions per second) for a single provider with a bulksize up to 50,000. We see that bulk sizes over 10,000 donot improve performance much but that there is a linear

14

increase for bulk sizes 1-10,000. Submitting allocationtransactions for multiple providers concurrently is notas efficient of a mechanism to improve throughput asbulk allocations, as seen by the fact that 3-6 paralleltransactions (providers) only reaches a peak through-put of about 1000 allocations per second. The drop ofhigher parallelism with small bulk sizes could be seen asan experiment setup artifact, where previous large bulksizes impact the restart of the experiment run. It alsohighlights the general strain on the system of increasedtransaction parallelism. Another interesting phenome-non is the drop at the high end, where throughput issatisfied, which is clearly a function of the number ofparallel transactions, and again points to the efficiencyof our bulk allocation mechanism.

7 LESSONS LEARNED

Table 3: Comparison of Bandcoin transactionswith other technologies.

Bandcoin Roam NFT BitcoinAuto X X XFast XUnique X X XPeriodic X XScarcity X X XBulk XReserve XTunnel XAuction X

We have found that the permissioned blockchain modelto be a very powerful comcept to automate bandwidthcontract purchases in mobile networks. A contract canbe purchased within a second 13 assuming funding hasalready been setup and made available through a pay-ment gateway as described in the previous section. Notethat transaction throughput may be improved by makinguse of transaction batches or purchasing allocations formultiple users at a time, or multiple blocks at a time.The sub second contract negotiation is easily hidden inthe process of switching network providers as the LTEAttach call alone to authenticate takes close to a secondin most networks, and as a comparison loading an eSIMon a phone takes 2-3 seconds. This mechanism opensthe door for much shorter and finer grained contracts

13local host full RPC from transaction submission to ledger report-ing committed as 0.5-1s in our test, with single validator devmodeconsensus algorithm.

for mobile access including roaming agreements. Tradi-tional physical SIM contracts are typically negotiatedon a yearly basis and eSIMs today are commonly offeredon a monthly or weekly basis. The contracts describedhere could realistically be offered down to a 10-15 secondbasis, but more realistically on a minute-by-minute orhour-by-hour basis. These times can be cut further whenphones start offering multiple eSIM slots to make it evenfaster to switch between providers.

The cryptographic guarantees and the message-levelas opposed to transport-level security offered by theblockchain design is also ideal for service provider inte-grations, similar to our auction service design, where athird party service purchases allocations on behalf of itsusers.

We have also experimented with tunneling these con-tract negotiations with the LTE protocol using the SIBand NAS mechanisms that can be run in a disconnectedstate before carrier authentication. Some more detailson that work are available in [10].

NFT assets share many features to our bandwidthcontracts. Similarities include, ability to mint scarcityand asset price at contract setup, asset sharing, uniqueand distinguishable (enforced through our epoch mech-anism) asset tracking and 3rd party verification, andmaintaining blockchain records of all transactions.Wedon’t support blockchain recorded transfer of ownershipand royalty processing as in NFTs, instead we allowexternal resale of grants encoded as PKI keys 14. Fur-thermore we support an inherent bidding model whereprices are determined in auctions and the bids may bekept private and result in proportional grants of resourceallocations.

We have summarized the differences in Table 3, whereroam, denotes the current LTE roaming protocol, uniqueand periodic pertain to the issued grants, scarcity refersto whether you have control over the scarcity of resourcesat creation or minting time, bulk and reserve indicatewhether bulk allocations and advanced reservation of re-source blocks are supported, respectively. Finally, tunnelrefers to whether 3rd parties can execute encapsulatedtransactions, and auction indicates whether auction pur-chases (demand-discovery) is supported.

REFERENCES[1] FCC: 16-55: The Second Report and Order and Order

on Reconsideration finalizing rules for innovative CitizensBroadband Radio Service in the 3.5 GHz Band (3550-3700 MHz). https://apps.fcc.gov/edocs_public/attachmatch/FCC-16-55A1.pdf. 2016.

14A design critical to our bulk allocation performanceimprovements.

15

[2] A. Afif Monrat, O. Schelén, and K. Andersson. Blockchainmobility solution for charging transactions of electrical vehi-cles. In 2020 IEEE/ACM 13th International Conference onUtility and Cloud Computing (UCC), pages 348–253, 2020.

[3] Miguel Castro and Barbara Liskov. Practical byzantine faulttolerance. In Proceedings of the Third Symposium on Oper-ating Systems Design and Implementation, OSDI ’99, page173–186, USA, 1999. USENIX Association.

[4] John M Chapin and William H Lehr. Cognitive radios fordynamic spectrum access-the path to market success for dy-namic spectrum access technology. IEEE CommunicationsMagazine, 45(5):96–103, 2007.

[5] S. Jeong, N. Dao, Y. Lee, C. Lee, and S. Cho. Blockchainbased billing system for electric vehicle and charging station.In 2018 Tenth International Conference on Ubiquitous andFuture Networks (ICUFN), pages 308–310, 2018.

[6] Khashayar Kotobi and Sven G Bilén. Blockchain-enabledspectrum access in cognitive radio networks. In 2017 WirelessTelecommunications Symposium (WTS), pages 1–6. IEEE,2017.

[7] Khashayar Kotobi, Philip B Mainwaring, and Sven G Bilen.Puzzle-based auction mechanism for spectrum sharing incognitive radio networks. In 2016 IEEE 12th InternationalConference on Wireless and Mobile Computing, Networkingand Communications (WiMob), pages 1–6. IEEE, 2016.

[8] Satoshi Nakamoto. Bitcoin: A peer-to-peer electronic cashsystem. Technical report, 2008.

[9] Mostafizur Rahman. A game-theoretic model for regulat-ing freeriding in subsidy-based pervasive spectrum sharingmarkets. PhD thesis, University of Central Florida, 2018.

[10] Thomas Sandholm and Sayandev Mukherjee. A multi-armedbandit-based approach to mobile network provider selection.arXiv preprint arXiv:2012.04755v2, 2021.

[11] Munawwar M Sohul, Miao Yao, Taeyoung Yang, and Jeffrey HReed. Spectrum access system for the citizen broadband radioservice. IEEE Communications Magazine, 53(7):18–25, 2015.

[12] Nick Szabo. Smart contracts: building blocks for digitalmarkets. Extropy, 16, 1996.

[13] William Vickrey. Counterspeculation, auctions, and com-petitive sealed tenders. The Journal of finance, 16(1):8–37,1961.

[14] Carl A Waldspurger. Lottery and stride scheduling: Flex-ible proportional-share resource management. PhD thesis,Massachusetts Institute of Technology, 1995.

[15] Hong Xu, Jin Jin, and Baochun Li. A secondary market forspectrum. In 2010 Proceedings IEEE INFOCOM, pages 1–5.IEEE, 2010.

[16] Seppo Yrjölä. Analysis of blockchain use cases in the citizensbroadband radio service spectrum sharing concept. In Inter-national Conference on Cognitive Radio Oriented WirelessNetworks, pages 128–139. Springer, 2017.

[17] Zhenyu Zhou, Xinyi Chen, Yan Zhang, and Shahid Mum-taz. Blockchain-empowered secure spectrum sharing for 5gheterogeneous networks. IEEE Network, 34(1):24–31, 2020.

16