ISO 11898:1993

Road vehicles - Interchange of digital information - Controller area network (CAN) for high-speed communication

Describes the general architecture of CAN in terms of hierarchical layers according to the ISO reference model for OSI specified in ISO 7498. Contains detailed specifications of aspects of CAN belonging to the physical layer and the data link layer. Specifies characteristics of setting up an interchange of digital information between electron control units of road vehicles equipped with CAN at transmission rates above 125 kbit/s up to 1 Mbit/s. The CAN is a serial communication protocol which supports distributed real-time control and multiplexing.

Véhicules routiers — Échange d'information numérique — Gestionnaire de réseau de communication à vitesse élevée (CAN)

General Information

• Status: Withdrawn
• Publication Date: 17-Nov-1993
• Withdrawal Date: 17-Nov-1993
• ICS: 43.040.15 - Car informatics. On board computer systems
• Technical Committee: ISO/TC 22 - Road vehicles
• Drafting Committee: ISO/TC 22 - Road vehicles
• Current Stage: 9599 - Withdrawal of International Standard
• Start Date: 19-Nov-2003
• Completion Date: 13-Dec-2025

Relations

• Amended By: ISO 11898:1993/Amd 1:1995 - Road vehicles - Interchange of digital information - Controller area network (CAN) for high-speed communication - Amendment 1
• Effective Date: 06-Jun-2022
• Revised: ISO 11898-1:2003 - Road vehicles - Controller area network (CAN) - Part 1: Data link layer and physical signalling
• Effective Date: 15-Apr-2008
• Revised: ISO 11898-2:2003 - Road vehicles - Controller area network (CAN) - Part 2: High-speed medium access unit
• Effective Date: 15-Apr-2008
• Parent: ISO 11898:1993/Amd 1:1995 - Road vehicles - Interchange of digital information - Controller area network (CAN) for high-speed communication - Amendment 1
• Effective Date: 15-Apr-2008

Standards Content (Sample)

IS0
INTERNATIONAL
STANDARD
First edition
1993-l 1-l 5
Road vehicles - Interchange of digital
information - Controller area network
(CAN) for high-speed communication
V6hicules routiers - khange d ‘informa tion numbrique - Gestionnaire
de rtbeau de communication 9 vitesse B/e&e (CAN)
Reference number
IS0 11898:1993(E)
IS0 11898:1993(E)
Contents
Page
1 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .~.~.
2 Normative references . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .~.
abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3 Definitions and
. . . . . . . . . . . . . . . . . . . . . . . . . . . .*.
3.1 Data link layer definitions
. . . . . . . . . . .*.
3.2 Physical layer definitions
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .~.
3.3 List of abbreviations
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4 Basic concepts of CAN
4.1 Frames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2 Bus access method
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3 Information routing
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.4 System flexibility
..,...............................,..............,..................
4.5 Data consistency
,.,.,.,.
4.6 Remote data request
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.7 Error detection
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.8 Error signalling and recovery time
..,,.,...,,,.....................,,,.,............................
4.9 Acknowledgement
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.10 Automatic retransmission
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.11 Fault confinement
4.12 ” error-active ” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.13 “error-passive”
,,.*.,.,,.,.,.
4.14 “bus off”
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Layered architecture of CAN
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.1 Reference to OSI model
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2 Protocol specification
. . . . . . . . . . . . .*.
5.3 Format description of services
0 IS0 1993
All rights reserved. No part of this publication may be reproduced or utilized in any form or
by any means, electronic or mechanical, including photocopying and microfilm, without per-
mission in writing from the publisher.
International Organization for Standardization
Case Postale 56 l CH-1211 Geneve 20 l Switzerland
Printed in Switzerland
ii
.......................................................................... 9
5.4 LLC interface
...................................................... 9
6 Description of LLC sublayer
6.1 Services of LLC sublayer . 10
....................................................... 13
6.2 Structure of LLC frames
.................................................... 15
6.3 Functions of LLC sublayer
........................................... 15
7 Interface between LLC and MAC
8 Description of MAC sublayer . 16
8.1 MAC sublayer .
8.2 Services of MAC sublayer . . . . . . . . . . .*.
Functional model of MAC sublayer architecture . 21
8.3
..................................................... 22
8.4 Structure of MAC frames
........................................................................ 27
8.5 Frame coding
8.6 Order of bit transmission .
8.7 Frame validation .
8.8 Medium access method .
8.9 Error detection . 29
.................................................................... 29
8.10 Error signalling
............................................................. 29
8.11 Overload signalling
LLC and MAC sublayer conformance . 30
................................................. 30
10 Description of physical layer
..................................... 30
10.1 Functional model of physical layer
................................................... 31
10.2 Services of physical layer
10.3 Physical Signalling (PLS) sublayer specification .
10.4 PLS-PMA interface specification . 34
10.5 Description of High-Speed Medium Access Unit (HS-MAU) 35
...................................................... 50
11 Description of supervisor
............................................................... 50
11.1 Fault confinement
11.2 Bus failure management .

