0% found this document useful (0 votes)
138 views3 pages

Stream Control Transmission Protocol

SCTP is a transport layer protocol that provides reliable in-order message delivery between applications. It supports features like multihoming, where a host can use multiple IP addresses. SCTP frames are called chunks, which can contain data from different connections simultaneously. SCTP uses heartbeat messages to check the connection state and frequently sends these to test connectivity. It is commonly used to carry signaling messages over the S1 interface between the eNB and MME in LTE networks.

Uploaded by

diporufai
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
138 views3 pages

Stream Control Transmission Protocol

SCTP is a transport layer protocol that provides reliable in-order message delivery between applications. It supports features like multihoming, where a host can use multiple IP addresses. SCTP frames are called chunks, which can contain data from different connections simultaneously. SCTP uses heartbeat messages to check the connection state and frequently sends these to test connectivity. It is commonly used to carry signaling messages over the S1 interface between the eNB and MME in LTE networks.

Uploaded by

diporufai
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 3

Stream Control Transmission Protocol (SCTP)

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

You might also like