Skip to content

Bandwidth sharing

With the lack of proper infrastructure in our target countries, there is almost no public Wi-Fi present. Shopping malls, restaurants, bus stations and shops all lack shared connectivity.

K3 is already testing a technical solution that allows for sharing bandwidth through special access points, and 3air will provide the right interface and blockchain solution for it.

There are 2 main issues with bandwidth sharing:

  1. Local regulations.
  2. Terms and conditions from the ISP provider.

Each country wants to control the usage of the internet in some manner. That’s why ISPs are regulated companies and require a license to operate. Each user needs to register so that there is a track record in case of any criminal activities. The same goes for mobile operators. There are a few exceptions to the rule with public Wi-Fi connections and similar, but even there it’s usually at least one authentication method in place.

Secondly, ISPs don’t allow for commercial or uncommercial sharing the bandwidth with others. This is especially true if on a shared connection plan that are by far the most popular type of broadband connectivity today. The ISPs that operate a shared network, sell your bandwidth cheaper than they buy it as they resell it multiple times. They operate on the premise that not everybody will use the full bandwidth at the same time and apply a fair usage policy. So, no bandwidth sharing is allowed on such connections and the ISP has the right to decline you services if your bandwidth usage is excessive.

There have already been raised concerns in the communities of such sharing economies about the long-term feasibility and potential crackdown from ISPs. (Is anyone concerned about what happens when ISPs get wise to the game re: internet usage?, 2021)

To avoid these issues, we are allowing for differentiation of services on our platform, where ISPs can choose to allow bandwidth sharing and charge a premium for it. When the user acquires such a package, he will get provided with a proper access point hardware, preinstalled with a software solution that allows for multiple, payable, or free connections. The user can also decide to share the bandwidth for free. This is especially desirable for shopping malls, restaurants and similar places that can market themselves better with such additional service.

To avoid the regulations issues the users will authenticate with their DIDs or they will use the internet under a short-term public connection policy that requires light authentication only.

Types of users

There are 4 types of users in the 3air bandwidth sharing model:

  • ISP, providing original bandwidth,
  • Access point operator, sharing his own bandwidth,
  • Consuming user, connecting to the shared access point.
  • Insurance provider, ensuring sustainable system maintenance.

These users incentives are not aligned and must be managed carefully.

ISP

The ISP’s basic business model is making revenue from selling bandwidth as its primary service and main revenue stream. ISP’s goals in a sharing economy are:

  • Create an additional revenue stream from selling bandwidth to transitory users (tourists, shop visitors, etc.).
  • Create an additional revenue stream from upselling existing users to be able to use roaming.
  • Promote themselves with providing exceptional services in public places, therefore gaining new customers.
  • Offer roaming possibilities on fixed connections to their clients and clients from other networks.

ISPs are strongly opposed to sharing bandwidth as it:

  • Promotes unnecessary network loads and unfair data usage.
  • Clogs up broadband infrastructure, especially at peak times.
  • Causes additional costs in needing to buy more bandwidth from the backbone providers.
  • Reduces their main revenue stream.

ISPs will therefore never allow bandwidth sharing without being additionally incentivized. Because of the sharing nature of most retail internet connection plans, ISPs will deny service if they notice unfair bandwidth usage. If you are constantly utilizing 100% of your shared connection, the ISP has the legal right to deny you service, even if you did not share your connection.

Access point operator

The Access Point (AP) Operator’s motivation in running an access point will vary greatly but can be summarized as one of the following:

  • Additional revenue stream from providing a connection point as a service.
  • Better customer experience within their business therefore building out the brand name and providing an edge over competition.
  • Attracting more transitory customers, such as tourists.

Someone from a developed country, where quality Wi-Fi or mobile data is available everywhere, it may be difficult to comprehend the advantages of being able to provide quality connectivity in public places or businesses.

Good connectivity in developing countries is hard to come by so providing such a service can have a big competitive edge. Shopping malls, restaurants, tourist centers, bus stations, banks, they all would benefit from providing public internet services.

Also, other users may be incentivized by earning additional revenue from providing a connection spot.

Consuming users

