ISO 15765-2:2016

Road vehicles - Diagnostic communication over Controller Area Network (DoCAN) - Part 2: Transport protocol and network layer services

ISO 15765-2:2016 specifies a transport protocol 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. It has been defined in accordance with the diagnostic services established in ISO 14229‑1 and ISO 15031‑5 but is not limited to use with them and is also compatible with most other communication needs for in‑vehicle networks. ISO 11898‑1 specifies variable length CAN frames with a maximum payload size dependent on the protocol device used. A CLASSICAL CAN protocol device can transmit/receive frames with payload sizes ranging from 0 bytes to 8 bytes per frame. A CAN FD (flexible data rate) protocol device can transmit/receive frames with payload sizes from 0 bytes to 64 bytes. A CAN FD protocol device is also capable of transmitting/receiving CLASSICAL CAN frames. The diagnostic communication over controller area network (DoCAN) protocol supports the standardized service primitive interface as specified in ISO 14229‑2 (UDS). ISO 15765-2:2016 provides the transport protocol and network layer services to support different application-layer implementations 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 ISO 15031, - world-wide harmonized on-board diagnostics (WWH-OBD) as specified in ISO 27145, and - end of life activation on on-board pyrotechnic devices (ISO 26021). The transport protocol specifies an unconfirmed communication. NOTE This part of ISO 15765 does not determine whether CLASSICAL CAN, CAN FD or both are recommended or required to be implemented by other standards referencing this part of ISO 15765.

Véhicules routiers — Communication de diagnostic sur gest ionnaire de réseau de communication (DoCAN) — Partie 2: Protocole de transport et services de la couche réseau

General Information

• Status: Withdrawn
• Publication Date: 11-Apr-2016
• ICS: 43.040.15 - Car informatics. On board computer systems
• ICS: 43.180 - Diagnostic, maintenance and test equipment
• Technical Committee: ISO/TC 22/SC 31 - Data communication
• Drafting Committee: ISO/TC 22/SC 31/WG 2 - Vehicle diagnostic protocols
• Current Stage: 9599 - Withdrawal of International Standard
• Start Date: 05-Apr-2024
• Completion Date: 13-Dec-2025

Relations

• Revised: ISO 15765-2:2024 - Road vehicles - Diagnostic communication over Controller Area Network (DoCAN) - Part 2: Transport protocol and network layer services
• Effective Date: 06-Jun-2022
• Revises: ISO 15765-2:2011 - Road vehicles - Diagnostic communication over Controller Area Network (DoCAN) - Part 2: Transport protocol and network layer services
• Effective Date: 17-May-2014

Standards Content (Sample)

INTERNATIONAL ISO
STANDARD 15765-2
Third edition
2016-04-01
Road vehicles — Diagnostic
communication over Controller Area
Network (DoCAN) —
Part 2:
Transport protocol and network layer
services
Véhicules routiers — Communication de diagnostic sur gest ionnaire
de réseau de communication (DoCAN) —
Partie 2: Protocole de transport et services de la couche réseau
Reference number
©
ISO 2016
© ISO 2016, Published in Switzerland
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
Ch. de Blandonnet 8 • CP 401
CH-1214 Vernier, Geneva, Switzerland
Tel. [phone]
Fax [phone]
[e-mail]
www.iso.org
ii © ISO 2016 – All rights reserved

