The document proposes an updated version of India's PM-WANI standard called WANI 3.0 to accelerate the growth of the open wireless network by enabling new business models and transactions. Key aspects of the proposed standard include supporting delegated payments between entities, recording transactions on an open ledger, and enabling network performance auditing to help the ecosystem grow in a quality-driven manner. The goal is to realize the full potential of PM-WANI by facilitating more participation from user app developers and small businesses.

1. PM-WANI 3.0: Unleashing Business
Innovation and Open Wireless Network
Growth for Universal Connectivity
PM-WANI has allowed sachetised access to WiFi connectivity. However, the true
vision of WANI standard, where small business owners can participate as network
service providers resulting in fast network growth, has not been realised. We propose
the next version of the WANI standard where a more open ecosystem can be enabled
to facilitate business interactions such as delegated payments and roaming, which in
turn can catalyse increased user base, rapid network growth, and business
innovations.
INTRODUCTION
Internet penetration in India has grown rapidly over the past five years. We now have
an estimated 650 million internet users1
, placing us behind just China. This rapid
Internet adoption can be primarily attributed to the availability of cheaper
smartphones and data through internet service provided by mobile carriers. When
coupled with India Stack primitives such as Aadhar and UPI, this has transformed
Indians into digital citizens who transact online for e-commerce, payments, and
identification through various day-to-day applications. We are now one of the
fastest-growing digital economies in the world.
Digitization has allowed the connected citizens to access the technical and economic
progress of the world and made them a stakeholder and beneficiaries of Indian
economic growth. As a corollary, the digital divide between the connected and the
unconnected citizen now presents itself as a fundamental divide, with unconnected
citizens denied a share in India’s progress and relegated to the meagre benefits of a
trickle-down economy. Ironically, India with the second highest number of people
connected to the Internet also has the highest number of unconnected people2
. There
is an urgent need to find new techno-economic solutions for connecting the
unconnected.
2
https://www.weforum.org/agenda/2020/08/internet-users-usage-countries-change-demographics/
1
https://www.statista.com/statistics/262966/number-of-internet-users-in-selected-countries/

2. The Prime Minister’s Wireless Access Network Interface (PM-WANI) program is one
solution. It is a standard that allows poor citizens of India to access WiFi bandwidth in
small units, much like cellular connectivity, while maintaining the necessary KYC
compliance needed for security reasons. This places WiFi as a companion of cellular
connectivity to provide a ordable bandwidth (due to small, sachetised o erings) to
Indians while retaining its lower capital and operating expenditures as compared to
cellular networks.
This is one of a kind initiative designed keeping in mind Indian requirements. The
basic standard has now been adopted by initial movers. It is now time to push for the
next iteration of the PM-WANI standard, which aims to create an open bandwidth
economy. This will spur an organic growth of a nationwide WiFi network supported by
small business owners as service providers. In this paper, we present a vision for this
new version of the PM-WANI standard, termed WANI 3.0, to highlight the role of
distributed ledgers, electronic contracts, and cryptographic proof systems in this
version.
We start by providing clear motivation for the standard design and an overview of the
proposed new version in this section below. In the next section, we provide a detailed
technical description of the standard. Finally, we close by providing glimpses of the
future that we envision by discussing the rich WiFi connectivity ecosystem that we
believe will emerge out of WANI 3.0.
PM-WANI Past and Present
The developed world accesses the internet primarily via home broadband access.
Majority of the Indians (apart from urban consumers) access the internet via cellular
prepaid plans. Although cellular connectivity in India is cheapest in the world, there
are limits to its usage. Cellular connectivity is not available everywhere. Expansion of
cellular connectivity requires high capital expenditure that is undertaken only when
the demand for bandwidth is significant, ensuring profitability for the bandwidth
provider. Alternatively, cellular service providers (CSPs) can set up and use their own
WiFi network to o oad their tra c, resulting in an access network that enjoys the
low capex of the WiFi network and authentication and accounting framework of
cellular networks. However, this approach needs an understanding of the right
locations to deploy the WiFi network and provide connectivity. This leads to a high
operating expenditure for the CSPs or for any other internet service provider.
PM-WANI is a way to circumvent these obstacles in growth of a nationwide WiFi
network by providing sachetised bandwidth access by engaging local businesses as

