SIST-TS CEN/TS 17363:2019

SLOVENSKI STANDARD
SIST-TS CEN/TS 17363:2019
01-november-2019
Inteligentni transportni sistemi - Izbirni dodatni podatki eKlica - Povezan koncept
podatkov o mobilni telefonski številki
Intelligent transport systems - ECall optional additional data - Linked mobile phone
number data concept
Intelligente Verkehrssysteme - Optionale zusätzliche eCall-Daten - Verbundenes
Mobilfunknummer Datenkonzept
Élément introductif - Élément central - Élément complémentaire
Ta slovenski standard je istoveten z: CEN/TS 17363:2019
ICS:
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
SIST-TS CEN/TS 17363:2019 en,fr,de
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

---------------------- Page: 1 ----------------------
SIST-TS CEN/TS 17363:2019

---------------------- Page: 2 ----------------------
SIST-TS CEN/TS 17363:2019


CEN/TS 17363
TECHNICAL SPECIFICATION

SPÉCIFICATION TECHNIQUE

August 2019
TECHNISCHE SPEZIFIKATION
ICS 13.200; 35.240.60
English Version

Intelligent transport systems - ECall optional additional
data - Linked mobile phone number data concept
Élément introductif - Élément central - Élément Intelligente Verkehrssysteme - Optionale zusätzliche
complémentaire eCall-Daten - Datenkonzept für verbundene
Mobilfunknummer
This Technical Specification (CEN/TS) was approved by CEN on 21 July 2019 for provisional application.

The period of validity of this CEN/TS is limited initially to three years. After two years the members of CEN will be requested to
submit their comments, particularly on the question whether the CEN/TS can be converted into a European Standard.

CEN members are required to announce the existence of this CEN/TS in the same way as for an EN and to make the CEN/TS
available promptly at national level in an appropriate form. It is permissible to keep conflicting national standards in force (in
parallel to the CEN/TS) until the final decision about the possible conversion of the CEN/TS into an EN is reached.

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
© 2019 CEN All rights of exploitation in any form and by any means reserved Ref. No. CEN/TS 17363:2019 E
worldwide for CEN national Members.

---------------------- Page: 3 ----------------------
SIST-TS CEN/TS 17363:2019
CEN/TS 17363:2019 (E)
Contents Page
European foreword . 3
Introduction . 4
1 Scope . 5
2 Normative references . 5
3 Terms and definitions . 5
4 Conformance . 6
5 Symbols and abbreviated terms . 6
6 Requirements . 7
6.1 General. 7
6.2 Registration and linking of the phone . 7
6.3 Distribution of MSD data . 8
7 Concepts and formats . 8
7.1 MSD data concepts and representation . 8
7.2 Linked phone number optional additional data concept ‘Object Identifier’ . 8
7.3 Linked phone number optional additional data concept ‘data’ . 9
7.4 Contents of the ‘Minimum Set of Data’ (MSD) . 9
8 Privacy provisions . 10
9 Advice to PSAPs on the use of the eCall OAD LTN . 11
Annex A (informative) ASN.1 definition of optional datablock . 12
Annex B (informative) ASN.1 definition of complete MSD message with LTN . 13
Annex C (informative) Example of HMI interaction . 19
Annex D (informative) Example of eCall sequence in car . 21
Bibliography . 22

2

---------------------- Page: 4 ----------------------
SIST-TS CEN/TS 17363:2019
CEN/TS 17363:2019 (E)
European foreword
This document (CEN/TS 17363:2019) has been prepared by Technical Committee CEN/TC 278
“Intelligent transport systems”, the secretariat of which is held by NEN.
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.
According to the CEN/CENELEC Internal Regulations, the national standards organisations of the
following countries are bound to announce this Technical Specification: 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.
3

