IEC 61158-3-8:2007

IEC 61158-3-8 ®
Edition 1.0 2007-12
INTERNATIONAL
STANDARD
NORME
INTERNATIONALE
Industrial communication networks – Fieldbus specifications –
Part 3-8: Data-link layer service definition – Type 8 elements

Réseaux de communication industriels – Spécifications des bus de terrain –
Partie 3-8: Définition du service de la couche de liaison de données –
Éléments de Type 8
All rights reserved. Unless otherwise specified, 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 permission in writing from
either IEC or IEC's member National Committee in the country of the requester.
If you have any questions about IEC copyright or have an enquiry about obtaining additional rights to this publication,
please contact the address below or your local IEC member National Committee for further information.

Droits de reproduction réservés. Sauf indication contraire, aucune partie de cette publication ne peut être reproduite ni
utilisée sous quelque forme que ce soit et par aucun procédé, électronique ou mécanique, y compris la photocopie et les
microfilms, sans l'accord écrit de la CEI ou du Comité national de la CEI du pays du demandeur.
Si vous avez des questions sur le copyright de la CEI ou si vous désirez obtenir des droits supplémentaires sur cette
publication, utilisez les coordonnées ci-après ou contactez le Comité national de la CEI de votre pays de résidence.

IEC Central Office Tel.: +41 22 919 02 11
3, rue de Varembé Fax: +41 22 919 03 00
CH-1211 Geneva 20 info@iec.ch
Switzerland www.iec.ch
About the IEC
The International Electrotechnical Commission (IEC) is the leading global organization that prepares and publishes
International Standards for all electrical, electronic and related technologies.

About IEC publications
The technical content of IEC publications is kept under constant review by the IEC. Please make sure that you have the
latest edition, a corrigenda or an amendment might have been published.

Useful links:
IEC publications search - www.iec.ch/searchpub Electropedia - www.electropedia.org
The advanced search enables you to find IEC publications The world's leading online dictionary of electronic and
by a variety of criteria (reference number, text, technical electrical terms containing more than 30 000 terms and
committee,…). definitions in English and French, with equivalent terms in
It also gives information on projects, replaced and additional languages. Also known as the International
withdrawn publications. Electrotechnical Vocabulary (IEV) on-line.

IEC Just Published - webstore.iec.ch/justpublished Customer Service Centre - webstore.iec.ch/csc
Stay up to date on all new IEC publications. Just Published If you wish to give us your feedback on this publication
details all new publications released. Available on-line and or need further assistance, please contact the
also once a month by email. Customer Service Centre: csc@iec.ch.

A propos de la CEI
La Commission Electrotechnique Internationale (CEI) est la première organisation mondiale qui élabore et publie des
Normes internationales pour tout ce qui a trait à l'électricité, à l'électronique et aux technologies apparentées.

A propos des publications CEI
Le contenu technique des publications de la CEI est constamment revu. Veuillez vous assurer que vous possédez
l’édition la plus récente, un corrigendum ou amendement peut avoir été publié.

Liens utiles:
Recherche de publications CEI - www.iec.ch/searchpub Electropedia - www.electropedia.org
La recherche avancée vous permet de trouver des Le premier dictionnaire en ligne au monde de termes
publications CEI en utilisant différents critères (numéro de électroniques et électriques. Il contient plus de 30 000
référence, texte, comité d’études,…). termes et définitions en anglais et en français, ainsi que
Elle donne aussi des informations sur les projets et les les termes équivalents dans les langues additionnelles.
publications remplacées ou retirées. Egalement appelé Vocabulaire Electrotechnique
International (VEI) en ligne.
Just Published CEI - webstore.iec.ch/justpublished
Service Clients - webstore.iec.ch/csc
Restez informé sur les nouvelles publications de la CEI.
Just Published détaille les nouvelles publications parues. Si vous désirez nous donner des commentaires sur
Disponible en ligne et aussi une fois par mois par email. cette publication ou si vous avez des questions
contactez-nous: csc@iec.ch.
IEC 61158-3-8 ®
Edition 1.0 2007-12
INTERNATIONAL
STANDARD
NORME
INTERNATIONALE
Industrial communication networks – Fieldbus specifications –

Part 3-8: Data-link layer service definition – Type 8 elements

Réseaux de communication industriels – Spécifications des bus de terrain –

Partie 3-8: Définition du service de la couche de liaison de données –

Éléments de Type 8
INTERNATIONAL
ELECTROTECHNICAL
COMMISSION
COMMISSION
ELECTROTECHNIQUE
PRICE CODE
INTERNATIONALE
CODE PRIX V
ICS 25.040.40; 35.100.20 ISBN 978-2-8322-0989-9