3. providers of bandwidth. In a few ways, the approach is very similar to the process
followed in UPI to enable digital payments. Instead of expecting banks to reach out to
citizens via ATMs and online banking, UPI allowed the creation of multiple apps who
were much more conversant with the needs and wants of their customers. Like in UPI,
where a bank needed to authenticate an entity, we need to do the same here with a
user to detect and respond to malicious activities. In the cellular network the SIM card
provides a way to associate each connection with a KYC compliant registered user.
PM-WANI provides for precisely such an authentication framework. Furthermore, it
provides a simple procedure for the users to purchase sachetised WiFi access plans
from participating vendors. We provide a simplified view of the overall procedure in
Figure 1; see Table 1 for familiarizing yourself with the “cast of characters” in the
WANI story.
Entity Role
Public Data O ce (PDO) The WiFi access point deployed at the final delivery
point, which may be owned by a small business owner
Public Data O ce
Aggregator (PDOA)
An aggregator for PDOs which provides them with
their tech stack and completes WANI procedures on
their behalf
User App A mobile or laptop application that allows users to
connect to PDOs
User App Server The backend services for the User App which interact
with PDOAs to complete WANI procedures
Central Registry A central registry hosted by WANI governance body to
register di erent entities and coordinate interaction
between entities
Table 1. Main entities involved in the WANI standard, the cast of characters for the
WANI story.
With these entities in mind, the steps of the access protocol depicted in Figure 1b can
be described as follows. Even before these steps, the user has already registered with a
User App (which itself is registered at the central registry) and obtained a WANI token
for access.
1. User (or more precisely, User App) discovers a PDO and connects to it by
sending its WANI token.

4. 2. WiFi captive portal of the PDO initiates user authentication with the User App
provider backend using the token passed by the user.
3. User App provider backend confirms that the user is registered with it by
returning a signed user profile token back to WiFi captive portal.
4. WiFi Captive Portal displays data packs available with their charges. User
selects the desired data sachet and clicks to confirm the terms.
5. WiFi Captive Portal sends ‘request for payment’ through its payment gateway.
6. User completes the payment.
7. PDOA activates all devices of the user.

5. Figure 1a. User’s perspective
Figure 1b. Usage and Backend Flows
Figure 1. Depiction of the user experience and backend procedures in the current WANI
standard.
Thus, the first version of PM-WANI standard, the version which is currently in use,
provides a simple and elegant procedure to address the concerns regarding
authentication. The two main features of this standard are:
1. Coexistence of open access and KYC.
WANI user apps complete KYC for the user and provide an anonymized token
that can be used to access the WANI network, much like a SIM card. The PDOA
can now maintain records for sessions, associated user tokens, and user app
providers, which can be used to relate sessions to users when needed by the
authorities.
2. Separation of User on-boarding and service delivery.
In the traditional service provider model, acquiring the users and delivering the
network is done by the same entity. WANI enables for a decoupling of these two
roles. The user app can be responsible for user acquisition and the PDOAs can
be responsible for network delivery. This unbundling of the value chain opens

6. the possibility of a more flexible and open business ecosystem with many
possible innovations.
To summarise, PM-WANI has already provided a framework which provides
bite-sized, sachetised bandwidth access, a simple compliance procedure for KYC, and
frictionless platform for purchasing WiFi connectivity (see Figure 2). Within a short
while, there are already about 120 PDOAs supporting about 120000 PDOs and around
80 user apps connecting to PM-WANI.
Figure 2. Merits of the current version of the PM-WANI standard.
Challenges
Adoption of the WANI standard has been slow in spite of its inherent merits. The full
potential of the WANI ecosystem hasn't been realised yet. This has been due to a lack
of adequate economic income to motivate small shop owners to become PDOs. This in
turn is partly due to the "low footfall" of users on the network. We would be able to
realise the complete value of the open ecosystem envisioned by WANI when many new
connectivity use cases would be developed and innovative user apps were launched.
This would on-board many more users and provide many di erent types of bundled
payment plans. This growth of users would have made it feasible for the PDOs to
increase their income, which in turn would have incentivised the rise of multiple small
PDOAs.

