ISO 15765-2:2024

International
Standard
ISO 15765-2
Fourth edition
Road vehicles — Diagnostic
2024-04
communication over Controller
Area Network (DoCAN) —
Part 2:
Transport protocol and network
layer services
Véhicules routiers — Communication de diagnostic sur
gestionnaire de réseau de communication (DoCAN) —
Partie 2: Protocole de transport et services de la couche réseau
Reference number
© ISO 2024
All rights reserved. Unless otherwise specified, or required in the context of its implementation, 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
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii
Contents Page
Foreword .v
Introduction .vi
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Symbols and abbreviated terms. 2
4.1 Symbols .2
4.2 Abbreviated terms .3
5 Conventions . 4
6 I SO 11898-1 CAN data link layer extension . 5
6.1 CAN CC and CAN FD frame feature comparison .5
6.2 Mapping of transport and network layer attributes to CAN data frames .5
7 T_Data abstract service primitive interface definition . 7
7.1 T_Data services.7
7.2 T_Data interface .7
7.3 Data type definitions .8
8 Transport and network layer services . . 8
8.1 General .8
8.2 Transport and network layer abstract service primitives .9
8.2.1 Data.req .9
8.2.2 Data.con .10
8.2.3 Data_FF.ind .10
8.2.4 Data.ind . . .10
8.2.5 ChangeParameter.req .11
8.2.6 ChangeParameter.con .11
8.3 Service data unit specification . 12
8.3.1 Mtype, message type . 12
8.3.2 AI, address information . 12
8 .3 .3  .14
8 . 3 .4  .14
8.3.5  .14
8.3.6 < Parameter_Value>.14
8.3.7 . 15
8.3.8 < Result_ChangeParameter> .16
8.4 ASP T_Data to TL_Data interface parameter mapping .16
9 Transport layer protocol. 17
9.1 Protocol functions .17
9.2 Single frame message transmission .17
9.3 Multiple frame message transmission .17
9.4 Transport layer protocol data units .19
9.4.1 Protocol data unit types .19
9.4.2 SF TL_PDU .19
9.4.3 FF TL_PDU .19
9.4.4 CF TL_PDU .19
9.4.5 FC TL_PDU .19
9.4.6 TL_PDU field specification .19
9.5 Transmit data length (TX_DL) configuration . . 20
9.5.1 Definition of TX_DL configuration values . 20
9.5.2 Verifying the correctness of received CAN frames . 20
9.5.3 Receiver determination RX_DL .21
9.6 Protocol control information specification . 22

iii
9.6.1 TL_PCI . 22
9.6.2 SingleFrame TL_PCI parameter definition . 23
9.6.3 FirstFrame TL_PCI parameter definition. 25
9.6.4 ConsecutiveFrame TL_PCI parameter definition . 26
9.6.5 FlowControl TL_PCI parameter definition .27
9.7 Maximum number of FC.WAIT frame transmissions (C ) .31
TL_WFTmax
9.8 Transport layer timing .31
9.8.1 Timing parameters .31
9.8.2 Transport layer timeouts . 35
9.8.3 Unexpected arrival of TL_PDU. 35
9.8.4 Wait frame error handling. 36
9.9 Interleaving of messages .37
10 Network layer protocol .37
10.1 Protocol data unit field specification .37
10.1.1 NL_PDU format .37
10.1.2 Address information (NL_AI) .37
10.2 Creating CAN frames based on NL_TAtype and TX_DL .37
10.3 Mapping of the NL_PDU fields .37
10.3.1 Addressing formats . .37
10.3.2 Normal addressing .37
10.3.3 Normal fixed addressing . 38
10.3.4 Extended addressing . 39
10.3.5 Mixed addressing . 39
11 Data link layer usage .40
11.1 Data link layer service parameters . 40
11.2 Data link layer interface services .41
11.3 CAN frame data length code (DLC) .41
11.3.1 DLC parameter .41
11.3.2 CAN frame data .41
11.3.3 Data length code (DLC) error handling .42
Annex A (normative) Use of normal fixed and mixed addressing according to SAE J1939-21 .43
Annex B (normative) Reserved CAN IDs .46
Bibliography . 47