– 2 – 61158-3-8 © IEC:2007
CONTENTS
FOREWORD . 4
INTRODUCTION . 6
1 Scope . 7
1.1 Overview . 7
1.2 Specifications . 7
1.3 Conformance . 7
2 Normative references. 8
3 Terms, definitions, symbols, abbreviations and conventions . 8
3.1 Reference model terms and definitions . 8
3.2 Service convention terms and definitions . 9
3.3 Common data-link service terms and definitions . 9
3.4 Additional Type 8 data-link specific definitions. 11
3.5 Common symbols and abbreviations . 12
3.6 Common conventions . 12
4 Data-link service and concepts . 13
4.1 Overview . 13
4.2 Sequence of primitives . 15
4.3 Connection-mode data-link services . 18
5 DL-management service . 22
5.1 Scope . 22
5.2 Facilities of the DL-management service . 22
5.3 Overview of services . 22
5.4 Overview of interactions . 23
5.5 Detailed specification of services and interactions . 26
Bibliography . 32

Figure 1 – Relationships of DLSAPs, DLSAP-addresses and group DL-addresses . 10
Figure 2 – Relationships of DLCEPs and DLCEP-addresses to default DLSAP . 14
Figure 3 – Sequence of primitives for the buffer data transfer . 17
Figure 4 – Normal data transfer service between a master and a slave . 18
Figure 5 – Sequence of primitives for a failed normal data transfer . 18
Figure 6 – Sequence of primitives for the reset service . 24
Figure 7 – Sequence of primitives for the event service . 24
Figure 8 – Sequence of primitives for the set value service . 25
Figure 9 – Sequence of primitives for the get value service . 25
Figure 10 – Sequence of primitives for the get current configuration service . 25
Figure 11 – Sequence of primitives for the get active configuration service . 25
Figure 12 – Sequence of primitives for the set active configuration service . 26

Table 1 – Summary of DL-connection-mode primitives and parameters . 16
Table 2 – Put buffer primitive and parameters . 19
Table 3 – Get buffer primitive and parameters . 19
Table 4 – Buffer received primitive and parameters . 20
Table 5 – Normal data transfer primitive and parameters . 21

61158-3-8 © IEC:2007 – 3 –
Table 6 – Summary of DL-management primitives and parameters . 24
Table 7 – Reset service primitives and parameters . 26
Table 8 – Event service primitive and parameters . 27
Table 9 – Set value service primitives and parameters . 27
Table 10 – Get value service primitives and parameters . 28
Table 11 – Get current configuration service primitives and parameters . 29
Table 12 – Get active configuration service primitives and parameters . 30
Table 13 – The active configuration parameter . 30
Table 14 – Set active configuration service primitives and parameters . 31

– 4 – 61158-3-8 © IEC:2007
INTERNATIONAL ELECTROTECHNICAL COMMISSION
____________
INDUSTRIAL COMMUNICATION NETWORKS –
FIELDBUS SPECIFICATIONS –
Part 3-8: Data-link layer service definition – Type 8 elements