IS0 11898:1993(E)
Foreword
IS0 (the International Organization for Standardization) is a worldwide
federation of national standards bodies (IS0 member bodies). The work
of preparing International Standards is normally carried out through IS0
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. IS0
collaborates closely with the International Electrotechnical Commission
(IEC) on all matters of electrotechnical standardization.
Draft International Standards adopted by the technical committees are
circulated to the member bodies for voting. Publication as an International
Standard requires approval by at least 75 % of the member bodies casting
a vote.
International Standard IS0 11898 was prepared by Technical Committee
lSO/TC 22, Road vehicles, Sub-Committee SC 3, Electrical and electronic
equipment.
IS0 11898:1993(E)
INTERNATIONAL STANDARD
- Interchange of digital information -
Road vehicles
Controller area network (CAN) for high-speed
communication
1 Scope
This International Standard specifies characteristics of setting up an interchange of digital information between
Electronic Control Units (ECUs) of road vehicles equipped with the Controller Area Network at transmission rates
above 125 kbit/s up to 1 Mbit/s.
The Controller Area Network (CAN) is a serial communication protocol which supports distributed real-time control
and multiplexing.
This specification of CAN describes the general architecture of CAN in terms of hierarchical layers according to the
IS0 reference model for Open Systems Interconnection (OSI) specified in IS0 7498. The data link layer and
physical layer are specified according to IS0 8802-2 and IS0 8802-3. This International Standard contains detailed
specifications of aspects of CAN belonging to the
a) physical layer;
b) data link layer
- Logical Link Control (LLC) sublayer,
- Medium Access Control (MAC) sublayer.
All other layers of the OSI model do not have counterparts within this specification of CAN protocol but are part
of the user’s level.
2 Normative references
The following standards contain provisions which, through reference in this text, constitute provisions of this part
of IS0 11898. At the time of publication, the editions indicated were valid. All standards are subject to revision,
and parties to agreements based on this part of IS0 11898 are encouraged to investigate the possibility of applying
the most recent editions of the standards indicated below. Members of IEC and IS0 maintain registers of currently
valid International Standards.
- Open Systems Interconnection - Basic Reference Model.
I SO 7498: 1984, lnforma tion processing systems
- Electrical disturbance by conduction and coupling - Part 3: Passenger cars and
IS0 7637-3: -l), Road vehicles
light commercial vehicles with nominal 12 V supply voltage and commercial vehicles with 24 V supply voltage -
Electrical transient transmission by capacitive and inductive coupling via lines other than supply lines.
IS0 8802-2:1989, Information processing systems - Local area networks - Part 2: Logical link control.
1) To be published.
IS0 11898:1993(E)
Local and metropolitan area networks - Part 3: Carrier sense
lSO/l EC 8802-3: 1993, Information technology -
multiple access with collision detection (CSMA/CD) access method and physical layer specifications.
3 Definitions and abbreviations
For the purposes of this International Standard, the following definitions apply.
3.1 Data link layer definitions
3.1.1 bit rate: Number of bits per time during transmission, independent of bit representation.
3.1.2 bit stuffing: Technique used in bit-oriented protocols in order
- to achieve data transparency (arbitrary bit patterns may not be interpreted as protocol information), and
- to provide “dominant” to “recessive” edges, and vice versa, which are necessary for correct resynchronization
when using a Non-Return-to-Zero bit representation.
Whenever the transmitting logic encounters a certain number (stuff width) of consecutive bits of equal value in the
data, it automatically stuffs a bit of complementary value - a stuff bit - into the outgoing bit stream. Receivers
destuff the frame, i.e. the inverse procedure is carried out.
3.1.3 bus: Topology of a communication network, where all nodes are reached by passive links which allow
transmission in both directions.
3.1.4 bus value: One of two complementary logical values: “dominant” or “recessive”. The “dominant“ value
During simultaneous transmission of
represents the logical “O“, and the “recessive” represents the logical “1 ‘I.
“dominant” and “recessive” bits, the resulting bus value will be “dominant”.
contention-based arbitration: Carrier Sense Multiple Access (CSMA) arbitration procedure where simul-
3.1.5
taneous access of multiple nodes results in a contention. One frame will survive the contention uncorrupted.
3.1.6 frame: Data link protocol data unit specifying the arrangement and meaning of bits or bit fields in the se-
quence of transfer across the transmission medium.
multicast: Addressing where a single frame is addressed to a group of nodes simultaneously. Broadcast
3.1.7
is a special case of multicast, whereby a single frame is addressed to all nodes simultaneously.
3.1.8 multi-master: System partitioned into several nodes where every node may temporarily control the action
of other nodes.
3.1.9 node: Any assembly, linked to a commun ication line, capable of communicating across the network ac-
Is pecification.
cording to a communication protoco
3.1.1 0 non-return-to-zero: Method of representi ng binary signals . Within one an d the same bit time, the signal
level does not change, i.e. a stream of bits having the same logical value provides no edges.
3.1.11 priority: Attribute to a frame controlling its ranking during arbitration. A high priority increases the proba-
bility that a frame wins the arbitration process.
3.1.12 protocol: Formal set of conventions or rules for the exchange of information between nodes, including
the specification of frame administration, frame transfer and physical layer.
3.1.13 receiver: Device that converts physical signals used for transmission back into logical information or data
signals.
3.1.14 transmitter: Device that converts information or data signals to electrical or optical signals so that these
signals can be transferred across the communication medium.