iv
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 document 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).
ISO draws attention to the possibility that the implementation of this document may involve the use of (a)
patent(s). ISO takes no position concerning the evidence, validity or applicability of any claimed patent
rights in respect thereof. As of the date of publication of this document, ISO had not received notice of (a)
patent(s) which may be required to implement this document. However, implementers are cautioned that
this may not represent the latest information, which may be obtained from the patent database available at
www.iso.org/patents. ISO shall not be held responsible for identifying any or all such patent rights.
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and expressions
related to conformity assessment, as well as information about ISO's adherence to the World Trade
Organization (WTO) principles in the Technical Barriers to Trade (TBT), see www.iso.org/iso/foreword.html.
This document was prepared by Technical Committee ISO/TC 22, Road vehicles, Subcommittee SC 31, Data
communication.
This fourth edition cancels and replaces the third edition (ISO 15765-2:2016), which has been technically
revised.
The main changes are as follows:
— restructured the document to achieve compatibility with OSI 7-layers model;
— introduced T_Data abstract service primitive interface to achieve compatibility with ISO 14229-2;
— moved all transport layer protocol-related information to Clause 9;
— clarification and editorial corrections.
A list of all parts in the ISO 15765 series can be found on the ISO website.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www.iso.org/members.html.

v
Introduction
The ISO 15765 series defines common requirements for vehicle diagnostic systems using the controller area
network (CAN), as specified in the ISO 11898 series.
The ISO 15765 series presumes the use of external test equipment for inspection, diagnostics, repair and
other possible use cases connected to the vehicle.
This document defines the requirements to enable the in-vehicle CAN network to successfully establish,
maintain and terminate communication with the devices externally connected to the diagnostic link
connector.
This document has been structured according to the open systems interconnection (OSI) basic reference
model, in accordance with ISO/IEC 7498-1 and ISO/IEC 10731, which structures communication systems
into seven layers. When mapped on this model, the OSI layer 4 and OSI layer 3 framework requirements
specified or referenced in the ISO 15765 series are structured according to Figure 1, which shows the related
documents of OSI layer 4 and OSI layer 3.
Figure 1 — DoCAN document reference according to the OSI model

vi
International Standard ISO 15765-2:2024(en)
Road vehicles — Diagnostic communication over Controller
Area Network (DoCAN) —
Part 2:
Transport protocol and network layer services
1 Scope
This document specifies a transport and network layer protocol with transport and network layer services
tailored to meet the requirements of CAN-based vehicle network systems on controller area networks as
specified in ISO 11898-1.
The diagnostic communication over controller area network (DoCAN) protocol supports the standardized
abstract service primitive interface as specified in ISO 14229-2 (UDS).
This document supports different application layer protocols such as:
— enhanced vehicle diagnostics (emissions-related system diagnostics beyond legislated functionality,
non-emissions-related system diagnostics);
— emissions-related on-board diagnostics (OBD) as specified in the ISO 15031 series and SAE J1979 series;
— world-wide harmonized on-board diagnostics (WWH-OBD) as specified in the ISO 27145 series; and
— end of life activation of on-board pyrotechnic devices (the ISO 26021 series).
The transport protocol specifies an unconfirmed communication.
NOTE This document does not determine whether CAN CC, CAN FD or both are recommended or required to be
implemented by other standards referencing 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.
ISO/IEC 7498-1, Information technology — Open Systems Interconnection — Basic Reference Model: The Basic Model
1)
ISO 11898-1 , Road vehicles — Controller area network (CAN) — Part 1: Data link layer and physical signalling
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO/IEC 7498-1, ISO 11898-1 and the
following apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at https:// www .electropedia .org/
1) Third edition under preparation. Stage at the time of publication: ISO/FDIS 11898-1:—.

