Der Kommunikationsablauf nach ISO 15118-20

Der CCS2-Stecker wird eingesteckt. Über den Control Pilot-Leiter im Kabel erkennt die Ladestation sofort dass ein Fahrzeug angeschlossen ist. Das geschieht über eine definierte Spannungsänderung auf dem CP-Leiter: Im unverbundenen Zustand liegt eine Spannung von 12 Volt an. Sobald das Fahrzeug den Stecker einsteckt, zieht es die Spannung auf 9 Volt herunter. Die Ladestation erkennt diesen Pegelwechsel und weiss: ein Fahrzeug ist verbunden und bereit.

Parallel dazu ist im CCS2-Stecker ein Proximity Pilot-Leiter verbaut der der Ladestation die mechanische Steckerverriegelung und die Kabelkapazität signalisiert. Erst wenn sowohl CP als auch PP korrekte Signale liefern gilt die physische Verbindung als vollständig hergestellt.

Bei AC-Laden antwortet die Ladestation auf den Pegelwechsel mit einem PWM-Signal auf dem Control Pilot, das dem Fahrzeug mitteilt wie viel Strom maximal bezogen werden darf. Dieses PWM-Signal ist über die Duty Cycle Breite kodiert: ein Duty Cycle von 16 Prozent entspricht beispielsweise einer maximalen Stromstärke von 10 Ampere. Der Onboard-Charger im Fahrzeug ist für die Gleichrichtung zuständig und regelt den Ladevorgang selbst. Wenn kein ISO 15118-20 Protokoll aktiv ist, reicht dieses PWM-Signal vollständig aus um den Ladevorgang zu steuern. Das ist der Grund warum AC-Laden auch ohne ISO 15118-20 funktioniert.

Bei DC-Laden ist der Ablauf fundamental anders. Die Ladestation liefert Gleichstrom direkt in die Batterie, der Onboard-Charger im Fahrzeug ist komplett umgangen. Das bedeutet Fahrzeug und Ladestation müssen sich zwingend über ein Protokoll auf Spannung, Strom und alle weiteren Parameter einigen bevor auch nur ein einziges Volt fliesst. Das PWM-Signal auf dem CP-Leiter reicht dafür nicht aus. Bei DC signalisiert die Ladestation über den CP deshalb einen speziellen Duty Cycle von 5 Prozent, was dem Fahrzeug mitteilt: Diese Station unterstützt digitale Kommunikation über ISO 15118 oder DIN SPEC 70121. Das Fahrzeug aktiviert daraufhin sein PLC-Modul und der Kommunikationsaufbau beginnt ab Schritt 2.

ISO 15118-20 selbst beginnt erst im nächsten Schritt. Die IEC 61851-1 Signalisierung bleibt aber während der gesamten Ladesession aktiv und dient als Sicherheitsebene, wird der Stecker gezogen oder die Verbindung unterbrochen, erkennt die Ladestation das sofort über den CP-Pegelwechsel und trennt die Leistungselektronik unabhängig davon was auf der ISO 15118-20 Protokollebene gerade passiert.

SLAC ist in ISO 15118-3 definiert und wird von ISO 15118-20 explizit referenziert: "If a V2G entity communicates by PLC, the V2G entity shall comply with ISO 15118-3." SLAC hat eine einzige aber kritische Aufgabe: sicherstellen dass Fahrzeug und Ladestation wirklich physisch am selben Kabel hängen und nicht versehentlich mit einer Nachbarstation kommunizieren. In einem Parkhaus mit vielen Ladepunkten nebeneinander ist das keine triviale Aufgabe — ohne SLAC könnte ein Fahrzeug theoretisch mit der falschen Ladestation kommunizieren.

Der Ablauf ist präzise definiert. Das Fahrzeug sendet wiederholt CM_SLAC_PARAM.REQ Nachrichten über den CP-Leiter und startet damit das SLAC-Verfahren. Die Ladestation antwortet mit CM_SLAC_PARAM.CNF und bestätigt ihre Bereitschaft. Danach sendet das Fahrzeug eine Serie von CM_START_ATTEN_CHAR.IND Nachrichten gefolgt von CM_MNBC_SOUND.IND Messtönen. Die Ladestation misst bei jedem dieser Töne die Signaldämpfung auf dem CP-Leiter und sammelt die Messwerte. Nach Abschluss der Messreihe sendet die Ladestation CM_ATTEN_CHAR.IND mit den gemittelten Dämpfungswerten zurück ans Fahrzeug.

Das Fahrzeug wertet diese Dämpfungswerte aus. Je niedriger die gemessene Dämpfung, desto direkter und stärker ist die physische Verbindung zwischen Fahrzeug und Station. Liegt der Dämpfungswert unterhalb eines definierten Schwellwerts, entscheidet das Fahrzeug: diese Station ist die richtige. Es sendet CM_SLAC_MATCH.REQ um den Matching-Prozess abzuschliessen. Die Ladestation antwortet mit CM_SLAC_MATCH.CNF und übermittelt dabei den Network Management Key (NMK) und die Network Identifier (NID) — zwei kryptographische Parameter die das gemeinsame logische PLC-Netzwerk definieren. Beide Geräte konfigurieren ihre HomePlug Green PHY Module mit diesen Parametern und sind damit im selben privaten PLC-Netzwerk.

Dieses PLC-Netzwerk nach HomePlug Green PHY arbeitet im Frequenzbereich von 1,8 bis 30 MHz und nutzt OFDM-Modulation (Orthogonal Frequency Division Multiplexing) für eine robuste Datenübertragung über das Stromkabel. Die Übertragungsrate ist begrenzt aber für die ISO 15118-20 Kommunikation vollständig ausreichend. Wichtig: Das PLC-Netzwerk selbst ist auf Layer 1 und 2 nicht verschlüsselt. Die Sicherheit der übertragenen Daten kommt ausschliesslich durch TLS auf Layer 4, das in Schritt 6 aufgebaut wird.

Das fertige PLC-Netzwerk bildet den physischen Datenkanal für alle weiteren Kommunikationsschritte von IPv6-Adressvergabe über SDP bis hin zum vollständigen ISO 15118-20 Nachrichtenaustausch.

Über das aufgebaute PLC-Netzwerk konfigurieren beide Geräte automatisch eine IPv6 Link-Local Adresse nach dem Stateless Address Autoconfiguration Verfahren gemäss IETF RFC 4862. Der Standard schreibt IPv6 als Pflicht vor: "A V2G entity shall support IPv6 as defined in IETF RFC 8200." IPv4 ist explizit nicht vorgesehen — ISO 15118-20 setzt konsequent auf IPv6 als einziges Netzwerkprotokoll.

