ISO 15628:2013

INTERNATIONAL ISO
STANDARD 15628
Second edition
2013-11-01
Intelligent transport systems —
Dedicated short range communication
(DSRC) — DSRC application layer
Systèmes intelligents de transport — Communications spécialisées à
courte portée (DSRC) — Couche d’application DSRC
Reference number
©
ISO 2013
© ISO 2013
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized otherwise in any form
or by any means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior
written permission. Permission can be requested 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 2013 – All rights reserved

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 . 6
6 Transfer kernel . 7
6.1 General . 7
6.2 Services . 8
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 .27
8.3 Behaviour .28
9 Extensibility for different lower layer services and application interfaces .29
9.1 General .29
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 .44
Annex E (informative) Lower layer services .45
Bibliography .49
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.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular the different approval criteria needed for the
different types of ISO documents should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www.iso.org/directives).
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. Details of
any patent rights identified during the development of the document will be in the Introduction and/or
on the ISO list of patent declarations received (see www.iso.org/patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation on the meaning of ISO specific terms and expressions related to conformity
assessment, as well as information about ISO’s adherence to the WTO principles in the Technical Barriers
to Trade (TBT) see the following URL: Foreword - Supplementary information
ISO 15628 was prepared by Technical Committee ISO/TC 204, Intelligent transport systems.
This second edition cancels and replaces the first edition (ISO 15628:2007), which has been
technically revised.
iv © ISO 2013 – All rights reserved

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 1, 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”.
INTERNATIONAL STANDARD ISO 15628:2013(E)
Intelligent transport systems — 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
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:2008) 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 8825-2:2008, Information technology — ASN.1 encoding rules: Specification of Packed
Encoding Rules (PER)
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
3.2
attribute
value, which may have a structure, consisting of a set or sequence of data elements
Note 1 to entry: 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
2 © ISO 2013 – All rights reserved

3.7
concatenation
function performed by the transfer kernel to map multiple T-APDU fragments into one data link layer
service data unit
Note 1 to entry: The inverse function is called separation or deconcatenation.
3.8
element
coherent set of data and functionality
Note 1 to entry: 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 to entry: In ISO/IEC 7498-1, fragmentation is called segmentation.
Note 2 to entry: 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 1 to entry: 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.
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.6
ASN.1
abstract syntax notation one (ISO/IEC 8824-1)
4.7
ASTM
American Society of Testing and Materials
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 © ISO 2013 – All rights reserved

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
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 1 to entry: 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:2008)
4.33
RSU
road-side unit
Note 1 to entry: This is often referred to as beacon.
4.34
RTTT
road transport and traffic telematics
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.
6 © ISO 2013 – All rights reserved

Figure 3 — Context and structure of the application layer core
6 Transfer 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.2.5.
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.2.5 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;
— 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:
8 © ISO 2013 – All rights reserved

— 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
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
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
10 © ISO 2013 – All rights reserved

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 is 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.2.11, is performed.
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;
— 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.2.11, “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.
12 © ISO 2013 – All rights reserved

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.2.5 Behaviour
The transfer protocol shall consist of the following steps, described in 6.2.6 to 6.2.17:
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
fragments, and
k) translating PDU to SDU and distribution to addressee.
NOTE 1 The implementation of individual steps is outside the scope of this International Standard as long as
their (externally observable) behaviour complies with requirements below. An implementation may even change
the order of steps as long as this does not have any implication for its peer implementation and for the overall
behaviour of the whole sequence of steps, i.e. for the T-APDUs and the LPDUs.
NOTE 2 The arrows shown in Figures 6 to 8 and 10 to 17 indicate the conversion process.
Figure 6 — Functionality of the T-Kernel
6.2.6 SDU to PDU
The T-Kernel shall translate the request and response service primitive into T-APDUs according to the
following rules.
A service.request is translated into the corresponding service-request T-APDU defined in Annex A. A
service.response is translated into the corresponding service-response T-APDU defined in Annex A. The
LID shall be removed and shall be given to the LLC in each LLC service primitive as defined in 6.2.12. In
the case of the INITIALISATION.request, the LID field shall be 1111 1111 .
Figure 7 — SDU to PDU
14 © ISO 2013 – All rights reserved

