ISO 11519-2:1994

INTERNATIONAL
STANDARD
First edition
1994-06-I 5
Road vehicles - Low-speed serial data
.I
communication -
Part 2:
Low-speed controller area network (CAN)
Whicules routiers - Communication en s&ie de don&es 9 basse
vitesse -
Partie 2: R6seau local 9 commande ~3 basse vitesse (CAN)
Reference number
IS0 11519-2:1994(E)
IS0 11519=2:1994(E)
Contents
Page
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1 Scope
........................................................ 1
2 Normative references . . . . . . . . . . . . .
3 Definitions and abbreviations .
3.1 Data link layer definitions .
........................................................ 2
3.2 Physical layer definitions
3.3 List of abbreviations .
4 Basic concepts of CAN .
....................................................................................
41 . Frames
42 . Bus access method .
Information routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43 .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
44 . System flexibility
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
45 . Data consistency
46 . Remote data request .
47 . Error detection .
. Error signalling and recovery time .
49 . Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.10 Automatic retransmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.11 Fault confinement .
4.12 ” error-active ” .
4.13 “error-passive” .
4.14 “bus off” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5 Layered architecture of CAN
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1 Reference to the OSI model
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2 Protocol specification
. . . . . . . . . . . . . . . . .*.
5.3 Format description of services
0 IS0 1994
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
IS0 11519=2:1994(E)
5.4 LLC interface .
............................................. 10
6 Description of the LLC sublayer
................................................. 10
6.1 Service of the LLC sublayer
.............................................. 10
6.2 Service primitive specification
.......................................................
6.3 Structure of LLC frames
............................................. : 15
Functions of the LLC sublayer
6.4
...........................................
7 Interface between LLC and MAC
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8 Description of the MAC sublayer
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.1 Services of the MAC sublayer
. . . . . . . . . . . 21
8.2 Functional model of the MAC sublayer architecture
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
8.3 Structure of MAC frames
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .*.
8.4 Frame coding
. . . . . . . . . . . . . . . . . .s.~. 27
8.5 Order of the bit transmission
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.6 Frame validation
I
. . . . . . . . . . . . .~.
8.7 Medium access method
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.8 Error detection
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.9 Error signalling
:.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.10 Overload signalling
II
. . . . . . . . . . * . . . . . . . . . . . . . . . . . . . . . . . . . . .
9 LLC and MAC sublayer conformance
. . . . . . . . . . . - . .~. -’ ’
10 Description of the physical layer T
i
,30
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.1 Functional model of the physical layer
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
10.2 Services of the physical layer
. . . . . . . . . . . . . . . . . 31
Physical Signalling (PLS) sublayer specification
10.3
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
10.4 PLS-PMA interface specification
10.5 Description of the low-speed medium access unit (LS-MAU)
. . . . . . . .*.
11 Description of the supervisor
Fault confinement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11 .l
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11.2 Bus failure management
. . .
III
IS0 11519=2:1994(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 11519-2 was prepared by Technical Committee
lSO/TC 22, Road vehicles, Sub-Committee SC 3, Electrical and electronic
equipment.
IS0 11519 consists of the following parts, under the general title Road
vehicles - Lo w-speed serial data communication:
- Part 1: General and definitions
- Part 2: Low-speed controller area network (CAN)
- Part 3: Vehicle area network (VAN)
- Part 4: Class B data communication network interface (J 1850)

INTERNATIONAL STANDARD IS0 11519=2:1994(E)
Road vehicles - Low-speed serial data
communication -
Part 2: ’
Low-speed controHer area network (CAN)
1 Scope
P’
This part of IS0 11519 specifies the data link layer and the physical layer of the low-speed Controller Area Network
(CAN), a cotimunications network up to 125 kbit/s, *for road vehicle application. The loWspeed ‘CAN is a seiial
communication protocol supporting distributed real-time control and multiplexing.
This specification describes the general architecture of CAN in terms of the hierarchical layers defined in the
ISO-OSI model according to IS0 7498.
_ .
Y
2 Normative references
The following standards contain provisions which, through reference in this text, constitute provisions of this part
of IS0 11519. 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 11519 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.
I SO 7498: 1984, Information processing systems - Open Systems Interconnection - Basic Reference Model.
IS0 8802-2:1989, Information processing systems - Local area networks - Part 2: Logical link control.
I SO/I EC 8802-3: 1993, Information technology - Local and metropolitan area networks - Part 3: Carrier sense
multiple access with collision detection (CSMA/CD) access ‘method ,and physical la,yer specifications.
IS0 11519-I :I 994, Road vehicles
- Low-speed serial data communication - Part I: General and definitions.
IS0 11519=2:1994(E) ’
3 Definitions and abbreviations
For the purposes of this part of IS0 11519 the definitions given in IS0 11519-l apply. The following additional
definitions and abbreviations are specific to this part of IS0 11519.
3.1 Data link layer definitions
3.1.1 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 stuffbit - into the outgoing bit stream. Receivers
destuff the frame, i.e. the inverse procedure is carried out.
3.1.2 bus value: One of two complementary logical values: “dominant” or “recessive”. The “dominant” value
represents the logical “0” and the “recessive” represents the logical “1”. During simultaneous transmission of
“dominant” and “recessive” bits, the resulting bus value will be “dominant”.
3.1.3 multicast: Method by which a single frame is addressed to a group of nodes simultaneously.
3.1.4 broadcast: Special case of multicast, whereby a single frame is addressed to all nodes simultaneously.
3.1.5 receiver: Device that converts signals used for transmission back into logical information or data signals.
3.1.6 transmitte.r: Device that converts information or data signals to electrical or optical signals so that these
signals can be transferred across the communication medium.
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 oper-
ation is guaranteed if the maximum number of electronic control units (ECUs) are connected to the bus line.
3.2.2 differential internal capacitance, cdiff:
Capacitance of an ECU 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.3 differential internal resistance, ZZdiff: Resistance of an ECU 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). T
3.2.4 differential voltage, Vdiff:
are the voltages of CAN-L and CAN-H, respectively, relative to ground of each individual
where vCAN-L and VCAN-H
ECU.
3.2.5 internal capacitance, C’in: Capacitance of an ECU 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?).
3.2.6 internal delay time, &:
Sum of all asynchronous delay times of an ECU occurring on the transmitting
and receiving paths, 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”: Resistance of an ECU 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).

