SIST EN 15722:2020

SLOVENSKI STANDARD
oSIST prEN 15722:2019
01-april-2019
Inteligentni transportni sistemi - e-Varnost - Minimalni nabor podatkov za
elektronski klic v sili
Intelligent transport systems - ESafety - ECall minimum set of data
Intelligente Transportsysteme - ESicherheit - Minimaler Datensatz für den elektronischen
Notruf eCall
Systèmes de transport intelligents - ESafety - Ensemble minimal de données (MSD) pour
l'eCall
Ta slovenski standard je istoveten z: prEN 15722
ICS:
03.220.20 Cestni transport Road transport
13.200 3UHSUHþHYDQMHQHVUHþLQ Accident and disaster control
NDWDVWURI
35.240.60 Uporabniške rešitve IT v IT applications in transport
prometu
oSIST prEN 15722:2019 en,fr,de
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

---------------------- Page: 1 ----------------------
oSIST prEN 15722:2019

---------------------- Page: 2 ----------------------
oSIST prEN 15722:2019


DRAFT
EUROPEAN STANDARD
prEN 15722
NORME EUROPÉENNE

EUROPÄISCHE NORM

February 2019
ICS 03.220.20; 13.200; 35.240.60 Will supersede EN 15722:2015
English Version

Intelligent transport systems - ESafety - ECall minimum set
of data
Systèmes de transport intelligents - ESafety - Ensemble Intelligente Transportsysteme - ESicherheit -
minimal de données (MSD) pour l'eCall Minimaler Datensatz für den elektronischen Notruf
eCall
This draft European Standard is submitted to CEN members for enquiry. It has been drawn up by the Technical Committee
CEN/TC 278.

If this draft becomes a European Standard, CEN members are bound to comply with the CEN/CENELEC Internal Regulations
which stipulate the conditions for giving this European Standard the status of a national standard without any alteration.

This draft European Standard was established by CEN in three official versions (English, French, German). A version in any other
language made by translation under the responsibility of a CEN member into its own language and notified to the CEN-CENELEC
Management Centre has the same status as the official versions.

CEN members are the national standards bodies of Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia,
Finland, Former Yugoslav Republic of Macedonia, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania,
Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland,
Turkey and United Kingdom.

Recipients of this draft are invited to submit, with their comments, notification of any relevant patent rights of which they are
aware and to provide supporting documentation.

Warning : This document is not a European Standard. It is distributed for review and comments. It is subject to change without
notice and shall not be referred to as a European Standard.


EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION

EUROPÄISCHES KOMITEE FÜR NORMUNG

CEN-CENELEC Management Centre: Rue de la Science 23, B-1040 Brussels
© 2019 CEN All rights of exploitation in any form and by any means reserved Ref. No. prEN 15722:2019 E
worldwide for CEN national Members.

---------------------- Page: 3 ----------------------
oSIST prEN 15722:2019
prEN 15722:2019 (E)

Contents Page
European foreword . 3
Introduction . 4
1 Scope . 5
2 Normative references. 5
3 Terms and definitions . 5
4 Symbols and abbreviated terms . 6
5 Requirements . 6
Annex A (normative) ASN.1 definition of MSD . 15
A.1 ASN.1 definition of MSD . 15
Annex B (informative) ASN.1 Data representation PER and BER explained . 21
B.1 What is ASN.1. 21
B.2 Encoding data using ASN.1 . 21
B.3 Examples . 23
Annex C (informative) Formal XML format description (XSD) for the MSD . 26
Annex D (informative) Explanation of rationale for MSD data concept elements . 32
Annex E (informative) Object Identifiers (OID) . 34
E.1 Formal definition of OID . 34
E.2 What is an object identifier? . 34
E.3 Object Identifiers and ISO standards . 34
E.4 OID for eCall data concepts . 34
Bibliography . 35

2

---------------------- Page: 4 ----------------------
oSIST prEN 15722:2019
prEN 15722:2019 (E)

