Explicit Congestion Notification Marking of User Traffic

Abstract

The proposed technology relates to methods and radio network nodes for Explicit Congestion Notification, ECN, marking of user traffic in wireless communication networks. For example, a method performed by a sending radio network node (10) comprises the step of monitoring (S10) a congestion metric on a data radio bearer, and the step of transmitting (S20) control information indicating traffic congestion on the same data radio bearer, based on the monitored congestion metric, to a receiving radio network node (20).Further, a method performed by a receiving radio network node (20) comprises the step of receiving (S100) control information indicating traffic congestion on a data radio bearer, based on a congestion metric, from a sending radio network node (10), and the step of marking (S200) next ECN-capable user packet of the user traffic on the same data radio bearer with ECN marking, based on the received control information.

Claims

1-42. (canceled)

43. A method performed by a sending radio network node for supporting Explicit Congestion Notification (ECN) marking of user traffic in a wireless communication network, wherein said method comprises the steps of: monitoring a congestion metric on a data radio bearer; and transmitting control information indicating traffic congestion on said data radio bearer, based on said congestion metric, to a receiving radio network node.

44. The method of claim 43, wherein said congestion metric is a Radio Link Control (RLC) buffer level.

45. The method of claim 43, wherein said congestion metric is a user packet queuing delay.

46. The method of claim 43, wherein said control information is transmitted in an RLC Control Protocol Data Unit (PDU).

47. The method of claim 43, wherein said control information is transmitted in a Medium Access Control (MAC) control message.

48. A method performed by a receiving radio network node for Explicit Congestion Notification (ECN) marking of user traffic in a wireless communication network, wherein said method comprises the steps of: receiving control information indicating traffic congestion on a data radio bearer, based on a congestion metric, from a sending radio network node; and marking a next ECN-capable user packet of said user traffic on said data radio bearer with ECN marking, based on said control information.

49. The method of claim 48, wherein said control information is received in a Radio Link Control (RLC) Control Protocol Data Unit (PDU).

50. The method of claim 48, wherein said control information is received in a Medium Access Control (MAC) control message.

51. The method of claim 48, wherein said user packet is an Internet Protocol (IP) packet.

52. The method of claim 48, wherein said wireless communication network is a Long Term Evolution (LTE) network.

53. A sending radio network node configured to support Explicit Congestion Notification (ECN) marking of user traffic in a wireless communication network, the sending radio network node comprising: a processor and a memory, said memory comprising instructions executable by the processor, whereby the processor is configured to monitor a congestion metric on a data radio bearer; and communication circuitry configured to transmit control information indicating traffic congestion on said data radio bearer, based on said congestion metric, to a receiving radio network node.

54. The sending radio network node of claim 53, wherein said congestion metric is a Radio Link Control (RLC) buffer level.

55. The sending radio network node of claim 53, wherein said congestion metric is a user packet queuing delay.

56. The sending radio network node of claim 53, wherein said control information is in an RLC Control Protocol Data Unit (PDU).

57. The sending radio network node of claim 53, wherein said control information is in a Medium Access Control (MAC) control message.

58. The sending radio network node of claim 53, wherein said processor is configured to cause the communication circuitry to transmit said control information based on said congestion metric exceeding a given threshold.

59. The sending radio network node of claim 53, wherein said wireless communication network is a Long Term Evolution (LTE) network.

60. The sending radio network node of claim 53, wherein said sending radio network node is an eNodeB.

61. The sending radio network node of claim 53, wherein said sending radio network node is a wireless communication device.

62. A non-transitory computer-readable medium comprising, stored thereupon, a computer program comprising instructions that, when executed by at least one processor of a sending radio network node, cause the at least one processor to: monitor a congestion metric on a data radio bearer; and prepare control information indicating traffic congestion on said data radio bearer, based on said congestion metric, for transmitting to a receiving radio network node.

63. A receiving radio network node configured to mark user traffic in a wireless communication network with Explicit Congestion Notification (ECN) marking, wherein said receiving radio network node comprises: communication circuitry configured to receive control information indicating traffic congestion on a data radio bearer, based on a congestion metric, from a sending radio network node; and a processor and a memory, said memory comprising instructions executable by the processor, whereby the processor is operative to mark a next ECN-capable user packet of said user traffic on said data radio bearer with ECN marking, based on said control information.

