Unified Bharat e-Charge (UBC) Explained: India’s EV Charging Interoperability Framework 

Electric mobility in India is set for explosive growth, but the charging infrastructure remains fragmented. Multiple networks operate in silos, each with its own app, credentials, and payment schemes. This fragmentation creates discovery friction and payment hassles for EV users: drivers often juggle multiple apps to find nearby chargers, reserve slots, or start sessions, and they face different billing processes depending on the network.  
 
The Unified Bharat e-Charge (UBC) initiative addresses this by defining an open, national interoperability protocol for EV charging. In essence, UBC ensures that every charger, every operator, and every app speak the same language.  
 
In this blog, we explore: 

1. What Unified Bharat e-Charge (UBC) is and how it solves India’s fragmented EV charging ecosystem 

2. How UBC’s Beckn-based architecture works in practice   

3. Why UBC is strategically critical for India’s EV scale-up 

The UBC Architecture: How it Works 

UBC’s technical foundation is the open Beckn Protocol, which enables interoperability across diverse platforms. The key actors include: 

• Beckn Application Providers (BAPs): These are user-facing apps or platforms such as CPO apps, OEM dashboards, map/navigation apps, or wallet apps. Essentially, any app the driver uses to find and initiate charging is a BAP. 

• Beckn Platform Providers (BPPs): These are the seller-side platforms, primarily the CPOs or e-Mobility Service Providers (eMSPs) that manage charging stations. A BPP “sells” charging as a service. It receives requests from BAPs and manages the fulfillment (starting, metering, and ending charging sessions). 

• Beckn Gateway (BG) / Registry: A lightweight registry that keeps track of all registered BAPs and BPPs in the network. When a user app wants to find a charger, it sends a search query to the BG. The BG’s job is simply to broadcast that query to all relevant BPPs (or to those that fit search criteria, like location or connector type). The gateway is not in the path for the actual charging session; it only facilitates discovery. 

• Catalog & Discovery Services (CDS): UBC’s technical spec mentions a Catalog Discovery Service, which essentially aggregates or curates standardized metadata about chargers (location, connector types, rates, etc.), ensuring consistent search results. 

• National Bulk Switching Layer (NBSL): In the UBC design, an NBSL is envisioned as a centralized coordination point for onboarding, certification, and compliance, ensuring trust and scalability. Think of it as the national switchboard that ties the decentralized network together. 

This architecture allows any BAP to discover any BPP. For example, if Google Maps (as a BAP) searches for chargers in Delhi, the Beckn Gateway broadcasts the request to all registered CPOs (BPPs). Each CPO’s system responds directly to Google Maps with its relevant station data. No intermediate hub keeps the conversation going; after the gateway broadcast, the session is purely peer-to-peer between the user’s app and the CPO’s backend. This ensures scalability and avoids a single point of failure. 

The Role of the Beckn Protocol 

Beckn provides the “common language” for interoperability. It defines message flows such as discover, select, init, confirm, status, start, and stop, covering a complete life cycle of a charging session.  

For EV charging, the key Beckn flows are: 

• Discovery: The user’s app (BAP) searches for chargers with specific attributes. E.g., “Find me chargers at location X with these attributes”. The gateway distributes this request, and each BPP (CPO) replies if it has matching stations. 
   

• Select & Confirm: Once the user picks a specific charger or slot, the BAP sends a select/init message to the chosen BPP. The BPP reserves the slot or unit of energy and confirms the BAP. 
   

• Fulfillment (/start and /stop): When the user plugs in or otherwise initiates charging, the BAP sends a /start message to the CPO, which triggers the charger. When done, a /stop message ends the session. The CPO meters the energy dispensed. 
   

• Billing & Payment (/on_status): After the session, meter readings and costs are shared, and payments are made directly to the operator, typically via UPI. 

By using Beckn, UBC effectively digitizes the charging session. Every transaction is an “order” on the network. This ensures that all parties (app, operator, user) have the same shared understanding of what’s happening, using a sector-agnostic data model.  

Beckn’s design means new services or add-ons (like battery swapping, idle battery trading, renewable energy credits, etc.) can be represented by extending the data model without breaking core compatibility. 

One big advantage of Beckn over typical payment protocols is it encodes business logic, not just money movement, enabling time-of-use tariffs, discounts, and refunds. It also separates authorization from settlement, ensuring flexibility and transparency. 

Compatibility with OCPI and Global Standards 

UBC and Beckn are designed to complement existing EV protocols. In particular, the popular European roaming standard OCPI (Open Charge Point Interface) is widely used for bilateral CPO partnerships. But OCPI assumes fixed relationships: two networks must sign agreements for roaming. This doesn’t scale well in India’s fragmented market. In contrast, UBC’s “universal” approach removes the need for bilateral contracts. 

That said, UBC does not preclude using OCPI under the hood. For example, a CPO’s internal system might use OCPP (Open Charge Point Protocol) to talk to its chargers and OCPI for settlement. UBC sits above these layers: it can translate a user’s request into whatever the CPO needs. Indeed, industry stakeholders envision UBC (Beckn) APIs coexisting with standards like OCPP and OCPI. The UBC Technical Spec even mentions configuring “Beckn ONIX for EV” alongside Type 6 connector standards. In practice, this means that if a CPO already shares data via OCPI, it could map that data into the Beckn messages, making it available on the open UBC network. 

