SCTP is a general-purpose transport layer protocol, like TCP and UDP, and operates above the IP layer. Like TCP, SCTP offers a point-to-point, connection oriented, reliable delivery transport service for applications communicating over an IP network and features powerful congestion control and packet loss recovery.
SCTP supports for multi-homing and partial ordering. Multihoming enables an SCTP host to establish a “session” with another SCTP host over multiple interfaces identified by separate IP addresses. Partial ordering lets SCTP provide in-order delivery of one or more related sequences of messages flowing between two hosts. Thus, SCTP can benefit applications that require reliable delivery and fast processing of multiple, unrelated data streams, c.f. “SCTP, New Transport Protocol for TCP/IP”, Randall Stewart, Chris Metz, Cisco Systems, page 64, November-December 2001 http://computer.org/internet/IEEE Internet Computing.
SCTP is described in (1) RFC 4960 “Stream Control Transmission Protocol”; (2) RFC 6458 “Sockets API Extensions for the Stream Control Transmission Protocol (SCTP)”; (3) RFC 4165 “Signaling System 7 (SS7) Message Transfer Part 2 (MTP2)—User Peer-to-Peer Adaptation Layer (M2PA)”
SCTP is used in (1) 3GPP TS 36.412 “S1 signalling transport” (within TSG RAN “Evolved Universal Terrestrial Access Network (E-UTRAN)”) and TS 36.413 “S1-AP Application Protocol” and (2) RFC 3588 or RFC 6733 “Diameter Base Protocol”
In some network places only one SCTP association between two nodes are allowed (like interface S1-MME between eNB and MME in LTE/EPC system, according to 3GPP TS 36.412, chapter 7), Diameter (according to RFC 6733) and M2PA (according to RFC 4165). At the same time, especially for S1-MME some traffic is time critical (should be delivered within ˜10 ms) though most traffic, especially paging to UEs with high idle mode DRX, is not so time critical, fully ok if delivered within 100-200 ms.
For the M2PA protocol there is also a need as is uses two streams in each direction for each association. One stream is used for Link Status messages. The other stream is used for User Data messages. Separating the Link Status and User Data messages into separate streams allows M2PA to prioritize the messages in a manner similar to MTP2.
Diameter: RFC6733, 2.1 Transport, 6th §: “A given Diameter instance of the peer state machine must not use more than one transport connection to communicate with a given peer, unless multiple instances exist on the peer, in which, case a separate connection per process is allowed.”
Bundling is including more than one SCTP data chunk (and/or SACK) in one SCTP message/IP datagram. This is particularly applicable and effective for small SCTP chunks (e.g. SACK, S1-AP paging messages, etc.). SCTP bundling reduces the number of IP datagrams sent.
In known SCTP systems, a Bundling Timer is set to a value in the range 0-10 ms (or more depending on application), to fulfil the timing requirements for the time-critical traffic, though that may be the minor part of the traffic. Thereby, one sacrifices network bandwidth efficiency and CPU load in end nodes and routers forwarding the datagrams between nodes, because of very little resulting bundling.
IETF recently published a new version of “A new data chunk for stream control transmission protocol”, Network Working Group, Internet-Draft, Standards Track; R. Stewart et al. Oct. 20, 2013 (draft-stewart-tsvwg-sctp-ndata.txt). This document introduces a parameter SCTP_SS_PRIORITY: Scheduling with different priorities is used.
Streams having a higher priority will be scheduled first and when multiple streams have the same priority, the default scheduling should be used for them. The priority can be assigned with the sctp_stream_value struct. The higher the assigned value, the lower the priority, that is, the default value 0 is the highest priority and therefore the default scheduling will be used if no priorities have been assigned.
This document would seem to constitute a solution for accomplishing different priorities for e.g. Link Status Messages and User Data messages, for instance for the M2PA protocol example above.
However, the prior art examples above still leaves something to be desired in terms of capacity utilisation and speed.
USPTO Backgrounds
USPTO Backgrounds