64. The receiving radio network node of claim 63, wherein said control information is in a Radio Link Control (RLC) Control Protocol Data Unit (PDU).

65. The receiving radio network node of claim 63, wherein said control information is in a Medium Access Control (MAC) control message.

66. The receiving radio network node of claim 63, wherein said user packet is an Internet Protocol (IP) packet.

67. The receiving radio network node of claim 63, wherein said wireless communication network is a Long Term Evolution (LTE) network.

68. The receiving radio network node of claim 63, wherein said receiving radio network node is a wireless communication device.

69. The receiving radio network node of claim 63, wherein said receiving radio network node is an eNodeB.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0024] The embodiments, together with further objects and advantages thereof, may best be understood by making reference to the following description taken together with the accompanying drawings, in which:

[0025] FIG. 1 is a schematic flow diagram illustrating an example of a method performed by a sending radio network node for supporting ECN marking of user traffic in a wireless communication network according to an embodiment.

[0026] FIG. 2 is a schematic flow diagram illustrating an example of a method performed by a receiving radio network node for ECN marking of user traffic in a wireless communication network according to an embodiment.

[0027] FIG. 3 is a schematic diagram illustrating an example of a sending radio network node configured to support ECN marking of user traffic in a wireless communication network according to an embodiment.

[0028] FIG. 4 is a schematic diagram illustrating an example of a receiving radio network node configured to mark user traffic in a wireless communication network with ECN marking according to an embodiment.

[0029] FIG. 5 is a schematic block diagram illustrating an example of a sending radio network node configured to support ECN marking of user traffic in a wireless communication network according to an alternative embodiment.

[0030] FIG. 6 is a schematic block diagram illustrating an example of a receiving radio network node configured to mark user traffic in a wireless communication network with ECN marking according to an alternative embodiment.

[0031] FIG. 7 is an illustration of an example of a MAC sub-header according to prior art.

[0032] FIG. 8 is an illustration of an example of an ECN RLC Control PDU according to an embodiment.

[0033] FIG. 9 is a schematic diagram illustrating an example of an implementation in an LTE protocol stack in a sending radio network node according to an embodiment.

[0034] FIG. 10 is a schematic diagram illustrating an example of an implementation in an LTE protocol stack in a receiving radio network node according to an embodiment.

[0035] FIG. 11 is an illustration of an example of an ECN MAC Control Element according to an embodiment.

[0036] FIG. 12 is an example simulation illustrating a possible improvement in congestion control using the proposed embodiments.

[0037] FIG. 13 is another example simulation illustrating a possible improvement in congestion control using the proposed embodiments.

DETAILED DESCRIPTION

[0038] Throughout the drawings, the same reference numbers are used for similar or corresponding elements.

[0039] When using the word “comprise” or “comprising” it shall be interpreted as non-limiting, i.e. meaning “consist at least of”.

[0040] As mentioned in the background above, ECN in LTE is specified in 3GPP TS 36.300 [Ref. 1]. The specification is however not detailed and does for instance not indicate how the ECN marking decision is applied to the IP packets. This has natural causes as the ECN marking functionality can be located on different places in the protocol stack depending on vendor preferences.

[0041] In cases where the IP packets are queued up as Radio Link Control (RLC) Service Data Units (SDUs) and the ECN marking decision is done below the Packet Data Convergence Protocol (PDCP) layer processing it becomes difficult to apply ECN marking on the IP packets as these are ciphered by the PDCP processing. The solution to this is to indicate to the PDCP layer that the next incoming IP packet should be ECN-CE marked.

[0042] The problem with such a solution is that packets are potentially ECN-CE marked in the tail of the packet stream and this can delay the congestion indications to the endpoints. Another potential issue is that the indication from the RLC layer processing to the PDCP layer processing can give an increased signaling load in the computer hardware, which may impose a restriction on how often ECN marking can be applied, making novel TCP versions like Data Center TCP (DCTCP) [Ref. 3] difficult to support.

[0043] The concept of the currently proposed invention is to signal congestion to a receiver by transmitting control information indicating that traffic congestion has occurred. The receiver will then convert that control information into ECN marking of the user traffic. ECN marking is thus done in a head of queue manner, avoiding the issues described above.