Der Ablauf von SLAAC ist vollständig automatisch und benötigt weder einen DHCP-Server noch eine manuelle Konfiguration. Jedes Gerät leitet seine IPv6 Link-Local Adresse aus seiner 48-Bit MAC-Adresse ab. Dazu wird die MAC-Adresse nach dem EUI-64 Verfahren in eine 64-Bit Interface ID umgewandelt: Die MAC-Adresse wird in zwei 24-Bit Hälften geteilt, dazwischen werden die Bytes FF:FE eingefügt und das siebte Bit des ersten Bytes wird invertiert. Diese 64-Bit Interface ID wird mit dem Link-Local Präfix FE80::/64 kombiniert. Das Ergebnis ist eine IPv6 Link-Local Adresse der Form FE80::xxxx:xxFF:FExx:xxxx die nur innerhalb des lokalen PLC-Netzwerks gültig ist und nicht ins Internet geroutet wird.

Bevor ein Gerät diese Adresse verwendet, prüft es über das Neighbor Discovery Protocol nach IETF RFC 4861 ob die Adresse bereits von einem anderen Gerät im Netzwerk verwendet wird. Dieser Vorgang heisst Duplicate Address Detection (DAD). Das Gerät sendet dazu eine Neighbor Solicitation Nachricht an die Solicited-Node Multicast-Adresse der geplanten Adresse. Antwortet kein anderes Gerät, gilt die Adresse als eindeutig und wird aktiviert.

Da die IPv6 Link-Local Adresse deterministisch aus der MAC-Adresse berechnet wird, ist sie bei jeder neuen Ladesession identisch — solange dieselbe Hardware verwendet wird. Das vereinfacht den Verbindungsaufbau weil keine Adressaushandlung zwischen den Sessions nötig ist.

Nach diesem Schritt haben beide Geräte eine eindeutige und verifizierte IPv6 Link-Local Adresse im gemeinsamen PLC-Netzwerk und sind bereit für den nächsten Schritt: die SECC Discovery über SDP.

Das Fahrzeug weiss nun dass es mit einer Ladestation verbunden ist und hat eine IPv6 Link-Local Adresse. Es weiss aber noch nicht auf welchem TCP-Port die Ladestation auf TLS-Verbindungen wartet und ob die Station überhaupt TLS unterstützt. Das klärt das SECC Discovery Protocol.

Das Fahrzeug sendet einen SDP Request als UDP-Paket an die reservierte IPv6 Multicast-Adresse FF02::1 auf dem fest definierten UDP-Port 15118. Dieser Port ist von der IANA exklusiv für V2G-Kommunikation reserviert. Der SDP Request wird als V2GTP Nachricht verpackt mit dem Payload Type SDPRequestPayloadID im 8-Byte V2GTP Header. Die Nachricht enthält zwei Parameter: den gewünschten Sicherheitsmodus, also ob das Fahrzeug TLS oder ungesicherte Kommunikation bevorzugt, sowie den gewünschten Transportprotokolltyp, also TCP oder UDP.

Der Standard schreibt vor dass das Fahrzeug TLS als bevorzugten Sicherheitsmodus anfordern soll. Es sendet im SDP Request den Wert Security: 0x10 für TLS. Nur in Ausnahmefällen und für bestimmte Value Added Services ist Security: 0x00 für ungesicherte Kommunikation erlaubt.

Die Ladestation empfängt den SDP Request und antwortet mit einem SDP Response (Payload Type SDPResponsePayloadID). Diese Antwort enthält vier Parameter: die IPv6-Adresse der Ladestation auf der TLS läuft, den TCP-Port auf dem die Ladestation auf eingehende TLS-Verbindungen wartet, den tatsächlich verwendeten Sicherheitsmodus und den tatsächlich verwendeten Transportprotokolltyp. Der Standard-TLS-Port für ISO 15118-20 ist 15118, kann aber vom Hersteller abweichen.

Hier liegt eine sicherheitsrelevante Schwachstelle die der Standard explizit benennt: SDP läuft über UDP ohne jede Verschlüsselung oder Authentifizierung. Ein Angreifer der Zugang zum PLC-Netzwerk hat könnte theoretisch eine gefälschte SDP Response schicken und das Fahrzeug auf einen falschen TCP-Port umleiten. Bei PLC ist dieses Risiko begrenzt weil physischer Zugang zum Kabel nötig wäre. Bei WLAN-basierter Kommunikation ist das Risiko deutlich höher weshalb der Standard dort zusätzlich IEEE 802.1X mit WPA3-Enterprise empfiehlt.

Sendet eine Ladestation im SDP Response Security: 0x10 für TLS, muss sie zwingend ein gültiges SECC Zertifikat besitzen das das Fahrzeug im nachfolgenden TLS Handshake prüfen kann. Sendet sie TLS an obwohl kein Zertifikat vorhanden ist, scheitert der TLS Handshake im nächsten Schritt unweigerlich. Genau das ist die Ursache des Fehlers der bei schlecht konfigurierten Stationen in den Logs als TLS no cert erscheint.

Nach diesem Schritt weiss das Fahrzeug genau wohin es die TLS-Verbindung aufbauen soll und welchen Sicherheitsmodus die Ladestation unterstützt.

Das Fahrzeug öffnet eine TCP-Verbindung nach IETF RFC 793 zur IPv6-Adresse und dem TCP-Port die es im SDP Response von der Ladestation erhalten hat. TCP steht für Transmission Control Protocol und bildet die zuverlässige Transportschicht für den gesamten weiteren ISO 15118-20 Datenaustausch.

Der TCP-Verbindungsaufbau erfolgt über den klassischen Three-Way-Handshake. Das Fahrzeug sendet als TCP-Client ein SYN Paket an die Ladestation. Die Ladestation antwortet als TCP-Server mit SYN-ACK. Das Fahrzeug bestätigt mit ACK. Nach diesen drei Paketen ist die TCP-Verbindung aufgebaut und beide Geräte sind bereit Daten zu übertragen.

TCP garantiert dabei drei wichtige Eigenschaften die für ISO 15118-20 zwingend nötig sind. Erstens Zuverlässigkeit: jedes gesendete Paket wird vom Empfänger bestätigt. Geht ein Paket verloren, wird es automatisch erneut gesendet. Zweitens Reihenfolge: TCP nummeriert jedes Byte mit einer Sequenznummer. Kommen Pakete in falscher Reihenfolge an, sortiert TCP sie vor der Übergabe an die Anwendung korrekt ein. Drittens Flusskontrolle: TCP passt die Übertragungsgeschwindigkeit an die Verarbeitungskapazität beider Geräte an und verhindert damit eine Überlastung des Empfängers.

