LTE Stream Control Transmission Protocol (SCTP)

In computer networking, the Stream Control Transmission Protocol (SCTP) is a transport-layer protocol (protocol number 132[1]), serving in a similar role to the popular protocols Transmission Control Protocol (TCP) and User Datagram Protocol (UDP). It provides some of the same service features of both: it is message-oriented like UDP and ensures reliable, in-sequence transport of messages with congestion control like TCP.

The IETF Signaling Transport (SIGTRAN) working group defined the protocol in 2000,[2] and the IETF Transport Area (TSVWG) working group maintains it. RFC 4960 defines the protocol. RFC 3286 provides an introduction.

Originally the SCTP was defined as a transport protocol for SS7 messages to be transmitted over IP networks. As TCP and UDP it is seen as a layer 4 transport protocol in the ISO OSI model.

The SCTP frames are called chunks. All chunks are associated to a connection that guarantees in-order delivery. However, within the same chunk there might be data blocks of different connections transmitted simultaneously. In addition, it is also possible to send urgent packets "out of order" with a higher priority.

SCTP also supports multihoming scenarios where one host owns multiple valid IP addresses.

Besides the data streams, SCTP frequently sends heartbeat messages to test the state of connection.

How SCTP works will be demonstrated by means of an example. Figure 1 shows the message flow required to transport the NAS signaling message Attach Request from the eNB to MME across the S1 interface.

 
Figure 1: SCTP example

After setting up a RRC connection on the Uu interface between the UE and the eNB, the UE sends the attach request message. When the appropriate RRC transport container is received by the eNB, the establishment of a dedicated SCTP stream on the S1 interface as shown in Figure 2 is triggered.

The establishment of the SCTP stream starts with a SCTP initiation message. It will always be sent by the eNB in the case of the attach procedure, because the RRC connection is established earlier and the request to transport the NAS message triggers the request to have a S1 connection. The SCTP initiation message contains the IP addresses of both the eNB and MME. The individual subscriber for which this connection is established is represented by a unique pair of SCTP source port and destination port numbers.

The SCTP initiation needs to be acknowledged by the peer SCTP entity in the MME. In the next step a SCTP cookie echo message is sent and acknowledged by Cookie Echo ACK. In the protocol world, this is called a heartbeat procedure. Such a procedure periodically checks the availability and function of the active connection. Similar functions with other message names are found, for example, in SS7 SCCP Inactivity Test or GTP Echo Request/Response.

On SCTP higher layer messages are transported using SCTP datagram (SCTP DTGR) packets. Each SCTP DTGR contains a Transaction Sequence Number (TSN) in addition to source and destination address information. This TSN will later be used by the peer entity to acknowledge the successful reception of the DTGR by sending an SCTP selective ACK message on S1 that confirms error-free reception of the SCTP DTGR that carried the attach request message. Further S1AP and NAS messages of this connection will be transported in the same way and the Cookie Echo/Cookie Echo ACKs will be sent periodically as long as the connection remains active.

If the S1 signaling transport layer SCTP has problems in offering proper functionality, there will be no signaling transport on S1 if the problems are located in the eNB SCTP entity. If the MME suffers from congestion or protocol errors on the SCTP level as shown in Figure 1.83, the expected selective ACK messages will be missing (maybe not sent at all, maybe sent with a TSN out of the expected range). This malfunction may be detected by a NACK Cookie Echo and as a result the connection will be terminated. Or the attach accept message expected to be received by the UE will be missed. The missing attach accept message will be recognized by the UE where a timer is guarding the NAS procedures. After the guard timer expires on the UE side the attach request message will be repeatedly sent up to n times (the counter value of n is configurable and typically signaled on the broadcast channel SIBs; the default value recommended by 3GPP is n = 5). If neither an attach request message nor an attach reject message is received by the UE the handset will go back to IDLE when the maximum number of attach request repetitions has been sent.

 
Figure 2: Failure in SCTP signaling transport