ISO 11519-2:1994
(Main)Road vehicles — Low-speed serial data communication — Part 2: Low-speed controller area network (CAN)
Road vehicles — Low-speed serial data communication — Part 2: Low-speed controller area network (CAN)
Specifies the data link layer and the physical layer of the CAN, a communications network up to 125 kbit/s, for road vehicle application. The low-speed CAN is a serial communication protocol supporting distributed real-time control and multiplexing. Defines the general architecture of the network in terms of the hierarchical layers defined in the ISO-OSI model according to ISO 7498.
Véhicules routiers — Communication en série de données à basse vitesse — Partie 2: Réseau local à commande à basse vitesse (CAN)
General Information
Relations
Standards Content (Sample)
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)
---------------------- Page: 1 ----------------------
IS0 11519=2:1994(E)
Contents
Page
1
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1 Scope
........................................................ 1
2 Normative references . . . . . . . . . . . . .
2
3 Definitions and abbreviations .
2
3.1 Data link layer definitions .
........................................................ 2
3.2 Physical layer definitions
3
3.3 List of abbreviations .
4
4 Basic concepts of CAN .
4
....................................................................................
41 . Frames
4
42 . Bus access method .
5
Information routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43 .
5
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
44 . System flexibility
5
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
45 . Data consistency
5
46 . Remote data request .
5
47 . Error detection .
5
. Error signalling and recovery time .
40
5
49 . Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
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
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5 Layered architecture of CAN
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1 Reference to the OSI model
8
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2 Protocol specification
8
. . . . . . . . . . . . . . . . .*.
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
---------------------- Page: 2 ----------------------
IS0 11519=2:1994(E)
9
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
13
.......................................................
6.3 Structure of LLC frames
............................................. : 15
Functions of the LLC sublayer
6.4
15
...........................................
7 Interface between LLC and MAC
16
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8 Description of the MAC sublayer
16
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.1 Services of the MAC sublayer
. . . . . . . . . . . 21
8.2 Functional model of the MAC sublayer architecture
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
8.3 Structure of MAC frames
26
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .*.
8.4 Frame coding
. . . . . . . . . . . . . . . . . .s.~. 27
8.5 Order of the bit transmission
27
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.6 Frame validation
I
27
. . . . . . . . . . . . .~.
8.7 Medium access method
28
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.8 Error detection
29
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.9 Error signalling
:.
29
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.10 Overload signalling
II
30
. . . . . . . . . . * . . . . . . . . . . . . . . . . . . . . . . . . . . .
9 LLC and MAC sublayer conformance
30
. . . . . . . . . . . - . .~. -’ ’
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
34
10.5 Description of the low-speed medium access unit (LS-MAU)
45
. . . . . . . .*.
11 Description of the supervisor
45
Fault confinement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11 .l
51
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11.2 Bus failure management
. . .
III
---------------------- Page: 3 ----------------------
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)
---------------------- Page: 4 ----------------------
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.
1
---------------------- Page: 5 ----------------------
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).
---------------------- Page: 6 ----------------------
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
---------------------- Page: 7 ----------------------
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.
4
---------------------- Page: 8 ----------------------
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.
---------------------- Page: 9 ----------------------
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).
6
---------------------- Page: 10 ----------------------
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
---------------------- Page: 11 ----------------------
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 _
7
LLC frame
piq-
MSDU
9
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,.]
.
1
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.
---------------------- Page: 12 ----------------------
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.
9
---------------------- Page: 13 ----------------------
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
10
---------------------- Page: 14 ----------------------
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
\
4
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
1
The parameter DATA is insignificant if the associated LLC data frame is of data length zero.
11
---------------------- Page: 15 ----------------------
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
th
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.