The consuming user has the following incentives to use the public access points:

  • Roaming capabilities on his fixed broadband.
  • Cheap, short-term access to quality Wi-Fi in public and semi-public places.

Insurance provider

The insurance provider takes on the risk of a HW failure and needs to be compensated by an appropriate reward. The Insurance provider incentives are the rewards from the Staking and Access Point pools.

Sharing model

There are different approaches to building out an IoT sharing economy and allowing bandwidth sharing. Some are using blockchain technology, like Helium and World Mobile Token and others are cloud based or similar, the biggest probably being Xfinity . Some of these models have already been applied and seem to tackle the tragedy-of-the-commons (Hardin, 1968) situation well, while the others still need to deploy and be tested in the real-world setting.

There have been many papers published on the topic of fair bandwidth sharing (F. P. Kelly, 2003) (D. Shah, 2011) (Lautenschlaeger, 2014). Those papers are intended for ISPs to set up a sustainable, cost effective and fair-use shared bandwidth model, but on a smaller scale they are also relevant for broadband sharing on public spaces. The challenge here is, how to provision bandwidth to the connected users to fairly distribute the available bandwidth without compromising on the quality of the connection for each user. This calls for a basic decision model and validating and finetuning it in a real-world setting. 3air plans to tackle this with the help of K3 expertise and experience in the shared broadband model at the ISP level. We believe that this is not a problem that blockchain needs to solve. The provisioning and fair usage does not need to be managed in a permissionless and decentralized way. Standard models allow for greater efficiency in this type of transactions and does not contribute significantly to the security or privacy as this data is not sensitive, attributed to a specific user or in general desirable to hack.

Blockchain-based micro-economies thus seem well designed for enabling bandwidth sharing (Bello, Muhammad, Binta, & Ahamed, 2021) (de Vos & Johan, 2018). They can work well in regard to rewarding its users and encouraging them to behave well and honest in the game theory. They enable financial incentives that help resolve the tragedy-of-the-commons situation. Financial data and financial transactions benefit greatly from the transparency, security, privacy and permissionless nature of the blockchain. A pool of funds, called Access point pool, may therefore be set up, to provide incentives for good behavior in the 3air sharing model.

3air bandwidth sharing model

Figure 17 3air bandwidth sharing model

Access point insurance

For a successful operation of an access point a certain amount of 3air tokens need to be staked in a smart contract. These tokens are used as insurance in case of access point HW damage, failure or other event that need maintenance or replacement of the access point or supporting infrastructure. The required amount is to be determined at a later stage and will be adjustable. At least 25 percent of the minimum needed tokens must be provided by the access point operator to incentivize good care of the infrastructure.

In the case of any maintenance or replacement needed the insurance tokens will be reduced by the amount needed for repairs or exchange of the access point. Until the 3air platform v2 is online, this procedure will need manual involvement of the operating ISP. Information about the errors and consequent repairs will be shared and the insurance token holders will have the right to file a dispute. The final decision may be taken by a vote from all insurance token holders.

3air platform v2 will be IoT and blockchain powered allowing self-reporting and automatic payments from the insurance pool to the maintenance team once the node is back on-line. Staked tokens will have access to all relevant IoT information and will be able to veto the maintenance team decisions to prevent exploitation of the system. If no consensus will be formed, insurance tokens from other access points will be able to vote on the dispute. Such a permissionless insurance system is complex and warrants a more in-depth analysis and review that will be provided with the 3air platform v2 documentation.

There will be a list of all issued access points provided and represented by a smart contract. Any token holder will be able to stake his tokens into such a smart contract and pledge them as insurance. In the time of “early staking” (see section 5.9.1 Early staking) tokens staked for insurance will also get distributed rewards from the staking pool.

To additionally reward insurance providers, these tokens may get distributed extra rewards from the Access point pool.

The amount of tokens staked in the insurance contract drives additional speed to the access point.

Once 3air v2 is operational, the reward structures will change as the bandwidth sharing model will switch to operate on the 3air chain.

Accessing shared services

There will be professional Access Points (AP) available, provided by the ISP and preloaded with the 3air software. The AP will be selected considering the business type and will have a radius of 50 to 100 m and be able to serve up to 500 users simultaneously.

