TECHNIQUES FOR COMMUNICATING AND MANAGING CONGESTION IN A WIRELESS NETWORK

Abstract

Techniques are described that can be used to communicate congestion information concerning a downlink or uplink. In response to congestion on a link, a device can attempt to receive traffic on another network, scan for another node, or enter sleep mode for a time. In some cases, determination of congestion can be made based on an amount of time a packet is enqueued as well as the number of packets that experience a similar amount of enqueuing delay.

Description

RELATED APPLICATION

This application claims the benefit of U.S. Provisional Application No. 61/330,837, filed May 3, 2010 (Attorney Docket No. P35030Z).

FIELD

The subject matter disclosed herein relates generally to techniques for communicating and managing congestion in a wireless network.

RELATED ART

In communication systems, bandwidth is scarce and numerous devices compete for use of available bandwidth. In the event of insufficient bandwidth, packets may not be transmitted or received in a timely manner. It is desirable to reduce the effects of congestion on networked devices.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments of the present invention are illustrated by way of example, and not by way of limitation, in the drawings and in which like reference numerals refer to similar elements.

FIG. 1 depicts an example of devices connected using a wireless network.

FIG. 2 depicts an example of a base station-initiated congestion report signaling to a mobile station.

FIG. 3 depicts an example system in accordance with an embodiment.

FIGS. 4-6 depict signal flows for respective (1) WiFi (or other network) offloading, (2) forced scanning, and (3) sleep cycle adjustment.

FIG. 7 depicts an example system in which a mobile station initiates reporting to a base station regarding quality of experience (QoE) for each application that uses a network.

FIG. 8 depicts an example of a congestion detection system that can be used in a base station or mobile station.

FIG. 9 depicts an example of how queuing delay and congestion indicator can be related.

FIG. 10 provides an example of a system in accordance with an embodiment.

DETAILED DESCRIPTION

Reference throughout this specification to “one embodiment” or “an embodiment” means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Thus, the appearances of the phrase “in one embodiment” or “an embodiment” in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined in one or more embodiments.

Embodiments of the invention may be used in a variety of applications. Some embodiments of the invention may be used in conjunction with various devices and systems, for example, a transmitter, a receiver, a transceiver, a transmitter-receiver, a wireless communication station, a wireless communication device, a wireless Access Point (AP), a modem, a wireless modem, a Personal Computer (PC), a desktop computer, a mobile computer, a laptop computer, a notebook computer, a tablet computer, a server computer, a handheld computer, a handheld device, a Personal Digital Assistant (PDA) device, a handheld PDA device, a network, a wireless network, a Local Area Network (LAN), a Wireless LAN (WLAN), a Metropolitan Area Network (MAN), a Wireless MAN (WMAN), a Wide Area Network (WAN), a Wireless WAN (WWAN), devices and/or networks operating in accordance with existing IEEE 802.11, 802.11a, 802.11b, 802.11e, 802.11g, 802.11 h, 802.11i, 802.11n, 802.16, 802.16d, 802.16e, 802.16m, or 3GPP standards and/or future versions and/or derivatives and/or Long Term Evolution (LTE) of the above standards, as well as any Release of LTE, a Personal Area Network (PAN), a Wireless PAN (WPAN), units and/or devices which are part of the above WLAN and/or PAN and/or WPAN networks, one way and/or two-way radio communication systems, cellular radio-telephone communication systems, a cellular telephone, a wireless telephone, a Personal Communication Systems (PCS) device, a PDA device which incorporates a wireless communication device, a Multiple Input Multiple Output (MIMO) transceiver or device, a Single Input Multiple Output (SIMO) transceiver or device, a Multiple Input Single Output (MISO) transceiver or device, a Multi Receiver Chain (MRC) transceiver or device, a transceiver or device having “smart antenna” technology or multiple antenna technology, or the like.

Some embodiments may be used in conjunction with one or more types of wireless communication signals and/or systems, for example, Radio Frequency (RF), Infra Red (IR), Frequency-Division Multiplexing (FDM), Orthogonal FDM (OFDM), Orthogonal Frequency Division Multiple Access (OFDMA), Time-Division Multiplexing (TDM), Time-Division Multiple Access (TDMA), Extended TDMA (E-TDMA), General Packet Radio Service (GPRS), Extended GPRS, Code-Division Multiple Access (CDMA), Wideband CDMA (WCDMA), CDMA 2000, Multi-Carrier Modulation (MDM), Discrete Multi-Tone (DMT), Bluetooth®, ZigBee™, or the like. Embodiments may be used in various other apparatuses, devices, systems and/or networks.