6.2.7 Encoding
The T-Kernel shall encode the request and response PDUs according to ASN.1 BASIC-PER, UNALIGNED
(ISO/IEC 8825-2:2008). The encodable ASN.1 types are specified in Annex A. The fill bit of ASN.1-type
definitions shall be set to zero.
NOTE In order to mitigate the implication of UNALIGNED encoding, some fill bits are included in the ASN.1-
type definition in Annex A. The encoding result is always an integral multiple of eight bits (octet). The octet
alignment and octet dealignment procedures are performed in PDU encoding and decoding steps, if it is needed.
The octet alignment and octet dealignment procedures are outside the scope of this International Standard. Refer
to 10.1 of ISO/IEC 8825-2:2008.
Figure 8 — Encoding
6.2.8 Fragmentation
The T-Kernel shall fragment encoded T-APDUs down to T-APDU fragments, which include a fragmentation
header. A fragmentation header shall have a length of at least 1 octet and at most 3 octets. The length
of the T-APDU fragments shall not exceed the maximum LLC frame length. The number of bits inside a
fragment shall be a multiple of 8 bits. All but the last fragment shall have the same length. Fragmentation
shall be made from the most significant bit down to the least significant bit according to ASN.1 BASIC-PER.
NOTE 1 Fragmentation is based on the property that the length of the PER encoded T-APDU is a multiple of
eight bits.
Fragmentation of multiple PDUs shall be done in parallel.
NOTE 2 As fragmentation is done in parallel, the fragmentation of a small T-APDU may be finished before a
larger one that was received from the SAP before the smaller one. As a consequence, T-APDUs with the same
priority might not be sent in the same order as they were received from the SAP.
A T-APDU fragment that contains a complete T-APDU is called a single-T-APDU.
6.2.8.1 Fragmentation header
The first octet of the fragmentation header shall be the first octet of the fragment. If the fragmentation header
consists of more than one octet, these octets are given in increasing order directly after the first octet.
6.2.8.2 Structure of the fragmentation header
The fragmentation header shall consist of one fragmentation indicator, one PDU number, one fragment
counter, and one fragment number extension indicator. The position of the related bits is described in
Figure 9. The bits are numbered from 7 to 0, where bit 7 is the most significant and bit 0 is the least
significant bit.
Figure 9 — One-octet fragmentation header
6.2.8.3 Fragmentation indicator
The most significant bit (bit 7) of any fragmentation header shall be the fragmentation indicator. The
fragmentation indicator shall be 1 if this fragment is the last of a sequence of fragments belonging to
one PDU or if the PDU is not fragmented. The fragmentation indicator shall be 0 if fragmentation is
performed and if it is not the last fragmented frame in a message.
6.2.8.4 PDU number
Bits 6 to 3 of the first octet represent a PDU number, which shall be unique for each LID during the
defragmentation time in the receiving entities and the same in all T-APDU fragments belonging to one
T-APDU. PDU number 0000 and 0001 shall only be used by T-APDU fragments that are sent by the B-Kernel.
2 2
6.2.8.5 One-octet fragmentation header
A one-octet fragmentation header shall be used if no fragmentation is performed or, if fragmentation
is performed, for fragments numbered 0 to 3. A fragment counter shall be used to identify a fragment.
Bits 2 and 1 shall be interpreted as an unsigned integer, where the highest significant bit is bit 2 of the
first octet and the least significant bit is bit 1 of the first octet. Bit 0 shall be set to 1 . If fragmentation
is performed then the first fragment shall be given the fragment counter value 0, the second fragment
the fragment counter value 1, etc. If no fragmentation is performed, then the fragment shall be given the
fragment counter value 0.
6.2.8.6 Two-octet fragmentation header
A two-octet fragmentation header shall be used for fragments between 4 and 511; bit 0 of the first octet
shall be set to 0 . Bits 2 and 1 of the first octet and bits 7 to 1 of the second octet shall be interpreted as
an unsigned integer, where the highest significant bit is bit 2 of the first octet and the least significant
bit is bit 1 of the second octet. Bit 0 of the second octet shall be set to 1 . Fragment numbers shall be
assigned to the fragment as specified in 6.2.8.5.
6.2.8.7 Three-octet fragmentation header
A three-octet fragmentation header shall be used for fragments between 512 and 65535; bit 0 of the
first octet shall be set to 0 . Bits 2 and 1 of the first octet, bits 7 to 1 of the second octet and bits 7 to 1
of the third octet are interpreted as unsigned integers, where the highest significant bit is bit 2 of the
first octet and the least significant bit is bit 1 of the third octet. Bit 0 of the second octet shall be set to
0 and bit 0 of the third octet shall be set to 1 . Fragment numbers shall be assigned to the fragment as
2 2
specified in 6.2.8.5.
16 © ISO 2013 – All rights reserved