---------------------- Page: 5 ----------------------
SIST-TS CEN/TS 17363:2019
CEN/TS 17363:2019 (E)
Introduction
This document complements EN 15722:2015, Intelligent transport systems — ESafety — ECall minimum
set of data and provides an “Optional Additional Data” concept to be transmitted as part of the MSD
transmission in accordance with EN 15722:2015.
In the event that a vehicle triggers a 112 eCall, the MSD is sent to a “public safety answering point” (PSAP).
The PSAP operator decodes the MSD data (usually, but not necessarily, automatically placed on the
operator's screen). The operator is put in wireless communication (via a mobile phone connection) with
the occupants of the vehicle.
However, sometimes, the operator does not receive any response from the vehicle. This may be due to
one of three reasons:
a) The equipment has failed/has a fault;
b) The occupants are dead, unconscious or otherwise unable to speak;
c) The occupants have left the vehicle and moved to a place of safety (for example behind a crash
barrier or well away from the road [this would often be the advice given by a PSAP in any event]).
NOTE 1 The communications media and means of transferring the eCall MSD are not defined in this document.
See the list of referenced Standards.
As, by this stage, the Minimum Set of Data (MSD) has already been successfully sent; it is usually relatively
easy to detect an in-vehicle system problem (the line has gone totally silent, indicating a dropped call, or
there is some interference noise etc.).
If the line appears to be operational, the responding PSAP has a dilemma. He/she has no way to determine
whether the cause is (b), where it is essential to quickly get emergency response to the scene, or (c), in
which case it may not even be necessary to send an emergency response to the scene.
Based on experience with pre-eCall emergency call systems using cellular telephone links, experience is
that more than 90 % of the time, the reason is (c), but without further information, the PSAP cannot take
that risk and is to send emergency response to the site.
However, current generation vehicles generally now provide the possibility for a 'Bluetooth' link between
the mobile phone of the occupants and the car. Thus, when the registered phone user enters, or is in close
proximity, to the vehicle (usually, but not always, activated when the ignition is turned on) his/her mobile
phone connects via Bluetooth to the vehicle's audio system No information about the user itself, or
her/his phone number is exchanged, as this information is neither known to the mobile phone nor is it
part of any Bluetooth exchange mechanism. That said, the vehicle does know, at any time, which
registered user phones are in or near the vehicle and linked to it at the time of the incident.
If, by means of prior consent, the user who registers his/her phone with the vehicle system enters his/her
phone number, it is possible to provide the PSAP with that phone number as an “Optional Additional
Data” (OAD) concept as part of the MSD.
In the event of a 'silent' call, the PSAP is therefore able to telephone the mobile phone number that was
linked to the vehicle at the time of the incident. It is expected that this will significantly reduce the number
of ‘silent’ calls.
This addition does not enable the vehicle to be tracked or logged in any way other than any other linked
mobile telephone, and, of course, in 112 eCall, the eCall phone connection to the network does not occur
at all until after the event (triggering of eCall).
NOTE 2 This specification provides an optional additional concept as part of the MSD sent to the PSAP, it does
not involve making any direct connection with the telephone number provided, but simply makes that number
available to the PSAP to call if available and required.
4

---------------------- Page: 6 ----------------------
SIST-TS CEN/TS 17363:2019
CEN/TS 17363:2019 (E)
This document defines the OAD concept, requirements to ensure the user's consent to the provision of
the linked phone number, any provisions to be made regarding privacy and advice to PSAPs on the use of
the extra information.
1 Scope
This document defines an eCall “Optional Additional Data" concept for 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.
This document defines:
a) Protocol requirements to ensure phone user consent to the provision of the linked 'phone number
to the PSAP in the event of an eCall triggering incident;
b) Definition of the OAD concept “Linked mobile Telephone Number” (LTN);
c) Privacy provisions;
d) Advice to PSAPs on the use of the eCall OAD LTN;
e) Example of an in-vehicle sequence generating the LTN OAD and forwarding it as part of the MSD.
For clarity, 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 15722:2015, Intelligent transport systems — eSafety — eCall Minimum set of Data
EN 16102, Intelligent transport systems — eCall — Operating requirements for third party support
EN ISO 24978, Intelligent transport systems — ITS safety and emergency messages using any available
wireless media — Data registry procedures
ISO/IEC 8825 (all parts), Information technology — ASN.1 encoding rules: Specification of Packed Encoding
Rules (PER)
ITU E.123, Notation for national and international telephone numbers, e-mail addresses and web addresses
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
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
Note 1 to Entry See EN 15722:2015, 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
5