IS0 11898:1993(E)
3.2 Physical layer definitions
3.2.1 common mode bus voltage range: Boundary voltage levels of VCAN L and VCAN H, for which proper op-
eration is guaranteed if up to the maximum number of ECUs are connected to the bus Iin%.
3.2.2 differential internal capacitance, C diff (of an ECU): Capacitance seen between CAN-L and CAN-H during
the recessive state when the ECU is disconnected from the bus line. (See figure 1.)
3.2.3 differential internal resistance, R diff (of an ECU): Resistance which is seen between CAN-L and CAN-H
during the recessive state when the ECU is disconnected from the bus line. (See figure 1.)
3.2.4 differential voltage, Vdiff: value
V
diff = VCAN-H - VCAN-L
with the voltages VCAN L and VCAN H denoting the voltages of CAN-L and CAN-H relative to ground of each in-
dividual ECU.
3.2.5 internal capacitance, Ci” (of an ECU): Capacitance seen between CAN-L (or CAN-H) and ground during
the recessive state when the ECU is disconnected from the bus line. (See figure 1.)
3.2.6 internal delay time, t Ecu (of an ECU): Sum of all asynchronous delay times occurring on the transmitting
and receiving path relative to the bit timing logic unit of the protocol IC of each individual ECU disconnected from
the bus line.
3.2.7 internal resistance, Ri” (of an ECU): Resistance which is seen between CAN-L (or CAN-H) and ground
during the recessive state when the ECU is disconnected from the bus line. (See figure 1.)
3.2.8 physical layer: Electrical circuit realization that connects an ECU to a bus. The total number of ECUs con-
nected on a bus is limited by electrical loads on the bus line.
3.2.9 physical media (of the bus): Pair of parallel wires, shielded or unshielded, dependent on EMC require-
ments. The individual wires are designated as CAN L and CAN-H. The names of the corresponding pins of ECUs
are also denoted by CAN-L and CAN-H respectively.
c------------------------------------------------------
f
i
I
I
ECU
I
I
f
RI"
I
r----w
w
I v CAN-L
I
--s-w J
I
I I
-i
I
I
I .---.
I
IR
I diff
r ‘I .,,-.Cdiff ;
I
I 1
I
I
L-l
Rin
I
I
r-----1
m
w w CAN-H
f
L B-B-- l
f
I
in
I [in
--. ----.
I
-. .- -.
I I- Ie
I
I
t
I
Ground
I
I
I
::ir J_
I
I
I
~-------------------,,,,,,,,,,,,,,,,,,,,----------------
Figure 1
- Definitions of internal capacitances and internal resistances of ECU
IS0 11898:1993(E)
3.3 List of abbreviations
Acknowledgement
ACK
ECU Electronic Control Unit
EOF End of Frame
CAN Controller Area Network
CRC Cyclic Redundancy Check
DLC Data Length Code
IC Integrated Circuit
FCE Fault Confinement Entity
LAN Local Area Network
LLC Logical Link Control
LME Layer Management Entity
LPDU LLC Protocol Data Unit
LSB Least Significant Bit
LLC Service Data Unit
LSDU
MAC Medium Access Control
MAU Medium Access Unit
Medium Dependent Interface
MDI
MPDU MAC Protocol Data Unit
Most Significant Bit
MSB
MSDU MAC Service Data Unit
NRZ Non-Return-to-Zero
0% Open System Interconnection
PL Physical Layer
PLS Physical Signalling
PMA Physical Medium Attachment
RTR Remote Transmission Request
SOF Start of Frame
4 Basic concepts of CAN
CAN has the following properties:
- multi-master priority-based bus access;
- non-destructive contention-based arbitration;
- multicast frame transfer by acceptance filtering;
- remote data request;
- configuration flexibility;
- system-wide data consistency;
- error detection and error signalling;
- automatic retransmission of frames that have lost arbitration or have been destroyed by errors during trans-
mission;
switching-off of de-
- distinction between temporary errors and permanent failures of nodes and autonomous
fective nodes.
4.1 Frames
Information on the bus is sent in fixed format frames of different but limited length. When the bus is idle, any
new frame.
connected node may start to transmit a
4.2 Bus access method
When the bus is idle, any node may start to transmit a frame. If two or more nodes start to transmit frames at the
same time, the bus access conflict is resolved by contention-based arbitration using the identifier. The mechanism
of arbitration guarantees that neither information nor time is lost. The transmitter with the frame of highest priority
gains bus access.
4.3 Information routing
In CAN systems a node does not make use of any information about the system configuration (e.g. node address).
Instead, receivers accept or do not accept information based upon a process called “Frame Acceptance
Filtering “, which decides whether the received information is relevant or not. There is no need for receivers to
know the transmitter of the information and vice versa.
4.4 System flexibility
Nodes may be added to the CAN network without requiring any change in the software or hardware of any node,
if the added node is not the transmitter of any data frame or if the added node does not require any additional
transmitted data.
4.5 Data consistency
Within a CAN network it is guaranteed that a frame is simultaneously accepted either by all nodes or by no node.
Thus data consistency is a property of the system achieved by the concepts of multicast and by error handling.
4.6 Remote data request
By sending a remote frame, a node requiring data may request another node to send the corresponding data
frame. The data frame and the corresponding remote frame are named by the same identifier.
4.7 Error detection
For dectecting errors, the following measures are provided:
- monitoring (transmitters compare the bit levels to be transmitted with the bit levels detected on the bus);
- 15-bit cyclic redundancy check;
- variable bit stuffing with a stuff width of 5;
- frame check.
IS0 11898:1993(E)
4.8 Error signalling and recovery time
Corrupted frames are flagged by any transmitting node and any normallly operating (error-active) receiving node.
Such frames are aborted and will be retransmitted according to the implemented recovery procedure (see 6.3.3).
The recovery time from detecting an error until the possible start of the next frame is typically 17 to 23 bit times
(in the case of a heavily disturbed bus, up to 29 bit times), if there are no further errors.
4.9 Acknowledgement
All receivers check the consistency of the received frame and will acknowledge a consistent frame and flag an
inconsistent frame.
4.10 Automatic retransmission
Frames that have lost arbitration and frames that have been disturbed by errors during transmission will be re-
transmitted automatically when the bus is idle again. A frame that will be retransmitted is handled like any other
frame. This means that it participates in the arbitration process in order to gain bus access.
4.11 Fault confinement
CAN nodes are able to distinguish short disturbances from permanent failures. Defective transmitting nodes are
switched off. “Switched off” means that a node is logically disconnected from the bus line, so that it can neither
send nor receive any frames.
4.12 “error-active”
An “error-active” node can normally take part in bus communication and send an active error flag when an error
has been detected. The active error flag consists of six (6) dominant consecutive bits and violates the rule of bit
stuffing and all fixed formats appearing in a regular frame (see 11 J.5).
4.13 “error-passive”
An “error-passive” node shall not send an active error flag. It takes part in bus communication, but when an error
has been detected a passive error flag is sent. The passive error flag consists of six (6) recessive consecutive bits.
After transmission, an “error-passive” node will wait some additional time before initiating a further transmission
(see suspend transmission in 8.4.5 and 11 .1.5).
4.14 “bus off”
A node is in the state “bus off” when it is switched off from the bus due to a request of fault confinement entity.
In the “bus off” state, a node can neither send nor receive any frames. A node can leave the “bus off” state only
upon a user request.
5 Layered architecture of CAN
5.1 Reference to OSI model
According to the OSI reference model, the CAN architecture represents two layers:
- data link layer,
- physical layer.
This International Standard specifies the data link and the physical layer of CAN (see figure 2).
According to IS0 8802-2 and IS0 8802-3 (LAN standards), the data link layer is subdivided into:
- Logic Link Control (LLC);
- Medium Access Control (MAC).
The physical layer is subdivided into:
- Physical Signalling (PLS);
- Physical Medium Attachment (PMA);
- Medium Dependent Interface (MDI).
The MAC sublayer operations are supervised by a management entity called the “Fault Confinement Entity
(FCE)“. Fault confinement is a self-checking mechanism that makes it possible to distinguish short disturbances
from permanent failures (fault confinement: see 11 .l).
The physical layer may be supervised by an entity that detects and manages failures of the physical medium (for
example, shorted or interrupted bus lines, bus failure management: see 11.2).
Data link layer
Supervisor
LLC
Acceptance filtering
Overload notification
Recovery management
. . . .---.-.-.-----.-.*.
MAC
Data encapsulation
/decapsulation
Frame coding
Fault
(stuffing, destuffing)
confinement
Medium access management
Error detection
(MAC-LME)
I
Error signalling
Acknowledgement
Serialization/deserialization
Physical layer‘
PLS
Bit encoding/decoding
Bit timing
Synchronization
. . . . . . . .*.*.*.-.
PMA
Driver/receiver characteristics
).*.*.-.-.*.~
MDI
Connectors
Figure 2 - Layered architecture of CAN
IS0 11898:1993(E)
5.2 Protocol specification
Two peer protocol entities communicate with each other by exchanging frame or Protocol Data Units (PDUs). An
(N)-layer Protocol Data Unit (NPDU) consists of N-layer specific Protocol Control Information (N-PCI) and (N)-user
data. In order to transfer a NPDU it must be passed to a (N-1)-layer entity via a (N-1)-Service Access Point
[(N-l)-SAP]. The NPDU is passed by means of the (N-l)-layer Service Data Unit [(N-l)-SDU] to the (N-l)-layer, the
services of which allow the transfer of the NPDU. The service data unit is the interface data whose identity is
preserved between (N)-layer entities, i.e. it represents the logical data unit transferred by a service. The data link
layer of the CAN protocol does not provide means for mapping one SDU into multiple PDUs nor means for
mapping multiple SDUs into one PDU, i.e. a NPDU is directly constructed from the associated NSDU and the layer
specific control information N-PCI. Figure 3 illustrates the data link sublayer interactions.
LSDU
LLC frame
{LpDUf----
MAC frame
M
w----
{MpDUt-
A
C
Physical Layer Interface
Figure 3 - Protocol layer interactions
5.3 Format description of services
5.3.1 Format description of service primitives
Service primitives are written in the form:
service.type(
[parameterl,.]
“service” indicates the name of the service, e.g. L-DATA for data transfer service provided by the LLC sublayer.
“type” indicates the type of the service primitives (see 5.3.2).
“[parameter1 ,.I’* is the list of values passed to the service primitives.
The brackets indicate that this parameter list may be empty.

5.3.2 Types of service primitives
Service primitives are of three generic types:
service. request
The request primitive is passed from the (N)-user (service user) to the (N)-layer (service provider) to request initi-
ation of the service.
service. indication
The indication primitive is passed from the (N)-layer to the (N)-user to indicate an internal (N)-layer (or sublayer)
event which is significant to the (N)-user. This event may be logically related to a remote service request, or may
be caused by an event internal to the (N)-layer (or sublayer).
service. confirm
The confirm primitive is passed from the (N)-layer (or sublayer) to the (N)-user to convey the results of one or more
associated previous service request(s). This primitive may indicate either failure to comply or some level of com-
pliance. It does not necessarily indicate any activity at the remote peer interface.
5.4 LLC interface
The LLC sublayer offers two types of connectionless transmission services to the LLC user:
- unacknowledged data transfer service,
- unacknowledged remote data request service.
The interface service data from or to the user is described in 6.1.2. The messages that can be sent between LLC
user and LLC sublayer are shown in table 1 a) and b).
Table 1 - Messages between LLC user and LLC sublayer
. /
a) Message sent from LLC user to LLC sublayer
User to LLC message Meaning
I
Reset-Request Request to set the node into an
initial state
b) Messages sent from LLC sublayer to LLC user
I I
LLC to user message Meaning
I I I
Reset-Response Response to the
Reset-Request
Node-Status Indicates the current status of
the node, i.e. it signals whether
or not the node is in the state
“bus off “.
I I
The LLC interface messages from and to the supervisor fault confinement entity are described in 11 .1.3.1.
6 Description of LLC sublayer
The LLC (Logical Link Control) sublayer describes the upper part of the OSI data link layer. It is concerned with
those protocol issues that are independent of the type of medium access method.