7. Currently, most of the WANI PDOs can be attributed to a few large PDOAs who have
by-and-large relied on subscription based payment plans similar to that provided by
ISPs. There are also very few technology providers for the complete WANI stack,
leading to a lower number of PDOAs. The bootstrapping process of the WANI platform
has been slow and there is an urgent need to rectify it. We believe that the growth rate
can be accelerated by laying down the next version of the standard which facilitates
easy integration of innovative user apps and business models and transactions
between various WANI entities.
Our Proposal
We can achieve our goal of allowing newer business models and transactions between
various WANI entities, by making minimal changes to the current WANI standard. We
simply need to introduce a few more procedures, some of which can be optional. In
particular, WANI 3.0 includes the support for following procedures
1. Delegated payments. In the current standard user pays the PDOs when they
connect. We propose procedures for payments directly by the User App on the
behalf of users based either on existing contracts (roaming) or on an
on-the-fly pricing.
2. Open ledger. We propose to include an open ledger which will record all the
transactions between di erent WANI entities. Such a ledger will provide for
easy settlement along with serving as a catalyst for newer and more innovative
business models..
3. Network performance audit. The health of any open ecosystem is heavily
dependent on the performance of the participants. We propose to engineer
telemetry services into the WANI ecosystem that allow verification of service
quality and in turn lead to reputation building for high-performers.
Our proposal for the new WANI standard supports multiple types of transactions
between the players, allowing them to easily develop new business use cases and
innovate. Our hope is that this proposal will lead to proliferation of innovative User
App and PDOA business models, leading in turn to growth of the WANI network. The
following new capabilities are getting enabled in the new WANI 3.0 standard:
1. User Apps. Currently User Apps are focused mostly on completing KYC. The
value addition of User Apps could go more than just KYC. In the new standard,

8. we are enabling support for User Apps to bundle payments for connectivity and
other services they provide.
2. PDOAs. It is our view that a PDOA should be able to gain from each-other’s
complementary capabilities and grow together. For example, in the new
standard, PDOAs can easily engage in roaming contracts.
3. Support for low friction network growth. Apart from User App providers and
PDOAs, other ecosystem service providers should be allowed to participate in
WANI. This WANI standard allows for ideas such as open wireless backhaul
growth through incentives easily realisable.
4. Quality of Service support. Finally, a framework has been provided for User
Apps to verify the quality of the network their users will be getting, depending
on their requirements.
Of course, all these need to be done without increasing the compliance burden. Most
of the additional components we propose are optional extensions to existing
procedures and will allow many di erent models for PDOs and PDOAs. We provide a
more detailed description of our proposed standard, WANI 3.0, in the next section.
THE NEXT VERSION OF THE WANI STANDARD
Motivating use cases
The vision for the standard laid in the introduction is broad and can enable many new
use cases. To start o , we wish to illustrate two interesting launch cases which we feel
would supercharge the WANI growth rate in the country.
1. Public WiFi App. Several attempts have been made by local and central
governments in providing public WiFi for citizens. Most of these public WiFi
deployments entail governments sponsoring local WiFi deployment. While
such e orts have been on-going for almost a decade now, it is unclear if they
have extended connectivity significantly. We believe that the new WANI
standard can provide a technology stack to fill this gap by enabling a new
business use case. The new WANI standard envisages developing a User App
that allows anyone to connect to WANI compliant PDOs. Critically, it allows
Governments to sponsor connectivity for qualified citizens. For instance, a local
government can sponsor 100 GB per month of data for all girl students from
BPL families. Such an app requires integration of procedures allowing for