3.1
CAN_DL
CAN frame data length
physical length of CAN frame data/payload (3.2) in bytes
Note 1 to entry: See Table 2.
3.2
payload
synonym for (CAN) data field as specified in ISO 11898-1
3.3
TX_DL
transmit data link layer data length
parameter configuring the maximum usable payload (3.2) length in bytes of the data link layer in the
transmitter for the application that implements the network layer
Note 1 to entry: The TX_DL is a fixed configuration value on the sender side for the PDU transmission.
3.4
RX_DL
received data link layer data length
parameter retrieving the maximum usable payload (3.2) length in bytes of the data link layer in the receiver
for the application that implements the network layer
Note 1 to entry: The RX_DL value is retrieved from the FirstFrame (FF) CAN_DL (3.1) of a segmented PDU and is used
to verify the correct data length of ConsecutiveFrames (CF).
4 Symbols and abbreviated terms
4.1 Symbols
C ComParam transport layer buffer overflow
TL_BUFFER_OVFLW
C ComParam transport layer consecutive frame sequence number
TL_CFSN
C ComParam transport layer data length code
TL_DLC
C ComParam transport layer error
TL_ERROR
C ComParam transport layer flow control flow status
TL_FCFS
C ComParam transport layer flow control block size
TL_FCBS
C ComParam transport layer flow control flow status continue to send
TL_FCFS(CTS)
C ComParam transport layer flow control flow status overflow
TL_FCFS(OVFLW)
C ComParam transport layer flow control separation time minimum
TL_FCSTmin
C ComParam transport layer flow control flow status wait
TL_FCFS(WAIT)
C ComParam transport layer error invalid flow status
TL_INVALID_FS
C ComParam transport layer ok
TL_OK
C ComParam transport layer receiver error to indicate that the receiving entity did not
TL_RX_ON
accept flow control parameter changes during this segmented message reception
C ComParam transport layer timeout A sender and receiver
TL_TIMEOUT_A
C ComParam transport layer sender timeout B sender
TL_TIMEOUT_Bs
C ComParam transport layer receiver timeout C receiver
TL_TIMEOUT_Cr
C ComParam transport layer error unexpected protocol data unit
TL_UNEXP_PDU
C ComParam transport layer wait frame transmissions overrun
TL_WFT_OVRN
C ComParam transport layer flow status wait frame transmissions maximum
TL_WFTmax
C ComParam transport layer error wrong parameter
TL_WRONG_PARAMETER
C ComParam transport layer error wrong segment number
TL_WRONG_SN
C ComParam transport layer error wrong value
TL_WRONG_VALUE
t time
t timing parameter transport layer receiver timing value Ar
TL_Ar
t timing parameter transport layer sender timing value As
TL_As
t timing parameter transport layer receiver timing value Br
TL_Br
t timing parameter transport layer sender timing value Bs
TL_Bs
t timing parameter transport layer receiver timing value Cr
TL_Cr
t timing parameter transport layer sender timing value Cs
TL_Cs
4.2 Abbreviated terms
For the purposes of this document, the following abbreviated terms apply.
AE address extension
AI address information
CAN controller area network
CAN CC CAN with static arbitration and data phase bit rate
CAN_DL CAN frame data length
CAN FD CAN with flexible data phase bit rate
CF consecutive frame
ChangeParameter layer service name
ComParam communication parameter
CTS continue to send
Data. abstract service primitive service name
DoCAN diagnostic communication over CAN
ECU electronic control unit
FC flow control
FF first frame
FF_DL first frame data length in bytes
FMI failure mode indicator
Mtype message type
N/A not applicable
PCI protocol control information
PCItype protocol control information type
PDU protocol data unit
SA source address
SDU service data unit
TA target address
TAtype target address type
NL network layer
OBD on-board diagnostics
OSI Open Systems Interconnection
PCI protocol control information
RTR remote transmission request
RX_DL received data link layer data length
SF single frame
SF_DL single frame data length in bytes
SN sequence number
SPN suspect parameter number
TX_DL transmit data link layer data length
UDS unified diagnostic services
WWH-OBD world-wide harmonized OBD
5 Conventions
This document is based on the conventions discussed in the OSI service conventions (ISO/IEC 10731) as they
apply for diagnostic services.

