There are a variety of ways to manage congestion in a communications network. Typically, a bitrate cap is applied to each connection to limit the amount of network bandwidth that any one device can occupy. A simple bitrate cap can work fairly well in wire line communications networks where it can be expected that the available bitrate in the “last mile” will remain constant. This holds well in wire line technologies such as DSL or fiber optics. The bitrate cap can be introduced either in the endpoint (modem) or in the access point (Digital Subscriber Line Access Multiplexer). The benefit with a bitrate cap for each device is that bitrate beyond the point at which all the connections are aggregated is strictly bounded, being limited to N×bitrate_cap, where N is the number of devices and bitrate_cap is the uplink bitrate cap.
However, numerous other methods are proposed or being implemented in wire line communications networks.
Low Extra Delay Background Transport (LEDBAT) is a working group of the IETF with the goal to standardize a congestion control for applications that wish to grab as much available bandwidth as possible but release it quickly as soon as congestion occurs. The LEDBAT working group charter is available at http://tools.ietf.org/wg/ledbat/charters. The traffic class associated to this behavior is often termed “less than best effort”. LEDBAT may be used for background upload and/or download services or with peer-to-peer technology. The LEDBAT method is already today implemented in peer to peer networks such as uTorrent. Flows that employ the LEDBAT congestion control mechanism may run with very high bitrates when the network is unloaded and will thus be able to complete, say, a file transfer much faster. This allows for efficient communication during periods of low network activity. However, a bitrate cap limitation can defeat the purpose and significantly reduce the effectiveness of the LEDBAT method.
The Congestion Exposure (ConEx) working group of the IETF has a charter, available at http://tools.ietf.org/wg/conex/charters, which states the aim of the working group is to develop a mechanism by which senders inform the network about the congestion encountered by previous packets on the same flow. The network may signal congestion by ECN (explicit congestion notification) markings or by dropping packets, and the receiver passes this information back to the sender in transport-layer acknowledgements. The mechanism to be developed by the ConEx working group will enable the sender to also relay the congestion information back into the network in-band at the IP layer, such that the total level of congestion is visible to all IP devices along the path. The purpose of this is to ensure that any single device doesn't cause too much congestion either on purpose (abuse) or by accident (Denial of Service attack). A problem with implementing the ConEx proposal is that it requires modification to every node within a network, which makes it a very difficult upgrade to apply to existing networks.
RFC3168 “The Addition of Explicit Congestion Notification (ECN) to IP” describes how ECNs may be applied to IP communications. This document specifies the incorporation of ECN (Explicit Congestion Notification) to TCP and IP, including ECN's use of two bits in the IP header. This document specifies that the Internet provide a congestion indication for incipient congestion where the notification can sometimes be through marking packets rather than dropping them (as is standard practice in TCP). This uses an ECN field in the IP header with two bits, making four ECN codepoints, ‘00’ to ‘11’. The ECN-Capable Transport (ECT) codepoints ‘10’ and ‘01’ are set by the data sender to indicate that the end-points of the transport protocol are ECN-capable.
In wireless communications networks, uplink congestion is typically managed by implementing an uplink bitrate cap per device to ensure that individual devices don't use too much of the finite uplink capacity. An uplink bitrate cap will typically be enforced by measuring the uplink bitrate and introducing packet drops if the uplink bitrate exceeds the bitrate cap. However, when a bitrate cap such as this is applied to a wireless network, the assumption of constant bitrate over the ‘last mile’ no longer holds. Typically the wireless communications devices are located at different distances from the base station and the laws of physics dictate that devices that are closer to the base station are able to get higher uplink bitrates than devices further away. This is because the output power of the transmitter in wireless communications devices is limited.
FIG. 1 shows a wireless communications system which allows a plurality of wireless communications devices 100 to communicate with the internet 150 via a wireless communications network 105 comprising a base station 110 and additional network equipment 120. Base station 110 includes a processor 111, which is arranged to perform the functions required to manage and conduct wireless communications with the wireless communications devices 100. Base station 110 creates at least one cell of the wireless communications network 105. The wireless communications network 105 includes an uplink scheduler 115, which schedules the transmissions of wireless communications devices 100. As illustrated in FIG. 1, some wireless communications devices 100 are situated very close to base station 110, and some are situated comparably further away.
As wireless communications devices 100 move around, the average expected bitrate in the uplink for each device is limited by:average_bitrate=total_max_ul_bitrate/N where N is the number of devices and “total_max_ul_bitrate” is the total maximum uplink bitrate for the cell. This assumption holds true for averages taken over medium term timescales (minutes and hours, as devices are moved around within the network over such a timescale), but does not hold true for averages taken over shorter timescales (seconds). Devices 100 that are far away from the base station 110 are unlikely to be able to reach the average bitrate while devices that are close to the base station can obtain bitrates well beyond the average bitrate.
A simple bitrate cap applied in this scenario does not account for the fact that a far away device can make much noise with little gain. A simple analogy is a person trying to hold a conversation in a crowded room with another person 10 m away. Further, such a simple bitrate cap unnecessarily limits the uplink bitrate for some devices. A device that is close to the base station could utilize the extra bitrate to complete an upload faster (with a very limited cost in terms of resource usage) and therefore leave room for others when the upload is complete. This is not possible with a bitrate cap in place.
For the bitrate cap control mechanism to be removed from a wireless communications network, an alternative mechanism to prevent abuse must be provided. Accordingly, there is a need for an improved mechanism for managing communications within a wireless communications network.
USPTO Backgrounds
USPTO Backgrounds