Migration Guide 2.0.1 → 2.1 Section B

Provisioning — Migration Guide

Use cases B01–B13 (Provisioning). Perspective: CSMS Developer.

7 Sections
13 Use Cases
B01 – B13

Created by tzi.app — your guide to migrating from OCPP 2.0.1 to OCPP 2.1.

1. Summary of Changes

High-Level Overview

Area Change Type Description
Connector status reporting Replaced StatusNotificationRequest replaced by NotifyEventRequest with AvailabilityState across B01, B04, B11, B12
StatusInfoType Breaking additionalInfo max: 512 → 1024 chars
SetVariablesRequest Breaking attributeValue max: 1000 → 2500 chars
SetNetworkProfileRequest Extended New enum values (OCPP201, OCPP21, Any), new fields (identity, basicAuthPassword), ocppCsmsUrl max: 512 → 2000 chars
B09 — New method Additive Network profiles can now be set via SetVariablesRequest on NetworkConfiguration component (preferred in 2.1)
B09 — Security rule Breaking Downgrading to Security Profile 1 is always rejected even when AllowSecurityProfileDowngrade = true (B09.FR.31)
B10 — Flow changed Changed Adds recommended step to set CS to Inoperative before migration; new requirement B10.FR.10
B11/B12 — Reset type Additive ResetEnumType gains ImmediateAndResume value
B13 — New use case Additive Reset with transaction resumption after reboot (ImmediateAndResume)
B01 — Gating rule Breaking B01.FR.08 — CS must not send any OCPP requests (including cached) before BootNotification completes

2. Cross-Cutting Change: StatusNotification Replaced by NotifyEvent

This is the most impactful change in the Provisioning section. In OCPP 2.0.1, connector status was reported via a dedicated StatusNotificationRequest. In OCPP 2.1, this is replaced by NotifyEventRequest using the AvailabilityState variable on the Connector component.

Affected Use Cases

Use Case OCPP 2.0.1 OCPP 2.1
B01 (Cold Boot - Accepted) CS sends StatusNotificationRequest per connector CS sends NotifyEventRequest with AvailabilityState per connector
B04 (Offline Reconnection) CS sends StatusNotificationRequest for connectors CS sends NotifyEventRequest with AvailabilityState for connectors
B11 (Reset - EVSE) CS sends StatusNotificationRequest (Unavailable → Available) CS sends NotifyEventRequest with AvailabilityState = Unavailable then Available
B12 (Reset with transaction) CS sends StatusNotificationRequest CS sends NotifyEventRequest with AvailabilityState

Message Format Comparison

OCPP 2.0.1 — StatusNotificationRequest 
{
  "timestamp": "2025-06-15T14:30:05.000Z",
  "connectorStatus": "Available",
  "evseId": 1,
  "connectorId": 1
}
OCPP 2.1 — NotifyEventRequest (replacement) 
{
  "generatedAt": "2025-06-15T14:30:05.000Z",
  "seqNo": 0,
  "eventData": [
    {
      "eventId": 1,
      "timestamp": "2025-06-15T14:30:05.000Z",
      "trigger": "Delta",
      "actualValue": "Available",
      "eventNotificationType": "HardWiredNotification",
      "component": {
        "name": "Connector",
        "evse": { "id": 1, "connectorId": 1 }
      },
      "variable": {
        "name": "AvailabilityState"
      }
    }
  ]
}

CSMS Migration Actions

  1. 1 Remove the StatusNotificationRequest handler from provisioning flows (or keep for backwards compatibility if supporting both versions).
  2. 2 Add a NotifyEventRequest handler that filters for variable.name = "AvailabilityState" on Connector components.
  3. 3 Map the actualValue field to connector status. Possible values remain the same: Available, Occupied, Reserved, Unavailable, Faulted.
  4. 4 Respond with an empty NotifyEventResponse ({}).

3. Data Type & Schema Changes

3.1 StatusInfoType

Field OCPP 2.0.1 OCPP 2.1 Action Required
additionalInfo max 512 chars max 1024 chars Update validation to accept longer strings

This affects all responses that include statusInfo: BootNotificationResponse, SetVariablesResponse, GetVariablesResponse, GetBaseReportResponse, GetReportResponse, SetNetworkProfileResponse, ResetResponse.

3.2 SetVariablesRequest — attributeValue

Field OCPP 2.0.1 OCPP 2.1 Action Required
setVariableData[].attributeValue max 1000 chars max 2500 chars Update validation

3.3 SetNetworkProfileRequest — connectionData