IS0 11519=2:1994(E)
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 electric loads on the bus line.
3.2.9 physical media: Pair of parallel wires of the bus, shielded or unshielded, depending on EMC requirements.
The individual wires are denoted as CAN-L and CAN-H. The corresponding pins of ECUs are also denoted by
CAN L and CAN-H.
-
ECU I
Rin
c----- 1
CAN-L
I
I
--I+ .- -.
Cdiff f
.- -.
I
I
L f
Rin
f
r
r-----1
CAN-H
--L
Ground
Figure 1 - Definitions of internal capacitances and internal resistances of an ECU
3.3 List of abbreviations
ACK Acknowledgement
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
LSDU LLC Service Data Unit
MAC Medium Access Control
MAU Medium Access Unit
IS0 11519-2:1994(E)
MDI Medium-Dependent Interface
MAC Protocol Data Unit
MPDU
Most Significant Bit
MSB
MSDU MAC Service Data Unit
Non-Return-to-Zero
NRZ
OSI 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:
- multimaster 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;
- distinction between temporary errors and permanent failures of nodes and autonomous switching-off of de-
fective nodes.
This part of IS0 11519 specifies the low-speed CAN for applications up to 125 kbit/s.
4.1 Frames
Information on the bus is sent in fixed format frames of different but limited lengths. When the bus is free, any
connected node may start to transmit a new frame.
42 . Bus access method
When the bus is free, 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 mech-
anism of arbitration guarantees that neither information nor time is lost. The transmitter with the frame of highest
priority gains bus access.
IS0 11519-2:1994(E)
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 can 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 (see 8.3.1).
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.
46 . 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
The following measures are provided for detecting errors:
- 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.
48 . Error signalling and recovery time
Corrupted frames are flagged by any transmitting node and any normally operating (error-active) receiving node.
Such frames are aborted and will be retransmitted according to the implemented recovery procedure (see 6.4.3).
The recovery time, from detecting an error until the possible start of the next frame, is typically 17 bit times 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, i.e. it participates in the arbitration process in order to gain bus access.

