Supported Topologies
Based on the OCPI 2.2.1-d2 Specification. This chapter describes the different network topologies supported by OCPI, from simple peer-to-peer connections to Hub-based architectures with message routing.
3. Supported Topologies
OverviewOCPI started as a bilateral protocol, for peer-to-peer communication. Soon parties started to use OCPI via Hubs, but OCPI 2.1.1 and earlier were not designed for that. OCPI 2.2 introduced a solution for this: message routing.
OCPI 2.2 introduced Platforms that connect via OCPI instead of CPO and eMSP, more on this in: EV Charging Market Roles. The following sections describe the different topologies that OCPI supports, from simple peer-to-peer to complex Hub-based architectures.
Peer-to-peer
Direct bilateral connections between two platforms. The simplest form of OCPI communication.
Hub-based
All platforms connect via a central Hub. Communication is routed through the Hub platform.
Hybrid
Platforms connect via a Hub but also maintain direct peer-to-peer connections for specific use cases.
3.1. Peer-to-peer
BasicThe simplest topology is a bilateral connection: peer-to-peer between two platforms, and in the most simple version each platform only has 1 role.
┌──────────────┐ ┌──────────────┐
│ PLATFORM │ │ PLATFORM │
│ │ OCPI │ │
│ ┌────────┐ │◄───────►│ ┌────────┐ │
│ │ eMSP │ │ │ │ CPO │ │
│ └────────┘ │ │ └────────┘ │
└──────────────┘ └──────────────┘In this basic topology, one platform hosts an eMSP role and the other hosts a CPO role. They communicate directly via a single OCPI connection. This is the foundation upon which all other topologies are built.
3.2. Multiple peer-to-peer connections
ScaledA more real-world topology where multiple parties connect their platforms and each platform only has 1 role. Not every party necessarily connects with all the other parties with the other role.
┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐
│ PLATFORM │ │ PLATFORM │ │ PLATFORM │ │ PLATFORM │
│ │ │ │ │ │ │ │
│ ┌──────┐ │ │ ┌──────┐ │ │ ┌──────┐ │ │ ┌──────┐ │
│ │eMSP1│ │ │ │eMSP3│ │ │ │eMSP2│ │ │ │eMSP4│ │
│ └──────┘ │ │ └──────┘ │ │ └──────┘ │ │ └──────┘ │
└─────┬────┘ └────┬─────┘ └────┬─────┘ └────┬─────┘
│ │ │ │
│ OCPI │ │ OCPI │
└───────┬───┘ └──────┬──────┘
│ │
┌───────┴──────┐ ┌────────────┬┴───────────┐
│ │ │ │ │
┌─────┴────┐ ┌───────┴──┴─┐ ┌───────┴────┐
│ PLATFORM │ │ PLATFORM │ │ PLATFORM │
│ │ │ │ │ │
│ ┌──────┐ │ │ ┌──────┐ │ │ ┌──────┐ │
│ │ CPO2 │ │ │ │ CPO1 │ │ │ │ CPO3 │ │
│ └──────┘ │ │ └──────┘ │ │ └──────┘ │
└──────────┘ └────────────┘ └────────────┘In this topology, multiple eMSP platforms connect to multiple CPO platforms via individual OCPI connections. Each platform still has a single role, but the number of connections grows as more parties join the network. Not all eMSPs need to connect to all CPOs — connections are established based on business relationships.
3.3. Peer-to-peer multiple the same roles
Multi-roleSome parties provide for example CPO or eMSP services for other companies. So the platform hosts multiple parties with the same role. This topology is a bilateral connection: peer-to-peer between two platforms, and both platforms can have multiple roles.
┌──────────────┐ ┌──────────────┐
│ PLATFORM │ │ PLATFORM │
│ │ OCPI │ │
│ ┌────────┐ │◄───────►│ ┌────────┐ │
│ │ eMSP1 │ │ │ │ CPO1 │ │
│ └────────┘ │ │ └────────┘ │
│ ┌────────┐ │ │ ┌────────┐ │
│ │ eMSP2 │ │ │ │ CPO2 │ │
│ └────────┘ │ │ └────────┘ │
│ ┌────────┐ │ │ │
│ │ eMSP3 │ │ │ │
│ └────────┘ │ │ │
└──────────────┘ └──────────────┘Left Platform
Hosts 3 eMSP roles (eMSP1, eMSP2, eMSP3) — a service provider offering eMSP services to multiple companies.
Right Platform
Hosts 2 CPO roles (CPO1, CPO2) — a service provider operating charge point networks for multiple companies.
This topology demonstrates how a single OCPI connection between two platforms can serve multiple parties. The platform itself is the entity that connects via OCPI, while the roles (CPO, eMSP) represent the individual companies using the platform's services.
3.4. Peer-to-peer dual roles
Dual RoleSome parties have dual roles, most of the companies are CPO and eMSP. This topology is a bilateral connection: peer-to-peer between two platforms, and both platforms have the CPO and the eMSP roles.
┌──────────────┐ ┌──────────────┐
│ PLATFORM │ │ PLATFORM │
│ │ OCPI │ │
│ ┌────────┐ │◄───────►│ ┌────────┐ │
│ │ CPO1 │ │ │ │ CPO2 │ │
│ └────────┘ │ │ └────────┘ │
│ ┌────────┐ │ │ ┌────────┐ │
│ │ eMSP1 │ │ │ │ eMSP2 │ │
│ └────────┘ │ │ └────────┘ │
└──────────────┘ └──────────────┘This is one of the most common topologies in the real world. Most EV charging companies operate both as a CPO (managing charge points) and as an eMSP (providing charging services to EV drivers). Both platforms have both roles, and a single OCPI connection handles all communication between them.
3.5. Peer-to-peer mixed roles
MixedSome parties have dual roles, or provide them to other parties and then connect to other companies that do the same. This topology is a bilateral connection: peer-to-peer between two platforms, and both platforms have multiple different and also the same roles.
┌──────────────┐ ┌──────────────┐
│ PLATFORM │ │ PLATFORM │
│ │ OCPI │ │
│ ┌────────┐ │◄───────►│ ┌────────┐ │
│ │ eMSP1 │ │ │ │ eMSP4 │ │
│ └────────┘ │ │ └────────┘ │
│ ┌────────┐ │ │ ┌────────┐ │
│ │ CPO1 │ │ │ │ CPO6 │ │
│ └────────┘ │ │ └────────┘ │
│ ┌────────┐ │ │ ┌────────┐ │
│ │ eMSP2 │ │ │ │ CPO5 │ │
│ └────────┘ │ │ └────────┘ │
│ ┌────────┐ │ │ ┌────────┐ │
│ │ CPO2 │ │ │ │ CPO7 │ │
│ └────────┘ │ │ └────────┘ │
└──────────────┘ └──────────────┘Left Platform
Hosts a mix of 2 eMSP roles (eMSP1, eMSP2) and 2 CPO roles (CPO1, CPO2) — providing services for multiple companies with different roles.
Right Platform
Hosts 1 eMSP role (eMSP4) and 3 CPO roles (CPO5, CPO6, CPO7) — a platform that provides both eMSP and CPO services, with more CPO clients.
This topology combines multi-role and dual-role patterns. Both platforms host multiple parties with different roles, all communicating through a single OCPI connection. The message routing capabilities introduced in OCPI 2.2 enable the correct routing of messages to the appropriate role on each platform.
3.6. Multiple peer-to-peer
ComplexMore a real-world topology when OCPI is used between market parties without a hub, all parties are platforms with multiple roles.
Disadvantage: Requires a lot of connections between platforms to be setup, tested and maintained. As the number of platforms grows, the number of required connections increases significantly.
┌──────────────┐ ┌──────────────┐
│ PLATFORM │ OCPI │ PLATFORM │
│ │◄───────────────────►│ │
│ ┌────────┐ │ │ ┌────────┐ │
│ │ eMSP1 │ │ │ │ eMSP3 │ │
│ └────────┘ │ │ └────────┘ │
│ ┌────────┐ │ OCPI │ ┌────────┐ │
│ │ eMSP2 │ │◄──────┐ ┌──────►│ │ CPO3 │ │
│ └────────┘ │ │ │ │ └────────┘ │
└──────┬───────┘ │ │ └───────┬──────┘
│ OCPI │ │ OCPI │
│ │ │ │
│ OCPI │ │ OCPI │
│ │ │ │
┌──────┴───────┐ │ │ ┌───────┴──────┐
│ PLATFORM │ │ │ │ PLATFORM │
│ │◄──────┘ └───────►│ │
│ ┌────────┐ │ │ ┌────────┐ │
│ │ CPO1 │ │ │ │ eMSP4 │ │
│ └────────┘ │ OCPI │ └────────┘ │
│ ┌────────┐ │◄───────────────────►│ ┌────────┐ │
│ │ CPO2 │ │ │ │ CPO4 │ │
│ └────────┘ │ │ └────────┘ │
└──────────────┘ └──────────────┘Top-left Platform
eMSP1, eMSP2
Top-right Platform
eMSP3, CPO3
Bottom-left Platform
CPO1, CPO2
Bottom-right Platform
eMSP4, CPO4
With four platforms, each having multiple roles, the number of OCPI connections becomes significant. Every platform needs a direct connection to each other platform it communicates with. This is where Hub-based topologies (described in sections 3.7 and 3.8) provide a scalable alternative.
3.7. Platforms via Hub
HubThis topology has all Platforms only connect via a Hub, all communication goes via the Hub.
┌──────────┐ ┌──────────┐
│ PLATFORM │ │ PLATFORM │
│ ┌──────┐ │ │ ┌──────┐ │
│ │eMSP5│ │ │ │ CPO5 │ │
│ └──────┘ │ │ └──────┘ │
└─────┬────┘ └────┬─────┘
│ │
│ OCPI OCPI │
│ │
┌─────┴────┐ ┌────────────────┐ ┌────┴─────┐
│ PLATFORM │ │ PLATFORM │ │ PLATFORM │
│ ┌──────┐ │ OCPI │ │ OCPI │ ┌──────┐ │
│ │eMSP3│ │◄───────►│ ┌────────┐ │◄────────►│ │ CPO3 │ │
│ └──────┘ │ │ │ Hub │ │ │ └──────┘ │
│ ┌──────┐ │ │ └────────┘ │ │ ┌──────┐ │
│ │eMSP4│ │ │ │ │ │ CPO4 │ │
│ └──────┘ │ └───┬────────┬───┘ │ └──────┘ │
└──────────┘ │ │ └──────────┘
OCPI │ │ OCPI
│ │
┌─────┴────┐ ┌─┴────────┐
│ PLATFORM │ │ PLATFORM │
│ ┌──────┐ │ │ ┌──────┐ │
│ │eMSP1│ │ │ │ CPO1 │ │
│ └──────┘ │ │ └──────┘ │
│ ┌──────┐ │ │ ┌──────┐ │
│ │eMSP2│ │ │ │ CPO2 │ │
│ └──────┘ │ │ └──────┘ │
└──────────┘ └──────────┘Central Hub
The Hub platform acts as the central routing node. All other platforms connect to it via OCPI, and it routes messages between them.
Connected Platforms
Six platforms connect to the Hub: three hosting eMSP roles (eMSP1-5) and three hosting CPO roles (CPO1-5). Each only needs one OCPI connection — to the Hub.
The Hub topology drastically reduces the number of connections required. Instead of each platform needing a direct connection to every other platform, each platform only needs a single connection to the Hub. The Hub then handles message routing between all connected platforms, making it much easier to scale the network.
3.8. Platforms via Hub and direct
HybridNot all Platforms will only communicate via a Hub. There might be different reasons for Platforms to still have peer-to-peer connections. The Hub might not yet support new functionality. The Platforms use a custom module for some new project, which is not supported by the Hub. etc.
┌──────────┐ ┌──────────┐
│ PLATFORM │ OCPI (direct) │ PLATFORM │
│ ┌──────┐ │◄───────────────────────────────────────►│ ┌──────┐ │
│ │eMSP5│ │ │ │ CPO5 │ │
│ └──────┘ │ │ └──────┘ │
└─────┬────┘ └────┬─────┘
│ │
│ OCPI OCPI │
│ │
┌─────┴────┐ ┌────────────────┐ ┌────┴─────┐
│ PLATFORM │ │ PLATFORM │ │ PLATFORM │
│ ┌──────┐ │ OCPI │ │ OCPI │ ┌──────┐ │
│ │eMSP3│ │◄───────►│ ┌────────┐ │◄────────►│ │ CPO3 │ │
│ └──────┘ │ │ │ Hub │ │ │ └──────┘ │
│ ┌──────┐ │ │ └────────┘ │ │ ┌──────┐ │
│ │eMSP4│ │ │ │ │ │ CPO4 │ │
│ └──────┘ │ └───┬────────┬───┘ │ └──────┘ │
└──────────┘ │ │ └──────────┘
OCPI │ │ OCPI
│ │
┌─────┴────┐ ┌─┴────────┐
│ PLATFORM │ │ PLATFORM │
│ ┌──────┐ │ │ ┌──────┐ │
│ │eMSP1│ │ │ │ CPO1 │ │
│ └──────┘ │ │ └──────┘ │
│ ┌──────┐ │ │ ┌──────┐ │
│ │eMSP2│ │ │ │ CPO2 │ │
│ └──────┘ │ │ └──────┘ │
└─────┬────┘ └──────────┘
│ ▲
│ OCPI │
│(direct) │
└──────────┘Reasons for direct connections
New Functionality
The Hub might not yet support new functionality that the platforms need to exchange.
Custom Modules
The Platforms use a custom module for some new project, which is not supported by the Hub.
Lower Latency
Direct connections can benefit from lower latency for specific use cases by bypassing the Hub.
In this topology, some platforms (e.g., the platform hosting eMSP1/eMSP2 and the platform hosting CPO1/CPO2) maintain both a Hub connection and a direct peer-to-peer OCPI connection. Similarly, the platform hosting eMSP5 and the platform hosting CPO5 have a direct OCPI connection alongside their Hub connections. This allows them to exchange data that the Hub may not support, use custom modules, or benefit from lower latency for specific use cases.