9. delegated payments and methods for measuring the Quality of Service (QoS) to
ensure that the service received is of good quality.
2. Roaming. ISPs often have their users on long-term subscription plans.
Allowing such users to "roam" on the WANI network, is a good way to
bootstrap WANI adoption. Such ISPs, or even PDOAs, can simply develop a
WANI User App which allows their users to access WANI compliant PDOs.
Further, they can enter into roaming contracts that fix prices and allow
payments to be completed by the on-boarding ISP.The ISP can also set up a
VPN service and route its users data to its home network (like mobile roaming)
before connecting them to the internet, in case there are concerns about user
data security and privacy. The network telemetry framework can o er QoS
guarantees also. In contrast to the bulky cellular roaming contracts, we have
enabled a simple open ledger for registering contracts and resolving conflicts to
support easy interaction between a large number of PDOAs, ISPs, and User
Apps.
Summary of the proposed standard
New Entities
We are proposing two new centralised services in WANI 3.0 to enable and record
interactions between di erent entities. These are, a public ledger for recording
transactions and a communication middleware to support interaction between WANI
participants and the ledger. At the beginning, these entities can be hosted by a
centralised agency, but they can even be outsourced to a service provider or to a
decentralised ecosystem going forward. Note that they will not play any role in
controlling the access and KYC, and therefore, all these di erent hosting models have
no security implication.
These new entities will coexist with existing entities such as PDOAs, PDOs, User Apps,
and central registry. In addition, they will support many new services o ered by third
party providers who come-up with innovative products and solutions for the WANI
ecosystem. For instance, a service provider can build a marketplace to book and
maintain roaming contracts; another may build a reputation system which can be
used for microlending; yet another may provide performance auditing services. We
depict the participants of the larger ecosystem in Figure 3.

10. Figure 3. Participants in the WANI 3.0 ecosystem.
Procedures
We now present the main procedures that constitute WANI 3.0. We begin by
presenting procedures which already exist in the current WANI standard, but have
been modified to enable a more open and flexible ecosystem. Then, we briefly describe
the public ledger and the communication middleware. As mentioned earlier, these two
components may not necessarily be mandated and can even be left outside the scope
of the standard with the view that independent consortia will implement these for a
participating group of WANI entities. The description below is brief and only outlines
the functionality of the procedures. A more detailed technical description will be
provided in a separate architecture and standard document.

11. Pricing Exchange and Authentication
The current version of the WANI standard discusses only one form of pricing
exchange between the user and the PDO/PDOA: When the user connects, it can choose
an appropriate sachet to purchase from the captive portal and complete the payment
to get access (see Figure 1b). However, this procedure is too limited to support the
roaming and the public WiFi app use case mentioned earlier. For roaming, we need to
base payments on a pre-existing roaming contract between the User App (which can
even be owned by a PDOA for its users) and the PDOA. For public WiFi app, we even
need to allow the possibility of an on-the-fly contract that can be o ered to any PDOA
which the user comes across. We present such a modified procedure in Figure 4; it
proceeds as follows:
1. User App discovers a PDO and connects to it by sending its WANI token.
2. WiFi captive portal of the PDO/PDOA initiates user authentication with the User
App provider backend using the token passed by the user.
3. The User App backend first checks if there is an existing contract with the PDOA
and if the specific user qualifies for it. Alternatively, it checks if the user
qualifies for an on-the-fly price o er for the PDOA.
4. The User App backend responds to the PDOA with either reference to an
existing contract or a new o er for the specific user, through a signed message.
In case neither applies to the user, it simply responds to the authentication
request.
5. Based on the response from the User App backend, the PDOA either verifies the
existing contract or accepts/rejects the on-the-fly o er.
6. This step is engaged only in case the user qualifies either for an existing
contract or there has been an on-the-fly o er for servicing him. PDOA sends a
signed response accepting/rejecting the o er or acknowledging the existing
contract.
7. The captive portal then either admits the user and displays the accepted pricing
or displays the standard sachets on the o er (in case step 6 does not apply).
8. Payment is completed by an interaction between the User App backend and
PDOA. There are multiple options here based on the agreed payment option. It
can be paid before service or even after service (when there are pre-existing
contracts); can be paid by the user directly or by the User App backend; can even
have clauses for verification of service which can be implemented using an
escrow based payment mechanism.3
3
This flexibility is what allows us to build different business models on the WANI interface. We will
elaborate on these possibilities later in the paper again.