[0044] Two examples of implementation, one that is based on Radio Link Control (RLC) layer control and one that is based on Medium Access Control (MAC) layer control, will be described in detail below. There may of course also be other alternatives for implementing the proposed embodiments. The conceptual benefits with forward ECN marking will be described, compared to the alternatives possible with state of the art technology.

[0045] The proposed embodiments are mainly described in the context of an LTE network, but may also be applied to other types of wireless communication networks.

[0046] For a better understanding of the proposed technology, it may be useful to begin with a brief overview of some background technology, described with reference to some non-limiting examples.

[0047] RLC Layer Control

[0048] An RLC Control Protocol Data Unit (PDU) header always begins with half a byte of data, consisting of one bit Data/Control (D/C) set to 0 and a three-bit Control PDU Type (CPT) field. The CPT defines the type of Control PDU.

[0049] Table 1 shows values used by 3GPP LTE. LCID=Logical Channel ID.

TABLE-US-00001 TABLE 1 RLC Control PDU Types Index LCID values size 000 STATUS PDU variable 001-111 Reserved for future needs N/A

[0050] MAC Layer Control

[0051] A MAC PDU sub-header for fixed sized MAC Control Elements (CE) consists of the four header fields R/R/E/LCID, as shown in FIG. 7. R=Reserved bits, E=Extension bits, LCID=Logical Channel ID. The LCID defines the type of CE.

[0052] Table 2 and Table 3 show values used for 3GPP LTE for Downlink Shared Channel (DL-SCH) and Uplink Shared Channel (UL-SCH). UE=User Equipment, DRX=Discontinuous Reception, C-RNTI=Cell Radio Network Temporary Identifier, BSR=Buffer Status Report.

TABLE-US-00002 TABLE 2 MAC Control Elements for DL-SCH Index LCID values Size 01011-11010 Reserved for future needs N/A 11011 Activation/Deactivation 1 11100 UE Contention Resolution Identity 6 11101 Timing Advance Command 1 11110 DRX Command 0

TABLE-US-00003 TABLE 3 MAC Control Elements for UL-SCH Index LCID values size 01011-11000 Reserved for future needs N/A 11001 Extended Power Headroom Report variable 11010 Power Headroom Report 1 11011 C-RNTI 2 11100 Truncated BSR 1 11101 Short BSR 1 11110 Long BSR 3

[0053] The MAC Control Element itself is coded in the payload part of the MAC PDU. Different sizes are used depending on the details of the particular control. In the simplest case, size is 0 and the function is already fully determined by the sub-header. The size of a MAC CE can also be variable.

[0054] FIG. 1 is a schematic flow diagram illustrating an example of a method performed by a sending radio network node for supporting ECN marking of user traffic in a wireless communication network. The method comprises the step S10 of monitoring a congestion metric on a data radio bearer. The method further comprises the step S20 of transmitting control information indicating traffic congestion on the same data radio bearer, based on the monitored congestion metric, to a receiving radio network node.

[0055] A congestion metric is a measure of the level of congestion on a data radio bearer. The congestion metric may for example be a measure of queue size or queue delay. In an example embodiment the congestion metric is an RLC buffer level. The term buffer level is generic and may represent e.g. the number of bytes or SDUs in the RLC buffer. In a particular embodiment the congestion metric is a user packet queuing delay, and may in an example embodiment be the time elapsed since the head SDU was inserted into the queue.

[0056] As an example, traffic congestion may be considered to have occurred when the congestion metric exceeds a certain threshold. Thus, in one embodiment, control information indicating traffic congestion is transmitted based on the congestion metric exceeding a given threshold.

[0057] The control information indicating traffic congestion may for example be transmitted to the receiver by adding dedicated elements into existing messages that carry the ECN marking to the receiver. According to an embodiment, which is based on RLC layer control, the control information is transmitted in an RLC Control Protocol Data Unit (PDU). According to an alternative embodiment, which is based on Medium Access Control (MAC) layer control, the control information is transmitted in a MAC control message, such as for example a MAC Control Element, or a particular Logical Channel ID (LCID) in the MAC sub-header, or similar. There may of course also be other alternatives for transmitting control information indicating traffic congestion.

[0058] FIG. 2 is a schematic flow diagram illustrating an example of a method performed by a receiving radio network node for ECN marking of user traffic in a wireless communication network. The method comprises the step S100 of receiving control information indicating traffic congestion on a data radio bearer, based on a congestion metric, from a sending radio network node. The method further comprises the step S200 of marking next ECN-capable user packet of the user traffic on the same data radio bearer with ECN marking, based on the received control information.