Contents Page
Foreword .v
Introduction .vi
1 Scope . 1
2 Normative references . 1
3 Terms, definitions and abbreviated terms . 2
3.1 Terms and definitions . 2
3.2 Abbreviated terms . 2
4 Conventions . 3
5 Document overview. 3
6 ISO 11898-1 CAN data link layer extension . 4
6.1 CLASSICAL CAN and CAN FD frame feature comparison . 4
6.2 Illustration of CAN parameters for transport protocol and network layer services . 5
6.3 Additional requirements for CAN FD . 6
7 Network layer overview . 7
7.1 General . 7
7.2 Services provided by network layer to higher layers . 7
7.3 Internal operation of network layer . 8
8 Network layer services .10
8.1 General .10
8.2 Specification of network layer service primitives .11
8.2.1 N_USData.request .11
8.2.2 N_USData.confirm .11
8.2.3 N_USData_FF.indication .11
8.2.4 N_USData.indication .12
8.2.5 N_ChangeParameters.request .12
8.2.6 N_ChangeParameter.confirm .13
8.3 Service data unit specification .13
8.3.1 Mtype, message type .13
8.3.2 N_AI, address information .13
8.3.3 .16
8.3.4 .16
8.3.5 .16
8.3.6 .16
8.3.7 .16
8.3.8 .17
9 Transport layer protocol .18
9.1 Protocol functions .18
9.2 SingleFrame transmission .18
9.2.1 SingleFrame transmission with TX_DL = 8.18
9.2.2 SingleFrame transmission with TX_D > 8 .19
9.3 Multiple-frame transmission .19
9.4 Transport layer protocol data units .21
9.4.1 Protocol data unit types . .21
9.4.2 SF N_PDU .21
9.4.3 FF N_PDU .21
9.4.4 CF N_PDU .21
9.4.5 FC N_PDU .21
9.4.6 Protocol data unit field description .22
9.5 Transmit data link layer data length (TX_DL) configuration.22
9.5.1 Definition of TX_DL configuration values .22
9.5.2 Creating CAN frames based on N_TAtype and TX_DL .23
9.5.3 Verifying the correctness of received CAN frames . .23
9.5.4 Receiver determination RX_DL .25
9.6 Protocol control information specification .25
9.6.1 N_PCI .25
9.6.2 SingleFrame N_PCI parameter definition .26
9.6.3 FirstFrame N_PCI parameter definition .28
9.6.4 ConsecutiveFrame N_PCI parameter definition .29
9.6.5 FlowControl N_PCI parameter definition .30
9.7 Maximum number of FC.WAIT frame transmissions (N_WFTmax) .33
9.8 Network layer timing .33
9.8.1 Timing parameters.33
9.8.2 Network layer timeouts .37
9.8.3 Unexpected arrival of N_PDU .37
9.8.4 Wait frame error handling .39
9.9 Interleaving of messages .39
10 Data link layer usage .39
10.1 Data link layer service parameters .39
10.2 Data link layer interface services .39
10.2.1 L_Data.request .39
10.2.2 L_Data.confirm .39
10.2.3 L_Data.indication .40
10.3 Mapping of the N_PDU fields .40
10.3.1 Addressing formats .40
10.3.2 Normal addressing .40
10.3.3 Normal fixed addressing .41
10.3.4 Extended addressing .41
10.3.5 Mixed addressing.42
10.4 CAN frame data length code (DLC) .43
10.4.1 DLC parameter .43
10.4.2 CAN frame data .43
10.4.3 Data length code (DLC) error handling .45
Annex A (normative) Use of normal fixed and mixed addressing with data link layer
according to SAE J1939 .46
Annex B (normative) Reserved CAN IDs .49
Bibliography .50
iv © ISO 2016 – All rights reserved

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
The committee responsible for this document is ISO/TC 22, Road vehicles, Subcommittee SC 31, Data
communication.
This third edition cancels and replaces the second edition (ISO 15765-2:2011), which has been
technically revised.
ISO 15765 consists of the following parts, under the general title Road vehicles — Diagnostic
1)
communication over Controller Area Network (DoCAN) :
— Part 1: General information and use case definition
— Part 2: Transport protocol and network layer services
— Part 4: Requirements for emissions-related systems
1) ISO 15765-3 Implementation of unified diagnostic services (UDS on CAN) has been withdrawn and replaced
by ISO 14229-3 Road vehicles — Unified diagnostic services (UDS) — Part 3: Unified diagnostic services on CAN
implementation (UDSonCAN)
Introduction
This part of ISO 15765 has been established in order to define common requirements for vehicle
diagnostic systems implemented on a controller area network (CAN) communication link, as specified
in ISO 11898-1. Although primarily intended for diagnostic systems, it also meets requirements from
other CAN-based systems needing a network layer protocol.
To achieve this, it is based on 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 as shown in Table 1.
Table 1 — Enhanced and legislated on-board diagnostics specifications applicable to the OSI
layers
Vehicle-
manufacturer- Legislated OBD Legislated WWH-OBD
a
OSI 7 layers
enhanced (on-board diagnostics) (on-board diagnostics)
diagnostics
Application ISO 14229-1,
ISO 15031-5 ISO 27145-3, ISO 14229-1
(layer 7) ISO 14229-3
ISO 15031-2, ISO 27145-2, SAE 1930-DA,
ISO 15031-5, SAE J1979-DA,
Vehicle
Presentation ISO 15031-6, SAE J2012-DA,
manufacturer
(layer 6) SAE J1930-DA, SAE J1939-DA (SPNs),
specific
SAE J1979-DA, SAE J1939-73
SAE J2012-DA Appendix A (FMIs)
Session (layer 5) ISO 14229-2
Transport protocol
ISO 15765-4,
(layer 4)
ISO 15765-2 ISO 15765-2
ISO 15765-2
Network (layer 3)
ISO 15765-4,
Data link (layer 2) ISO 11898-1 ISO 11898-1
ISO 11898-1
ISO 11898-1, ISO 15765-4 ISO 27145-4
ISO 11898-2,
ISO 11898-3,
ISO 11898-1, ISO 11898-1,
Physical (layer 1) or
ISO 11898-2 ISO 11898-2
vehicle
manufacturer
specific
a
7 layers according to ISO/IEC 7498-1 and ISO/IEC 10731
The application layer services covered by ISO 14229-3 have been defined in compliance with diagnostic
services established in ISO 14229-1 and ISO 15031-5 but are not limited to use only with them.
ISO 14229-3 is also compatible with most diagnostic services defined in national standards or vehicle
manufacturer’s specifications.
For other application areas, ISO 15765 can be used with any CAN physical layer.
vi © ISO 2016 – All rights reserved