FIG. 1 depicts an example of devices that can be connected using a wireless network. The network can be compliant with any variety of IEEE 802.16 or LTE. In the downstream or downlink case, generically-named transmitters 102 and/or 202 above may be interchangeably referred to as a base station (BS), enhanced Node B (eNB), or access point (AP). In this downlink case, receivers 104 and/or 204 above may be interchangeably referred to as a mobile station (MS), subscriber station (SS), user equipment (UE), or station (STA) at the system level herein. Further, the terms BS, eNB, and AP may be conceptually interchanged, depending on which wireless protocol is being used, so a reference to BS herein may also be seen as a reference to either of eNB or AP. Similarly, a reference to MS or SS herein may also be seen as a reference to either of UE or STA.

An MS can be implemented in a handheld personal computer, mobile telephone, set top box, or any computing device. Any type of user interface is available such as a keypad, mouse, and/or touch screen.

A BS can transmit signals to an MS using a downlink (DL) and receive signals from an MS using an uplink (UL). In some embodiments, a BS can determine whether DL or UL control channels are congested. For example, a DL can be considered congested if all or some percentage of control channels on the DL are allocated. For systems compliant with IEEE P802.16m draft 8 (2010) and variations and derivatives thereof, a control channel can be a control channel specified in section 16.3.5.2. For systems compliant with LTE and variations and derivatives thereof, a control channel can be a control shared channel known as Physical Downlink Control Channel (PDCCH). Similarly, an UL can be considered congested if all or some percentage of channels on the UL are allocated.

In some cases, to perform load balancing among BSs on a DL or UL, a BS can identify a DL or UL as congested even though not all channels on the DL or UL are allocated. The BS can offload traffic to one or more other BSs on the DL or UL.

FIG. 2 depicts an example of a BS-initiated congestion report signaling to an MS. In some embodiments, 1 bit can be used in a message to indicate congestion or no congestion on a DL and another 1 bit can be used in a message to indication congestion or no congestion on the UL. In some embodiments, multiple levels of congestion can be indicated in a congestion report using multiple bits transmitted in the same message or a sequence of messages. In some cases, the congestion report can indicate a percentage of the DL or UL burst usage. The percentage of the DL or UL burst usage can be indicated in one or more bits transmitted in the same message or a sequence of messages.

For example, the congestion report can be sent in a broadcast MAC message at the end of a primary control channel or secondary control channel message. In some cases, at the beginning of each sub-frame, a portion or field in a MAC header can indicate that a MAC message includes a congestion report and indicates a total size of the congestion report. Reserved bits in a MAC header can be used to indicate that a MAC message includes a congestion report and indicates a total size of the congestion report. The MAC message can include a Primary Super Frame header message and/or a Secondary Super Frame header. One or more bits in the reserved bits can include the congestion report. IEEE 802.16m draft 8 (2010) describes a Primary Super Frame header message (section 16.3.5.2.1.1) in a primary control channel and describes a Secondary Super Frame header message (Section 16.3.5.2.1.2) in a secondary control channel. The end of the Primary Super Frame header message and Secondary Super Frame header can include reserved bits. In LTE, reserved bits in a physical downlink control channel (PDCCH) message in a control shared channel can be used to convey the congestion report.

Of note, in LTE, RFC 3168 (2001) specifies 2 bits in an IP header can be used for a congestion message but does not explicitly specify under what condition a BS should indicate congestion is present.

A BS can send a congestion report over the wireless network either periodically or in response to one or more events. When sent periodically, the periodicity of the message can be in the order of seconds, although other periods can be used. The periodicity can depend on the periodicity of the message that the congestion report follows. The BS can request to send the congestion message in response to a change in either downlink or uplink congestion states. In some cases, the BS can request to send the congestion message in response to a congestion level exceeding or falling below a threshold. The BS can broadcast a congestion report to all MSs in network.

In some embodiments, no acknowledgement message of the congestion report message is transmitted from an MS to BS or vice versa. Not transmitting an acknowledgement message can avoid use of bandwidth in a potentially congested UL or DL path. In addition, not transmitting an acknowledgement message can avoid adding to congestion on an UL or DL path.

