Introduction

The DNP3 protocol is a standardized SCADA protocol with a large propagation in the world. Due to its high efficiency it works very well in environments with low bandwidth and high latency like TETRA networks.
In contrast to some other protocols like MODBUS, DNP3 does not need a periodic polling of all field stations to collect events like changed binary inputs, counters or analog values in the field stations. After the logic connection to the field station is established, any kind of events are sent unsolicitedly to the SCADA server when they happen at the outstation.
Events which are happening within a certain time frame are usually collected to be sent together in one message frame. In case something happens in a field station, which changes many parameters within i.e. one second, these events will be combined into one message frame instead of generating many single messages (each including overhead and requiring acknowledgement from the SCADA server). This has a major positive impact to save bandwidth in a TETRA network.
A single DNP3 message can usually be as long as 2048 bytes, but the transport layer splits the message into smaller parts of up to 256 bytes.
There are two implementations of DNP3: DNP3/IP, which is the IP based protocol version and DNP3/Serial which is using a serial data connection.

Both DNP3 versions (IP and Serial) are designed to work perfectly over a TETRA network.
 

DNP3/IP

The DNP3/IP standard allows the use either with TCP or UDP as transport protocol, as the acknowledgement and repetition of missing frames is fully handled by the DNP3 protocol itself.
In TETRA networks UDP should always be preferred over TCP!
TCP has more overhead, adds additional acknowledgement packets which are not needed for DNP3 and TCP stacks at the server side usually do not have adjustable packet timeouts, which can lead to unnecessary packet repetitions and congestions on the TETRA Packet Data Channel.
 

Requirements for DNP3/IP in TETRA
Control Room Connection

The SCADA server should have a direct IP connection to the TETRA switch. It uses the TETRA Packet Data Gateway of the TETRA infrastructure as the router into the wireless TETRA network. This eliminates the bottleneck and the high latency of a radio connection on the control room side. Also the possible unsolicited events, which can be sent at any time from any field station, could cause a congestion and packet loss if the SCADA server would be linked via a TETRA radio connection.

TETRA Network requirements

In the TETRA network, the Packet Data service must be available to route the IP packets between the SCADA server and the field stations.
Also, each base station must have one slot configured as a Packet Data Channel (PDCH). The PDCH should be assigned as “static” to avoid a communication loss in the SCADA system in case too many voice calls are active at a certain time. The availability of emergency calls is given at any time as an emergency call will “steal” any kind of traffic slot in case all slots should be busy at the time of the emergency call.
Finally the TETRA network should support Packet Data Channel Sharing to handle more than one modem being on the PDCH at the same time.
Without PDCH sharing, a single modem will block the PDCH for exclusive use during the communication and in addition for the configured time of the “READY timer” (usually 3-5 seconds). During this time, no other modem can do any kind of IP communication on this time slot. In case another modem wants to send an IP packet, it will be refused with “No resources” from the base station, which will result in a packet loss. 
With PDCH sharing, at least 32 modems can be on the same time on a single PDCH. The base station handles the efficient communication without any waste of TETRA resources. In this case on each base station, 50-100 modems can operate easily with DNP3/IP on one single Packet Data Channel.

At least one Packet Data Channel per base station is required for the use of DNP3/IP.

DNP3/Serial

For DNP3/Serial either Packet Data or SDS can be used as the transport method in the TETRA network. In the control room a TGW-100 gateway is needed to connect the serial interfaces of the SCADA server to the TETRA infrastructure and to perform the routing to the field modems based on the SCADA address found in the messages. 
Packet Data has a better error handling as it can selectively repeat any small part of a message, also Packet Data does not need a native SDS-API support for the TETRA infrastructure manufacturer in the TGW-100 gateway.
SDS messages are using the Main Control Channel of the TETRA base station for communication. For smaller deployments (up to 20-30 modems per TETRA basestation) no additional traffic slot should be needed.
In case more modems are attached to a TETRA base station, the SDS traffic can affect the control channel in a way that i.e. call setups can take longer due to high traffic. In this case a Secondary Control Channel can be used to run the SCADA traffic separated from the other control messages.

As the SDS API to send and receive SDS via the TETRA switch is not standardized, the TGW-100 must support the API of the TETRA infrastructure manufacturer.
Smaller deployments of up to 20 field stations and pilots can be used with SDS even without a TGW-100 gateway, using a TMO-100 TETRA modem also at the master side. Nevertheless, for production use a TGW-100 is recommended.

If not more than 20-30 modems are registered to a base station, SDS can use the Main Control Channel so that no additional traffic slot is needed for the SCADA service.
Packet Data has a more efficient error handling than SDS. If Packet Data is already used for other IP based services, also DNP3/Serial can share the already available PDCH without affecting the MCCH load.