Der Standard schreibt TCP als einziges Transportprotokoll für den ISO 15118-20 Hauptkommunikationskanal vor. SDP im vorherigen Schritt läuft als einzige Ausnahme über UDP, weil es sich um einen einfachen Discovery-Broadcast handelt bei dem die Verbindungslosigkeit von UDP kein Problem darstellt. Alle weiteren Nachrichten vom TLS Handshake über den V2GTP Nachrichtenaustausch bis zum SessionStop laufen ausnahmslos über diese eine TCP-Verbindung.

Der Standard definiert auch Timeouts für den TCP-Verbindungsaufbau. Antwortet die Ladestation nicht innerhalb der vorgeschriebenen Zeit auf den SYN des Fahrzeugs, bricht das Fahrzeug den Verbindungsversuch ab und kann einen neuen Versuch starten oder den Ladevorgang als gescheitert melden. Nach erfolgreichem TCP-Aufbau beginnt sofort der TLS 1.3 Handshake im nächsten Schritt.

Der Standard schreibt TLS 1.3 nach IETF RFC 8446 als Pflicht vor: "For the considered use cases mutual authentication with TLS version 1.3 shall be supported by each V2G entity." Es handelt sich immer um eine gegenseitige Authentifizierung, das heisst sowohl das Fahrzeug prüft die Ladestation als auch die Ladestation prüft das Fahrzeug.

Das Fahrzeug sendet als TLS-Client das ClientHello. Dieses Paket enthält die supported_versions Extension mit dem Wert 0x0304 für TLS 1.3, einen zufälligen Nonce mit mindestens 231 Bit Entropie, die cipher_suites Liste mit den zwei vom Standard vorgeschriebenen Cipher Suites TLS_AES_256_GCM_SHA384 als bevorzugte Suite und TLS_CHACHA20_POLY1305_SHA256 als Fallback, die supported_groups Extension mit den elliptischen Kurven secp521r1 (521 Bit) und x448 (448 Bit), den ECDH Public Key des Fahrzeugs in der key_share Extension für den späteren Schlüsselaustausch, die status_request Extension welche die Ladestation auffordert OCSP-Antworten für ihre Zertifikate mitzuliefern, sowie die certificate_authorities Extension mit der vollständigen Liste aller Root CA Distinguished Names die das Fahrzeug kennt. Diese Liste enthält die DNs aller V2G Root CA Zertifikate und PE Private Root CA Zertifikate die im gesicherten Speicher des Fahrzeugs abgelegt sind.

Befindet sich das Fahrzeug im CPM4PE Pairing-Modus, sendet es eine leere authorities Liste. Der Standard formuliert das als explizites Requirement: "While the EVCC is in CPM4PE, it shall send an empty authorities element regardless if the EVCC has any V2G root CA certificates and PE private root CA certificates or not." Diese leere Liste ist das präzise definierte Signal an die Ladestation dass ein Pairing-Vorgang initiiert werden soll.

Die Ladestation antwortet als TLS-Server mit dem ServerHello. Sie liest die certificate_authorities Liste des Fahrzeugs und wählt anhand der übermittelten Distinguished Names diejenige Zertifikatskette aus die zu einer dem Fahrzeug bekannten Root CA führt. Das ServerHello enthält den ausgewählten Named Group und die ausgewählte Cipher Suite, den eigenen ECDH Public Key für den Schlüsselaustausch, die vollständige Zertifikatskette bis zur Root CA ausschliesslich des Root CA Zertifikats selbst, sowie bei öffentlichen Ladestationen die OCSP-Antworten für jedes Zertifikat in der Kette. Der Standard begrenzt die Gültigkeitsdauer jeder OCSP-Antwort auf maximal eine Woche. Befindet sich die private Ladestation im CPM4PE Modus, sendet sie zusätzlich ihr PE Private Root CA Zertifikat vollständig mit. Das ist die einzige Situation in der ein Root CA Zertifikat über die Leitung übertragen wird.

Nach dem ServerHello sendet die Ladestation eine CertificateRequest Nachricht und fordert das Fahrzeug auf sein Vehicle Certificate zu übermitteln. Die certificate_authorities Extension in dieser Nachricht enthält die DNs aller V2G Root CA und OEM Root CA Zertifikate die auf der Ladestation gespeichert sind. Im CPM4PE Modus ist auch diese Liste leer.

Das Fahrzeug antwortet mit seiner Vehicle Zertifikatskette. Das Vehicle Certificate basiert auf dem Profil B.8 des Standards mit einer Schlüssellänge von 521 Bit für die Kurve secp521r1 oder 448 Bit für Curve448.

Beide Geräte prüfen nun die jeweils empfangene Zertifikatskette. Das Fahrzeug prüft ob die Kette der Ladestation zu einer bekannten Root CA führt, ob alle Zertifikate zeitlich gültig sind und ob der OCSP-Status jedes Zertifikats den Wert "good" trägt. Schlägt eine dieser Prüfungen fehl, bricht das Fahrzeug den TLS-Aufbau sofort ab: "If the EVCC is unable to validate the SECC/PE certificate chain successfully, the EVCC shall abort the TLS session setup process." Bei PE Zertifikaten privater Ladestationen ohne OCSP-Antworten setzt das Fahrzeug die Validierung ohne Revocation Check fort. Die öffentliche Ladestation prüft das Vehicle Certificate des Fahrzeugs und kontaktiert dafür den OCSP-Responder oder bezieht eine Certificate Revocation List mit einer maximalen Gültigkeitsdauer von einer Woche.

Beide Geräte berechnen anschliessend lokal aus ihren eigenen ECDH Private Keys und den ausgetauschten ECDH Public Keys denselben Shared Secret. Aus diesem Shared Secret werden die symmetrischen Session Keys für AES-GCM abgeleitet. Kein Session Key wird übertragen. Nach dem Finished Paket ist der TLS-Handshake abgeschlossen und der verschlüsselte Kanal steht.

Ist das CPM4PE Pairing erfolgreich verlaufen, speichern beide Geräte die empfangenen Root CA Zertifikate dauerhaft in ihrem gesicherten Speicher und der CPM4PE Modus erlischt automatisch. Beim nächsten Einstecken sind beide Root CAs bekannt und der Pairing-Schritt entfällt.

Alle weiteren Nachrichten werden über das Vehicle to Grid Transport Protocol (V2GTP) übertragen. V2GTP ist das Trägerprotokoll für alle ISO 15118-20 Applikationsnachrichten und läuft vollständig innerhalb des verschlüsselten TLS-Kanals. Jede V2GTP Nachricht beginnt mit einem fest definierten 8-Byte Header der von beiden Geräten sequentiell geprüft wird.