FIG. 3 depicts an example system including a base station (BS) 200 and mobile station (MS) 300. A MAC layer 202 of BS 200 can determine whether UL or DL congestion is present and transmit a congestion report to MS 300. In some cases, MAC layer 202 can also inform MS 300 of an action to take in response to a congestion report. For example, the action can be indicated in a reserved field of an Advanced MAP (A-MAP) message specified in IEEE 802.16m draft 8 (2010) (section 16.3.5.2.2) or a reserved field of a C-RNTI (Cell Radio Network Temporary Identifier) message specified in LTE.

In some cases, if BS 200 does not inform MS 300 of an action to take in response to a congestion report, MS 300 can ask the BS which action to take or whether an anticipated action is acceptable. In some embodiments, each MS can ask the BS what response to perform so that all MSs do not perform the same task and cause other types of congestion.

In some cases, a MAC layer 301 of MS 300 can determine whether congestion report in a MAC message indicates congestion. For example, the actions taken by MS 300 can be one or more of: (1) WiFi offloading 302, (2) forced scanning 304, and (3) sleep cycle adjustment 306. MS 300 can respond to the congestion report by finding other alternatives to achieve the required quality of service for its applications and also help ease the congestion in the process.

The following describes activities of module 302 of FIG. 3 in response to a congestion report message 401. Referring to FIG. 4, at 401, an MS receives a congestion report message. At 402, an MS can scan for other wireless access networks such as an IEEE 802.11 compliant network and variations thereof, TV white space, or other local area or wide area networks, such as LTE. If the WiFi or other network permits communication with the MS, a connection is established with such network. At 403, the MS offloads communications to the available network via an access point. For example, the MS can tell the WiFi network (or other network) to continue the congested connection by providing quality of service (QoS) parameters when the prior network was IEEE 802.16m compliant or Quality Class Identifier (QCI) parameters when the prior network was LTE compliant. The WiFi network can use the QoS or QCI parameters in order to prioritize a connection for the MS to attempt to achieve a desired QoS or QCI. In addition, network re-entry to a WiFi network takes place which can attempt to continue a connection started using a IEEE 802.16m or LTE network. The MS can offload fully or partially the DL or UL traffic to the available network. At 404, the MS informs the BS to close down the UL or DL service flow with the MS that is fully offloaded to the available network. For partial offload of the DL or UL traffic to the available network, if the MS has two radios, then both connections can remain active. But if the MS has one radio, the MS can discontinue the connection on the former network.

The following describes activities of module 304 of FIG. 3 in response to a congestion report message 501. Referring to FIG. 5, at 501, an MS receives a congestion report message from a BS. At 502, an MS can perform scanning to find out other base stations in the same network (e.g., WiMAX (e.g., IEEE 802.16 and variations thereof) or LTE) that are not experiencing congestion in the DL or UL. An MS can adjust its scan cycle to find another frequency more or less frequently or enter scanning mode even if a scanning threshold is not crossed. A scanning threshold can be a particular BS signal strength level. If a BS signal strength is too low, then a MS might enter scanning mode. In some cases, regardless of whether the BS signal strength is too low, the MS can adjust its scan cycle.

An MS can also listen for a BS's UL or DL congestion message during scanning to determine whether to switch to another frequency. If the other frequency is indicated as congested in a direction (i.e., UL or DL) that is to be used by the MS, then the MS might not switch to that frequency. However, in some cases, an MS can switch to another frequency and then listen for congestion messages.

At 503, the MS requests handover from a first BS to a second BS in the network. In accordance with applicable protocols, the first and second BS communicate to change a BS of the MS.

The following describes activities of module 306 of FIG. 3 in response to a congestion report message 601. In FIG. 6, at 601, an MS receives a congestion report message from a BS. At 602, the MS can request a new sleep cycle from the BS. At 603, the MS can receive a sleep cycle response from the BS. If the MS complies with WiMAX, the MS can request to go to sleep. In 802.16m draft 8 (2010), a sleep request message is AAI-SLP-REQ and the response message is AAI-SLP-RSP (section 16.2). If the MS complies with LTE, the MS can enter discontinuous reception (DRX) mode instead of sleep mode.