Figure 10 — Fragmentation
6.2.9 Multiplexing
The T-Kernel shall multiplex the T-APDU fragments according to a head-of-the-line strategy where the
priorities are given by the I-Kernel (see 7.3.2).
NOTE Apart from respecting priorities, this International Standard does not impose any restriction on how
a multiplexer should serve the queues. As a consequence, T-APDUs with the same priority may not be sent in the
same order as they were fragmented.
Figure 11 — Multiplexing
6.2.10 Concatenation
Multiple consecutive T-APDU fragments may be mapped on one LLC service if the services and the LID
used in the services are the same and the size constraints for the LLC frames are not violated. The order
of the T-APDU fragments inside the LSDU shall be the one given by the multiplexing procedure.
NOTE These conditions for concatenation will only occur in the following two situations.
— One or more T-APDU fragments, each containing one short, unfragmented T-APDU, are mapped on one LSDU.
— One or more T-APDU fragments, each containing one short, unfragmented T-APDU, are mapped on one LSDU
after the last fragment of a series of T-APDU fragments belonging to one T-APDU.
Figure 12 — Concatenation
6.2.11 Concatenation with chaining
A chain consists of consecutive and ordered concatenated T-APDU fragments having the same PDU number.
The execution of operations invoked by a T-APDU belonging to a chain is dependent on the successful
execution of the operations invoked in the previous T-APDU fragments of the same chain.
If a chained T-APDU fragment generates a response T-APDU fragment with a ReturnStatus different
from “no error”, none of the operations invoked by the subsequent T-APDU fragments of the same chain
shall be performed and all associated responses shall contain a ReturnStatus of “chainingError”.
NOTE If a chaining parameter has the value “true”, and the procedures defined in 6.2.11 are ignored, it would
not affect the whole peer-to-peer protocol because the chaining parameters are not passed to a peer receiver side.
6.2.12 Access to LLC
The T-Kernel shall use the LLC service assigned in the FlowControl parameter of the T-ASDU. The
FlowControl parameter shall be interpreted as defined in 6.2.4. For the INITIALISATION.request service
the “DL-UNITDATA.request with response request” service shall be used; for the INITIALISATION.
response service, the “DL-UNITDATA.request without response request” service shall be used.
Figure 13 — Access to LLC
6.2.13 Access from LLC
The T-Kernel on the receiving side shall receive the LSDUs in the LLC indication primitives via the LSAP.
6.2.14 Demultiplexing
The T-Kernel shall demultiplex the LSDUs containing one or more concatenated T-APDU fragments
according to the PDU number in the first fragmentation header.
The T-Kernel shall demultiplex LSDUs containing concatenated T-APDU fragments according to the PDU
number in the first fragmentation header.
18 © ISO 2013 – All rights reserved

