DOCUMENT REVISION HISTORY

Name of Document: DNP V3:00 Transport Functions

Network File Name: P009-0PD.TF
Original Author: Malcolm Smith
Date and Version of Preliminary Release: November 8, 1992 Version 0.00A
Associated Software Release(s): DNP V3.00
Revisions Since Preliminary Release
Date Version By Whom Pages
Affected
Reason for Changes
Nov. 08/92 0.00A M. Smith All Created
Aug. 20/93 0.01 J. Bhat All Revised after review
Sep 01/93 0.01 AV All Corrections as per C. Huene
May 30/97 0.01 S. Tessari All Converted to MSWord 6.0
DNP Users Group
DNP PRODUCT DOCUMENTATION
DNP V3.00
TRANSPORT FUNCTIONS
Document Version: 0.01
Internal File: P009-0PD.TF
Associated Software Release: DNP V3.00
NOTICE OF RIGHTS - DNP USERS GROUP
The contents of this manual are the property of the DNP Users Group.
Revisions or additions to the definition and functionality of the
Distributed Network Protocol cannot be made without express written
agreement from the DNP Users Group or its duly authorized party. In
addition, no part of this document may be altered or revised or added to
in any form or by any means, except as permitted by written agreement
with the DNP Users Group or a Party duly authorized by the DNP
Users Group.
As a Party, duly authorized by the DNP Users Group, Harris
Corporation has made every reasonable attempt to ensure the
completeness and accuracy of this document, however, the information
contained in this manual is subject to change without notice, and does
not represent a commitment on the part of Harris Corporation or the
DNP Users Group. An update program for DNP documents is provided
upon request by Harris Corporation on behalf of the DNP Users Group.
TRADEMARK NOTICES
Brand and product names mentioned in this document are trademarks
or registered trademarks of their respective companies.
DNP V3.00 Transport Functions (Version 0.01)
i
TABLE OF CONTENTS
ABOUT THIS DOCUMENT iii
PURPOSE OF THIS SPECIFICATION iii
WHO SHOULD USE THIS SPECIFICATION iii
HELP AND ADDITIONAL DOCUMENTATION iii
HOW THIS SPECIFICATION IS ORGANIZED iv
CONVENTIONS USED IN THIS SPECIFICATION iv
1. OVERVIEW 1-1
2. TRANSPORT FUNCTIONS 2-1
2.1 TRANSPORT HEADER 2-1
2.2 TRANSPORT HEADER FIELD DEFINITIONS 2-2
2.3 FRAME ASSEMBLING 2-3
2.4 TRANSMISSION OF MESSAGES 2-4
3. TRANSPORT SERVICES AND RESPONSIBILITIES 3-1
3.1 TRANSPORT FUNCTIONS 3-1
3.2 INTERFACE DESCRIPTION 3-2
LIST OF ABBREVIATIONS AND ACRONYMS
DNP Users Group
ii
TABLE OF FIGURES
FIGURE 2-1 TRANSPORT LAYER MESSAGE LAYOUT 2-2
FIGURE 2-2 TH BIT DEFINITIONS 2-2
FIGURE 2-3 ASSEMBLING OF DATA FROM THREE DATA FRAMES 2-3
FIGURE 2-4 TRANSMISSION OF A SINGLE FRAME MESSAGE 2-4
FIGURE 2-5 FRAGMENTING OF A MULTI-FRAME APPLICATION MESSAGE 2-4
DNP V3.00 Transport Functions (Version 0.01)
iii
ABOUT THIS DOCUMENT
PURPOSE OF THIS SPECIFICATION
This document specifies the Distributed Network Protocol (DNP) V3.00 Transport
Functions, transmission procedures and Transport Protocol Data Unit.
WHO SHOULD USE THIS SPECIFICATION
This specification is intended for communication engineers and programmers interested in
knowing the function and message format of the DNP V3.00 Transport Functions. This
includes programmers implementing and designing DNP V3.00 Transport Functions
software/hardware and quality assurance personnel testing and verifying implementations
of the DNP V3.00 Transport Functions. Application programmers may find this
specification useful in determining how to interface with and make use of the DNP V3.00
Transport Functions. Familiarity with the ISO-OSI 7-layer model, IEC 3-layer EPA and
IEC TC-57 standards is helpful.
HELP AND ADDITIONAL DOCUMENTATION
The following documentation may be helpful.
IEC 870-5-1 and IEC 870-5-2 standards (or drafts), Technical Committee No. 57 for
data transmission in telecontrol systems
DNP V3.00 Data Object Library (P009-0BL)
DNP V3.00 Application Layer (P009-0PD.APP)
DNP V3.00 Data Link Layer (P009-0PD.DL).
DNP Users Group
iv
HOW THIS SPECIFICATION IS ORGANIZED
1. OVERVIEW
A general overview of the transport functions.
2. TRANSPORT FUNCTIONS
A detailed description of the packet formats and transmission procedures.
3. TRANSPORT SERVICES AND RESPONSIBILITIES
Services provided by an interface to the transport functions.
LIST OF ABBREVIATIONS AND ACRONYMS
CONVENTIONS USED IN THIS SPECIFICATION
In this document, the octet is a term used to refer to an eight bit-data object and is
synonymous with the term byte. The low order bit of an octet is referred to as bit 0 and
the high order bit as bit 7.
Irregular capitalization is used in referencing technical terms which have an associated
verb or noun. For example, data link indications commonly referred to as IND, can also be
described using the word INDication.
DNP V3.00 Transport Functions (Version 0.01)
1-1
1. OVERVIEW
This document defines the Distributed Network Protocol (DNP) V3.00 Transport
Functions, Transport Protocol Data Unit (TPDU), as well as transport services and
transmission procedures. Master stations, submaster stations and outstations or intelligent
electronic devices (IEDs) can use these transport functions to pass messages between
primary (originating) stations and secondary (receiving) stations. In this protocol, master
stations, submaster stations and outstations are both originators (primary stations) and
receivers (secondary stations).
The ISO (International Organization for Standardization) OSI (Open System
Interconnection) model supported by this protocol specifies physical, data link and
application layers only. This is termed the Enhanced Protocol Architecture (EPA).
However, to support advanced RTU functions and messages larger than the maximum
frame length as defined by the IEC (International Electrotechnical Committee) document
870-5-1, the DNP V3.00 Data Link is intended to be used with this pseudo-transport layer
which implements message assembly and disassembly.
This pseudo-transport layer is actually a super-data link transport protocol which is
normally found as part of some OSI data links. However, because the IEC data link (DNP
V3.00 Data Link Layer) does not support these functions in the data link, it is necessary to
move them out of the data link in order to maintain compliance.
DNP V3.00 Transport Functions (Version 0.01)
2-1
2. TRANSPORT FUNCTIONS
This section describes the Transport layer functions which act as a pseudo-transport layer
to the DNP data link layer. The pseudo-transport layer function is specific only for those
messages that are larger than one Link Protocol Data Unit (LPDU) between primary and
secondary stations. This pseudo-transport layer acts as the DNP data link user in a
protocol stack consisting of only the DNP Data Link and DNP Application Layer. This
functionality allows the pseudo-transport layer to disassemble one Transport Service Data
Unit (TSDU) into multiple (more than one) Transport Protocol Data Units (TPDUs), or
frames, and assemble multiple (more than one) TPDUs into one TSDU.
This process works as follows:
The pseudo-transport layer takes one TSDU (user data) and breaks it into several
sequenced TPDUs (each with Transport Protocol Control Information (TPCI)). Each
TPDU is sent to the data link layer as Link Service Data Unit (LSDU) for transmission.
It also works in the reverse fashion. The pseudo-transport layer receives multiple TPDUs
from the data link layer and assembles them into one TSDU.
LSDUs are user data fragments which are small enough to fit into the defined FT3 frame
format. When a primary station transmits a message to a secondary station, the transport
functions break the message into LSDUs. These functions add a Transport layer Header
(TH) octet at the beginning of the user data fragments that contain the information for the
secondary station to reconstruct the complete message. All pseudo-transport layer
messages have a TH.
The secondary station checks the TH octet on reception of each LSDU for the correct
sequence and builds a TSDU message for higher layers.
The TH contains information that can identify the first frame, last frame and give every
frame a six-bit sequence number. This information is required to reconstruct a message
and also to guard against higher layers from receiving misdirected or incomplete messages.
2.1 TRANSPORT HEADER
After the data link receives a complete frame, the data is presented to the transport
functions in a format illustrated below. The TH field is stripped out before the frame is
combined with other frames belonging to the same message. Figure 2-1 shows the
structure of a TPDU.
-----------------
| | |
DNP Users Group
2-2
| TH | USER DATA |
| | |
-----------------
Figure 2-1 Transport Layer Message Layout
TH Transport control octet. One octet in length.
USER DATA 1 to 249 octets in length.
When an application requests the transmission of a long message, the message is broken
into fragments small enough to fit in a single DNP V3.00 Data Link frame. The maximum
size of a fragment is 249 octets of user data. The TH is added to the head of the fragment
and the maximum number of octets to be framed becomes 250 octets.
Maximum data link data count + 255 octets
Data link header data count - 5 octets
Transport header - 1 octet
Application user data = 249 octets
2.2 TRANSPORT HEADER FIELD DEFINITIONS
-----------------------------------------------
| | | | | | | | |
| FIN | FIR | | | SEQUENCE | | |
| | | | | | | | |
-----------------------------------------------
BIT 7 6 5 4 3 2 1 0
Figure 2-2 TH Bit Definitions
FIN The final bit indicates that this frame of user data is the last frame of a
sequence which compromises a complete user message.
FIN = 0 More frames follow.
1 Final frame of a sequence.
FIR The first bit indicates that the frame is the first in a sequence of frame(s)
which comprise a complete message. When a secondary station receives a
frame with the FIR bit set, all previously received unterminated frame
sequences are discarded. The first frame of a sequence may have any
sequence from 0 to 63.
If a frame is received without the FIR bit set and no message sequence is
currently in progress, then the frame is ignored.
If a complete user message is only one frame in length, both the FIR and
FIN bits are set.
FIR = 1 First frame of a sequence.
0 Not the first frame of a sequence.
DNP V3.00 Transport Functions (Version 0.01)
2-3
SEQUENCE The sequence number of the frame is used to check that each frame is being
received in sequence. It guards against missing or duplicated frames. All
user messages start off with a sequence specified in the first frame which
has the FIR bit set (each message may start with any sequence number
between 0 and 63). After sequence number 63 the next sequence number
will be 0.
The sequence number increments for each frame sent to or received from
the same address belonging to the same message and resets at the
beginning of a new message. The sequence number does not have to
increment across message boundaries, i.e. any sequence number is valid
when the FIR bit is set.
2.3 FRAME ASSEMBLING
Figure 2-3 illustrates the assembling of a three-frame message. The first frame of the
message identified by having the FIR bit set in the TH field. The last frame is identified by
having the FIN bit set in the TH field.
USER DATA FRAMES TRANSPORT DATA BUFFER