European foreword
This document (prEN 15722:2019) has been prepared by Technical Committee CEN/TC 278 “Intelligent
transport systems”, the secretariat of which is held by NEN.
This document is currently submitted to the CEN Enquiry.
This document will supersede EN 15722:2015 and differs from that document in that the vehicleCategory
enumeration now provides for additional UNECE vehicle categories, some typing errors were corrected
and additional clarifications are added to solve frequently asked questions.
In comparison with the previous edition, the following technical modifications have been made:
The number of vehicle categories supported by this standard has been expanded through revision of the
enumeration values to enable support for additional categories of vehicles, which now covers the full
UNECE categorization, and the privacy requirements have been updated to include EU 2016/679 GDPR.
EN 15722:2015 is a document referenced in EU regulations for eCall. This revision does not bring any
inconsistency to that reference, but simply enables the benefits of eCall to any category of vehicle.
3

---------------------- Page: 5 ----------------------
oSIST prEN 15722:2019
prEN 15722:2019 (E)

Introduction
The pan-European in-vehicle emergency call, 'eCall', is estimated to have the potential to save up to 2 500
fatalities annually in the EU when fully deployed, and furthermore to reduce the severity of injuries, to
bring significant savings to the society in and to reduce human suffering.
Emergency calls made from vehicles or mobile telephones using wireless technologies, can assist with the
objectives of significantly reducing road deaths and injuries, but drivers often have poor (imprecise)
location awareness, especially on interurban roads or abroad. Additionally, in many situations the car
occupants may not be in a position to call using a normal mobile phone.
The situation is worse for those travelling abroad. A high (and increasing) number of vehicles travelling
outside their home country is thus also contributing to the need for automated emergency call system in
vehicles. In EU there are over 100 million trips to another EU country per year, 65 % of the people feel
less protected while abroad and most do not know which number to call in an emergency (in some
countries over 60 %). Language problems are pertinent and may render proper communication difficult.
Yet, in the most crucial cases, the victim(s) may not be able to call because they have been injured/trapped,
do not know the local number to call, and in many cases, particularly in rural situations and late at night,
there may be no witnesses who happen to have a mobile phone and a sense of community.
eCall, in the context of "Intelligent Transport Systems" or "ITS", (previously known as "Road Traffic and
Transport Telematics") can be described as a "user instigated or automatic system to provide notification
to public safety answering points, by means of wireless communications, that a vehicle has crashed, and
to provide coordinates and a defined minimum set of data, and where possible a voice link to the PSAP”.
The objective of implementing the pan-European in-vehicle emergency call system (eCall) is to automate
the notification of a traffic accident, wherever in the European Union and associated countries, with the
same technical standards and the same quality of services objectives of other emergency services (for
example the TS12 emergency call of GSM/UMTS).
This European Standard specifies the "Minimum Set of Data" (MSD) to be transferred by such an in-vehicle
eCall system in the event of a crash or emergency.
NOTE The communications media and means of transferring the eCall MSD are not defined in this European
Standard. See list of referenced standards.
4

---------------------- Page: 6 ----------------------
oSIST prEN 15722:2019
prEN 15722:2019 (E)

1 Scope
This document specifies the standard data concepts that comprise the "Minimum Set of Data" (MSD) to be
transferred from a vehicle to a 'Public Safety Answering Point' (PSAP) in the event of a crash or emergency
via an 'eCall' communication transaction.
Optional additional data concepts may also be transferred.
The communications media protocols and methods for the transmission of the eCall message are not
specified in this document.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
EN 16062, Intelligent transport systems — ESafety — eCall high level application requirements (HLAP)
using GSM/UMTS circuit switched networks
EN 16102, Intelligent transport systems — eCall — Operating requirements for third party support
ISO/IEC 8825-2, Information technology — ASN.1 encoding rules: Specification of Packed Encoding Rules
(PER)
NOTE Communications standards required for transmission of eCall using GSM/UMTS wireless
communications networks are referenced in EN 16062 and EN 16072.
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— IEC Electropedia: available at http://www.electropedia.org/
— ISO Online browsing platform: available at http://www.iso.org/obp
3.1
ASN.1/Abstract Syntax Notation 1.
notation that describes rules and structures for representing, encoding, transmitting, and decoding data
enabling representation of objects that are independent of machine-specific encoding techniques; see
Annex B
3.2
eCall
emergency call generated either automatically via activation of in-vehicle sensors or manually by the
vehicle occupants; when activated it provides notification and relevant location information to the most
appropriate 'Public Safety Answering Point’, by means of mobile wireless communications networks,
carries a defined standardized ‘Minimum Set of Data’ notifying that there has been an incident that
requires response from the emergency services, and establishes an audio channel between the occupants
of the vehicle and the most appropriate 'Public Safety Answering Point'
3.3
minimum set of data (MSD)
direct, timely data content of an eCall message to the PSAP operator receiving the emergency call
containing information about the location of the incident, providing detail characterising the vehicle, and
potentially sometimes also providing additional data that is deemed relevant
5

---------------------- Page: 7 ----------------------
oSIST prEN 15722:2019
prEN 15722:2019 (E)

3.4
public safety answering point
‘first level’ responder to whom an emergency call/eCall is directed
4 Symbols and abbreviated terms
For the purposes of this document, the following symbols and abbreviated terms apply.
ASN.1 abstract syntax notation one (ISO/IEC 8824/ISO/IEC 8825)
3G third generation mobile cellular network system, defined by 3GPP standards
3GPP third generation partnership protocol
BCD binary coded decimal
BER basic encoding rules (ASN.1)
CNG compressed natural gas
ETSI European telecommunications standards institute
EC European Commission
EU European Union
GSM global system mobile
GNSS global navigation satellite system
ID identity
IP Internet protocol
IVS in-vehicle system
LPG liquid propane gas
M mandatory
MSD minimum set of data
O optional
OID object identifier (ISO/IEC 8824)-see Annex E
PER packed encoding rules (ASN.1)
PSAP public safety answering point
UMTS universal mobile telecommunications system
UPER unaligned packet encoding rules (ASN.1)
5 Requirements
5.1 Concepts and formats
5.1.1 MSD data concepts
NOTE The minimum set of data is important information to assist the provision of the most appropriate services
to the crash or emergency site and to speed up the response. The minimum set of data makes it possible for the PSAP
operator to respond to the eCall even without the voice connection.
The "Minimum Set of Data" shall be a direct, timely message to the PSAP operator receiving the emergency
call.
6

---------------------- Page: 8 ----------------------
oSIST prEN 15722:2019
prEN 15722:2019 (E)

The information elements in the MSD have been selected on the basis of their relevance in an emergency
rescue situation.
The MSD has an ‘optional additional data’ block that can be used to add information elements that are
relevant to a specific situation. See 5.1.5.
5.1.2 Representation of MSD data concepts
The message shall be sent in the sequence defined within the ASN.1 definition defined in Annex A.
The transferred MSD for Pan-European eCall shall be represented in Abstract Syntax Notation (ASN.1)
using the ‘Unaligned Packed Encoding Rules’ (UPER) as defined in ISO/IEC 8825-2, using the ASN1
definitions found in Annex A. See also 5.1.4.
The transfer of the MSD for Pan-European eCall using other wireless communications media (for example
E- UTRAN) may be specified in future standards for ‘high level application protocols’ for that wireless
media.
NOTE 1 An XML encoding of the MSD data representation can be used in TPSP-to-PSAP applications (EN 16102).
Annex C contains the derived XSD for such encoding.
NOTE 2 In order to implement presentation in ASN.1 UPER, readers are advised to also read Annex B "ASN.1 Data
Representation PER and BER explained"; and also the relevant normative referenced documents.
5.1.3 Different versions of MSD data
It is foreseen that, over time, new versions of the MSD data definition will occur. Wherever possible, later
versions of the MSD shall be backwards compatible with existing versions.
If a future version of the MSD is defined which is not backwards compatible (i.e. cannot be automatically
interpreted by receiving systems) then its deployment shall be coordinated to ensure that all receiving
systems are ready before IVS adopt this new MSD format.
The main structure of an MSD shall, in any version, contain two elements, the first of which is known as
the MSD version (msdVersion) which designates the encoding rules that have been used to create the
second element.
Systems receiving an MSD shall support all standardized MSD versions, which are each uniquely identified
using this msdVersion parameter.
5.1.4 Distribution of MSD data
The MSD shall be transmitted using one or more communications media as defined in other eCall
Standards
In order to enable interpretation by the PSAP, the MSD shall always be presented in an ASN.1 encoded
module: either ASN.1 ‘Unaligned Packet Encoding Rules’ (UPER) or ASN.1 ‘Extended XML Encoding Rules’
(EXER) encoding shall be used.
The ASN.1 module shall contain the MSD as defined in this European Standard plus none or more ‘optional
additional data’ concepts presented as defined in 5.1.5 and whose name, content and presentation has
been made available in a data registry as required by this European Standard (See 5.1.5).
In the case of an MSD for pan-European eCall it shall be encoded using ‘Unaligned Packed Encoding Rules’
(UPER) as defined in ISO/IEC 8825-2. The length of this encoded MSD (including any ‘optional additional
data’) shall not exceed 140 bytes (as specified in EN 16062). Any payload bytes received outside of the
ASN.1 message length shall be ignored by the receiving entity.
The maximum length of data presented by an MSD for pan-European eCall sent via another wireless media
shall be defined in the eCall “High Level Application Protocol” standard for that specific wireless media
NOTE 1 It is assumed that the integrity of the transmitted data is assured by the underlying communication
interface standard used. For example EN 16072 which defines the operating requirements for the transmission of
Pan-European eCall and EN 16062 (eCall high level application protocols for GSM/UMTS) which provide the high
level application protocols for sending a Pan-European eCall via a circuit switched GSM/UMTS wireless phone
network.
7

---------------------- Page: 9 ----------------------
oSIST prEN 15722:2019
prEN 15722:2019 (E)

EN 16102 defines provisions for Third Party supported eCall.
NOTE 2 If the MSD is transferred using another means of communication that has no, or less stringent, data limits,
XML encoding rules can be used if preferred. Annex C contains the derived XSD for such encoding.
5.1.5 Additional data
The MSD message has a provision for ‘optional’ additional data. This European Standard specifies the
presentation of any such data within an MSD message. The nature and content of such additional data is
not part of this standard.
EXAMPLE Additional data may contain a reference to an external source of relevant information (such as a
phone number, a website URL, etc. where further information may be found, or additional data specific to the vehicle
or incident (e.g. battery temperature in the case of an electric or hybrid vehicle; number of rollovers; URL to the
technical specifications to a particular vehicle model; etc.)
Optional additional data shall not include any data concerning or identifying a person (personal data)
unless the transfer of such data has been explicitly and expressly prior instructed and authorized by the
person who is identified by the data and its provision shall in any event only be provided only in
accordance with European Union and National privacy regulations pertaining at the time of the transfer
of any such personal data and in accordance with the provisions of EU 2016/679 ‘General Data Protection
Requirements’.
Any additional data element(s) shall each consist of two parts:
1. A relative ‘object identifier’ (OID)
2. the data content.
The relative OID shall be allocated by CEN TC278 WG15 or a body nominated by it. For further information
see Annex E.
CEN/TC 278/WG15 or a body nominated by it shall allocate an ‘Object Identifier’ (OID) for each ‘Optional
Additional Data concept’. Within the MSD the ‘Optional Additional Data concept’ used shall be identified
by a ‘relative OID’, i.e. it will only contain the arcs of the object identifier of the concept starting below the
eCall MSD ‘Optional Additional Data concept’ object identifier. See 5.2 below.
Additional data shall be represented using an ASN.1representation definition that itself is made available
to emergency services/PSAPs.
When sending an MSD containing this additional data, using GSM/UMTS (EN 16062), the addition of such
data shall never cause the total (UPER encoded) MSD message length to exceed the maximum available
number of bytes (total message length = 140 bytes).
In order to ensure that the above requirement is met with any combination of optional parameters within
the main MSD message, the total length of additional data concepts may not exceed 94 bytes of data
encoded in ASN.1 UPER.
5.2 ISO Object identifier
ISO/ITU “Object Identifiers” are explained in informative Annex E.
The full eCall MSD, or any optional additional data concept, is preceded by its ISO object identifier. When
eCall data is stored or used outside of the eCall context this OID shall be prefixed onto all representations
of the MSD or any eCall data concept.
In eCall context, when data is being sent to a specific receiver (e.g. PSAP), the OID may be assumed to be
known and is not transmitted. Thus the OID is not transferred over the air between the IVS and PSAP.
eCall has been allocated the OID: 1.0.14817.106.2.1
EXPLANATION
1. identifies the data concept as an ISO parent route standard
8

---------------------- Page: 10 ----------------------
oSIST prEN 15722:2019
prEN 15722:2019 (E)

0. identifies the arc as being identified by a Standards reference number.
14817 In this case ISO 14817 being the parent standard for ITS data registry
106 emergency-service
2 pre-harmonisation-automated-calls
1 cen-15722
Below this OID three nodes are defined:
1.0.14817.106.2.1.1 for ‘Mandatory Data Concepts’
1.0.14817.106.2.1.2 for ‘Optional Data Concepts’
1.0.14817.106.2.1.3 for eCall data elements
5.3 Contents of the ‘Minimum Set of Data’ (MSD)
5.3.1 General
The following sub-clauses provide the definition of the minimum set of data that shall be sent from the
vehicle in case of an emergency call.
5.3.2 Basic contents of MSD version 2
Table 1 provides a summary of the semantic contents of the MSD.
The sequence of data presentation shall be as specified in Table 1, represented as described in 5.1.2 and
distributed as described in 5.1.4.
For clarity the ‘type’ used in Table 1 is a semantic representation of the type used in the ASN.1 definition.
The exact representation is defined in Annex A.
The real position of the element in the data-stream is defined by the ASN.1 ‘unaligned packet encoding
rules (UPER), following the definition in Annex A. Elements therefore do not necessarily start or end on a
byte boundary.
9

---------------------- Page: 11 ----------------------
oSIST prEN 15722:2019
prEN 15722:2019 (E)

Table 1 — Contents/format of the MSD data concept
M – Mandatory data field
O – Optional data field.
MSD
msdVersion
 INTEGER - M MSD format version
(1.255) The format described in this document
carries version 2
See 5.1.4 for detailed information.
Msd
msdStructure

messageIdentifier
 INTEGER  M Message identifier, starting with 1 for
each new eCall transaction and to be
(1.255)
incremented with every application layer
MSD retransmission following a new
‘Send MSD’ request after the incident
event
Control
M
automaticActivatio
 BOOLEAN    true = Automatic activation
n
false = Manual activation
testCall
BOOLEAN  true = Test call
false = Emergency
positionCanBeTrust
BOOLEAN  true = Position can be trusted
d
false = Low confidence in position

“Low confidence in position” shall mean
that there is less than 95% confidence that
exact position is within a radius of ± 150
m of reported position
The category of the vehicle according to UNECE
vehicleType
ENUM
Vehicle classification ECE-TRANS-WP29-78-r4e
for type approval according to Directive
2007/46/EC of the European Parliament and of
the Council as referenced in eCall Regulations, esp
Commission Delegated Regulation (EU) 2017/79.
The supported vehicle categories are:
(Category M - Power-driven vehicles having at leas
four wheels and used for the carriage of passengers)
- Category M1 passenger vehicle
- Category M2 buses and coaches
- Category M3 buses and coaches
(Category N - Power-driven vehicles having at least
four wheels and used for the carriage of goods)
- Category N1 light commercial vehicles
- Category N2 heavy duty vehicles
- Category N3 heavy duty vehicles
10

---------------------- Page: 12 ----------------------
oSIST prEN 15722:2019
prEN 15722:2019 (E)

(Category L – Motor vehicles with less than four
wheels- but including light quads)
- Category L1 P2WV
- Category L2 three-wheeled vehicle
- Category L3 P2WV
- Category L4 three wheels asymmetrically
arranged
- Category L5 vehicle three wheels symmetrically
- Category L6 four wheels limited power
- Category L7 four wheels limited power
--- 2018 extension (see5.8.2.3) ---
(Trailers [including semi–trailers])
- Category O -
(Agricultural vehicles)
- Category T
- Category R
- Category S
(off-road vehicles)
- Category G -
- Category “Other”

1
1
VIN
VIN  M VIN number according to ISO 3779
vehiclePropulsionStorageType
M Contains information about the presence of
propulsion storage inside the vehicle
sending the MSD.
gasolineTankPresen
 BOOLEAN
t
dieselTankPresent
BOOLEAN
compressedNaturalG
BOOLEAN
true = present; false = not present
as

liquidPropaneGas
BOOLEAN
If no information about the propulsion
storage is known, all elements shall be set
electricEnergyStor
BOOLEAN
to FALSE.
age
hydrogenStorage
BOOLEAN
otherPropulsionSto
BOOELAN
rage
timeStamp
INTEGER sec M Timestamp of the initial data message
generation within the current eCall
32
(0.2 -1)
incident event, represented in seconds
st
elapsed since midnight Janauray 1 , 1970
UTC.

1.
The field is named vehicleIdentificationNumber in the ASN.1 definition. The ASN.1 type VIN is defined in Annex A
and codes for a correct representation of the World Manufacturer Index (WMI), the Vehicle Type Descriptor (VDS)
and the Vehicle Identification Sequence (VIS) that make up a VIN number, taking into account the preconditions of
each part.

11

---------------------- Page: 13 ----------------------
oSIST prEN 15722:2019
prEN 15722:2019 (E)

NOTE 1 The initial message generation
immediately follows the eCall generation sequence
subsequent to a (confirmed) trigger.
NOTE 2 Subsequent transmissions within the
given incident use the same timestamp, but the
messageIdentifier changes.
NOTE 3 Failure value for time stamp set to “0”
vehicleLocation
M The last known vehicle position determined
at the latest moment possible before
message generation.
milliarcsec
positionLatitude
 INTEGER   Position latitude (WGS84)
31 31
EXPLANATION (calculation example):
(-2 .2 -1)
48.3003333 = 48°18'1.20" N = 48*60*60.000” +
18*60.000” + 1.20” = 173881.200” = 173881200
milliarcsec
maximum value:
90°00'00.000” = 324000000
minimum value:
-90°00'00.000” = -324000000

If latitude is invalid or unknown, the
representation of value 2147483647 shall
be transmitted.

If both latitude and longitude have value 0
then the location shall also be interpreted
as invalid/unknown.
NOTE If the transmitter or receiver
determines either latitude or longitude to be
invalid/unknown, then it is advised to transmit both
longitude and latitude as unknown.
positionLongitude milliarcsec
INTEGER Position longitude (WGS84)
31 31 maximum value:
(-2 .2 -1)
180°00'00.000'' = 648 000 000
minimum value:
-180°00'00.000'' = -648 000 000
See latitude for calculation example and
notes.
vehicleDirection
INTEGER 2° M The vehicle’s last known real direction of
travel (expressed in 2°-degrees steps from
(0.255) (2
(magnetic or geographical) north (0– 358,
degree)
clockwise) determined at the latest
moment possible before message
generation.
EXPLANATION (calculation example):
due North = 0° = 0 * 2° => 0,
due East = 90° = 45 * 2° => 45
12

---------------------- Page: 14 ----------------------
oSIST prEN 15722:2019
prEN 15722:2019 (E)

due South = 180° = 90 * 2° => 95
due West = 270° = 135 * 2° => 135
The direction shall be unaffected by
random fluctuations of GNSS signals.

If direction of travel is invalid or
unknown, the representation of value 255
shall be transmitted
recentVehicleLocationN1
O Known location of the vehicle some time
before the generation of the data for the
MSD message.

The recent location shall be chosen such
that they could normally assist the
receiving party to confirm the current
location of the vehicle in di
...