INTERNATIONAL STANDARD ISO 15765-2:2016(E)
Road vehicles — Diagnostic communication over
Controller Area Network (DoCAN) —
Part 2:
Transport protocol and network layer services
1 Scope
This part of ISO 15765 specifies a transport protocol 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. It has been defined in accordance with the diagnostic services established in
ISO 14229-1 and ISO 15031-5 but is not limited to use with them and is also compatible with most other
communication needs for in-vehicle networks.
ISO 11898-1 specifies variable length CAN frames with a maximum payload size dependent on the
protocol device used. A CLASSICAL CAN protocol device can transmit/receive frames with payload
sizes ranging from 0 bytes to 8 bytes per frame. A CAN FD (flexible data rate) protocol device can
transmit/receive frames with payload sizes from 0 bytes to 64 bytes. A CAN FD protocol device is also
capable of transmitting/receiving CLASSICAL CAN frames.
The diagnostic communication over controller area network (DoCAN) protocol supports the
standardized service primitive interface as specified in ISO 14229-2 (UDS).
This part of ISO 15765 provides the transport protocol and network layer services to support different
application-layer implementations 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 ISO 15031,
— world-wide harmonized on-board diagnostics (WWH-OBD) as specified in ISO 27145, and
— end of life activation on on-board pyrotechnic devices (ISO 26021).
The transport protocol specifies an unconfirmed communication.
NOTE This part of ISO 15765 does not determine whether CLASSICAL CAN, CAN FD or both are recommended
or required to be implemented by other standards referencing this part of ISO 15765.
2 Normative references
The following documents, in whole or in part, are normatively referenced in this document and are
indispensable for its application. 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 — Part 1
2)
ISO 11898-1:2015 , Road vehicles — Controller area network (CAN) — Part 1: Data link layer and physical
signalling
2) The dated reference is to the first version of ISO 11898-1 that includes the definition of CAN FD. Versions after
the dated reference are also valid. Future dated references are valid for CAN FD.
3 Terms, definitions and abbreviated terms
3.1 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.
3.1.1
CAN frame data length
CAN_DL
physical length of CAN frame data/payload in bytes
Note 1 to entry: See Table 3.
3.1.2
transmit data link layer data length
TX_DL
configures the maximum usable payload length in bytes of the data link layer in the transmitter for the
application that implements the network layer as defined in this part of ISO 15765
Note 1 to entry: The TX_DL is a fixed configuration value on the sender side for the PDU transmission.
3.1.3
Received data link layer data length
RX_DL
retrieved maximum usable payload length in bytes of the data link layer in the receiver for the
application that implements the network layer as defined in this part of ISO 15765
Note 1 to entry: The RX_DL value is retrieved from the FirstFrame (FF) CAN_DL of a segmented PDU and is used
to verify the correct data length of ConsecutiveFrames (CF).
3.2 Abbreviated terms
For the purposes of this part of ISO 15765, the following abbreviated terms apply.
BRS bit rate switch
BS BlockSize
CAN controller area network
CAN_DL CAN frame data link layer data length in bytes
CAN FD controller area network with flexible data rate and larger payload as defined in
ISO 11898-1
CLASSICAL CAN controller area network with static data rate and up to 8 data bytes as defined in
ISO 11898-1
CF ConsecutiveFrame
CTS continue to send
DLC CAN frame data link layer data length code
DoCAN diagnostic communication over CAN
ECU electronic control unit
FC FlowControl
FF FirstFrame
FF_DL FirstFrame data length in bytes
FMI failure mode indicator
FS FlowStatus
Mtype message type
N/A not applicable
2 © ISO 2016 – All rights reserved