---------------------- Page: 7 ----------------------
SIST-TS CEN/TS 17363:2019
CEN/TS 17363:2019 (E)
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
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
public safety answering point
‘first level’ responder to whom an emergency call/eCall is directed
3.5
(Bluetooth) registered phone
phone that has been registered (via Bluetooth)
3.6
(Bluetooth) linked phone
previously registered phone that is in the near presence of the Bluetooth car kit and linked to it, enabling
bi directional access between the car and the phone
4 Conformance
In order to claim conformance with this document, communication is to be established using accepted
wireless communication standards, and it is to be able to demonstrate that the MSD transferred together
with any standardized optional data elements defined herein comply with the specifications of this
document to the extent that such data are available from the vehicle.
5 Symbols and abbreviated terms
ASN.1 abstract syntax notation one (ISO 8824 (all parts)/ ISO 8825 (series))
EC European Commission
EU European Union
IVS in-vehicle system
LTN Linked mobile Telephone Number
MSD minimum set of data
OAD Optional Additional Data
PER packed encoding rules (ASN.1)
PSAP public safety answering point
UPER unaligned packet encoding rules (ASN.1)
6

---------------------- Page: 8 ----------------------
SIST-TS CEN/TS 17363:2019
CEN/TS 17363:2019 (E)
6 Requirements
6.1 General
This document describes an addendum to the standard defined in EN 15722 for the coding of the MSD
message. Any requirement from EN 15722 shall be met for the exchange of information in the additional
data block
It is foreseen that, over time, it is possible that other communication number links may become possible.
Any OAD that does not represent a standard mobile telephone number in the format defined in 6.3 shall
be defined and named separately and distinctly from the OAD concept LTN data definition specified in
6.3.
The OAD LTN shall ONLY be provided where the in-vehicle operating system can verify that the LTN
handset is operational and in or near the vehicle, i.e. linked to the vehicle, at the time of the incident. The
OAD LTN SHALL NOT be provided where such live validation is not in operation.
Specifically, if a system does not have this capability, but wishes to provide a user /driver telephone,
number to the PSAP it shall use a different means (such as a different registered OAD) or means specified
in EN 16102 or in any eCall aftermarket standards to inform the PSAP of this number.
6.2 Registration and linking of the phone
6.2.1 Registration and user consent
When acquiring use of a vehicle, the user is often given the opportunity to “register” one or more mobile
phone numbers by Bluetooth wireless connection. In normal vehicle operation this then means that
whenever the registered mobile phone is inside or in close proximity to the vehicle the vehicle will link
with it and provide hands free access to the phone and connectivity to the vehicle audio system.
In order to enable the LTN data concept value (the linked telephone number) to be transferred to the
PSAP as part of the MSD, it is required that a shortened (and translated) version of the following question
is introduced in the Bluetooth registration process and that the question is fully documented in the
0uowner's manual:
“In an emergency 112-eCall (for example after a crash), if this phone is present in the vehicle at the time
of the incident, do you consent to the number of this phone being provided to the emergency services in
order to enable the rescue services to be able to talk with you in case you immediately leave the vehicle
after the incident or the vehicle equipment is incapacitated by the incident?”.
Where the user provides consent to this question by answering confirmative, then the user shall be asked
to enter the number of the registered mobile phone in international format. The user shall be asked to
confirm or re-enter the number to ensure correctness. The number shall then be stored.
In case the user does not give his consent to the first question, does not enter a correct phone number or
does not confirm the entered phone number, no number shall be stored. In such case the OAD for linked
phone numbers shall not be used for the registered phone.
While the questions need to specifically cover each and all these aspects, the exact wording and sequence
used shall be at the determination and responsibility of the system supplier who shall be responsible to
ensure that it meets EU privacy requirements in respect of prior consent for the use of personal
information and it is fully explained in the owner’s manual.
An (informative) example of the HMI can be found in Annex C.
7