FOREWORD
1) The International Electrotechnical Commission (IEC) is a worldwide organization for standardization comprising
all national electrotechnical committees (IEC National Committees). The object of IEC is to promote
international co-operation on all questions concerning standardization in the electrical and electronic fields. To
this end and in addition to other activities, IEC publishes International Standards, Technical Specifications,
Technical Reports, Publicly Available Specifications (PAS) and Guides (hereafter referred to as “IEC
Publication(s)”). Their preparation is entrusted to technical committees; any IEC National Committee interested
in the subject dealt with may participate in this preparatory work. International, governmental and non-
governmental organizations liaising with the IEC also participate in this preparation. IEC collaborates closely
with the International Organization for Standardization (ISO) in accordance with conditions determined by
agreement between the two organizations.
2) The formal decisions or agreements of IEC on technical matters express, as nearly as possible, an international
consensus of opinion on the relevant subjects since each technical committee has representation from all
interested IEC National Committees.
3) IEC Publications have the form of recommendations for international use and are accepted by IEC National
Committees in that sense. While all reasonable efforts are made to ensure that the technical content of IEC
Publications is accurate, IEC cannot be held responsible for the way in which they are used or for any
misinterpretation by any end user.
4) In order to promote international uniformity, IEC National Committees undertake to apply IEC Publications
transparently to the maximum extent possible in their national and regional publications. Any divergence
between any IEC Publication and the corresponding national or regional publication shall be clearly indicated in
the latter.
5) IEC provides no marking procedure to indicate its approval and cannot be rendered responsible for any
equipment declared to be in conformity with an IEC Publication.
6) All users should ensure that they have the latest edition of this publication.
7) No liability shall attach to IEC or its directors, employees, servants or agents including individual experts and
members of its technical committees and IEC National Committees for any personal injury, property damage or
other damage of any nature whatsoever, whether direct or indirect, or for costs (including legal fees) and
expenses arising out of the publication, use of, or reliance upon, this IEC Publication or any other IEC
Publications.
8) Attention is drawn to the Normative references cited in this publication. Use of the referenced publications is
indispensable for the correct application of this publication.
9) Attention is drawn to the possibility that some of the elements of this IEC Publication may be the subject of
patent rights. IEC shall not be held responsible for identifying any or all such patent rights.
NOTE Use of some of the associated protocol types is restricted by their intellectual-property-right holders. In all
cases, the commitment to limited release of intellectual-property-rights made by the holders of those rights permits
a particular data-link layer protocol type to be used with physical layer and application layer protocols in type
combinations as specified explicitly in the IEC 61784 series. Use of the various protocol types in other combinations
may require permission of their respective intellectual-property-right holders.
International Standard IEC 61158-3-8 has been prepared by subcommittee 65C: Industrial
networks, of IEC technical committee 65: Industrial-process measurement, control and
automation.
This first edition and its companion parts of the IEC 61158-3 subseries cancel and replace
IEC 61158-3:2003. This edition of this part constitutes an editorial revision.
This edition includes the following significant changes with respect to the previous edition:
a) deletion of the former Type 6 fieldbus, and the placeholder for a Type 5 fieldbus data-link
layer, for lack of market relevance;

61158-3-8 © IEC:2007 – 5 –
b) addition of new types of fieldbuses;
c) division of this part into multiple parts numbered 3-1, 3-2, …, 3-19.
This bilingual version (2013-07) corresponds to the monolingual English version, published in
2007-12.
The text of this standard is based on the following documents:
FDIS Report on voting
65C/473/FDIS 65C/484/RVD
Full information on the voting for the approval of this standard can be found in the report on
voting indicated in the above table.
The French version of this standard has not been voted upon.
This publication has been drafted in accordance with ISO/IEC Directives, Part 2.
The committee has decided that the contents of this publication will remain unchanged until the
maintenance result date indicated on the IEC web site under http://webstore.iec.ch in the data
related to the specific publication. At this date, the publication will be:
• reconfirmed;
• withdrawn;
• replaced by a revised edition, or
• amended.
NOTE The revision of this standard will be synchronized with the other parts of the IEC 61158 series.
The list of all the parts of the IEC 61158 series, under the general title Industrial
communication networks – Fieldbus specifications, can be found on the IEC web site.

– 6 – 61158-3-8 © IEC:2007
INTRODUCTION
This part of IEC 61158 is one of a series produced to facilitate the interconnection of
automation system components. It is related to other standards in the set as defined by the
“three-layer” fieldbus reference model described in IEC/TR 61158-1.
Throughout the set of fieldbus standards, the term “service” refers to the abstract capability
provided by one layer of the OSI Basic Reference Model to the layer immediately above. Thus,
the data-link layer service defined in this standard is a conceptual architectural service,
independent of administrative and implementation divisions.

61158-3-8 © IEC:2007 – 7 –
INDUSTRIAL COMMUNICATION NETWORKS –
FIELDBUS SPECIFICATIONS –
Part 3-8: Data-link layer service definition – Type 8 elements

1 Scope
1.1 Overview
This part of IEC 61158 provides common elements for basic time-critical messaging
communications between devices in an automation environment. The term “time-critical” is
used to represent the presence of a time-window, within which one or more specified actions
are required to be completed with some defined level of certainty. Failure to complete specified
actions within the time window risks failure of the applications requesting the actions, with
attendant risk to equipment, plant and possibly human life.
This standard defines in an abstract way the externally visible service provided by the Type 8
fieldbus data-link layer in terms of
a) the primitive actions and events of the service;
b) the parameters associated with each primitive action and event, and the form which they
take; and
c) the interrelationship between these actions and events, and their valid sequences.
The purpose of this standard is to define the services provided to
• the Type 8 fieldbus application layer at the boundary between the application and data-link
layers of the fieldbus reference model, and
• systems management at the boundary between the data-link layer and systems
management of the fieldbus reference model.
1.2 Specifications
The principal objective of this standard is to specify the characteristics of conceptual data-link
layer services suitable for time-critical communications, and thus supplement the OSI Basic
Reference Model in guiding the development of data-link protocols for time-critical
communications. A secondary objective is to provide migration paths from previously-existing
industrial communications protocols.
This specification may be used as the basis for formal DL-Programming-Interfaces.
Nevertheless, it is not a formal programming interface, and any such interface will need to
address implementation issues not covered by this specification, including
a) the sizes and octet ordering of various multi-octet service parameters, and
b) the correlation of paired request and confirm, or indication and response, primitives.
1.3 Conformance
This standard does not specify individual implementations or products, nor does it constrain the
implementations of data-link entities within industrial automation systems.
There is no conformance of equipment to this data-link layer service definition standard.
Instead, conformance is achieved through implementation of the corresponding data-link
protocol that fulfills the Type 8 data-link layer services defined in this standard.