IS0 11519=2:1994(E)
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 dominant consecutive bits and violates the rule of bit
stuffing, all fixed formats appearing in a regular frame (see 11 .I .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 recessive consecutive bits.
After transmission, an “error-passive” node will wait an additional time before initiating a further transmission (see
suspend transmission in 8.3.5 and 11 .I .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 a 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 the OSI model
According to the OSI reference model, the CAN architecture represents two layers:
- data link layer,
- physical layer.
This standard describes the data link layer and physica I I i iyer of CAN, as shown in figure 2.
According to IS0 8802-2 and IS0 8802-3 (LAN standards ), the data I ink layer is subdivided into:
- Logical 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.1).
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).
IS0 11519-2:1994(E)
Data link layer
Supervisor
LLC
-----------------q
r
Acceptance filtering I
i
I
Overload notification
I
Recovery management
I
,.-.)--.---.-.----.---.--.---.---~
I
MAC
I
Data encapsulation
I I
Idecapsulation
I
Frame coding
f
(stuffing, destuffing)
I
Medium access management
I
Error detection
I
I
Error signalling
I
Acknowledgement
I
Serialization/deseriaLization
f
I
Physical layer
i
PLS
Bit encoding/decoding
Bit timing
Synchronization
,.*.-.
PMA
Driver/receiver characteristics
.-.-.*.*.-.--.,
MDI
Connectors
LLC = Logical Link Control
MAC = Medium Access Control
PLS = Physical Signalling
PMA = Physical Medium Attachment
MDI = Medium-Dependent Interface
LME = Layer Management Entity
Figure 2 - Layered architecture of CAN