6 ISO 11898-1 CAN data link layer extension
6.1 CAN CC and CAN FD frame feature comparison
ISO 11898-1 specifies variable length CAN frames with a maximum payload size dependent on the protocol
device used. A CAN CC protocol device can transmit/receive frames with payload sizes ranging from 0 byte
to 8 byte per frame.
A CAN FD (flexible data rate) protocol device can transmit/receive frames with payload sizes from 0 byte to
64 byte. A CAN FD protocol device is also capable of transmitting/receiving CAN CC frames.
Therefore, the segmented transfer of data using FirstFrame (FF), FlowControl (FC) and ConsecutiveFrame
(CF) type frames shall support a variable configurable payload length without changing the original protocol
concept.
Table 1 outlines the different features of the CAN frame types provided by ISO 11898-1.
Table 1 — CAN frame feature comparison
RefNo Feature CAN CC CAN FD
#1 Payload length 0 to 8 bytes: data length code (DLC) 0 to 8 Yes Yes
a
#2 Payload length 8 bytes: data length code (DLC) 9 to 15 Yes No
b
#3 Payload length 12 to 64 bytes : data length code (DLC) 9 to 15 No Yes
Different bit rates supported for the arbitration and data phases of a
#4 No Yes
CAN frame
#5 Remote transmission request (RTR) Yes No
a
For CAN CC, the DLC values 9 to 15 are automatically reduced to the value of 8 which leads to the maximum possible CAN_DL
for CAN CC.
b
CAN FD does not support all payload lengths between 8 bytes and 64 bytes (e.g. a CAN FD frame with 10 meaningful data
bytes requires a payload length of 12 bytes); see Table 2.
6.2 Mapping of transport and network layer attributes to CAN data frames
Figure 2 shows the mapping of CAN parameters onto the data link layer addressing information NL_AI. It
illustrates the validity and applicability of transport/network layer parameters and the resulting support of
CAN CC versus CAN FD data link layer.
Figure 2 describes this for the example of using either normal or normal fixed addressing. For extended
addressing and mixed addressing, the concept in general also applies but the mapping of the NL_AI
parameter onto the CAN frame differs.