Byte 1 enthält die Protocol Version mit dem Wert 0x01. Byte 2 enthält die Inverse Protocol Version 0xFE — das bitweise Komplement von 0x01 — als Verifizierungsmuster damit der Empfänger sofort erkennen kann ob der Header korrekt übertragen wurde. Bytes 3 und 4 enthalten den Payload Type der definiert um welche Art von Nachricht es sich handelt. Bytes 5 bis 8 enthalten die Payload Length als vorzeichenloser 32-Bit Integer der die Länge des nachfolgenden Nutzdatenbereichs in Bytes angibt.

Der Empfänger prüft den Header strikt sequentiell: zuerst Protocol Version und Inverse Version, dann Payload Type, dann Payload Length. Stimmt die Protocol Version nicht, wird die Nachricht sofort verworfen. Ist der Payload Type unbekannt, wird die Nachricht verworfen. Ist die Payload Length grösser als der Empfänger verarbeiten kann, wird die Nachricht verworfen. Nachrichten mit ungültigem Header werden in allen Fällen stillschweigend verworfen ohne eine Fehlermeldung zu senden.

Der Standard definiert verschiedene Payload Types für verschiedene Nachrichtenkategorien. 0x8001 ist der SAPPayloadID für SupportedAppProtocol Nachrichten. 0x8002 ist der allgemeine Payload Type für ISO 15118-20 Mainstream-Nachrichten. 0x8004 ist der Payload Type für DC-spezifische Nachrichten. 0x8101 ist der Payload Type für Schedule Renegotiation. 0x8102 ist der Payload Type für Metering Confirmation.

Die erste Applikationsnachricht nach dem TLS-Aufbau ist SupportedAppProtocolReq vom Fahrzeug mit dem Payload Type 0x8001. Der Inhalt dieser Nachricht wird nicht als reguläres XML sondern als EXI-kodiertes XML übertragen. EXI steht für Efficient XML Interchange und ist ein Binärkodierungsformat für XML das vom W3C standardisiert ist. Der Standard gibt an dass EXI bis zu 100-mal kompakter sein kann als reguläres XML und dabei gleichzeitig schneller zu verarbeiten ist. Das ist besonders relevant für die ressourcenbeschränkten PLC-Module in Fahrzeugen und Ladestationen die nur begrenzte Rechenleistung und Speicher haben.

Das Fahrzeug listet in SupportedAppProtocolReq alle V2G-Protokollversionen die es beherrscht in Präferenzreihenfolge mit je einem Prioritätswert. Typischerweise: ISO 15118-20 mit Priorität 1, ISO 15118-2 mit Priorität 2, DIN SPEC 70121 mit Priorität 3. Jeder Eintrag enthält den vollständigen Protokoll-Namespace-String, die Versionsnummer Major und Minor sowie den Prioritätswert. Der Standard erlaubt maximal 20 Protokolleinträge in einer einzigen SupportedAppProtocolReq Nachricht.

Die Ladestation liest die Liste, vergleicht sie mit den eigenen Fähigkeiten und wählt das Protokoll mit der höchsten gemeinsamen Priorität aus. Sie antwortet mit SupportedAppProtocolRes und übermittelt den Schema-ID des gewählten Protokolls sowie einen ResponseCode. Ist kein gemeinsames Protokoll vorhanden, antwortet die Ladestation mit dem ResponseCode Failed_NoNegotiation und die Verbindung wird beendet. Ab diesem Moment wissen beide Geräte exakt welches Protokoll für den Rest der Session verwendet wird und alle weiteren Nachrichten werden entsprechend kodiert und interpretiert.

Das Fahrzeug sendet SessionSetupReq als erste ISO 15118-20 Applikationsnachricht nach dem abgeschlossenen TLS-Handshake und der Protokollverhandlung über SupportedAppProtocol. Mit dieser Nachricht eröffnet das Fahrzeug formal die V2G Kommunikationssession.

Die Nachricht enthält die EVCC ID, eine eindeutige Kennung des Fahrzeugs. Der Standard schreibt vor dass die ersten drei Bytes dieser ID den World Manufacturer Identifier nach ISO 3780 enthalten müssen, denselben WMI der auch in der Fahrzeug-Identifikationsnummer (FIN/VIN) verwendet wird. Die restlichen Bytes enthalten eine herstellerspezifische Kennung die das Fahrzeug eindeutig identifiziert. Damit ist die EVCC ID weltweit eindeutig und kann keinem anderen Fahrzeug zugeordnet werden.

Das Fahrzeug sendet im SessionSetupReq Header einen Zeitstempel als bestes Schätzwert der aktuellen SECC Time. Hat das Fahrzeug keine Kenntnis der aktuellen UTC-Zeit, sendet es den Wert null als Zeitstempel. Das ist explizit erlaubt und signalisiert der Ladestation dass das Fahrzeug keine synchronisierte Uhr hat.

Die Ladestation antwortet mit SessionSetupRes und übermittelt drei wichtige Parameter. Erstens die Session ID: eine von der Ladestation generierte eindeutige Kennung für diese Session. Die Session ID besteht aus acht zufälligen Bytes und darf weder null sein noch mit einer aktiven Session ID übereinstimmen. Sie identifiziert diese spezifische Ladesession eindeutig und wird in jede nachfolgende Nachricht im Header eingetragen. Zweitens die EVSE ID: eine eindeutige Kennung des Ladepunkts im Format nach Annex C des Standards, typischerweise bestehend aus Ländercode, Betreiberkennzeichen und Ladepunktnummer. Kann die Ladestation keine EVSE ID liefern, setzt sie den Wert auf ZZ00000. Drittens den initialen SECC-Zeitstempel: dieser definiert den Startzeitpunkt der sogenannten SECC Time, der gemeinsamen Zeitreferenz für alle weiteren Nachrichten in dieser Session.

Die SECC Time ist modelliert nach UNIX Time und wird in Mikrosekunden als vorzeichenloser 64-Bit Integer übertragen. Die Mikrosekundenauflösung ermöglicht präzise Berechnungen von Übertragungslatenzen und die Synchronisation mit hochauflösenden externen Uhren wie Smartmetern. Der Standard schreibt dabei ausdrücklich vor dass SECC Time nie für die Prüfung von Zertifikatsgültigkeiten verwendet werden darf. Das Fahrzeug könnte die SECC Time manipulieren um abgelaufene Zertifikate als gültig erscheinen zu lassen. Für Zertifikatsprüfungen braucht es deshalb eine unabhängige vertrauenswürdige Zeitquelle.

