intolerant but loss tolerant traffic
Connectionless unreliable no retransmissions
Non-real time, delay tolerant but loss intolerant traffic
Connection-oriented reliable retransmissions
3.4
LTE Evolved Packet Core Network
Disadvantage Disadvantages of s of TCPTCP
Although it has proved to enormously resilient in carrying most types of IP traffic, TCP has demonstrated some distinct disadvantages when carrying signalling and control traffic.
TCP employs a ‘byte-oriented’ stream interface which ignores the message structure of the data it is carrying and treats all data as a stream of bytes to be transferred. TCP does not segment data based on the length or structure of the individual messages being passed to it by the higher-layer applications it is serving.
In order to reconstitute messages, higher-layer applications must insert control markings to delineate messages for the peer higher layer before passing the data to TCP, which adds to the complexity of the application and the ratio of overhead to data being carried.
Additionally, the single session that is gener ally established between TCP peers and the strictly controlled sequencing and acknowledgement mechanism for data exchange can cause a problem known as ‘head-of-line blocking’.
Head-of-line blocking means that, in the event of a retransmission being required, no further data can be sent until a valid copy of a data segment that requires retransmission has been successfully received and acknowledged. This means that data that requires retransmission, but that may not itself be part of a time-critical message, will hold back all following data, some of which may be time-critical This situation is exacerbated if the application only requires TCP’s byte sequencing functionality but not its reliable delivery mechanism.
The SS7 (Signalling System no. 7) messages used in PSTNs (Public Switched Telephone Networks) networks are typical of data types that have been seen to suffer from transmission over TCP for the reasons stated above. To overcome these issues, SCTP has been proposed as an alternative layer 4 system that could more reliably transfer signalling and control data across IP-based connections.
Signalling Application
Message 3
Message 2
Message 1
Streamed
Streamed
TCP MesMessagsage 3e 3 MesMessagsage 2e 2 MesMessagsage 1e 1 TCP
Corrupted push
single connection streamed data head-of-line blocking adaptive transmission timers MTU (Maximum Transmission Unit)
X X
Signalling Application
LT3604/v4.0 © Wray Castle Limited 3.5
Major Protocols
SCTP SCTP
SCTP, like TCP, is a connection-oriented layer 4 protocol that runs over the connectionless network layer service of IP. However, unlike TCP, which allows only a single session between two hosted applications (described by an IP address and port number), SCTP can provide multiple simultaneous sessions (known as ‘streams’) which can be multiplexed over the ‘association’ that is established between two hosts.
Multiple streams operating within the same association allow signalling flows to be separated, perhaps sending time-critical information over one stream and non-time-critical information over another, which can help to alleviate head-of-line blocking problems.
Each SCTP session is initiated through a graceful start-up process in which the parameters that describe the association between the two hosts (security information, transport addresses, number of streams and port addresses to be used) are agreed.
The SCTP start-up process is also designed to overcome some of the security and service continuity problems associated with TCP, such as connection hijacking and denial of service attacks.
An SCTP association is torn down using a graceful take-down process.
Further Reading: IETF RFC3286, RFC4960 Streamed
SCTP
Message 3 Message 2 Message 1 Message by
Message
SCTP
Message by Message
Sequenced delivery within streams
User data fragmentation
Acknowledgement
Chunk bundling
Stream 2 (call 2) Stream 1 (call 1)
Corrupted block
Message 3 Message 2 Message 1 Message 3 Message 2 Message 1
Association
X X
Signalling Application
Signalling Application
3.6
LTE Evolved Packet Core Network
SCTP Functions SCTP Functions
The term ‘stream’ is used in SCTP to refer to a sequence of individual user messages, referenced by an SSN (Stream Sequence Number), which are to be delivered to the upper layer.
This has the advantage of reducing the effects of head-of-line blocking of all messages by concentrating retransmission activities, when needed, on the messages travelling over only the affected stream; other streams can continue to transmit new messages. Additionally, a ‘blocked’ stream will only block messages marked as ‘ordered’, i.e. they are part of a sequence. Messages marked as ‘unordered’ may bypass the blockage and be delivered without delay to the upper-layer adaptation layer.
When necessary, SCTP fragments user messages to ensure that the SCTP packet passed to the lower layer conforms to the underlying network’s MTU (Maximum Transmission Unit). On receipt, fragments are reassembled into complete messages before being passed to the SCTP user.
SCTP assigns a TSN (Transmission Sequence Number) to each user message or message fragment that it transmits. The TSN is independent of any stream sequence number assigned at the stream level.
In this way, reliable delivery of all messages is kept functionally separate from the sequenced delivery within individual streams.
The SCTP packet as delivered to the IP layer consists of ‘chunks’. Each chunk may contain either user data – a message or message fragment – or SCTP control information. SCTP may bundle more than one chunk into a single SCTP packet if the MTU allows. This ‘chunk bundling’ function is responsible for assembly of the complete SCTP packet and its disassembly at the receiving end.
Further Reading: IETF RFC3286, RFC4960 Streamed
Message 3 Message 2 Message 1 Message 3 Message 2 Message 1
Association
LT3604/v4.0 © Wray Castle Limited 3.7
Major Protocols
SCTP Concepts SCTP Concepts
SCTP provides layer 4, end-to-end transport functions for signalling and control messages. The SCTP protocol sits on top of a standard IP protocol stack.
SCTP uses the concept of the TA (Transport Address), which is defined by an IP address and port number. In the context of SIGTRAN (Signalling Transport) the port number identifies the adaptation layer that is using SCTP’s transport services.
An SCTP endpoint can be defined as a logical sender or receiver of SCTP PDUs – an instance of S1AP or of SGsAP, for example. On the protocol stack this relates to a combination of IP address and port number. A single SCTP endpoint can have one or more transport addresses associated with it. When an endpoint has more than one transport address, it is said to be ‘multihomed’. Multihoming is useful as it assists with fault tolerance. It is convenient to consider an endpoint as a list of one or more transport addresses. A transport address may be considered as a ‘path’ to an endpoint.
An association may be defined as a protocol relationship between a defined pair of endpoints. Only one association can exist between a pair of endpoints at any given time. However, any endpoint may be used simultaneously in any number of associations.
A stream is a unidirectional logical channel between associated SCTP endpoints. An association may be configured to contain a number of incoming and outgoing streams, the maximum number of which is negotiated during the association’s initialization procedure. The use of multiple streams helps to reduce the impact of head-of-line blocking experienced by other connection-oriented protocols such as TCP.
Each stream is allocated an SI (Stream Identifier) and may be considered as a unique information flow within the context of an association.
One application of a stream may be to transfer signalling messages received on a particular signalling link connecting endpoint A to endpoint B. In the example shown in the diagram, link 1 may be mapped to stream 1 and link 2 to stream 2.
Further Reading: IETF RFC3286, RFC4960 Link 1 (IP address + port no.)
AL– Application Layer
IP +port number is known as a 'transport address'
3.8
LTE Evolved Packet Core Network
DiffServ DiffServ
DiffServ, as the name suggests, allows an IP transport network to differentiate between packets based on the service being carried by each packet – it essentially allows a network to prioritize some services over others.
The DiffServ architecture was deigned to provide a simple, highly scalable means to provide CoS (Class of Service) behaviour in the Internet, without the need for signalling or resource reservation on a pre-flow basis – as is the case with some systems such as RSVP (Resource Reservation Protocol).
DiffServ is defined in RFC 2474 ‘Definition of the DS Field (Differentiated Services Field) in the IPv4 and IPv6 Headers’, and RFC 2425 ‘An Architecture for Differentiated Services’.
This architecture achieves scalability by only dealing in aggregates of traffic, rather than attempting to provide QoS on a per-connection basis. Which of these predefined aggregates a packet belongs to is conveyed by means of IP-layer packet-marking using the DSCP field within the packet.
Packets are classified and marked at the boundary of the network (the eNB and PDN-GW in the EPS) to receive a particular per-hop forwarding behaviour on nodes along their path. Sophisticated classification, marking, policing and shaping operations only need to be implemented at network boundaries or hosts.
Network resources are allocated to traffic streams by service provisioning policies which govern how traffic is marked and conditioned upon entry to a DiffServ-capable network, and how that traffic is forwarded within that network. This administrative control is not considered directly in the DiffServ architecture documents, and is typically handled by administrative controls and provisioning of the intervening routers.
Once packets are classified at the edge of the network, specific forwarding treatments, formally called PHB (Per-Hop Behaviour), are applied on each network element, providing the packet with the appropriate delay bound, jitter bound, bandwidth, etc. This combination of packet marking and well defined PHBs results in a scalable QoS solution.
Further Reading: IETF RFC2474, RFC 2425