N_AE network address extension
N_AI network address information
N_Ar network layer timing parameter Ar
N_As network layer timing parameter As
N_Br network layer timing parameter Br
N_Bs network layer timing parameter Bs
N_ChangeParameter network layer service name
N_Cr network layer timing parameter Cr
N_Cs network layer timing parameter Cs
N_Data network data
N_PCI network protocol control information
N_PCItype network protocol control information type
N_PDU network protocol data unit
N_SA network source address
N_SDU network service data unit
N_TA network target address
N_TAtype network target address type
N_USData network layer unacknowledged segmented data transfer service name
NW network
NWL network layer
OBD on-board diagnostics
OSI Open Systems Interconnection
PCI protocol control information
RX_DL received data link layer data length in bytes
SF SingleFrame
SF_DL SingleFrame data length in bytes
SN SequenceNumber
SPN suspect parameter number
ST SeparationTime minimum
min
TX_DL transmit data link layer data length in bytes
UDS unified diagnostic services
WWH-OBD world-wide harmonized OBD
4 Conventions
This International Standard is based on the conventions discussed in the OSI service conventions
(ISO/IEC 10731) as they apply for diagnostic services.
5 Document overview
Figure 1 illustrates the most applicable application implementations utilizing the DoCAN protocol.
Figure 1 — DoCAN document reference according to the OSI model
6 ISO 11898-1 CAN data link layer extension
6.1 CLASSICAL CAN and CAN FD frame feature comparison
ISO 11898-1 CLASSICAL CAN frames support payload lengths up to a maximum of 8 bytes. ISO 11898-1
CAN FD frames support payload lengths up to a maximum of 64 bytes. Therefore, the segmented
transfer of data using FirstFrame (FF), FlowControl (FC) and ConsecutiveFrame (CF) type frames
needs to be implemented with a variable configurable payload length without changing the original
protocol concept. The SF frame type has also been adapted to support the increased payload length
allowed with CAN FD frames.
4 © ISO 2016 – All rights reserved

Table 2 outlines the different features of the CAN frame types provided by ISO 11898-1.
Table 2 — CAN frame feature comparison
RefNo Feature CLASSICAL CAN CAN FD
Payload length 0.8 bytes
#1 Yes Yes
Data length code (DLC) 0.8
Payload length 8 bytes
#2 Yes No
a
Data length code (DLC) 9.15
b
Payload length 12.64 bytes
#3 No Yes
Data length code (DLC) 9.15
Different bit rates supported for the arbitration and
#4 No Yes
data phases of a CAN frame.
#5 Remote transmission request (RTR) Yes No
a
For CLASSICAL CAN, the DLC values 9.15 are automatically reduced to the value of 8 which leads to the maximum
possible CAN_DL for CLASSICAL CAN.
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 3 and 10.4.2.3.
6.2 Illustration of CAN parameters for transport protocol and network layer services
Figure 2 shows the mapping of CAN parameters onto the network/transport layer addressing
information N_AI. It illustrates the validity and applicability of network/transport layer parameters
and the resulting support of CLASSICAL CAN vs. 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 N_AI parameter onto the CAN
frame differs.
Key
1 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
2 the shown N_AI mapping is an example for normal and normal fixed addressing only
3 the bit rate switch (BRS) in the ‘Format’ information defines the transmission speed of the data phase
Figure 2 — Illustration of CAN parameters for network layer services
Table 3 — CLASSICAL CAN/CAN FD data length comparison table
Data length code
CLASSICAL CAN data length (CAN_DL) CAN FD data length (CAN_DL)
(DLC)
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 CLASSICAL CAN, the DLC values 9.15 are automatically reduced to the value of 8 which leads to the maximum
possible CAN_DL for CLASSICAL CAN.
6.3 Additional requirements for CAN FD
If a CAN FD protocol device is used, this part of ISO 15765 can be configured to create either
CLASSICAL CAN or CAN FD type frames. When CAN FD type frames are enabled for the data link layer,
two new options need to be supported as follows.
a) The BRS bit which is part of a CAN FD frame and is used to determine if the data phase is to be
transmitted at a different bit rate than the arbitration phase. The bitrate of the data phase is
defined to be equal or higher than the arbitration bitrate. Bit rate switching does not influence the
transport protocol itself (see Figure 2).
b) The maximum allowed payload length (CAN_DL, 8 . 64 bytes); see Table 3.
Accommodating different maximum payload length values requires the addition of a new configuration
variable “transmit data link layer data length” (TX_DL) for the transmitting node as specified in 9.5.
The configurable TX_DL value acts as a switch and upper bound for the valid CAN frame data lengths
(CAN_DL) for the transmitting node.
— TX_DL equal to 8:
The transport protocol behaves identical to previous versions of this International Standard based
on ISO 11898-1 (CLASSICAL CAN with 8 byte payload). See RefNo #1 in Table 2. CAN Frames
created by the protocol for transmission shall only use DLC values 2.8. This applies to both,
CLASSICAL CAN and CAN FD type frames;
— TX_DL greater than 8:
Only ISO 11898-1 CAN FD type frames shall be used. DLC values 2.15 are allowed. See RefNo #1
and RefNo #3 in Table 2.
6 © ISO 2016 – All rights reserved