12. Figure 4. WANI 3.0 pricing exchange and authentication procedure.
Note that the additional steps are included in the interaction between the PDOA and
the User App backend, and not in the interaction between the User App and the PDO.
This makes the burden for including these changes very low, requiring changes only
in the cloud backend of PDOA and User App Provider.
Ledger and Communication Middleware
To enable open interactions between WANI entities, we need a transparent and
e cient mechanism for conflict resolution. We propose to have a public ledger
capable of hosting smart contracts for this purpose. We can either have a centralised
ledger hosted by a trusted entity or a decentralised one where the hosting
responsibility is shared by multiple entities thereby ensuring its long term
sustainability. In either case, we need an immutable ledger with mechanisms for Sybil
attack resistance in place.4
We have the following functional requirements from our
ledger:
1. Authentication and Signatures. All WANI entities have a unique identifier on
the ledger, which can be used for signatures as well.
4
We refrain from making the technical specifications for the ledger deployment concrete because the
exact specification can depend on the mode of deployment. For instance, we can either consider a
permissioned setup for adding new contracts for registered entities or consider Sybil resistance based on
fiat payments with proofs of UPI payments.

13. 2. Open. Any WANI entity (PDO, PDOA, User App, etc.) can read or write allowed
transactions on the ledger. This allows easy and publicly verifiable contracts.5
3. Live. All WANI entities can interact with the ledger via a communication
middleware through standardised APIs.
We remark that the role of the ledger should be for public verification, and all the
necessary processing needed for di erent services and contracts should not be on the
ledger. This can be enforced by charging a gas fee for the ledger based on the “size” of
contract data and per transaction. Note that each entity can interact with the ledger
using a communication client, through the communication middleware, at the
backend. Again, this will allow easy extension of the existing standard to include a
ledger.
We can use the ledger for recording many di erent type of contracts such as: roaming
contracts between PDOAs, on-the-fly bookings and service requirements, network
performance audit outputs6
, and contracts expressing payment arrangements.
Roaming
Existing PDOAs often have monthly subscription plans for their users, much like
standard ISPs. Roaming contracts between such PDOAs can allow them to expand
their e ective coverage, and o er their subscribers connectivity in broader
geographical regions. While a roaming contract can be a proprietary agreement
between two PDOAs, we propose to record such contracts on ledger to allow easy
resolution of conflicts and for enabling reputation build-up for high performers. Also,
a third party service provider can develop a platform to enable matchings between
PDOAs or PDOAs and User Apps. We simply need to record the contract on the ledger.
With this view in mind, we only need to standardise the following components:
1. Service level agreement (SLA). A format for the SLA for roaming, so that it can
be recorded on the ledger in a consistent way and assurance services can be
provided by third party vendors.
2. Authentication. The authentication and accounting procedures for users to
access a PDOAs network.
6
Instead of recording the output in plain form, we can maintain privacy by simply recording a
zero-knowledge proof on the ledger which allows any PDOA to provide a cryptographic evidence of its
good performance when queried but does not show the performance output in open.
5
We should allow support for a broad class of smart contracts to admit all the latest developments in
blockchains. For instance, the stack chosen should support zero-knowledge proofs to enable scaling and
privacy.

14. 3. Smart Contract. The settlement procedure on the ledger to initialise a booking
and termination upon conclusion of the SLA is implemented as a smart contract
with appropriate functions.
For authentication, the process described in Figure 4 already allows authentication of
a user and pricing exchange based on pre-existing roaming contracts. We outline the
SLA data format in Table 2 and the booking and termination procedures for smart
contracts in Figure 5 below.
Attribute Category Description
Parties Identities of the various parties involved
in the SLA and the roles they play. For
example, the PDOA will play the role of
an aggregator of services and the User
App the role of payer for services.
Plan O ering/plans provided by a PDOA.
Details such as usage allowed,
geo-location of the PDOs, min/max.
throughput (optional) will be included in
the plan attributes.
Micro-payment rates (Price) Instead of pre- or post-payment for the
entire service, SLA contracts allow
partial confirmation of payments (which
need not be maintained on the ledger)
called micro-payments. These
micropayments will be signed and
exchanged between the PDOA and User
App. Information about the
micro-payment rates and intervals at
which they need to be made will be
specified in the SLA. Both static and
dynamic pricing are supported.
Booking Volume Booking volume requested and agreed
upon by the User App and the PDOA.
Context information Validity of the SLA Period, Status of the
plans (IN ACTIVE, TERMINATED)

