ISO 15628:2007

INTERNATIONAL ISO
STANDARD 15628
First edition
2007-02-01

Road transport and traffic telematics —
Dedicated short range communication
(DSRC) — DSRC application layer
Télématique du transport routier et de la circulation (TICS) —
Communication de courte portée dédiée (DSRC) — Couche
d'application DSRC




Reference number
ISO 15628:2007(E)
©
ISO 2007

---------------------- Page: 1 ----------------------
ISO 15628:2007(E)
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but
shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In
downloading this file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat
accepts no liability in this area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation
parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In
the unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given below.


©  ISO 2007
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or
ISO's member body in the country of the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland

ii © ISO 2007 – All rights reserved

---------------------- Page: 2 ----------------------
ISO 15628:2007(E)
Contents Page
Foreword. iv
Introduction . v
1 Scope . 1
2 Normative references . 2
3 Terms and definitions. 2
4 Abbreviations . 4
5 Structure of the application layer core. 7
6 T-Kernel . 8
6.1 General. 8
6.2 Services . 8
6.3 Behaviour . 13
7 Initialisation kernel . 21
7.1 General. 21
7.2 Services . 21
7.3 Behaviour . 24
8 Broadcast kernel. 27
8.1 General. 27
8.2 Services . 28
8.3 Behaviour . 29
9 Extensibility for different lower layer services and application interfaces . 30
9.1 General. 30
9.2 Extended definitions. 30
Annex A (normative) Data structures. 34
Annex B (normative) Naming and registration. 40
Annex C (informative) Example of coding . 41
Annex D (normative) Declaration of application layer features supported. 43
Annex E (informative) Lower layer services. 44
Bibliography . 49

© ISO 2007 – All rights reserved iii

---------------------- Page: 3 ----------------------
ISO 15628:2007(E)
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies
(ISO member bodies). The work of preparing International Standards is normally carried out through ISO
technical committees. Each member body interested in a subject for which a technical committee has been
established has the right to be represented on that committee. International organizations, governmental and
non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the
International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of technical committees is to prepare International Standards. Draft International Standards
adopted by the technical committees are circulated to the member bodies for voting. Publication as an
International Standard requires approval by at least 75 % of the member bodies casting a vote.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO shall not be held responsible for identifying any or all such patent rights.
ISO 15628 was prepared by Technical Committee ISO/TC 204, Intelligent transport systems.
iv © ISO 2007 – All rights reserved

---------------------- Page: 4 ----------------------
ISO 15628:2007(E)
Introduction
The communication requirements of many ITS applications can be fulfilled by DSRC. The DSRC International
Standards enable compliant communication systems to serve multiple ITS applications in parallel.
The small service areas and severe real-time constraints require a specific protocol architecture leading to the
reduced protocol stack shown in Figure A, built up by the “application layer”, the “data link layer” and the
“physical layer”. Such architecture is very common for real-time environments.
This International Standard gives the architecture and services offered by the DSRC application layer.

Figure 1 — DSRC protocol stack
This International Standard contains, besides the normative main body, three normative annexes: “Data
structures”, “Naming and registration”, “Declaration of application layer features supported”; plus two
informative annexes: “Example of coding” and “Lower layer services”.

© ISO 2007 – All rights reserved v

---------------------- Page: 5 ----------------------
INTERNATIONAL STANDARD ISO 15628:2007(E)

Road transport and traffic telematics — Dedicated short range
communication (DSRC) — DSRC application layer
1 Scope
This International Standard specifies the application layer core which provides communication tools for
applications based on DSRC. These tools consist of kernels that can be used by application processes via
service primitives. The application processes, including application data and application-specific functions, are
outside the scope of this International Standard.
This International Standard is named “application layer”, although it does not cover all functionality of OSI
Layer 7 and it includes functionality from lower layers.
It uses services provided by DSRC data link layer, and covers functionality of intermediate layers of the “OSI
Basic Reference Model” (ISO/IEC 7498-1).
Figure 2 illustrates the global data flow between the parts of the DSRC stack (physical, data link and
application layers) and the application.


NOTE For definitions of the terms used in Figure 2, see ISO/IEC 7498-1.
Figure 2 — Architecture and data flow of the DSRC stack
© ISO 2007 – All rights reserved 1

