OCPI 2.3.0 Chapter 3

Supported Topologies

Based on the OCPI 2.3.0-booking-1.0 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 2.3.0-booking-1.0

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

Scaling

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 │  │  │ OCPI  │  │
  │  │  └────────┼──┼──┼──────┘  │  └───────┘  │
  │  └───────────┼──┘  │         │              │
  │              │     │         │              │
┌─┴──────────┐ ┌─┴─────┴──────┐ ┌┴──────────────┴┐
│  PLATFORM  │ │   PLATFORM   │ │    PLATFORM    │
│            │ │              │ │                │
│  ┌──────┐  │ │  ┌────────┐  │ │  ┌──────────┐  │
│  │ CPO2 │  │ │  │  CPO1  │  │ │  │   CPO3   │  │
│  └──────┘  │ │  └────────┘  │ │  └──────────┘  │
└────────────┘ └──────────────┘ └────────────────┘

In this topology, each eMSP platform connects to one or more CPO platforms, and vice versa. The connections are independent bilateral OCPI links. Not all eMSPs need to connect to all CPOs.

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  │  │              │              │
│  └────────┘  │              │              │
│              │              │              │
└──────────────┘              └──────────────┘

A single OCPI connection between two platforms can serve multiple parties (roles) on each side. For example, one platform may host three eMSP services while the connected platform hosts two CPO services, all over one bilateral OCPI link.

3.4. Peer-to-peer dual roles

Dual

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  │  │
│  └────────┘  │              │  └────────┘  │
│              │              │              │
└──────────────┘              └──────────────┘

When both platforms have dual roles (CPO + eMSP), a single OCPI connection handles data exchange in both directions. Platform A's CPO role communicates with Platform B's eMSP role, and Platform A's eMSP role communicates with Platform B's CPO role, all over the same bilateral link.

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  │  │
│  └────────┘  │              │  └────────┘  │
│              │              │              │
└──────────────┘              └──────────────┘

In this topology, a single platform can host a mix of CPO and eMSP roles for different companies. Both sides of the bilateral connection may contain overlapping role types (e.g., both platforms have eMSP and CPO roles). All communication flows over one OCPI link.

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 of this: requires a lot of connections between platforms to be setup, tested and maintained.

Figure 7. Multiple peer-to-peer with mixed roles topology example
┌──────────────┐                    ┌──────────────┐
│   PLATFORM   │                    │   PLATFORM   │
│              │       OCPI         │              │
│  ┌────────┐  │◄──────────────────►│  ┌────────┐  │
│  │ eMSP1  │  │                    │  │ eMSP3  │  │
│  └────────┘  │        ┌─── OCPI ─►│  └────────┘  │
│              │        │           │              │
│  ┌────────┐  │◄─ OCPI ┼──────┐   │  ┌────────┐  │
│  │ eMSP2  │  │        │      │   │  │  CPO3  │  │
│  └────────┘  │        │      │   │  └────────┘  │
└──────┬───────┘        │      │   └──────┬───────┘
       │                │      │          │
       │ OCPI           │      │          │ OCPI
       │                │      │          │
┌──────┴───────┐        │      │   ┌──────┴───────┐
│   PLATFORM   │        │      │   │   PLATFORM   │
│              │────────┘      └───│              │
│  ┌────────┐  │                   │  ┌────────┐  │
│  │  CPO1  │  │       OCPI        │  │ eMSP4  │  │
│  └────────┘  │◄─────────────────►│  └────────┘  │
│              │                   │              │
│  ┌────────┐  │                   │  ┌────────┐  │
│  │  CPO2  │  │                   │  │  CPO4  │  │
│  └────────┘  │                   │  └────────┘  │
└──────────────┘                   └──────────────┘

In this scenario, four platforms each have multiple roles and maintain direct bilateral OCPI connections to each other. Every platform pair requires its own OCPI connection. As the number of platforms grows, the number of required connections grows quadratically, making this topology difficult to scale.

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  │
       │                                         │
┌──────┴───────┐    OCPI   ┌────────┐    OCPI  ┌─┴────────────┐
│   PLATFORM   │◄─────────►│PLATFORM│◄────────►│   PLATFORM   │
│              │           │        │          │              │
│  ┌────────┐  │           │┌──────┐│          │  ┌────────┐  │
│  │ eMSP3  │  │           ││ Hub  ││          │  │  CPO3  │  │
│  └────────┘  │           │└──────┘│          │  └────────┘  │
│              │           │        │          │              │
│  ┌────────┐  │           └───┬──┬─┘          │  ┌────────┐  │
│  │ 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.
  • Other reasons (e.g., latency, specific business agreements, etc.)
Figure 9. Platforms connected via a Hub and directly topology example
┌──────────────┐                         ┌──────────────┐
│   PLATFORM   │          OCPI           │   PLATFORM   │
│              │◄───────────────────────►│              │
│  ┌────────┐  │                         │  ┌────────┐  │
│  │ eMSP5  │  │                         │  │  CPO5  │  │
│  └────────┘  │                         │  └────────┘  │
└──────┬───────┘                         └───────┬──────┘
       │                                         │
       │  OCPI                             OCPI  │
       │                                         │
┌──────┴───────┐    OCPI   ┌────────┐    OCPI  ┌─┴────────────┐
│   PLATFORM   │◄─────────►│PLATFORM│◄────────►│   PLATFORM   │
│              │           │        │          │              │
│  ┌────────┐  │           │┌──────┐│          │  ┌────────┐  │
│  │ eMSP3  │  │           ││ Hub  ││          │  │  CPO3  │  │
│  └────────┘  │           │└──────┘│          │  └────────┘  │
│              │           │        │          │              │
│  ┌────────┐  │           └───┬──┬─┘          │  ┌────────┐  │
│  │ eMSP4  │  │               │  │            │  │  CPO4  │  │
│  └────────┘  │               │  │            │  └────────┘  │
└──────────────┘               │  │            └──────────────┘
                         OCPI  │  │  OCPI
                               │  │
┌──────────────┐               │  │            ┌──────────────┐
│   PLATFORM   │◄──────────────┘  └───────────►│   PLATFORM   │
│              │          OCPI                 │              │
│  ┌────────┐  │◄─────────────────────────────►│  ┌────────┐  │
│  │ eMSP1  │  │                               │  │  CPO1  │  │
│  └────────┘  │                               │  └────────┘  │
│              │                               │              │
│  ┌────────┐  │                               │  ┌────────┐  │
│  │ eMSP2  │  │                               │  │  CPO2  │  │
│  └────────┘  │                               │  └────────┘  │
└──────────────┘                               └──────────────┘

Hub Connections

All platforms connect to the central Hub for standard OCPI communication and general message routing between parties.

Direct Connections

Some platforms also maintain direct peer-to-peer OCPI connections for specific use cases, bypassing the Hub when needed.

This is a hybrid topology. Most platforms connect through the Hub for standard OCPI communication. However, some platforms also maintain direct peer-to-peer OCPI connections for specific use cases. In this example:

  • The eMSP5 platform connects directly to the CPO5 platform (bypassing the Hub).
  • The eMSP1/eMSP2 platform connects directly to the CPO1/CPO2 platform.
  • All platforms also connect to the Hub for general routing.

A platform can use both the Hub and direct connections simultaneously. The direct connections might carry traffic for custom modules or newer functionality that the Hub doesn't support yet.

OCPI 2.3.0 Supported Topologies. Based on the Open Charge Point Interface (OCPI) 2.3.0-booking-1.0 Specification.