SCTP Protocol in SIMATIC Networks: Transport Reference Guide

Overview of SCTP in Industrial Automation

The Stream Control Transmission Protocol (SCTP) is a transport layer protocol defined in RFC 4960 and updated by RFC 9260 in 2022. It was originally specified by the IETF Signaling Transport (SIGTRAN) working group in 2000 to carry PSTN signaling messages over IP networks. As described in the SCTP Wikipedia reference, SCTP combines the reliability of TCP with the message boundary preservation of UDP, and adds two features that neither TCP nor UDP provide: multi-homing and multi-streaming.

In an industrial SIMATIC environment, the most common reason to consider SCTP is a third-party mandate (customer requirement, telecom backhaul, or regulatory framework) that specifies SCTP as the only acceptable transport. SIMATIC S7-1200 and S7-1500 CPUs and their associated CP modules do not expose SCTP as a configured transport option in the TIA Portal connection configuration; the protocol is not part of the published firmware feature set of the Siemens SIMATIC CP family as of the current TIA Portal V18 / V19 generation. This reference describes the architecture, the affected modules, the alternatives, and the available workaround strategies for engineers who must integrate SIMATIC into an SCTP-mandated environment.

SCTP Technical Architecture

SCTP operates at OSI layer 4 and provides connection-oriented, message-oriented, reliable data transfer. The common header is exactly 12 bytes, followed by one or more chunks:

Each chunk carries its own 4-byte header: Chunk Type (1 byte), Chunk Flags (1 byte), Chunk Length (2 bytes), and a variable-length Chunk Value. The valid chunk types in the current RFC 9260 specification are:

The four-way handshake replaces the TCP three-way handshake and adds DoS protection through a state cookie. Multi-homing means that each endpoint advertises a list of transport addresses; HEARTBEAT chunks continuously monitor reachability of each alternate address, and a path failure triggers retransmission on a backup without re-establishing the association. Multi-streaming allows multiple independent data flows inside one association so that head-of-line blocking affects only one stream. SCTP also implements message bundling: several short DATA chunks from different streams can be concatenated into a single IP packet to improve throughput, and partial reliability (PR-SCTP, RFC 3758) lets the application set a TTL for each message.

SIMATIC CP Module Compatibility Assessment

None of the SIMATIC S7-1200 or S7-1500 CP modules listed below ships with a firmware release that exposes SCTP as a user-selectable transport in the TIA Portal project tree. The published manuals enumerate only TCP, UDP, ISO-on-TCP, PROFINET, S7 communication, Modbus TCP, OPC UA Transport Profile, and IEC 61850 MMS (selected CPs). SCTP is therefore a non-feature at the catalog level, and a feature request raised with Siemens support will be returned as "not on the roadmap" for the legacy S7-300 / S7-400 CP family.

The CP 1623 / CP 1628 are PCI Express cards supplied with a Siemens driver package. The driver provides the PROFINET, S7, and TCP/UDP acceleration features of the CP, but SCTP acceleration is not part of the documented feature set. A SIMATIC IPC running Windows or Linux can still open a raw SCTP socket on the underlying OS stack, but the CP firmware does not participate in the association. The CPU side stays on TCP/UDP; the IPC side speaks SCTP to the remote peer.

Industrial Use Cases That Specify SCTP

The vast majority of SIMATIC deployments never encounter SCTP because industrial automation standardized on TCP and ISO-on-TCP decades ago. The following scenarios are the few that do require SCTP, and identifying the original use case is the first step in any workaround design:

• Telecommunications signaling — Diameter, M3UA, M2PA, M2UA, SUA, IUA, all of which were specified by IETF SIGTRAN and ITU-T on top of SCTP.
• 4G/5G mobile radio interfaces — S1AP, NGAP, X2AP, E1AP, F1AP, and N2 use SCTP per 3GPP TS 36.413, TS 38.413, and TS 38.472.
• Cellular IoT gateways — Some industrial 5G/4G routers expose a "raw SCTP" mode for backhaul into operator core networks.
• Substation automation over LTE — Certain IEC 61850-90-5 deployments have been implemented with SCTP at the transport layer in research contexts; deployed utility networks predominantly use TCP or UDP.
• Rail and defense signaling — Vendor-specific protocols in some signaling stacks still require SCTP for redundancy and authentication.