Instead of contending for a congested channel and wasting power in the process, the MS can go to sleep, consume less power, power down components to save power until the next congestion message or for a certain amount of time, or buffer UL traffic depending upon the maximum tolerated delay of the applications it is servicing at the time. In some cases, the MS may not send a congestion message to the BS until another congestion report is received indicating no UL congestion. The MS can re-awaken periodically to determine whether a better opportunity to access the channel has arisen (e.g., the relevant channel is not as congested).

In response to reported DL congestion, a transmitter can resend all related packets. For example, if 10 packets are expected to be received and 9 packets were received, the MS can request resending all 10 packets. If all 10 packets are not received, MS can flush 9 packets and wait for receipt of all 10 packets. However, in some embodiments, in response to reported DL congestion, the MS may not flush packets in a group, request retransmission of packets in the group, or request transmission of another ACK (in case the ACK message was lost) but instead, the MS may freeze its state and wait until congestion is resolved. To determine whether congestion is resolved, in WiMax, a DL-MAP message indicates usage of the DL whereas in LTE, a preamble indicates DL usage. DL usage can indicate whether congestion is resolved. For example, reduced DL usage can indicate congestion is resolved.

In response to reported UL congestion, an application layer may cause packets to decrease in transmission rate and decrease a rate specified in UL bandwidth requests to the BS. In WiMax, an MS can use a bandwidth request mechanism to request UL bandwidth from a BS. In LTE, an MS can use a scheduling request (SR) to request UL bandwidth from a BS. In either case, the rate requested in a bandwidth request can be decreased. In some cases, a MAC layer also slows a packet transmission rate.

FIG. 7 depicts an example system in which an MS initiates reporting to a BS regarding quality of experience (QoE) for each application that uses a network. Each application experiences its own congestion on the wireless network. For example, voice over IP (VoIP) applications can be the most sensitive to delays caused by congestion. For download using a file transfer protocol (FTP), QoE can be response time (i.e., time to finish download). For video, QoE can be jitter (i.e., frames violated per second). For audio, QoE can be medium opinion score. Each application that uses the wireless network provides a QoE to a MAC layer (not shown) in the WiMax NIC and the MAC layer transmits the QoE to a base station. For example, during network initiation, capability information transmitted using a MAC message can be used to transmit QoE.

In response to the QoE reports from the MS, the BS can prioritize scheduling service flows of applications. Each application has a service flow from an MS to the BS. Using the indication from the client about the currently experienced QoE, the BS can use its scheduler to make the decision to prioritize traffic to deliver acceptable QoE to applications.

FIG. 8 depicts an example of a congestion detection system. When this system is used at a BS, the system measures DL congestion. When this system is used at an MS, the system measures UL congestion.

Packet queue 802 can be responsible for storing packets before they can be transmitted over the air interface via a wireless network to another device. Channel access control 804 can be responsible for scheduling when a packet in queue 802 is to be transmitted and also how to transmit the packet (based on scheduling set by a BS). Channel access control 804 can also be responsible for collecting and providing queuing delay information.

Congestion detection control 806 can be responsible for generating a binary indicator, C, with 0 or 1 to indicate respective no congestion or congestion on the link. In some embodiments, a queuing delay is measured as a time interval between the arrival of a packet at packet queue 802 and the first transmission of the packet triggered by channel access control 804. In some cases, if x packets have been waiting in a packet queue for more than a high packet delay threshold, Q1, then the link is considered congested. In some cases, x is 1 and Q1 is 500 ms, although other values can be used. In some cases, if y packets have been waiting in a packet queue for less than a low packet delay threshold, Q2, then the link is considered not congested. In some cases, y=10 and Q2 is 100 ms, although other values can be used.

The following congestion detection pseudo code can be used to update the value of congestion indicator, C:

If (q > or = Q1)
{
x = x + 1;
y = 0;
if (x > or = P1)
{
C = 1;
}
}
else
{
if (q < or = Q2)
{
y = y + 1;
x = 0;
if (y > or = P2)
{
C = 0;
}
}
}

where:

• • q denotes the queuing delay (ms) of how long a packet has been in packet queue 802;
  • x represents a high packet count; and
  • y represents a low packet count.
    Both x and y are set to 0 in initialization. Variable C=1 indicates congestion is detected.

The following thresholds can be used in congestion detection control:

• • Q1: the high packet delay threshold, e.g. 500 ms
  • Q2: the low packet delay threshold, e.g. 100 ms
  • P1: the high packet count threshold, e.g., 1
  • P2: the low packet count threshold, e.g., 10.