– 8 – 61158-3-8 © IEC:2007
2 Normative references
The following referenced documents are indispensable for the application of this document. For
dated references, only the edition cited applies. For undated references, the latest edition of
the referenced document (including any amendments) applies.
ISO/IEC 7498-1, Information technology – Open Systems Interconnection – Basic Reference
Model — Basic Reference Model: The Basic Model
ISO/IEC 7498-3, Information technology – Open Systems Interconnection – Basic Reference
Model — Basic Reference Model: Naming and addressing
ISO/IEC 10731, Information technology – Open Systems Interconnection – Basic Reference
Model – Conventions for the definition of OSI services
3 Terms, definitions, symbols, abbreviations and conventions
For the purposes of this document, the following terms, definitions, symbols, abbreviations and
conventions apply.
3.1 Reference model terms and definitions
This standard is based in part on the concepts developed in ISO/IEC 7498-1 and ISO/IEC
7498-3, and makes use of the following terms defined therein:
3.1.1 DL-address [7498-3]
3.1.2 DL-connection [7498-1]
3.1.3 DL-connection-end-point [7498-1]
3.1.4 DL-connection-end-point-identifier [7498-1]
3.1.5 DL-connection-mode transmission [7498-1]
3.1.6 DL-connectionless-mode transmission [7498-1]
3.1.7 correspondent (N)-entities [7498-1]
correspondent DL-entities  (N=2)
correspondent Ph-entities  (N=1)
3.1.8 (N)-entity [7498-1]
DL-entity  (N=2)
Ph-entity  (N=1)
[7498-1]
3.1.9 (N)-layer
DL-layer  (N=2)
Ph-layer  (N=1)
3.1.10 layer-management [7498-1]
3.1.11 DL-local-view [7498-3]
3.1.12 DL-name [7498-3]
3.1.13 naming-(addressing)-domain [7498-3]
3.1.14 peer-entities [7498-1]
61158-3-8 © IEC:2007 – 9 –
3.1.15 primitive name [7498-3]
3.1.16 DL-protocol [7498-1]
3.1.17 DL-protocol-connection-identifier [7498-1]
3.1.18 DL-protocol-data-unit [7498-1]
3.1.19 reset [7498-1]
3.1.20 (N)-service [7498-1]
DL-service  (N=2)
Ph-service  (N=1)
[7498-1]
3.1.21 (N)-service-access-point
DL-service-access-point  (N=2)
Ph-service-access-point  (N=1)
[7498-3]
3.1.22 DL-service-access-point-address
[7498-1]
3.1.23 DL-service-connection-identifier
3.1.24 DL-service-data-unit [7498-1]
3.1.25 DL-simplex-transmission [7498-1]
3.1.26 systems-management [7498-1]
3.1.27 DLS-user-data [7498-1]
3.2 Service convention terms and definitions
This standard also makes use of the following terms defined in ISO/IEC 10731 as they apply to
the data-link layer.
3.2.1 confirm (primitive)
3.2.2 DL-service-primitive;
primitive
3.2.3 DL-service-provider
3.2.4 DL-service-user
3.2.5 indication (primitive);
acceptor.deliver (primitive)
3.2.6 request (primitive);
requestor.submit (primitive)
3.2.7 response (primitive);
acceptor.submit (primitive)
3.3 Common data-link service terms and definitions
NOTE This subclause contains the common terms and definitions used by Type 8.
3.3.1
link, local link
single DL-subnetwork in which any of the connected DLEs may communicate directly, without
any intervening DL-relaying, whenever all of those DLEs that are participating in an instance of