IS0 11898:1993.(E)
6.1 Services of LLC sublayer
6.1.1 LLC sublayer
The LLC sublayer offers two types of connectionless-mode transmission services:
Unacknowledged data transfer service
This service provides means by which LLC users can exchange Link Service Data Units (LSDU) without the es-
tablishment of a data link connection. The data transfer can be point-to-point, multicast or broadcast.
Unacknowledged remote data request service
This service provides means by which a LLC user can request another remote node to transmit a Link Service Data
Unit (LSDU) without the establishment of a data link connection.
The way ‘in which the remote node serves the data request is not specified here. Basically, there are two ways:
a) The requested data is prepared by the remote user for transmission. In this case the data is located in a remote
node buffer and will be transmitted by the LLC entity upon reception of the remote request frame.
b) The requested data will be transmitted by the remote user upon reception of the remote request frame.
According to the two different LLC services, there are two types of frames from or to the user:
- LLC Data Frame,
- LLC Remote Frame.
The LLC Data Frame carries data from a transmitter to a receiver. The LLC remote frame is transmitted to request
the transmission of a data frame (with the same identifier) from a (single) remote node. In both cases, the LLC
sublayer notifies the successful transmission or reception of a frame to the user.
6.1.2 Service primitive specification
This subclause describes in detail the LLC service primitives and their associated parameters. The complete list
of LLC service primitives is given in table 2.
Table 2 - LLC service primitives overview
Unacknowledged Data Transfer Service
L-Data.request Request for data transfer
I I I
L-Data.indication Indication of data transfer
L-Data.confirm Confirm data transfer
Unacknowledged Remote Data Request Service
L-Remote.request Request for remote data request
I
I I
L-Remote.indication Indication of remote data request
I I
L-Remote.confirm Confirmation remote data request
The parameters that are associated with the different LLC service primitives are listed in table3.
Table 3 - List of LLC service primitive parameters
identifies the data and its priority
Confirmation parameter
6.1.2.1 L-DATA.request
a) Function
The L DATA.request primitive is passed from the LLC user to the LLC sublayer to request that a LSDU be sent
to oneor more remote LLC entities.
b) Semantics of L-DATA.request primitive
The primitive shall provide parameters as follows:
L-DATA.request(
IDENTIFIER
DLC
DATA
The parameter DATA is insignificant if the associated LLC data frame is of data length zero.
c) Effect on receipt
Receipt of this primitive causes the LLC sublayer to initiate the transfer of a LLC data frame by use of the data
transfer service provided by the MAC sublayer (see table 5).
6.1.2.2 L-DATA.indication
Function
a)
The L DATA.indication primitive is passed from the LLC sublayer to the LLC user to indicate the arrival of a
LSDUr
b) Semantics of L-DATA.indication primitive
The primitive shall provide parameters as follows:
L-DATA.indication(
IDENTIFIER
DLC
DATA
)
The paramater DATA is insignificant if the associated LLC data frame is of data length zero.