Schema comparison: 2.0.1 vs 2.1 
// OCPP 2.0.1
{
  "configurationSlot": 1,
  "connectionData": {
    "ocppVersion": "OCPP20",
    "ocppTransport": "JSON",
    "ocppInterface": "Wired0",
    "ocppCsmsUrl": "<max 512>",
    "messageTimeout": 30,
    "securityProfile": 2
  }
}

// OCPP 2.1
{
  "configurationSlot": 1,
  "connectionData": {
    "ocppVersion": "OCPP21",
    "ocppTransport": "JSON",
    "ocppInterface": "Wired0",
    "ocppCsmsUrl": "<max 2000>",
    "messageTimeout": 30,
    "securityProfile": 2,
    "identity": "CS-001",          // NEW
    "basicAuthPassword": "password123"  // NEW
  }
}

Field-level changes:

Field OCPP 2.0.1 OCPP 2.1 Action Required
ocppVersion OCPP12, OCPP15, OCPP16, OCPP20 Adds OCPP201, OCPP21 Add new enum values
ocppInterface Wired0-Wired3, Wireless0-Wireless3 Adds Any Add new enum value
ocppCsmsUrl max 512 chars max 2000 chars Update validation
identity Not present max 48 chars (optional) New field — CS identity for basic auth
basicAuthPassword Not present max 64 chars (optional) New field — basic auth password

3.4 ResetEnumType

Value OCPP 2.0.1 OCPP 2.1
Immediate Yes Yes
OnIdle Yes Yes
ImmediateAndResume Not present New — reset immediately and resume transactions after reboot (B13)

3.5 VariableCharacteristics — New Field

Field OCPP 2.0.1 OCPP 2.1 Description
maxElements Not present integer, minimum 1 Maximum number of elements in list-type variables

4. Use Case Changes (B01-B12)

4.1 B01 — Cold Boot Charging Station

Change Detail
Connector status reporting StatusNotificationRequest → NotifyEventRequest (see Section 2)
New requirement B01.FR.05 CS sends NotifyEventRequest with variable.name = AvailabilityState for each Connector
New requirement B01.FR.07 If Connector was set to Unavailable by ChangeAvailabilityRequest, that state must persist across reboots
New requirement B01.FR.08 Between power-on and successful BootNotification completion, CS SHALL NOT send any OCPP requests except BootNotificationRequest — including cached messages from prior sessions
Messages list StatusNotificationRequest/Response removed; NotifyEventRequest/Response added

CSMS Action: Update post-boot handler to expect NotifyEventRequest instead of StatusNotificationRequest. Be aware of B01.FR.08 — the CS will not send cached messages until boot is accepted.

4.2 B02 — Cold Boot Charging Station (Pending)

No significant changes beyond the general StatusNotification → NotifyEvent replacement. Functional requirements B02.FR.01, B02.FR.05, B02.FR.06, B02.FR.09 remain the same.

4.3 B03 — Cold Boot Charging Station (Rejected)

No changes. Requirements B03.FR.03 and B03.FR.07 remain the same.

4.4 B04 — Offline Behavior Idle Charging Station

Change Detail
Connector status reporting StatusNotificationRequest → NotifyEventRequest with AvailabilityState
B04.FR.01 If offline period exceeded OfflineThreshold: CS sends NotifyEventRequest for all Connectors (was StatusNotificationRequest)
B04.FR.02 If offline period did not exceed OfflineThreshold: CS sends NotifyEventRequest only for changed Connectors (was StatusNotificationRequest)

CSMS Action: Update reconnection handler to process NotifyEventRequest instead of StatusNotificationRequest.

4.5 B05 — Set Variables

Change Detail
attributeValue max length 1000 → 2500 chars
New requirement B05.FR.01 Response will contain the same number of setVariableResult entries as setVariableData entries sent
New requirement B05.FR.02 Each result entry will match the same component/variable combination
New requirement B05.FR.12 If request omitted attributeType, response will contain attributeType = Actual

These new requirements formalize behavior that was implicit in 2.0.1. No logic changes needed.

4.6 B06 — Get Variables

Change Detail
New requirement B06.FR.11 If request omitted attributeType, response will contain attributeType = Actual
New requirement B06.FR.13 If the variable has no attributeValue for the requested type, CS returns an empty string

These formalize implicit 2.0.1 behavior.

4.7 B07 — Get Base Report

Change Detail
SummaryInventory clarified Now explicitly described as including AvailabilityState for CS, each EVSE, each Connector, and abnormal state variables (Problem, Tripped, Overload, Fallback)
VariableCharacteristics new field maxElements added (see Section 3.5)

4.8 B08 — Get Custom Report

No significant changes beyond VariableCharacteristics gaining maxElements.

4.9 B09 — Setting a New NetworkConnectionProfile

