ETSI TS 101 556-3 V1.1.1 (2014-10)

Intelligent Transport Systems (ITS); Infrastructure to Vehicle Communications; Part 3: Communications system for the planning and reservation of EV energy supply using wireless networks

DTS/ITS-0010031

General Information

• Status: Published
• Publication Date: 19-Oct-2014
• Technical Committee: ITS WG1 - Application Requirements and Services
• Current Stage: 12 - Completion
• Due Date: 14-Nov-2014
• Completion Date: 20-Oct-2014

Standards Content (Sample)

ETSI TS 101 556-3 V1.1.1 (2014-10)






TECHNICAL SPECIFICATION
Intelligent Transport Systems (ITS);
Infrastructure to Vehicle Communications;
Part 3: Communications system for the planning and
reservation of EV energy supply using wireless networks

---------------------- Page: 1 ----------------------
2 ETSI TS 101 556-3 V1.1.1 (2014-10)



Reference
DTS/ITS-0010031
Keywords
Charging, ITS
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

Important notice
The present document can be downloaded from:
http://www.etsi.org
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the only prevailing document is the
print of the Portable Document Format (PDF) version kept on a specific network drive within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
http://portal.etsi.org/tb/status/status.asp
If you find errors in the present document, please send your comment to one of the following services:
http://portal.etsi.org/chaircor/ETSI_support.asp
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying
and microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.

© European Telecommunications Standards Institute 2014.
All rights reserved.

TM TM TM
DECT , PLUGTESTS , UMTS and the ETSI logo are Trade Marks of ETSI registered for the benefit of its Members.
TM
3GPP and LTE™ are Trade Marks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
GSM® and the GSM logo are Trade Marks registered and owned by the GSM Association.
ETSI

---------------------- Page: 2 ----------------------
3 ETSI TS 101 556-3 V1.1.1 (2014-10)
Contents
Intellectual Property Rights . 4
Foreword . 4
Modal verbs terminology . 4
1 Scope . 5
2 References . 5
2.1 Normative references . 5
2.2 Informative references . 5
3 Definitions and abbreviations . 6
3.1 Definitions . 6
3.2 Abbreviations . 6
4 Overview of the recharging spot reservation procedure . 6
4.1 Reservation process in the context of related electro-mobility standards . 6
4.2 Identification of the reservation server . 8
5 Protocol procedures . 9
5.1 Overview of the protocol operation . 9
5.2 Pre-Reservation procedure . 10
5.3 Reservation procedure . 11
5.4 Cancellation procedure . 12
5.5 Update procedure . 12
6 Reservation modification issues . 13
7 Tabular description of protocol messages . 13
7.1 Pre-Reservation Request and Response message formats . 13
7.2 Reservation Request and Response message formats. 14
7.3 Cancellation Request and Response message formats . 15
7.4 Update Request and Response message formats . 16
8 Protocol encoding . 16
Annex A (normative): ASN.1 syntax . 17
History . 20

ETSI