Der Standard schreibt vor dass alle Zeitstempel in nachfolgenden Nachrichten monoton steigend sein müssen, also jede Nachricht einen Zeitstempel haben muss der grösser ist als der vorherige. Die einzige Ausnahme gilt für SessionSetupReq und ServiceDiscoveryReq am Beginn einer neuen Session.

Jede nachfolgende Nachricht beider Geräte muss dieselbe Session ID im Header führen. Weicht die Session ID ab oder sendet das Fahrzeug eine Session ID von null, erkennt die Ladestation dass eine neue Session aufgebaut werden soll und vergibt eine neue ID mit dem ResponseCode OK_NewSessionEstablished.

Der Standard erlaubt zusätzlich das Fortsetzen einer pausierten Session. Wurde eine frühere Session über SessionStopReq mit dem Parameter ChargingSession: Pause unterbrochen statt terminiert, kann das Fahrzeug beim nächsten Einstecken in SessionSetupReq die Session ID dieser pausierten Session mitschicken. Die Ladestation prüft ob sie diese Session kennt, ob das Fahrzeug dasselbe ist wie bei der pausierten Session, und ob die Ladestation dieselbe ist. Dazu berechnet sie einen SHA512-Hash aus Session ID und Vehicle Certificate und vergleicht ihn mit dem gespeicherten Wert. Stimmt alles überein, antwortet sie mit OK_OldSessionJoined und die Session wird fortgesetzt ohne den gesamten Ablauf neu zu durchlaufen. Stimmt etwas nicht überein, wird die pausierte Session gelöscht und eine neue Session mit OK_NewSessionEstablished eröffnet.

Das Fahrzeug sendet zuerst AuthorizationSetupReq. Diese Nachricht enthält ausser dem obligatorischen V2GTP Header und der Session ID keinen weiteren Inhalt. Sie dient ausschliesslich dazu den Autorisierungsprozess formal anzustossen und der Ladestation zu signalisieren dass das Fahrzeug bereit ist die Autorisierungsmethode zu verhandeln.

Die Ladestation antwortet mit AuthorizationSetupRes und teilt mit welche Autorisierungsmethoden sie anbietet. Der Standard kennt genau zwei Methoden: EIM, External Identification Means, und PnC, Plug and Charge. Die Ladestation kann eine oder beide anbieten, maximal aber zwei Einträge im Parameter AuthorizationServices.

Bietet die Ladestation nur EIM an, sendet sie EIM_ASResAuthorizationMode als einzigen Eintrag. Dieser Modus-Parameter ist inhaltlich leer — er signalisiert lediglich dass EIM verfügbar ist. Die eigentliche Identifikation des Nutzers läuft dann ausserhalb des ISO 15118-20 Protokolls über einen separaten physischen Kanal, also RFID-Karte am Lesegerät oder Bestätigung über eine App via Internet. ISO 15118-20 wartet in diesem Fall auf ein externes Signal von der Ladestation dass die Autorisierung erfolgreich war oder abgebrochen wurde.

Bietet die Ladestation PnC an, sendet sie zusätzlich PnC_ASResAuthorizationMode. Dieser Parameter enthält eine von der Ladestation generierte kryptographische Zufallszahl, den sogenannten Challenge-Wert, mit einer Länge von 17 Bytes. Dieser Challenge-Wert hat eine wichtige Sicherheitsfunktion: Er verhindert Replay-Angriffe bei denen ein Angreifer eine frühere gültige Autorisierungsanfrage abfängt und zu einem späteren Zeitpunkt erneut einspielt. Da der Challenge-Wert bei jeder Session neu und zufällig generiert wird, ist eine aufgezeichnete AuthorizationReq Nachricht einer früheren Session wertlos.

Der Standard definiert eine wichtige Einschränkung für private Ladestationen: Eine private Ladestation für V2H die keine OCSP-Antworten für ihre PE-Zertifikatskette liefert darf PnC gar nicht als Autorisierungsmethode anbieten. Sie muss in diesem Fall zwingend nur EIM in AuthorizationSetupRes übermitteln und darf PnC_ASResAuthorizationMode nicht in die Nachricht aufnehmen. Das ist logisch: PnC setzt voraus dass das Contract Certificate des Fahrzeugs gegen eine Root CA geprüft werden kann deren Zertifikat nicht widerrufen wurde. Ohne OCSP gibt es keine Möglichkeit diesen Widerrufsstatus zu prüfen.

Zusätzlich enthält AuthorizationSetupRes den booleschen Parameter CertificateInstallationService. Ist dieser auf true gesetzt, teilt die Ladestation dem Fahrzeug mit dass sie als Kanal für die Installation eines neuen Contract Certificates dienen kann. Das Fahrzeug kann dann über CertificateInstallationReq ein neues Contract Certificate vom Mobilitätsdienstleister anfordern, das über die Ladestation als Mittler geliefert wird.

Das Fahrzeug wählt basierend auf dem Angebot der Ladestation die Autorisierungsmethode und sendet AuthorizationReq mit dem Parameter SelectedAuthorizationService.

Bei EIM sendet das Fahrzeug EIM_AReqAuthorizationMode ohne weiteren Inhalt. Das Fahrzeug wartet nun passiv. Die Ladestation prüft in regelmässigen Abständen ob die externe Autorisierung abgeschlossen ist, also ob die RFID-Karte gelesen und validiert wurde oder ob die App-Bestätigung eingegangen ist. Solange das nicht der Fall ist, antwortet die Ladestation auf AuthorizationReq mit dem ResponseCode OK_WaitForAuthorization. Das Fahrzeug sendet AuthorizationReq in diesem Fall periodisch erneut bis entweder die Autorisierung erfolgreich war, sie abgebrochen wurde oder ein Timeout erreicht wird.

Bei PnC sendet das Fahrzeug PnC_AReqAuthorizationMode mit dem vollständigen Contract Certificate, der gesamten Zertifikatskette bis zur Root CA ausschliesslich des Root CA Zertifikats selbst, sowie einer XML-Signatur über die Nachricht. Diese Signatur wird mit dem privaten Schlüssel des Contract Certificates erstellt und bindet den Challenge-Wert der Ladestation in die Signatur ein. Damit kann die Ladestation prüfen: Erstens ob das Contract Certificate gültig und nicht widerrufen ist. Zweitens ob der Sender tatsächlich im Besitz des privaten Schlüssels des Contract Certificates ist. Drittens ob diese AuthorizationReq Nachricht frisch ist und nicht eine Wiederholung einer früheren Session.