15. Figure 5 below illustrates the booking and termination procedures for roaming. The
contract management layer can be implemented by a third party service provider to
enable the booking and management of roaming contracts. This part of the
implementation can be in the form of a platform implemented to enable matchmaking
between PDOAs and User Apps. This third party will set up SLAs as smart contracts on
the ledger, posting a hash of the SLA and using appropriate signatures to initialise the
SLA contract. Then, as the service is delivered, the accounting can be maintained
o -ledger. Finally, once the service in the SLA is delivered, the contract is terminated.
The contract can be used to implement many di erent forms of payments (pre-paid,
incremental, or postpaid) and one can include the proofs of payment such as UPI
transaction ids and values in the contract.
Figure 5. Booking and termination procedures for roaming. In this figure, we assume
that a third party provider will set up a contract management service and interact with
ledger’s communication middleware to facilitate API-based interaction with the
ledger.

16. Payments
Building on the ledger, participants of the WANI ecosystem can engage in innovative
payment agreements. While electronic payments can be already enabled using
mechanisms such as UPI, or even a Centrally Backed Digital Currency (CBDC) in the
future, we propose mechanisms for integrating digital payment and their proofs in
business agreements that can be verified and enacted through smart contracts. Our
proposed payment framework builds on the following components:
1. Ledger. A trusted ledger which keeps a track of all the transactions between
WANI entities. Everyone with an identity (verifiable using a public key) on the
ledger can transact with the ledger.
2. Contract manager. The contract manager is an intermediary that enables
contracts, hosts the middleware for interacting with the ledger, and facilitates
contract condition verification and associated payments. Specifically, its role
will include contract creation, payment reconciliation, contract termination,
and conflict resolution in a transparent7
manner.
3. Data oracle service. For enforcement of the contracts, we need data related to
identity, network performance metrics, etc., which can be provided by di erent
data oracle service providers, centralised or decentralised.
4. Reconciliation service. For transparent and open operation, we require
real-time accounting and reconciliation services which allows parties to
transact and exchange messages promising payments (micro-payments).
Reconciliation service providers serve this purpose of enabling verified (signed)
message exchange and maintaining state o -ledger for such operations8
.
Note that, while these services can be implemented by each provider in a di erent
manner, standardisation of the message format is needed to enable interoperability.
Building on these components, we can enable many di erent payment flows. We
illustrate one such flow in Figure 6 below. Here, once the contract is created between
multiple ‘Parties’, the internet usage and other data mentioned in the contract will be
collected by a third party data oracle service. After the user concludes its service
consumption, a request is generated by taking into account various parameters of the
contract, which is verified by the contract manager. Once the verification is done, a
ledger entry is created for payment. Throughout reconciliation service providers make
sure that any intermediate payment confirmation is completed as per the contract.
8
This is similar to state channel services in blockchains.
7
‘Transparency’ is a property of modern cryptographic protocols which allows trustless verification of the
protocol transcript without reliance on a trusted setup.

17. Furthermore, once the contract is concluded, the contract manager terminates the
contract using signed messages provided by the reconciliation services.
Figure 6. A plausible flow for service delivery and payment.
A PEEK INTO THE FUTURE
In our final section, we present a view of the ecosystem that can be built once the
proposed WANI 3.0 standard is implemented. This will illustrate how all the proposed
components come together to enable an open networking and connected application
business ecosystem, resulting in greater income for the PDOs, higher user adoption,
and ultimately faster growth of the WANI ecosystem. We close the paper by
pointing-out how this standard can be taken to other places in the world, providing an
opportunity for Indian equipment manufacturers to supply WANI compliant APs to
global markets.
A consortium for open WiFi networking and applications
ecosystem
We present a setting where a consortium has been set up to provide a neutral ground
for di erent stakeholders to collaboratively grow the ecosystem comprising WiFi
network services and connected applications. The consortium facilitates enforcement
of a governance structure that ensures good network performance, fast integration of
new applications, and fair sharing of revenues from use cases involving multiple
participants. This governance structure is enforced using the ledger proposed above,
along with specific implementation of payment procedures to incentivise the
participants towards desired behaviour. The modifications suggested to the

