An OCPP connection carries communication between an EV charging station and its management system. Cellular internet failover can restore a network path when the primary ISP fails, but the charger and platform still need to reconnect and reconcile their records. For charging operators, the useful test is not simply whether the router comes online: it is whether status, commands and transaction reporting recover correctly.
The Open Charge Point Protocol, or OCPP, defines communication between charging stations and charging management systems. A charging station management system (CSMS) may sit within the broader charge point management system (CPMS) an operator uses to run its network. OCPP describes their conversation; the site network and internet service carry it.
That distinction explains how OCPP enables chargers to connect with management platforms. A charger needs a supported protocol implementation and the correct platform settings, as well as a working route to the management endpoint. A healthy internet circuit cannot fix incorrect credentials or an incompatible implementation. Equally, a correctly configured charger cannot reach a remote endpoint through a failed ISP connection.
A typical site path runs from the charger, through Ethernet or Wi-Fi and the local network, to a router and then the management cloud. Some chargers instead use an integrated cellular modem. Backup designed for the site router helps only the chargers whose communication actually traverses that router. A separate embedded connection needs its own resilience plan.
The Open Charge Alliance’s protocol overview distinguishes OCPP 1.6, 2.0.1 and 2.1. OCPP 1.6 supports SOAP and JSON implementations. OCPP 2.0.1 adds capabilities including improved transaction handling, device management and security; OCPP 2.1 extends the later architecture. The alliance also notes that application logic built for OCPP 2.0.1 remains compatible with 2.1.
The alliance explicitly states that OCPP 1.6 and 2.0.1 are not compatible. Record the version and implementation on both sides before a pilot. Changing the WAN path does not translate one OCPP version into another or add a feature a charger lacks.
A charger can deliver energy while its cloud record becomes stale. That makes a single “online” indicator an incomplete recovery test. The operator needs to know which functions have resumed and which records remain outstanding.
| Function | What the Cloud Needs | What to Check After Failover |
|---|---|---|
| Status visibility | Current charger reports | Fresh state and timestamps |
| Remote commands | A reachable station and application response | Acknowledgment and actual outcome |
| Transactions | Complete charging session records | Consistent identifiers, energy and timestamps |
Treat command delivery and command execution as different observations. A request accepted by a platform does not, by itself, show that the charger performed the action. Transaction recovery likewise needs a record comparison, not just a dashboard refresh.
Cellular backup provides an alternative WAN path around a failed primary internet service. It is useful when a working charger and local network lose their route to an otherwise available management platform. Wireless transport can also avoid dependence on a second physical ISP cable, although the actual independence of power, carrier infrastructure and equipment still matters.
The broader benefits of wireless EV connectivity extend beyond backup, but a failover project has a narrower job: restore the communication path that this site’s chargers use.
A backup connection needs working equipment, an active service and sufficient coverage at the installation location. A strong signal on a technician’s phone outside the cabinet is not an acceptance test for the deployed antenna and router.
The useful readiness check exercises the intended route to the required services. Include endpoint reachability, DNS resolution and any firewall or secure-access requirements in the design. Distinguish a primary connection that is physically down from one that remains connected locally but cannot reach the management cloud. Decide which conditions should trigger a switch and which team receives the alert.
Changing WAN paths may change the outward-facing address or interrupt an existing application connection. The charger and CSMS may need to reconnect even after the router has restored internet access. Keep router recovery time and application recovery time as separate measurements.
Queued-message behavior belongs to the charger and platform implementation. Establish what each stores, the storage limit, retry behavior and what happens after a reboot. Do not assume the network service buffers OCPP transactions or makes application retries safe.
Failback needs the same attention. A primary service that repeatedly recovers and fails can cause repeated transitions. The networking team should agree on restoration criteria, then test whether returning to the primary path causes another application interruption or leaves gaps in reporting.
EV charging network connectivity depends on several systems, and a backup WAN protects only part of that chain. Diagnose the failed layer before treating every offline alarm as a carrier problem.
A failed switch, disconnected cable or unavailable Wi-Fi access point can isolate a charger before traffic reaches the backup router. Cellular coverage can also vary by location and installation conditions. Map both routes, including shared equipment, so the alternative path does not depend on the component it is meant to protect.
The charger, router and local networking equipment have different power requirements. Keeping a router powered does not provide energy to a charging station. Keeping a charger powered does not keep its network switch running. Plan continuity and recovery for each, with qualified electrical personnel responsible for the electrical design.
A second internet route cannot restore an unavailable CSMS endpoint or repair a platform authentication failure. The incident process should distinguish “charger cannot reach the cloud” from “cloud service is unavailable.” Otherwise, a networking team may keep switching links while the actual failure sits elsewhere.
For a wider operational view, Kajeet’s discussion of EV charging uptime and failures provides context. Keep connectivity status, charger availability and successful charging sessions as separate measures in the pilot.
Offline behavior depends on the charger, its configuration and the platform’s operating model. An existing session, a newly requested session and remote management are different cases. One may work while another does not.
For example, an operator might find that an established session continues locally while its cloud status stops updating. Another configuration might prevent a new start when authorization cannot reach the platform. Those are scenarios to establish on representative equipment, not universal promises about OCPP.
Document the permitted offline behavior before commissioning backup. Include how a driver starts a session, whether local authorization is available, which operating settings remain effective and how records reach the platform afterward. OCPP 1.6 already supports a local authorization list, but whether a charger uses one depends on its configuration. Payment and authorization services may have dependencies beyond the charger’s OCPP connection; test those separately when they are in scope.
A useful pilot demonstrates recovery at the charger and in the management system, not only at the router. Use representative charger models, firmware and protocol versions, with the equipment and platform vendors involved in the acceptance criteria.
Keep a timestamped incident timeline alongside the final results. It should show when the network switched, when the application recovered, what drivers experienced and when records became consistent. That gives support teams a practical recovery reference rather than a one-time pass/fail screenshot.
As a network expands, connectivity planning for EV growth becomes an operating discipline. Revisit the pilot after material charger, firmware, platform or network changes instead of assuming the original result covers every later deployment.
Internet failover can reduce dependence on a single ISP, but cloud continuity is an end-to-end outcome. Separate network recovery from application reconnection, offline charging behavior and transaction reconciliation. The strongest acceptance evidence connects all four.
Kajeet SmartFailover combines automatic cellular backup with readiness monitoring and traffic prioritization, with Sentinel providing centralized visibility across sites. Match those capabilities to the site’s actual WAN path, then validate charger and CPMS behavior with their vendors. Questions to settle with Kajeet include whether OCPP and CSMS endpoints are among the prioritized traffic during an outage, how readiness alerts reach the operations team and whether the backup router sits on the path each charger uses. Discuss managed internet failover for the deployment and use the pilot results to define the operating plan.
Some chargers can continue local charging without internet, depending on configuration and authorization requirements. New session starts, remote commands and cloud reporting may behave differently. Test the specific charger and platform rather than assuming all charging stops or all services continue when connectivity fails.
OCPP defines charger-to-management-system communication, not a requirement to use Wi-Fi. The network path may use Ethernet, Wi-Fi or cellular connectivity according to the charger and site design. Backup must cover the path that the charger actually uses.
Do not assume it does. A WAN transition can interrupt the application connection, requiring the charger and management platform to reconnect. Measure network restoration and application recovery separately, including the effect on active charging and transaction reporting.
Successful reconciliation depends on the charger and management platform’s implementation, configuration and available storage. Establish queue limits, retry behavior and recovery after reboot, then compare transaction records after an outage. Protocol support alone is not an acceptance test.