If a customer mandates SCTP, the request is almost always traceable to one of the bullet points above. The pragmatic reaction is not to seek a SIMATIC firmware patch that adds SCTP, but to introduce a gateway or a SIMATIC IPC that terminates the SCTP association outside the CPU.

Transport Protocol Alternatives in SIMATIC

SIMATIC offers a generous set of transport options. The table below compares the features that matter when SCTP is being considered as a replacement or substitute.

The RFC 1006 ISO transport over TCP, often called "ISO-on-TCP" or simply "ISO transport", is the closest S7-1500 native option to SCTP in terms of message orientation and reliability. It is the transport used by S7 communication and by the TSEND / TRCV blocks when the connection type is "ISO on TCP". T_Conn is the parameter data block that stores the remote IP, remote port, and the local TPDU length. ISO-on-TCP still does not give you multi-homing, but it gives you the message semantics and the ISO transport selector that the S7 partner expects.

UDP-Based Workaround Strategy

SCTP cannot be replaced by raw UDP without losing reliability, sequencing, multi-homing, and multi-streaming. A common engineering compromise is to implement a thin SCTP-like application layer on top of UDP, where the PC endpoint maintains the SCTP association with the remote peer and the SIMATIC CPU exchanges reliable datagrams with the PC over a single UDP socket. The pattern has the following components:

1. Heartbeat probe: the PC sends a one-byte heartbeat to the CPU every 2 s; the CPU replies. If two consecutive heartbeats are missed, the CPU triggers a backup connection on a different IP.
2. Sequence number: each datagram carries a 32-bit sequence number; the receiver buffers and discards duplicates.
3. Application ACK: a 4-byte selective acknowledgment is sent every 16 datagrams, listing received sequence numbers.
4. Reassembly: the message boundary is provided by a length prefix in the UDP payload, since UDP preserves datagram boundaries on its own.
5. Keep-alive on UDP socket: configure TUSEND / TURCV with a connect_id that does not time out (TIA Portal default 30 s; raise to 600 s for store-and-forward applications).

The cost is a per-byte overhead of 4 (sequence) + 4 (length) + 4 (control flags) = 12 bytes per datagram, on top of the 8-byte UDP header and the 20-byte IPv4 header. For 100-byte payloads, the efficiency is 100 / (100+12+8+20) = 71 %, which is comparable to a 128-byte SCTP DATA chunk that would carry 100 bytes of payload and 4 bytes of chunk header plus 12 bytes of common header = 100/136 = 74 %.

PC-Based Software Implementation

For situations where the SCTP association must be terminated on the local site, a SIMATIC IPC (IPC 227G, IPC 277G, IPC 347G, IPC 647E, IPC 847E) is the most maintainable option. The CPU retains its PROFINET, S7, and TCP/UDP transport options, and the IPC is added as a peer in the S7 project under "PC station".

• Linux kernel SCTP — The mainline kernel (≥ 2.6) ships lksctp with the net/sctp module. Enable with modprobe sctp and inspect with cat /proc/net/sctp/assocs and cat /proc/net/sctp/remaddrs.
• Windows SCTP — Microsoft does not ship a native SCTP stack with Windows. Options include the lksctp-for-Windows port, the sctp.ko driver package, and commercial libraries such as OpenFastCSC.
• Python — The pysctp module wraps the Linux kernel ABI; install with pip install pysctp on a SIMATIC IPC with matching kernel headers.
• Java — The JDK does not include SCTP. The OpenFastCSC project provides a JNI binding for the Linux lksctp module.

Example Python SCTP server that listens on port 38412 and echoes a length-prefixed datagram to a SIMATIC IPC-side client. The struct sctp_initmsg is set to 10 outbound streams and 10 inbound streams:

import socket
import struct