IS0 11519=2:1994(E)
5.2 Protocol specification
Two peer protocol entities communicate with each other by exchanging frame or protocol data units (PDU). An
N-layer protocol data unit (NPDU) consists of an N-layer-specific protocol control information (n-PCI) and N-user
data. In order to transfer a NPDU it must be passed to an N-l layer entity via an N-l service access point
[(N-I)-SAP]. The NPDU
is passed by means of the N-l layer Service Data Unit [(N-I)-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 SDU, i.e. an NPDU is directly constructed from the associate NSDU and the
layer-specific control information N-PCI. Figure 3 illustrates the data link sublayer interactions.
LSDU _
LLC frame
piq-
MSDU
MAC frame
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(
[parameter,.]
.
where
- “service” indicates the name of the service, e.g. L DATA for data transfer service provided by the LLC sub-
-
layer;
- “type” indicates the type of the service primitives (see 5.3.2);
- “[parameter,.]” is the list of values passed to the service primitives. The brackets indicate that this parameter
list may be empty.
IS0 11519=2:1994(E)
5.3.2 Types of service primitives
Service primitives are of three generic types.
Service. request
a)
The request primitive is passed from the N-user (sewice user) to the N-layer (service provider) to request in-
itiation of the service.
b) Service. indica tion
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 sewice request, or
may be caused by an event internal to the N-layer (or sublayer).
Sewice. confirm
d
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 compliance. 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.2. The messages that can be exchanged between
LLC user and LLC sublayer are given in tables 1 and 2.
Table 1 - Message sent from LLC user to LLC sublayer
\
User-to-LLC
Meaning
message
Reset-Request Request to set the node into an initial state
Table 2 - Message sent from LLC sublayer to LLC user
LLC-to-user
Meaning
message
Reset-Response Response to the Reset-Request
Indicates the current status of the node, i.e.
Node Status it signals whether or not the node is in the
-
status “bus off”
\
The LLC interface messages from and to the supervisor fault confinement entity are described in 11 .I -3.1.
IS0 11519=2:1994(E)
6 Description of the 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.
6.1 Service of the LLC sublayer
The LLC sublayer offers two types of connectionless-mode transmission services:
a) 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.
b) Unacknowledged remote data request service
This service provides means by which LLC users 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.
1) 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.
2) 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 (or from) the user.
6.2 Service primitive specification
detail the LLC service primitives and their associated parameters. The complete list of
This section describes in
LLC service primitives is given in table3.
Table 3 - LLC service primitives overview
Unacknowledged data transfer service
L-DATA.request Request for data transfer
L-DATA.indication Indication of data transfer
L-DATA.confirm Confirmation of data transfer
Unacknowledged remote data request service
L-REMOTE.request Request for remote data transfer
L-REMOTE.indication Indication of remote data request
L-REMOTE.confirm Confirmation of remote data request
IS0 11519-2:1994(E)
The parameters that are associated with the different LLC service primitives are listed in table4.
Table 4 - List of LLC service primitive parameters
\
LLC LLC service service primitive primitive parameters parameters
IDENTIFIER IDENTIFIER Identifies Identifies the the data data and and its its priority priority
DLC DLC Data Data length length code code
DATA DATA Data Data the the user user wants wants to to transmit transmit
TRANSFER-STATUS TRANSFER-STATUS Confirmation Confirmation parameter parameter
\ \
I I
6.2.1 L-DATA.request
Function
a)
The L-DATA.request primitive is passed from the LLC user to the LLC sublayer to request that an LSDU be
sent to one or more remote LLC entities.
b) Semantics of the 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.
Effect on receipt
cl
Receipt of this primitive causes the LLC sublayer to initiate the transfer of an LLC data frame by use of the
data transfer service provided by the MAC sublayer (see 8.1 .l).
6.2.2 L_DATA.indication
a) Function
The L DATA.indication primitive is passed from the LLC sublayer to the LLC user to indicate the arrival of an
LSDU_
b) Semantics of the L-DATA.indication primitive
The primitive shall provide parameters as follows.
L-DATA.indication(
IDENTIFIER
DLC
DATA
The parameter DATA is insignificant if the associated LLC data frame is of data length zero.
IS0 11519=2:1994(E)
c) Effect on receipt
The effect of receipt of this primitive by the LLC user is unspecified.
6.2.3 L-DATA.confirm
a) Function
The L DATA.confirm primitive is passed from the local LLC sublayer to the LLC user to convey the results of
the pr&ious L-DATA.request 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 indication primitive to the corresponding LLC user ‘(S)
b) Semantics of the L-DATA.confirm primitive
The primitive shall provide parameters as fo lows.
L-DATA.confirm(
IDENTIFIER
TRANSFER-STATUS
)
The TRANSFER STATUS is used to indicate the completion of the transaction initiated by the previous
L-DATA.request-primitive.
TRANSFER-STATUS:[COMPLETE,NOT-COMPLETE]
c) Effect on receipt
The effect of receipt of this primitive by the LLC user is unspecified.
6.2.4 L-REMOTE.request
a) Function
The L REMOTErequest primitive is passed from the LLC user to the LLC sublayer to request a single remote
LLC entity to transmit an LSDU.
b) Semantics of the 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 8.1 .l).
IS0 11519-2:1994(E)
6.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 data transmission of an LSDU.
b) Semantics of the LTREMOTE.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 of receipt of this primitive by the LLC user is unspecified.
6.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 the L-REMOTE.confirm primitive
The primitive shall provide parameters as follows.
L-REMOTE.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 of receipt of this primitive by the LLC user is unspecified.
6.3 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 11519=2:1994(E)
6.3.1 Specification of the LLC data frame
An LLC data frame is composed of three bit fields (see figure4):
- Identifier field,
- Data Length Code (DLC) field,
- LLC data field.
ldentif ier
DLC LLC data
field field field
I
I I I
Figure 4 - LLC data frame
a) Identifier
The length of the identifier is 11 bits. The most significant bits (ID-IO to ID-4) shall not all be “1 “.
b) DLC field
The number of bytes in the data field is indicated by the data length code (see table 5). 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. Other values shall not be used.
Table 5 - Coding of the numbers of data bytes by the
data length code
/
Data length code
Number of data
bytes
DLC3 DLCZ DLCI DLCO
0 0 0 0 0
1 0 0 0 1
2 0 0 1 0
3 0 0 1 1
0 1 0 0
0 1 0 1
6 0 1 1 0
7 0 1 1 1
I 8 1 0 O I O I
c) Data field
The data field consists of the data to be transferred within a data frame. It can contains from 0 bytes to
8 bytes and each byte contains 8 bits.