18. authentication procedure in Figure 1 o er su cient flexibility to incorporate di erent
types of financial transactions between di erent participants of the ecosystem.
The functions of the consortium can be divided into four components, described in
separate sections below:
Consortium ledger and on-boarding new entities
The consortium hosts a decentralised ledger. Each new entity entering the consortium
is given an identity for the ledger enabled by a private key for signing messages and a
public key recorded on the ledger. The governance structure of the ledger described
the Sybil resistance mechanism for on-boarding new entities. For instance, there can
be a one-time enrolment fee to support consortium activities, with the proof of fee
payment recorded on the ledger. The ledger can be hosted by multiple validators to
ensure that there is no dependence on a single entity for maintaining the ledger and
there is censorship resistance. The consensus and Sybil resistance mechanism
followed can be a variation of the proof of stake mechanism, with stake defined by fiat
committed through UPI-based payments or governance tokens given for specific
purpose served.9
Marketplace platform
The consortium will host a platform for displaying di erent PDOA o ering their
network or for di erent entities to put up a network requirements, along with the
associated SLA. Furthermore, the same platform will allow easy integration of other
services such as network performance audit service and the payment services with an
SLA. The platform will provide web applications for interaction, interact with other
services needed for SLA verification and completion, and read and write on the public
ledger.
A typical user journey on the platform will be as follows:
1. A PDOA posts an SLA listing the locations where it supports this SLA.
2. A User App comes to the platform and books one such service, integrating with
it a third party network performance audit service and a payment service. This
User App can be another PDOA as well, in the case of roaming contracts.
3. When the user completes the booking, a smart contract corresponding to this
booking will be initiated on the ledger. Based on the agreed payment terms, this
9
The exact mechanisms must be laid down clearly in the governance structure document of the
consortium upfron.

19. may even require the User App to pay money to the consortium to emulate an
escrow from which payments will be made to the PDOA later after the
verification of service.
4. When a user connects to this PDOA, the authentication procedure will allow the
PDOA to verify that the user already has an existing contract, and the user will
get access.
5. The third party network performance audit service will independently verify
network service quantity and quality, separately from the measurements done
and reported by the PDOA for accounting.
6. Upon conclusion, the payment service will be utilised to verify that all the
conditions are met and release the payment.
7. The platform will terminate the SLA contract on the ledger, posting the final
state of the contract.
Figure 6 below illustrates the protocols involved in enabling the marketplace
platform.

20. Figure 6. Interaction between WANI procedures and components
for the marketplace platform.
Network performance audit
The consortium will have one, or multiple, network performance audit services
participating in it. In its simplest form, network auditing service can be a trusted
service such as standard speed tests for checking the available bandwidth or simply a
service that collects telemetry data from trusted hardware deployed by PDOAs.

21. Interestingly, many other innovative implementations are possible10
, including a
potential open and trustfree implementation of an equivalent of speedtest.
Any such performance audit service needs a communication middleware which allows
signalling to the devices; also, most implementations will need some integration with
the PDO access points. The consortium may be made responsible for maintaining a
common communication middleware to accommodate multiple performance
measurement service providers and for certification for integration of the
performance measurement clients with PDO access points. We present a plausible
setup in Figure 5 where the performance audit service measures the ISP Backhaul of
the PDO, to ensure that PDO is capable of providing the performance it guarantees,
and the QoS that a User gets to ensure it is charged correctly. Note that the output of
the performance audit service can be reported to the ledger in a privacy preserving
manner using zero-knowledge proofs, which will allow the high performers to
establish their reputation without revealing low performers publicly. This reputation
can also be used during the booking phase with the marketplace platform hosted by
the consortium.
10
See, for instance, a recent research paper “Trust-free Service Measurement and Payments for
Decentralized Cellular Networks,” Proceedings of the 21st ACM workshop on Hot Topics in
Networks (HotNets ’22), proposes the idea of independent measurement of service by the user
device.

22. Figure 5. Interaction Between Performance Audit Service and the Ledger
Payments
Traditional roaming contracts are based on GSM standards and rely on long-term
reputation of the service providers and lengthy legal framework to ensure honest
behaviour. Existing sachetised network service plans (the pre-paid plans for cellular
service) take payment in advance from the user without providing any guarantee of
the service. The guarantees are provided by the TRAI regulations which ensure good
quality service by all carriers using spectral licence. Both these mechanisms are
high-friction mechanisms and are not well-suited for our ecosystem with many small
PDOAs and new users. The presence of a neutral consortium allows us to implement a
trustfree payment ecosystem where neither the service provider nor the user needs to
trust the other and pay in advance before the service is delivered. For instance, the
consortium can hold the payment from the user in an escrow and release it to the

