Patent Grant
8417826
The present invention relates to communications and, more particularly, to control systems for packet-data wireless communication networks.
Wireless, radio frequency communication systems enable people to communicate with one another over long distances without having to access landline-connected devices such as conventional telephones. While early systems were primarily configured for voice communications, technological improvements have enabled the development of “3-G” (third generation) and similar wireless networks for both voice and high-speed packet data transfer. For example, CDMA-based, “1x-EVDO” (Evolution Data Optimized, or Evolution Data Only) wireless communication networks, now implemented in many parts of the U.S. and elsewhere, use the CDMA2000® 3-G mobile telecommunications protocol/specification for the high-speed wireless transmission of both voice and non-voice data. 1x-EVDO is an implementation of CDMA2000) that supports high data rates, specifically, forward link data rates up to 3.1 Mbit/s, and reverse link rates up to 1.8 Mbit/s in a radio channel dedicated to carrying high-speed packet data, e.g., a 1.25 MHz-bandwidth radio channel separate from the radio channel for carrying voice data.
In 3-G packet data networks, e.g., those using the Internet Protocol (“IP”) for data transmission generally and voice over IP (“VoIP”) for voice-data transmission, data is broken into a plurality of addressed data packets. For example, with VoIP, analog audio/voice signals are captured, digitized, and broken into data packets. The data packets, both voice and non-voice, are then transmitted and routed over an IP-based communications network, where they are received and reassembled by the access terminal to which the data packets are addressed. Unlike circuit switched systems, however, in which a physical or logical circuit (e.g., pathway) is established for each call (with the resources for the circuit being dedicated to the call during the entirety of its duration), the data packets may be sent at different times, out of order, and/or along different pathways. In this manner, data transmission resources are utilized in a more efficient and optimized manner.
The use of VoIP allows voice services to be integrated with multimedia and other packet data services in a wireless communication network. This facilitates a diversity of applications, and may increase overall system performance. However, wireless networks present a particular challenge to packet voice traffic. Generally speaking, as network load increases, there is an increased likelihood of dropped calls, poor quality calls (e.g., resulting from increased frame error rates), long transmission latencies, and the like, all of which may lead to high user dissatisfaction rates. More specifically, the air interface in a wireless network (e.g., the radio link between one or more fixed base stations and various mobile or other wireless access terminals) is dynamic by nature, as is the system capacity and the performance associated with each voice user. Thus, there may be occasions where not enough bandwidth is available to accommodate every active user according to target quality of service (“QOS”) levels. Additionally, even if bandwidth is available, there may be times when it is not possible to meet target or required QOS levels in transmitting voice or other data packets to a wireless access terminal, due to varying radio airlink conditions or the like.
In some instances, these problems may be compounded as a result of limitations in network electronic processing capacity. In particular, carrying out wireless packet data communications involves the ongoing electronic processing of large numbers of data packets. For this purpose, each element of network infrastructure (e.g., wireless units, base stations, RNC, MSC, etc.) will typically include one or more microprocessors or other electronic processing units. When network traffic load is heavy, processor resources may be overextended, e.g., in a particular leg/hop of the communication channel there may not be enough processing power to accommodate the data load according to required or target QOS levels. Additionally, during times of traffic overload the processing units and communication buses connected thereto tend to have complex and/or erratic processor overload behaviors. These factors may result in flow drop and dropped packets, resulting in poor quality calls and unacceptable system performance.
An embodiment of the present invention relates to a method for processor overload control in a wireless communication network, for purposes of controllably reducing processor load during times of heavy network traffic and thereby reducing incidents of data loss and the like that might negatively affect system performance. On an ongoing basis, the processor occupancy level (“PO” or “PO level”) of a network microprocessor or other electronic processing unit is monitored (e.g., periodically measured) and directly or indirectly compared to a target PO level. The processing unit is at a location in the network where data is processed, for example in a base station controller or an RNC. If the measured PO exceeds the target PO, one or more network load sources associated with the processing unit are controlled to reduce the data load of the processing unit, until the measured PO falls below a designated PO. (The designated PO level may be the same as the target PO, or it may be a different value.) By associated “load source,” it is meant a source of extant and/or potential data traffic through the processing unit, and/or a network control factor relating thereto, the control of which prevents an increase in the data traffic handled by the processing unit, and/or that results in a reduction thereof. Such sources include data packets and data flows on the forward and/or reverse links, newly initiated calls/communications, forward link BE flow window size, and the like.
In another embodiment, network load sources are controlled to reduce processing unit data load according to differentiated quality of service (“QOS”) levels. Thus, non delay-critical data flows/packets (e.g., BE flows) are reduced or eliminated before a controlled reduction in delay-critical data flows/packets, e.g., EF or AF flows. (A “flow” is a stream of data packets between a particular source address/port and a unique destination address/port, wherein the packets are generated according to the same protocol.) For example, if the measured PO exceeds a target PO level, and if a projected reduction in BE flows will reduce the processor load to below a designated PO level, then the BE flows are controllably reduced without affecting any EF flows. If on the other hand a reduction or elimination of BE flows will not sufficiently ease processor load, then EF flows may also be controllably reduced.
In another embodiment, network load sources are controlled to reduce the processing unit PO level by carrying out one or more of the following processes: reconfiguring BE forward link window size; muting a percentage of Rel 0 and Rev A reverse link BE flows; dropping a percentage of forward link EF packets; skipping a percentage of forward link time slots in scheduling; and temporarily halting the admission of newly initiated calls/communications over the network for the processing unit.
In another embodiment, network load sources are controlled both at the processing unit itself, and by issuing appropriate commands to other components in the network, depending on the particular load source to be controlled. For example, if it is determined to temporarily halt the admission of new calls/transmissions for the processing unit in question, a command to this effect may be issued to the RNC.
In another embodiment, the processing unit includes one or more processing sub-units. Data traffic may be monitored with respect to the processing unit as a whole, but more typically with respect to the processing sub-units individually. On a periodic ongoing basis, the PO levels of the processing sub-units are measured and compared to one or more target PO's. Based on the ongoing comparisons, network load sources are controlled with respect to the processing sub-units.
The present invention will be better understood from reading the following description of non-limiting embodiments, with reference to the attached drawings, wherein below:
With reference to
As noted, the processor overload control system 10 is implemented as part of a wireless telecommunication network 12. One example of such a network 12 is shown in
Various methods exist for conducting wireless communications between base stations 20a-20c and wireless units 36a, 36b. One such method is the CDMA (code division multiple access) spread-spectrum multiplexing scheme, widely implemented in the U.S. under various standards as discussed above. In a CDMA-based network, transmissions from wireless units to base stations are across the reverse link 28b, which is a 1.25 MHz frequency bandwidth centered at a first designated frequency. Generally, each wireless unit is allocated the entire bandwidth all of the time, with the signals from individual wireless units being differentiated from one another using an encoding scheme. Transmissions from base stations to wireless units are across the forward link 28a, which is a similar 1.25 MHz frequency bandwidth centered at a second designated frequency. The forward and reverse links may each comprise a number of traffic channels and signaling or control channels, the former primarily for carrying data, and the latter primarily for carrying the control, synchronization, and other signals required for implementing CDMA communications. Thus, in the case of CDMA communications, the processing unit 14 may be configured to separate and decode spread-spectrum signals received over the airlink, and to combine and encode signals for transmission over the airlink, among other functions.
The base stations 20a-20c are in turn connected to the RNC 22 over a “backhaul” communication pathway 38. For example, the backhaul 38 might include a concentrator router 40 and a high capacity multiplexer (“MUX”) 42, wherein data received at the RNC 22 is forwarded to the concentrator router 40 and then over a high capacity line to the MUX 42 for transfer to the base stations 20a-20c. The RNC 22 acts as the interface between the wireless/radio end of the network 12 and various internal and external networks such as a public switched telephone network (“PSTN”) 44 and the Internet 46. The RNC 22 includes a traffic processor unit (“TP”) 48 for performing the signaling functions necessary to establish calls or other data transfer to and from the wireless units 36a, 36b. For high-speed data transmission to and from the Internet 46 or elsewhere (e.g., for facilitating web browsing, real time file transfer, or downloading large data files), the network 12 may use the Internet Protocol, where data is broken into a plurality of addressed data packets 50. For use in transferring packet data 50 between the network 12 and other networks such as the Internet 46, the wireless network 12 may include a packet data serving node (“PDSN”) 52 for routing wireless unit-originated or terminated packet data, an authentication, authorization, and accounting module (“AAA”) 54, one or more firewalls 56, and a VoIP media gateway 58 that converts VoIP transmissions into a format suitable for transfer over the PSTN 44 (e.g., analog voice signals) and vice versa. The network 12 may also include a core IP network portion 60 for internal landline communications between different elements of the network, e.g., between the RNC 22 and AAA module 54 or other service center.
Although the base stations 20a-20c are illustrated as each having one processing unit 14, it may instead be the case that each includes a number of processing units, depending on the capacity of the base station. When a call or other communication is newly initiated, one of the processing units is temporarily assigned to process the call. When the call is terminated, the processing unit is freed up, and may be assigned to process another call. Additionally, referring back to
With reference to the processing unit 14 in
If the network 12 utilizes differentiated quality of service (“QOS”) levels, then network load sources 24 are controlled to reduce processing unit data load according to the differentiated network QOS levels. Thus, non delay-critical data flows/packets (e.g., BE flows) are reduced before a controlled reduction in delay-critical data flows/packets, e.g., EF or AF flows. (A “flow” is a stream of data packets between a particular source address/port and a unique destination address/port, wherein the packets are generated according to the same protocol.) EF, AF, and BE flows are implemented according to a set of scheduling and queuing schemes, in a standard manner, such as those defined by the IETF “DiffServ” standard. Designated EF flows provide a low loss, low latency, low jitter, assured bandwidth, and end-to-end service through the network 12, e.g., akin to a point-to-point connection or “virtual leased line.” Designated AF flows have a minimum rate guarantee and low loss rate. BE flows are transmitted at the best efforts of the network, typically without system monitoring or guaranteed rates. Thus, in each processor 14 and/or processor sub-unit 62, 64 there may exist multiple data flows that include BE flows, AF flows, and EF flows. For bearer traffic packets (e.g., packets carrying user data as opposed to network signaling data), the flows can be simplified as comprising (i) BE flows for any applications that do not have a stringent delay and (ii) EF flows for applications that have stringent delay constraints wherein the data packets have to be processed and delivered at a minimum delay. Examples of the latter include VoIP and VT flows. Thus, as noted above, since BE flows do not have stringent delay constraints, the overload control system 10 is configured to control the BE flows first. EF flows are impacted only if controlling the BE flows is insufficient to reduce processor load to a desired level.
With reference to
An embodiment of the present invention will now be explained in more detail with reference to
At Step 120, the PO level 16 of the processing unit 14, 62, 64 in question is measured. (The steps of
Here, AFt=0=1, and fmin is a constant value, e.g., 0.02, representing a minimum value for AF. AFt is updated every T seconds, wherein T is a tunable parameter in the range of, e.g., 1 to 10 seconds with a default value of 1 second. Thus:
As should be appreciated, if the measured PO level 16 does not exceed the target PO 18, then the acceptance factor AF will remain at 1. If the measured PO level 16 exceeds the target PO 18, then the acceptance factor AF will be a value between fmin and 1. The acceptance factor AF thus acts as a measure of the extent to which the measured PO 16 exceeds the target PO 18, for use in controllably reducing BE flows, possibly EF flows, and other load sources 24.
At Step 126, the BE flow PO level per link is calculated, that is, the percentages of processor occupancy due to BE flows on the forward and reverse links are calculated, as follows:
Here, NPBE
At Step 128, a value “A” is calculated, which represents the percentage PO to be reduced. Δ is calculated as:
Δ=(1−AF)·PO
As should be appreciated, if AF=1 (meaning that the measured PO does not exceed the target PO), then Δ=0, meaning that the PO is not to be reduced. As AF approaches its minimum value of fmin (e.g., 0.02), A increases to a maximum value of (1−fmin) PO, e.g., 0.98 PO (that is, 98% of the PO is to be reduced).
At Step 130, it is determined if A is less than or equal to POBE, where POBE is the processor occupancy level due to BE flows and POBE=POBE
Here, “α” is a tunable parameter in the range of, e.g., 1 to 1.5 with a default value of 1. Subsequently, at Step 134 a reduction ratio “R” is calculated for BE flows on each link, as follows:
Additionally, since EF flows are not impacted when a reduction in BE flows will be sufficient to remedy the overload condition (e.g., if 0<Δ≦POBE), the following values are assigned in relation to EF flows:
Application of the reduction ratios is discussed below, and may depend on processing unit type.
Referring back to Step 130, if Δ>POBE (e.g., if the percentage of PO to be reduced is greater than the percentage of processor occupancy due to BE flows), then at Step 136 a “Δ” value and reduction ratio are determined for EF flows, as follows:
Subsequent to either Step 134 or Step 136, as the case may be, there will be a set of reduction ratios “R” for EF flows and BE flows (RBE
new window size=(1−RBE
As should be appreciated, the larger the value for RBE
Here, the LIU 32 is configured to drop EF flow packets according to the above when it receives a request to do so from the BAP sub-unit or otherwise from the overload control system 10.
For BAP reverse link overload control, still assuming a BAP Δ>0 at Step 160, at Step 170 designated percentages of Rel 0 and Rev A BE flows are muted, meaning that no packets are sent over these flows:
“Ratio—1” and “Ratio—2” correspond to the relative percentages of the Rel 0 and Rev A flows with respect to the combined Rel 0 and Rev A flows.
DSP skips(RBE
When a time slot is skipped, the DSP will not schedule packets to be sent at the slots. Instead, the packets will be stored in a buffer.
For BMP reverse link overload control, and still assuming BMP Δ>0, at Step 186 designated percentages of Rel 0 and Rev A BE flows are muted:
The BAP sub-unit 62 may receive window-shrinking requests from the LIU 32, from itself, from the overload control system 10, or the like. Whenever requests are received from any two or more sources in the same time period, the BAP sub-unit 62 uses the smallest overload control window size among the several requests. Additionally, the BAP sub-unit 62 may receive requests to mute RL Rel 0 and Rev A BE flows from the BMP sub-unit 62 and from itself. Whenever requests are received from any two or more sources in the same time period, the sum of the Rel 0 and Rev A BE flows to be muted should meet the maximum percentage needs among the BAP sub-unit, BMP sub-unit, and LIU. Additionally, the BAP sub-unit 62 may be configured to set and reset the overload flag for both the BAP and BMP, and may transmit the overload flag value to the RNC 22.
The base stations 20a-20c are configured to mute RL Rel 0 flows as requested by the BAP sub-unit or otherwise by the overload control system 10. Additionally, the RNC 22 is configured to mute the RL Rev A flows as requested by the overload control system. The RNC 22 is also configured to allow or disallow newly initiated calls as requested by the overload control system.
As noted above, the system 10 may be implemented as a hardware module, hardware/software module, script or other software program, or suite of software programs. The system 10 may be centralized, and possibly including one or more distributed sub-routines or utility programs operating in different parts of the network 12 for reporting and control purposes. Alternatively, the system 10 may be distributed about the network, e.g., in place in multiple iterations at each processing unit or sub-unit. In either case, the system is integrated with the processing units and/or with one or more network components (e.g., the base stations and RNC) for carrying out the methods described herein.
Since certain changes may be made in the above-described method and system of overload control in a packetized communication network, without departing from the spirit and scope of the invention herein involved, it is intended that all of the subject matter of the above description or shown in the accompanying drawings shall be interpreted merely as examples illustrating the inventive concept herein and shall not be construed as limiting the invention.
| Number | Name | Date | Kind |
|---|---|---|---|
| 4974256 | Cyr et al. | Nov 1990 | A |
| 5774668 | Choquier et al. | Jun 1998 | A |
| 6067545 | Wolff | May 2000 | A |
| 6252950 | Duty et al. | Jun 2001 | B1 |
| 6377975 | Florman | Apr 2002 | B1 |
| 6496505 | La Porta et al. | Dec 2002 | B2 |
| 6661776 | Kaufman et al. | Dec 2003 | B1 |
| 6910024 | Krishnamurthy et al. | Jun 2005 | B2 |
| 6922564 | Witana | Jul 2005 | B2 |
| 6928482 | Ben Nun et al. | Aug 2005 | B1 |
| 7068607 | Partain et al. | Jun 2006 | B2 |
| 7274666 | Balakrishnan et al. | Sep 2007 | B2 |
| 7447152 | Kim et al. | Nov 2008 | B2 |
| 7564872 | Chawla et al. | Jul 2009 | B1 |
| 20020181394 | Partain et al. | Dec 2002 | A1 |
| 20030140147 | Gavish et al. | Jul 2003 | A1 |
| 20030154284 | Bernardin et al. | Aug 2003 | A1 |
| 20040165529 | Lee | Aug 2004 | A1 |
| 20050155032 | Schantz | Jul 2005 | A1 |
| 20060120339 | Akiyama et al. | Jun 2006 | A1 |
| Number | Date | Country |
|---|---|---|
| 1039699 | Sep 2000 | EP |
| 1137316 | Sep 2001 | EP |
| 1703668 | Sep 2006 | EP |
| Entry |
|---|
| Wei Song; Hai Jiang; Weihua Zhuang; Xuemin Shen; , “Resource management for QoS support in cellular/WLAN interworking,” Network, IEEE , vol. 19, No. 5, pp. 12-18, Sep.-Oct. 2005. |
| Number | Date | Country | |
|---|---|---|---|
| 20080104377 A1 | May 2008 | US |