---------------------- Page: 3 ----------------------
4 ETSI TS 101 556-3 V1.1.1 (2014-10)
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (http://ipr.etsi.org).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Foreword
This Technical Specification (TS) has been produced by ETSI Technical Committee Intelligent Transport Systems
(ITS).
The present document is part 3 of a multi-part deliverable covering the infrastructure to Vehicle Communication as
identified below:
Part 1: "Electric Vehicle Charging Spot Notification Specification";
Part 2: "Communication system specification to support application requirements for Tyre Pressure Monitoring
System (TPMS)";
Part 3: "Communications system for the planning and reservation of EV energy supply using wireless
networks".
Modal verbs terminology
In the present document "shall", "shall not", "should", "should not", "may", "may not", "need", "need not", "will",
"will not", "can" and "cannot" are to be interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms
for the expression of provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.
ETSI

---------------------- Page: 4 ----------------------
5 ETSI TS 101 556-3 V1.1.1 (2014-10)
1 Scope
The present document specifies wireless application protocols and messages supporting the discovery of offered
services (completing related discovery protocols), charging spot reservation (and possible renegotiation), pre-payment
of the service reservation in the vehicle (involving pre-payment support or contract validation), and application-level
logical pairing of the Electric Vehicle to a selected charging spot. Requirements regarding the underlying transport and
network layer services are also defined.
2 References
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
reference document (including any amendments) applies.
Referenced documents which are not found to be publicly available in the expected location might be found at
http://docbox.etsi.org/Reference.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
2.1 Normative references
The following referenced documents are necessary for the application of the present document.
[1] ISO/IEC 15118-2: "Road vehicles - Vehicle-to-Grid Communication Interface - Part 2: Network
and application protocol requirements".
[2] DIN SPEC 91286:2011: "Electric mobility - Schemes of identifiers for E-Roaming - ContractID
and Electric Vehicle Supply Equipment ID".
[3] IETF RFC 5246: "The Transport Layer Security (TLS) Protocol Version 1.2".
[4] IETF RFC 6347: "Datagram Transport Layer Security Version 1.2".
2.2 Informative references
The following referenced documents are not necessary for the application of the present document but they assist the
user with regard to a particular subject area.
[i.1] ETSI TS 101 556-1: "Intelligent Transport Systems (ITS); Infrastructure to Vehicle
Communication; Electric Vehicle Charging Spot Notification Specification".
[i.2] IEC 61851-3: "Electric vehicle conductive charging system - Part 3: Communication protocol
between electric vehicle charging station and electric vehicle".
[i.3] ISO/IEC 15118-7: "Road vehicles - Vehicle-to-Grid Communication Interface - Part 7: Network
and application protocol requirements for wireless communication".
[i.4] ISO/IEC 15118-3: " Road vehicles -- Vehicle to grid communication interface -- Part 3: Physical
and data link layer requirements".
[i.5] ISO/IEC 15118-8: " Road vehicles -- Vehicle to grid communication interface -- Part 8: Physical
layer and data link layer requirements for wireless communication".
ETSI

---------------------- Page: 5 ----------------------
6 ETSI TS 101 556-3 V1.1.1 (2014-10)
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the following terms and definitions apply:
Alternating Current (AC): AC charging through the usual grid voltage
Direct Current (DC): fast charging over high-voltage DC current provided by the recharging spot
Electric Vehicle Supply Equipment (EVSE): charging control equipment in the charging spot
inductive: inductive charging without a physical contact
quickdrop: swapping of the EV battery pack or of the trailer carrying the battery extension
3.2 Abbreviations
For the purposes of the present document, the following abbreviations apply:
AC Alternating Current
DC Direct Current
EIM External Identification Means
EV Electric Vehicle
EVSE Electric Vehicle Supply Equipment
HMI Human Machine Interface
NFC Near Field Communications
TCP Transport Control Protocol
TLS Transport Layer Security
UDP Universal Datagram Protocol
UTC Universal Time Coordinate
4 Overview of the recharging spot reservation
procedure
4.1 Reservation process in the context of related electro-
mobility standards
The recharging spot reservation process starts from the journey planning phase and continues during the driving phase,
terminating with the approach of the reserved parking / fast recharge / quick drop area. The charging spot reservation
process shall support both EVs equipped with the V2G adapter, i.e. ISO/IEC 15118-2 interface compliant vehicles [1],
as well as EVs performing "mode 3" recharging based only on the IEC 61851-3 interface [i.2]. This includes support of
different electrical energy provisioning modes, such as wired, quick drop or inductive recharging.
Figure 1 illustrates the scope of this protocol in the context of the EV's journey phases and in relation to other standards.
This protocol is expected to be implemented either in the EV's on-board computer or on the driver's nomadic device.
The reservation involves the validation of the user's payment account, in order to make sure beforehand that the user is
capable of paying for the reserved services; therefore the reservation management server shall be prepared to handle
such account validation.
ETSI

---------------------- Page: 6 ----------------------
7 ETSI TS 101 556-3 V1.1.1 (2014-10)

Figure 1: Overview of complementing EV recharging management standards' roles
Depending on the system architecture, the recharging spot selection is done either by the EV, a nomadic device
application, or an electro-mobility server/infrastructure; such architectural difference is irrelevant from the point of view
of this reservation protocol. A candidate recharging spot has been selected before initiating this procedure.
As shown in Figure 1, the matching of charging spot identifier by the EV driver is complemented by the EVSE's
matching of plugged-in EV with the one belonging to the reservation. When the EV supports the V2G interface, the
ISO/IEC 15118-2 procedures [1] ensure that only the EVs with a valid reservation shall be able to recharge.
Furthermore, the ISO/IEC 15118-2 procedures [1] may ensure that the offered charging sessions terminate by the end of
the reservation period, so that there is no point for the EV to stay longer than reserved. The implementation of this
concept requires appropriate system-level integration between the presently described reservation interface and the V2G
interface defined in the ISO/IEC 15118-2 documents [1]; the present document defines the identification data which
shall be passed between these systems.
In order to support EVs recharging without the V2G interface, the reservation process shall allow the exchange of a
Pairing ID, such as RFID or NFC based identifiers, which is then used by the EVSE during the validation of physical
pairing.
The complete transaction cycle begins from information gathering at the start of journey planning, and completes with
the billing and accounting of utilized charging services. Figure 2 illustrates the wider view of this transaction cycle, and
shows this cycle, along with the role of relevant communication standards.

Figure 2: The EV energy management cycle
ETSI

---------------------- Page: 7 ----------------------
8 ETSI TS 101 556-3 V1.1.1 (2014-10)
It is furthermore recognized that a trustable reservation system shall be complemented by an appropriate enforcement
process to guarantee that the reserved resource shall be available. The main challenges are to ensure that the reserved
recharging space is not occupied by someone else before the arrival of reserving EV and that the reserving EV departs
by the end of the reserved time period. While the specification of such complementing enforcement is out of scope of
the present document, the following observations are made:
• It appears that a legal enforcement is a most cost-effective solution for enforcing reservation-based EV
charging spots in regions where parking itself is payment based. In that case the EVSE may detect through
some sensor when a vehicle occupies a corresponding parking slot, and alert parking enforcement personnel if
a valid charging session is not initiated subsequently within some timeout. Similarly, the EVSE may alert
parking enforcement personnel if the recharging EV does not depart by the end of its reservation period.
• In regions where parking is for free, EV charging spots should be planned in locations of abundant parking
space availability; therefore, chances for conflicting parking occupation would be minimized.
The EV charging spot reservation protocol specified in the present document is based on a request-response model
based client-server architecture, where every transaction is initiated by the reserving client. There may be situations,
where the EV driver should be alerted of some upcoming time limit, such as the pending expiry of reserved charging
time if the EV is still plugged in. Figure 3 gives a graphical illustration of such relevant time limit alerts. The presently
described protocol conveys all the needed information to the client device during the reservation process for making
such alert. It is not the responsibility of the reservation management server to make such alerts towards the EV driver;
therefore, no such alert procedure is being specified. Displaying alerts as needed is the responsibility of the client device
implementation, and is considered to be a design issue being out of the scope of the present document.

Figure 3: HMI aspects of the EV recharging management procedure
The present reservation protocol does not convey the actual pricing information of the reserved services. The reason is
that the charging session is negotiated upon plugin at the start of the ISO/IEC 15118 procedure [1] and [i.3], and the
final charging price may depend on the selected power and priority levels. Conveying pricing information during the
reservation stage might therefore be confusing for EV users.
4.2 Identification of the reservation server
Before initiating the recharging spot reservation, the client device has the EVSE-ID which identifies the recharging spot
intended to be reserved. This list of candidate EVSE-IDs is received either directly through the recharging spot
notification broadcasts, or from the e-Mobility management server which plans and optimizes the recharging spot
allocations. There is an IPv6 address or URL resource belonging to each EVSE-ID, which identifies the corresponding
server responsible for the reservations; this information is contained in the 'Booking contact information' data element
of recharging spot notification broadcasts specified in ETSI TS 101 556-1 [i.1] and shall be received by the entity
making the recharging spot reservation. While the 'Booking contact information' data element is indicates as optional in
ETSI TS 101 556-1 [i.1], from the perspective of the present document it is expected to be present in the recharging
spot notification broadcasts.
ETSI

---------------------- Page: 8 ----------------------
9 ETSI TS 101 556-3 V1.1.1 (2014-10)
5 Protocol procedures
5.1 Overview of the protocol operation
Figure 4 illustrates the overall flow of the EV energy supply reservation protocol procedures. The format of the
involved messages and fields is described in clause 7 and clause 8.

Figure 4: The EV recharging spot reservation process flowchart
Upon the completion of the reservation procedure, the charging spot reservation server shall forward to the
corresponding EVSE to the assigned Reservation ID (in case of V2G based recharging) or the driver identifier (in case
of recharging without V2G). The specification of such interface to the EVSE is out of the scope of the present
document. It is noted that the first release of the ISO/IEC 15118-2 standard [1] does not support the transmission of
Reservation ID. Therefore, such validation of the arriving EV can be based on either a future revision of
ISO/IEC 15118-2 [1] or on the wireless V2G interface specified in the ISO/IEC 15118-7 [i.3] document.
The application messages described in the present document rely on IP-based network layer service, utilizing the
transport protocol stack shown in Figure 5. As illustrated in Figure 5, the deployment of this service may be realized
through any IP-based system, as well as through a web-based reservation interface running behind a proxy server. The
access options shown in Figure 5 are examples for deployment possibilities, keeping in mind that the presently
described application layer protocol is agnostic to the underlying communications technology.
ETSI

---------------------- Page: 9 ----------------------
10 ETSI TS 101 556-3 V1.1.1 (2014-10)

Figure 5: Deployment options for accessing the reservation service
In case of stream-based transport layer service, the messages defined in the present clause are exchanged in the same
transport-layer session, which is set up by the client before sending the Pre-Reservation Request message. This
transport-layer session is terminated upon the reception of the Reservation Response message, which completes the
reservation procedure.
Before processing any request message, the reservation management server always authenticates the requesting client.
For this security reason, the services of the underlying TLS v1.2 [3] and [4] secure transport layer shall be used. For
stream-based transport services (such as TCP), the required TLS implementation is defined in IETF RFC 5246 [3],
while for datagram-based transport services (such as UDP), the required TLS implementation is defined in
IETF RFC 6347 [4]. Currently, TLS provides for one-way authentication of the server.
Subsequently to a completed reservation, there is a possibility to cancel a reservation or update the reservation times.
The reservation update supports only later arrival time update and/or earlier departure, and not the other way around. As
described in clause 6, a change of EVSE, later departure, or similar changes require making a new reservation and the
cancellation of existing one. The matching Reservation ID / Reservation Password combination requirement assures the
security of reservation updating process.
During the driving phase, the EV may want to poll the status of the charging spot, in order to know whether it is already
available or still occupied by a preceding vehicle. Such polling procedure is not supported by the presently described
service, but it may be directly provided by the wireless V2G interface of the EVSE, which is specified in the
ISO/IEC 15118-7 [i.3] and document.
5.2 Pre-Reservation procedure
The client starts the reservation process by sending the Pre-Reservation Request message for reserving the preferred
recharging spot. To identify the requested charging spot, the client uses the EVSE-ID in the Pre-Reservation Request
message. The structure of EVSE-ID is defined in DIN 91286:2011 [2]. The server responds by informing the current
status in the Pre-Reservation Response message, putting the recharging spot into pre-reservation status so that the client
can trust it can safely go ahead to reserve a recharging spot which is indicated to be available. In case of a battery
changing station this means the pre-reservation of the needed battery type. If the Pre-Reservation Response informs no
availability at the requested recharging spot, the client can send a new Pre-Reservation Request message for the next
candidate recharging spot on its list.
In case of battery replacement service, there is no indication of the needed battery type. The reason is that it may not be
practical to keep track of all possible changeable EV battery types within this protocol. It is the responsibility of the
recharging spot discovery procedure to keep track of possible recharging spots for a given battery type. From the point
of view of this protocol, if a battery replacement station offers multiple battery types then a distinct EVSE-ID is used to
indicate a recharging spot for each corresponding battery type, and the EV addresses the requested EVSE-ID.
It is needed to ensure that the requesting client is a valid one, since the recharging spot gets into a pre-reservation status
upon the processing of this request. A suitable security mechanism is provided by the client authentication procedure of
the underlying TLS v1.2 [3] and [4] security layer. The implementation shall take care of setting up the required client
certificates for both contract-based and pre-paid procedures.
ETSI

---------------------- Page: 10 ----------------------
11 ETSI TS 101 556-3 V1.1.1 (2014-10)
The server responds with the availability status of the recharging spot. Available recharging spots are placed into pre-
reserved status by the server for the indicated time. The EV should complete the reservation procedure until the
indicated time; otherwise, the pre-reservation status is removed on the server side.
The testable requirements for the Pre-Reservation procedure are listed in Table 1.
Table 1: Testable requirements for the Pre-Reservation procedure
Requirement # Semantics
1 The encoding of Pre-Reservation Request and Response messages shall correspond
to the syntax defined in the present document
2 The ArrivalTime shall be greater than current time
3 The estimated DepartureTime shall be present unless Quickdrop service is requested
4 If present, the DepartureTime shall be greater than ArrivalTime
5 The BatteryType field shall be present when Quickdrop service is requested

5.3 Reservation procedure
The client continues the reservation process by sending the Reservation Request message for reserving the preferred
charging spot. The client identifies itself through the PreReservation-ID obtained in the Pre-Reservation step. This
message also indicates the selected payment method (PaymentType).
A reservation request contains the estimated arrival (ArrivalTime) and departure time (DepartureTime) and the
requested energy (EnergyReq). The client also sends the energy required for the completion of the current trip
(EnergyMin). Requested energy and the minimal energy can therefore have different values.
The EV chooses the needed recharging service through the Recharging-type parameter. The third part of the message is
the payment method selection. The payment method can be contract or pre-payment. If the EV selects the contract
option, then the ContractID shall be also included. The format of the ContractID is defined in ISO/IEC 15118-2 [1]. In
case of pre-payment, the External Identification Means (EIM) is also included. The procedure for obtaining and
managing of the External Identification Means is out of the scope of the present document, and is specific to the local
EV recharging system. For example, there could be payment cards or virtual tokens sold that include some External
Identification Means identifier.
The transmission of ContractID or ExternalIdentificationMeans is also done in the ISO/IEC 15118-2 protocol [1]. No
additional identification information is collected beyond these required identifiers for proper reservation handling. In
addition, encryption is provided by the underlying TLS protocol.
The reservation request may contain the PairingID, which is then used by the EVSE to validate that the correct vehicle
has connected to the charging spot. This field shall be present when the EV does not support the V2G interface. The
encoding of Pairing-ID is implementation dependent; for example, it may correspond to a code written on an RFID card
or to the NFC identifier of a smartphone device.
As with the preceding Pre-Reservation Request message, the underlying TLS v1.2 [3] and [4] security layer provides
client authentication.
If the reservation is acceptable, the server sends the reservation response message with response code OK. Otherwise
the response contains the actual error code, e.g. no free capacity at the selected charging spot or payment error. Positive
response message contains the reservation identifier, the reserved charging spot number, optional information about the
free cancellation time limit, and optionally extra information about the charging spot. The absence of free cancellation
time limit indicates that the EV driver may freely make a cancellation at any time. The EV should arrive to the charging
spot before the expiration time. After this time the charging centre deletes the EV's reservation.
The reservation request may be rejected for a number of reasons, such as pre-reservation identifier mismatch, payment
reservation error, or insufficient power availability at the EVSE for satisfying the request. The relating cause is
identified by the ReservationResponseCode field.
ETSI

---------------------- Page: 11 ----------------------
12 ETSI TS 101 556-3 V1.1.1 (2014-10)
The testable requirements for the Reservation procedure are listed in Table 2.
Table 2: Testable requirements for the Reservation procedure
Requirement # Semantics
6 The encoding of Reservation Request and Response messages shall correspond to the
syntax defined in the present document
7 The ArrivalTime and DepartureTime shall be the
...