ISO 11519-3:1994

ISO
INTERNATIONAL
11519-3
STANDARD
First edition
1994-06-15
- Low-Speed serial data
Road vehicles
communication -
Part 3:
Vehicle area network (VAN)
- Communication en s&ie de donnees 3 basse
Whicules routjers
vitesse -
Partie 3: Mseau local de vehicule (VAN)
Reference number
ISO 11519=3:1994(E)
< Contents
Page
1 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2 Normative references . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
3 Definitions and abbreviations
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
3.1 Definitions
3.2 List of abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . .*.*. 4
4 Presentation of architecture
4.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .~.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.2 Reference to OSI model
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5 Description of LLC sublayer
5.1 LLC Service specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .~.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.2 Error management at LLC level
,. 10
5.3 Error recovery management at LLC level
6 Description of the MAC sublayer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .*.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .~. 10
6.1 Specification of MAC Service
6.2 Structure of MAC frames . . .*.
6.3 Specification of Medium Access Method (MAC) . . . . . . . . . . . . . . . . .
. . . . . . . .*. 48
7 Description of physical layer
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
7.1 Specification of physical Service
7.2 Encoding/decoding and synchronization sublayer . . . . . . . . . . . . . . . . 53
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
7.3 Line transmitter/receiver
7.4 Connector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
,,.,.,,.,. 79
7.5 Communication medium
8 Electrical Parameters *.*.,.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
8.1 At LLC sublayer level
8.2 At MAC sublayer level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
0 ISO 1994
All rights reserved. No part. of this publication may be reproduced or utilized in any form or
by any means, electronie or mechanical, inciuding photocopying and microfilm, without per-
mission in writing from the publisher.
International Organization for Standardization
Case Postale 56 l CH-l 211 Geneve 20 l Switzerland
Printed in Switzerland
ii
8.3 At physical layer level . .*. 80
9 Conformance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
9.1 Conformance at MAC layer level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
9.2 Conformance at physical layer level: Line transmitter/receiver
tests . . . . . . . . . . . . . . . . . . . . . .~.~. 84
Annexes
A Setup example for Baud Rate Multiplier .,,,,,,,,,. 89
B Setup example of realization of interface between physical layer and
data link layer . . . . . . . . . . . .I. 90
B.l Interface position/OSI model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
B.2 Definition of dialogue Signals between binar-y and electric
encodingldecoding sublayers .,,.*,.,.,. 90
B.3 Coding bit and Symbol (see 7.2.3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
B.4 Character synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
B.5 Signals exchange rules between PLI and PL2 sublayers . . . 96
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
B.6 Exceptions to this Signal exchange rules
B.7 Timing diagram for various dialogue Signals between PLI and PL2
. . . . . . . . . . . . .*. 96
sublayers
ISO 11519=3:1994(E)
Foreword
ISO (the International Organization for Standardization) is a worldwide
federation of national Standards bodies (ISO member bodies). The work
of preparing International Standards is normally carried out through ISO
technical committees. Esch member body interested in a subject for
which a technical committee has been established has the right to be
represented on that committee. International organizations, governmental
and non-governmental, in liaison with ISO, also take part in the work. ISO
collaborates closely with the International Electrotechnical Commission
(IEC) on all matters of electrotechnical standardization.
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 ISO 11519-3 was prepared by Technical Committee
lSO/TC 22, Road vehicles, Sub-Committee SC 3, Electrical and electronie
equipmen t.
ISO 11519 consists of the following Parts, under the general title Road
vehicles - Low-Speed serial da ta communica tion:
- Part 7: 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 (J7850)
Annexes A and B form an integral part of this part of ISO 11519.
iv
INTERNATIONAL STANDARD
ISO 11519=3:1994(E)
Road vehicles - Low-Speed serial data
communication -
Part 3:
Vehicle area network (VAN)
1 Scope
This part of ISO 11519 specifies the data link layer and the physical layer of the Vehicle Area Network (VAN),
communications network up to 125 kbit/s, for road vehicle application. The VAN is an access-method-oriented
multimaster-multislave which allows optimized request/response management by special method of handling a
remote transmission request (retaining access to the medium to allow insertion of a response).
This part of ISO 11519 defines the general architecture of the low-Speed communication network up 125 kbits/s
and the content of the data link layer, and the physical layer for transmission between different types of electronie
modules on board road vehicles.
2 Normative references
The following Standards contain provisions which, through reference in this text, constitute provisions of this patt
of ISO 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 ISO 11519 are encouraged to investigate the possibility of applying
the most recent editions of the Standards indicated below. Members of IEC and ISO maintain registers of currently
valid International Standards.
lSO/TR 8509: 1987, Information processing Systems - Open Systems In terconnection - Service conven tions.
ISO 8802-2:1989, Information processing Systems - Local area networks - Part 2: Logical link control.
3 Definitions and abbreviations
3.1 Definitions
For the purposes of this part of ISO 11519, the following definitions apply.
acknowledgement field (ACK): Field used by a module concerned to indicate correct interpretation of the
3.1.1
. frame by a receiver.
ISO 11519=3:1994(E)
3.1.2 autonomous module: Module which tan initiate data sending over the transmission medium.
3.1.3 bitwise arbitration: Arbitration technique which allows a priority message to take precedence on the bus
and dominate other messages of lower priority with which it collides. The collision is thus not destructive for the
highest-priority message. This bitwise arbitration technique is based on the use of dominant and recessive states
on the bus, with the dominant states taking precedence over the recessive bits.
In the event of a collision in the arbitration field (simultaneous sending of recessive and dominant bits), only those
modules sending a dominant bit will keep on transmitting, while the others will cease to transmit. This process is
repeated for each bit of the arbitration field.
Bus value The bus tan take 2 electrical states:
dominant (D) corresponds to a logic level “0” ,
recessive (R) corresponds to a logic level *‘l ” .
3.1.4 code Violation: Any error that converts a bit or other physical Symbol into an out-of-code Symbol.
3.1.5 collision; interference: Physical phenomenon that occurs when several Signals are superimposed on one
another, whether they are of internal origin (modules connected to the bus) or external origin (noise).
3.1.6 collision detection: Collision detected by a sending module when interference occurs on the bus and
modifies the Signal transmitted (more precisely, the Signal received is different from the Signal sent).
3.1.7 command field (COM): Field containing command information associated with the frame.
3.1.8 con tentio n: Situation that arises when several modules Start transmitting simultaneously on the com-
munica tion bus.
3J.9 data field (DAT): Part of the frame containing data. The field consists of a whole number of bytes.
3.1.10 data transmission: Process by which encoded data tan be sent over a transmission medium sequentially
in binar-y form.
3.l.11 end of data (EOD): Part of the frame indicating the end of data. The EOD is located just after the Frame
Check Sequence (FCS).
3.1.12 end of frame (EOF): Part of the frame indicating the end of a frame.
3.1.13 extensibility: Situation where modules tan be added to the network without having to Change the soft-
Ware or hardware of any module for an existing application, within the limits of the communication layers specified
in this document.
3.1.14 MAC frame: Sequence of fields containing either:
a statt of frame field;
an identifier field;
a command field;
a data field;
a frame check sequence field;
an end of data field;
an acknowledgement field;
an end of frame field.
or
a statt of frame field;
an identifier field;
a command field;
a frame check sequence field;
an end of data field;
an acknowledgement field;
an end of frame field.
Esch frame is separated by an interframe spacing field.
ISO 11519=3:1994(E)
3.1.15 frame check sequence (FCS): Part of the frame which Checks its integrity. In the present case, this
function is performed by means of a Cyclic Redundancy Check (CRC).
3.1.16 identifier field (IDEN): Part of the frame following the SOF, which identifies and specifies the data con-
veyed in the frame.
3.1.17 interframe spacing (IFS): Minimum time interval locally required between the sending of two consecu-
tive frames, which is controlled by the MAC sublayer.
3.1.18 module: Physical entity connected to the network, capable of receiving and/or sending data via the me-
dium.
3.1.19 remote transmission request: By sending a data request, a module that wishes a data unit tan request
another module to send it the corresponding data. The data unit tan be sent either immediately in the Same frame
or later in a separate frame identified by the same identifier.
3.1.20 Slave module: Module which tan
- receive data
- send data when requested, by means of an in-frame response mechanism.
3.1.21 Start of frame (SOF): Part of the frame which indicates the Start of the frame and synchronizes the re-
ceiving modules’ clocks.
3.1.22 synchronous access module: Module which tan initiate transmission only after a Start of Frame (SOF)
Character appears on the bus.
3.2 List of abbreviations
Acknowledge
ACK
ADT Acknowledged Data Transfer
BR Bit Rate
BT Bit Time
D Dominant State
DL Data Link
End Of Data
EOD
EOF End Of Frame
Frame Check Sequence
FCS
IFS Interframe Spacing
LLC Logical Link Control
LSB Least Significant Bit
LSDU Link Service Data Unit
ISO 1151993:1994(E)
MAC Medium Access Control
MDI Medium Dependent Interface
MSB Most Significant Bit
NADT Not Acknowledged Data Transfer
OSI Open Systems Interconnection
PL
Physical Layer
PLS Physical Signalling
PMA Physical Medium Attachment
Q/R Question/Response Frame
RD Recessive State
RAK Request Acknowledge
RT Remote Transmission
RTR Remote Transmission Request
SOF Start Of Frame
TS Time Slot
4 Presentation of architecture
4.1 General
The objectives of the VAN are to interconnect different types of electronie modules on board a vehicle and to
transmit messages having different priority levels.
The VAN is an asynchronous data transmission System which allows the transfer of packets of data.
The messages handled tan be typically:
- messages of 1 byte, to write or to read from a Slave peripheral module;
- messages from 0 to 28 bytes, to exchange Parameters and/or events between the different autonomous
modules;
- long messages segmented by the User.
The document allows the possibility of interconnecting heterogeneous modules including, among others, very
simple Slave modules.
The implications for the frame format and layer design are:
- the use of a special Start Of Frame field which tan correct the local clocks of the simple modules and establish
a common time base;
- the possibility of chaining the response of a module in the same request frame concerning it;
- the possibility of direct in-frame acknowledgement.

4.2 Reference to OSI model
The VAN architecture camplies with the ISO reference model for Open Systems Interconnection (OSI) with re-
spect to the breakdown by layers. This breakdown is shown in figure 1.
Beyond scope of document
Scope of document
Application Supervisor
Presentation
Session
Transport
Network
LLC Error management Unsuccessful
Data
attempt count
link
L
Errorrecovery Repeat attempt
management count
I I-4 I
MAC Acceptance fitter
I I
Frame test
I I
Data encapsulationl
decapsulation
Serializing
I I
Medium access
controC function
I
Line break
Physical Bit and Symbol
(bus Status)
encodingldecoding
synchronization
I l-2 i
Line interface
I
I
I l-l I
Figure 1 - Breakdown by layers in accordance with OSI model
ISO 11519=3:1994(E)
5 Description of LLC sublayer
The LLC (Logical Link Control) sublayer is the upper part of the data link layer ( ayer 2 of the ISO reference
model - see figure 1).
mode.
The objective is to provide a multipoint data transmission Service, in connectionless
of Service which tan be pro-
The architecture of the VAN, described in this part of ISO 11519, allows two types
vided by the LLC sublayer (in accordance with the International Standard on LAN architecture, ISO 8802-2):
- The class I LLC Service which offers a data transfer Service without acknowledgement: this provides a mini-
mum level of Service and requires the implementation of greatly reduced functionalities at the LLC layer pro-
tocol level;
- The class Ill LLC Service which offers, in addition to class I Services (Point-to-Point, multipoint or broadcast
data transfer), check Services on the Operation of the data link (acknowledgement, flow control, sequencing
and error recovery).
Generally speaking, the LLC sublayer provides the functionalities needed for Supervision of the data links and
should incorporate at its level recovery capabilities in the event of failure of a module.
The description of the Services of the LLC sublayer is given in 5.1. The precise definition of LLC procedure el-
ements required for implementation of these Services is not yet contained in this part of ISO 11519.
5.1 LLC Service specifications
5.1.1 Object
This subclause specifies the Services which are provided by the LLC sublayer to the LLC user in the framework
of the VAN architectural model defined in this part of ISO 11519 (see figure 1 for the description of the layers).
5.1.2 General presentation of LLC Services
The Services provided by the LLC sublayer are designed to allow exchange of packets between the loca
entity (LLC User) and peer entities (LLC users) which are connected to the communication bus.
In Order to provide these Services, the LLC sublayer builds its functions on the Services provided by the next
sublayer (MAC Services: see 6.1).
There are three types of Services provided by the LLC sublayer. All these Services are connectionless oriente
they do not need the establishment and maintenance of a connection, see ISO 8802-2).
Unacknowledged data transfer Service
5.1.2.1
The unacknowledged data transfer Service provides the means by which a transfer entity tan send Link Service
Data Units (LSDU) to transfer entities.
This Service tan be used for Point-to-Point, multipoint or broadcast exchanges with maximum efficiency.
5.1.2.2 Acknowledged data transfer Service
The acknowledged data unit exchange Service provides the means by which a transfer entity tan exchange Link
Service Data Units (LSDU) to another transfer entity with the guarantee that the LSDU has been transmitted cor-
rectly.
This Service tan be based either on an LLC-level acknowledgement mechanism LLC Type 3 when a high level of
reliability is required or on the acknowledge capability provided by the MAC sublayer (see 6.3.2.1 .l).
This patt of ISO 11519 does not specify the functions of the LLC sublayer necessary to provide acknowledged data
unit exchanges (LLC type 3).
The acknowledged data transfer Service is to be used for Point-to-Point exchanges only.
ISO 11519=3:1994(E)
5.1.2.3 Remote data transmission Service
The remote data transmission Service provides the means by which a transfer entity at one module tan request
(consume) a data unit (LSDU) that is located (produced) at some other remote module.
This Service tan be used for Point-to-Point, multipoint or broadcast exchanges, with respect to the transferred data
units (LSDU).
This Service is divided in two subservices:
- the response preparation Service,
- the reply Service.
5.1.3 Description of LLC Service interactions
5.1.3.1 Service specification method and notation
This subclause describes the Service aspects of the LLC sublayer (corresponding to the various functionalities of
the LLC sublayer provided for users located in the upper layer).
This is an abstract representation (or model) of an interface between the LLC sublayer and an LLC Service User,
independent of any specific implementation.
The LLC Service definition proposed hereafter camplies with the ISO reference model: in particular, it uses the
associated Service notations in lSO/TR 8509.
The Service primitives used are of three types: request, indication, tonfirm. Their meaning is summarized below:
Request The request primitive is sent by a (N)-user to the (N)-layer or (N)-sublayer to request initiation of
a Service.
Indication The indication primitive is sent by the (N)-layer or (N)-sublayer to a user of the (N)-Service to in-
dicate that an event internal to the (N)-(sub-)layer has occurred and that the event in question is
significant for the (N)-User. An indication tan be triggered by a Service request executed pre-
viously or by an internal event in the (N)-(sub-flayer.
Confirm The tonfirm primitive is sent by (N)-layer to a (N)-user to retrieve the results associated with the
previous Service request.
The links (logical and temporal) between indication and tonfirm are diverse, depending basically on the character-
istics of each Service.
LLC ser vice user LLC Service provider LLC Serviceuser
Reques t-
- Indication
tonfirm V
- Schematic diagram of interactions between adjacent layers
Figure 2
5.1.3.2 Description of Service interactions
Table 1 gives a list of the Service primitives characterizing each of the LLC Service elements described in this patt
of ISO 11519. Subclause 5.1.3.3 gives a detailed description of each of these Service primitives.

Table Table 1 1 - - List List of of LLC LLC Service Service primitives primitives
Unacknowledged Unacknowledged data data transfer transfer
data transfer.
DL-DATA.request Request for unacknowledged
DL-DATA.indication Indication of unacknowledged data transfer.
Confirm of unacknowledged data transfer.
DL-DATA.confirm
Acknowledged Acknowledged data data transfer transfer
Request Request for for acknowledged acknowledged data data transfer. transfer.
DL-ACK-DATA.request DL-ACK-DATA.request
Indication Indication of of acknowledged acknowledged data data transfer. transfer.
DL-ACK-DATA.indication DL-ACK-DATA.indication
Confirm Confirm of of acknowledged acknowledged data data transfer. transfer.
DL-ACK-DATA.confirm DL-ACK-DATA.confirm
Remote Remote transmission transmission Service Service with with acknowledgement acknowledgement
Reply Reply Service Service
Request Request for for remote remote transmission. transmission.
DL-REPLY.request DL-REPLY.request
Indication Indication of of remote remote transmission. transmission.
DL-REPLY.indication DL-REPLY.indication
Confirm of remote transmission.
DL-REPLY.confirm
Service
Response preparation
response preparation.
DL-REPLY-UPDATE.request Request for
Confirm of response preparation.
DL-REPLY-UPDATE.confirm
Remote Remote transmission transmission Service Service without without acknowledgement acknowledgement
Reply Reply Service Service
Request Request for for remote remote transmission. transmission.
DL-REPLY.request DL-REPLY.request
I
I
Indication Indication of of remote remote transmission. transmission.
DL-REPLY.indication DL-REPLY.indication
I
I
DL-REPLY.confirm DL-REPLY.confirm Confirm Confirm of of remote remote transmission. transmission.
Response Response preparation preparation Service Service
Request Request for for response response preparation. preparation.
DL-REPLY-UPDATE.request DL-REPLY-UPDATE.request
Confirm Confirm of of response response preparation. preparation.
DL-REPLY-UPDATE.confirm DL-REPLY-UPDATE.confirm

5.1.3.3 Definition of LLC Service primitives
This subclause gives the definition of LLC Service primitives such as presented in 5.1.3.2 with their associated
Parameters.
The following Parameters are used to formalize the kind of interactions which appear at the transfer/LLC Service
interface:
The IDEN Parameter is used to identify the data which are exchanged using this interaction (sent, received or
requested in a remote transmission);
The DATA Parameter represents the user data transferred (LSDU) using this primitive;
The SERVICE CLASS specifies whether or not the LLC sublayer uses the acknowledge capability in the medium
access control sublayer for the data unit transmission;
The NREP-DL indicates the maximum number of retransmissions that the data link layer may achieve (using
the recovery capabilities of both LLC and MAC sublayers) to provide the complete execution of the corre-
sponding request;
The NREP-ACK Parameter indicates the maximum number of retransmissions that the data link layer may
achieve by lack of acknowledgement of the receiving entity;
The STATUS Parameter specifies whether the corresponding request was executed with success or not. In the
latter case, it indicates the type of failure.
Table 2 gives the list of Parameters associated to the primitives for each LLC Service.
Table 2 - Parameters
LLC Services List of Parameters Type of interaction
R I C
E N 0
Q D N
F
IDEN X X X
X X
DATA
Unacknowledged data transfer
NREP-DL X
X
STATUS
X
IDEN X X
X
DATA X
SERVICE-CLASS X X X
Acknowledged data transfer
NREP-DL X
NREP-ACK X
X
STATUS
X X X
IDEN
X
DATA
X
SERVICE-CLASS X X
RePlY
NREP-DL X
STATUS X
IDEN X X
Response preparation DATA X
STATUS X
ISO 11519=3:1994(E)
5.2 Error management at LLC level
Transmission errors are indicated by the MAC sublayer to the LLC sublayer.
Error recovery procedures are managed by the LLC sublayer.
Recovery management after loss of arbitration by the LLC sublayer is optional. Repetitions of this type are not
accounted for (see 5.3). They tan be indicated to the network administration.
52.1 Errors in transmit mode
When transmit mode errors are indicated by the MAC sublayer, the LLC sublayer tan repeat the transmission re-
quest following a time delay.
5.2.2 Errors in receive mode
In receive mode, errors indicated to the LLC sublayer by the MAC sublayer correspond:
- either to an error indicated by the physical layer to the MAC sublayer (Code Violation, synchronization, etc.);
.
- or to an invalid frame detected by the MAC sublayer.
If an error is detected in receive mode, the MAC sublayer notifies the LLC sublayer of the type of error (see
6.3.5).
5.3 Error recovery management at LLC level
After a loss of arbitration, an LLC Ievel recovery tan occur in the following conditions:
- another frame send attempt is made without further delay, after sending the frame which caused the collision;
- There is no Iimit to the number of repeat attempts at the LLC sublayer level;
a specific request by a user of the LLC sublayer tan interrupt further send attempts.
A send attempt tan only be repeated after sending the EOF Character and waiting for the interframe spacing (IFS).
6 Description of the MAC sublayer
This clause describes the functions, main characteristics (and subsequently the protoco ) of the MAC (Medium
Access Control) sublayer of the VAN.
The MAC sublayer is the lower part of the data link layer of the ISO reference model (see figure 1). lt contains the
medium access facilities used for sharing a data communication bus between two or mc re interconnected mod-
ules in the vehicle, and the other functionalities required for the implementation of a data link layer (data serializing
and deserializing, interface with the physical layer).
This part of ISO 11519 includes an access method specification (general principles) and the corresponding par-
ameter values for implementation on a medium such as that considered in this document (differential pair for bit
rates ranging from 10 kbits/s to 125 kbits/s). For the latest technical developments, the Iimit of the data transfer
is 250 kbit/s.
6.1 Specification of MAC Service
6.1.1 Object
Subclause 6.1 specifies the Services provided by the MAC sublayer to the LLC sublayer within the VAN architec-
ture defined in this document (see figure 1 for the breakdown by layers).
ISO 11519=3:1994(E)
lt includes a general description of MAC Services (6.1.2) and, for each type of module that is defined, it specifies
the list of available Services (table3).
Tabie 3 - I IIAC Services
Types of modules
Service categories Role
Autonomous Slave
P(=l) Yes No
Unacknowledged data transfer
C Yes Yes
P(=l) Yes Yes
Acknowledged data transfer
C Yes Yes
Yes No
P Yes
Remote transmission with immediate response Yes
C Yes Yes
Yes No
Remote transmission with deferred response P Yes No
I
C Yes No
Subclause 6.1.3 gives a detailed specification of Service primitives: they represent a conceptual description of
interactions between the MAC sublayer and a MAC-Service user which are necessary for the execution of these
Services.
6.1.2 General description of MAC Service
The Services provided by the MAC sublayer are designed to allow data exchange between the local user entity
(LLC sublayer) and peer entities (LLC sublayers) connected to the communication bus.
The MAC Services proposed in this part of ISO 11519 are of four types:
- Unacknowledged data transfer Service: This enables the Iocal entity to exchange data over a data link with-
out cal1 connection or acknowledgement of the receiving LLC entities. This simple data transfer is point-to-
Point, or multipoint, or broadcast-oriented.
- Acknowledged data transfer Service: This enables the local LLC entity to transfer data to another LLC entity
with a request for acknowledgement by the receiving LLC entity. This data transfer mode is Point-to-Point
oriented in connectionless mode.
- Remote transmission with immediate response Service: This Service authorizes the local LLC entity to re-
quest the transfer of data produced by another LLC entity at some remote module.
Icer module: they
The polled data must be previously prepared and stored at the MAC sublayer level at the prodL
are sent immediately in the request frame (immediate response: see 6.2.1).
ISO 11519=3:1994(E)
This Service tan be used for Point-to-Point, multipoint or broadcast exchanges, with respect to transferred data
(MSDU): the t ransferred data are received by one or more LLC entities, including the entity which initiated the
servrce.
Using the Service, the MAC acknowledge capability may be used: in case of success (immediate response);
acknowledgement is given by the MAC entity which initiated the remote transfer (the transferred data are
considered valid for a receiving MAC entity only in case of a positive acknowledgement: see 6.2.6).
This Service is s ubdivided into two s ubservices:
the response preparation Service for locally updating the data buffer,
the reply Service for remote access to data.
- Remote transmission with deferred response Service: This Service authorizes the local LLC entity to request
the transfer of data produced by another LLC entity at some remote module: the polled data are sent in a de-
ferred mode, using a separate frame identified by the same identifier.
various func-
MAC Services and module types allow interconnection of heterogeneous modules corresponding to
tional requirements.
This part of ISO 11519 introduces two types of module which are taken into account in specification of VAN layers
1 and 2 (autonomous module and Slave module). This subclause specifies the characteristic functional require-
ments (profiles) for each type of module.
Table3 specifies the MAC Services that may be available depending on the type of the module (autonomous or
Slave). lt states for each category of Service which role the module tan take depending on its type. The list of roles
is the following:
Producer (P) A module is said to be a Producer while executing a Service if it held the functionality of
sending user data (the LLC entity is a data Source).
P(=l) means initiator is also Producer.
Consumer (C) A module is said to be a consumer when it held the functionality to receive user data (the LLC
entity is a data sink).
A module is said to be an initiator if it has the capability to initiate the execution of the
Initiator (1)
Service.
6.1.3 Detailed description of MAC Service
6.1.3.1 Service specification method and notation
This subclause describes the Service aspects of the MAC sublayer (corresponding to the various functionalities
of the MAC sublayer provided for users located in the upper layer).
This is an abstract representation (or model) of an interface between the MAC sublayer and a MAC Service User,
independent of any specific implementation.
The MAC Service definition proposed hereafter camplies with the ISO reference model: in particular, it uses the
associated Service notations in ISO/TR 8509.
The Service primitives used are classified into three types: request, indication, tonfirm. Their meanings are sum-
marized below:
Request The request primitive is sent by an (N)-user to the (NI-layer or (N)-sublayer to request initiation
of a Service.
Indication The indication primitive is sent by the (N)-layer or (NI-sublayer to a user of the (N)-Service to
indicate that an event internal to the (N)-(sub-)layer has occurred and that the event in question
is significant for the (N)-User. An indication tan be triggered by a Service request executed
previously or by an internal event in the (N)-(sub-)layer.
Confirm The tonfirm primitive is sent by (N)-layer to an (N)-user to retrieve the results associated with
the previous Service request.
ISO 11519=3:1994(E)
The links (logical and temporal) between indication and tonfirm are diverse, depending basically on the character-
istics of each Service (see 6.1.3.3).
MAC Serviceuser
MACser vice user MAC serviceprovider
Request
V Indication
Confirm V
Schematic diagram of interactions between adjacent layers
Figure 3 -
6.1.3.2 Description of Service interactions
Table4 gives a list of the Service primitives characterizing each of the MAC Service elements described in this patt
of ISO 11519. Subclause 6.1.3.3 gives a detailed description of each of these Service primitives.
6.1.3.3 Detailed specification of MAC Services
This subclause describes in detail the primitives and their associated Parameters corresponding to the various MAC
Services described in 6.1.3.2.
The IDEN Parameter is used to identify the data which are exchanged using this interaction (sent, received or re-
quested in a remote transmission).
The EXT Parameter is a 1 -bit field reserved for subsequent applications. In this part of ISO 11519 the Parameters
value is set at 1 (recessive bit). The DATA Parameter specifies the user data (data unit of the MAC Service) to be
transferred by the MAC entity.
lt is assumed that there is sufficient information in this Parameter for the MAC entity to be able to determine the
data length (possibly nil).
The transmission-Status, reception-Status and transfer-status Parameters specify the level of success in transmit-
ting the corresponding data.
Primitives associated with unacknowledged data transfer Service (NDT)
6.1.3.3.1
6.1.3.3.1 .l MA-DATA.request
a) Function
This primitive tan initiate unacknowledged data transfer between the local LLC entity and one or more receiving
LLC entities.
ISO 11519=3:1994(E)
Table 4 - List of MAC Service primitives
Unacknowledged data transfer
MA-DATA.request Request for unacknowledged data transfer.
Indication of unacknowledged data transfer.
MA-DATA.indication
Confirm of unacknowledged data transfer.
MA-DATA.confirm
Acknowledged data transfer
Request for acknowledged data transfer.
MA-ACK-DATA.request
Indication of acknowledged data transfer.
MA-ACK-DATA.indication
MA-ACK-DATA.confirm Confirm of acknowledged data transfer.
Remote transmission Service with acknowledgement
Reply Service
Request for remote transmission.
MA-REPLY.request
Indication of remote transmission.
MA-Reply.indication
MA-REPLY.confirm Confirm of remote transmission.
Response preparation Service
MA-REPLY-UPDATE.request Request for response preparation.
MA-REPLY-UPDATE.confirm Confirm of response preparation.
Remote transmission Service without acknowledgement
Reply Service
Request for remote transmission.
MA-REPLY.request
MA-REPLY.indication Indication of remote transmission.
MA-REPLY.confirm Confirm of remote transmission.
Response preparation Service
I
MA-REPLY-UPDATE.request Request for response preparation.
MA-REPLY-UPDATE.confirm Confirm of response preparation.
ISO 11519=3:1994(E)
Parameters associated with MA-DATA request primitive
This primitive contains the following Parameters:
- MA-DATA.request (IDEN, EXT, DATA).
The IDEN field tan identify the modules concerned by the transferred data (DATA). The EXT Parameter is an
extension field which may be used by the LLC sublayer (an extension bit conveyed in the data frame: see
6.2.3.3).
The DATA Parameter must contain sufficient information to indicate to the MAC sublayer the length of the data
to be transferred.
Figure4 gives examples of possible exchanges for the primitives associated with the unacknowledged data
transfer Service.
Operations associated with this primitive
This primitive is sent by a LLC entity to the MAC sublayer whenever it needs to transfer data in NADT mode
(unacknowledged) to one or more remote LLC entities.
Upon receiving this primitive, the MAC sublayer prepares a data frame by adding the frame-specific fields
(identifier, command field including the extension bit and RAK bit indicating that acknowledgement is not re-
auested, see 6.2).
Sending module Receiving modules
A A
. . c .
MA-DATA.ind
MA-DATA.req V-
-\
\
\
\ MA-DATA.ind
I
:
/
/
MA-DATA.conf e
LLC MAC
Casea:SuccessfuLtransfer - severalreceivers
Sending module Otherinterconnected modules
MA-DATA.req B
MA-DATA.conf e s
LLC MAC MAC LLC
Case b:Datatransfer aborted (errordetectedintransmitmode)
Figure 4 - Example of primitive exchanges in NDT Service
ISO 11519=3:1994(E)
6.1.3.3.1.2 MA-DATA.indication
) Function
This primitive allows the MAC sublayer to indicate an unacknowledged data transfer to an entity of the LLC
sublayer.
) Parameters associated with MA-DATA.indication primitive
This primitive contains the Parameters:
- MA-DATA.indication (IDEN, EXT, DATA, RECEPTION-STATUS).
The IDEN and EXT Parameters are the Same as those provided in the corresponding request, while the DATA
field specifies the data received by the MAC sublayer.
lt indicates the a rrival of a val id or invalid frame. N oti fication of i nvalid re ce ived frame to the LLC sublayer is left
to the implernen ter’s choice: in case of nvalidity, th e DATA pa rameter is not provided.
c) Operations associated with this primitive
The MA-DATA.indication primitive is sent by the MAC sublayer to an LLC entity to indicate the arrival of a data
frame without request for acknowledgement. A frame of this type must be indicated in this way when the
received frame is valid (correct format, reception without error, see 6.2.6) and when the identifier (IDEN) des-
ignates the local MAC entity.
If the MAC entity initiating the request (MA-DATA.request) is itself designated by the IDEN field, the
MA-DATA.indication primitive must be called by the MAC entity to the local LLC entity (e.g., all frames sent
with a reserved broadcast address Cause the MA-DATA.indication primitive to be called up on all modules
connected to the medium).
d) Additional comments
The Codes which tan be conveyed by the reception-Status Parameter are as follows:
- RECEPTION-OK: indicates the arrival of a valid frame,
- RECEPTION-ERROR: tan be used to indicate the arrival of an invalid frame.
6.1.3.3.1.3 MA-DATA,confirm
a) Function
This primitive has a local meaning. lt provides the LLC sublayer with an execution report on the MA-DATA,
request primitive by indicating, in particular, the success or failure of transmission (e.g., error detected in
transmit mode).
b) Parameters associated with MA-DATA.confirm primitive
This primitive contains the Parameters:
- MA-DATA.confirm (IDEN, EXT, TRANSMISSION-STATUS).
The TRANSMISSION-STATUS Parameter is used to pass Status information to the local LLC entity which re-
quested data transfer.
lt indicates the success or failure of the corresponding MA-DATA.request.
The list of possible values for the TRANSMISSION-STATUS Parameter is given in d) below.
c) Operations associated with this primitive
This primitive is generated in response to an MA-DATArequest primitive initiated by the local LLC entity. The
LLC entity is responsible for placing the MA-DATA.confirm Parameter in relation with the corresponding re-
ISO 11519=3:1994(E)
quest. The contents of the data whose transfer was requested by this MA-DATArequest primitive must be
preserved by the local LLC entity (at least) until this tonfirm is returned.
d) Additional comments
At the LLC sublayer, sufficient information must be available to associate the tonfirm with the appropriate re-
quest (e.g., the MAC sublayer tan process only one request at a time or tan process requests on a first-in
first-out basis: the association is deduced from the Order of response).
The list of possible values for the TRANSMISSION-STATUS Parameter is as follows:
- TRANSMISSION-COMPLETED: Indicates that the data frame has been sent validly (see 6.2.6);
- LOSS-OF-ARBITRATION? If the MAC entity does not recover in the event of contention, it thereby indicates
to the LLC entity that the medium cannot be accessed due to a collision with a message of higher priority;
- TRANSMISSION-ERROR? This concerns only errors detected in transmit mode: e.g., BIT-ERROR,
FORMAT-ERROR or ACK-ERROR (see 6.3.4).
Sending module Receiving module
A A
. . fl .
----
----
----
----
--
----
c-- - MA-ACK-DATA.ind
-e--
4-
C-
--
----
--
-- 4-
LLC MAC MAC LLC
Casea:SuccessfuLacknowLedgeddatatransfer
Sending module Other modu!e
A A
/ . *
MA-ACK-DATA.req
MA-ACK-DATA.confe
LLC MAC MAC LLC
Case b:UnsuccessfuL acknowledged data transfer request
Figure 5 -
Example of exchanges of acknowledged data transfer Service primitives
1) Recovery on loss of arbitration by the MAC sublayer is optional.
2) In the case of locally detected transmission errors:
CODE-ERROR (Code Violation),
ACK-ERROR if the acknowledgement field has the value POSITIVE-ACK.
Figure 5 gives examples of exchanges of primitives associated with the acknowledged data transfer Service.
ISO 11519=3:1994(E)
6.1.3.3.2 Primitives associated with acknowledged data transfer Service (ADT)
6.1.3.3.2.1 MA-ACK-DATA.request
a) Function
This primitive allows Point to Point data transfer with acknowledgement by the remote module receiving the
data.
b) Parameters associated with MA-ACK-DATA.request primitive
The list of Parameters associated with this primitive is as follows:
- MA-ACK-DATA.request (IDEN, EXT, DATA).
The IDEN field tan identify the module concerned by the transferred data (DATA). The EXT Parameter is an
extension field reserved for possible use by the LLC sublayer (one extension bit conveyed in the data frame:
see 6.2.2).
The DATA Parameter must contain sufficient information to indicate to the MAC sublayer the length of the data
to be transferred.
c) Operations associated with MA-ACK-DATA.request primitive
This primitive is sent by an LLC entity to the MAC sublayer to activate data transfer in acknowledgement mode
to a remote receiving module.
Upon receiving this primitive, the MAC sublayer attempts to send a data frame with explicit acknowledgement
request, using the acknowledged data transmission procedures.
6.1.3.3.2.2 MA-ACK-DATA.indication
a) Function
This primitive allows the MAC sublayer to indicate acknowledged data transfer to an entity of the LLC sublayer.
b) Parameters associated with MA-A
...