Each user connecting to an Access Point (AP) will need to authenticate himself. There are 2 ways of authentication:

  1. Full authentication, using a DID.
  2. Light authentication, using the public use policy.

The identification with a DID is almost seamless as the only thing needed is to allow the connection to the DID. The system then checks on the blockchain if the user is a 3air customer and if he has roaming services enabled and allows or denies access to the internet accordingly.

If the user is not a 3air customer, he has the option to buy a voucher code to access the public internet. The public internet usage policy sets the level of authentication, usually through validating the users email address or phone number. The voucher allows the user to connect to any 3air provided AP. Vouchers have usage limitations and automatically disconnect a client after the conditions are met.

The AP operator can choose to allow free access to the services if this is more suitable for his business model. In this case he forfeits the related rewards from operating an AP.

Internet access interface will be branded by the AP operator and the ISP providing services. The user can see the availability of a 3air connection in his home area and can apply for services.

Access point pool

The Access point pool is intended to incentivize all the parties needed to provide bandwidth sharing services to the end user. The Access point pool will be fueled by:

  • Premium fees, paid monthly by the end user for roaming.
  • Premium fees, paid monthly by the access point operator.
  • Access fees, paid by transitory users who pay online or buy a voucher.

Rewards distribution

The rewards from the Access Point pool are distributed on a weekly basis.

There are three parties that need to be incentivized to operate the bandwidth sharing system so the end user can connect to it. The AP pool is split:

  1. 10% - Access point operators.
  2. 50% - ISPs providing the bandwidth.
  3. 40% - Insurance providers.

Access point operators are distributed 10% of the total AP pool. These 10% are distributed to each pool in accordance with how many users have connected to it in past week. To calculate each AP reward, we use the formula:

Rap = Rt * Uap / Ut

Where:

  • Rap (Reward of selected AP)
  • Rt (Total rewards for all AP)
  • Uap (Unique users connected to the selected AP in the week)
  • Ut (Total users connected in the week, calculated as the sum of all Uap)

The reasoning behind such a split is simple as it incentivizes the AP operators to promote the services and connect as many users as possible. This generates revenue stream in the system.

ISP’s are bearing most of the costs in this model. They provide the initial AP, infrastructure and provide ongoing bandwidth. Therefore, they are awarded the majority of the AP pool funds. The funds are split based on connected users with a similar formula as AP operators:

RISP = Rt * UISP / Ut

Where:

  • RISP (Reward of selected ISP)
  • Rt (Total rewards for all ISPs)
  • UISP (Total users served by ISP in the week, calculated as the sum of Uap that the ISP provides service to.)
  • Ut (Total users connected in the week, calculated as the sum of all UISP)

To ensure fair rewards distribution, another option would be to split the rewards by bandwidth usage. At the same time, this opens up the potential for system exploitation with ISPs intentionally spending bandwidth. Additionally, the bandwidth tracking and calculations provide a more difficult and complex system. We have also restrained from calculating on total users as it is again easier to exploit in both the AP and ISP rewards calculations. We believe the suggested system is the best balance between fairness and complexity with the least exploiting potential.

Insurance providers also carry some potential risk and are therefore awarded 40% of the rewards. To prevent token centralization and equal distribution between APs, a system of diminishing returns will be integrated. The goal is to have as balanced AP insurance as possible. Each AP needs to be fully insured before it can become operational.

The rewards for the insurance providers are set up so that they have diminishing returns on the additional tokens staked. The formula to calculate the total insurance reward per AP is:

Ri(ap) = Ri(t) * f / APn + ((Ri(t) – (Ri(t) * f)) / Ts * Ts(ap))

Where:

  • Ri(ap) (total insurance reward for AP)
  • Ri(t) (total insurance rewards)
  • F (distribution factor between 0 and 1)
  • APn (total number of operational AP)
  • Ts (total tokens staked in all AP)
  • Ts(ap) (total tokens staked in current AP)

The distribution factor (F) regulates how much power the diminishing system has. A lower value means returns are less diminishing and higher values mean that the rewards on additional tokens will be more diminishing. With adjustments to this factor we can balance the AP insurance pools. To calculate the reward per user, we first calculate the reward per token in a specific AP:

Rt(ap) = Ri(ap) / Ts(ap)

Where:

  • Rt(ap) (Reward per token of a specific AP)
  • Ri(ap) (total insurance reward for AP)
  • Ts(ap) (total tokens staked in current AP)

The reward per user is then:

Ru(ap) = Rt(ap) * Ts(uap)

Where:

  • Ru(ap) (Reward per user in a specific AP)
  • Rt(ap) (Reward per token of a specific AP)
  • Ts(uap) (Total tokens stakes by user in the AP)

Such a system should provide a fair and competitive rewards structure with minimal centralization and exploitation options. It should incentivize all the key players to provide quality services to the end user.

The tokens are paid to the wallets that have staked the tokens.

In the time of early staking rewards, users can also decide to stake the tokens in the normal staking pool. Such staked tokens are also distributed early staking rewards.

Providing Free internet

An AP operator can decide to provide the internet to his clients for free. This is especially desirable in restaurants, bars, shops and similar, as it might attract new customers and tourists.

If an AP decides to deliver free internet, he also forfeits his right for the AP operator reward distribution. These rewards go back to the AP pool, to be used in the next distribution. The AP operator is still eligible to standard insurance staking rewards.

3air or an ISP can decide to set up a free internet AP in areas of interest. In such cases they must follow the rules of a normal AP operator.

Maintenance request cases

In the case of maintenance costs, the amount of tokens is deducted from the AP pool where each contributor gets deducted the proportional amount of how much he has staked.

For instance, if a user holds 5% of the total staked tokens in the AP, his contribution to the repairs will be 5% of total costs.

Staking and unstaking

Staking will be done via a browser application that will allow connecting a wallet in the dApp. A full list of APs will be shown but only the ones with minimum self-delegation will be active for delegating the tokens to. The AP’s will have statistics included such as total tokens staked, self-delegation percentage, maintenance request, cost incurred and current APY. Additional statistics may be included.

To delegate his stake, the user will need to select an AP and the amount of tokens he wishes to delegate and interact with a smart contract to stake them.

At unstaking the user again interacts with a smart contract. Unstaking takes 2 weeks, and no rewards are distributed during the unstaking period. After 2 weeks the user gets his tokens returned into the wallet he staked the tokens with.

Staking and unstaking to APs and the early staking pool can be done at the same if desired, but it needs to be noted that they are two different staking contracts and they have different unstaking requirements.

Roaming

Roaming within the 3air system is easy and desirable for all parties involved. There is no need for in depth contractual relationships between different providers. All the premiums and voucher funds are collected in a separate pool and distributed according to usage. Fair and permissionless. With the use of Digital Identities, that are as of now perceived inhackable, the users can connect to an AP and provable and permissionless authenticate themselves.

This goes for roaming between different providers as well as between cities or countries. Roaming is instant and fair priced.

It is to note, that ISP can also join the 3air platform with roaming function alone and just participate with allowing the setup of APs withing their networks. This may create many access points around the world. It is important, that there is an agreement in place between 3air and the ISP before a setup of an AP is allowed. This is the only sustainable way to build a sharing economy in the future. The ISP have their economic model that does not include an uncontrolled sharing of bandwidth. As of now the sharing communities are still small and mostly unnoticeable but to become mainstream, ISPs will need to be included.

Closing thoughts

It is tricky to get the details right in such a system of complex interactions. The game theory provides good insight of how different actors will act as it is in their own self-interest. We believe we have tackled all the exploit loopholes but will be monitoring the system closely once implemented to adjust the parameters of rewards distribution and insurance staking. This is by no means a closed and final model and will be evolving in the future.

At this point we would also like to ask ourselves the question, does such a system warrant a whole new second layer blockchain. There are many projects developing their chains without any real purpose or in depth thought. We agree that a side chain might have some advantages, but there are also downsides. They involve security concerns, compatibility issues, additional development time, adoption, recognition and others. There is the decision to be made how much transactions need to be recorded on the blockchain. Authentication events should be timestamped and recorded, and logs can be aggregated and recorded at certain times. We believe with data optimization a full sidechain may not be needed. That said, a sidechain might be warranted if more data want to be recorded on blockchain in real time.