7 Network layer overview
7.1 General
This part of ISO 15765 specifies an unconfirmed network layer communication protocol for the
exchange of data between network nodes, e.g. from ECU to ECU, or between external test equipment
and an ECU. If the data to be transferred does not fit into a single CAN frame, a segmentation method is
provided.
In order to describe the functioning of the network layer, it is necessary to consider services provided
to higher layers and the internal operation of the network layer.
7.2 Services provided by network layer to higher layers
The service interface defines a set of services that are needed to access the functions offered by the
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) N_USData.request: This service is used to request the transfer of data. If necessary, the network
layer segments the data.
2) N_USData_FF.indication: This service is used to signal the beginning of a segmented message
reception to the upper layer.
3) N_USData.indication: This service is used to provide received data to the higher layers.
4) N_USData.confirm: 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) N_ChangeParameter.request: This service is used to request the dynamic setting of specific
internal parameters.
2) N_ChangeParameter.confirm: This service confirms to the upper layer that the request to
change a specific protocol has completed (successfully or not).
7.3 Internal operation of network layer
The internal operation of the network layer provides methods for segmentation, transmission with
FlowControl, and reassembly. The main purpose of the network layer is to transfer messages that might
or might not fit in a single CAN frame. Messages that do not fit into a single CAN frame are segmented
into multiple parts, where each can be transmitted in a CAN frame.
Figure 3 shows an example of an unsegmented message transmission.
Figure 3 — Example of an unsegmented message
Figure 4 shows an example of a segmented message transmission.
8 © ISO 2016 – All rights reserved

Figure 4 — Example of a segmented message
FlowControl is used to adjust the sender to the network layer capabilities of the receiver. This
FlowControl scheme allows the use of diagnostic gateways and sub-networks.
8 Network layer services
8.1 General
All network layer services have the same general structure. To define the services, three types of
service primitive are specified as follows:
— 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 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. N_USData, “type” indicates the type of service
primitive, and “parameter A, parameter B [,parameter C, .]” are the N_SDU as a list of values passed by
the service primitive. The square brackets indicate that this part of the parameter list may be empty.
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 part of ISO 15765:
request, indication and confirm.
— Using the service primitive request (service_name.request), a service user requests a service from
the service provider.
— Using the service primitive indication (service_name.indication), 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.confirm), the service provider informs the service
user about the result of a preceding service request of the service user.
10 © ISO 2016 – All rights reserved