Significant Changes
Change Detail
New method (preferred) Network profiles can be set via SetVariablesRequest on the NetworkConfiguration component (Method B). SetNetworkProfileRequest is retained as legacy (Method A).
New requirement B09.FR.21 CSMS SHALL NOT send SetVariablesRequest containing any NetworkConfiguration variable for a slot currently in NetworkConfigurationPriority
New requirement B09.FR.22 If CS receives such a request, it responds Rejected with reasonCode = "PriorityNetworkConf"
New requirement B09.FR.31 Even when AllowSecurityProfileDowngrade = true, downgrading to Security Profile 1 is always rejected if current profile is higher than 1
Schema changes See Section 3.3 for field additions and size increases
CSMS Action — Method B (new, preferred):
  1. 1 Ensure the target slot is NOT in the active NetworkConfigurationPriority. If it is, remove it first via SetVariablesRequest.
  2. 2 Set variables on NetworkConfiguration component with instance = <configurationSlot>.
  3. 3 Add the slot back to NetworkConfigurationPriority.

CSMS Action — Security: Handle the new B09.FR.31 rule. Even if AllowSecurityProfileDowngrade is true, do not attempt to downgrade to Profile 1 from a higher profile — the CS will always reject it.

4.10 B10 — Migrate to New CSMS

Change Detail
New recommended step [B10.FR.05] Before resetting, send ChangeAvailabilityRequest to set CS to Inoperative to prevent new transactions, then use GetTransactionStatusRequest to verify no queued transactions
New requirement B10.FR.10 CS will send BootNotificationRequest to new CSMS even if it has not rebooted
Flow simplification 2.0.1 included SetNetworkProfileRequest as Step 1 within B10. In 2.1, B09 is a prerequisite — the profile is already configured before migration begins
2.0.1 Migration Flow
1. SetNetworkProfileRequest
   (store new profile)
2. SetVariablesRequest
   (update priority)
3. ResetRequest
   (trigger reboot)
2.1 Migration Flow
Prereq: B09 completed
1. SetVariablesRequest
   (update priority)
2. ChangeAvailabilityRequest
   (set Inoperative) [RECOMMENDED]
3. ResetRequest
   (trigger reboot)

Fallback requirements (B10.FR.06-FR.09) remain unchanged — CS will try old connection profiles if new CSMS is unreachable, and should never permanently stop reconnecting.

4.11 B11 — Reset Without Ongoing Transaction

Change Detail
New reset type ImmediateAndResume added to ResetEnumType (triggers B13 flow)
Post-reset status Uses NotifyEventRequest instead of StatusNotificationRequest
New requirement B11.FR.02 If CS was set to Inoperative by CSMS, EVSEs SHALL return to Unavailable after reboot
New requirement B11.FR.05 If EVSE was Reserved, it SHALL return to Reserved after reboot

4.12 B12 — Reset With Ongoing Transaction

Change Detail
TransactionEvent detail 2.1 explicitly specifies triggerReason=ResetCommand and stoppedReason=ImmediateReset in the TransactionEventRequest
New requirement B12.FR.05 If TransactionEventResponse not received within timeout, CS queues and resends after reboot
New requirement B12.FR.09 CS responds Rejected if it doesn't support individual EVSE reset
New requirement B12.FR.10 CS responds Rejected if unable to reset for reasons other than ongoing transactions

5. New Use Case: B13 — Reset With Ongoing Transaction (Resuming)

B13 is entirely new in OCPP 2.1. It enables a Charging Station to reset and resume ongoing transactions after reboot, rather than terminating them.

Property Value
Trigger CSMS sends ResetRequest with type = ImmediateAndResume
Prerequisite CS supports TxResumptionTimeout > 0
Key Benefit Transactions survive reboots — important for firmware updates or configuration changes during active charging

Flow

B13 — Reset with Transaction Resumption 
CSMS                                     Charging Station
 |                                              |
 | ResetRequest(ImmediateAndResume)             |
 |--------------------------------------------->|
 |                                              |
 | ResetResponse(Accepted)                      |
 |<---------------------------------------------|
 |                                              |
 | TransactionEventRequest(Updated,             |
 |   triggerReason=ResetCommand)                |
 |<---------------------------------------------|
 | TransactionEventResponse()                   |
 |--------------------------------------------->|
 |                                              |
 |                                    [Reboot]  |
 |                                              |
 | BootNotificationRequest(...)                 |
 |<---------------------------------------------|
 | BootNotificationResponse(Accepted)           |
 |--------------------------------------------->|
 |                                              |
 | TransactionEventRequest(Updated,             |
 |   triggerReason=TxResumed)                   |
 |<---------------------------------------------|
 | TransactionEventResponse()                   |
 |--------------------------------------------->|
 |                                              |
 | [If TxProfile existed and not persistent]    |
 | SetChargingProfileRequest(TxProfile)         |
 |--------------------------------------------->|