---------------------- Page: 6 ----------------------
ISO 15628:2007(E)
The following subjects are covered by this International Standard:
⎯ application layer structure and framework;
⎯ services to enable data transfer and remote operations;
⎯ application multiplexing procedure;
⎯ fragmentation procedure;
⎯ concatenation and chaining procedures;
⎯ common encoding rules to translate data from abstract syntax ASN.1 (ISO/IEC 8824-1) into transfer
syntax (ISO/IEC 8825-2:2002) and vice versa;
⎯ communication initialisation and release procedures;
⎯ broadcast service support;
⎯ DSRC management support including communication profile handling; and
⎯ extensibility for different lower layer services and application interfaces.
It is outside the scope of this International Standard to define a security policy. Some transport mechanisms
for security-related data are provided.
NOTE No implementation of the “broadcast pool” functionality has become known. “Broadcast pool” functionality is
therefore considered untested.
2 Normative references
The following referenced documents are indispensable for the application 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.
ISO/IEC 7498-1, Information technology — Open Systems Interconnection — Basic Reference Model: The
Basic Model
ISO/IEC 8824-1, Information technology — Abstract Syntax Notation One (ASN.1): Specification of basic
notation
ISO/IEC 8825-2:2002, Information technology — ASN.1 encoding rules: Specification of Packed Encoding
Rules (PER)
ISO 14816, Road transport and traffic telematics — Automatic vehicle and equipment identification —
Numbering and data structure
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
3.1
application
user of the services offered by the DSRC communication stack
2 © ISO 2007 – All rights reserved

---------------------- Page: 7 ----------------------
ISO 15628:2007(E)
3.2
attribute
value, which may have a structure, consisting of a set or sequence of data elements
NOTE The value of an “attribute” can be observed or modified by sending a request to GET (read) or SET (write) the
value.
3.3
attribute identifier
identifier which unambiguously distinguishes an attribute from all other attributes within the same element
3.4
beacon service table
data structure transmitted by the RSU indicating available services
3.5
broadcast pool
data structure broadcast from the RSU to the OBUs
3.6
chaining
function performed by the transfer kernel to link the execution of service primitives
3.7
concatenation
function performed by the transfer kernel to map multiple T-APDU fragments into one data link layer service
data unit
NOTE The inverse function is called separation or deconcatenation.
3.8
element
coherent set of data and functionality
NOTE Application elements are created by the applications and are addressed using element identifiers.
3.9
element identifier
identifier which unambiguously distinguishes an element from all other elements residing in the same OBU
3.10
fragmentation
function performed by the transfer kernel to map one ASDU on multiple LSDUs
NOTE 1 In ISO/IEC 7498-1, fragmentation is called segmentation.
NOTE 2 The inverse function is called defragmentation or, in ISO/IEC 7498-1, disassembling.
3.11
head of the line
queuing discipline (also referred to as strict or fixed priority queuing), where a number of queues are served in
priority order
NOTE A lower priority queue is served if all higher priority queues are empty, each queue is served in “first come,
first served” order, and each user goes to the head of the line of the users of lower priorities but behind all users of equal
or higher priority.
© ISO 2007 – All rights reserved 3

---------------------- Page: 8 ----------------------
ISO 15628:2007(E)
3.12
management
provides and distributes values for the communication parameters for controlling the DSRC communication
stack
3.13
multiplexing
function within the transfer kernel allowing simultaneous support for more than one application in a single
OBU
3.14
operation
abstract representation of behaviour invoked in an entity
3.15
profile
information about capabilities and settings in the different DSRC layers
3.16
single-T-APDU fragment
T-APDU that contains a complete PDU
3.17
T-APDU fragment
fragment header followed by part or all of the encoding of a value of the ASN.1 type T-APDUs
3.18
time
number of seconds passed since 1st January 1970, 00:00 (UTC)
3.19
vehicle service table
data structure transmitted by the OBU indicating available services
4 Abbreviations
For the purposes of this document, the following abbreviations apply.
4.1
ADU
application data unit
4.2
AID
application identifier
4.3
APDU
application protocol data unit
4.4
ARIB
Association of Radio Industries and Businesses
4.5
ASDU
application service data unit
4 © ISO 2007 – All rights reserved

---------------------- Page: 9 ----------------------
ISO 15628:2007(E)
4.6
ASN.1
abstract syntax notation one (ISO/IEC 8824-1)
4.7
ASTM
American Society of Testing and Material
4.8
B-Kernel
broadcast kernel
4.9
BST
beacon service table
4.10
CEN
Comité européen de normalisation
4.11
DSRC
dedicated short range communication
4.12
EID
element identifier
4.13
EVENT-RT
event-report
4.14
FCS
frame check sequence
4.15
ID
identifier
4.16
IEEE
Institute of Electrical and Electronic Engineers
4.17
IID
invoker identifier
4.18
I-Kernel
initialisation kernel
4.19
LID
logical link control identifier
4.20
LLC
logical link control
© ISO 2007 – All rights reserved 5