– 10 – 61158-3-8 © IEC:2007
communication are simultaneously attentive to the DL-subnetwork during the period(s) of
attempted communication
3.3.2
DLSAP
distinctive point at which DL-services are provided by a single DL-entity to a single higher-layer
entity
NOTE This definition, derived from ISO/IEC 7498-1, is repeated here to facilitate understanding of the critical
distinction between DLSAPs and their DL-addresses.

NOTE 1 DLSAPs and PhSAPs are depicted as ovals spanning the boundary between two adjacent layers.
NOTE 2 DL-addresses are depicted as designating small gaps (points of access) in the DLL portion of a DLSAP.
NOTE 3 A single DL-entity may have multiple DLSAP-addresses and group DL-addresses associated with a single
DLSAP.
Figure 1 – Relationships of DLSAPs, DLSAP-addresses and group DL-addresses
3.3.3
DL(SAP)-address
either an individual DLSAP-address, designating a single DLSAP of a single DLS-user, or a
group DL-address potentially designating multiple DLSAPs, each of a single DLS-user
NOTE This terminology is chosen because ISO/IEC 7498-3 does not permit the use of the term DLSAP-address to
designate more than a single DLSAP at a single DLS-user.
3.3.4
extended link
DL-subnetwork, consisting of the maximal set of links interconnected by DL-relays, sharing a
single DL-name (DL-address) space, in which any of the connected DL-entities may
communicate, one with another, either directly or with the assistance of one or more of those
intervening DL-relay entities
NOTE An extended link may be composed of just a single link.

61158-3-8 © IEC:2007 – 11 –
3.3.5
frame
denigrated synonym for DLPDU
3.3.6
receiving DLS-user
DL-service user that acts as a recipient of DLS-user-data
NOTE A DL-service user can be concurrently both a sending and receiving DLS-user.
3.3.7
sending DLS-user
DL-service user that acts as a source of DLS-user-data
3.4 Additional Type 8 data-link specific definitions
3.4.1
device
slave or master
3.4.2
device code
two octets which characterize the properties of a slave
3.4.3
DL-segment
group of slaves in consecutive order
3.4.4
DL-segment level
nesting level number of a DL-segment
3.4.5
master
DL-entity controlling the data transfer on the local link and initiating the medium access of the
slaves by starting the DLPDU cycle
3.4.6
slave
DL-entity accessing the medium only after being initiated by the preceding slave or master

– 12 – 61158-3-8 © IEC:2007
3.5 Common symbols and abbreviations
NOTE This subclause contains the common symbols and abbreviations used by Type 8.
DL- Data-link layer (as a prefix)
DLC DL-connection
DLCEP DL-connection-end-point
DLE DL-entity (the local active instance of the data-link layer)
DLL DL-layer
DLPCI DL-protocol-control-information
DLPDU DL-protocol-data-unit
DLM DL-management
DLMS DL-management Service
DLS DL-service
DLSAP DL-service-access-point
DLSDU DL-service-data-unit
FIFO First-in first-out (queuing method)
OSI Open systems interconnection
Ph- Physical layer (as a prefix)
PhE Ph-entity (the local active instance of the physical layer)
PhL Ph-layer
Quality of service
QoS
3.6 Common conventions
This standard uses the descriptive conventions given in ISO/IEC 10731.
The service model, service primitives, and time-sequence diagrams used are entirely abstract
descriptions; they do not represent a specification for implementation.
Service primitives, used to represent service user/service provider interactions (see ISO/IEC
10731), convey parameters that indicate information available in the user/provider interaction.

61158-3-8 © IEC:2007 – 13 –
This standard uses a tabular format to describe the component parameters of the DLS
primitives. The parameters that apply to each group of DLS primitives are set out in tables
throughout the remainder of this standard. Each table consists of up to six columns, containing
the name of the service parameter, and a column each for those primitives and parameter-
transfer directions used by the DLS:
 the request primitive’s input parameters;
 the request primitive’s output parameters;
 the indication primitive’s output parameters;
 the response primitive’s input parameters; and
 the confirm primitive’s output parameters.
