OCPP, OCPI, and UBC: India's Three-Layer EV Charging Stack Explained
The EV charging conversation in India has acquired a new vocabulary. OCPP. OCPI. UBC. Beckn. To the casual observer these sound like competing standards vying for dominance. They are not. Each operates at a different layer of the charging stack, and India's interoperable future depends on all of them working in concert.
Understanding where each protocol sits — and what it does not do — is essential for charge point operators, fleet managers, app developers, and policymakers allocating capital under schemes like PM E-DRIVE.
The Device Communication Layer: OCPP
The Open Charge Point Protocol (OCPP), maintained by the Open Charge Alliance, is the foundational language between a physical charger and its backend management system. It handles start and stop commands, authentication at the charger, meter value reporting, fault diagnostics, firmware updates, load balancing, and remote configuration.
Without OCPP, a charger is a vendor-locked device with no fleet-scale manageability. OCPP is what allows an operator to run hundreds of geographically dispersed chargers from a single Charging Management System (CSMS).
Critically, OCPP stops at the charger-to-backend boundary. It does not define how a consumer discovers a charger, how two operators settle a roaming session, or how payment flows. That work belongs to higher layers.
The Roaming Layer: OCPI
The Open Charge Point Interface (OCPI), maintained by the EVRoaming Foundation, sits one layer up. It governs communication between Charge Point Operators (CPOs) and eMobility Service Providers (eMSPs), enabling roaming, cross-network authentication, tariff exchange, session token handoff, and billing settlement.
OCPI is the protocol that lets a driver registered with one network charge at a station owned by another. In mature European markets with a handful of large operators, bilateral OCPI integrations scale reasonably well.
India's challenge is structural. With dozens of CPOs expanding simultaneously across cities and highways, pairwise OCPI agreements become operationally expensive. Every new operator means new contracts, new API mappings, new settlement workflows. The combinatorial complexity grows faster than the network itself.
This is not a failure of OCPI. It is a recognition that roaming alone does not solve marketplace interoperability at India's scale.
The Consumer Transaction Layer: UBC
The Unified Bharat eCharge (UBC) layer addresses what OCPP and OCPI do not: unified discovery, booking, consumer authentication, payment, and open access across all participating apps. Built on the Beckn Protocol's decentralized open-network architecture, UBC functions as digital public infrastructure for EV charging, conceptually parallel to what UPI did for payments.
Under UBC, a consumer can discover any public charger, see real-time availability and tariffs, reserve a slot, authenticate, initiate charging, and pay, all through whichever participating app they choose. The charger does not need to belong to the same operator as the app.
The original architecture for this national interoperability layer was developed by Pulse Energy, working alongside the Ministry of Heavy Industries and the Beckn Foundation, before being opened into a broader public-standard framework. The intent was never proprietary control. It was to give India a vendor-neutral discovery and transaction layer that complements, rather than replaces, the global device and roaming protocols beneath it.
How a Charging Session Flows Across All Three
Consider a driver using a UBC-participating app to charge at a station operated by a different network.
First, the app queries the UBC registry and surfaces nearby chargers with live availability and pricing. This is the discovery layer. The driver reserves a slot and authenticates; UBC handles the transaction handshake.
If the session crosses operator boundaries, OCPI exchanges session tokens and billing data between the driver's service provider and the station's CPO. This is the roaming layer.
Once initiated, OCPP manages the physical charging session: energy delivery, meter readings, fault monitoring, and remote stop commands. This is the device layer.
At completion, payment settles through UBC's unified interface, with UPI integration, transparent pricing, and no app-switching for the consumer.
Each protocol does what it is best at. None of them tries to do the others' jobs.
Why the Layering Matters for India
India's EV market is defined by population scale, price sensitivity, dozens of concurrent CPOs, mixed urban-rural deployment, and a strong existing digital public infrastructure base. In that environment, an open-registry, marketplace-style interoperability model scales more cleanly than a web of bilateral roaming contracts.
Operators building under PM E-DRIVE and successor schemes should not view OCPP, OCPI, and UBC as an either-or choice. A well-architected charging network implements OCPP at the device, uses OCPI where bilateral roaming makes commercial sense, and connects to UBC for nationwide consumer discovery and payment. The three layers are designed to coexist.
The practical implication for operators is straightforward. Invest in OCPP-compliant hardware. Establish OCPI relationships where your roaming volume justifies them. And register on the UBC network to be discoverable to every participating app in the country.
India's charging future is not a protocol war. It is a stack. Understanding the stack is the first step toward building on it.
← Back to all posts