ISO 15118-2:2014

INTERNATIONAL ISO
STANDARD 15118-2
First edition
2014-04-01
Road vehicles — Vehicle-to-Grid
Communication Interface —
Part 2:
Network and application protocol
requirements
Véhicules routiers — Interface de communication entre véhicule et
réseau électrique —
Partie 2: Exigences du protocole d'application et du réseau

Reference number
©
ISO 2014
©  ISO 2014
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized otherwise in any form or by any
means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior written permission.
Permission can be requested from either ISO at the address below or ISO’s member body in the country of the requester.
ISO copyright office
Case postale 56  CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO 2014 – All rights reserved

Contents Page
Foreword . v
Introduction . vi
1  Scope . 1
2  Normative references . 1
3  Terms and definitions . 3
4  Symbols and abbreviated terms . 7
5  Conventions . 8
5.1  Definition of OSI based services . 8
5.2  Requirement structure . 8
5.3  Usage of RFC references . 8
5.4  Notation used for XML schema diagrams . 9
6  Document overview . 9
7  Basic requirements for V2G communication . 11
7.1  General information . 11
7.2  Service primitive concept of OSI layered architecture . 11
7.3  Security concept . 12
7.4  V2G communication states and data link handling . 21
7.5  Data Link Layer . 26
7.6  Network Layer . 26
7.7  Transport Layer . 28
7.8  V2G Transfer Protocol . 32
7.9  Presentation Layer . 36
7.10  Application Layer . 46
8  Application Layer messages . 55
8.1  General information and definitions . 55
8.2  Protocol handshake definition . 56
8.3  V2G Message Definition . 60
8.4  V2G Communication Session and BodyElement Definitions . 62
8.5  Complex data types . 104
8.6  Identification Modes and Message Set definitions . 137
8.7  V2G communication timing . 170
8.8  Message sequencing and error handling . 184
8.9  Request-Response Message Sequence examples . 206
Annex A (informative) Mapping of Part 1 use case elements . 214
Annex B (informative) Mapping of ISO 15118 message element names to SAE J2847/2 terms . 250
Annex C (normative) Schema definition . 254
Annex D (informative) Message examples . 278
Annex E (informative) Application of certificates . 299
Annex F (normative) Certificate profiles . 313
Annex G (informative) Encryption for the Distribution of Secret Keys . 321
Annex H (normative) Specification of Identifiers . 323
Annex I (informative) Message sequencing for renegotiation . 326
Annex J (informative) Overview on XML Signatures . 330
Annex K (informative) Summary of requirements . 334
Bibliography . 341