NOTE The request, indication, response and confirm primitives are also known as requestor.submit,
acceptor.deliver, acceptor.submit, and requestor.deliver primitives, respectively (see ISO/IEC 10731).
One parameter (or part of it) is listed in each row of each table. Under the appropriate service
primitive columns, a code is used to specify the type of usage of the parameter on the primitive
and parameter direction specified in the column:
M — parameter is mandatory for the primitive.
U — parameter is a User option, and may or may not be provided depending on
the dynamic usage of the DLS-user. When not provided, a default value
for the parameter is assumed.
C — parameter is conditional upon other parameters or upon the environment of
the DLS-user.
(blank) — parameter is never present.
Some entries are further qualified by items in brackets. These may be
a) a parameter-specific constraint
(=) indicates that the parameter is semantically equivalent to the parameter in the
service primitive to its immediate left in the table.
b) an indication that some note applies to the entry
(n) indicates that the following note n contains additional information pertaining to the
parameter and its use.
In any particular interface, not all parameters need be explicitly stated. Some may be implicitly
associated with the DLSAP at which the primitive is issued.
In the diagrams which illustrate these interfaces, dashed lines indicate cause-and-effect or
time-sequence relationships, and wavy lines indicate that events are roughly
contemporaneous.
4 Data-link service and concepts
4.1 Overview
Type 8 provides a connection-oriented subset of services, specified in ISO/IEC 8886, on pre-
established DLCs. The DLS provides the sending or receiving DLS-user with either a FIFO
queue or a retentive buffer, where each queue item or buffer can hold a single DLSDU.
DL-names, known conventionally as DL-addresses, are identifiers from a defined identifier
space — the DL-address-space — which serve to name objects within the scope of the data-
link layer. The objects that need to be named within the DLL are data-link-connection-end-
points (DLCEPs).
– 14 – 61158-3-8 © IEC:2007
The DL-address-space from which DL-addresses are drawn may be partitioned into sub-spaces
of DL-addresses due to the class of the device in which the DLS-entity resides, and the class
of the addressed DLCEP.
Only two DLSAPs are supported by a DLE: a single default DLSAP for sending and receiving
data, and a single default management DLSAP to invoke local DL-management services. As
these DLSAPs are accessed locally, they have no DLSAP DL-address assigned to them. The
DLSAP used is determined implicitly by the type of service primitive selected.
A DLS-user may need to distinguish among several DLCEPs at the same DLSAP for sending
and receiving data; thus a local DLCEP-identification mechanism is also provided. All primitives
issued at such a DLSAP within the context of a DLC use this mechanism to identify the local
DLCEP. The naming-domain of this DLCEP-identification is the DL-local-view.
The relationship between DLSAPs, DLCEPs and DLCEP DL-addresses used for data transfer
services is shown in Figure 2.

NOTE 1 DLSAPs and PhSAPs are depicted as ovals spanning the boundary between two adjacent layers.
NOTE 2 DL-addresses are depicted as designating small gaps (points of access) in the DLL portion of a DLSAP. A
DLCEP-address also designates a specific point of information flow (its DLCEP) within the DLSAP.
NOTE 3 Only one DLS-user-entity can be associated with any given DL-entity.
NOTE 4 Only one default DLSAP is supported.
NOTE 5 Only connection oriented DL-services are supported. All DLCs are pre-configured and pre-established. No
DLSAP addresses are assigned.
Figure 2 – Relationships of DLCEPs and DLCEP-addresses to default DLSAP

61158-3-8 © IEC:2007 – 15 –
The DLS provides three classes of DLCEPs:
a) PEER — the DLS-user can exchange DLSDUs with one other peer DLS-user;
b) PUBLISHER — the DLS-user can send DLSDUs to a set of zero or more associated
subscribing DLS-users;
c) SUBSCRIBER — the DLS-user can receive DLSDUs from the associated publishing DLS-user.
NOTE The DLCEP Classes PUBLISHER and SUBSCRIBER only support one conveyance path from the publisher
DLCEP to each subscriber DLCEP. No conveyance path from a subscriber DLCEP to the publisher DLCEP exists.
All buffers and queues are pre-created and bound to DLCEPs. The DLS-user cannot directly
create, delete, bind or unbind buffers or queues.
DLCEPs of class PEER always use queues; DLCEPs of classes PUBLISHER and SUBSCRIBER
always use buffers which are bound to them.
DLCEPs of class PEER are used only for confirmed data transfer; DLCEPs of classes
PUBLISHER and SUBSCRIBER are used only for unconfirmed data transfers.
All DLCs are pre-defined and pre-established by local DL-management before any DLS-user is
granted access to the DLS.
All information used during creation of buffers and queues and establishing of DLCs is stored
by local DL-management. The means by which a DLS-user can obtain this information from
local DL-management is a local issue, beyond the scope of this standard.
A buffer is referenced by a Buffer DL-identifier assigned by local DL-management during
creation. As each buffer or queue is associated with (bound to) a single DLCEP, a DLCEP
DL-identifier or DLCEP DL-address (if assigned to the DLCEP) can also be used to reference
the buffer or queue bound to this DLCEP. Local DL-management can provide the DLS-user
with the facility to inter-convert the reference types.
4.2 Sequence of primitives
4.2.1 Constraints on sequence of primitives
This subclause defines the constraints on the sequence in which the primitives defined in 4.3
may occur. The constraints determine the order in which primitives occur, but do not fully
specify when they may occur.
In order to request a service, the DLS-user uses a request primitive. A confirmation primitive is
returned to the DLS-user after the service has been completed. The arrival of a service request
is indicated to the remote DLS-user by means of an indication primitive. The connection-mode
primitives and their parameters are summarized in Table 1. The major relationships among the
primitives at two DLC end-points are shown in Figure 3 through Figure 5.

