EN 15722:2020

SLOVENSKI STANDARD
01-november-2020
Nadomešča:
SIST EN 15722:2015
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: EN 15722:2020
ICS:
03.220.20 Cestni transport Road transport
13.200 Preprečevanje nesreč in Accident and disaster control
katastrof
35.240.60 Uporabniške rešitve IT v IT applications in transport
prometu
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

EN 15722
EUROPEAN STANDARD
NORME EUROPÉENNE
August 2020
EUROPÄISCHE NORM
ICS 03.220.20; 13.200; 35.240.60 Supersedes 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 European Standard was approved by CEN on 5 July 2020.

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. Up-to-date lists and bibliographical references
concerning such national standards may be obtained on application to the CEN-CENELEC Management Centre or to any CEN
member.
This European Standard exists 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, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway,
Poland, Portugal, Republic of North Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and
United Kingdom.
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
© 2020 CEN All rights of exploitation in any form and by any means reserved Ref. No. EN 15722:2020 E
worldwide for CEN national Members.

Contents Page
European foreword . 4
Introduction . 5
1 Scope . 6
2 Normative references . 6
3 Terms and definitions . 6
4 Symbols and abbreviated terms . 7
5 Requirements . 8
5.1 Concepts and formats . 8
5.1.1 MSD data concepts . 8
5.1.2 Representation of MSD data concepts . 8
5.1.3 Different versions of MSD data . 9
5.1.4 Distribution of MSD data . 9
5.1.5 Additional data . 9
5.2 ISO Object identifier . 10
5.3 Contents of the ‘Minimum Set of Data’ (MSD) . 11
5.3.1 General. 11
5.3.2 Basic contents of MSD version 3 . 11
5.3.3 Previous versions of MSD message . 15
Annex A (normative) ASN.1 definition of MSD . 20
A.1 ASN.1 definition of MSD . 20
A.2 Syntax check of ASN.1 definition of MSD . 24
A.3 Examples of ASN.1 encoded MSD . 24
Annex B (informative) ASN.1 Data representation PER and BER explained . 26
B.1 What is ASN.1 . 26
B.2 Encoding data using ASN.1 . 27
B.2.1 General. 27
B.2.2 Basic Encoding Rules (BER) . 27
B.2.3 Distinguished Encoding Rules (DER) . 27
B.2.4 Packed Encoding Rules (PER/UPER) . 27
B.2.5 XML Encoding Rules (XER) . 28
B.3 Examples . 28
B.3.1 General. 28
B.3.2 ASN.1 example definition . 28
B.3.3 Encoding using BER or DER . 29
B.3.4 Encoding using PER . 29
B.3.5 Encoding using XER and EXER . 30
Annex C (informative) Formal XML format description (XSD) for the MSD . 31
Annex D (informative) Explanation of rationale for MSD data concept elements . 36
Annex E (informative) Object Identifiers (OID) . 38
E.1 Formal definition of OID . 38
E.2 What is an object identifier? . 38
E.3 Object Identifiers and ISO standards . 38
E.4 OID for eCall data concepts . 38
Bibliography . 39

