NOT APPLICABLE
NOT APPLICABLE
NOT APPLICABLE
The present invention relates to radio telecommunication systems. More particularly, and not by way of limitation, the present invention is directed to a system and method for dynamically controlling throughput over the air interface between a mobile terminal and a radio telecommunication network.
The length of the packet queue (PQ) in a Node-B (base station) is handled by High-Speed Downlink Packet Access (HSDPA) flow control (FC). The flow control process contends with two somewhat contradictory goals: (1) keep the PQ length short for low delay (low latency), which is good for time-sensitive traffic; and (2) keep the PQ length long enough to avoid under-utilization of the available radio bearer, as when there is an empty PQ buffer while there are packets waiting in the Radio Network Controller (RNC).
The existing HSDPA FC algorithm tries to fulfill both requirements by dynamically setting the shaping rate of the packet flow in the RNC. The shaping rate is set relative to a target delay according to the following algorithm:
Performance of the Uu interface between the mobile terminal and the Node B depends highly on the target delay selected by the HSDPA FC algorithm.
The main problem with the existing HSDPA FC algorithm is that there is no target delay that is optimal for all types of traffic. Delay-sensitive traffic (for example, online gaming traffic) requires a very small target delay, while “throughput oriented” traffic (for example, downloading a large file) should use a higher target delay to avoid underutilization of the available radio resource. The existing HSDPA FC algorithm adjusts the shaper bit rate to match the target delay set by the operator, but it does not change the target delay. When a user utilizes services from both types, preference is usually given to the delay-sensitive traffic. It is acceptable if the download speed drops, for example 20 percent, but delay of online gaming traffic is far less tolerable.
The present invention dynamically selects a target delay according to the type of service being utilized. Whenever a user activates a delay-sensitive service, the target delay is dynamically changed to a smaller value to reduce latency. If a user terminates all delay-sensitive services, the target delay is dynamically changed to a larger value to maximize download speed. This satisfies the normal user preference not to have the delay-sensitive traffic impacted by other services.
In one embodiment, the present invention is directed to a computer-controlled method of dynamically controlling throughput over an air interface between a mobile terminal and a radio telecommunication system, wherein the radio telecommunication system includes a radio access network and a core network. The method includes the steps of determining by a core network node, whether a traffic flow (service) for the mobile terminal is delay-sensitive; when there is no delay-sensitive traffic flow for the mobile terminal, maintaining a radio access bearer (RAB) for the mobile terminal in a throughput-oriented mode; and when there is a delay-sensitive traffic flow for the mobile terminal, changing the target delay parameter to establish a low-delay RAB for the mobile terminal.
In another embodiment, the present invention is directed to a core network node for dynamically controlling throughput over an air interface between a mobile terminal and a radio telecommunication system, wherein the radio telecommunication system includes a radio access network and a core network. The node includes means for monitoring traffic for the mobile terminal and determining whether the traffic is delay-sensitive or throughput-oriented; means for causing the radio access network to maintain a RAB for the mobile terminal in a throughput-oriented mode, responsive to a determination that the traffic for the mobile terminal is throughput-oriented; and means for causing the radio access network to change a target delay parameter to a lower value to establish a low-delay RAB for the mobile terminal, responsive to a determination that the traffic for the mobile terminal is delay-sensitive.
In another embodiment, the present invention is directed to a computer-controlled method of dynamically controlling throughput over an air interface between a mobile terminal and a radio telecommunication system, wherein the radio telecommunication system includes a radio access network and a core network. The method includes the steps of detecting a type of service being utilized by the mobile terminal; and dynamically selecting a target delay for the traffic between a base station and the mobile terminal.
The present invention improves the performance of the Uu interface between the mobile terminal and the Node B, providing improved delay and throughput performance. In addition, the invention supports delay-sensitive traffic when a secondary bearer cannot be set up due to technical reasons, operator policies, or heavy traffic load.
In the following section, the invention will be described with reference to exemplary embodiments illustrated in the figures, in which:
In order to dynamically select a target delay according to the type of service being utilized, a controlling node must first identify the type of service and its associated flow requirements. In one embodiment, this may be done by defining categories of services, i.e., delay-sensitive (low latency) flow, or throughput-oriented flow. Then, using Deep Packet Inspection (DPI) functionality in a core network node, the user traffic can be analyzed and classified into the categories above.
After this traffic-identification process is done, the controlling DPI node knows whether the user has delay-sensitive (low latency) traffic or not, and signals the HSDPA FC entity in the Node B accordingly. If there is a change in the user behavior (for example, the user starts to use a delay-sensitive application), the DPI node signals the change to the HSDPA FC entity, which then changes the target delay value.
When the DPI Engine 11 in the GGSN detects that the user is switching to or from a delay-sensitive service, the GGSN 12 informs the SGSN serving the user, such as SGSN 14a. Preferably, the GGSN uses only standardized GTP messages, although non-standard messages may also be utilized. In one embodiment, the GGSN sends an Update PDP Context Request message to the SGSN. The SGSN then coordinates with the Radio Access Network (RAN) to adjust the target delay in the HSDPA FC entity in the Node B/base station accordingly.
The GGSN may signal the SGSN to either create a new secondary Radio Access Bearer (RAB), to modify an already active secondary bearer by adding the new flow's Traffic Flow Templates (TFTs), or to modify the default RAB. For example, when the user switches to a delay-sensitive service, the GGSN looks for a secondary bearer that can accommodate the flow. If there is no such bearer, but one could be created, the GGSN may request the SGSN to create a new best effort, but low-latency secondary RAB and to map the low-latency flow to the new RAB. If a low-latency secondary RAB already exists, the GGSN simply updates the secondary RAB via an Update PDP Context Request to contain the new flow. Alternatively, the Update PDP Context Request may request the SGSN to modify the default RAB so it enters “low latency” mode, meaning smaller delay, and slightly lower throughput.
The second case is always possible, while the first case is only possible for certain users (depending on configuration) and network situation. For example, in a high load it may not be possible to create new bearers. During default RAB modification, the RNC may adjust the target delay parameter of the HSDPA FC entity to a value of 20-50 ms, for example, for low-latency mode or to a value of 100-200 ms, for example, for throughput-oriented mode. The RNC may also adjust Active Queue Management (AQM) parameters of the flow based on delay requirements. In case of a Long Term Evolution (LTE) access network, the Radio Link Control (RLC) AQM Service Data Unit (SDU) parameter may be modified instead of the FC parameter.
If a secondary RAB already exists, the GGSN 12 sends an Update PDP Context Request message to the SGSN instead of the Create PDP Context Request message 31. The update message is used to add Traffic Flow Templates (TFTs) and to modify bearer parameters for the secondary RAB. The SGSN modifies the secondary RAB then returns an Update PDP Context Response message to the GGSN in a process similar to
If there are secondary RABs, the secondary RABs handle the low-delay traffic flows, and the primary RAB remains in throughput-oriented mode. When the DPI Engine 11 detects a low-delay flow termination, one of the secondary RABs is modified. The primary bearer is not modified by the DPI-driven actions.
If it is determined at step 43 that a secondary RAB is not allowed (which is the typical case for High Speed Packet Access (HSPA) users), the method moves from step 43 to step 47, where the primary RAB is modified with a new low target delay. In this case the primary RAB enters low-delay mode at step 48. Thereafter, the DPI Engine 11 monitors the traffic flows and if a low-delay flow termination is detected, the method moves to step 49, where the DPI Engine determines whether there are still other low-delay flows on the RAB. If so, the primary RAB remains in low-delay mode at 48. However, if there are no other low-delay flows on the RAB, the method moves to step 50, where the primary RAB is modified with a new high target delay. In this case the primary RAB returns to throughput-oriented mode at step 41.
It is possible that moving to the low-delay mode for an extended period will have an overly adverse impact on throughput. Therefore, in one embodiment, the system may automatically switch back to the throughput-oriented mode after a defined time period. Alternatively, the network may monitor downlink buffer levels for traffic destined for the mobile terminal, and if the levels rise above a threshold value, the system may automatically switch back to the throughput-oriented mode.
As will be recognized by those skilled in the art, the innovative concepts described in the present application can be modified and varied over a wide range of applications. Accordingly, the scope of patented subject matter should not be limited to any of the specific exemplary teachings discussed above, but is instead defined by the following claims.