---------------------- Page: 10 ----------------------
ISO 15628:2007(E)
4.21
LPDU
LLC protocol data unit
4.22
LSDU
LLC service data unit
4.23
L1
layer 1 of DSRC (physical layer)
4.24
L2
layer 2 of DSRC (data link layer)
4.25
L7
application layer core of DSRC
4.26
MAC
medium access control
4.27
NEN
Nederlands Normalisatie-instituut
4.28
OBU
on-board unit
NOTE This equipment usually resides on board a vehicle.
4.29
PDU
protocol data unit
4.30
PPDU
physical layer protocol data unit
4.31
PSDU
physical layer service data unit
4.32
PER
packed encoding rules (ISO/IEC 8825-2:2002)
4.33
RSU
road-side unit
NOTE This is often referred to as beacon.
4.34
RTTT
road transport and traffic telematics
6 © ISO 2007 – All rights reserved

---------------------- Page: 11 ----------------------
ISO 15628:2007(E)
4.35
SDU
service data unit
4.36
T-APDU
transfer application protocol data unit
4.37
T-Kernel
transfer kernel
4.38
VST
vehicle service table
5 Structure of the application layer core
The “application layer core” shall consist of the T-Kernel and either the I-Kernel or the B-Kernel, or both.
Figure 3 shows the application layer kernels and the relationships to external entities. The T-Kernel provides
the basic transportation facilities that can be used by the I-Kernel, by the B-Kernel and by the applications.

Figure 3 — Context and structure of the application layer core
© ISO 2007 – All rights reserved 7

---------------------- Page: 12 ----------------------
ISO 15628:2007(E)
6 T-Kernel
6.1 General
The T-Kernel shall transfer information between two peer kernels or applications, and shall abstract from the
realization of this transfer.
The T-Kernel shall offer its services by means of service primitives defined in 6.2.2.
The T-Kernel shall transfer the information by means of T-APDUs defined in Annex A.
The T-Kernel shall realize the transfer by means of a protocol with the behaviour defined in 6.3.
The T-Kernel shall use the services of the logical link control sub-layer of the DSRC data link layer, which is
defined in Clause 9 and Annex E.
NOTE The behaviour defined in 6.3 does not guarantee that the service elements with the same priorities will be
delivered to a receiving application in the same order as they were delivered to the T-Kernel on the sending side.
6.2 Services
6.2.1 General
The T-Kernel shall provide the following services:
⎯ GET: The invocation of the “GET” service by an application shall result in the retrieval (reading) of
information (i.e. attributes) from a peer application. The service shall only be requested in a confirmed
mode, and a reply is expected.
⎯ SET: The invocation of the “SET” service by an application shall result in the modification (writing) of
information (i.e. attributes) by a peer application. The service may be requested in confirmed or
non-confirmed mode. In confirmed mode, a reply is expected.
⎯ ACTION: The invocation of the “ACTION” service by an application shall result in the performance of an
action by a peer application. An action is further qualified by the value of the “ActionType” (see ISO 14906
for examples). The service may be requested in confirmed or non-confirmed mode. In confirmed mode, a
reply is expected.
⎯ EVENT-REPORT: The invocation of the “EVENT-REPORT” service by an application or by the I-Kernel
shall result in the notification of an event to a peer application or I-Kernel. The service may be requested
in confirmed or non-confirmed mode. In confirmed mode, a reply is expected.
⎯ INITIALISATION: The invocation of the “INITIALISATION” service by the I-Kernel shall result in an
attempt to initialise the communication between an RSU and each OBU that has not yet established
communication with that RSU. The “INITIALISATION” service shall only be used by the I-Kernel.
6.2.2 Service primitives
The T-Kernel shall provide the services given in 6.2.1 by the following service primitives:
⎯ GET.request;
⎯ GET.indication;
⎯ GET.response;
⎯ GET.confirm;
8 © ISO 2007 – All rights reserved

---------------------- Page: 13 ----------------------
ISO 15628:2007(E)
⎯ SET.request;
⎯ SET.indication;
⎯ SET.response;
⎯ SET.confirm;
⎯ ACTION.request;
⎯ ACTION.indication;
⎯ ACTION.response;
⎯ ACTION.confirm;
⎯ EVENT-REPORT.request;
⎯ EVENT-REPORT.indication;
⎯ EVENT-REPORT.response;
⎯ EVENT-REPORT.confirm:
⎯ INITIALISATION.request;
⎯ INITIALISATION.indication;
⎯ INITIALISATION.response;
⎯ INITIALISATION.confirm.
The INITIALISATION.request and INITIALISATION.confirm primitives shall only be used on the RSU side, the
INITIALISATION.indication and INITIALISATION.response primitives shall only be used on OBU side.