iv © ISO 2014 – All rights reserved

Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies
(ISO member bodies). The work of preparing International Standards is normally carried out through ISO
technical committees. Each member body interested in a subject for which a technical committee has been
established has the right to be represented on that committee. International organizations, governmental and
non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the
International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are described
in the ISO/IEC Directives, Part 1. In particular the different approval criteria needed for the different types of
ISO documents should be noted. This document was drafted in accordance with the editorial rules of the
ISO/IEC Directives, Part 2 (see www.iso.org/directives).
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO shall not be held responsible for identifying any or all such patent rights. Details of any patent
rights identified during the development of the document will be in the Introduction and/or on the ISO list of
patent declarations received (see www.iso.org/patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation on the meaning of ISO specific terms and expressions related to conformity assessment,
as well as information about ISO's adherence to the WTO principles in the Technical Barriers to Trade (TBT)
see the following URL: Foreword - Supplementary information
The committee responsible for this document is ISO/TC 22, Road vehicles, Subcommittee SC 3, Electrical
and electronic equipment.
ISO 15118-2 was developed in conjunction with IEC TC 69, Electric road vehicles and electric industrial
trucks.
ISO 15118 consists of the following parts, under the general title Road vehicles — Vehicle-to-Grid
Communication Interface:
 Part 1: General information and use-case definition
 Part 2: Network and application protocol requirements
 Part 3: Physical and data link layer requirements

To be published.
Introduction
The pending energy crisis and necessity to reduce greenhouse gas emissions has led the vehicle
manufacturers to a very significant effort to reduce the energy consumption of their vehicles. They are
presently developing vehicles partly or completely propelled by electric energy. Those vehicles will reduce the
dependency on oil, improve the global energy efficiency and reduce the total CO emissions for road
transportation if the electricity is produced from renewable sources. To charge the batteries of such vehicles,
specific charging infra-structure is required.
Much of the standardization work on dimensional and electrical specifications of the charging infrastructure
and the vehicle interface is already treated in the relevant ISO or IEC groups. However the question of
information transfer between the EV and the EVSE has not been treated sufficiently.
Such communication is necessary for the optimization of energy resources and energy production systems so
that vehicles can recharge in the most economical or most energy efficient way. It is also required to develop
efficient and convenient billing systems in order to cover the resulting micro-payments. The necessary
communication channel may serve in the future to contribute to the stabilization of the electrical grid as well as
to support additional information services required to operate electric vehicles efficiently and economically.
vi © ISO 2014 – All rights reserved

INTERNATIONAL STANDARD ISO 15118-2:2014(E)

Road vehicles — Vehicle-to-Grid Communication Interface —
Part 2: Network and application protocol requirements
1 Scope
This part of ISO 15118 specifies the communication between battery electric vehicles (BEV) or plug-in hybrid
electric vehicles (PHEV) and the Electric Vehicle Supply Equipment. The application layer message set
defined in this part of ISO 15118 is designed to support the energy transfer from an EVSE to an EV. ISO
15118-1 contains additional use case elements (Part 1 Use Case Element IDs: F4 and F5) describing the
bidirectional energy transfer. The implementation of these use cases requires enhancements of the
application layer message set defined herein. The definitions of these additional requirements will be subject
of the next revision of this International Standard.
The purpose of this part of ISO 15118 is to detail the communication between an EV (BEV or a PHEV) and an
EVSE. Aspects are specified to detect a vehicle in a communication network and enable an Internet Protocol
(IP) based communication between EVCC and SECC.

Key
1 Scope of ISO/IEC FDIS 15118-2:2013(E)
2 Message definition considers use cases defined for communication between SECC to SA
Figure 1 — Communication relationship among EVCC, SECC and secondary actor
This part of ISO 15118 defines messages, data model, XML/EXI based data representation format, usage of
V2GTP, TLS, TCP and IPv6. In addition, it describes how data link layer services can be accessed from a
layer 3 perspective. The Data Link Layer and Physical Layer functionality is described in ISO 15118-3.
2 Normative references
The following documents, in whole or in part, are normatively referenced in this document and are
indispensable for its application. For dated references, only the edition cited applies. For undated references,
the latest edition of the referenced document (including any amendments) applies.
ISO 3166-1, Codes for the representation of names of countries and their subdivisions ― Part 1: Country
codes
ISO 15118-1, Road vehicles ― Vehicle to grid communication interface ― Part 1: General information and
use-case definition
IEC 61851-1, Electric vehicle conductive charging system ― Part 1: General requirements (Ed 2.0 2010)
IEC 61851-22, Electric vehicle conductive charging system - Part 22: AC electric vehicle charging station
IEC CDV 61851-23, Electric vehicle conductive charging system - Part 23: D.C. electric vehicle charging
station (Ed 1.0 2012)
IEC 62196, Plugs, socket-outlets, vehicle connectors and vehicle inlets - Conductive charging of electric
vehicles
W3C EXI 1.0, Efficient XML Interchange (EXI) Format 1.0, W3C Recommendation (March 2011)
W3C XML Signature Syntax and Processing Version 1.1, - W3C Recommendation (April 2013)
IETF RFC 768, User Datagram Protocol (August 1980)
IETF RFC 793, Transmission Control Protocol - DARPA Internet Program - Protocol Specification (September
1981)
IETF RFC 1981, Path MTU Discovery for IP version 6 (August 1996)
IETF RFC 2460, Internet Protocol, Version 6 (IPv6) Specification (December 1998)
IETF RFC 6960, X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP (June
2013)
IETF RFC 3122, Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification (June 2001)
IETF RFC 3315, Dynamic Host Configuration Protocol for IPv6 (DHCPv6) (July 2003)
IETF RFC 3484, Default Address Selection for Internet Protocol version 6 (IPv6) (February 2003)
IETF RFC 6582, The NewReno Modification to TCP's Fast Recovery Algorithm (April 2012)
IETF RFC 4291, IP Version 6 Addressing Architecture (February 2006)
IETF RFC 4429, Optimistic Duplicate Address Detection (DAD) for IPv6 (April 2006)
IETF RFC 4443, Internet Control Message Protocol (ICMP v6) for the Internet Protocol version 6 (IPv6)
specification (March 2006)
IETF RFC 4861, Neighbor Discovery for IP version 6 (IPv6) (September 2007)
IETF RFC 4862, IPv6 Stateless Address Autoconfiguration (September 2007)
IETF RFC 5095, Deprecation of Type 0 Routing Headers in IPv6 (December 2007)
IETF RFC 5116, An Interface and Algorithms for Authenticated Encryption (January 2008)
IETF RFC 5234, Augmented BNF for Syntax Specifications: ABNF (January 2008)
IETF RFC 5246, The Transport Layer Security (TLS) Protocol Version 1.2 (August 2008)
IETF RFC 5280, Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL)
Profile (May 2008)
IETF RFC 5289, TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter Mode (GCM)
(August 2008)
IETF RFC 5480, Elliptic Curve Cryptography Subject Public Key Information (March 2009)
IETF RFC 5722, Handling of Overlapping IPv6 Fragments (December 2009)
IETF RFC 6066, Transport Layer Security (TLS) Extensions: Extension Definitions (January 2011)
IETF RFC 6106, IPv6 Router Advertisement Options for DNS Configuration (November 2010)
IETF RFC 6961, The Transport Layer Security (TLS) Multiple Certificate Status Request Extension (June
2013)
2 © ISO 2014 – All rights reserved