[0059] An ECN-capable user packet may in one embodiment be an IP packet that is ECN capable (ECT).

[0060] As described above, the proposed embodiments may be implemented using RLC layer control, and thus the control information may in one embodiment be received in an RLC Control PDU. Alternatively, the proposed embodiments may be implemented using MAC layer control, and thus the control information may in an alternative embodiment be received in a MAC control message, such as for example a MAC Control Element, or a particular LCID in the MAC sub-header, or similar. There may of course also be other alternatives for receiving control information indicating traffic congestion.

[0061] In the following, some non-limiting examples of illustrative embodiments are described.

[0062] RLC Layer Control

[0063] In an example embodiment, an ECN RLC Ctrl PDU is generated whenever an ECN marking decision is made. In a particular embodiment, the size of the ECN Ctrl PDU is 1 byte and its disposition is according to FIG. 8.

[0064] The use of the reserved bits is to be decided. In one embodiment they can be used to indicate a queue size or queue delay, quantized to 16 levels.

[0065] FIG. 9 shows the functionality deployed in the LTE protocol stack in a sending radio network node according to an embodiment.

[0066] In this embodiment, the RLC buffer level is monitored in the RLC layer processing. The term buffer level is generic and can for example depict either the number of bytes, SDUs, segments of SDUs, PDUs or portions of PDUs in the RLC buffers. In a preferred embodiment the level is given by the queuing delay i.e. the time elapsed since the head SDU was inserted into the queue.

[0067] In this embodiment, an ECN RLC Ctrl PDU is created if the two conditions below are satisfied: [0068] 1. An RLC data PDU is transmitted, this also includes retransmission of RLC PDUs, and [0069] 2. The RLC buffer level exceeds a given threshold

[0070] The created ECN RLC Ctrl PDU is transmitted, preferably with a higher priority than the RLC SDUs.

[0071] FIG. 10 shows the functionality deployed in the LTE protocol stack in a receiving radio network node according to an embodiment.

[0072] In this embodiment, the following steps are taken when an ECN Ctrl PDU is detected at the RLC layer: [0073] 1. A notification is sent to the PDCP layer [0074] 2. In PDCP layer processing upon de-capsulation of PDCP PDU, the de-capsulated IP packet is ECN-CE marked if: [0075] a. The IP packet is ECN capable (ECT), and [0076] b. A new ECN notification has been received from the RLC layer processing

[0077] Table 4 shows how received ECN Ctrl PDUs are translated to ECN marking in IP header in PDCP processing.

[0078] MAC Layer Control

[0079] The MAC Control Element contains the same elements of information as the RLC Ctrl PDU. Furthermore the processing is similar to above. In a proposed embodiment, a new LCID is needed for the new ECN MAC Control Element sent over the DL-SCH and UL-SCH channels, as exemplified below by updating the table 6.2.1-1 and 6.2.1-2 in the 36.321 MAC spec. For convenience, the same reserved LCID value is shown for both UL and DL control elements. CCCH=Common Control Channel.

[0080] A MAC Control element itself can either be without a body and have zero size, or it can have a body including similar information as for the RLC control PDU. An example of an ECN MAC Control Element according to an embodiment is depicted in FIG. 11.

[0081] The example in FIG. 11 shows an ECN MAC Control Element which has 6 bits that can be used to indicate a queue size or queue delay, quantized to 64 levels, and 2 spare bits marked with the R character.

[0082] In an example of an implementation, at least some of the steps, functions, procedures, modules and/or blocks described herein are implemented in a computer program, which is loaded into the memory for execution by processing circuitry including one or more processors. The processor(s) and memory are interconnected to each other to enable normal software execution. An optional input/output device may also be interconnected to the processor(s) and/or the memory to enable input and/or output of relevant data such as input parameter(s) and/or resulting output parameter(s).

[0083] The embodiments herein may thus be implemented through one or more processors, such as a processor in the sending radio network node depicted in FIG. 3, or the processor in the receiving radio network node depicted in FIG. 4, together with computer program code for performing the functions and actions of the embodiments herein.

[0084] According to an embodiment, a sending radio network node is configured to support ECN marking of user traffic in a wireless communication network. The sending radio network node is configured to monitor a congestion metric on a data radio bearer, and to transmit control information indicating traffic congestion on the same data radio bearer, based on the monitored congestion metric, to a receiving radio network node.