– 16 – 61158-3-8 © IEC:2007
Table 1 – Summary of DL-connection-mode primitives and parameters
Service Primitive Parameter
Put buffer DL-PUT request (in Buffer DL-identifier
DLS-user-data)
DL-PUT confirm (out Status)
Get buffer DL-GET request (in Buffer DL-identifier)
DL-GET confirm (out Status,
DLS-user-data)
UFFER-RECEIVED indication (out Status)
Buffer received DL-B
Normal data DL-DATA request (in DLCEP DL-identifier,
transfer DLS-user-data)
DL-DATA indication (out DLCEP DL—identifier,
DLS-user-data)
DL-DATA confirm (out Status)
NOTE The method by which a DL-DATA confirm primitive is correlated with its corresponding
preceding request primitive is a local matter.

The sequence of primitives of a successful normal data transfer is defined in the time-
sequence diagrams in Figure 4. The sequence of primitives in a failed normal data transfer is
defined in the time-sequence diagram in Figure 5.

61158-3-8 © IEC:2007 – 17 –
Publisher Subscriber
DL-PUT request
DL-PUT confirm
DL-PUT request
DL-PUT confirm
DLPDU
DL-BUFFER-RECEIVED indication
DL-GET request
DL-GET confirm
DL-GET request
DL-GET confirm
Extended Link
NOTE 1 Primitives within the outlined areas can be repeated many times between instances of the primitives in
the enclosing areas.
NOTE 2 The request primitives within the outlined areas are locally confirmed.
Figure 3 – Sequence of primitives for the buffer data transfer

– 18 – 61158-3-8 © IEC:2007
Master Slave
DLE 1 DLE 2
DL-Data request
DL-Data indication
DL-Data confirm
.
.
DL-Data request
.
DL-Data indication
DL-Data confirm
Extended Link
Figure 4 – Normal data transfer service between a master and a slave
Master Slave
DLE 1 DLE 2
DL-Data request
DL-Data confirm
DL-Data request
DL-Data confirm
Extended Link
Figure 5 – Sequence of primitives for a failed normal data transfer
4.3 Connection-mode data-link services
4.3.1 Put buffer
4.3.1.1 Function
The DLS-user uses this service to write directly to the specified buffer. The service is locally
processed after the DL-PUT request primitive has arrived. The DLE communicates the
successful processing of the service to the DLS-user by means of a DL-PUT confirmation
primitive (immediate confirmation).

61158-3-8 © IEC:2007 – 19 –
4.3.1.2 Types of parameters
Table 2 indicates the primitive and parameters of the Put Buffer DLS.
Table 2 – Put buffer primitive and parameters
DL-PUT Request Confirm
input output
Parameter name
Buffer DL-identifier M
DLS-user-data M
Status M
NOTE The method by which a confirm primitive is correlated with its
corresponding preceding request primitive is a local matter.

4.3.1.2.1 Buffer DL-identifier
This parameter specifies the local DL-identifier of the buffer as assigned by local
DL-management.
4.3.1.2.2 DLS-user-data
This parameter specifies the user-data which is to be written to the buffer.
4.3.1.2.3 Status
This parameter indicates the success or failure of the preceding request. The value conveyed
in this parameter is as follows:
a) “OK — success — service completed”
b) “IV — failure — invalid parameters in the request”.
4.3.2 Get buffer
4.3.2.1 Function
The DLS-user uses this service to directly read the specified buffer. The service is locally
processed after the DL-GET request primitive has arrived. The DLE communicates the
successful processing of the service to the DLS-user by means of a DL-GET confirmation
primitive (immediate confirmation).
4.3.2.2 Types of primitives and parameters
4.3.2.2.1 General
Table 3 indicates the primitives and parameters of the Get Buffer DLS.
Table 3 – Get buffer primitive and parameters
DL-GET Request Confirm
Parameter name input output
Buffer DL-identifier M
DLS-user-data C
Status M
NOTE The method by which a confirm primitive is correlated with its
corresponding preceding request primitive is a local matter.