FIG. 9 depicts an example of how queuing delay and congestion indicator can be related. A high delay threshold and low delay threshold are used as criteria to determine whether the network is congested or not and the packet count threshold is used to minimize the impact of random event and avoid oscillation.

Referring again to FIG. 8, an Application Programming Interface (API) is responsible for exposing the information collected by congestion detection control 806 to applications. For example, applications can use the information to determine whether to request transmission of content on a channel.

A BS can respond to congestion on its DL by broadcasting a congestion report to all MS. An application can create a congestion report and request a MAC layer (not depicted) to transmit a congestion report in a MAC message. In addition or alternatively, a BS can react to congestion on its DL by prioritizing important packets. A MAC layer can prioritize packets. In some cases an application can inform the MAC layer of priority of packets based on a priority field in an IP header. The most important packets can be decided by packet size specified in IP header, for example, in a manner as described in U.S. Patent Application No. ______, filed ______ (attorney docket number P33587).

An MS can respond to UL congestion by letting application layers know of the congestion and the applications can lower a source rate of packets to a packet queue, inter-packet time, or request transmission at a lower rate. In some cases, an MS can respond to UL congestion by prioritizing packets.

FIG. 10 provides an example of a system in accordance with an embodiment. Computer system 1000 may include host system 1002 and display 1022. Computer system 1000 can be implemented in a handheld personal computer, mobile telephone, set top box, or any computing device. Any type of user interface is available such as a keypad, mouse, and/or touch screen. Host system 1002 may include chipset 1005, processor 1010, host memory 1012, storage 1014, graphics subsystem 1015, and radio 1020. Chipset 1005 may provide intercommunication among processor 1010, host memory 1012, storage 1014, graphics subsystem 1015, and radio 1020. For example, chipset 1005 may include a storage adapter (not depicted) capable of providing intercommunication with storage 1014.

Processor 1010 may be implemented as Complex Instruction Set Computer (CISC) or Reduced Instruction Set Computer (RISC) processors, x86 instruction set compatible processors, multi-core, or any other microprocessor or central processing unit. In various embodiments, processor 1010 performs instructions that perform some of the embodiments described herein.

Host memory 1012 may be implemented as a volatile memory device such as but not limited to a Random Access Memory (RAM), Dynamic Random Access Memory (DRAM), or Static RAM (SRAM). Storage 1014 may be implemented as a non-volatile storage device such as but not limited to a magnetic disk drive, optical disk drive, tape drive, an internal storage device, an attached storage device, flash memory, battery backed-up SDRAM (synchronous DRAM), and/or a network accessible storage device.

Graphics subsystem 1015 may perform processing of images such as still or video for display. An analog or digital interface may be used to communicatively couple graphics subsystem 1015 and display 1022. For example, the interface may be any of a High-Definition Multimedia Interface, DisplayPort, wireless HDMI, and/or wireless HD compliant techniques. Graphics subsystem 1015 could be integrated into processor 1010 or chipset 1005. Graphics subsystem 1015 could be a stand-alone card communicatively coupled to chipset 1005.

Radio 1020 may include one or more radios capable of transmitting and receiving signals in accordance with applicable wireless standards such as but not limited to any version of IEEE 802.11 and IEEE 802.16. For example, radio 1020 may include at least a physical layer interface and media access controller.

Embodiments of the present invention may be implemented as any or a combination of: one or more microchips or integrated circuits interconnected using a motherboard, hardwired logic, software stored by a memory device and executed by a microprocessor, firmware, an application specific integrated circuit (ASIC), and/or a field programmable gate array (FPGA). The term “logic” may include, by way of example, software or hardware and/or combinations of software and hardware.

Embodiments of the present invention may be provided, for example, as a computer program product which may include one or more machine-readable media having stored thereon machine-executable instructions that, when executed by one or more machines such as a computer, network of computers, or other electronic devices, may result in the one or more machines carrying out operations in accordance with embodiments of the present invention. A machine-readable medium may include, but is not limited to, floppy diskettes, optical disks, CD-ROMs (Compact Disc-Read Only Memories), and magneto-optical disks, ROMs (Read Only Memories), RAMs (Random Access Memories), EPROMs (Erasable Programmable Read Only Memories), EEPROMs (Electrically Erasable Programmable Read Only Memories), magnetic or optical cards, flash memory, or other type of media/machine-readable medium suitable for storing machine-executable instructions.