[0085] In an example embodiment the congestion metric is an RLC buffer level. In another example embodiment the congestion metric is a user packet queuing delay.

[0086] In one embodiment, the sending radio network node is configured to transmit control information indicating traffic congestion based on the congestion metric exceeding a given threshold.

[0087] In one embodiment the sending radio network node is configured to transmit control information indicating traffic congestion in an RLC Control PDU. In an alternative embodiment the sending radio network node is configured to transmit control information indicating traffic congestion in a MAC control message.

[0088] FIG. 3 is a schematic diagram illustrating an example of a sending radio network node 10 operative to support ECN marking of user traffic in a wireless communication network according to an embodiment. In this example, the sending radio network node 10 basically comprises a processor 11, an associated memory 12 and optional communication circuitry 13. The optional communication circuitry 13 is adapted for wireless and/or wired communication with one or more other nodes, including transmitting and/or receiving information.

[0089] As indicated in the specific example of FIG. 3, the sending radio network node 10 comprises a processor 11 and a memory 12, wherein the memory 12 comprises instructions executable by the processor 11 to perform operations of the sending radio network node 10. Thus, in this example embodiment the processor 11 is operative to monitor a congestion metric on a data radio bearer.

[0090] As indicated in FIG. 3, the sending radio network node 10 may also include communication circuitry 13 for communication with one or more other nodes, including transmitting and/or receiving information. Thus, in a particular embodiment the sending radio network node 10 comprises communication circuitry 13 configured to transmit control information indicating traffic congestion on the same data radio bearer, based on the monitored congestion metric, to a receiving radio network node.

[0091] According to an embodiment, a receiving radio network node is configured to mark user traffic in a wireless communication network with ECN marking. The receiving radio network node is configured to receive control information indicating traffic congestion on a data radio bearer, based on a congestion metric, from a sending radio network node, and to mark next ECN-capable user packet of the user traffic on the same data radio bearer with ECN marking, based on the received control information.

[0092] In one embodiment the receiving radio network node is configured to receive control information indicating traffic congestion in an RLC Control PDU. In an alternative embodiment the receiving radio network node is configured to receive control information indicating traffic congestion in a MAC control message.

[0093] In one embodiment the ECN-capable user packet is an IP packet that is ECN capable (ECT).

[0094] FIG. 4 is a schematic diagram illustrating an example of a receiving radio network node 20 operative to mark user traffic in a wireless communication network with ECN marking according to an embodiment. In this example, the receiving radio network node 20 basically comprises a processor 21, an associated memory 22 and optional communication circuitry 23. The optional communication circuitry 23 is adapted for wireless and/or wired communication with one or more other nodes, including transmitting and/or receiving information.

[0095] As indicated in the specific example of FIG. 4, the receiving radio network node may include communication circuitry 23 for communication with one or more other nodes, including transmitting and/or receiving information. Thus, in a particular embodiment the receiving radio network node 20 comprises communication circuitry 23 configured to receive control information indicating traffic congestion on a data radio bearer, based on a congestion metric, from a sending radio network node.

[0096] As indicated in FIG. 4, the receiving radio network node 20 comprises a processor 21 and a memory 22, wherein the memory 22 comprises instructions executable by the processor 21 to perform operations of the receiving radio network node 20. Thus, in this example embodiment the processor 21 is operative to mark next ECN-capable user packet of the user traffic on the same data radio bearer with ECN marking, based on the received control information.

[0097] In some of the proposed embodiments, the wireless communication network is a Long Term Evolution, LTE, network.

[0098] The proposed embodiments may be used for downlink (DL) traffic. In such an implementation, the sending radio network node may be a base station, such as an eNodeB in an embodiment, and the receiving radio network node may be a wireless communication device, such as for example a user equipment (UE) in an embodiment.

[0099] As an alternative, the proposed embodiments may however also be used for uplink (UL) traffic. In such an implementation, the sending radio network node may be a wireless communication device, such as for example a user equipment (UE) in an embodiment, and the receiving radio network node may be a base station, such as an eNodeB in an embodiment.

[0100] As described above, at least some of the steps, functions, procedures, modules and/or blocks described above may be implemented in software such as a computer program for execution by suitable processing circuitry including one or more processing units.