– 20 – 61158-3-8 © IEC:2007
4.3.2.2.2 Buffer DL-identifier
This parameter specifies the local DL-identifier of the buffer as assigned by local
DL-management.
4.3.2.2.3 DLS-user-data
This parameter is present when the preceding request primitive was successfully executed.
This parameter specifies the data which was read from the buffer.
4.3.2.2.4 Status
This parameter indicates the success or failure of the preceding request. The value conveyed
in this parameter is as specified in 4.3.1.2.3.
4.3.3 Buffer received
4.3.3.1 Function
The DLS-provider uses this service to inform the DLS-user about the successful update of all
buffers.
NOTE If the DLS-provider detects an error, no DL-BUFFER-RECEIVED indication is generated.
4.3.3.2 Types of primitives and parameters
4.3.3.2.1 General
Table 4 indicates the primitive and parameters of the Buffer Received DLS.
Table 4 – Buffer received primitive and parameters
DL-BUFFER-RECEIVED Indication
Parameter name output
Status M
4.3.3.2.2 Status
This parameter indicates the successful update of all buffers. The value conveyed in this
parameter is as follows:
NOTE 1 In this protocol all buffers on all DLCs are updated at the same time.
a) “OK — success — buffer received without errors”
NOTE 2 If the DLE detects an error no DL-BUFFER-RECEIVED indication is generated.
4.3.4 Normal data transfer
4.3.4.1 Function
This service allows a DLS-user (called local user) to send DLS-user-data to a single remote
DLE. If the remote DLE receives the data correctly, the data is reported to its DLS-user. The
requesting DLS-user receives a confirmation indicating the receipt or non-receipt of the user
data at the remote DLE.
4.3.4.2 Types of primitives and parameters
4.3.4.2.1 General
Table 5 indicates the types of primitives and the parameters needed for normal data transfer.

61158-3-8 © IEC:2007 – 21 –
Table 5 – Normal data transfer primitive and parameters
DL-DATA Request Indication Confirm
Parameter name input output output
DLCEP DL-identifier M M
DLS-user-data M M(=)
Status  M
NOTE The method by which a confirm primitive is correlated with its corres-ponding
preceding request primitive is a local matter.

4.3.4.2.2 DLCEP DL-identifier
This parameter specifies the DLCEP for which the data transfer service is to occur. The
identifier was assigned by local DL-management when the DLC was pre-established.
4.3.4.2.3 DLS-user-data
This parameter specifies the user data to be transmitted (request) or which was received
(indication).
4.3.4.2.4 Status
The link status parameter indicates the success or failure of the preceding request. The value
conveyed in this parameter is as follows:
a) “OK — success — service completed”
b) “RR — failure — resources of the remote DLCEP not available or insufficient”
c) “LR — failure — resources of the local DLCEP not available or insufficient”
d) “NA — failure — no response, or not a plausible response (acknowledge response), of
the remote device”
e) “DS — failure — DLE not synchronized at the moment”
f) “IV — failure — invalid parameter in the request”.

– 22 – 61158-3-8 © IEC:2007
5 DL-management service
5.1 Scope
This clause defines the administrative DL-management services (DLMS) which are available to
the DLMS user, together with their service primitives and the associated parameters. All
DL-management services use the default management DLSAP.
5.2 Facilities of the DL-management service
The service interface between the DLMS-user and the DLE makes the following functions
available:
a) reset of the local DLE;
b) request and change the current operating parameters of the local DLE;
c) indication of unexpected events, errors, and status changes, either local or remote;
d) read-out of the active DL-subnetwork configuration;
e) read-out of the current DL-subnetwork configuration;
f) setting of a DL-subnetwork configuration.
Together these facilities constitute the DLMS.
5.3 Overview of services
5.3.1 General
DL-management provides the following services to all DLMS-users:
a) reset
b) event.
DL-management may provide the following services to DLMS-users:
c) set value
d) get value.
DL-management provides the following additional services to DLMS-users of DLEs that are
functioning as a DLL master:
e) get current configuration
f) get active configuration
g) set active configuration.
5.3.2 Reset
The DLMS-user uses this required service to cause DL-management to reset the DLE. The
DLMS-user receives a confirmation for this service.
5.3.3 Event
DL-management uses this required service to inform the DLMS-user of certain events or
detected errors in the DLE.
61158-3-8 © IEC:2007 – 23 –
5.3.4 Set value
The DLMS-user uses this service to set a new value to the variables of the DLE. It receives a
confirmation on whether the specified variable(s
...