Die Ladestation prüft die XML-Signatur lokal und leitet das Contract Certificate über OCPP ans Backend weiter. Das Backend kontaktiert das Clearing House, typischerweise Hubject, welches das Contract Certificate gegen die Root CA Zertifikate validiert und den Widerrufsstatus über OCSP prüft. Das Ergebnis kommt über OCPP zurück zur Ladestation, die es in AuthorizationRes mit dem ResponseCode OK oder einem entsprechenden Fehlercode ans Fahrzeug übermittelt. Erst nach erfolgreichem AuthorizationRes mit ResponseCode OK geht die Session in die nächste Phase über.

Das Fahrzeug sendet ServiceDiscoveryReq. Diese Nachricht hat keinen spezifischen Inhalt ausser dem Header — sie dient ausschliesslich dazu die Ladestation aufzufordern ihre verfügbaren Dienste bekannt zu geben.

Die Ladestation antwortet mit ServiceDiscoveryRes und einer vollständigen Liste aller Dienste die sie anbietet. Der Standard erlaubt maximal acht Dienste in einer einzigen Antwort. Jeder Dienst wird durch eine eindeutige Service ID, einen Service Namen und einen booleschen Parameter FreeService beschrieben der angibt ob der Dienst kostenlos angeboten wird.

Der Standard definiert folgende Energieübertragungsdienste: AC Charging für einphasiges oder dreiphasiges Wechselstromladen, DC Charging für Gleichstromladen, DC_BPT für bidirektionalen Gleichstrom also Vehicle to Home und Vehicle to Grid über DC, AC_BPT für bidirektionalen Wechselstrom also Vehicle to Home über AC, ACDP für automatisiertes Laden über ein robotergestütztes Verbindungssystem, ACDP_BPT für bidirektionales automatisiertes Laden, sowie WPT für drahtloses induktives Laden. Zusätzlich können Value Added Services wie Internetzugang oder andere Mehrwertdienste angeboten werden. Der Standard weist dabei explizit darauf hin dass die VAS-Anforderungen noch nicht vollständig definiert sind und Implementierer entsprechend Vorsicht walten lassen sollen.

Benötigt das Fahrzeug weitere technische Details zu einem bestimmten Dienst, sendet es ServiceDetailReq mit der Service ID des gewünschten Dienstes. Die Ladestation antwortet mit ServiceDetailRes und einer ServiceParameterList die die spezifischen Parameter dieses Dienstes enthält. Für Energieübertragungsdienste enthält diese Liste typischerweise den unterstützten Steuerungsmodus: Scheduled Control Mode, Dynamic Control Mode oder beide. Im Scheduled Control Mode verhandeln Fahrzeug und Ladestation vorab einen festen Energieplan. Im Dynamic Control Mode passt die Ladestation den Energiefluss laufend an die aktuellen Netzbedingungen an. Welcher Modus gewählt wird hat direkte Auswirkung auf den nachfolgenden ScheduleExchange Schritt. Das Fahrzeug kann für jeden angebotenen Dienst separat ServiceDetailReq senden um alle nötigen Informationen für seine Entscheidung zu sammeln.

Basierend auf den gesammelten Informationen trifft das Fahrzeug seine Wahl und sendet ServiceSelectionReq. Diese Nachricht enthält zwei Parameter. Der erste ist SelectedEnergyTransferService mit der Service ID und der Parameter Set ID des gewählten Energieübertragungsdienstes. Für V2H über DC ist das DC_BPT. Der zweite Parameter ist SelectedVASList, eine optionale Liste aller gewählten Value Added Services mit ihren jeweiligen Service IDs und Parameter Set IDs.

Mit der ServiceSelectionReq ist gleichzeitig der Steuerungsmodus für die gesamte Session festgelegt. Das Fahrzeug wählt beim Dienst entweder Scheduled Control Mode oder Dynamic Control Mode und beide Geräte halten sich für den Rest der Session an diesen Modus. Ein Wechsel des Steuerungsmodus während einer laufenden Session ist nicht vorgesehen.

Die Ladestation prüft ob die gewählten Dienste und Parameter Set IDs mit ihrem Angebot aus ServiceDiscoveryRes übereinstimmen. Stimmen sie überein, bestätigt sie mit ServiceSelectionRes und dem ResponseCode OK. Stimmen sie nicht überein, antwortet sie mit einem Fehlercode und die Session kann nicht fortgesetzt werden. Nach erfolgreichem ServiceSelectionRes sind Dienst und Steuerungsmodus für die gesamte Session verbindlich festgelegt und der Ablauf geht in die ChargeParameterDiscovery und den ScheduleExchange über.

Das Fahrzeug sendet ScheduleExchangeReq und übermittelt darin seine Energieparameter sowie die Rahmenbedingungen für die gewünschte Energieübertragung. Diese Nachricht ist der zentrale Verhandlungsschritt in dem Fahrzeug und Ladestation ihre jeweiligen Möglichkeiten und Bedürfnisse austauschen bevor Strom fliesst.

Der Parameter MaximumSupportingPoints teilt der Ladestation mit wie viele Einträge das Fahrzeug in einem Ladeplan maximal verarbeiten kann. Der Standard schreibt mindestens 12 Einträge als Pflichtminimum vor, erlaubt aber bis zu 1024. Dieser Wert ist wichtig weil die Ladestation im Scheduled Control Mode einen detaillierten Zeitplan mit Leistungswerten zurückschickt und dabei die Kapazität des Fahrzeugs nicht überschreiten darf.

Zusätzlich zu MaximumSupportingPoints übermittelt das Fahrzeug je nach gewähltem Steuerungsmodus unterschiedliche Parameter.

Im Scheduled Control Mode sendet das Fahrzeug Scheduled_SEReqControlMode. Dieser Parameter enthält die gewünschte Abfahrtszeit als SECC Time Stempel falls bekannt, den angestrebten Ladestand beim Abfahrtszeitpunkt, die aktuell verfügbare Batteriekapazität, sowie den aktuellen State of Charge. Der Standard schreibt explizit vor dass wenn keine Abfahrtszeit verfügbar ist das Fahrzeug dieses Element in ScheduleExchangeReq weglassen muss und nicht etwa einen Standardwert einsetzen darf. Die Ladestation berücksichtigt die Abfahrtszeit bei der Erstellung des Ladeplans um sicherzustellen dass der gewünschte Ladestand rechtzeitig erreicht wird.

Im Dynamic Control Mode sendet das Fahrzeug Dynamic_SEReqControlMode. Dieser Parameter enthält ebenfalls den aktuellen State of Charge, die Mindestleistung die das Fahrzeug bezieht oder abgibt, sowie die maximale Leistung in beide Richtungen. Zusätzlich kann das Fahrzeug einen EVTargetEnergyRequest übermitteln der der Ladestation mitteilt wie viel Energie das Fahrzeug insgesamt übertragen möchte, sowie einen EVMaximumEnergyRequest und EVMinimumEnergyRequest als obere und untere Grenzen.