Key
a
DLC value results in a CAN_DL value (n), which is the physical length of a CAN frame data/payload; in the receiver,
CAN_DL is used to determine the sender TX_DL value.
b
The shown NL_AI mapping is an example for normal and normal fixed addressing only.
For 11-bit CAN identifiers, the mapping of the NL_AI target address (TA) and source address (SA) into a CAN identifier
is implied.
Figure 2 — Illustration of transport and network layer attributes mapping to the CAN data frame
subfields
Table 2 shows the data length code value between CAN CC and CAN FD.
Table 2 — CAN CC/CAN FD data length comparison table
Data length code (DLC) CAN CC data length (CAN_DL) CAN FD data length (CAN_DL)
0 0 0
1 1 1
2 2 2
3 3 3
4 4 4
5 5 5
6 6 6
7 7 7
8 8 8
a
9 8 12
a
10 8 16
a
11 8 20
a
12 8 24
a
13 8 32
a
14 8 48
a
15 8 64
a
For CAN CC, the DLC values 9 to 15 are automatically reduced to the value of 8 which leads to the maximum possible CAN_DL
for CAN CC.
7 T_Data abstract service primitive interface definition
7.1 T_Data services
The Open Systems Interconnection (OSI) defines abstract service primitives (ASP) as an implementation-
independent description of an interaction between a service user and a service provider. The abstract
service primitives are defined for a particular service transition.
The ASP interface defines the service and parameter mappings beween OSI layers.
Figure 3 shows the T_Data.req (request), T_Data.ind (indication), T_DataSOM.ind (indication), and T_Data.
con (confirmation) service interface.
Key
t time
1 service access point
2 read back from N-layer service provider
Figure 3 — T_Data.req, T_Data.ind, T_DataSOM.ind and T_Data.con service interface
7.2 T_Data interface
The ASP T_Data interface is independent (abstraction) of the transport protocol used in the OSI-4 layer. It
connects the session layer (OSI-5) and the various transport layers (OSI-4).
The ASP T_Data interface shall support the services as specified in Table 3.
Table 3 — ASP T_Data interface
ASP Description
T_Data.req
This service is used by the T_Data interface to request the transfer of a message.
T_Data.ind
This service is used to signal to the T_Data interface the completion of a message reception.
T_DataSOM.ind
This service is used to signal to the T_Data interface the beginning of a segmented message
reception.
T_Data.con
This service confirms to the T_Data interface that the requested service has been carried
out (successfully or not).
7.3 Data type definitions
This requirement specifies the data types of the abstract service primitive interface parameters.
The data types shall be in accordance to:
— Enum = 8-bit enumeration;
— Unsigned Byte = 8-bit unsigned numeric value;
— Unsigned Word = 16-bit unsigned numeric value;
— Unsigned Long = 32-bit unsigned numeric value;
— Byte Array = sequence of 8-bit aligned data;
— Word Array = sequence of 16-bit aligned data;
— Bit String = 8-bit binary coded.
8 Transport and network layer services
8.1 General
In order to describe the functioning of the transport and network layer, it is necessary to consider services
provided to higher layers and the internal operation of the transport and network layer.
All transport and network layer services have the same general structure. To define the services, three types
of service primitive are specified:
— a service request primitive, used by higher communication layers or the application to pass control
information and data required to be transmitted to the network layer;
— a service indication primitive, used by the network layer to pass status information and received data to
upper communication layers or the application;
— a service confirmation primitive, used by the network layer to pass status information to higher
communication layers or the application.
This service specification does not specify an application programming interface but only a set of service
primitives that are independent of any implementation.
All transport and network layer services have the same general format. Service primitives are written in
the form:
service_name.type
(
parameter A,
parameter B
[,parameter C, .]
)
where “service_name” is the name of the service, e.g. TL_/NL_Data, “type” indicates the type of service
primitive, and “parameter A, parameter B [,parameter C, .]” are the TL_/NL_SDU as a list of values passed
by the service primitive. The square brackets indicate that this part of the parameter list is optional.
The service primitives define how a service user (e.g. diagnostic application) cooperates with a service
provider (e.g. network layer). The following service primitives are specified in this document: request,
indication and confirm.
— Using the service primitive request (service_name.req), a service user requests a service from the
service provider.
— Using the service primitive indication (service_name.ind), the service provider informs a service user about
an internal event of the network layer or the service request of a peer protocol layer entity service user.
— With the service primitive confirm (service_name.con), the service provider informs the service user
about the result of a preceding service request of the service user.
The service interface defines a set of services that are needed to access the functions offered by the transport
and network layer, i.e. transmission/reception of data and setting of protocol parameters.
Two types of service are defined:
a) communication services: these services, of which the following are defined, enable the transfer of up to
4 294 967 295 bytes of data:
1) Data.req: this service is used to request the transfer of data. If necessary, the network layer
segments the data;
2) Data_FF.ind: this service is used to indicate the beginning of a segmented message reception to the
upper layer;
3) Data.ind: this service is used to provide received data to the higher layers;
4) Data.con: this service confirms to the higher layers that the requested service has been carried out
(successfully or not);
b) protocol parameter setting services: these services, of which the following are defined, enable the
dynamic setting of protocol parameters:
1) ChangeParameter.req: this service is used to request the dynamic setting of specific internal
parameters;
2) ChangeParameter.con: this service confirms to the upper layer that the request to change a specific
protocol has completed (successfully or not).
8.2 Transport and network layer abstract service primitives
8.2.1 Data.req
The service primitive requests transmission of < MessageData > with < Length > bytes from the sender to the
receiver peer entities identified by the address information in SA, TA, TAtype [and AE] (see 8.3 for parameter
definition).
Data.req
(
Mtype
SA
TA
TAtype
[AE]


)
Each time the Data.req service is called, the transport and network layer shall indicate the completion (or
failure) of the message transmission to the service user by issuing a Data.con service call.

8.2.2 Data.con
The Data.con service is issued by the transport and network layer. The service primitive confirms the
completion of a Data.req service identified by the address information in SA, TA, TAtype [and AE]. The
parameter < Result > provides the status of the service request (see 8.3 for parameter definition).
Data.con
(
Mtype
SA
TA
TAtype
[AE]

)
8.2.3 Data_FF.ind
The Data_FF.ind service is issued by the transport and network layer. The service primitive indicates to the
adjacent upper layer the arrival of a FirstFrame (FF) of a segmented message received from a peer protocol
entity, identified by the address information in SA, TA, TAtype [and AE] (see 8.3 for parameter definition). This
indication shall take place upon receipt of the FF of a segmented message.
Data_FF.ind
(
Mtype
SA
TA
TAtype
[AE]
)
The Data_FF.ind service shall always be followed by a Data.ind service call from the transport and network
layer, indicating the completion (or failure) of message reception.
A Data_FF.ind service call shall only be issued by the transport and network layer if a correct FF message
segment has been received.
If the transport and network layer detect any type of error in an FF, then the message is ignored by the
transport and network layer and no Data_FF.ind is issued to the adjacent upper layer.
If the transport and network layer receive an FF with a data length value (FF_DL) that is greater than the
available receiver buffer size, then this is considered as an error condition and no Data_FF.ind is issued to
the adjacent upper layer.
8.2.4 Data.ind
The Data.ind service is issued by the transport and network layer. The service primitive
indicates < Result > events and delivers < MessageData > with < Length > bytes received from a peer protocol
entity identified by the address information in SA, TA, TAtype [and AE] to the adjacent upper layer (see 8.3 for
parameter definition).
The parameters < MessageData > and < Length > are valid only if < Result > equals OK.

