OCPI 2.2.1-d2 Chapter 3

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.

9 Sections
8 Topology Diagrams
3.1 - 3.8

3. Supported Topologies

Overview

OCPI 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

Basic

The simplest topology is a bilateral connection: peer-to-peer between two platforms, and in the most simple version each platform only has 1 role.

Figure 2. Peer-to-peer topology example
┌──────────────┐         ┌──────────────┐
│   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

Scaled

A 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.

Figure 3. Multiple peer-to-peer topology example
┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐
│ 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-role

Some 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.

Figure 4. Peer-to-peer with multiple roles topology example
┌──────────────┐         ┌──────────────┐
│   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 Role

Some 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.

Figure 5. Peer-to-peer with both CPO and eMSP roles topology example
┌──────────────┐         ┌──────────────┐
│   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

Mixed

Some 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.

Figure 6. Peer-to-peer with mixed roles topology example
┌──────────────┐         ┌──────────────┐
│   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

Complex

More 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.

Figure 7. Peer-to-peer with mixed roles topology example
┌──────────────┐                     ┌──────────────┐
│   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

Hub

This topology has all Platforms only connect via a Hub, all communication goes via the Hub.

Figure 8. Platforms connected via a Hub topology example
┌──────────┐                                         ┌──────────┐
│ 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

Hybrid

Not 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.

Figure 9. Platforms connected via a Hub and directly topology example
┌──────────┐                                         ┌──────────┐
│ 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.

OCPI 2.2.1-d2 Supported Topologies. Based on the Open Charge Point Interface (OCPI) 2.2.1-d2 Specification.