Die Ladestation verarbeitet die Anfrage und antwortet mit ScheduleExchangeRes. Der Parameter EVSEProcessing teilt dem Fahrzeug mit ob die Ladestation die Verarbeitung abgeschlossen hat oder noch rechnet. Hat die Ladestation noch nicht fertig gerechnet, sendet sie EVSEProcessing: Ongoing und das Fahrzeug sendet ScheduleExchangeReq nach einer kurzen Wartezeit erneut. Dieser Polling-Mechanismus erlaubt der Ladestation komplexe Optimierungsberechnungen durchzuführen ohne die Verbindung zu unterbrechen.

Im Scheduled Control Mode enthält ScheduleExchangeRes über Scheduled_SEResControlMode einen oder mehrere ScheduleTuple Einträge. Jeder ScheduleTuple enthält einen PowerSchedule mit Zeitfenstern und den jeweiligen Leistungswerten in Watt, sowie optional einen Preisplan in Form eines AbsolutePriceSchedule mit konkreten Preisen pro Zeitfenster und Währung, oder eines PriceLevelSchedule mit abstrakten Preisniveaus von günstig bis teuer. Der Standard formuliert dazu ausdrücklich: Über Preisinformationen stimuliert die Ladestation das Fahrzeug zu bestimmten Zeitfenstern zu laden oder zu entladen, sie erzwingt aber keine Entscheidung. Das Fahrzeug darf den Ladeplan basierend auf seinen eigenen Präferenzen anpassen, muss dabei aber innerhalb der von der Ladestation vorgegebenen Leistungsgrenzen bleiben.

Beim bidirektionalen Laden über DC_BPT enthält der PowerSchedule auch negative Leistungswerte. Ein negativer Wert bedeutet dass in diesem Zeitfenster Energie aus der Batterie ins Netz oder ins Haus zurückgespeist werden soll. Das Fahrzeug liest diese Werte und weiss damit für jeden Zeitpunkt der Session ob es laden oder entladen soll.

Im Dynamic Control Mode enthält ScheduleExchangeRes über Dynamic_SEResControlMode keine festen Zeitpläne sondern Echtzeit-Vorgaben: die aktuelle Zielleistung, die maximale und minimale erlaubte Leistung sowie optional Preisinformationen. Diese Vorgaben können sich während der laufenden Session jederzeit ändern.

Enthält ScheduleExchangeRes den Parameter GoToPause mit dem Wert TRUE, signalisiert die Ladestation dass aktuell keine Leistung verfügbar ist, zum Beispiel weil das lokale Netz überlastet ist oder keine Solarenergie zur Verfügung steht. Das Fahrzeug wechselt daraufhin direkt in den Standby-Modus über PowerDeliveryReq mit ChargeProgress: Standby ohne zuerst Energie zu übertragen.

Ändert sich die Situation während laufender Energieübertragung grundlegend, kann jederzeit eine Schedule-Neuverhandlung angestossen werden. Die Ladestation sendet dazu eine ScheduleRenegotiation Nachricht mit dem Payload Type 0x8101. Das Fahrzeug unterbricht den laufenden Energiefluss, sendet erneut ScheduleExchangeReq mit aktualisierten Parametern und beide Geräte einigen sich auf einen neuen Plan. Diese Neuverhandlung erfolgt ohne die TLS-Session oder die V2G-Session zu unterbrechen und ist besonders relevant wenn sich die Netzlast plötzlich ändert, Solarenergie wegfällt oder ein anderes Fahrzeug an derselben Infrastruktur angesteckt wird.

Das Fahrzeug sendet PowerDeliveryReq mit dem Parameter ChargeProgress und leitet damit die eigentliche Energieübertragung ein. Dieser Parameter kennt vier definierte Werte die den Zustand der Energieübertragung steuern.

Start signalisiert der Ladestation dass das Fahrzeug bereit ist und die Energieübertragung beginnen soll. Die Ladestation prüft daraufhin ob alle Voraussetzungen erfüllt sind, schaltet die Leistungselektronik frei und bestätigt mit PowerDeliveryRes mit ResponseCode OK. Erst nach diesem Bestätigungssignal fliesst tatsächlich Strom.

Stop signalisiert der Ladestation dass die Energieübertragung beendet werden soll. Die Ladestation trennt die Leistungselektronik und bestätigt. Nach Stop folgt zwingend SessionStopReq um die V2G Session formal zu beenden.

Standby versetzt die Energieübertragung in einen Wartezustand ohne die Session zu beenden. Die physische Verbindung bleibt aufrecht, kein Strom fliesst, aber Fahrzeug und Ladestation bleiben in aktivem Kommunikationskontakt. Der Standby-Modus ist nützlich wenn vorübergehend keine Energie verfügbar ist oder das Energiemanagementsystem eine Pause anordnet. Das Fahrzeug kann jederzeit mit einem neuen PowerDeliveryReq mit ChargeProgress: Start aus dem Standby-Modus zurückkehren.

Pause ermöglicht eine vollständige Unterbrechung der Session ohne Verbindungstrennung. Im Gegensatz zu Stop bleibt die Session erhalten und kann später über SessionSetupReq mit der gespeicherten Session ID wieder aufgenommen werden. Vor dem Senden von PowerDeliveryReq mit ChargeProgress: Pause muss das Fahrzeug zwingend zuerst PowerDeliveryReq mit ChargeProgress: Stop senden.

Für bidirektionales Laden über DC_BPT enthält PowerDeliveryReq zusätzlich den Parameter BPT_ChannelSelection. Der Wert Charging weist die Ladestation an Energie in die Fahrzeugbatterie zu übertragen. Der Wert Discharging weist die Ladestation an Energie aus der Fahrzeugbatterie zu beziehen und ins Hausnetz oder ins öffentliche Netz zurückzuspeisen. Die Ladestation konfiguriert daraufhin ihre bidirektionale Leistungselektronik entsprechend und schaltet sie in die gewünschte Richtung frei.

Zusätzlich zu BPT_ChannelSelection enthält PowerDeliveryReq bei DC_BPT den Parameter EVPowerProfile. Dieser beschreibt den geplanten Leistungsverlauf des Fahrzeugs für die kommende Übertragungsperiode, aufgeteilt in Zeitfenster mit jeweils einem Leistungswert in Watt. Die Ladestation vergleicht dieses Profil mit ihren eigenen Möglichkeiten und den Netzbedingungen. Weicht das Profil des Fahrzeugs von dem ab was die Ladestation liefern oder aufnehmen kann, antwortet sie mit einem entsprechenden ResponseCode und das Profil muss neu verhandelt werden.