The drawings and the forgoing description gave examples of the present invention. Although depicted as a number of disparate functional items, those skilled in the art will appreciate that one or more of such elements may well be combined into single functional elements. Alternatively, certain elements may be split into multiple functional elements. Elements from one embodiment may be added to another embodiment. For example, orders of processes described herein may be changed and are not limited to the manner described herein. Moreover, the actions of any flow diagram need not be implemented in the order shown; nor do all of the acts necessarily need to be performed. Also, those acts that are not dependent on other acts may be performed in parallel with the other acts. The scope of the present invention, however, is by no means limited by these specific examples. Numerous variations, whether explicitly given in the specification or not, such as differences in structure, dimension, and use of material, are possible. The scope of the invention is at least as broad as given by the following claims.

Claims

1. A method performed by a computer system, the method comprising:

receiving link congestion information of a link on a wireless network and

determining an action to perform in response to the congestion information.

2. The method of claim 1, wherein link congestion information is received in reserved bits of one of a Primary Super Frame header message, a Secondary Super Frame header, or a physical downlink control channel (PDCCH) message.

3. The method of claim 1, wherein link congestion information is described using one bit.

4. The method of claim 1, wherein link congestion information is described using multiple bits.

5. The method of claim 1, wherein the action is selected from a group consisting of: requesting to obtain communications from another wireless network, identifying another base station in the wireless network, and entering wait mode.

6. The method of claim 1, further comprising:

receiving from a base station an indication of an action to perform.

7. The method of claim 1, further comprising:

determining quality of experience of at least one application based in part on downlink channel quality and

requesting transmission of the quality of experience of at least one application to a base station.

8. The method of claim 1, wherein link congestion information is based in part on a time packets are queued and a number of packets that are queued.

9. A method performed by a computer system, the method comprising:

determining congestion on one or more of an up link or a down link and

requesting transmission of a congestion report based on the determined congestion.

10. The method of claim 9, wherein the determining congestion comprises one or more of:

determining whether all channels on a link are used and

determining whether a percentage of channels on a link are allocated and determining whether the percentage exceeds a threshold.

11. The method of claim 9, wherein the requesting transmission comprises:

requesting transmission of the congestion report in reserved bits of a message, the message comprising one or more of: a Primary Super Frame header message, a Secondary Super Frame header, or a physical downlink control channel (PDCCH) message

12. The method of claim 9, further comprising:

requesting transmission of an indication of an action to perform, wherein the action is selected from a group consisting of: requesting to obtain communications from another wireless network, identifying another base station in the wireless network, and entering wait mode.

13. A mobile station comprising:

a display device and

a computing system communicatively coupled to the display device, the computer system configured to: receive link congestion information of a link on a wireless network and determine an action to perform in response to the congestion information.

14. The mobile station of claim 13, wherein link congestion information is received in reserved bits of one of a Primary Super Frame header message, a Secondary Super Frame header, or a physical downlink control channel (PDCCH) message.

15. The mobile station of claim 13, wherein the action is selected from a group consisting of: requesting to obtain communications from another wireless network, identifying another base station in the wireless network, and entering wait mode.

16. The mobile station of claim 13, wherein the computer system is also configured to:

determine quality of experience of at least one application based in part on downlink channel quality and

request transmission of the quality of experience of at least one application to a base station.

17. A base station comprising:

one or more antennas;

a radio; and

a computing system communicatively coupled to the display device, the computer system configured to: determine congestion on one or more of an up link or a down link and request transmission of a congestion report based on the determined congestion.

18. The base station of claim 17, wherein to determine congestion, the computer system is to perform one or more of:

determine whether all channels on a link are used and

determine whether a percentage of channels on a link are allocated and determine whether the percentage exceeds a threshold.

19. The base station of claim 17, wherein to request transmission of a congestion report, the computer system is to request transmission of a congestion report in reserved bits of a message, the message comprising one or more of: a Primary Super Frame header message, a Secondary Super Frame header, or a physical downlink control channel (PDCCH) message.

20. The apparatus of claim 17, wherein the computer system is further configured to:

request transmission of an indication of an action to perform, wherein the action is selected from a group consisting of: requesting to obtain communications from another wireless network, identifying another base station in the wireless network, and entering wait mode.