IS0 11519=2:1994(E)
Specification of the LLC remote frame
6.3.2
An LLC remote frame is composed of two bit fields (see figure 5):
- Identifier field,
- DLC field.
ldentif ier DLC
I field I field I
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.3.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.4 Functions of the LLC sublayer
The LLC sublayer provides the following functions:
a) frame acceptance filtering,
b) overload notification,
c) recovery management.
6.4.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 desti-
nation of the frame but describes the meaning of the data. Each receiver decides by a frame acceptance filtering
whether the frame is relevant to it or not.
6.4.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.4.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,
Interface between LLC and MAC
The MAC sublayer provides services to the local LLC for:
- acknowledged transfer of LLC frames,
- transmission of overload frames.
The interface service data from or to the LLC sublayer is described in 8.1 l
IS0 11519-2:1994(E)
8 Description of the 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 relevant to:
- encapsulation/decapsulation of the transmit/receive data,
- error detection and signalling,
- management of the transmit/receive medium access.
8.1 Services of the 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
a)
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.
b) Acknowledged remote data request
This service provides means by which an 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 “acknowl-
edged 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 user.
Overload frame transfer
c)
This service provides means by which an 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.
8.1 .l Service primitive specification
The service primitives that the MAC sublayer provides to the LLC sublayer are given in table 6.
Table 6 - MAC sublayer service primitives
Acknowledged data transfer
MA-DATA. request MA-DATA.indication MA DATA.confirm
-
I I
Acknowledged remote data request
MA REMOTE.indication MA-REMOTE.confirm
MA-REMOTE.request _
I I
Overload frame transfer
MA-OVLD.request MA OVLD.indication MA OVLD.confirm
- -
I I
IS0 11519-2:1994(E)
8.1 .I .I MA-DATA.request
a) Function
The MA-DATArequest primitive is passed from the LLC sublayer to the MAC sublayer to request that an
MSDU be sent to one or more remote MAC entities.
b) Semantics of the MA-DATA.request primitive
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.
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.1 .I .2 MA-DATA.indication
a) Function
The MA DATA.indication primitive is passed from the MAC sublayer to the LLC sublayer to indicate the arrival
of an MSDU.
b) Semantics of the 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 an
MSDU is indicated to the LLC sublayer only if it has been received correctly.
c) Effect on receipt
The effect of receipt of this primitive by the LLC sublayer is unspecified.
8.1 .I .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 11519-2:1994(E)
b) Semantics of the 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 MATDATA.request
primitive.
TRANSMISSION-STATUS:- [SUCCESS,NO-SUCCESS]
Failures are either errors which occurred during transmission or loss of arbitration.
c) Effect on receipt
The effect of receipt of this primitive by the LLC sublayer is unspecified.
8.1 .I .4 MA-REMOTE.request
a) Function
The MA REMOTE.request primitive is passed from the LLC sublayer to the MAC sublayer to request a single
remote MAC entity to transmit an MSDU.
b) Semantics of the 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.1 .I .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 an MSDU.
IS0 11519=2:1994(E)
b) Semantics of the MA-REMOTE.indication primitive
The primitive shall provide parameters as follows.
MA-REMOTE.indication(
IDENTIFIER
DLC
The arrival of an MSDU transmission request is indicated to the LLC sublayer only if it has been received cor-
rectly.
c) Effect on receipt
The effect of receipt of this primitive by the LLC sublayer is unspecified.
8.1 .I .6 MA REMOTE.confirm
-
a) Function
The MA-REMOTE.confirm primitive is passed from the local MAC sublayer to the LLC sublayer to convey the
results of the previous MA REMOTErequest. 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).
b) Semantics of the MATREMOTEconfirm primitive
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 arbitration.
c) Effect on receipt
The effect of receipt of this primitive by the LLC sublayer is unspecified.
8.1 .I .7 MA-OVLD.request
a) Function
The MA OVLD.request primitive is passed from the LLC sublayer to the MAC sublayer to request the trans-
missionif a MAC overload frame (see 8.3.4). The overload frame is a fixed format frame and is completely
constructed in the MAC sublayer.
IS0 11519-2:1994(E)
b) Semantics of the MA-OVLD.request primitive
The primitive does not provide any parameter:
MA-OVLD.request(
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.1 .I .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 received (see 8.3.4).
Semantics of the MA OVLD.indication primitive
W -
The primitive does not provide any parameters:
MA-OVLD.indication(
)
Effect on receipt
The effect of receipt of this primitive by the LLC sublayer is unspecified.
8.1 .I .9 MA OVLDxonfirm
--
a) Function
The MA OVLD.confirm primitive is passed from the MAC sublayer to the LLC sublayer to indicate that an
overload-frame has been sent. This confirmation is local, i.e. it does not imply that the remote peer protocol
entities have received correctly the overload frame.
b) Semantics of the MA-OVLD.confirm primitive
The primitive shall provide parameters as follows.
MA-OVLD.confirm(
TRANSMISSION-STATUS
The TRANSMISSION-STATUS is used to indicate the success or failure of the previous MA OVLD.request
-
primitive.
c) Effect on receipt
The effect of receipt of this primitive by the LLC sublayer is unspecified.

IS0 11519=2:1994(E)
8.2 Functional model of the MAC sublayer architecture
The functional capabilities of the MAC sublayer are described by use of the functional model specified in
...