SCTP_PROTO = 132  # IPPROTO_SCTP on Linux
SCTP_INITMSG = 14  # option name
initmsg = struct.pack('HHHH', 10, 10, 8, 60)  # OS, MIS, max_att, max_to

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM, SCTP_PROTO)
s.setsockopt(SCTP_PROTO, SCTP_INITMSG, initmsg)
s.bind(('0.0.0.0', 38412))
s.listen(5)

conn, addr = s.accept()
while True:
    data = conn.recv(2048)
    if not data:
        break
    # Length-prefixed echo: first 4 bytes = payload length
    conn.send(struct.pack('!I', len(data)) + data)

On the SIMATIC side the data exchange happens through a TUSEND / TURCV pair that targets the IPC IP and UDP port 38412. The PROFINET traffic, S7 connection, and the IPC channel are independent and can coexist on the same Ethernet subnet. TIA Portal V18 and V19 expose TUSEND / TURCV under "Instructions > Communication > Open User Communication".

SIMATIC SCL Sample for the CPU Side

The following Structured Control Language snippet shows a typical S7-1500 bridge block. It opens a TCP listener on port 2000 for configuration, opens a UDP socket to the IPC at 192.168.10.50 / 38412, and forwards each received TCP request to the IPC as a length-prefixed UDP datagram.

// fbSctpBridge.scl - S7-1500 / S7-1200 (FW 4.4+)
FUNCTION_BLOCK "fbSctpBridge"
{ S7_Optimized_Access := 'TRUE' }
VERSION : 1.0
VAR_INPUT
  iEnable : BOOL;
  iIpcIp : STRING[15] := '192.168.10.50';
  iIpcPort : UINT := 38412;
  iLocalTcpPort : UINT := 2000;
END_VAR
VAR_OUTPUT
  oUdpBusy : BOOL;
  oTcpBusy : BOOL;
  oError : BOOL;
  oStatus : WORD;
END_VAR
VAR
  stUdpConnParams : TCON_IP_V4;   // UDP param struct
  stTcpConnParams : TCON_IP_V4;   // TCP param struct
  fbUdpSend : TUSEND;
  fbUdpRecv : TURCV;
  fbTcpServer : TSERVER;
  tSendBuf : ARRAY[0..1452] OF BYTE;
  tRecvBuf : ARRAY[0..1452] OF BYTE;
  tLen : UDINT;
END_VAR
BEGIN
  IF iEnable THEN
    // TCP listener config
    #fbTcpServer.connectId := 1;
    #fbTcpServer.connParam.localPort := #iLocalTcpPort;
    #fbTcpServer();
    oTcpBusy := #fbTcpServer.status = 16#7000;

    // UDP send / recv config
    #fbUdpSend.id := 10;
    #fbUdpSend.connectId := 2;
    #fbUdpSend.req := TRUE;
    #fbUdpSend.len := #tLen;
    #fbUdpSend.data := #tSendBuf;
    #fbUdpSend();

    #fbUdpRecv.id := 11;
    #fbUdpRecv.connectId := 2;
    #fbUdpRecv();

    oUdpBusy := #fbUdpSend.status = 16#7000 OR
                #fbUdpRecv.status = 16#7000;
    oStatus  := #fbUdpSend.status;
  END_IF;
END_FUNCTION_BLOCK

Compile the block in TIA Portal V18 or V19 and download it to the S7-1500 CPU. The TCP listener can be tested with telnet 192.168.10.20 2000 from the engineering station; the UDP datagram exchange can be observed in Wireshark with the filter udp.port == 38412.

Security and Network Considerations

SCTP brings its own security extensions, most of which are not natively available in SIMATIC and must be implemented on the IPC peer:

• RFC 4895 (AUTH) — adds a shared-key HMAC-SHA-1 to the INIT / INIT-ACK / COOKIE-ECHO handshake, preventing connection-flooding and man-in-the-middle attacks during association setup.
• DTLS over SCTP (RFC 8261) — replaces the deprecated RFC 3436 TLS-over-SCTP, supports streaming datagram mode and application data record protection. Requires OpenSSL ≥ 1.1.1 with the DTLS-SCTP provider.
• IPsec / ESP — can protect the entire SCTP packet at layer 3, used in carrier networks where M3UA runs over SCTP / IPsec.
• NAT traversal — SCTP is not NAT-friendly out of the box. RFC 6951 (UDP Encapsulation) wraps SCTP inside UDP and is the only practical path through enterprise firewalls. Most firewalls will still not understand the multi-homed paths and may drop heartbeats.
• Firewall rules — open the destination UDP port (RFC 6951 mode) or TCP port (deprecated) toward the IPC IP; the SIMATIC CPU does not need a rule change because it is only a TCP/UDP peer of the IPC.
• CP 1545-1 security features — the SIMATIC CP 1545-1 brings firewall, VPN, and TLS termination for TCP-based protocols; SCTP traffic is not filtered by the CP and must be terminated upstream.

Diagnostics and Verification Procedures

Once the gateway architecture is in place, the following checks verify that the SCTP association is alive and that the CPU-to-IPC datagram exchange is healthy:

1. On the SIMATIC IPC, run ss -K -p under Linux (iproute2 ≥ 4.16) to see active SCTP associations, including TSN, SSN, and the state (ESTABLISHED, SHUTDOWN-PENDING). On older systems use cat /proc/net/sctp/assocs.
2. On the same IPC, run cat /proc/net/sctp/remaddrs to list remote addresses and the primary / active path.
3. Capture with Wireshark and apply the display filter sctp; the source / destination port, chunk type, TSN, and SSN are decoded. Multi-homing is visible when the same association shows two different IP source addresses for HEARTBEAT chunks.
4. In TIA Portal online diagnostics, open the CPU's diagnostic buffer and the CP 1543-1's connection statistics; no SCTP counters are exposed, but UDP datagram counters on TUSEND / TURCV confirm the IPC↔CPU link.
5. Use tshark -z sctp,assoc to enumerate all SCTP associations, retransmission counts, and RTT estimates.
6. In the TIA Portal project, right-click the CPU and select "Online & Diagnostics > Diagnostic buffer" to confirm no communication alarms raised by the CP 1543-1 during the SCTP association lifetime.

If a connection fails, the first check is whether the Wireshark capture shows an INIT / INIT-ACK / COOKIE-ECHO / COOKIE-ACK handshake; an absent INIT means the SCTP peer is unreachable, while an absent COOKIE-ACK means the path MTU is below 1280 bytes and the handshake is being fragmented. In the latter case, raise the MTU on the managed switch port to ≥ 1500 bytes and disable jumbo frame fragmentation of the SCTP cookie. A second common failure is the SIMATIC CPU's TCP connection watchdog (default 30 s) closing the socket while the IPC is still waiting for the next SCTP HEARTBEAT; raise the CPU-side keep-alive in the T_Conn parameter to 600 s.

Migration Path and Field-Proven Tips

When the engineering team is forced to deploy SIMATIC into an SCTP-mandated environment, the field-proven rollout pattern is as follows:

1. Validate that the remote peer really requires SCTP. Many "SCTP required" specifications in vendor RFPs are a copy-paste from a 3GPP document and the peer will accept TCP if you ask.
2. If SCTP is non-negotiable, source a SIMATIC IPC with a Linux image that ships the lksctp kernel module. Siemens does not bundle the module on its IPC images; you will need to rebuild the kernel or use a third-party distribution.
3. Configure the IPC as a "PC station" in the TIA Portal project and add an S7 connection to the CPU. This is the control plane; the SCTP traffic is the data plane and never touches the S7 protocol.
4. Open the firewall on the managed switch between the IPC and the remote peer. Add a SPAN port to a Wireshark capture node so that the SCTP association can be observed during commissioning.
5. Commission with a synthetic load generator that sends 100 INIT/s and 1000 DATA/s for 24 hours; the SIMATIC CPU is rated for a fixed number of open user connections (typically 64 for S7-1516, 32 for S7-1511) and the watchdog will close the UDP socket if the load exceeds the configured resource limit.
6. Document the architecture, the part numbers, the firmware versions, and the IP addresses in the project's network diagram. The SCTP gateway is a critical single point of failure; the customer will need this information for maintenance.

Frequently Asked Questions