[0101] According to an embodiment, a computer program comprises instructions, which when executed by at least one processor, cause the processor(s) to monitor a congestion metric on a data radio bearer, and prepare control information indicating traffic congestion on the same data radio bearer, based on the monitored congestion metric, for transmitting to a receiving radio network node.

[0102] According to another embodiment, a computer program comprises instructions, which when executed by at least one processor, cause the processor(s) to read control information indicating traffic congestion on a data radio bearer, based on a congestion metric, where the control information is received from a sending radio network node, and mark next ECN-capable user packet of the user traffic on the same data radio bearer with ECN marking, based on the received control information.

[0103] The proposed technology also provides a carrier comprising one or more of the above computer programs, wherein the carrier is one of an electronic signal, an optical signal, an electromagnetic signal, a magnetic signal, an electric signal, a radio signal, a microwave signal, or a computer-readable storage medium.

[0104] By way of example, the software or computer program may be realized as a computer program product, which is normally carried or stored on a computer-readable medium, in particular a non-volatile medium. The computer-readable medium may include one or more removable or non-removable memory devices including, but not limited to a Read-Only Memory (ROM), a Random Access Memory (RAM), a Compact Disc (CD), a Digital Versatile Disc (DVD), a Blueray disc, a Universal Serial Bus (USB) memory, a Hard Disk Drive (HDD) storage device, a flash memory, a magnetic tape, or any other conventional memory device. The computer program may thus be loaded into the operating memory of a computer or equivalent processing device for execution by the processing circuitry thereof.

[0105] The flow diagram or diagrams presented above may be regarded as a computer flow diagram or diagrams, when performed by one or more processors. A corresponding radio network node may be defined as a group of function modules, where each step performed by the processor corresponds to a function module. In this case, the function modules are implemented as a computer program running on the processor. Hence, the radio network nodes may alternatively be defined as a group of function modules, where the function modules are implemented as a computer program running on at least one processor.

[0106] Hence, the computer program residing in memory may be organized as appropriate function modules configured to perform, when executed by the processor, at least part of the steps and/or tasks described herein. An example of such function modules is illustrated in FIGS. 5 and 6.

[0107] FIG. 5 is a schematic block diagram illustrating an example of a sending radio network node for supporting ECN marking of user traffic in a wireless communication network according to an alternative embodiment. The sending radio network node 10 in this example comprises a monitoring module 100 configured to monitor a congestion metric on a data radio bearer. The sending radio network node 10 further comprises a preparation module 200 configured to prepare control information indicating traffic congestion on the same data radio bearer, based on the monitored congestion metric, for transmitting to a receiving radio network node.

[0108] FIG. 6 is a schematic block diagram illustrating an example of a receiving radio network node for ECN marking of user traffic in a wireless communication network according to an alternative embodiment. The receiving radio network node 20 in this example comprises a reading module 120 configured to read control information indicating traffic congestion on a data radio bearer, based on a congestion metric, where the control information is received from a sending radio network node. The receiving radio network node 20 further comprises a marking module 220 configured to mark next ECN-capable user packet of the user traffic on the same data radio bearer with ECN marking, based on the received control information.

[0109] The proposed embodiments enable more timely congestion signals to the endpoints and also makes it possible to support new ECN based congestion control algorithms that deviate from the behaviour depicted in RFC 3168 [Ref. 2].

EXAMPLE SIMULATIONS

[0110] A few examples of the possible improvement with head of queue ECN marking is shown below.

[0111] FIG. 12 shows an example trace for a file transfer with TCP Reno where ECN marking is done in the tail of the queue, or in the head of the queue by means of RLC Ctrl PDUs. The upper graph shows Congestion Window Size (CWND) and the lower graph shows TCP segment delay. It is clear from the lower graph that the head marking approach gives a much smaller overshoot during slow start. The head ECN marking gives a peak TCP segment delay of 200 ms at T=0.6 while the tail ECN marking gives a peak TCP segment delay higher than 400 ms. Thus the head ECN marking gives a much quicker reaction to congestion.