IANA Service&PortRegistry, Service Name and Transport Protocol Port Number Registry [viewed 2011-01-
16], Available from: http://www.iana.org/assignments/service-names-port-numbers/service-names-port-
numbers.xml
NIST FIPS PUB 180-4: Secure Hash Standard (SHS) (March 2012)
NIST Special Publication 800-56A: Recommendation for Pair-Wise Key Establishment Schemes Using
Discrete Logarithm Cryptography (Revised) (March 2007)
NIST Special Publication 800-38A: Recommendation for Block Cipher Modes of Operation - Methods and
Techniques (2001)
3 Terms and definitions
For the purposes of this document, the terms in ISO 15118-1 and the following apply.
3.1
Basic Charging
BC
charging phase during a charging session controlled by IEC 61851-1 only
3.2
charging limits
set of physical constraints (e.g. voltage, current, energy, power) that is negotiated during a V2G
Communication Session for a charging session
3.3
Communication Setup Timer
Timer monitoring the time from plug-in until the Session Setup message
3.4
Contract Certificate
certificate issued to EVCC either by V2G Root CA or by Sub-CA, which is used in XML Signatures in
application layer so that SECC or secondary actor can verify the Contract issued to the EVCC and signatures
issued by the EVCC
3.5
CP State
Control Pilot (Vehicle) State according to IEC 61851-1 signalled on Control Pilot Line
3.6
credentials
anything that provides the basis for confidence, belief, credit, etc.
EXAMPLE Examples include certificates, passwords, user names etc.
3.7
Data Link Setup
setup phase for establishing the data link
Note 1 to entry: Entry Condition: Any valid control pilot signal according to IEC 61851-1; Exit Condition: D-
LINK_READY.indication(DLINKSTATUS=LinkEstablished).
3.8
Distinguished Encoding Rules = ASN-1 encoding rule
DER
method for encoding a data object, such as an X.509 certificate, to be digitally signed or to have its signature
verified
3.9
global address
IP address with unlimited scope
3.10
High Level Communication Charging
HLC-C
charging phase during a charging session controlled by ISO 15118
3.11
link-local address
IP address with link-only scope that can be used to reach neighbouring interfaces attached to the same link
3.12
Identification Mode
mandatory and optional messages and parameters with respect to charging scenarios using External
Identification Means (EIM) and charging scenarios using Plug and Charge (PnC) for identification
Note 1 to entry: An Identification Mode covers a set of similar charging scenarios for a specific identification means.
3.13
(IP) address
IP-layer identifier for an interface or a set of interfaces
3.14
Maximum Transfer Unit
MTU
maximum size (in bytes) of the largest protocol data unit that the Data Link Layer that can be pass onwards
3.15
Message Set
set of mandatory V2G messages and parameters for the EVCC or SECC covering one or multiple use case
elements
3.16
Message Timer
Timer monitoring the exchange of a Request-Response-Pair
3.17
network segment
collection of devices that can exchange data on Data Link Layer level directly via Data Link Addresses
EXAMPLE Ethernet: all devices which can see each other via MAC addresses.
3.18
node
device that implements IPv6
3.19
OEM Provisioning Certificate
certificate issued to the EVCC, so that a Contract Certificate can be securely requested and received from a
secondary actor
3.20
Performance Time
non-functional timing requirement defining the time a V2G Entity shall not exceed when executing or
processing certain functionality
Note 1 to entry: This is a fixed time value.
4 © ISO 2014 – All rights reserved