IS0 11898:1993(E)
c) Effect on receipt
The effect on receipt of this primitive by the LLC user is unspecified.
6.1.2.3 L-DATA.confirm
a) Function
The L DATA.confirm primitive is passed from the local L -LC sublayer to the LLC user to convey the results of
the prkious L DATArequest primitive. This primitive is a local confirmation, i.e. it does not imply that the re-
mote LLC entity or entities have passed the associated ndication primitive to the corresponding LLC user(s).
b) Semantics of LBDATA.confirm primitive
The primitive shall provide parameters as follows:
L-DATA.confirm(
IDENTIFIER
TRANSFER STATUS
-
The TRANSFER STATUS is used to indicate the completion of the transaction initiated by the previous
L-DATArequest-primitive.
TRANSFER-STATUS: [COMPLETE,NOT-COMPLETE]
c) Effect on receipt
The effect on receipt of this primitive by the LLC user is unspecified.
6.1.2.4 LJlEMOTE.request
a) Function
The L REMOTE.request primitive is passed from the LLC user to the LLC sublayer to request a single remote
LLC entity to transmit a LSDU.
b) Semantics of L-REMOTE.request primitive
The primitive shall provide parameters as follows:
L-REMOTE.request(
IDENTIFIER
DLC
)
The value of DLC equals the length of the data field of the requested data frame.
c) Effect on receipt
Receipt of this primitive causes the LLC sublayer to initiate the transfer of an LSDU by use of the remote data
transfer service provided by the MAC sublayer (see table 5).
IS0 11898:1993(E)
6.1.2.5 L-REMOTE.indication
a) Function
The L-REMOTE.indication primitive is passed from the LLC sublayer to the LLC user to indicate the arrival of
a request for transmission of a LSDU.
b) Semantics of L-REMOTE.indication primitive
The primitive shall provide parameters as follows:
L REMOTE.indication(
-
IDENTIFIER
DLC
The identifier identifies the LSDU to be sent. The value of DLC equals the length of the data field of the re-
quested data frame.
c) Effect on receipt
The effect on receipt of this primitive by the LLC user is unspecified.
6.1.2.6 L-REMOTE.confirm
a) Function
The L REMOTE.confirm primitive is passed from the local LLC sublayer to the LLC user to convey the results
of the-previous L-REMOTE.request primitive. This primitive is a local confirmation, i.e. it does not imply that
the remote LLC entity has passed the associated indication primitive to the corresponding LLC user.
b) Semantics of L-REMOTE.confirm primitive
The primitive shall provide parameters as follows:
L-REMQTE.confirm(
IDENTIFIER
TRANSFER STATUS
-
)
The TRANSFER STATUS is used to indicate the completion of the transaction initiated by the previous
L-REMOTE.requkt primitive.
TRANSFER STATUS: [COMPLETE,NOT-COMPLETE]
-
c) Effect on receipt
The effect on receipt of this primitive by the LLC user is unspecified.
6.2 Structure of LLC frames
LLC frames are the data units that are exchanged between peer LLC entities (LPDU). The structure and format
of the LLC data and remote frame are specified subsequently.
IS0 <11898:1993(E)
6.2.1 Specification of LLC data frame
A LLC data frame is composed of three bit fields (see figure4):
- Identifier field,
- Data Length Code (DLC) field,
- LLC data field.
Identifier DLC LLC data
field field field
I
I I I
Figure 4 - LLC data frame
Identifier
The identifier’s length is 11 bits. The most significant bits (ID-10 to ID-4) shall not all be “1 ‘I.
DLC field
The number of bytes in the data field is indicated by the Data Length Code. This Data Length Code consists of
4 bits. The data field can be of length zero. The admissible number of data bytes for a data frame ranges from 0
to 8. Values other than those specified in table4 may not be used.
Table 4 - Coding of the numbers of data bytes by the
Data Length Code
Data Data Length Length Code Code
Number Number of of data data
I
bytes bytes
DLC3 DLC3 DLCZ DLCZ DLCI DLCI DLCO DLCO
r r
0 0 0 0
0 0 0 0 0 0
0 0 1 1
1 1 0 0 0 0
2 2 0 0 0 0 1 1 0 0
3 3 0 0 0 0 1 1 1 1
4 4 0 0 1 1 0 0 0 0
5 5 0 0 1 1 0 0 1 1
1 1 0 0
6 6 0 0 1 1
1 1 1 1
7 7 0 0 1 1
8 8 1 1 0 0 0 0 0 0
Data field
The data field consists of the data to be transferred within a data frame. It can contain from 0 bytes to 8 bytes,
and each byte contains 8 bits.
IS0 11898:1993(E)
6.2.2 Specification of LLC remote frame
A LLC remote frame is composed of two bit fields (see figure 5):
- Identifier field,
- DLC field.
ldentif ier
DLC
field
field
Figure 5 - LLC remote frame
The format of the LLC remote frame identifier is identical to the format of the LLC data frame identifier (see
6.2.1). There is no data field, independent of the value of the data length code. This value is the data length code
of the corresponding data frame.
6.3 Functions of LLC sublayer
The LLC sublayer provides the following functions:
a) frame acceptance filtering,
b) overload notification,
c) recovery management.
6.3.1 Frame acceptance filtering
A frame transaction initiated at the LLC sublayer is a single, self-contained operation independent of previous
frame transactions. The content of a frame is named by its identifier. The identifier does not indicate the destina-
tion of the frame but describes the meaning of the data. Each receiver decides by frame acceptance filtering
whether the frame is relevant for it or not.
6.3.2 Overload notification
The transmission of an overload frame will be initiated by the LLC sublayer if internal conditions of a receiver re-
quire delay of the next LLC data or LLC remote frame.
At most two overload frames may be generated to delay the next data frame or remote frame.
6.3.3 Recovery management
The LLC sublayer provides means for automatic retransmission of frames that have lost arbitration or that have
been disturbed by errors during transmission. The frame transmission service will not be confirmed to the user
before the transmission is successfully completed.
7 Interface between LLC and MAC
The MAC sublayer provides services to the local LLC for
- (MAC-) acknowledged transfer of LLC frames,
IS0 11898:1993(E)
- transmission of overload frames.
The interface service data from or to the LLC sublayer is described in 6.1.
8 Description of MAC sublayer
8.1 MAC sublayer
The MAC (Medium Access Control) sublayer represents the lower part of the OSI Data Link Layer. It services the
interface to the LLC sublayer and the physical layer, and comprises the functions and rules that are related to
- encapsulation/decapsulation of the transmit/receive data,
- error detection and signalling,
- management of the transmit/receive medium access.
8.2 Services of MAC sublayer
The services provided by the MAC sublayer allow the local LLC sublayer entity to exchange MAC Service Data
Units (MSDU) with the peer LLC sublayer entities. The MAC sublayer services are:
Acknowledged data transfer
This service provides means by which LLC entities can exchange MSDUs without the establishment of a data link
connection. The data transfer can be point-to-point, multicast or broadcast.
Acknowledged remote data request
This service provides means by which a LLC entity can request another remote node to transmit an LSDU without
the establishment of a data link connection. The remote LLC entity uses the MAC service “acknowledged data
transfer” for the transmission of the requested data. In both cases acknowledgement of a service is generated
by the MAC sublayer of the remote node(s). Acknowledgement does not contain any data of the remote node’s
user.
Overload frame transfer
This service provides means by which a LLC entity can initiate the transmission of an overload frame, a special
fixed format LPDU, to cause the delay of the next data frame or remote frame.
The service primitives the MAC sublayer provides to the LLC sublayer are given in table 5.
Table 5
- MAC sublayer service primitives
Acknowledged Data Transfer
MA-DATA.confirm
MA-DATA.request MA-DATA.indication
I I
Acknowledged Remote Data Request
MA-REMOTE.request MA _ REMOTE.indication MA-REMOTE.confirm
I I
Overload Frame Transfer
MA-OVLD .conf irm
MA-OVLD.request MA-OVLD.indication
I I I
8.2.1 MA-DATA.request
a)
The MATDATA.request primitive is passed from the LLC sublayer to the MAC sublayer to request that a MSDU
be sent to one or more remote MAC entities.
Semantics of MA-DATA.request primitive
b)
The primitive shall provide parameters as follows:
MA-DATA.request(
IDENTIFIER
DLC
DATA
The parameter DATA is insignificant for MAC data frames of data length zero.
Effect on receipt
d
Receipt of this primitive causes the MAC sublayer to prepare a protocol data unit by adding all MAC specific
control information (SOF, RTR bit, resewed bits, CRC, “recessive” bit during ACK-Slot, EOF) to the MSDU
coming from the LLC sublayer. The MAC PDU will be serialized and passed bit by bit as a service data unit to
the physical layer for transfer to the peer MAC sublayer entity or entities.
8.2.2 MA-DATA.indication
a) Function
The MATDATA.indication primitive is passed from the MAC sublayer to the LLC sublayer to indicate the arrival
of a MSDU.
b) Semantics of MA-DATA.indication primitive
The primitive shall provide parameters as follows:
MA-DATA.indication(
IDENTIFIER
DLC
DATA
The parameter DATA is insignificant if the associated MAC data frame is of data length zero. The arrival of a
MSDU is indicated to the LLC sublayer only if it has been received correctly.
c) Effect on receipt
The effect on receipt of this primitive by the LLC sublayer is unspecified.
8.2.3 MA-DATA.confirm
a) Function
The MA DATA.confirm primitive is passed from the local MAC sublayer to the LLC sublayer to convey the re-
sults of the previous MA DATA.request primitive. This primitive is a remote confirmation, i.e. it indicates that
the remote MAC entity oFentities have passed the associated indication primitive to the corresponding user(s).
IS0 11898:1993(E)
b) Semantics of MA_DATA.confirm primitive
The primitive shall provide parameters as follows:
MA-DATA.confirm(
IDENTIFIER
TRANSMISSION STATUS
-
)
The TRANSMISSION STATUS is used to indicate the success or failure of the previous MA-DATA-request
-
primitive.
TRANSMISSION-STATUS: [SUCCESS,NO SUCCESS]
-
Failures are either errors which occurred during transmission or loss of the arbitration.
c) Effect on receipt
The effect on receipt of this primitive by the LLC sublayer is unspecified.
8.2.4 MA-REMOTE.request
a) Function
The MATREMOTE.request primitive is passed from the LLC sublayer to the MAC sublayer to request a single
remote MAC entity to transmit a MSDU.
b) Semantics of MA_REMOTE.request primitive
The primitive shall provide parameters as follows:
MA-REMOTE.request(
IDENTIFIER
DLC
The identifier identifies the MSDU to be sent. The value of DLC equals the length of the data of the requested
MSDU.
c) Effect on receipt
Receipt of this primitive causes the MAC sublayer to prepare a protocol data unit by adding all MAC specific
control information (SOF, RTR bit, reserved bits, CRC, “recessive” bit during ACK-Slot, EOF) to the MSDU
coming from the LLC sublayer. The MAC PDU will be serialized and passed bit by bit as a service data unit to
the physical layer for transfer to the peer MAC sublayer entity or entities.
8.2.5 MA-REMOTE.indication
a) Function
The MA REMOTE.indication primitive is passed from the MAC sublayer to the LLC sublayer to indicate the
arrival of-a request for transmission of a MSDU.
b) Semantics of MA-REMOTE.indication primitive
The primitive shall provide parameters as follows:
IS0 11898:1993(E)
MA-REMOTE.indication(
IDENTIFIER
DLC
The arrival of a MSDU transmission request is indicated to the LLC sublayer only if it has been received cor-
rectly.
c) Effect of receipt
The effect of receipt on this primitive by the LLC sublayer is unspecified.
8.2.6 MA-REMOTE.confirm
a)
The MA_REMOTE.confirm primitive is passed from the local MAC sublayer to the LLC sublayer to convey the
results of the previous MA REMOTE.request. This primitive is a remote confirmation, i.e. it indicates that the
remote MAC entity or entities have passed the associated indication primitive to the corresponding user(s).
Semantics of MA-REMOTE.confirm primitive
b)
The primitive shall provide parameters as follows:
MA-REMOTE.confirm(
IDENTIFIER
TRANSMISSION STATUS
-
>
The TRANSMISSION-STATUS is used to indicate the success or failure of the previous
MA-REMOTE.request primitive.
TRANSMISSION-STATUS: [SUCCESS,NO SUCCESS]
-
Failures are either errors which occurred during transmission or loss of the arbitration.
Effect on receipt
cl
The effect on receipt of this primitive by the LLC sublayer is unspecified.
8.2.7 MA-OVLD.request
a) Function
The MA OVLD.request primitive is passed from the LLC sublayer to the MAC sublayer to request transmission
of a MAC overload frame (see 8.4.4). The overload frame is a fixed format frame and is completely constructed
in the MAC sublayer.
b) Semantics of MA-OVLD.request primitive
The primitive does not provide any parameter:
MA OVLD.request(
-
IS0 11898:1993(E)
c) Effect on receipt
Receipt of this primitive causes the MAC sublayer to form an overload frame. The overload frame will be
passed to the lower protocol layers for transfer to the peer MAC sublayer entities.
8.2.8 MA-OVLD.indication
Function
a)
The MA OVLD.indication primitive is passed from the MAC sublayer to the LLC sublayer to indicate that an
overload-frame has been
...