In a digital packet-switched communications system different types of traffic, e g voice, data, audio and video, may be conveyed between multiple parties via shared resources, e g routers or transmission channels. Some traffic, such as many audio and video applications, typically occurs in real time, whereas other traffic, such as many data applications, typically is non-real time traffic.
In such a system a sender is an application or entity that encodes and sends media, that has been received from a sending party, to a receiver. A receiver is an application or entity that receives, decodes and presents media to a receiving party. An application, acting as a sender or as a receiver or both, may be located in a client or on a server, e g in user equipment or other hardware of a sending or a receiving party. An application can be run in a client or on a server to provide or deliver a service, e g to a user or other party. More specifically, an application can run on a server to encode and send media to a client, where an application is running to receive, decode and present the media to a user, whereby the applications running on the server and in the client function to provide a service to the user. A service may involve one or several media types, e g voice and data, or video and audio.
Different transmission requirements apply for real-time traffic compared to non-real time traffic. For example, non-real time traffic such as file transfer does not allow packet loss, i e packets of data that are not received correctly at the receiving end, but is less sensitive to transmission delay than real-time traffic. Real-time traffic, on the other hand, can tolerate some packet loss but is more sensitive to transmission delay than non-real time traffic. Therefore different types of transmission protocols have been designed to comply with the needs of real-time traffic and non-real time traffic respectively. One example of a protocol adapted to fulfill the requirements of non-real time traffic is Transmission Control Protocol (TCP), and one example of a protocol adapted to fulfill the requirements of real time traffic is User Datagram Protocol (UDP). A typical use of UDP is for real-time critical data such as Voice over IP (VoIP) and streaming media. Another use of UDP is for signalling control data for on-line games.
FIG. 1 shows an example of a shared resource 120 having an ingress node 110 and multiple egress nodes 100. It is a well-known fact that packet-switched networks utilizing shared resources between the users can experience congestion. Congestion will happen when the sum of traffic of the ingress nodes, i e the entry points, of the shared resource exceeds the sum of the traffic of the egress nodes, i e the exit points, of the same shared resource. The most typical example is a router with a specific number of connections. Even if the router has processing power enough to re-route the traffic according to the link throughput, the currently available link throughput might restrict the amount of traffic the outgoing links from the router can cope with. Hence, the buffers of the router will build up and eventually overflow. The network now experiences congestion and the router is forced to drop packets.
Another example of congestion can be found when studying wireless networks with shared channels such as Wireless Local Area Network (WLAN) specified in IEEE 802.11 a/b/g, or mobile networks such as High-Speed Packet Access (HSPA), Long-Term Evolution (LTE) and Worldwide Interoperability for Microwave Access (WiMAX). In these networks, at least the downlink is shared between the users and is by that a possible candidate to experience congestion. In e.g. the case of LTE, shown in FIG. 2, the eNB base station 220 will manage re-transmissions on the Medium Access Control (MAC) layer over transmission channels 210 to the mobile terminal or User Equipment (UE) 200 which will have impact on the amount of traffic the eNB base station at any given moment can provide throughput for. The more re-transmissions required for successful reception at the UE, the less available power for providing throughput for other users, thereby making the use of the transmission capacity of the shared resource less efficient.
The normal behavior for any routing node is to provide buffers that can manage a certain amount of variation in input/output link capacity and hence absorb minor congestion occurrences. However, when the congestion is severe enough, the routing node will eventually drop packets.
For TCP traffic, a dropped packet will be detected by the sender since no Acknowledge (ACK) is received for that particular packet and a re-transmission will occur. Further, the TCP protocol has a built in rate adaptive mechanism which will lower the transmission bit-rate when packet losses occur and re-transmissions happen on the Internet Protocol (IP) layer. If an ACK is not received within a specific time interval, set by a re-transmission time-out value, the data is retransmitted. The TCP retransmission time-out value is dynamically determined for each connection, based on round-trip time. At the receiver, sequence numbers are used to correctly order segments that may be received out of order and to eliminate duplicates. TCP governs the amount of data sent by returning a window with every acknowledgement to indicate a range of acceptable sequence numbers beyond the last segment successfully received. The window indicates an allowed number of octets that the sender may transmit before receiving further permission. Since this flow control is built into the protocol itself, TCP provides a rate adaptive mechanism independently of whatever application that uses it. This mechanism has the effect that the transmission bit-rate can be reduced stepwise when congestion occurs, and also that it can be increased stepwise when congestion ceases.
To further increase the performance of routing nodes, a scheme called “Explicit Congestion Notification (ECN) for IP” has been developed, specified in IETF specification RFC 3168, which is hereby incorporated in its entirety by reference. As shown in FIG. 3, this scheme utilizes two bits, ECN bits 300 in the Type Of Service (TOS) field 310, in the IP header 320 to signal the risk for congestion-related losses. The field has four code points where two are used to signal ECN capability and the other two are used to signal congestion. The code point for congestion is set in e.g. routers and when the receiver has encountered a congestion notification it propagates the information to the sender of the stream which then can adapt its transmission bit-rate. For TCP, this is done by using two, previously reserved, bits in the TCP header. When received, these bits trigger the sender to reduce its transmission bit-rate.
UDP traffic has no similar generic mechanism for reliable transmission and flow control. UDP traffic is by definition non-reliable in the sense that the delivery is not guaranteed. Lost UDP packets will not be re-transmitted unless the application has some specialized feature which allows this. UDP by itself does not respond in any way to network congestion, and the transmission rate is determined by the application, not by UDP itself.
ECN is defined for IP usage with any transport protocol. Hence, ECN for UDP is not excluded in the specification for ECN, IETF RFC 3168, although it is only specified in terms of using with TCP traffic. UDP by itself has no mechanism to change its transmission behavior based upon the reception of a congestion notification message. Without this mechanism, ECN for UDP becomes highly unreliable since the effect of setting the ECN bits in the IP header cannot be predicted. ECN for UDP needs the same generic mechanisms as ECN for TCP; a fast back-channel for signalling feedback from the receiver to the sender regarding the received transmissions and a rate control algorithm for changing the transmission bit-rate dynamically.
As delay-sensitive communication services, such as UDP based real-time communication services, may also be quite sensitive to packet loss there is a need to manage the transmissions via shared resources for such services so that congestion can be alleviated or avoided and/or to make efficient use of the transmission capacity of the shared resource, e g when increasing the traffic after that congestion has ceased. The transmissions via shared resources can be managed by controlling the transmission bit-rate of the applications providing the services via the shared resources. However, controlling the transmission bit-rate of the applications will impact the transmission delay. Whereas a less delay-sensitive service will still be working although delivered at a slower pace if the transmission bit-rate is reduced, the consequence for a delay-sensitive service may be that the service cannot be seen as working if a too drastic reduction of the transmission bit-rate is performed.
USPTO Backgrounds
USPTO Backgrounds