23. service provider only after service verification (using, for example, the performance
audit service). Furthermore, using the ledger a conflict resolution mechanism can be
incorporated in the smart contracts and the consortium can implement default
penalties by asking each entity to stake collateral to engage in high-value contracts.
Many such payment mechanisms can be implemented using a combination of UPI
payments (or CBDC), trusted consortium governance, and a public ledger with ability
to host smart contracts.
Public WiFi App
To illustrate how the presence of a consortium can be used to enable new applications,
we revisit the public WiFi application we discussed earlier. Through this user app, a
local government can enable free (up to a certain amount of monthly data) WiFi access
for qualified citizens. There are two possible approaches to follow. In the first
approach, the government can book bandwidth from PDOAs with established
reputation on the ledger for its public WiFi app users, using the marketplace platform.
Note that the verification of connecting users qualification for free WiFi can be
completed as a part of authentication procedure in Figure 2. However, this approach
only accommodates PDOAs with existing reputation on the ledger and, further,
assumes that the government knows which areas will be accessed by the users. A more
open ecosystem should even allow a user with the public WiFi app to connect to new
PDOAs on-the-fly, without pre-existing contracts. Even such access is possible in our
proposed setup; we present a brief description of this form of access below:
1. The user connects to the hotspot, which further sends the information to the
PDOA backend.
2. The PDOA backend verifies the user credentials used with the ‘User-App
Backend’. The User-App backend verifies the user, and also sends a free usage
o er in the reply.
3. The PDOA backend checks the o er and finds it acceptable. The o er
acceptance message is then sent to the ‘Contract Manager’.
4. The ‘Contract Manager’ creates a contract on the ledger and this contract
includes all SLAs, payments and other information and the user is able to access
internet.
5. For maintaining the SLA, the Performance Audit service collects the
performance data from the hotspot and by sending challenge tra c using the
User-App.
6. The usage data is also accessed for contract execution from the AAA servers
hosted by the PDOA backend.

24. 7. Once the User disconnect or the data-sachet is exhausted, a request is sent to
the ‘Payments service’ for payment disbursement to the entities as per the
terms of the contract.
Figure 6. On-the-fly WiFi access for qualified users of the public WiFi app.
Closing Remarks: Taking WANI standard to the world
The standard proposed here applies not only to the India context, but to many other
developing nations of the world. In developed economies, almost everyone can a ord
to pay for broadband services at home, and the only bottleneck seems to be extending
the last mile of connectivity in rural areas. Many interesting wireless ISP (WISP)
deployments have emerged to enable this. Furthermore, the public WiFi deployments
are meant only for providing coverage in markets and popular destinations. In
contrast, in developing countries most people cannot a ord to buy bulk connectivity
at fixed monthly charges and would prefer sachetised purchase of WiFi connectivity.
Also, public WiFi schemes need to provide free connectivity to people in their daily

25. lives, and not just in popular public spaces, which can be enabled by the public WiFi
app we have proposed. Finally, the open business ecosystem we propose to enable can
facilitate economic incentives of distributed deployment of the network, while the
PDOAs can undertake optimised network management and technical deployment as a
part of centralised management.
This setup has a global appeal and can be adopted in larger markets. This provides a
unique opportunity to Indian equipment manufacturers and communication startups
to target global markets with PM-WANI. They can even adopt variations of the
proposed standard that are compatible with widely used open access standards such
as Open WiFi to cater to larger demand. In other words, through this update, WANI
can become a global WiFi standard for sachetised WiFi access and open connected
applications and network ecosystem.
Written by Saurabh Chakrabarti, Nilesh Gupta, Vishal Sevani, Sharad Sharma, and
Himanshu Tyagi on behalf of iSPIRT Foundation. Nilesh Gupta and Himanshu Tyagi
are faculty members at the Indian Institute of Management Nagpur and Indian
Institute of Science, respectively, and they are also representing their views as
researchers on the topic.
The authors would like to thank Centre For Development Of Telematics (CDoT) for
their detailed discussions and conversations about the workings of PM-WANI. Would
also like to thank Bhuvnesh Sachdeva, Shubhendu Sharma, and Satyam Darmora for
their insightful comments about the WANI ecosystem.