Data.ind
(
Mtype
SA
TA
TAtype
[AE]



)
The Data.ind service call is issued after reception of a SingleFrame (SF) message or as an indication of the
completion (or failure) of a segmented message reception.
If the transport and network layer detect any type of error in an SF, then the message is ignored by the
transport and network layer and no Data.ind is issued to the adjacent upper layer.
8.2.5 ChangeParameter.req
The service primitive is used to request the change of an internal parameter’s value on the local protocol
entity. The < Parameter_Value > is assigned to the < Parameter > (see 8.3 for parameter definition).
A parameter change is always possible, except after reception of the FF (Data_FF.ind) and until the end of
reception of the corresponding message (Data.ind).
ChangeParameter.req
(
Mtype
SA
TA
TAtype
[AE]


)
This is an optional service that can be replaced by fixed parameter values.
8.2.6 ChangeParameter.con
The service primitive confirms completion of a ChangeParameter.con service applying to a message
identified by the address information in SA, TA, TAtype [and AE] (see 8.3 for parameter definition).
ChangeParameter.con
(
Mtype
SA
TA
TAtype
[AE]


)
8.3 Service data unit specification
8.3.1 Mtype, message type
Type: enumeration
Range: diagnostics, remote diagnostics
Description: the parameter Mtype is used to identify the type and range of address information parameters
included in a service call. This document specifies a range of two values for this parameter. The intention
is that users of this document can extend the range of values by specifying other types and combinations
of address information parameters to be used with the transport and network layer protocol specified in
this document. For each such new range of address information, a new value for the Mtype parameter is
specified to identify the new address information.
Requirements:
— If Mtype = diagnostics, then the address information (AI) shall consist of the parameters SA, TA and TAtype.
— If Mtype = remote diagnostics, then the address information (AI) shall consist of the parameters SA, TA,
TAtype and AE.
8.3.2 AI, address information
8.3.2.1 AI description
These parameters refer to addressing information. As a whole, the AI parameters are used to identify the
source address (SA), the target address (TA) of message senders and recipients, as well as the communication
model for the message (TAtype) and the optional address extension (AE).
8.3.2.2 SA, source address
Type: 8 bits
Range: 00 to FF
16 16
Description: the SA parameter is used to encode the sending network layer protocol entity.
8.3.2.3 TA, target address
Type: 8 bits
Range: 00 to FF
16 16
Description: the TA parameter is used to encode one or multiple (depending on the TAtype: physical or
functional) receiving network layer protocol entities.
8.3.2.4 TAtype, target address type
Type: enumeration
Range: see Table 4
Description: the parameter TAtype is an extension to the TA parameter. It is used to encode the
communication model used by the communicating peer entities of the transport and network layer. The
following requirements are supported:
— the transport and network layer protocol is capable of carrying out parallel transmission of different
messages that are not mapped onto the same NL_AI;

— error handling for unexpected PDUs only pertains to messages with the same AI:
— CAN CC frames will not cause a CAN FD message to be terminated and vice-versa;
— this explicitly prevents mixing CAN FD/CAN CC frame types in a single message.
Table 4 specifies the allowed combinations of TAtype communication models.
Table 4 — Allowed combinations of TAtype communication models
TAtype Physical/Functional addressing
a
TAtype #1 Physical
CAN base format (CAN CC, 11-bit)
b
TAtype #2 Fun
...