3.21
private environment
area with (physical) access limited to a small number of vehicles (EVs), which may be a private parking
garage or a garage / parking lot of a company with its own EV fleet, where one or several private wall-box(es)
are used instead of public charging stations as EVSE, and where in order to keep the private wall-box simple
and cheap in production and operation it is allowed to stay offline permanently, which allows a private wall-box
to use leaf certificates with a longer maximum validity than allowed for public charging stations and using a
private root certificate which is different to the V2G root certificates and which has to be installed into each EV
that is allowed to charge within this specific private environment, resulting in a limited number of EVs
belonging to one private environment, the difference to a “trusted environment” being that in a (pure; i.e. not
additionally “trusted”) private environment TLS and the corresponding data encryption at connection level is
always used, and solely certificate handling is simplified for the private wall-box (EVSE) since it may stay
offline permanently, resulting in unrestricted certificate validity periods, shorter certificate chain length, omitting
OCSP, and an additional “pairing mode”
3.22
Identification Mode
group of mandatory and optional Message Sets covering a set of similar charging scenarios for a specific
identification means
3.23
renegotiation
messaging for updating the agreement on the charging schedule between EV and EVSE during a V2G
Communication Session by retransmitting the parameters SASchedule and ChargingProfile
3.24
Request-Response Message Pair
request message and the corresponding response message
3.25
Request-Response Message Sequence
predefined sequence of Request-Response Message Pairs
3.26
SDP Client
V2G Entity that uses the SDP server to get configuration information about the SECC to be able to access the
SECC
3.27
SDP Server
V2G Entity providing configuration information for accessing the SECC
3.28
SECC Certificate
certificate issued to SECC either by V2G Root CA or by Sub-CA, which is used in TLS so that the EVCC can
verify the authenticity of the SECC
3.29
Sequence Timer
Timer monitoring a Request-Response Message Sequence
3.30
Sub-CA
subordinate certificate authority who issues SECC Certificates and/or Contract Certificates on behalf of the
V2G Root CA
Note 1 to entry: The ability of issuing the certificates are delegated from V2G Root CA, and V2G Root CA can revoke the
Sub-CA at any time.
3.31
Sub-CA Certificate
certificate issued to Sub-CA
3.32
TCP_DATA
socket/interface for data transfer based on TCP connection
3.33
Timeout
timing requirement defining the time a V2G Entity monitors the communication system for a certain event to
occur
Note 1 to entry: If the specified time is exceeded the respective V2G Entity initiates the related error handling. This is a
fixed time value.
3.34
Timer
device or piece of software used in an implementation for measuring time.
Note 1 to entry: Depending on the specific use case a timer is used to trigger certain system events as well.
3.35
Trusted Environment
closed user group (e. g. members of car sharing system) with some pre-distributed token for access to the
SECC charging service (e.g. key to home garage, RFID token for car sharing), which is something where a
person or instance is responsible for, for example (not limited to) a person with its home garage, a car sharing
operator or a taxi operator
3.36
V2G Charging Loop
V2G messaging phase for controlling the charging process by ISO 15118
3.37
V2G Communication Session
association of two specific V2G Entities for exchanging V2G messages
3.38
V2G Entity
primary actor participating in the V2G communication using a mandatory or optional transmission protocol
defined by ISO 15118-2
3.39
V2G Message
message exchanged on application layer
Note 1 to entry: Refer to Clause 8 Application Layer messages.
3.40
V2G Setup
setup phase for V2G messaging
Note 1 to entry: Entry Condition: D-LINK_READY.indication(DLINKSTATUS=LinkEstablished); Exit Condition:
PowerDeliveryReq with ChargeProgress equals Start or Stop.
3.41
V2G Transfer Protocol
communication protocol to transfer V2G messages between two V2GTP entities
6 © ISO 2014 – All rights reserved