[0112] A similar experiment is run with Data Center TCP (DCTCP) [Ref. 3], see FIG. 13. DCTCP is a novel TCP version for Data Centers that base the CWND on the fraction of TCP segments that are ECN-CE marked. The DCTCP implementation in this experiment has a feature that avoids the slow start overshoot. Instead the benefit with head marking is seen around T=4.5 s and T=7.0 s. Head marking gives a quicker response to the increase in queuing delay and thus a smaller delay peak. For instance at T=7.0 s the head ECN marking gives a peak TCP segment delay of little more than 100 ms, while the tail ECN marking gives a peak TCP segment delay higher than 200 ms.

[0113] The lower peak delays is beneficial not only for the file transfers but also for other latency sensitive cross traffic over the same bearer, examples of which are online gaming traffic and Voice-over-Internet Protocol (VoIP).

[0114] As used herein, the non-limiting terms “User Equipment” and “wireless device” may refer to a mobile phone, a cellular phone, a Personal Digital Assistant, PDA, equipped with radio communication capabilities, a smart phone, a laptop or Personal Computer, PC, equipped with an internal or external mobile broadband modem, a tablet PC with radio communication capabilities, a target device, a device to device UE, a machine type UE or UE capable of machine to machine communication, iPAD, customer premises equipment, CPE, laptop embedded equipment, LEE, laptop mounted equipment, LME, USB dongle, a portable electronic radio communication device, a sensor device equipped with radio communication capabilities or the like. In particular, the term “UE” and the term “wireless device” should be interpreted as non-limiting terms comprising any type of wireless device communicating with a radio network node in a cellular or mobile communication system or any device equipped with radio circuitry for wireless communication according to any relevant standard for communication within a cellular or mobile communication system.

[0115] As used herein, the non-limiting term “radio network node” may refer to base stations, network control nodes such as network controllers, radio network controllers, base station controllers, and the like, as well as to wireless devices such as exemplified above. In particular, the term “base station” may encompass different types of radio base stations including standardized base stations such as Node Bs, or evolved Node Bs, (eNodeBs), and also macro/micro/pico radio base stations, home base stations, also known as femto base stations, relay nodes, repeaters, radio access points, base transceiver stations, BTSs, and even radio control nodes controlling one or more Remote Radio Units, RRUs, or the like.

[0116] It will be appreciated that the methods and devices described herein can be combined and re-arranged in a variety of ways.

[0117] For example, embodiments may be implemented in hardware, or in software for execution by suitable processing circuitry, or a combination thereof.

[0118] The steps, functions, procedures, modules and/or blocks described herein may be implemented in hardware using any conventional technology, such as discrete circuit or integrated circuit technology, including both general-purpose electronic circuitry and application-specific circuitry.

[0119] Particular examples include one or more suitably configured digital signal processors and other known electronic circuits, e.g. discrete logic gates interconnected to perform a specialized function, or Application Specific Integrated Circuits (ASICs).

[0120] Examples of processing circuitry includes, but is not limited to, one or more microprocessors, one or more Digital Signal Processors, DSPs, one or more Central Processing Units, CPUs, video acceleration hardware, and/or any suitable programmable logic circuitry such as one or more Field Programmable Gate Arrays, FPGAs, or one or more Programmable Logic Controllers, PLCs.

[0121] It should also be understood that it may be possible to re-use the general processing capabilities of any conventional device or unit in which the proposed technology is implemented. It may also be possible to re-use existing software, e.g. by reprogramming of the existing software or by adding new software components.

[0122] The term ‘processor’ should be interpreted in a general sense as any system or device capable of executing program code or computer program instructions to perform a particular processing, determining or computing task.

[0123] The processing circuitry including one or more processors is thus configured to perform, when executing the computer program, well-defined processing tasks such as those described above.

[0124] The processing circuitry does not have to be dedicated to only execute the above-described steps, functions, procedure and/or blocks, but may also execute other tasks.

[0125] The embodiments described above are merely given as examples, and it should be understood that the proposed technology is not limited thereto. It will be understood by those skilled in the art that various modifications, combinations and changes may be made to the embodiments without departing from the present scope as defined by the appended claims. In particular, different part solutions in the different embodiments can be combined in other configurations, where technically possible.

REFERENCES

[0126] [1] 3GPP TS 36.300 v12.0.0 section 11.6 [0127] [2] RFC 3168 “The Addition of Explicit Congestion Notification (ECN) to IP” [0128] [3] M. Alizadeh et al. “Data Center TCP (DCTCP)”, SIGCOMM'10, Aug. 30-Sep. 3, 2010, New Delhi, India