OCPI gives you a choice that other charging protocols don’t really make explicit: how do you connect to your roaming partners? You can either run direct connections to each one (peer-to-peer, P2P) or push everything through a hub that fans your messages out to many partners on your behalf. If the CPO and eMSP roles here are new to you, start with what a CPO and eMSP actually do.
OCPI 2.1.1 technically supported both but the protocol made hubs feel like the natural choice. OCPI 2.2 made P2P a first-class architecture. Today neither is clearly “better” — they solve different problems, and most mature operators use a mix.
This article is a practitioner’s view on when to pick which.
The two architectures, fast
Peer-to-peer (P2P)
You and your partner connect directly. Your servers talk to their servers. The OCPI Credentials handshake (coming soon) establishes trust between you specifically, and from then on every Locations push, Session update, CDR transmission, and Token query is a direct call.
[ You ] <-- direct connections --> [ Partner A ]
<-- direct connections --> [ Partner B ]
<-- direct connections --> [ Partner C ]One pipe per partner. Bilateral contracts. Bilateral debugging.
Hub
You connect to a hub. The hub connects to many other parties. Your message to “all partners” goes once to the hub; the hub fans it out. A query for someone else’s data goes to the hub; the hub asks the right party and returns the answer.
flowchart LR
You[You] --> Hub[Hub]
Hub --> A[Partner A]
Hub --> B[Partner B]
Hub --> C[Partner C]
Hub --> N[...50 more]
style Hub fill:#e6f2ff,stroke:#3399ffOne pipe to one party. The hub becomes your single point of integration, monitoring, and contract.
What each model is actually good at
P2P is good for:
- Strategic partnerships you want to control end-to-end. Your top eMSP partner that drives 30% of your roaming revenue deserves a direct connection. You decide together how you handle outages, what your support SLA is, how you do beta testing.
- Avoiding hub fees on high-volume connections. A hub takes a cut of every transaction. For a partnership that does millions of sessions a year, even a 1% cut adds up to real money you could keep.
- Cases where the hub doesn’t reach your partner. Not every party uses every hub. If your partner is on a different hub than yours, you either join their hub, they join yours, or you go P2P.
- Sensitive data flows. If your business or legal team is uncomfortable with a third party touching your session data, P2P is the only answer.
- Innovation lead. New OCPI features (or pre-spec experimental features) often roll out P2P first because both sides can iterate without waiting for the hub to support it.
Hubs are good for:
- The long tail. You probably want to roam with 30-100 eMSPs. The 25th most important one doesn’t justify a bilateral contract and a direct integration. The hub gives you that reach with one integration.
- Onboarding speed. New partner via hub: a contract amendment with the hub, sometimes just a config change, you’re live in days. New partner P2P: contract negotiation, Credentials exchange, testing, partner-by-partner debugging — weeks per partner.
- Operational simplicity. One partner to call when something is wrong. One dashboard. One set of credentials. One contract. The hub handles the inventory of partners.
- Data normalization. Hubs absorb some of the partner-by-partner variation. Some partners interpret OCPI fields slightly differently; the hub often patches over the more egregious cases. (This is also a downside if you want raw fidelity.)
- Discovery. Hubs typically publish a list of available parties (via the HubClientInfo module in OCPI 2.2+) so you can see who’s reachable without negotiating individually.
The real question: pick one, or use both?
For anyone bigger than a single-region pilot, the answer is almost always “both.”
A typical mature configuration:
- 2-5 direct P2P connections with your highest-value or most strategic partners.
- One hub absorbing 20-80 long-tail partners.
- Maybe a second hub if your business spans regions and one hub doesn’t cover both well.
That mix gives you control where it matters, reach where you need it, and avoids the all-eggs-in-one-basket risk of being fully dependent on a single hub.
The math: when does P2P pay for itself?
This is the conversation that should happen in your finance team, not just your engineering team.
A hub charges either per session (say €0.05) or as a percentage of session revenue (say 2%). If you’re doing 100,000 roamed sessions per year through a single partner via a hub, you’re paying €5,000+ per year for that one partner’s traffic to flow through the hub.
Building a direct integration to that partner costs:
- One-time:
2-6 engineering-weeks (€20-50K depending on your costs). - Ongoing:
10-25% of an engineer for monitoring, debugging, evolution (€10-25K/year).
The breakeven is around 50,000-200,000 sessions/year per partner, depending on your engineering economics and the hub’s pricing. Smaller volume → hub wins clearly. Larger volume → P2P wins clearly. In between → it’s a judgment call about strategic value, not just cost.
What changes operationally
A practitioner’s checklist of what gets harder or easier with each model.
| Operational task | P2P | Hub |
|---|---|---|
| Add a new partner | Contract + integration per partner | Often a config change |
| Add a new module (e.g. ChargingProfiles) | Roll out to each partner separately | Hub upgrades; partners follow |
| Diagnose a failed session | Direct line to the partner’s on-call | Talk to the hub; hub escalates |
| Renegotiate terms | Direct, bilateral | Through the hub’s contract framework |
| Get new-partner discovery | Manual (find them, contract, integrate) | Hub publishes available parties |
| Handle a partner outage | Your monitoring sees it directly | Hub mediates; you see it via hub status |
| Stay current with OCPI versions | Independent per partner | Hub announces version support |
| Lock-in risk | Low (you own the connection) | Higher (hub is part of your stack) |
The OCPI 2.2 changes that matter here
OCPI 2.2 added two things that improved hub experiences specifically (see the 2.1.1 to 2.2 migration guide for the full set of changes).
HubClientInfo is a dedicated module for hubs to publish their connected-parties list, with live status. Before this, discovering who was reachable through a hub was an out-of-band process (their docs, their dashboard, their support team). Now it’s a machine-readable endpoint. Practically, this means a CPO can program against “all eMSPs reachable through hub X” rather than maintaining a manual list.
The role-based Credentials object (with the roles array) supports hubs declaring themselves as Hub plus the parties they represent. The handshake feels less like a hack and more like a designed feature.
Neither change made hubs strictly better or worse than P2P, but both made the hub model more honest about what it does.
A pragmatic decision framework
If you’re starting from zero and asking “how should I connect?”, here’s the order I’d think about it.
- Identify your top 3 strategic partners. These get P2P. Take the time to do it right. Negotiate operational SLAs in the contract.
- Identify the hub(s) that reach your other intended partners. If one hub covers 80% of the rest, that’s your hub.
- Estimate volumes. If a partner you’d planned to reach via hub turns out to be high-volume, reconsider — direct may pay for itself.
- Budget the engineering cost of both: building the P2P stack once (you’d need it for the top 3 anyway) plus integrating one hub. Both are real budget items.
- Plan for the hub to handle the long tail and grow. New partner becomes reachable via the hub → cheap. New partner is strategically important → upgrade to P2P over time if volume justifies.
The trap to avoid: don’t sign with a single hub assuming “we’ll never need P2P” and then discover your top-revenue partner is on the other hub. Build the P2P capability early; you’ll need it eventually.
What this means for your engineering team
A few practical takeaways for the people writing the code.
- Your OCPI client/server should treat hub and P2P partners identically internally. The Credentials handshake is the same shape. The module endpoints are the same. The differentiation should be in configuration, not code paths.
- Per-partner observability. Whether you reach a partner via P2P or hub, track that partner’s health (latency, error rate, success rate) individually. “The hub is having issues” is rarely true; usually one specific partner behind the hub is having issues, and the hub forwards the failure to you.
- Token rotation hygiene. Whichever model you use, set up automated token rotation reminders. Tokens that expire because no one renewed them are the most common cause of partners silently disappearing.
- Test both models in your CI if you support both. Run integration tests against a mock P2P partner AND a mock hub. They have subtly different failure modes.
The honest summary
There is no universally right answer between hub and P2P. The hub model trades some control and a per-session fee for dramatically less operational overhead. P2P trades operational overhead for control, lower per-session cost at high volume, and resilience.
Most successful operators end up with a small number of P2P connections to their most important partners plus a hub (sometimes two) for everything else. The architecture choice is reversible — you can promote a hub connection to P2P or demote a P2P connection to hub-mediated — so don’t over-think the initial decision. Start where the cost makes sense, monitor your actual volumes and operational pain, and adjust over time.