3.42
V2GTP Entity
V2G Entity supporting the V2G Transfer Protocol
3.43
V2G Root CA
certificate Authority (CA) who issues Contract Certificates and/or SECC Certificates, or who delegates ability
to issue such Certificates to Sub-CA
3.44
V2G Root Certificate
certificate issued to V2G Root CA
4 Symbols and abbreviated terms
For the purposes of this document, the following abbreviated terms apply:
BEV Battery Electric Vehicle
CA Certificate Authority
CRL Certificate Revocation List
DH Diffie Hellman
DER Distinguished Encoding Rules
ECDSA Elliptic Curve Digital Signature Algorithm
EMAID E-Mobility Account Identifier
EMOCH E-Mobility Operator Clearing House (see also 15118-1, [12])
EV Electric Vehicle
EVCC Electric Vehicle Communication Controller
EVSE Electric Vehicle Supply Equipment
EXI Efficient XML Interchange
OCSP Online Certificate Status Protocol
OEM Original Equipment Manufacturer
NACK Negative Acknowledgement
PDU Protocol Data Unit
PHEV Plug-in Hybrid Electric Vehicle
PKI Public Key Infrastructure
PLC Power Line Communication
PnC Plug and Charge
SA secondary actor
SDP SECC Discovery Protocol
SDU Service Data Unit
SECC Supply Equipment Communication Controller
TCP Transmission Control Protocol
V2G Vehicle to Grid Communication
V2G CI Vehicle-to-Grid Communication Interface
V2GTP V2G Transfer Protocol
UDP User Datagram Protocol
XML Extensible Markup Language
5 Conventions
5.1 Definition of OSI based services
ISO 15118-2 is based on the conventions discussed in the OSI Service Conventions (refer to ISO 10731) as
they apply for the individual layers specified in this document.
This part of ISO 15118-2 describes requirements applicable to layer 3-7 according to the OSI layered
architecture.
5.2 Requirement structure
This document uses a requirement structure i.e. a unique number identifies each individual requirement
included in this document. This requirement structure allows for easier requirement tracking and test case
specification. The following format is used:
"[V2G"Y"-"XXX"]" requirement text Where:
 "V2G" represents the ISO 15118 set of standards,
 Y represents the document part of the ISO 15118 document set
 XXX represents the individual requirement number and
 "requirement text" includes the actual text of the requirement.
EXAMPLE [V2G2-000] This shall be an example requirement.
5.3 Usage of RFC references
When RFCs are referenced all “shall/ shall not” requirements are mandatory.
[V2G2-001] In this document, if a referenced RFC has been updated by one or several RFC, the update is
fully applicable.
[V2G2-002] If an update or part of an update applicable to an RFC referenced herein is not compatible with
the original RFC or the implementation described by this standard the update shall not apply.
[V2G2-003] All published Errata, for the ISO 15118 referenced RFCs, are fully applicable in this standard.
8 © ISO 2014 – All rights reserved

5.4 Notation used for XML schema diagrams
This standard makes use of XML as a description format for V2G messages. For details with regards to the
XML schema diagram notation used in this document refer to Altova XMLSpy Manual.
Allowing for an easy way to distinguish the types used for the XML schema definitions in this standard
following naming conventions apply:
 complex type use capitalized first letters
 simple types use non capitalized first letters