Figure 4 — Services used in confirmed mode


Figure 5 — Services used in non-confirmed mode
© ISO 2007 – All rights reserved 9

---------------------- Page: 14 ----------------------
ISO 15628:2007(E)
6.2.3 Format of service primitives
The T-ASDUs for the service primitives shall have the formats defined in Tables 2 to 6, with the notation
defined in Table 1.
Table 1 — Definition of the expressions used in Tables 2 to 5
Symbol Definition
iid/eid Mandatory. IID of related indication if present, else EID of related indication.
optional The use of the optional fields is detailed by the underlying ASN.1 standards.
= Same as in corresponding request/indication.
⎯ Not applicable.

Table 2 — Format of the GET service primitives
Parameter name Request/indication Response Confirm ASN.1 type
Invoker identifier (IID) optional = Dsrc-EID
Link identifier (LID) mandatory = BIT STRING
Chaining mandatory = Boolean
Element identifier (EID) mandatory iid/eid Dsrc-EID
Access credentials optional ⎯ OCTET STRING
Attribute Id list (AttrIdList) optional ⎯ AttributeIdList
FlowControl mandatory mandatory optional INTEGER
Attribute list (AttrList) ⎯ optional AttributeList
Return code (Ret) ⎯ optional ReturnStatus

Table 3 — Format of the SET service primitives
Parameter name Request/indication Response Confirm ASN.1 type
Invoker identifier (IID) optional = Dsrc-EID
Link identifier (LID) mandatory = BIT STRING
Chaining mandatory = Boolean
Element identifier (EID) mandatory iid/eid Dsrc-EID
Access credentials optional ⎯ OCTET STRING
Attribute list (AttrList) mandatory ⎯ AttributeList
Mode mandatory ⎯ Boolean
FlowControl mandatory mandatory optional INTEGER
Return code (Ret) ⎯ optional ReturnStatus

10 © ISO 2007 – All rights reserved

---------------------- Page: 15 ----------------------
ISO 15628:2007(E)
Table 4 — Format of the ACTION service primitives
Parameter name Request/indication Response Confirm ASN.1 type
Invoker identifier (IID) optional = Dsrc-EID
Link identifier (LID) mandatory = BIT STRING
Chaining mandatory = Boolean
Element identifier (EID) mandatory iid/eid Dsrc-EID
ActionType mandatory ⎯ INTEGER(0.127,.)
Access credentials optional ⎯ OCTET STRING
ActionParameter optional ⎯ Container
Mode mandatory ⎯ Boolean
FlowControl mandatory mandatory optional INTEGER
ResponseParameter ⎯ optional Container
Return code (Ret) ⎯ optional ReturnStatus

Table 5 — Format of the EVENT-REPORT service primitives
Parameter name Request/indication Response Confirm ASN.1 type
Invoker identifier (IID) optional = Dsrc-EID
Link identifier (LID) mandatory = BIT STRING
Chaining mandatory = Boolean
Element identifier (EID) mandatory iid/eid Dsrc-EID
EventType mandatory ⎯ INTEGER(0.127,.)
Access credentials optional ⎯ OCTET STRING
EventParameter optional ⎯ Container
Mode mandatory ⎯ Boolean
FlowControl mandatory mandatory optional INTEGER
Return code (Ret) ⎯ optional ReturnStatus

Table 6 — Format of the INITIALISATION service primitives
Parameter name Request/indication Response Confirm ASN.1 type

Link identifier (LID) mandatory mandatory (private) BIT STRING
Initialisation parameter mandatory (BST) mandatory (VST) BST/VST

6.2.4 Parameters
The parameters shall be set and interpreted as follows:
IID shall be of ASN.1 type Dsrc-EID and carry the identifier of the element initiating the request or the
response, respectively. This parameter is not needed if an answer shall be sent to a default invoker. If IID is
used, it shall contain the EID of the response to this primitive.
LID shall be the LID chosen by the I-Kernel on the OBU side as specified in 7.3.2.
Chaining shall be a Boolean parameter. If true, “concatenation with chaining”, defined in 6.3.6, is performed.
© ISO 2007 – All rights reserved 11