Während der laufenden Energieübertragung sendet das Fahrzeug in regelmässigen Abständen MeteringConfirmationReq mit dem Payload Type 0x8102. Diese Nachricht enthält die aktuellen Messwerte der übertragenen Energie: Wirkleistung in Watt, Blindleistung in VAr, Strom in Ampere und die kumulierte übertragene Energiemenge in Wattstunden. Die gesamte Nachricht ist mit einer XML-Signatur gesichert die mit dem privaten Schlüssel des Contract Certificates erstellt wird. Diese kryptographische Signatur macht die Messwerte fälschungssicher und ermöglicht eine manipulationssichere Abrechnung. Ein Dritter der die Messwerte abfängt und verändert kann die Signatur nicht erneuern weil er den privaten Schlüssel des Contract Certificates nicht kennt. Die Ladestation prüft die Signatur und bestätigt mit MeteringConfirmationRes.

Soll die Energieübertragung in den Standby-Modus wechseln, schreibt der Standard einen zwingenden Zwischenschritt vor: Das Fahrzeug muss zuerst den Stromfluss physisch auf null reduzieren, also den tatsächlichen Energiefluss stoppen, bevor es PowerDeliveryReq mit ChargeProgress: Standby sendet. Dieser Zwischenschritt verhindert abrupte Leistungssprünge die die Leistungselektronik beschädigen könnten. Die Ladestation kann einen Standby-Wunsch ablehnen und mit einem entsprechenden Fehler-ResponseCode antworten, woraufhin das Fahrzeug die Energieübertragung direkt mit ChargeProgress: Stop beendet statt in den Standby zu wechseln.

Der Standard definiert ausserdem einen Mechanismus für den Fall dass die Ladestation den Energiefluss aus externen Gründen unterbrechen muss, zum Beispiel weil das lokale Netz überlastet ist oder ein Sicherheitssystem anspricht. In diesem Fall sendet die Ladestation eine ScheduleRenegotiation Nachricht mit dem Payload Type 0x8101 und das Fahrzeug reduziert die Leistung entsprechend oder wechselt in den Standby-Modus. Dieser Mechanismus stellt sicher dass die Ladestation jederzeit die Kontrolle über den Energiefluss behält ohne die Session abrupt zu beenden.

Das Fahrzeug sendet SessionStopReq um die V2G Kommunikationssession formal zu beenden. Diese Nachricht enthält den Parameter ChargingSession der zwei mögliche Werte kennt und damit definiert wie die Session beendet wird.

Der Wert Terminate signalisiert dass die Session vollständig und endgültig beendet wird. Alle gespeicherten Sessiondaten werden gelöscht, die TLS-Verbindung wird geschlossen und die physische Verbindung kann getrennt werden. Eine Wiederaufnahme dieser Session ist nicht möglich. Das ist der normale Weg wenn der Ladevorgang abgeschlossen ist oder der Nutzer das Fahrzeug abstecken möchte.

Der Wert Pause signalisiert dass die Session zwar unterbrochen aber nicht beendet wird. Die Ladestation speichert die Session ID und alle relevanten Sessiondaten. Das Fahrzeug kann zu einem späteren Zeitpunkt über einen neuen SessionSetupReq mit der gespeicherten Session ID die Session fortsetzen ohne den gesamten Kommunikationsablauf von vorne zu durchlaufen. Vor dem Senden von SessionStopReq mit ChargingSession: Pause muss das Fahrzeug zwingend sicherstellen dass die Energieübertragung bereits über PowerDeliveryReq mit ChargeProgress: Stop beendet wurde.

Die Ladestation empfängt SessionStopReq, verarbeitet den ChargingSession Parameter und antwortet mit SessionStopRes und dem ResponseCode OK. Bei Terminate löscht die Ladestation alle Sessiondaten sofort nach dem Senden von SessionStopRes. Bei Pause speichert sie die Sessiondaten für eine definierte Zeit und wartet auf eine mögliche Wiederaufnahme.

Nach dem Austausch von SessionStopReq und SessionStopRes terminieren beide Geräte alle TLS-Sessions die zu dieser V2G-Session gehören. Der Standard formuliert das als hartes Requirement das keine Ausnahmen kennt: "The EVCC shall irretrievably erase/delete/destroy all cryptographic data calculated for all TLS sessions being terminated. This includes all keys calculated for TLS encryption, any data calculated for certificate validation, any TLS session tickets that may have been stored."

Konkret bedeutet das: Alle symmetrischen AES Session Keys die für die Verschlüsselung der TLS-Verbindung verwendet wurden werden unwiderruflich gelöscht. Alle ephemeren ECDH Private Keys die für den Schlüsselaustausch generiert wurden werden gelöscht. Alle OCSP-Antworten und Zertifikatsvalidierungsdaten die während des TLS-Handshakes berechnet wurden werden gelöscht. Alle TLS Session Tickets die für eine mögliche Session-Wiederaufnahme ohne vollständigen Handshake gespeichert wurden werden gelöscht.

Diese unwiderrufliche Löschung aller kryptographischen Daten ist die technische Grundlage für Forward Secrecy. Selbst wenn ein Angreifer zu einem späteren Zeitpunkt in den Besitz des privaten Schlüssels der Ladestation gelangt, kann er damit vergangene Kommunikationssessions nicht entschlüsseln. Die Session Keys existieren nach dem SessionStop auf keinem der beiden Geräte mehr.

Der Standard schreibt für die Ladestation einen präzisen Timing-Ablauf vor. Bei Terminate sendet die Ladestation SessionStopRes und wartet danach zwei Sekunden bevor sie den PLC-Verbindungsabbau über DLINK_TERMINATE.request() initiiert. Diese zwei Sekunden geben dem Fahrzeug Zeit SessionStopRes zu empfangen und seinerseits die kryptographischen Daten zu löschen. Bei Pause wechselt die Ladestation nach SessionStopRes in einen definierten Schlaf- und Aufwachzyklus um auf eine mögliche Wiederaufnahme zu warten.

Nach dem PLC-Verbindungsabbau ändert die Ladestation das PWM-Signal auf dem Control Pilot zurück auf den Leerlaufzustand. Das Fahrzeug erkennt diesen Pegelwechsel und gibt den Stecker zur physischen Trennung frei. Die Steckerverriegelung wird gelöst und der CCS2-Stecker kann sicher abgezogen werden. Der gesamte Kommunikationsablauf nach ISO 15118-20 ist damit vollständig abgeschlossen.