Key Requirements

Req ID Requirement
B13.FR.01 If TxResumptionTimeout = 0 or not supported, CS responds Rejected
B13.FR.02 If no transactions are ongoing, CS responds Accepted and acts as B11 (normal reset)
B13.FR.03 If transactions are ongoing, CS responds Accepted and will resume them after reboot
B13.FR.13 If TxAllowEnergyTransferResumption = true, energy transfer resumes automatically after reboot
B13.FR.14 If TxAllowEnergyTransferResumption = false, transaction resumes in SuspendedEVSE state
B13.FR.30 After reboot, CS sends TransactionEventRequest with triggerReason = TxResumed
B13.FR.31 When CSMS receives triggerReason = TxResumed and had a TxProfile for the transaction and ChargingProfilePersistence for TxProfile is false/absent, CSMS SHALL re-send the SetChargingProfileRequest

CSMS Implementation Actions

  1. 1 Add support for sending ResetRequest with type = ImmediateAndResume.
  2. 2 Handle TransactionEventRequest with triggerReason = TxResumed — this indicates a resumed transaction.
  3. 3 Track which transactions have active TxProfile charging profiles.
  4. 4 Re-send SetChargingProfileRequest for transactions that resume if the profile is not persistent.
  5. 5 Check TxResumptionTimeout and TxAllowEnergyTransferResumption configuration variables before sending ImmediateAndResume.

6. New & Changed Configuration Variables

Component Variable OCPP 2.0.1 OCPP 2.1 Description
TxCtrlr TxResumptionTimeout Not present New Seconds to wait for transaction resumption after ImmediateAndResume reset. Value of 0 means not supported.
TxCtrlr TxAllowEnergyTransferResumption Not present New Whether energy transfer may resume automatically on resumed transactions (boolean)
SecurityCtrlr Identity Not present New (deprecated) CS identity for basic auth. Deprecated in favor of NetworkConfiguration component.
SecurityCtrlr BasicAuthPassword Not present New (WriteOnly) Basic auth password
SecurityCtrlr AllowSecurityProfileDowngrade Existed Updated behavior Even when true, downgrading to Profile 1 is always rejected (B09.FR.31)
DeviceDataCtrlr ConfigurationValueSize Not present New Max length of configuration values
DeviceDataCtrlr ReportingValueSize Not present New Max length of reported values
SmartChargingCtrlr ChargingProfilePersistence (instance: TxProfile) Not present New Whether TxProfile charging profiles persist across reboots (relevant to B13)

7. Migration Checklist

Must Do

  • Replace StatusNotification handlers — Update B01, B04, B11, B12 flows to handle NotifyEventRequest with AvailabilityState instead of StatusNotificationRequest
  • Update field size validations — StatusInfoType.additionalInfo (512 → 1024), SetVariablesRequest.attributeValue (1000 → 2500), SetNetworkProfileRequest.ocppCsmsUrl (512 → 2000)
  • Add ImmediateAndResume reset type — Update ResetEnumType enum to include ImmediateAndResume
  • Handle B01.FR.08 — Be aware that CS will not send cached messages before BootNotification is accepted
  • Update SetNetworkProfile handling — Add new OCPPVersionEnumType values (OCPP201, OCPP21), new OCPPInterfaceEnumType value (Any), new fields (identity, basicAuthPassword)
  • Handle B09.FR.31 — Do not attempt security profile downgrade to Profile 1 from a higher profile

Should Do

  • Implement B13 support — Handle ImmediateAndResume reset with transaction resumption
  • Implement Method B for B09 — Set network profiles via SetVariablesRequest on NetworkConfiguration component (preferred over legacy SetNetworkProfileRequest)
  • Update B10 migration flow — Add ChangeAvailabilityRequest (Inoperative) step before reset, per B10.FR.05
  • Handle triggerReason=TxResumed — Re-send TxProfile charging profiles for resumed transactions (B13.FR.31)
  • Track new config variables — Read and store TxResumptionTimeout, TxAllowEnergyTransferResumption from device model reports

Good to Know

  • B05.FR.01, B05.FR.02, B05.FR.12, B06.FR.11, B06.FR.13 formalize previously implicit behavior — no logic changes needed if already handling responses correctly
  • VariableCharacteristics gains a maxElements field in report data — update parsing if storing device model
  • SummaryInventory report type in B07 is now explicitly defined to include AvailabilityState for CS/EVSE/Connector plus abnormal state variables

OCPP 2.1 Provisioning Migration Guide — Section B (Use Cases B01–B13) — CSMS Developer Perspective