---------------------- Page: 16 ----------------------
ISO 15628:2007(E)
EID shall be of ASN.1 type Dsrc-EID and carry the identifier of the element that shall receive the indication or
confirm related to a request or response, respectively. This EID is used by the T-Kernel on the side of the
receiver to deliver an indication or a confirm to the addressed element. When the IID is used in a request, the
element invoking a response shall use this IID as the EID.
AccessCredentials shall be of ASN.1 type OCTET STRING and carry security-related information needed to
fulfil access conditions in order to perform the operation on the addressed element.
AttrIdList shall be a list of IDs of attributes of the element receiving a GET.indication. The values of these
attributes shall be sent via a GET.response and GET.confirm to the element invoking the GET.request,
provided that applicable access conditions have been fulfilled.
FlowControl shall be a parameter that represents the behaviour of the underlying communication service. This
parameter shall be mapped by the T-Kernel on a certain LLC-service. The relation between FlowControl
parameter, application layer behaviour and LLC service shall be as defined in Table 7. Other lower layer (LLC)
services related or not related to this table are described in Clause 9 and Annex E.
Table 7 — Relation between FlowControl parameter, application layer behaviour and LLC service
Flow- Application layer LLC service
Control
1 no flow control, no answer DL-UNITDATA.request without response request
2 no flow control, answer DL-UNITDATA.request with response request
3 no flow control DL-UNITDATA.indication
4 flow control, data unit transmission DL-DATA-ACK.request
5 flow control, data unit transmission DL-DATA-ACK.indication
6 flow control, data unit transmission status DL-DATA-ACK-STATUS.indication
7 flow control, data unit exchange DL-REPLY.request
8 flow control, data unit exchange DL-REPLY.indication
9 flow control, data unit exchange status DL-REPLY-STATUS.indication
10 flow control, data unit exchange preparation DL-REPLY-UPDATE.request
11 flow control, data unit exchange preparation status DL-REPLY-UPDATE-STATUS.indication

AttrList shall be a sequence of attributes sent by SET.request/SET.indication or GET.response/GET.confirm.
The element receiving a SET.indication shall modify the values of the attributes identified in the AttrIdList to
the values given in the AttrIdList, provided that applicable access conditions have been fulfilled. In the case of
GET.response/GET.confirm, the element that received the corresponding GET.indication shall send the
values of the attributes addressed in the AttrIdList of the GET.indication to the element invoking the
GET.request, provided that applicable access conditions have been fulfilled.
Ret shall be a return code issued as an answer to a service.indication. The following codes are predefined:
⎯ noError: the requested operation was performed successfully;
⎯ accessDenied: the requested operation was not performed for reasons pertinent to the security of the
system;
⎯ argumentError: one or more attribute values were not accessed because the identifier for the specified
attribute was not recognized or the attribute value specified was out of range or otherwise inappropriate
for one or more attributes, or the action or event-report invoked was not supported by the receiving entity;
⎯ complexityLimitation: the requested operation was not performed because a parameter was too complex;
⎯ processingFailure: a general failure in processing the operation was encountered;
12 © ISO 2007 – All rights reserved

---------------------- Page: 17 ----------------------
ISO 15628:2007(E)
⎯ processing: the requested operation is being processed, and the result is not yet available;
⎯ chainingError: the requested operation was not performed in accordance with the rule defined in 6.3.6,
“concatenation with chaining”.
Mode shall be a Boolean parameter. If true, then there shall be a service.response to a service.indication
(confirmed mode).
ActionType shall identify an operation of the element which receives an ACTION.indication and which shall be
invoked.
ActionParameter shall be the information needed for the invocation of an operation identified in an
ACTION.indication.
ResponseParameter may be information resulting from the execution of the operation invoked by
ACTION.indication.
EventType shall identify the message which shall be delivered to an element which receives an
EVENT-REPORT.indication.
EventParameter shall be the additional information needed for the message sent via an
EVENT-REPORT.request and EVENT-REPORT.indication, respectively.
Initialisation parameter shall be the information needed for the initialisation of the communication (i.e. the BST
on the downlink and VST on the uplink) sent via an initialisation service.
6.3 Behaviour
The transfer protocol shall consist of the following steps, described in 6.3.1 to 6.3.12:
a) translating SDU to a T-APDU,
b) encoding of the T-APDU,
c) fragmentation of the T-APDU,
d) multiplexing of T-APDU fragments,
e) concatenation of short T-APDU fragments,
f) access to the LLC,
g) access from the LLC,
h) demultiplexing of T-APDU fragments,
i) defragmentation of non-concatenated T-APDU fragments,
j) decoding and separation of a T-APDU, possibly concatenated with one or more single-T-APDU fragm
...