In summary, UBC leverages Beckn as its open transaction protocol while staying compatible with global EV standards. It brings the advantages of Beckn’s network model (decentralized, discoverable, multi-vendor) without ripping out existing protocols. As one comparison notes, UEI/UBC has the “potential to simplify communication between CPOs, DISCOMs, and end consumers” by acting like a “universal translator”, whereas OCPI requires bilateral bookkeeping and can lock out new entrants. 

Real-World Usage Scenarios 

Walk-In Charging (Instant Sessions) 

Imagine a commuter in Bengaluru needs a quick charge. She opens her preferred UBC-enabled app (say, Google Maps or an OEM app) and searches for nearby chargers. The app sends a Beckn “search” query. The UBC gateway broadcasts it to all charging operators, and each matching CPO responds with its station details and real-time availability. Within seconds, she sees a consolidated list: locations, connector types, current rates, and uptime. She picks a convenient charger. 

Next, she taps “Start Charging” on the app. Under the hood, the app issues a Beckn /start request to that CPO’s backend. The charging process begins (the driver plugs in, and the charger verifies the request). Once finished, she taps “Stop”. The app sends a Beckn /stop, the charger ends the session, and sends meter readings. The CPO then sends a status report via Beckn, including kWh consumed and total cost. The driver sees the final bill and pays, for example, by UPI to the CPO’s account, all through the same app. 

Crucially, no separate app-switching or RFID card is needed. The entire session, from discovery to payment, is handled by one interface. This walk-in use case is fully supported by UBC. As DST’s recent guidelines illustrate, the flow is straightforward: the user queries, receives responses, selects a charging point, and the UBC network “facilitates direct communication” for start/stop commands. After charging, the operator’s UPI ID is provided, and the user pays directly, avoiding extra fees. 

In practice, the experience is much like using an all-in-one travel app to book parking and pay for it, but for EV charging. Users don’t have to register with each network: their account with the BAP suffices. Because UBC knows your profile, it can even show user-specific tariff plans (e.g., fleet discounts) if applicable. Overall, walk-in charging becomes seamless as tapping a button. 

Reservation and Slot Booking 

For many drivers, especially in dense urban areas, being able to reserve a charger or a time slot in advance is important. UBC supports this too. A BAP can query not only for “available now” but also for future availability. For example, a user could choose to charge in 30 minutes or next hour. The app would send a Beckn /select and /confirm message specifying the desired time and energy amount. The CPO’s system would then lock that slot and confirm back. 

This reservation flow is especially useful for highway or fleet charging. The Government’s PM E-Drive scheme explicitly envisions real-time slot booking in its unified EV app. UBC’s protocol enables exactly that: on the same network, a user app can hold space at a charger. If the user doesn’t show up, the CPO can release the reservation automatically. If the user arrives early, they may check availability and get charged instantly. 

Whether walk-in or reserved, the charging session uses the same basic Beckn messages. The difference is only in timing. The powerful feature is that both modes run on one network and app. The unified app the government is building (as per PIB) will allow users to see “slot booking, charger availability, and progress” in real time. UBC makes that possible by standardizing how availability is communicated and reserved across operators. 

Strategic Relevance for India’s EV Growth 

India’s EV push has strong policy backing. Initiatives like the National Electric Mobility Mission Plan (NEMMP) and now the PM E-Drive are all aimed at accelerating adoption. UBC aligns with India’s EV and digital economy goals by solving a systemic bottleneck. It ensures that investments in charging infrastructure are fully leveraged, removes barriers to adoption, and supports renewable energy integration.  

Interoperability has long been cited as a barrier in government reports; for instance, a recent DST whitepaper on EV charging explicitly endorses open networks like UEI/UBC to streamline charging across diverse operators. 

Just as UPI unified payments, UBC aims to unify charging. The analogy is apt, “like UPI, which facilitates seamless financial transactions, UEI [UBC] aims to streamline EV charging across diverse CPOs and EV users”. This national-scale approach fits India’s preference for unified, government-endorsed platforms. 

Finally, the protocol is open-source and India-led (Beckn originated in India). It avoids lock-in to foreign protocols or vendors, strengthening self-reliance under the “Make in India” initiative. As India plans to manufacture its own EV chargers and batteries, having a sovereign open standard for their software interoperability is strategically valuable. 

Conclusion

The Unified Bharat e-Charge (UBC) initiative is India’s EV journey leap. By applying the open, Beckn-based protocol to EV charging, UBC dissolves silos between chargers, operators, and apps. Users gain one-stop discovery and payment; CPOs gain market reach and efficiency, and governments accelerate clean mobility goals. Backed by data and demos, UBC is poised to power thousands of charging points (and their future innovations) without lock-in or complexity. 

In a sense, UBC is India’s own “UPI for EV charging”. A nation-scale platform that anyone can join. As India rolls out its EV super-app and expands charging networks under PM E-Drive, UBC provides the digital backbone for a truly interoperable, user-friendly future. Looking ahead – vehicle-to-grid integration, smart grids, dynamic tariffs and more – this unified protocol will be the enabler. The fragmentation of today’s EV charging world may be a thing of the past with UBC.