An LSDU with an invalid first fragmentation header shall be discarded.
NOTE 1 This results in queues in which all LSDUs have the same PDU number in their first fragment header.
As subsequent T-APDU fragments in an LSDU can only be single-T-APDU fragments, all T-APDU fragments from a
T-APDU will be put in the same queue.
NOTE 2 As only a decoder that knows the type of PDUs to be decoded can determine the length of a PER-
encoded PDU, the demultiplexer cannot determine the length of concatenated T-APDU fragments. Therefore,
separation of concatenated T-APDU fragments is postponed until the decoding step. As this demultiplexing step
guarantees that any two T-APDU fragments with the same PDU number will always be put in the same queue, this
demultiplexing (separation) can indeed be solved later.
Figure 14 — Demultiplexing
6.2.15 Defragmentation
The T-Kernel shall defragment the LSDUs per queue, i.e. all LSDUs with same PDU number in the first
fragmentation header, by removing in each LSDU the first fragmentation header and by concatenating
the remaining LSDU parts according to the fragment number in the first fragmentation header. If the
fragmentation header is not valid, the LSDU and all other LSDUs with same PDU number in their first
fragmentation header shall be discarded.
NOTE 1 This defragmentation results in octet strings that contain one complete T-APDU possibly concatenated
with one or more single-T-APDU fragments.
NOTE 2 As only a decoder that knows the type of PDUs to be decoded can determine the length of a PER-
encoded PDU, the defragmenter cannot determine the length of the first T-APDU and therefore cannot separate
a T-APDU from any concatenated single-T-APDU fragments. The separation of concatenated T-APDU fragments is
postponed until the decoding step.
NOTE 3 As one defective first fragmentation header will cause the deletion of all LSDUs with the same PDU
number in their first fragmentation header, such a defect will cause the deletion of any concatenated single-T-
APDU fragments.
If one or more T-APDU fragment headers of a T-APDU are still missing when T-APDU fragments with the
eight higher PDU numbers (out of 14 cyclically used values) are received, all LSDUs with a PDU number
equal to the PDU number of a missing T-APDU fragment are discarded.
NOTE 4 As the T-APDU fragments could not be interpreted, a T-Kernel cannot determine whether or not a
discarded T-APDU is part of an indication or part of a conformance application service primitive, or whether it
was part of an action, an event-report, a set or a get. The T-Kernel is therefore unable to generate or assist an
application element in generating a T-APDU with the correct value of the ReturnStatus.
Figure 15 — Defragmentation
6.2.16 Decoding and separation
The T-Kernel shall decode the defragmented T-APDU according to ASN.1 BASIC-PER, UNALIGNED
(ISO 8825-2:2008). The decodable ASN.1 types are specified in Annex A.
When provided with an octet string containing a T-APDU with possibly concatenated single-T-APDU
fragments, the decoder (separator) proceeds decoding steps as described below.
1) It decodes the T-APDU.
2) If it does not succeed in decoding the T-APDU, the whole octet string is discarded.
3) If it succeeds in decoding the T-APDU, it passes the decoded T-APDU to the next procedure (see 6.2.17).
4) It shall look for trailing octets and assume that these remaining octets contain one more single-T-
APDU fragments.
5) It shall check the validity of the first fragment header of the remaining octet string (bit 2 to bit 0
shall have the value “001 ”).
6) If the first fragment header is invalid, all the remaining T-APDU fragments shall be discarded.
7) If the first fragment header of the T-APDU is valid, the fragment header shall be removed and the
decoder (separator) shall proceed decoding with step 1.
This requires an ASN.1 decoder that does not collapse when it has to decode an octet string longer than
the PDU to be decoded. The decoder should even be able to return the remaining octet string. Whether or
not such an ASN.1 decoder is commercially available is outside the scope of this International Standard.
Figure 16 — Decoding
20 © ISO 2013 – All rights reserved

6.2.17 PDU to SDU
The decoded T-APDU shall be used to build the T-ASDU according to the following rules.
A service-request shall be translated into the corresponding service.indication T-ASDU. A service-
response shall be translated into the corresponding service.con
...