---------------------- Page: 9 ----------------------
SIST-TS CEN/TS 17363:2019
CEN/TS 17363:2019 (E)
6.2.2 Linking and unlinking
If a registered phone connects via Bluetooth, i.e. gets linked to the ca, and the user has provided a phone
number and his consent to embed this in the eCall message, the phone number shall be communicated to
the eCall device.
If the Bluetooth connection gets interrupted (for whatever reason) the eCall device shall be notified. The
eCall device shall, in such case, forget the provided number.
6.2.3 Use of phone number in case of eCall
If the registered mobile telephone is present at the time of the incident causing the eCall to be sent, and
the driver has provided consent and provided the TS11 telephone number of the mobile phone, then the
MSD that is sent as part of the eCall shall contain the OAD LTN that provides this number.
If this Bluetooth-linked mobile is not present (linked by Bluetooth to the vehicle) at the time, the eCall is
triggered, the OAD LTN shall not be sent as part of the MSD.
NOTE To be clear, at the time that this document is being developed, the OAD LTN is not required by the eCall
regulations, but the OAD LTN is a service that the equipment provider can provide to its clients and the PSAP
receiving an eCall.
6.3 Distribution of MSD data
The MSD shall be transmitted as described in EN 15722. An (informative) scheme explaining the process
can be found in Annex D.
7 Concepts and formats
7.1 MSD data concepts and representation
The MSD, as defined in EN 15722, is a direct, timely message to the PSAP operator receiving the
emergency call.
The MSD has an optional additional data block that will be used to add information elements containing
information about the phone number of (one of) the occupants.
The MSD is 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 defined in EN 15722:2015
Annex A. The message shall be sent in the sequence also defined in Annex A.
The information about the phone number of (one of) the occupants of the vehicle sending the MSD shall
be represented in ASN.1 UPER as well, following the provision made in above named Annex.
7.2 Linked phone number optional additional data concept ‘Object Identifier’
The object identifier uniquely identifies the format and meaning of the data which follows in the optional
additional data concept.
Both the syntax of the data structure and the semantic meaning of the content is referenced via this
identifier so that it can be usefully applied.
The uniqueness of each specific relative identifier is ensured by a specific international standardisation
body, and maintained in a data registry operated in accordance with EN ISO 24978. These identifiers are
all relative to a specific root. And the root of all eCall relative OID's shall be the same.
eCall has been allocated the OID 1.0.14817.106.2.1. Within this, arc ‘.2’ has been defined to contain
‘Optional Additional Data concepts’. The OID for this deliverable shall be 1.0.14817.106.2.1.2.5. To be able
to differentiate between versions, this OID is extended with an extra arc. The resulting OID is
1.0.14817.106.2.1.2.5.1.
8

---------------------- Page: 10 ----------------------
SIST-TS CEN/TS 17363:2019
CEN/TS 17363:2019 (E)
The OID for ‘Optional Additional Data concepts’ (1.0.14817.106.2.1.2) is fixed and shall not be transmitted
over the air as part of the optional additional data. The MSD data element ‘OID’ is defined as RELATIVE-
OID and shall contain 5.1 if this concept is used.
For further detail regarding the use of OIDs in eCall, see EN 15722.
7.3 Linked phone number optional additional data concept ‘data’
The objective of this data concept is to provide the PSAP with the phone number of (one of) the occupants
of the vehicle at the time of the incident. The number provided shall be in ITU E.123 international notation
without the plus sign, i.e. only the country code and the local number (without a leading zero if present).
The data concept will not take up more than the minimum amount of bytes available for the optional
additional data; as such, there is no risk of the complete MSD to exceed the maximum number of bytes
allowed by using this data concept.
7.4 Contents of the ‘Minimum Set of Data’ (MSD)
7.4.1 General
The following subclauses provide the definition of the minimum set of data that shall be sent from the
vehicle in case of an emergency call.
7.4.2 Basic contents of MSD
Table 1 provides a summary of the semantic contents of the MSD, for a full description please refer to
EN 15722.
Table 1 — Contents/format of the MSD data concept
M – Mandatory data field
O – Optional data field.
MSD
 msdVersion INTEGER - M
(1.255)
Msd
 msdStructure

optionalAdditionalData O
 oid RELATIVE-
OID
data OCTET
STRING
This document describes the contents of the optionalAdditionalData block.
9

---------------------- Page: 11 ----------------------
SIST-TS CEN/TS 17363:2019
CEN/TS 17363:2019 (E)
7.4.3 Contents of the optionalAdditionalData
Table 2 provides a summary of the semantic contents of the optionalAdditionalData part of the MSD for
this data concept.
The sequence of data presentation shall be as specified in Table 2, represented as described in 6.2 and
distributed as described in 6.3.
For clarity the ‘type’ used in Table 2 is a semantic representation of the type used in the ASN.1 definition.
The exact representation is found 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 2 — Contents/format of Linked Phone Number additional data
M – Mandatory data field (i.e. mandatory if this encoding scheme is used)
O – Optional data field.
optionalAdditionalData