8.2 Specification of network layer service primitives
8.2.1 N_USData.request
The service primitive requests transmission of with bytes from the sender
to the receiver peer entities identified by the address information in N_SA, N_TA, N_TAtype [and N_AE]
(see 8.3 for parameter definition).
N_USData.request (
Mtype
N_SA
N_TA
N_TAtype
[N_AE]


)
Each time the N_USData.request service is called, the network layer shall signal the completion (or
failure) of the message transmission to the service user by issuing an N_USData.confirm service call.
8.2.2 N_USData.confirm
The N_USData.confirm service is issued by the network layer. The service primitive confirms the
completion of an N_USData.request service identified by the address information in N_SA, N_TA, N_
TAtype [and N_AE]. The parameter provides the status of the service request (see 8.3 for
parameter definition).
N_USData.confirm (
Mtype
N_SA
N_TA
N_TAtype
[N_AE]

)
8.2.3 N_USData_FF.indication
The N_USData_FF.indication service is issued by the 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 N_SA, N_TA, N_TAtype [and N_AE] (see 8.3 for
parameter definition). This indication shall take place upon receipt of the FF of a segmented message.
N_USData_FF.indication (
Mtype
N_SA
N_TA
N_TAtype
[N_AE]
)
The N_USData_FF.indication service shall always be followed by an N_USData.indication service call
from the network layer, indicating the completion (or failure) of message reception.
An N_USData_FF.indication service call shall only be issued by the network layer if a correct FF message
segment has been received.
If the network layer detects any type of error in an FF, then the message shall be ignored by the network
layer and no N_USData_FF.indication shall be issued to the adjacent upper layer.
If the network layer receives an FF with a data length value (FF_DL) that is greater than the available
receiver buffer size, then this shall be considered as an error condition and no N_USData_FF.indication
shall be issued to the adjacent upper layer.
8.2.4 N_USData.indication
The N_USData.indication service is issued by the network layer. The service primitive indicates Result> events and delivers with bytes received from a peer protocol entity
identified by the address information in N_SA, N_TA, N_TAtype [and N_AE] to the adjacent upper layer
(see 8.3 for parameter definition).
The parameters and are valid only if equals N_OK.
N_USData.indication (
Mtype
N_SA
N_TA
N_TAtype
[N_AE]



)
The N_USData.indication 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 network layer detects any type of error in an SF, then the message shall be ignored by the network
layer and no N_USData.indication shall be issued to the adjacent upper layer.
8.2.5 N_ChangeParameters.request
The service primitive is used to request the change of an internal parameter’s value on the local protocol
entity. The is assigned to the (see 8.3 for parameter definition).
A parameter change is always possible, except after reception of the FF (N_USData_FF.indication) and
until the end of reception of the corresponding message (N_USData.indication).
N_ChangeParameter.request (
Mtype
N_SA
N_TA
N_TAtype
[N_AE]


)
This is an optional service that can be replaced by implementation of fixed parameter values.
12 © ISO 2016 – All rights reserved

8.2.6 N_ChangeParameter.confirm
The service primitive confirms completion of an N_ChangeParameter.confirm service applying to
a message identified by the address information in N_SA, N_TA, N_TAtype [and N_AE] (see 8.3 for
parameter definition).
N_ChangeParameter.confirm (
Mtype
N_SA
N_TA
N_TAtype
[N_AE]


)
8.3 Service data unit specification
8.3.1 Mtype, message type
Type: enumeration
Range: diagnostics, remote diagnostics
Description: The parameter Mtype shall be used to identify the type and range of address information
parameters included in a service call. This part of ISO 15765 specifies a range of two values for this
parameter. The intention is that users of this part of ISO 15765 can extend the range of values by
specifying other types and combinations of address information parameters to be used with the network
layer protocol specified in this part of ISO 15765. For each such new range of address information, a
new value for the Mtype parameter shall be specified to identify the new address information.
— If Mtype = diagnostics, then the address information N_AI shall consist of the parameters N_SA,
N_TA, and N_TAtype.
— If Mtype = remote diagnostics, then the address information N_AI shall consist of the parameters
N_SA, N_TA, N_TAtype, and N_AE.
8.3.2 N_AI, address information
8.3.2.1 N_AI description
These parameters refer to addressing information. As a whole, the N_AI parameters are used to identify
the source address (N_SA), the target address (N_TA) of message senders and recipients, as well as the
communication model for the message (N_TAtype) and the optional address extension (N_AE).
8.3.2.2 N_SA, network source address
Type: 8 bits
Range: 00 to FF
16 16
Description: The N_SA parameter shall be used to encode the sending network layer protocol entity.
8.3.2.3 N_TA, network target address
Type: 8 bits
Range: 00 to FF
16 16
Description: The N_TA parameter shall be used to encode one or multiple (depending on the N_TAtype:
physical or functional) receiving network layer protocol entities.
8.3.2.4 N_TAtype, Network target address type
Type: enumeration
Range: see Table 4
Description: The parameter N_TAtype is an extension to the N_TA parameter. It shall be used to encode
the communication model used by the communicating peer entities of the network layer (see Figure 2).
The following requirements shall be supported.
— The network layer protocol shall be capable of carrying out parallel transmission of different
messages that are not mapped onto the same N_AI.
— Error handling for unexpected PDUs only pertains to messages with the same N_AI.
— CLASSICAL CAN frames will not cause a CAN FD message to be terminated and vice-versa.
— This explicitly prevents mixing CAN FD/CLASSICAL CAN frame types in a single message.
Table 4 defines the allowed combinations of N_TAtype communication models.
Table 4 — Allowed combinations of N_TAtype communication models
Physical/Functio
...