6 Document overview
Figure 2 describes the organization of the different ISO 15118 documents and the usage of the subclauses ,
according to the OSI layered architecture.
As indicated by the bold framed shapes this Part of ISO 15118 defines requirements applicable to layers 3-7
according to the OSI layered architecture. Layer 1 and 2 requirements including the V2G Standardized
Service Primitive Interface are specified in Part 3 of this standard.
Vehicle to Grid Communication
ISO/IEC 15118-1
Application Layer Messages (8)
OSI Layer 7
SDP(7.10.1)
Application
EXI (7.9)
OSI Layer 6
Presentation
ISO/IEC 15118-2
V2GTP (7.8)
OSI Layer 5
Session
TCP,UDP,TLS (7.7)
OSI Layer 4
Transport
IP,ICMP,SLAAC (7.6)
OSI Layer 3
Network
V2G Standardized Service Primitive Interface
OSI Layer 2
Data Link
ISO/IEC 15118-3
OSI Layer 1
Physical
Key
OSI Layers and applicable requirements described in this Part of ISO 15118
OSI Layers and applicable requirements defined in other Parts of ISO 15118
Figure 2 — Vehicle to Grid Communication document overview
10 © ISO 2014 – All rights reserved

7 Basic requirements for V2G communication
7.1 General information
This Part of ISO 15118 describes the realization of the V2G use cases elements defined by Part 1 of this
standard.
7.2 Service primitive concept of OSI layered architecture
7.2.1 Overview
This subclause explains how the OSI layered architecture is applied for the purpose of this document. It is
intended to provide simple means for describing the interfaces between the individual communication protocol
layers required by this document and furthermore allows for defining timing requirements more precisely.
Services are specified by describing the service primitives and parameters that characterize a service. This is
an abstract definition of services and does not force a particular implementation.
Figure 3 depicts a simplified view of OSI layer interaction sufficient to understand the OSI layered architecture
principles for the context of this document.

Key
PDUX: Protocol Data Unit of network entity x
PCI: Protocol Control Information
SDU : Service Data Unit of network entity x
X
Figure 3 — OSI layered architecture principles
When a layer i+1 instance of V2G Entity m exchanges data with a layer i+1 instance of V2G Entity m+1 each
instance uses services of an instance of layer i. A service is defined as a set of service primitives.
7.2.2 Syntax of service primitives
Service primitives are described with the following syntax:
[Initial of layer]-[NAME].[primitive type](parameter list)
 whereas [initial of layer] is one out of the following seven:
[Physical, Data Link, Network, Transport, Session, Presentation, Application]
 whereas [NAME] is the name of the primitive
EXAMPLE Typical examples for [Name] are CONNECT, DISCONNECT, DATA; other names are used in this Part
and Part 3 of this standard.
 whereas [primitive type] is one out of the following four:
[request, indication, response, confirmation]
 whereas (parameter list) includes a list of parameters separated by comma the user of the service is
supposed to provide when using the respective service primitive; optional parameters are marked with
brackets "[.]".
NOTE In this document, the primitive type ".indication" always indicates an event asynchronously to the upper layer.
7.3 Security concept
7.3.1 Call Flows (Flow Charts)
The following two figures (Figure 4 and Figure 5) depict the principal approach for the semi-online and the
online case from a security point of view, showing the necessary security services applied as well as an
abstract view on the different data necessary for the operation.
The full data flow / sequence charts can be found in subclause 8.8 of this document. In these overview figures
only the security relevant information shall be highlighted.
The security concept provides a basic transport based protection mechanism. For certain scenarios, the
usage of Transport Layer Security (TLS) for the transport communication between EVCC and SECC is
mandated. For some other scenarios, the usage of TLS is optional. Specific messages are protected on
application layer (XML-messages), if data has to be protected on the way from or to a secondary actor, or if
the protection has to last longer than the existence of the TLS channel. Also the concept is independent from
any further protection mechanisms on lower levels than layer 3 in the OSI layer model.
Figure 4 shows an example use case for a semi-online connection for a Plug and Charge scenario:
In this Plug-and-Charge example, all TCP/IP based communication is protected using a unilaterally
authenticated TLS channel between the two peers. (Note: TLS is not mandatory for certain Identification
Modes other than the Plug-and-Charge Identification Mode). All communication is terminated at the SECC.
The meter reading is cyclically signed by the vehicle to support the billing process (refer to 8.4.3.13.1). This
information may be used for billing if local regulations permit it. The EVSE provides the charging records,
containing the signed meter reading to the backend for further processing.
NOTE 1 The communication between SECC and SA in Figure 4 is shown for informational purpose only and not
intended to specify a particular message sequence.
12 © ISO 2014 – All rights reserved