--------------
| SOURCE = n |
--------------
--------------
| FIR = 1 |
| FIN = 0 |
| SEQUENCE = 3| Note sequence starts with the value in the frame that has the FIR bit = 1
| USER DATA 0 |
-------------- -----------> -------------
| USER DATA 0 |
-------------
--------------
| SOURCE = n |
--------------
--------------
| FIR = 0 |
| FIN = 0 |
| SEQUENCE = 4|
| USER DATA 1 |
-------------- -----------> -------------
| USER DATA 1 |
-------------
| USER DATA 0 |
-------------
--------------
| SOURCE = n |----------------------------------->
-------------- SOURCE ADDRESS passed to application
--------------
| FIR = 0 |
| FIN = 1 | FIN indicates last frame
| SEQUENCE = 5|
| USER DATA 2 |
-------------- -----------> -------------
| USER DATA 2 | FIN indicated this is the last frame of message
-------------
| USER DATA 1 |
-------------
| USER DATA 0 | complete message passed to application
------------- ----------->
Figure 2-3 Assembling of Data From Three Data Frames
DNP Users Group
2-4
2.4 TRANSMISSION OF MESSAGES
Figure 2-4 illustrates the transmission of a single frame message using the SEND -
CONFIRM frame service. Figure 2-5 illustrates the transmission of a multi-frame message
using the SEND - CONFIRM frame service.
FRAMES SENT FROM DATA LINK COMPLETE MESSAGE FROM APPLICATION
CONFIRM FRAMES RECEIVED
---------------
| DESTINATION | parameter from application
---------------
---------------
| USER DATA |
| |
| 30 octets |
---------------
--------------
| DESTINATION | parameter to data link
--------------
--------------
| FIR = 1 |
| FIN = 1 | 1 TH octet
| SEQUENCE = 1 |
| USER DATA 0 | send 30 user octets plus 1 TH = 31 octets
SEND <----- --------------
CONFIRM -------> --------------------> SUCCESS to application layer
Figure 2-4 Transmission of a Single Frame Message
--------------
| DESTINATION | parameter from application
--------------
--------------
| USER DATA |
| |
| 598 octets |
--------------
--------------
| DESTINATION | parameter to data link
--------------
--------------
| FIR = 1 |
| FIN = 0 | 1 TH octet
| SEQUENCE = 2 |
| USER DATA 0 | send 249 octets (1 to 249 is the valid range for this count)
SEND <------- --------------
CONFIRM --------> --------------
| DESTINATION | parameter to data link
--------------
--------------
| FIR = 0 |
| FIN = 0 |
| SEQUENCE = 3 |
| USER DATA 1 | send 249 octets
SEND <------- --------------
CONFIRM --------> --------------
| DESTINATION | parameter to data link
--------------
--------------
| FIR = 0 |
| FIN = 1 |
| SEQUENCE = 4 |
| USER DATA 2 | send last 100 octets (249 + 249 + 100 = 598)
SEND <------- --------------
CONFIRM --------> --------------------> SUCCESS to application layer
Figure 2-5 Fragmenting of a Multi-Frame Application Message
DNP V3.00 Transport Functions (Version 0.01)
3-1
3. TRANSPORT SERVICES AND
RESPONSIBILITIES
3.1 TRANSPORT FUNCTIONS
This section describes the services offered by the pseudo-transport layer and its function.
The communication requirements of the network layer and the application layer are
satisfied by the pseudo-transport layer service primitives.
The pseudo-transport layer is responsible for performing the following functions:
Packing user data into multiple frames (more than one) of the defined DNP V3.00 Data
Link frame format and using the services of the DNP V3.00 Data Link for transmitting
the data
Unpacking multiple frames that are received from the data link into user data
Controlling all aspects of the data link excluding data link configuration.
The pseudo-transport layer is responsible for providing the following services:
Exchange of SDUs between peer DNP V3.00 pseudo-transport layers
Error notification to transport user
Sequencing of SDUs
Prioritized SDU delivery
Quality SDU delivery.
SDUs will only be exchanged between peer DNP V3.00 pseudo-transport layers.
Error notification is given to the transport user when a response to a request has not been
received.
Priority delivery can be set to EXPEDITED or NORMAL to indicate a high or low
priority request.
Quality delivery can be set to SEND-NO-REPLY or SEND-CONFIRM to indicate
whether or not message acknowledgment is required.
DNP Users Group
3-2
3.2 INTERFACE DESCRIPTION
The pseudo-transport layer service primitives are illustrated in pseudo code to illustrate
the requirements and behavior in a real implementation and are not intended as an exact
interface definition.
Transport request (REQ) services can be used at any time after the transport functions
have been initialized and configured by the system.
confirm = request_transport_service(
SERVICE,
TIME_SERVICE,
destination,
source,
send_data_buffer,
send_count,
retry_flag,
time_of_transmission)
Input:
SERVICE Service to perform.
TIME_SERVICE Guaranteed time service to perform.
source Source address to use in sent message.
destination Destination address to use in sent message.
send_data_buffer Data to send in message.
send_count Number of octets in message.
retry_flag Instructs data link layer to retry unacknowledged frames or not.
time_of_transmission Time that first bit of first octet of message is to be sent.
Output:
time_of_transmission Time that first bit of first octet of message was sent
confirm = 0 Requested service is successful.
1 Requested service has failed.
2 Requested SEND data service is terminated by the current primary
station. (reception of a NACK frame from the secondary station).
3 Service code is not implemented.
4 Requested service cannot proceed at this time because the data link
is busy either with a previous requested transaction, current
unrequested transaction or waiting for physical layer availability.
DNP V3.00 Transport Functions (Version 0.01)
3-3
service = 0 Send a message specified in parameters using SEND-CONFIRM
frames. Fails if the data link is busy.
1 Send a message specified in parameters using SEND-NO- REPLY
frames. Fails if the data link is busy.
2 Expedited send a message specified in parameters using SEND-
CONFIRM frames. May necessitate canceling the current
secondary transaction if a half-duplex system is used.(i.e. forces the
data link to send a NACK frame instead of a CONFIRM frame in
the next secondary transaction). This action only takes place if the
primary station is using SEND-CONFIRM frames.
3 Expedited send a message specified in parameters using SEND-
NO-REPLY expected frames. In a half-duplex system, this may
mean canceling the current secondary transaction. (as above).
4 Return link status. Return successful if the data link is not busy.
time_service = 0 Send message at time specified in time_of_transmission. This
service should have the highest priority.
1 Send message at any time with priority specified.
Data link indications (IND) can be requested at any time by the service user but should be
checked as often as possible in order to obtain received data.
indications = request_data_link_indications(
source_address,
destination_address,
received_data_buffer,
received_data_count,
time_of_reception)
Output:
source_address Source address of received message.
destination_address Destination address of received address.
received_data_buffer Received message.
received_data_count Number of octets in message.
time_of_reception Time at which first bit of first octet of message was received.
DNP Users Group
3-4
Indications = 0 No indications to report.
1 Data link has received a valid message that has been placed in
received_data_buffer and the number of octets received has been
placed in received_data_count. The source address of the received
message has been placed in source_address. If the data link is
configured as a master station then the time that the first bit of the
first octet of the message was received has been placed in
time_of_reception. If the data link is configured as an outstation
then the time_of_reception will still be returned but the service user
has to be aware of the possibility of inaccurate times received
before the outstation has been time-synchronized.
2 Pseudo-transport layer has detected a transaction failure.
DNP V3.00 Transport Functions (Version 0.01)
1
LIST OF ABBREVIATIONS AND
ACRONYMS
CRC cyclic redundancy check
DNP Distributed Network Protocol
EPA enhanced protocol architecture
IEC International Electrotechnical Commission
ISO International Organization for Standardization
octet 8-bit data object (byte)
OSI Open System Interconnection
RTU remote terminal unit