WO2008066429A1 - A method for improved handling of traffic congestion in a wireless telecommunications system - Google Patents
A method for improved handling of traffic congestion in a wireless telecommunications system Download PDFInfo
- Publication number
- WO2008066429A1 WO2008066429A1 PCT/SE2006/050510 SE2006050510W WO2008066429A1 WO 2008066429 A1 WO2008066429 A1 WO 2008066429A1 SE 2006050510 W SE2006050510 W SE 2006050510W WO 2008066429 A1 WO2008066429 A1 WO 2008066429A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- node
- function
- sub
- rbs
- interface
- Prior art date
Links
- 238000000034 method Methods 0.000 title claims abstract description 21
- 230000006870 function Effects 0.000 claims description 84
- 230000001413 cellular effect Effects 0.000 claims description 4
- 230000007423 decrease Effects 0.000 description 7
- 239000000872 buffer Substances 0.000 description 5
- 201000001718 Roberts syndrome Diseases 0.000 description 4
- 208000012474 Roberts-SC phocomelia syndrome Diseases 0.000 description 4
- 238000010586 diagram Methods 0.000 description 3
- 230000007246 mechanism Effects 0.000 description 3
- 230000003247 decreasing effect Effects 0.000 description 2
- 238000005001 rutherford backscattering spectroscopy Methods 0.000 description 2
- 230000005540 biological transmission Effects 0.000 description 1
- 230000003139 buffering effect Effects 0.000 description 1
- 230000001934 delay Effects 0.000 description 1
- 230000003111 delayed effect Effects 0.000 description 1
- 238000009434 installation Methods 0.000 description 1
- 238000012886 linear function Methods 0.000 description 1
- 238000005259 measurement Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000009467 reduction Effects 0.000 description 1
- 238000004088 simulation Methods 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/11—Identifying congestion
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/12—Avoiding congestion; Recovering from congestion
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/20—Traffic policing
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
- H04L47/2441—Traffic characterised by specific attributes, e.g. priority or QoS relying on flow classification, e.g. using integrated services [IntServ]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/25—Flow control; Congestion control with rate being modified by the source upon detecting a change of network conditions
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W28/00—Network traffic management; Network resource management
- H04W28/02—Traffic management, e.g. flow control or congestion control
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W28/00—Network traffic management; Network resource management
- H04W28/02—Traffic management, e.g. flow control or congestion control
- H04W28/0252—Traffic management, e.g. flow control or congestion control per individual bearer or channel
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W28/00—Network traffic management; Network resource management
- H04W28/02—Traffic management, e.g. flow control or congestion control
- H04W28/0289—Congestion control
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W28/00—Network traffic management; Network resource management
- H04W28/02—Traffic management, e.g. flow control or congestion control
- H04W28/10—Flow control between communication endpoints
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W28/00—Network traffic management; Network resource management
- H04W28/02—Traffic management, e.g. flow control or congestion control
- H04W28/10—Flow control between communication endpoints
- H04W28/12—Flow control between communication endpoints using signalling between network elements
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
- H04W88/12—Access point controller devices
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W92/00—Interfaces specially adapted for wireless communication networks
- H04W92/04—Interfaces between hierarchically different network devices
- H04W92/12—Interfaces between hierarchically different network devices between access points and access point controllers
Definitions
- a method for improved handling of traffic congestion in a wireless telecommunications system is provided.
- the present invention discloses a method for handling traffic congestion in a wireless telecommunications system which comprises at least a first node such as a Radio Base Station, RBS, and at least a second node such as a Radio Network Controller, RNC.
- the system is also able to comprise one or more users, UE.
- the RNC communicates with the RBS, and the RBS communicates with the users, so that there is a first interface, lub, between the RNC and the RBS, and a second interface, Uu, between the RBS and the UEs.
- the traffic in the system can comprise one or more so called flows.
- WCDMA Wideband Code Division Multiple Access
- RNC Wideband Code Division Multiple Access
- RBS sometimes also referred to as "Node B”
- UE there is a scheduling function in the RBS which is responsible for distributing the radio channel among the UEs with which the RBS communicates.
- the scheduler in the RNC determines, for each UE, the number of bits that can be transmitted to that particular UE during a predetermined period of time.
- both the RNC and the RBS have buffering capability, so that data which is to be transmitted to a UE is divided between the RNC and the RBS buffers.
- the RBS contains a buffer for every UE which it communicates with, these buffers usually being referred to as Priority Queues, PQs.
- PQs Priority Queues
- the traffic in the system can comprise a number of so called “flows", there usually being one flow for each PQ.
- the flow control should ensure that congestion on the lub is avoided, while at the same time trying to utilize the available lub bandwidth to a great extent.
- the flow control function should also guarantee a 'fair" sharing of the lub capacity among the flows.
- the flow control should ensure that the interface is fully utilized, which can be achieved by keeping the PQ level high enough.
- PQ levels should be kept as low as possible in order to decrease memory in the RBS, to minimize packet loss at handovers, and also to give re-transmitted data a low delay.
- a wireless telecommunications system which can comprise at least one first node such as a Radio Base Station, RBS, and at least one second node such as a Radio Network Controller, RNC, and which system is also able to comprise one or more users, UE.
- RBS Radio Base Station
- RNC Radio Network Controller
- the RNC communicates with the RBS, and the RBS communicates with the users, UEs, meaning that there is a first interface (lub) between the RNCs and the RBSs, and a second interface (Uu) between the RBSs and the UEs.
- lub first interface
- Uu second interface
- the traffic in the system can comprise one or more flows, which are intended to be controlled by the method of the invention.
- the method according to the invention comprises the use of one flow control function per each of said controlled flows.
- the flow control function comprises a first sub- function with an algorithm for handling congestion in the first interface, and a second sub-function with an algorithm for handling congestion in the second interface.
- the method of the invention utilizes one flow control function per flow, optimal flow control can be ensured for each flow.
- the flow control function is not only per flow, but can also comprises one algorithm for each of the two possible bottlenecks, the lub and Uu interfaces, the control function can be optimized for both cases, without the need for any compromises which could be caused by taking into consideration both cases simultaneously in one and the same function.
- the algorithm used by the first sub-function differs from the algorithm which is used by the second sub-function.
- the two sub-functions of the flow control function both have as their output a standard control frame in the system, which is sent to the RNC, and which contains information about how much traffic the RNC is allowed to send to the RBS for the specific flow which is controlled by that flow control function.
- only one of the two sub-functions can be active at one and the same time.
- the invention also discloses a node for use in a cellular telephony system with a function according to the invention.
- FIG. 1 shows a symbolic overview of a system in which the invention may be applied
- Fig 2 shows a schematic overview of a principle behind the invention
- Fig 3 shows a function for use in the invention
- Fig 4a and 4b show some advantages which can be gained by means of the invention.
- a system 100 is schematically shown in which the invention can be applied.
- the system 100 will be described below as being a cellular telephony system of the WCDMA type, but it should be understood that this is as an example only, the invention may be applied in other kinds of cellular telephony systems as well.
- the system 100 comprises a number of so called cells, in which there may be a number of users, referred to as UE, User Equipment, shown as 150 in fig 1.
- UE User Equipment
- the system also comprises a number of nodes referred to as Radio Base Stations, RBS, shown as 130 in fig 1.
- RBS Radio Base Stations
- One of the roles of the RBS 130 is that for each cell, one RBS 130 monitors and controls traffic to and from the UEs 150 in the cell.
- the interface between the RBS 130 and the UE 150 is referred to as the Uu interface, shown as 140 in fig 1.
- the Uu interface 140 thus also becomes the interface for the UEs towards the rest of the system 100.
- the system 100 also comprises a node on "the next level" as seen from the RBS 130, said node being the Radio Network Controller, RNC, shown as 110 in fig 1.
- RNC Radio Network Controller
- One role of the RNC 110 is to carry out control of the RBS 130.
- the interface between the RNC 110 and the RBS 130 is referred to as the lub interface, shown as 125 in fig 1.
- Traffic between the RBS and the RNC is conveyed on a Transport Network, TN, shown as 120 in fig 1.
- TN Transport Network
- the system 100 needs to have some sort of control function for the traffic to and from the RBS 130, both the traffic between the RBS 130 and the RNC 110, i.e. the traffic on the lub interface, and the traffic on the Uu interface, i.e. the traffic between the RBS 130 and the UE 150.
- One of the tasks of such a control function is to detect and avoid congestion on the Iu and Uu interfaces.
- the RBS 130 contains one or more buffers for every UE, usually referred to as Priority Queues, PQs.
- PQs Priority Queues
- the traffic to and from each UE can be divided into so called flows, and in the example given here, there is one PQ in the RBS for each flow. In other applications, it could be possible to use more than one flow per PQ, or conversely, more than one PQ per flow.
- a flow control function which is responsible for controlling the data flows between the RNC 110 and the RBS 130, and in more detail, the function is intended to control flows from the RNC to the RBS, the so called down-link direction.
- the flow control function of the invention operates in a per flow manner, meaning that a separate instance of the flow control function is assigned to each PQ.
- the flow control function of the invention comprises a first sub-function with an algorithm for handling congestion in the lub interface, and a second sub-function with an algorithm for handling congestion in the Uu interface.
- a principle behind the invention is thus to introduce a flow control function which comprises two parts or sub-algorithms: one which can effectively handle the case when the lub interface is the bottleneck, and another which can effectively handle the case when the Uu interface is the bottleneck.
- CA Capacity Allocation frame
- a mechanism must be introduced for deciding, at any given point in time, which of the interfaces, the lub or the Uu, that limits, i.e. is the actual bottleneck in the system. Based on this decision, the flow control function will choose one of the two sub-algorithms to produce the CA message to the RNC.
- fig 2 schematically shows the flow control function 200 of the invention.
- the flow control function 200 of the invention is located in the RBS 130, for which reason the flow control function 200 is shown in fig 2 as being located inside "the box" 130.
- the flow control function 200 comprises one "bottleneck handler" for each of the interfaces.
- the flow control function 200 comprises one "bottleneck handler” for each of the interfaces.
- the lub handler 210 uses as input data lub bottleneck information 211
- the Uu handler 220 has as its input data Uu bottleneck information 221.
- the output from the bottleneck handlers 210, 220 is used as input to a bottleneck algorithm selector 230, which is a function that chooses which of the two bottleneck handlers 210, 220. that should be allowed to produce the output from the flow control function 200.
- the output of the flow control function 200 is, as mentioned previously, the CA frame to the RNC, which tells the RNC how much data it is allowed to send on the flow which is controlled by the function 200.
- the selector 230 can work in a number of ways, but in a preferred embodiment, the function of the selector is as follows: If there is no congestion on one of the interfaces for a certain predefined interval, the handler for the other interface is allowed to regulate the data flow, i.e. decide the contents of the CA. In other words, one of the handlers 210, 220, is defined as always being active unless the other one has congestion during the predefined interval.
- this is designed to work as follows: If there is no congestion on the lub interface for a predefined interval of, for example, 10 seconds, then the Uu bottleneck handler 220 is selected to regulate the flow, otherwise the lub bottleneck handler 210 is selected to regulate the flow.
- the choice of function for the selector 230 is suitably decided for each system or installation based on experimental data such as simulations, or on experience.
- this input is data which enables the bottleneck handlers to see if there is any congestion on their respective interfaces.
- This data can be in a variety of forms, such as, for example, data on lost frames, destroyed frames or delayed frames over the interface in question.
- the function of the lub bottleneck handler 210 is as follows: If the congestion on the lub results in packet loss, the RLC (Radio Link Control) protocol will retransmit the affected packets. These retransmissions can cause large delays, because the retransmitted packets will also have to wait in the transport network buffer again, which can cause much larger round trip times, RTT, in the system. Therefore, there is a need for a "conservative" flow control algorithm for the lub interface, but which can still avoid loss in the transport network.
- RLC Radio Link Control
- the lub bottleneck handler 210 use is made of an exponential decrease function together with a linear increase function.
- the exact rate of the exponential function as well as that of the linear function is suitably determined from case to case, depending on the application in question.
- lub bottleneck handler 210 can also be envisioned for the lub bottleneck handler 210, such as, for example, step functions, i.e. functions with a more or less instantaneous cut-off.
- the function of the Uu bottleneck handler 220 is as follows: a principle in this context is that if the length (in time) of the PQ in the RBS, referred to as pqt, is larger than a certain predefined limit, the function 220 decreases the bit rate factor in the CA, referred to as caBitrate, and if pqt is below a certain predefined threshold, the function 220 increases the caBitrate.
- the flow control function can react very fast to changes in Uu conditions, e.g. if the Uu rate of a PQ increases suddenly, the pqt will decrease, and the flow control will increase the caBitrate based on the measured pqt, and vice versa.
- the Uu bottleneck handler 220 is more "aggressive" than the linear increase method used by the lub handler 210.
- the function of the Uu handler 220 in a preferred embodiment is as follows: use is made of a transfer function with a variable referred to as pqtCoeff which will be explained in more detail in the following, but which transfer function contains a "boosting part". Short pqts will boost the CA bit rate if no lub congestion is present, and long pqts will lead to a reduction of the CA bit rate, regardless of whether or not lub congestion is present.
- the caBitrate will be increased, and in this case the Uu handler 220 will, in a preferred embodiment, wait for a given amount of arrived data between each increase.
- the amount of data which is awaited is calculated as a product of a time limit and the variable caBitrate, for example 400ms x caBitrate.
- the transfer function used by the Uu bottleneck handler 220 which makes use of the variable pqtCoeff, is illustrated in fig 3. It should be pointed out that the transfer function shown in fig 3 is merely one example of a transfer function which has proven to give good results, other transfer functions can also be used without departing from the scope of the present invention.
- Fig 3 shows a diagram 300 with the variable pqtCoeff as a function of the pqt, i.e. the waiting time in the PQ of the flow which is controlled by the flow control function.
- One way of determining the pqt is to use the length of the PQ in bits, which is a known factor, and to also use the average serving rate of the PQ, which is also known and depends on, inter alia, the Uu conditions. The pqt can then be calculated as the PQ in bits divided by the serving rate of the PQ.
- variable pqtCoeff is then determined from the pqt using the transfer function 310 shown in fig 3.
- this particular transfer function makes use of four points, shown as Ci, C 2 , C 3 and C 4 , which thus create four "areas" in the diagram.
- the flow control function 200 simply uses the function shown in the diagram 300, and finds the point on the function 310 which corresponds to that pqt value, and the corresponding pqtCoeff value is found on the vertical axis. This value is then used for determining the caBitrate according to [1] above.
- the function 310 shown in fig 3 is merely an example of a transfer function which may be used in the invention, and has proven to give good results without being overly complicated. Other transfer functions may also be used without departing form the scope of the invention.
- Curve 410 shows the maximum available bottleneck utilization when only using an lub bottleneck handler.
- Curve 420 shows the maximum achievable bottleneck utilization with the use of a universal algorithm, i.e. one and the same algorithm for lub and Uu.
- Curve 430 shows the maximum achievable bottleneck utilization with the use of only a Uu bottleneck handler.
- the node which has been exemplified above and in the drawings as a Radio Base Station, RBS, or Node B in a 3G system can according to the invention be a node for use in many wireless telecommunications systems which systems can comprise at least one user, UE, and which comprise a hierarchy of nodes above the UE, with the node of the invention being intended to be the first node in the system, i.e. the node which is the closest to the UE, and in which system there is also a second node above the first node, where the first node is equipped with means for communicating with the second node and also with the UE.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
The invention discloses a method for handling traffic congestion in a wireless telecommunications system (100) which comprises a first node such as a Radio Base Station, RBS, and a second node such as a Radio Network Contrailer, RNC, and one or more users, UE. The RNC (110) communicates with the RBS (130), and the RBS communicates with the UEs (150), so that there is a first interface (125) between the RNCs and the RBS's, and a second interface (140) between the RBS's and the UEs. The traffic can comprise one or more flows which can be controlled by the method, the method comprising the use of one flow control function (200) per each of said flows. The flow control function (200) comprises a first sub-function (210) with an algorithm for handling congestion in the first interface (125), and a second sub-function (220) with an algorithm for handling congestion in the second interface (140).
Description
TITLE
A method for improved handling of traffic congestion in a wireless telecommunications system.
TECHNICAL FIELD
The present invention discloses a method for handling traffic congestion in a wireless telecommunications system which comprises at least a first node such as a Radio Base Station, RBS, and at least a second node such as a Radio Network Controller, RNC. The system is also able to comprise one or more users, UE.
In the system in which the invention is intended to be applied, the RNC communicates with the RBS, and the RBS communicates with the users, so that there is a first interface, lub, between the RNC and the RBS, and a second interface, Uu, between the RBS and the UEs. The traffic in the system can comprise one or more so called flows.
BACKGROUND
In some wireless telecommunication systems of the Wideband Code Division Multiple Access (WCDMA) kind which comprise the components described above, i.e. RNC, RBS (sometimes also referred to as "Node B") and UE, there is a scheduling function in the RBS which is responsible for distributing the radio channel among the UEs with which the RBS communicates.
Based on the UEs' measurements on the radio channel, which are reported to this function in the RBS, and also based on the available bits in the RBS and other factors, the scheduler in the RNC determines, for each UE, the number of bits that can be transmitted to that particular UE during a predetermined period of time.
In one embodiment of the WCDMA system, both the RNC and the RBS have buffering capability, so that data which is to be transmitted to a UE is divided between the RNC and the RBS buffers.
The RBS contains a buffer for every UE which it communicates with, these buffers usually being referred to as Priority Queues, PQs. The traffic in the system can comprise a number of so called "flows", there usually being one flow for each PQ.
To achieve a good system performance, i.e. good throughput, there is a need for a function which is responsible for controlling the data flows between the RNC and the RBS.
There are two possible bottlenecks in the system: the lub (RNC-RBS) interface and the Uu (RBS-UE) interface. Known flow control solutions use a universal control law which handles both of these bottlenecks.
If the lub interface is the bottleneck in the system, the flow control should ensure that congestion on the lub is avoided, while at the same time trying to utilize the available lub bandwidth to a great extent. The flow control function should also guarantee a 'fair" sharing of the lub capacity among the flows.
If the Uu interface is the bottleneck, the flow control should ensure that the interface is fully utilized, which can be achieved by keeping the PQ level high enough. On the other hand, in this case the, PQ levels should be kept as low as possible in order to decrease memory in the RBS, to minimize packet loss at handovers, and also to give re-transmitted data a low delay.
In lub limited case, the flow control has to guarantee the fair share of capacity among flows, while in the Uu limited case, the Uu scheduler itself guarantees the fair share of Uu capacity among the flows.
As can be seen, the objects of the two different bottleneck (lub/Uu) cases are quite different.
SUMMARY
As has been explained above, there is a need for a flow control function in a wireless telecommunication system, such as the WCDMA system, which can handle congestion on either of said two interfaces in a manner which is more satisfactory than previously known such control functions.
This need is addressed by the present invention in that it discloses a method for handling traffic congestion in a wireless telecommunications system which can comprise at least one first node such as a Radio Base Station, RBS, and at least one second node such as a Radio Network Controller, RNC, and which system is also able to comprise one or more users, UE.
In the system in which the invention can be applied, the RNC communicates with the RBS, and the RBS communicates with the users, UEs, meaning that there is a first interface (lub) between the RNCs and the RBSs, and a second interface (Uu) between the RBSs and the UEs.
As mentioned previously, the traffic in the system can comprise one or more flows, which are intended to be controlled by the method of the invention. The method according to the invention comprises the use of one flow control function per each of said controlled flows.
It should be pointed out that all flows in a system in which the invention is applied may not be controlled by a flow control function of the invention, depending on the specific application. Thus, the term "flow controlled flows" has been used above, to indicate this fact.
In a preferred embodiment, the flow control function comprises a first sub- function with an algorithm for handling congestion in the first interface, and a second sub-function with an algorithm for handling congestion in the second interface.
Thus, since the method of the invention utilizes one flow control function per flow, optimal flow control can be ensured for each flow. In addition, since the flow control function is not only per flow, but can also comprises one algorithm for each of the two possible bottlenecks, the lub and Uu interfaces, the control function can be optimized for both cases, without the need for any compromises which could be caused by taking into consideration both cases simultaneously in one and the same function.
Suitably but not necessarily, the algorithm used by the first sub-function differs from the algorithm which is used by the second sub-function.
Preferably, the two sub-functions of the flow control function both have as their output a standard control frame in the system, which is sent to the RNC, and which contains information about how much traffic the RNC is allowed to send to the RBS for the specific flow which is controlled by that flow control function.
In a particular embodiment of the invention, only one of the two sub-functions can be active at one and the same time.
The invention also discloses a node for use in a cellular telephony system with a function according to the invention.
BRIEF DESCRIPTION OF THE DRAWINGS
The invention will be described in more detail in the following, with reference to the appended drawings, in which
Fig 1 shows a symbolic overview of a system in which the invention may be applied, and
Fig 2 shows a schematic overview of a principle behind the invention, and
Fig 3 shows a function for use in the invention, and
Fig 4a and 4b show some advantages which can be gained by means of the invention.
DETAILED DESCRIPTION
In fig 1 , a system 100 is schematically shown in which the invention can be applied. The system 100 will be described below as being a cellular telephony system of the WCDMA type, but it should be understood that this is as an example only, the invention may be applied in other kinds of cellular telephony systems as well.
The system 100 comprises a number of so called cells, in which there may be a number of users, referred to as UE, User Equipment, shown as 150 in fig 1.
The system also comprises a number of nodes referred to as Radio Base Stations, RBS, shown as 130 in fig 1. One of the roles of the RBS 130 is that for each cell, one RBS 130 monitors and controls traffic to and from the UEs 150 in the cell.
The interface between the RBS 130 and the UE 150 is referred to as the Uu interface, shown as 140 in fig 1. As can be realized, the Uu interface 140 thus also becomes the interface for the UEs towards the rest of the system 100.
The system 100 also comprises a node on "the next level" as seen from the RBS 130, said node being the Radio Network Controller, RNC, shown as 110 in fig 1. One role of the RNC 110 is to carry out control of the RBS 130.
The interface between the RNC 110 and the RBS 130 is referred to as the lub interface, shown as 125 in fig 1. Traffic between the RBS and the RNC is conveyed on a Transport Network, TN, shown as 120 in fig 1.
With reference to fig 1 , it will be appreciated that the system 100 needs to have some sort of control function for the traffic to and from the RBS 130, both the traffic between the RBS 130 and the RNC 110, i.e. the traffic on the lub interface, and the traffic on the Uu interface, i.e. the traffic between the RBS 130 and the UE 150. One of the tasks of such a control function is to detect and avoid congestion on the Iu and Uu interfaces.
As also explained initially, the RBS 130 contains one or more buffers for every UE, usually referred to as Priority Queues, PQs. The traffic to and from each UE can be divided into so called flows, and in the example given here, there is one PQ in the RBS for each flow. In other applications, it could be possible to use more than one flow per PQ, or conversely, more than one PQ per flow.
According to the invention, in order to achieve good system performance (throughput), a flow control function is suggested which is responsible for controlling the data flows between the RNC 110 and the RBS 130, and in more detail, the function is intended to control flows from the RNC to the RBS, the so called down-link direction.
The flow control function of the invention operates in a per flow manner, meaning that a separate instance of the flow control function is assigned to each PQ. In addition, the flow control function of the invention comprises a first sub-function with an algorithm for handling congestion in the lub interface, and a second sub-function with an algorithm for handling congestion in the Uu interface.
By switching between these sub-algorithms, for which a mechanism will also be described, a better overall performance can be obtained than with the use of a universal algorithm for both cases, since it will be possible to make the sub-algorithms more efficient for their respective cases, compared with a universal control algorithm.
A principle behind the invention is thus to introduce a flow control function which comprises two parts or sub-algorithms: one which can effectively handle the case when the lub interface is the bottleneck, and another which can effectively handle the case when the Uu interface is the bottleneck.
In a WCDMA network, there is a standard frame referred to as the Capacity Allocation frame, CA, which the RBS sends to the RNC. The contents of the CA message determine the maximum transmission rate at which the RNC may send data to the RBS. At any given time, in a system which uses the invention, one of the two sub-algorithms is selected to generate a CA to the RNC, due to the circumstances at that point in time.
Accordingly, a mechanism must be introduced for deciding, at any given point in time, which of the interfaces, the lub or the Uu, that limits, i.e. is the actual bottleneck in the system. Based on this decision, the flow control function will choose one of the two sub-algorithms to produce the CA message to the RNC.
This mechanism for choosing the proper sub-algorithm is shown in fig 2, which schematically shows the flow control function 200 of the invention. Suitably, the flow control function 200 of the invention is located in the RBS 130, for which reason the flow control function 200 is shown in fig 2 as being located inside "the box" 130.
As shown in fig 2, the flow control function 200 comprises one "bottleneck handler" for each of the interfaces. Thus, there is one "bottleneck handler"
210 for the lub interface and one "bottleneck handler" 220 for the Uu interface. The lub handler 210 uses as input data lub bottleneck information 211 , and the Uu handler 220 has as its input data Uu bottleneck information 221.
The output from the bottleneck handlers 210, 220, is used as input to a bottleneck algorithm selector 230, which is a function that chooses which of the two bottleneck handlers 210, 220. that should be allowed to produce the output from the flow control function 200. The output of the flow control function 200 is, as mentioned previously, the CA frame to the RNC, which tells the RNC how much data it is allowed to send on the flow which is controlled by the function 200.
The selector 230 can work in a number of ways, but in a preferred embodiment, the function of the selector is as follows: If there is no congestion on one of the interfaces for a certain predefined interval, the handler for the other interface is allowed to regulate the data flow, i.e. decide the contents of the CA. In other words, one of the handlers 210, 220, is defined as always being active unless the other one has congestion during the predefined interval.
In a preferred embodiment of the invention, this is designed to work as follows: If there is no congestion on the lub interface for a predefined interval of, for example, 10 seconds, then the Uu bottleneck handler 220 is selected to regulate the flow, otherwise the lub bottleneck handler 210 is selected to regulate the flow.
However, this is merely an example of how the algorithm selection is carried out, it is also possible to envision an embodiment in which neither selector is active unless certain criteria are fulfilled, or, for example, the lub bottleneck handler can be the one that is always active. The choice of function for the selector 230 is suitably decided for each system or installation based on experimental data such as simulations, or on experience.
Turning now to the input 211 , 221 , to the bottleneck handlers 210, 220, this input is data which enables the bottleneck handlers to see if there is any congestion on their respective interfaces. This data can be in a variety of forms, such as, for example, data on lost frames, destroyed frames or delayed frames over the interface in question.
Next, the respective function of the two bottleneck handlers 210, 220, will be described.
The function of the lub bottleneck handler 210 is as follows: If the congestion on the lub results in packet loss, the RLC (Radio Link Control) protocol will retransmit the affected packets. These retransmissions can cause large delays, because the retransmitted packets will also have to wait in the transport network buffer again, which can cause much larger round trip times, RTT, in the system. Therefore, there is a need for a "conservative" flow control algorithm for the lub interface, but which can still avoid loss in the transport network.
Based on this and other requirements, in a preferred embodiment of the invention, in the lub bottleneck handler 210 use is made of an exponential decrease function together with a linear increase function. The exact rate of the exponential function as well as that of the linear function is suitably determined from case to case, depending on the application in question.
Apart from purely exponential functions, other non-linear decrease functions can also be envisioned for the lub bottleneck handler 210, such as, for example, step functions, i.e. functions with a more or less instantaneous cut-off.
The function of the Uu bottleneck handler 220 is as follows: a principle in this context is that if the length (in time) of the PQ in the RBS, referred to as pqt, is larger than a certain predefined limit, the function 220 decreases the bit
rate factor in the CA, referred to as caBitrate, and if pqt is below a certain predefined threshold, the function 220 increases the caBitrate.
Due to the principle behind the Uu handler function 220, as described above, the flow control function can react very fast to changes in Uu conditions, e.g. if the Uu rate of a PQ increases suddenly, the pqt will decrease, and the flow control will increase the caBitrate based on the measured pqt, and vice versa. Thus, the Uu bottleneck handler 220 is more "aggressive" than the linear increase method used by the lub handler 210.
In more detail, the function of the Uu handler 220 in a preferred embodiment is as follows: use is made of a transfer function with a variable referred to as pqtCoeff which will be explained in more detail in the following, but which transfer function contains a "boosting part". Short pqts will boost the CA bit rate if no lub congestion is present, and long pqts will lead to a reduction of the CA bit rate, regardless of whether or not lub congestion is present.
According to the transfer function which is used for boosting and reducing the CA bit rate, the variable caBitrate is calculated using the variable pqtCo- eff as follows: caBitrate = caBitrate * pqtCoeff [1]
As will be explained in more detail with reference to fig 3, if pqtCoeff is smaller than 1 , the caBitrate will be decreased, but there will suitably be a waiting period between each decrease. This means that if the bit rate can only be decreased once per each such period. A value of this period which has proven useful is 400 ms, although other values can of course also be used.
If pqtCoeff is larger than 1 the caBitrate will be increased, and in this case the Uu handler 220 will, in a preferred embodiment, wait for a given amount of arrived data between each increase. Suitably, the amount of data which is
awaited is calculated as a product of a time limit and the variable caBitrate, for example 400ms x caBitrate. Thus, in the case of increase, there is a "limiting timer", and in the case of decrease there is a "bit-counter", both of which are intended to guard against too many modifications within a short period of time.
The transfer function used by the Uu bottleneck handler 220, which makes use of the variable pqtCoeff, is illustrated in fig 3. It should be pointed out that the transfer function shown in fig 3 is merely one example of a transfer function which has proven to give good results, other transfer functions can also be used without departing from the scope of the present invention.
Fig 3 shows a diagram 300 with the variable pqtCoeff as a function of the pqt, i.e. the waiting time in the PQ of the flow which is controlled by the flow control function. One way of determining the pqt is to use the length of the PQ in bits, which is a known factor, and to also use the average serving rate of the PQ, which is also known and depends on, inter alia, the Uu conditions. The pqt can then be calculated as the PQ in bits divided by the serving rate of the PQ.
The variable pqtCoeff is then determined from the pqt using the transfer function 310 shown in fig 3. As can be seen from fig 3, this particular transfer function makes use of four points, shown as Ci, C2, C3 and C4, which thus create four "areas" in the diagram.
When pqt has been determined, the flow control function 200 simply uses the function shown in the diagram 300, and finds the point on the function 310 which corresponds to that pqt value, and the corresponding pqtCoeff value is found on the vertical axis. This value is then used for determining the caBitrate according to [1] above.
It should again be pointed out that the function 310 shown in fig 3 is merely an example of a transfer function which may be used in the invention, and has proven to give good results without being overly complicated. Other transfer functions may also be used without departing form the scope of the invention.
Finally, figs 4a and 4b show advantages which may be gained using the present solution.
In fig 4a, three different curves 410, 420, 430, are shown, which illustrate the following:
• Curve 410 shows the maximum available bottleneck utilization when only using an lub bottleneck handler.
• Curve 420 shows the maximum achievable bottleneck utilization with the use of a universal algorithm, i.e. one and the same algorithm for lub and Uu.
• Curve 430 shows the maximum achievable bottleneck utilization with the use of only a Uu bottleneck handler.
In fig 4b, two curves 420, 440 are shown, which illustrate the following:
• 420 is the same as the curve 420 from fig 4a, and thus shows the maximum achievable bottleneck utilization with the use of a universal algorithm, i.e. one and the same algorithm for lub and Uu.
• 440 shows the maximum achievable bottleneck utilization when switching between an lub and an Uu bottleneck handler, as proposed by the present invention.
As can be seen, significant advantages can be gained by means of separate lub and Uu bottleneck handlers, as disclosed by the present invention.
The invention is not limited to the examples given above, but may be freely varied within the scope of the appended patent claims.
Thus, the node which has been exemplified above and in the drawings as a Radio Base Station, RBS, or Node B in a 3G system, can according to the invention be a node for use in many wireless telecommunications systems which systems can comprise at least one user, UE, and which comprise a hierarchy of nodes above the UE, with the node of the invention being intended to be the first node in the system, i.e. the node which is the closest to the UE, and in which system there is also a second node above the first node, where the first node is equipped with means for communicating with the second node and also with the UE.
Also, it should be pointed out that although the invention discloses flow control with one control function per flow, there may be flows in the system which are not subjected to such control. It is in order to highlight this that some of the appended claims contain the expression of "one flow control per each controlled flow".
Claims
1. A method for handling traffic congestion in a wireless telecommunications system (100), said wireless system comprising at least one first node such as a Radio Base Station, RBS, and at least one second node such as a Radio Network Controller, RNC, the system (100) also being able to comprise one or more users, UE, in which system the RNC (110) communicates with the RBS (130), and the RBS communicates with the UE (150), so that there is a first interface (125) between the RNC and the RBS, and a second interface (140) between the RBS and the UE, in which system (100) the traffic can comprise one or more flows which can be controlled by the method, the method being characterized in that it comprises the use of one flow control function (200) per each of said controlled flows.
2. The method of claim 1 , according to which the flow control function (200) comprises a first sub-function (210) with an algorithm for handling congestion in the first interface (125), and a second sub-function (220) with an algorithm for handling congestion in the second interface (140).
3. The method of claim 2, according to which the algorithm used by the first sub-function (210) differs from the algorithm which is used by the second sub-function (220).
4. The method of claim 2, according to which the algorithm used by the first sub-function (210) is the same as the algorithms which is used by the second sub-function (220).
5. The method of any of claims 1 -4, according to which the flow control function (200) comprises a part (210, 220) which is located in the RBS (130).
6. The method of claim 5, according to which the two sub-functions (210, 220) of the flow control function (200) both have as their output a standard control frame in the system, which is sent to the RNC (110), and contains information about how much traffic the RNC is allowed to send to the RBS (130) for the specific flow which is controlled by the flow control function.
7. The method of any of the previous claims, according to which only one of the two sub-functions (210, 220) can be active at one and the same time.
8. The method of claim 7, according to which one of the sub-functions (210, 220) is defined to always be active if there is no congestion on the interface (125, 140) which is handled by the other sub-function (210, 220) for a certain predefined interval of time.
9. A node (130) for use in a wireless telecommunications system (100), which system can comprise at least one user, UE, and which comprises a hierarchy of nodes above the UE, said node (130) being intended to be the first node in the system, i.e. the node which is the closest to the UE, in which system (100) there is also a second node (110) above said first node (130), the first node (130) being equipped with means for communicating with the second node (110) and also with the UE (150), so that there is in the system a first interface (125) between the second node (110) and the first node (130), and a second interface (140) between the first node (130) and the UE (150), the traffic in the system being able to comprise one or more flows which can be controlled by the first node (130), the first node (130) being characterized in that it comprises one flow control function (200) for each of said controlled flows.
10. The node (130) of claim 9, in which said flow control function comprises a first sub-function (210) with an algorithm for handling congestion in the first interface (125) and a second sub-function (220) with an algorithm for handling congestion in the second interface (140).
11. The node (130) of claim 10, in which the algorithm used by the first sub- function (210) differs from the algorithm which is used by the second sub- function (220).
12. The node (130) of claim 10, in which the algorithm used by the first sub- function (210) is the same as the algorithm which is used by the second sub- function (220).
13. The node (130) of claim 10 or 11 , in which the two sub-functions (210, 220) of the flow control function (200) both have as their output a standard control frame in the system, which is sent to the RNC (110), and which contains information about how much traffic the RNC (110) is allowed to send to the node (130) for the specific flow which is controlled by the flow control function (200).
14. The node (130) of any of claims 10-13, in which only one of the two sub- functions (210, 220) can be active at one and the same time.
15. The node (130) of claim 14, in which one of the sub-functions (210, 220) is defined to always be active if there is no congestion on the interface (125, 140) which is handled by the other sub-function (210, 220) for a certain predefined interval of time.
16. The node (130) of any of claims 10-15, said node being the Radio Base Station, RBS, in a 3G cellular telephony system, such as the WCDMA system.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
PCT/SE2006/050510 WO2008066429A1 (en) | 2006-11-28 | 2006-11-28 | A method for improved handling of traffic congestion in a wireless telecommunications system |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
PCT/SE2006/050510 WO2008066429A1 (en) | 2006-11-28 | 2006-11-28 | A method for improved handling of traffic congestion in a wireless telecommunications system |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2008066429A1 true WO2008066429A1 (en) | 2008-06-05 |
Family
ID=39468134
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/SE2006/050510 WO2008066429A1 (en) | 2006-11-28 | 2006-11-28 | A method for improved handling of traffic congestion in a wireless telecommunications system |
Country Status (1)
Country | Link |
---|---|
WO (1) | WO2008066429A1 (en) |
Cited By (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP2178326A1 (en) * | 2008-10-16 | 2010-04-21 | Vodafone Group PLC | Method for assigning bandwidth in the call admission control of lub interface |
WO2011025438A1 (en) | 2009-08-25 | 2011-03-03 | Telefonaktiebolaget L M Ericsson (Publ) | Using the ecn mechanism to signal congestion directly to the base station |
EP2292038A1 (en) * | 2008-06-24 | 2011-03-09 | Telefonaktiebolaget L M Ericsson (PUBL) | Congestion control in a wireless communication network |
WO2011096856A1 (en) * | 2010-02-02 | 2011-08-11 | Telefonaktiebolaget L M Ericsson (Publ) | Flow control ca allocation correction factor based on scheduling policy, mobility, load or radio channel type |
WO2011120581A1 (en) * | 2010-03-31 | 2011-10-06 | Telefonaktiebolaget L M Ericsson (Publ) | Congestion handling in a communication network |
WO2012134360A1 (en) * | 2011-03-29 | 2012-10-04 | Telefonaktiebolaget L M Ericsson (Publ) | Congestion control in an hspa system |
WO2013050062A1 (en) * | 2011-10-04 | 2013-04-11 | Telefonaktiebolaget L M Ericsson (Publ) | Congestion handling in a base station of a mobile network |
JP2014112886A (en) * | 2014-01-07 | 2014-06-19 | Telefon Ab L M Ericsson | Congestion processing for communication network |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2002052886A1 (en) * | 2000-12-22 | 2002-07-04 | Nokia Corporation | Traffic congestion |
EP1633086A2 (en) * | 2004-09-06 | 2006-03-08 | Nokia Corporation | Radio system, base station, controller, and method of controlling data transmission |
WO2006071174A1 (en) * | 2004-12-30 | 2006-07-06 | Telefonaktiebolaget Lm Ericsson (Publ) | Method and apparatus for flow control at cell change for high speed downlink packet access |
WO2006097805A1 (en) * | 2005-03-15 | 2006-09-21 | Nokia Corporation | Flow control with dynamic priority allocation for handover calls |
WO2006103136A1 (en) * | 2005-04-01 | 2006-10-05 | Ipwireless Inc | Flow control in a cellular communication system |
-
2006
- 2006-11-28 WO PCT/SE2006/050510 patent/WO2008066429A1/en active Application Filing
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2002052886A1 (en) * | 2000-12-22 | 2002-07-04 | Nokia Corporation | Traffic congestion |
EP1633086A2 (en) * | 2004-09-06 | 2006-03-08 | Nokia Corporation | Radio system, base station, controller, and method of controlling data transmission |
WO2006071174A1 (en) * | 2004-12-30 | 2006-07-06 | Telefonaktiebolaget Lm Ericsson (Publ) | Method and apparatus for flow control at cell change for high speed downlink packet access |
WO2006097805A1 (en) * | 2005-03-15 | 2006-09-21 | Nokia Corporation | Flow control with dynamic priority allocation for handover calls |
WO2006103136A1 (en) * | 2005-04-01 | 2006-10-05 | Ipwireless Inc | Flow control in a cellular communication system |
Cited By (20)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP2292038A4 (en) * | 2008-06-24 | 2015-02-11 | Unwired Planet Internat Ltd | Congestion control in a wireless communication network |
EP2292038A1 (en) * | 2008-06-24 | 2011-03-09 | Telefonaktiebolaget L M Ericsson (PUBL) | Congestion control in a wireless communication network |
EP2178326A1 (en) * | 2008-10-16 | 2010-04-21 | Vodafone Group PLC | Method for assigning bandwidth in the call admission control of lub interface |
US8923115B2 (en) | 2009-08-25 | 2014-12-30 | Telefonaktiebolaget L M Ericsson (Publ) | Using the ECN mechanism to signal congestion directly to the base station |
WO2011025438A1 (en) | 2009-08-25 | 2011-03-03 | Telefonaktiebolaget L M Ericsson (Publ) | Using the ecn mechanism to signal congestion directly to the base station |
EP2471302A1 (en) * | 2009-08-25 | 2012-07-04 | Telefonaktiebolaget LM Ericsson (publ) | Using the ecn mechanism to signal congestion directly to the base station |
EP2471302A4 (en) * | 2009-08-25 | 2013-03-27 | Ericsson Telefon Ab L M | Using the ecn mechanism to signal congestion directly to the base station |
US8854970B2 (en) | 2010-02-02 | 2014-10-07 | Telefonaktiebolaget L M Ericsson (Publ) | Flow control CA allocation correction factor based on scheduling policy, mobility, load or radio channel type |
WO2011096856A1 (en) * | 2010-02-02 | 2011-08-11 | Telefonaktiebolaget L M Ericsson (Publ) | Flow control ca allocation correction factor based on scheduling policy, mobility, load or radio channel type |
WO2011120581A1 (en) * | 2010-03-31 | 2011-10-06 | Telefonaktiebolaget L M Ericsson (Publ) | Congestion handling in a communication network |
CN102823202A (en) * | 2010-03-31 | 2012-12-12 | 瑞典爱立信有限公司 | Congestion handling in a communication network |
US9112797B2 (en) | 2010-03-31 | 2015-08-18 | Telefonaktiebolaget L M Ericsson (Publ) | Congestion handling in a communication network |
CN102823202B (en) * | 2010-03-31 | 2016-08-03 | 瑞典爱立信有限公司 | The method of the congested process in communication network and networking component |
EP2692170A1 (en) * | 2011-03-29 | 2014-02-05 | Telefonaktiebolaget L M Ericsson (PUBL) | Congestion control in an hspa system |
EP2692170A4 (en) * | 2011-03-29 | 2014-06-11 | Ericsson Telefon Ab L M | Congestion control in an hspa system |
WO2012134360A1 (en) * | 2011-03-29 | 2012-10-04 | Telefonaktiebolaget L M Ericsson (Publ) | Congestion control in an hspa system |
US9253682B2 (en) | 2011-03-29 | 2016-02-02 | Telefonaktiebolaget L M Ericsson (Publ) | Congestion control in an HSPA system |
WO2013050062A1 (en) * | 2011-10-04 | 2013-04-11 | Telefonaktiebolaget L M Ericsson (Publ) | Congestion handling in a base station of a mobile network |
US8923117B2 (en) | 2011-10-04 | 2014-12-30 | Telefonaktiebolaget L M Ericsson (Publ) | Congestion handling in a base station of a mobile network |
JP2014112886A (en) * | 2014-01-07 | 2014-06-19 | Telefon Ab L M Ericsson | Congestion processing for communication network |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US8369221B2 (en) | Efficient flow control in a radio network controller (RNC) | |
US5668951A (en) | Avoiding congestion system for reducing traffic load on selected end systems which utilizing above their allocated fair shares to optimize throughput at intermediate node | |
JP4510826B2 (en) | Method for scheduling uplink transmission of user equipment and base station | |
US8339962B2 (en) | Limiting RLC window size in the HSDPA flow control | |
US7724750B2 (en) | Expedited data transmission in packet based network | |
WO2008066429A1 (en) | A method for improved handling of traffic congestion in a wireless telecommunications system | |
Oh et al. | Constraint-based proactive scheduling for MPTCP in wireless networks | |
US20050237973A1 (en) | Wireless communications apparatus, and routing control and packet transmission technique in wireless network | |
US8000249B2 (en) | Method for improved congestion detection and control in a wireless telecommunications systems | |
US20040228285A1 (en) | Packet communications system | |
US7382732B2 (en) | Method and system for flow control for route switching | |
US20090005053A1 (en) | Data Flow Control Device and Method for Congestion Avoidance Into Lub and Lur Interfaces of a Radio Access Network of a Mobile Communication Network | |
JP2009207208A (en) | Method for improving performance of tcp connection | |
WO2005088917A1 (en) | Control station apparatus, base station apparatus, terminal apparatus, packet communication system, and packet communication method | |
CN101582842A (en) | Congestion control method and congestion control device | |
JP2002009841A (en) | Enhanced service quality control in mobile communication network | |
Wallace et al. | Concurrent multipath transfer using SCTP: Modelling and congestion window management | |
US20140281034A1 (en) | System and Method for Compressing Data Associated with a Buffer | |
ES2448792T3 (en) | Traffic congestion on radio network controllers | |
EP3395023B1 (en) | Dynamically optimized queue in data routing | |
WO2009037152A1 (en) | Improved utilization of data links | |
Verma et al. | An adaptive data chunk scheduling for concurrent multipath transfer | |
US20110164500A1 (en) | Congestion Control in a Wireless Communication Network | |
Nádas et al. | Providing congestion control in the Iub Transport Network for HSDPA | |
Kumar et al. | A multipath packet scheduling approach based on buffer acknowledgement for congestion control |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 06824579 Country of ref document: EP Kind code of ref document: A1 |
|
NENP | Non-entry into the national phase |
Ref country code: DE |
|
122 | Ep: pct application non-entry in european phase |
Ref document number: 06824579 Country of ref document: EP Kind code of ref document: A1 |