Figure 4 — Example for semi-online communication (1 of 2)
Figure 5 shows an example for an online Plug and Charge use case:
As in the semi-online case, in this Plug-and-Charge example, all TCP/IP based communication is protected
using a unilaterally authenticated TLS channel between the two peers. (Note: TLS is not mandatory for certain
Identification Modes other than the Plug-and-Charge Identification Mode). Some of the information provided
by the vehicle may need to be sent to the SA for further processing, like the eMAID or the vehicles credentials
to be able so sign the tariff information. The EVCC calculates a charging profile (refer to subclause 8.4.3.9.2)
and sends it to the SECC. The SECC may send it to SA systems like Smart Grid or Demand Clearing House.
The further process is similar to the semi-online case with the exception, that the final charging data can be
directly submitted to the SA. It is assumed that the SECC will also use a secure transport connection to the
SA, although the security of the vehicle communication to the SA is secured on application layer.
NOTE 2 The communication between SECC and SA in Figure 5 is shown for informational purpose only and not
intended to specify a particular message sequence.
14 © ISO 2014 – All rights reserved

EVCC SECC Secondary Actor (SA)
seq Begin of charging process
seq Communication Setup
seq Establish IP-based Connection
seq Establish TLS Session
Client Hello()
Server Hello()
EVSE Certificate with
V2G Root Certificate
key and chain needed
needed to verify EVSE
... continue according to subclause 7.7.3
certificate as TLS server
supportedAppProtocolReq()
supportedAppProtocolRes()
... continue according to subclause 8.8
seq Identification, Authentication and Authorization
PaymentDetailsReq()
Contract Certificate with key
PaymentDetailsRes()
and chain needed
AuthorizationReq()
V2G Root Certificate
AuthorizationRes() needed
seq Target Setting and Charge Scheduling
seq Request individual tariff tables
ChargeParameterDiscoveryReq()
MO Sub-CA 2 Certificate
ChargeParameterDiscoveryRes()
with key needed
Online request for individual tariff
tables for EMAID
... continue according to subclause 8.8
(outside socpe of this specification)
loop Charge control and Re-scheduling
ChargingStatusReq()
ChargingStatusRes()
opt Metering
MeteringReceiptReq()
MeteringReceiptRes()
Contract Certificate with key
needed
seq End of charging process
... finish according to subclause 8.8
seq Forward Receipt (PnC only)
online exchange of signed V2G Root Certificate
needed
meter receipt data for Plug'n Charge profile
(outside scope of this standard)

Figure 5 — Example for online communication
There are further use cases where security mechanism are needed on application layer. These are the initial
enrolment of contract keys and certificate as well as the update of the certificate. In this case vehicle specific
OEM keys are used. Those mechanisms are described in Annex 0. An overview on all needed certificates can
be found in Annex F.
7.3.2 Certificate and key management
The call flows shown in subclause 7.3.1 require the existence of multiple certificates to be applied for the
different security layers. There are SECC Certificates used in the TLS layer for EVCC to authenticate SECC.
There are Contract Certificates used at the application layer to authenticate against an SECC and/or
secondary actor. There are V2G Root Certificates and possibly Sub-CA Certificates which certify SECC
Certificates and Contract Certificates.
Separate from above certificates, there may be OEM Root Certificates and OEM Provisioning Certificates to
be used for installing and updating Contract Certificates.
For an overview over all possible certificate profiles, see Annex F.
[V2G2-004] Each V2G Entity shall use X.509v3 certificates due to the need of extensions for storing EC-
parameters. For details refer to IETF RFC 5280.
Table 1 shows what fields a X.509v3-certificate consists of:
Table 1 — Basic Certificate Fields
Certificate field Description
Version Version of certificate (for 15118 shall be v3 = 0x2)
Serial number Unique number of certificate (within the domain of the issuer)
Signature algorithm Used signature algorithm
Issuer Entity, who has issued and signed the certificate
Validity period Time period, in which the certificate is valid
Subject Entity, to which the certificate is issued
Public key Public key corresponding to a private key
Issuer UID Optional issuer unique identifier
Subject UID Optional subject unique identifier
Extensions Optional (see Table 2)
Signature Signature of the certificate generated by the issuer
NOTE 1 For those not familiar with the various fields refer to IETF RFC 5280.
Depending on the use case additional information may be included using so called certificate extensions.
Table 2 summarizes common certificate extensions.
16 © ISO 2014 – All rights reserved

