ISO 11898:1993
(Main)Road vehicles — Interchange of digital information — Controller area network (CAN) for high-speed communication
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
Relations
Standards Content (Sample)
IS0
INTERNATIONAL
11898
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)
---------------------- Page: 1 ----------------------
IS0 11898:1993(E)
Contents
Page
1
1 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .~.~.
1
2 Normative references . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .~.
2
abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3 Definitions and
2
. . . . . . . . . . . . . . . . . . . . . . . . . . . .*.
3.1 Data link layer definitions
3
. . . . . . . . . . .*.
3.2 Physical layer definitions
4
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .~.
3.3 List of abbreviations
4
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4 Basic concepts of CAN
5
4.1 Frames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2 Bus access method
5
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3 Information routing
5
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.4 System flexibility
5
..,...............................,..............,..................
4.5 Data consistency
5
,.,.,.,.
4.6 Remote data request
5
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.7 Error detection
6
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.8 Error signalling and recovery time
6
..,,.,...,,,.....................,,,.,............................
4.9 Acknowledgement
6
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.10 Automatic retransmission
6
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.11 Fault confinement
6
4.12 ” error-active ” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.13 “error-passive”
6
,,.*.,.,,.,.,.
4.14 “bus off”
6
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Layered architecture of CAN
5
6
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.1 Reference to OSI model
8
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2 Protocol specification
8
. . . . . . . . . . . . .*.
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
---------------------- Page: 2 ----------------------
.......................................................................... 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
16
8.1 MAC sublayer .
16
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
27
8.6 Order of bit transmission .
27
8.7 Frame validation .
28
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
9
................................................. 30
10 Description of physical layer
..................................... 30
10.1 Functional model of physical layer
................................................... 31
10.2 Services of physical layer
31
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
56
11.2 Bus failure management .
---------------------- Page: 3 ----------------------
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.
---------------------- Page: 4 ----------------------
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.
---------------------- Page: 5 ----------------------
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.
---------------------- Page: 6 ----------------------
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------------------------------------------------------
1
f
i
I
I
ECU
I
I
f
RI"
I
r----w
1
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
1
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
3
---------------------- Page: 7 ----------------------
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;
4
---------------------- Page: 8 ----------------------
- 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.
5
---------------------- Page: 9 ----------------------
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.
---------------------- Page: 10 ----------------------
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
7
---------------------- Page: 11 ----------------------
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
0
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,.]
1
“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.
---------------------- Page: 12 ----------------------
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.
---------------------- Page: 13 ----------------------
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
10
---------------------- Page: 14 ----------------------
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 s
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.