oid RELATIVE OID  M Fixed value: 5.1
data  encoded as OCTET STRING
 linkedPhone NumericalString  M Consignor contact telephone number or
telephone number displayed on goods
container as contact number in case of
emergency.
The number should be specified in ITU E. 123
international format without the plus sign, but
including the country- and area code (without
zero).
8 Privacy provisions
In accordance with EN 15722, an OAD shall not include any data concerning or identifying a person
(personal data) unless the transfer of such data has been explicitly and expressly instructed prior and
authorized by the person who is identified by the data, and its provision shall, in any event, only be
provided in accordance with European Union and National privacy regulations pertaining at the time of
the transfer of any such personal data. These specifications, ensuring such compliance and prior consent,
are defined in 6.2 above.
10

---------------------- Page: 12 ----------------------
SIST-TS CEN/TS 17363:2019
CEN/TS 17363:2019 (E)
9 Advice to PSAPs on the use of the eCall OAD LTN
The optional additional data, “Linked Telephone Number” (LTN), can only be available in vehicles who
have Bluetooth linked provisions that can ascertain if a linked user telephone number is actually linked
to the vehicle at the time of the incident.
Clauses 6.2.2 and 6.2.3 above are designed to ensure that an OAD LTN is only sent if the registered phone
was actually present and operational at the time of the incident. If an in-vehicle system wishes to advise
the PSAP of a user telephone number that it has registered but cannot validate that it is in use in the
vehicle at the time of the incident, it shall use another means to do so.
This is designed to enable the PSAP to differentiate between handsets that were actually linked to the
vehicle at the time of the incident from those which 'may' be present.
The linked telephone number provided as OAD LTN in the MSD is only provided after the triggering of an
eCall so the Article 29 working party provision for eCall data is already in force.
The linked telephone number provided as OAD LTN in the MSD shall be treated by the PSAP as
confidential private information and shall be retained only under specific provisions of National
Regulations that govern the procedures of PSAPS. Normally the data shall be destroyed and erased as
soon after the incident as practicable, and PSAPs shall be responsible to provide written instruction to
operators regarding National requirements in this respect.
11

---------------------- Page: 13 ----------------------
SIST-TS CEN/TS 17363:2019
CEN/TS 17363:2019 (E)
Annex A
(informative)

ASN.1 definition of optional datablock
A.1 General
As soon as the OID has revealed the nature of the data as being the Linked Telephone Number concept
(using the standard eCall MSD message definition, see EN 15722) the data from the
optionalAdditionalData block can be decoded. Either by applying the definition of the datablock to that
data (this Annex), or by applying a constituted complete eCall MSD message definition (Annex B).
A.2 ASN.1 definition
MSD_ADDITIONAL_LTN_1 DEFINITIONS AUTOMATIC TAGS ::= BEGIN

-- Definition can be used to decode data in the data part
-- of optionalAdditionalData in the MSD message.
--

-- For use when creating MSD
ltnOID RELATIVE-OID ::= { 5 1 }

-- The concept itself
LTN ::= SEQUENCE {
  linkedPhone     NumericString(SIZE(1.17))
}

END

A.3 Syntax check of ASN.1 definition
ASN.1 Studio Version 8.0
Copyright (C) 2016 OSS Nokalva, Inc. All rights reserved.
This product is licensed for use by "Cheiron IT bv, Leiden, Holland - Standards Editor"
License "66410E",only for project "CEN TC278 WG15 related standards work", on platform(s)

ASN.1 syntax check result: C0043I: 0 error messages, 0 warning messages and 0 informatory
messages issued.

12:06:45: LTN: Compilation summary: The project LTN includes 1 PDUs and 0 ASN.1 values.
A.4 Example
The example below is shown in ASN.1 value encoding (plain text):
value LTN ::=
{
 linkedPhone "31207110123"
}

The same example encoded in UPER (hexadecimal representation, 7 bytes):
52 11 8C 11 09 1A 00
12

---------------------- Page: 14 ----------------------
SIST-TS CEN/TS 17363:2019
CEN/TS 17363:2019 (E)
Annex B
(informative)

ASN.1 definition of complete MSD message with LTN
B.1 General
ASN.1 has the possibility to include coding rules. Therefore, as soon as decoding with the definition from
EN 15722 has revealed the OID belonging to LTN, the complete message can be decoded using a
constituted decoding
...