Table 2 — Certificate extension examples
Certificate extensions Description
Usage of the corresponding private key (e.g. Digital Signature,
Key usage
Non-Repudiation, Key Encipherment, …)
Further specification of key usage using OIDs, e.g.:
Server Authentication (1.3.6.1.5.5.7.3.1)
Client Authentication (1.3.6.1.5.5.7.3.2)
Note, sometimes here also the following values are encoded:
Netscape SGC (1.3.6.1.4.1.311.10.3.3)
Extended Key Usage
Microsoft SGC (2.16.840.1.113730.4.1)
SGC stands for Server Gated Crypto and indicated that the server
may also use strong cryptography for the connection with the
client’s browser. This extension was used at the time of strong
crypto export control to enable financial web site to provide
appropriate protection of the data transfer.
CRL distribution point Location to retrieve certificate revocation lists
OCSP Location to retrieve OCSP response (exists only for SubCA
certificates). Refer to IETF RFC 6960 for details.
Authority information Additional authorization information
Subject alternative name Alternative names of the entity
Basic constraint = CA True if the certificate is V2G Root Certificate or SubCA certificate.
NOTE 2 For those not familiar with OIDs, e.g. 1.3.6.1.5.5.7.3.1, refer to: Object Identifier (OID) Repository.
[V2G2-005] Each V2G Entity shall support Hash-operation SHA-256 (signature process) according to NIST
FIPS PUB 180-4 (for Part 1 Use Case Element ID: F1).
[V2G2-006] For each V2G Entity the signature operation shall be ECC-based using elliptic curves
(secp256r1[SECG notation]) with signature algorithm ECDSA (for Part 1 Use Case Element
ID: F1).
[V2G2-007] The key length for ECC based asymmetric cryptography each V2G Entity uses shall be 256 bit.
[V2G2-885] All certificate validations shall be carried out in conformance with RFC 5280. The EVCC and
the SECC may cache certificate validation results during one charging session.
[V2G2-926] The certificate extensions mentioned in Annex F shall be supported. Deviations are specified
wher
e necessary.
[V2G2-925] A leaf certificate shall be treated as invalid, if the trust anchor at the end of the chain does not
match the specific root certificate required for a certain use, or if the required Domain
Component value is not present.
[V2G2-910] The EVCC should implement a mechanism to check the validity periods of certificates and
OCSP responses.
[V2G2-886] The EVCC may choose the accuracy of its time source at its own discretion, but it shall respect
the chosen accuracy when using the time source. The accuracy should be at least one day.
NOTE 3 This requirement theoretically even allows for precisions of e.g. one year. The implementer should carefully
weigh the security consequences of such a decision.
NOTE 4 If a TLS connection is built up successfully, the EVCC might use the time from a EVSETimeStamp field sent
from the SECC through said connection for synchronization of its internal clock, however the implementer should carefully
weigh the security consequences of such a decision.
[V2G2-887] The SECC shall ensure that at any point in time it has a certificate for itself, which is valid for at
least one more hour.
7.3.3 Number of root certificates and root validity, certificate depth and size
[V2G2-008] Each EVCC shall support at least one V2G Root Certificate.
[V2G2-877] Each SECC shall support the storage of at least 10 V2G Root Certificates.
NOTE 1 Due to overlapping validity periods, up to 10 concurrently valid certificates may exist. See V2G2-012
NOTE 2 A number of five (5) V2G Root Certificates is strongly recommended. However, just one is mandatory. Having
less than 5 or just 1 certificate brings a risk to the OEM. Having just 1 V2G Root Certificate allows the car to charge just in
that one region. The OEM will need to state in the manual and during offering the car to customers, that this car charges
only in its "home" region. If an OEM is afraid, that 5 V2G Root Certificates are not sufficient to cover the "usage radius" of
its cars, OEM is free to provide more root certificate storage locations.
NOTE 3 It is assumed that the V2G Root Certificates applied on OSI layer 4 are also used on OSI layer
...