European foreword
This document (EN 15722:2020) has been prepared by Technical Committee CEN/TC 278 “Intelligent
transport systems”, the secretariat of which is held by NEN.
This European Standard shall be given the status of a national standard, either by publication of an
identical text or by endorsement, at the latest by February 2021, and conflicting national standards shall
be withdrawn at the latest by February 2021.
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. CEN shall not be held responsible for identifying any or all such patent rights.
This document supersedes EN 15722:2015.
In comparison with the previous edition, the following modifications have been made:
— Correction of some typing errors;
— Added additional clarifications to solve frequently asked questions;
— Inclusion of recent locations mandatory to support more efficient dispatch of emergency services;
— MSD field “numberOfPassengers” replaced by “numberOfOccupants”;
— 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;
— Updated privacy requirements to include EU 2016/679 GDPR.
According to the CEN-CENELEC Internal Regulations, the national standards organisations of the
following countries are bound to implement this European Standard: Austria, Belgium, Bulgaria, Croatia,
Cyprus, Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland,
Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Republic of North
Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and the United
Kingdom.
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 document 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 document.
See list of referenced standards.
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 as part of the MSD.
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) — Part 2:
NOTE Communications standards required for transmission of eCall using GSM/UMTS wireless
communications networks are referenced in EN 16062 and EN 16072 [6].
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 https://www.iso.org/obp/ui
3.1
ASN.1
Abstract Syntax Notation One
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
MSD
minimum set of data
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
3.4
PSAP
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 project
BCD binary coded decimal
BER basic encoding rules (ASN.1)
CNG compressed natural gas
CXER Canonical XML encoding rules
ETSI European telecommunications standards institute
EC European Commission
EU European Union
EXER extended XML encoding rules
GSM global system for mobile communications
GNSS global navigation satellite system
ID identity
IP Internet protocol
ISO international organization for standardization
ITS intelligent transport system(s)
ITU international telecommunication union
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
P2WV powered 2-wheel vehicles
PDU protocol data unit (ASN.1)
PER packed encoding rules (ASN.1)
PSAP public safety answering point
TPSP third party service provider
UMTS universal mobile telecommunications system
UPER unaligned packet encoding rules (ASN.1)
VDS vehicle type descriptor (part of VIN)
VIN vehicle identification number
VIS vehicle identification sequence (part of VIN)
WMI world manufacturer index (part of VIN)
WGS84 world geodetic system
XER XML encoding rules
XML extensible markup language
XSD XML Schema Definition
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.
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 document 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 document (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. Any payload bytes received outside of the ASN.1 message length shall
be ignored by the receiving entity.
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 [6]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.
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 document specifies the presentation
of any such data within an MSD message. The nature and content of such additional data is not part of
this document.
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’ [8].
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 ‘oad’-
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
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 3
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.
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 3
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 incremented with every
(1.255)
application layer MSD retransmission following a
request to resend after the incident event
Control
M
automaticActivation
BOOLEAN    true = Automatic activation
false = Manual activation
testCall
BOOLEAN  true = Test call
false = Emergency
positionCanBeTrusted
BOOLEAN  true = Position can be trusted
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
vehicleType
ENUM  The category of the vehicle according to UNECE
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 people)
- 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
(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 33(Trailers
[including semi–trailers])
- Category O -
(Agricultural vehicles)
- Category T
- Category R
- Category S
(off-road vehicles)
- Category G -
- Category “Other”
a
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.
gasolineTankPresent
BOOLEAN
dieselTankPresent BOOLEAN
compressedNaturalGas
BOOLEAN
true = present; false = not present
liquidPropaneGas
BOOLEAN
If no information about the propulsion storage is
known, all elements shall be set to FALSE.
electricEnergyStorage
BOOLEAN
hydrogenStorage BOOLEAN
otherPropulsionStorage
BOOLEAN
timeStamp
INTEGER sec M Timestamp of the initial data message generation
within the current eCall incident event, represented
(0.2 -1)
st
in seconds elapsed since midnight January 1 , 1970
UTC.
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.
positionLatitude INTEGER milliarcsec   Position latitude (WGS84)
31 31
(-2 .2 -1) EXPLANATION (calculation example):
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 INTEGER milliarcsec Position longitude (WGS84)
31 31
(-2 .2 -1) maximum value:
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 (magnetic or
(0.255) (2 degree)
geographical) north (0– 358, 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
due South = 180° = 90 * 2°  => 90
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
M Known location of the vehicle ‘some time’ before the
generation of the data for the MSD message.
The three readings (vehicleLocation,
recentVehicleLocationN1 and
recentVehicleLocationN2) shall be taken within a
timeframe of no more than 15 sec. without the
possibility to derive information about the driving
speed at the time of triggering.
latitudeDelta INTEGER 100   Latitude Delta (+ for North and – for South; WGS84)
with respect to vehicleLocation.
(-512.511) milliarcsec
1 Unit = 100 miliarcseconds,
which is approximately 3m (on Earth)
maximum value:
511 = 0°0'51.100'' (≈1580m)
minimum value:
-512 = -0°0'51.200'' (≈ -1583m)
longitudeDelta
INTEGER 100 Longitude Delta (+ for East and – for West; WGS84)
with respect to vehicleLocation.
(-512.511) milliarcsec
See latitudeDelta for details
recentVehicleLocationN2
M Known location of the vehicle ‘some time’ before
recentVehicleLocationN1.
The three readings (vehicleLocation,
recentVehicleLocationN1 and
recentVehicleLocationN2) shall be taken within a
timeframe of no more than 15 sec. without the
possibility to derive information about the driving
speed at the time of triggering.
latitudeDelta
INTEGER 100   Latitude Delta (+ for North and – for South) with
respect to recentVehicleLocationN1.
(-512.511) milliarcsec
See recentVehicleLocationN1.
latitudeDelta for details
longitudeDelta INTEGER 100 Longitude Delta (+ for East and – for West) with
respect to recentVehicleLocationN2.
(-512.511) milliarcsec
See recentVehicleLocationN1.
latitudeDelta for details
numberOfOccupants
INTEGER  O Number of occupants in the vehicle according to
available information.
(0.255)
If no information about the number of occupants is
available, this parameter needs to be omitted or
filled with the representation of value 255
NOTE 1 This information is indicative only as it may
be not always be reliable in providing exact
information about the number of occupants (e.g.
because seatbelts may not be fastened by occupants
or seatbelts may be fastened for other reasons).
NOTE 2 For vehicle categories without enclosing
(e.g. motorcycles) ‘occupants’ will be read as ‘riders’
or ‘vehicle users’.
optionalAdditionalData O
oid
RELATIVE-OID    See 5.1.5
data
OCTET STRING  See 5.1.5
a)
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.

5.3.3 Previous versions of MSD message
5.3.3.1 General
Previous versions of the MSD message shall be supported by PSAPs to ensure proper handling of legacy
systems. Such versions shall be described with a table described and defined in the same way as Table 1.
5.3.3.2 MSD message version 1
MSD message version 1 has been withdrawn due to an erroneous ASN.1 data representation which might
cause disruption in the handling of eCalls by PSAP systems. As a result this version shall not be supported
by PSAPs and shall not be used by an IVS as of publication of EN 15722:2015.
5.3.3.3 MSD message version 2 (2015)
MSD message version 2 was introduced with the publication of EN 15722:2015. The decision to make
recentVehicleLocationN1 and recentVehicleLocationN2 mandatory incurred a change that enforced a
new version (3) in the 2020 release. That necessity made it possible to incorporate some other changes
more efficiently as well.
Version 2, described in Table 2, shall no longer be implemented in eCall IVS devices, but it shall be
implemented in receiving systems.
Table 2 — Contents/format of the MSD data concept version 2
M – Mandatory data field
O – Optional data field
MSD
msdVersion INTEGER - M MSD format version
(1.255) The format described in this table 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 incremented with every
(1.255)
application layer MSD retransmission following a
new ‘Send MSD’ request after the incident event
Control
M
automaticActivation
BOOLEAN    true = Automatic activation
false = Manual activation
testCall
BOOLEAN  true = Test call
false = Emergency
positionCanBeTrustd BOOLEAN  true = Position can be trusted
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
vehicleType ENUM  The category of the vehicle according to UNECE
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
(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

a
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.
gasolineTankPresent
BOOLEAN
dieselTankPresent
BOOLEAN
compressedNaturalGas
BOOLEAN
true = present; false = not present
liquidPropaneGas BOOLEAN
If no information about the propulsion storage is
known, all elements shall be set to FALSE.
electricEnergyStorage
BOOLEAN
hydrogenStorage
BOOLEAN
otherPropulsionStorage
BOOLEAN
timeStamp INTEGER sec M Timestamp of the initial data message generation
within the current eCall incident event,
(0.2 -1)
represented in seconds elapsed since midnight
st
January 1 , 1970 UTC.
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.
positionLatitude
INTEGER milliarcsec   Position latitude (WGS84)
31 31
(-2 .2 -1) EXPLANATION (calculation example):
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 INTEGER milliarcsec Position longitude (WGS84)
31 31
(-2 .2 -1) maximum value:
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 (magnetic or
(0.255) (2 degree)
geographical) north (0– 358, 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
due South  = 180°  = 90 * 2°  => 90
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
different driving environments such as city or
motorway.
latitudeDelta
INTEGER 100   Latitude Delta (+ for North and – for South;
WGS84) with respect to vehicleLocation.
(-512.511) milliarcsec
1 Unit = 100 miliarcseconds,
which is approximately 3m (on Earth)
maximum value:
511 = 0°0'51.100'' (≈1580m)
minimum value:
-512 = -0°0'51.200'' (≈ -1583m)
longitudeDelta INTEGER 100 Longitude Delta (+ for East and – for West;
WGS84) with respect to vehicleLocation.
(-512.511) milliarcsec
See latitudeDelta for details
recentVehicleLocationN2
O Known location of the vehicle some time before
recentVehicleLocationN1.
The recent location shall be chosen such that they
could normally assist the receiving party to
confirm the current location of the vehicle in
different driving environments such as city or
motorway.
latitudeDelta
INTEGER 100   Latitude Delta (+ for North and – for South) with
respect to recentVehicleLocationN1.
(-512.511) milliarcsec
See recentVehicleLocationN1.
latitudeDelta for details
longitudeDelta
INTEGER 100 Longitude Delta (+ for East and – for West) with
respect to recentVehicleLocationN2.
(-512.511) milliarcsec
See recentVehicleLocationN1.
latitudeDelta for details
numberOfPassengers INTEGER  O Number of occupants in the vehicle according to
available information.
(0.255)
If no information about the number of occupants is
available, this parameter needs to be omitted or
filled with the representation of value 255
NOTE 1 This information is indicative only as it
may be not always be reliable in providing exact
information about the number of passengers (e.g.
because seatbelts may not be fastened by
passengers or seatbelts may be fastened for other
reasons).
NOTE 2 For vehicle categories without enclosing
(e.g. motorcycles) ‘occupants’ will be read as ‘riders’
or ‘vehicle users’.
optionalAdditionalData O
oid RELATIVE-   See 5.1.5
OID
data OCTET  See 5.1.5
STRING
a)
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.
NOTE See EN 15722:2015 for further information regarding MSD version 2, including its ASN.1
...