Message-based coexistence interface between wireless devices

A coexistence mechanism for arbitrating between performing operations associated with a first network device and performing operations associated with a second network device coupled to the first network device. The start time of a scheduled operation associated with a second network device is determined based, at least in part, on an activity report message received at a first network device from the second network device. A scheduled operation associated with the first network device is performed if the scheduled operation associated with the first network device can be performed prior to the start time of the scheduled operation associated with the second network device. Otherwise, the priority of the scheduled operation associated with the first network device is compared to the priority of the scheduled operation associated with the second network device to determine whether to grant control of the transmission channel to the first or second network device.

BACKGROUND

Embodiments of the inventive subject matter generally relate to the field of wireless communication systems, and, more particularly, to a coexistence interface between wireless local area network (WLAN) and Bluetooth® devices.

In wireless networks, WLAN and Bluetooth devices that are not located at close proximities from one another can avoid interference by various techniques. For example, a Bluetooth® device can implement Adaptive Frequency Hoping (AFH) to avoid frequencies within an operating frequency band associated with a WLAN device. In cases where the WLAN and Bluetooth® devices are located at close proximities from one another, or even co-located within the same wireless device or circuit board, alternative coexistence techniques are typically implemented to avoid interference between transmissions of the WLAN and Bluetooth® devices. For example, collaborative coexistence techniques may be implemented where the WLAN and Bluetooth® devices exchange information to avoid transmitting data at the same time.

SUMMARY

Various embodiments are disclosed of a method for arbitrating between performing operations associated with a first network device and performing operations associated with a second network device coupled to the first network device. In one embodiment, a start time of a scheduled operation associated with a second network device is determined based, at least in part, on an activity report message received at a first network device from the second network device. It is determined whether a scheduled operation associated with the first network device can be performed prior to the start time of the scheduled operation associated with the second network device based, at least in part, on a transaction time associated with the scheduled operation associated with the first network device. The scheduled operation associated with the first network device is performed if the scheduled operation associated with the first network device can be performed prior to the start time of the scheduled operation associated with the second network device.

DESCRIPTION OF EMBODIMENT(S)

The description that follows includes exemplary systems, methods, techniques, instruction sequences and computer program products that embody techniques of the present inventive subject matter. However, it is understood that the described embodiments may be practiced without these specific details. For instance, although examples refer to a coexistence interface for WLAN and Bluetooth® devices, in other embodiments the coexistence interface may be implemented for other wireless standards, e.g., WiMAX based on the IEEE 802.16 standard. In other instances, well-known instruction instances, protocols, structures and techniques have not been shown in detail in order not to obfuscate the description.

In various embodiments, a coexistence interface mechanism for WLAN and Bluetooth® devices utilizes the periodicity of some Bluetooth® data traffic to arbitrate between performing WLAN data transmission operations and Bluetooth® data transmission operations. In one example, a Bluetooth® device sends an activity report message to a WLAN device including timing information (e.g., start time and duration) associated with a scheduled Bluetooth® operation. The activity report message also comprises priority information associated with the scheduled Bluetooth® operation. Based on this timing and priority information, the coexistence interface mechanism implements an arbitration process to determine whether the WLAN device or the Bluetooth® device is granted control of the transmission channel for performing a scheduled operation. The coexistence interface mechanism may improve coexistence between WLAN and Bluetooth® devices that are located at close proximities to one another by arbitrating between performing WLAN data transmission operations and Bluetooth® data transmission operations. Furthermore, the coexistence interface mechanism may improve system performance by offloading coexistence processing from application processors and may save power by delaying performance of lower priority operations that would typically be interrupted by higher priority operations. In some embodiments, coexistence between WLAN and Bluetooth® devices may also be improved by sending Quality of Service (QoS) allocation report messages between the devices and/or sending frequency report messages from the WLAN device to the Bluetooth® device, as will be further described below.

FIG. 1depicts a conceptual diagram of one embodiment of a system for implementing a message-based coexistence mechanism between a WLAN device110and a Bluetooth® device120. As illustrated, in one implementation, the WLAN device110and the Bluetooth® device120may be located on the same circuit100, e.g., a circuit board, system-on-a-chip, etc. The circuit100may be included within an electronic device, e.g., a mobile phone192. It is noted, however, that in other embodiments the WLAN device110and the Bluetooth® device120may be located on different circuits, e.g., on separate circuit boards within a computer system. It is further noted that the circuit100may be included within various types of electronic devices, such as personal computers, laptops, and portable media devices. The WLAN device110and the Bluetooth® device120can perform WLAN and Bluetooth® data transmission operations, respectively, to communicate with one or more electronic devices via a wireless network. For example, the WLAN device110may send data to and receive data from an access point194and a laptop195, and the Bluetooth® device120may send data to and receive data from the laptop195and the Bluetooth® headset196. In various embodiments, a data traffic arbitration mechanism may be implemented in the WLAN device110and the Bluetooth® device120for determining whether to grant control of the transmission channel to the WLAN device110or the Bluetooth® device120to achieve coexistence between the devices, as will be further described below.

In one embodiment, the WLAN device110and the Bluetooth device120may utilize separate antennas. In this embodiment, the data traffic arbitration mechanism granting control of the transmission channel may comprise enabling the antenna (and/or corresponding transceiver circuitry) associated with one of the devices (e.g., the WLAN device110to allow the device to perform data transmission operations, and disabling the antenna (and/or corresponding transceiver circuitry) associated with the other device (e.g., the Bluetooth® device120). In another embodiment, the WLAN device110and the Bluetooth® device120may share a single antenna. In this embodiment, the data traffic arbitration mechanism granting control of the transmission channel may comprise granting access to the shared antenna to one of the devices (e.g., the WLAN device110to allow the device to perform data transmission operations, and denying access to the shared antenna to the other device (e.g., the Bluetooth® device120).

As illustrated, in one specific implementation, the WLAN device110includes a processing unit130, a transceiver unit135, an arbitration unit150, a legacy arbitration unit170, and a multiplexer155. The Bluetooth® device120includes a processing unit140, a transceiver unit145, an arbitration unit160, a legacy arbitration unit180, and a multiplexer165. The WLAN device110may operate according to the IEEE 802.11 specification and one or more of the corresponding IEEE 802.1x amendments, e.g., the IEEE 802.11b/g/n amendments. The Bluetooth® device120may operate in accordance with one or more specifications, such as those set forth by the Bluetooth Special Interest Group.

The arbitration unit150of the WLAN device110is coupled to the arbitration unit160of the Bluetooth® device120via a plurality of input/output (I/O) lines. For example, the arbitration unit150is coupled to the arbitration unit160via four I/O lines. In one specific example, the arbitration unit150may provide a data signal and a clock signal to the arbitration unit160via two I/O lines, and may receive a data signal and a clock signal from the arbitration unit160via two additional I/O lines. To implement the coexistence technique, the WLAN device110and the Bluetooth® device120may send control and informational messages via the data I/O lines. For example, the devices may send 64-bit packets having a message and other information, such as packet integrity check bits (e.g., CRC-16). It is noted, however, that the number of I/O lines between the arbitration unit150and the arbitration unit160may vary from one implementation to another. It is further noted that in other embodiments the WLAN and Bluetooth® devices may communication by other means, e.g., 32-bit packets, or by both packetized data and level signals.

During operation, as shown at stage A, the arbitration unit160of the Bluetooth® device120provides an activity report message to the arbitration unit150of the WLAN device110. The activity report message includes a start time, duration, and priority of a scheduled operation associated with the Bluetooth® device120. At stage B, the arbitration unit150performs arbitration functions to determine whether to grant control of the transmission channel to the WLAN device or the Bluetooth® device, as will be described further below with reference toFIGS. 2-3B. Both the arbitration unit150and160may be implemented in software and/or hardware. For example, the arbitration units may comprise a plurality of state machines to perform the arbitration functions described below.

Based on the arbitration results, for transmit operations, either the processing unit130of the WLAN device110or the processing unit140of the Bluetooth® device120processes data associated with a scheduled data transmission operation. For example, the processing unit may load the transmission data from memory and may convert the data from digital to analog form. In other implementations, the data associated with the scheduled data transmission operation has already been processed and is ready for transmission. At stage C, either the transceiver unit135or the transceiver unit145performs the corresponding scheduled data transmission operation associated with the WLAN device110or the Bluetooth® device120, respectively. For example, the transceiver unit may filter and amplify the analog signal, and may transmit the signal via an antenna. In another example, the transceiver unit may receive an analog signal associated with the scheduled data transmission operation. For the WLAN device110, the data transmission operation may be various types of WLAN transmissions, for example, traffic related to link stability, such as beacon transmissions, and for the Bluetooth® device120, the data transmission operation may be various types of Bluetooth® transmissions, for example, synchronous connection-oriented (SCO) traffic and extended SCO (eSCO) traffic.

As illustrated, in one implementation, the WLAN device110includes the multiplexer155for switching between the arbitration unit150and the legacy arbitration unit170. The Bluetooth® device120includes the multiplexer165for switching between the arbitration unit160and the legacy arbitration unit180. In this implementation, the option to switch to the legacy arbitration units may help ensure compatibility with other industry coexistence techniques. It is noted, however, that in other embodiments the WLAN device110and the Bluetooth® device120may not include the legacy arbitration units170and180and the multiplexers155and165.

It should be noted that the components described with reference toFIG. 1are meant to be exemplary only, and are not intended to limit the inventive subject matter to any specific set of components or configurations. For example, in various embodiments, one or more of the components described may be omitted, combined, modified, or additional components included, as desired. For instance, in some embodiments the WLAN device110and the Bluetooth® device120may each be circuits within a system-on-a-chip (SoC), and may share a single antenna and/or may share at least some of the transceiver circuitry in the analog front end (AFE). In other embodiments, the coexistence techniques described herein may be implemented within other types of wireless devices, e.g., WiMAX, ZigBee®, and Wireless USB devices.

FIG. 2depicts an example flow diagram of a method for arbitrating between performing operations associated with the WLAN device110and performing operations associated with the Bluetooth® device120. At block210, a priority, start time, and duration of a scheduled operation associated with the Bluetooth® device120is determined based, at least in part, on an activity report message received from the Bluetooth® device120via a data I/O line. In one example, the arbitration unit150of the WLAN device receives the activity report message from the Bluetooth® device120and determines the priority, start time, and duration of the scheduled Bluetooth® operation based, at least in part, on data included within the message.

In one implementation, in order to generate the activity report message, the arbitration unit160of the Bluetooth® device120identifies a scheduled Bluetooth® operation and determines the priority, start time, and duration associated with the scheduled operation. In one example, the priority of the scheduled Bluetooth® operation may be determined from a lookup table that maps each type of Bluetooth® traffic to a priority weight. For instance, a range of priority weights 0-7 may be used, where a priority weight of 0 is assigned to the lowest priority traffic and a priority weight of 7 is assigned to the highest priority traffic. In one example, link polling transmissions to prevent losing a link or to recover a lost link may be considered critical traffic and therefore may be assigned the highest priority weight, e.g., a priority weight 7. Also, in this example, synchronous connection-oriented (SCO) traffic may be assigned a priority weight 5, and channel assessment transmissions may be assigned a priority weight 3. In some implementations, a similar priority scheme may be used to determine the priority of the different types of WLAN traffic, e.g., a priority weight of 7 may be assigned for transmissions related to link stability. It is noted, however, that in other implementations the priority of Bluetooth® and/or WLAN traffic may be determined by other methods, e.g., the priority may be predetermined by the Bluetooth® or WLAN scheduling engine or other processing engine. In one embodiment, the priority information may be encoded within the activity report message using a plurality of bits, e.g., three or four bits.

The start time information included within the activity report message may indicate the start time of the scheduled Bluetooth® operation. In one example, the start time information may be an encoded time value (e.g., measured in μs) that indicates the amount of time from the falling edge of the clock signal associated with the activity report message to the start of the scheduled Bluetooth® operation. In one implementation, the arbitration unit150of the WLAN device110may track the amount of time that has expired from the falling edge of the clock signal associated with the activity report message and compare it to the start time value to determine how much time remains until the start of the scheduled Bluetooth® operation. The duration information included within the activity report message may indicate the duration of the scheduled Bluetooth® operation, which is typically known ahead of time by the Bluetooth® device120.

At block220, it is determined whether a scheduled data transmission operation associated with the WLAN device110can be performed (i.e., executed and completed) prior to the start time of the scheduled Bluetooth® data transmission operation based, at least in part, on a transaction time associated with the scheduled WLAN operation. As described above, in one implementation, the arbitration unit150of the WLAN device110may track the amount of time that passes by from the falling edge of the clock signal associated with the activity report message and compare it to the start time value to determine how much time remains until the start of the scheduled Bluetooth® operation. The arbitration unit150may then compare the transaction time associated with the scheduled WLAN operation to the amount of time remaining until the start of the scheduled Bluetooth® operation to determine whether the scheduled WLAN operation can be performed prior to the start of the scheduled Bluetooth® operation.

FIG. 3Adepicts an example timing diagram showing when a scheduled WLAN operation can be performed prior to the start of the scheduled Bluetooth® operation. The timing diagram shows a point A indicating the point in time corresponding to the falling edge of the clock signal associated with the activity report message, and a point B indicating the point in time when the scheduled WLAN device is detected by the arbitration unit150. After point B, the arbitration unit150can determine the transaction time associated with the scheduled WLAN operation and then determine whether the scheduled WLAN operation can be performed (i.e., executed and completed) prior to the start of the scheduled Bluetooth® operation. In the example shown inFIG. 3A, the arbitration unit150will determine that the scheduled WLAN operation can be completed prior to the start of the scheduled Bluetooth® operation.FIG. 3Bdepicts an example timing diagram showing when scheduled WLAN operation cannot be performed prior to the start of the scheduled Bluetooth® operation. In some cases, the amount of time between the reception of the activity report message and the start of the scheduled Bluetooth® operation may be relatively short, the transaction time of the scheduled WLAN operation may be relatively long, and/or the point in time when the scheduled WLAN operation is detected may be too close to the start time of the scheduled Bluetooth® operation. In the example shown inFIG. 3B, the arbitration unit150will determine that the scheduled WLAN operation cannot be completed prior to the start of the scheduled Bluetooth® operation.

Returning toFIG. 2, if the scheduled WLAN operation can be performed prior to the start time of the scheduled Bluetooth® operation, at block240, the WLAN device110is granted control of the transmission channel. For example, the arbitration unit150may provide a control signal to the processing unit130and/or the transceiver unit135to indicate that the WLAN device110has been granted control of the transmission channel. It is noted, however, that in other implementations the arbitration unit150may also store a value in a register of the WLAN device110to indicate control of the transmission channel has been granted. At block250, the scheduled WLAN data transmission operation is performed. For example, the transceiver unit135may perform the operation by transmitting the WLAN data via an antenna to a receiving entity (e.g., access point194).

If the scheduled WLAN operation cannot be performed prior to the start time of the scheduled Bluetooth® operation, at block230, the priorities of the scheduled operations (e.g., the assigned priority weights) are compared to determine whether the priority associated with the scheduled WLAN operation is higher than the priority associated with the scheduled Bluetooth® operation. If the priority of the scheduled WLAN operation is higher than or the same as the priority associated with the scheduled Bluetooth® operation, at block240, the WLAN device110is granted control of the transmission channel. Furthermore, in this example, the arbitration unit150may provide an activity denied message to the Bluetooth® device120to indicate that control of the transmission channel has been denied due to priority arbitration and therefore the scheduled Bluetooth® operation will be delayed or cancelled. At block250, the scheduled WLAN data transmission operation is performed. It is noted, however, that in some implementations, if the priority of the scheduled WLAN operation is the same as the priority associated with the scheduled Bluetooth® operation, the Bluetooth® device120may be granted control of the transmission channel.

If the priority of the scheduled WLAN operation is lower than the priority associated with the scheduled Bluetooth® operation, at block260, the Bluetooth® device120is granted control of the transmission channel. In this example, the arbitration unit150may provide a control signal to the processing unit130and/or the transceiver unit135to indicate that the WLAN device110has been denied control of the transmission channel and therefore to delay performing the scheduled WLAN data transmission operation. It is noted that in this example the arbitration unit150may not send a message (e.g., the activity denied message) to the Bluetooth® device120. If the Bluetooth® device120does not receive a message, then the Bluetooth® device120is allowed to perform the scheduled operation. It is noted, however, that in other embodiments the arbitration unit150may provide an activity grated message to the Bluetooth® device120to indicate that control of the transmission channel has been granted to the Bluetooth® device120. In this example, instead of initiating the WLAN operation and suspending the WLAN operation due to the higher priority Bluetooth® traffic, power is saved by delaying performance of the lower priority WLAN operation until it can be completed.

In various embodiments, the arbitration unit160of the Bluetooth device120generates and sends the activity report message immediately after a scheduled Bluetooth® operation is detected by the arbitration unit160. This may provide the WLAN device110adequate time to perform scheduled WLAN operations during idle periods of the Bluetooth® device120, especially if the priority of the scheduled Bluetooth® operations is higher than the priority of the scheduled WLAN operations. In some implementations, an activity report message is sent before each scheduled Bluetooth® transmission, i.e., both Bluetooth® transmit and receive operations. In other implementations, e.g., for deterministic Bluetooth® traffic, such as SCO and eSCO traffic, a single activity report message can be sent to inform the WLAN device110about multiple Bluetooth® operations. By providing the start time and duration information (in addition to the priority information), the WLAN device110can calculate the start time for the various Bluetooth® operations. The arbitration unit150of the WLAN device110can still check whether WLAN operations can be performed during Bluetooth® idle periods and also compare the priority of the scheduled traffic. If a scheduled WLAN operation has a higher priority than a scheduled Bluetooth® operation, then the multiple Bluetooth® operations may be interrupted, and a new activity report message can be sent when the Bluetooth® device120once again gains control of the transmission channel.

FIG. 4depicts an example flow diagram of a method for processing Quality of Service (QoS) allocation information. In one embodiment, the WLAN device110and the Bluetooth® device120exchange QoS allocation report messages to determine whether a desired amount of time is being allotted for transmission of WLAN traffic and a desired amount of time is being allotted for transmission of Bluetooth® traffic. The WLAN device110sends QoS allocation report messages to the Bluetooth® device120, and the Bluetooth® device120sends QoS allocation report messages to the WLAN device110, via the corresponding data I/O lines, to determine whether a desired time allocation quota is being maintained between WLAN and Bluetooth® traffic. In other words, the QoS information may help maintain a desired balance between WLAN and Bluetooth® traffic, as will be described further below.

In one implementation, both the WLAN device110and the Bluetooth device120implement the QoS processes illustrated inFIG. 4. It is noted that the WLAN and Bluetooth® devices may perform the QoS process concurrently or at different times. At block410, it is determined whether a predetermined amount of time has elapsed since the QoS process was initiated or since the last QoS allocation report message was sent. If the predetermined amount of time has not elapsed, then the process loops back to the beginning and restarts. If the predetermined amount of time has elapsed, at block420, it is determined how many data packets where transmitted during the predetermined amount of time. For example, the arbitration unit150of the WLAN device110determines how many data packets were transmitted in the WLAN data transmission operation performed during the predetermined amount of time, and the arbitration unit160of the Bluetooth® device120determines how many data packets were transmitted in Bluetooth® data transmission operation performed during the predetermined amount of time. It is noted that the predetermined amount of time may be programmable.

At block430, a QoS allocation report is provided to the WLAN device110or the Bluetooth® device120including QoS allocation information. For example, the arbitration unit150of the WLAN device110provides the arbitration unit160of the Bluetooth® device120QoS allocation information based on how many WLAN data packets were transmitted during the predetermined amount of time, and the arbitration unit160of the Bluetooth® device120provides the arbitration unit150of the WLAN device110QoS allocation information based on how many Bluetooth® data packets were transmitted during the predetermined amount of time. In one specific implementation, based on the detected number of packets that were transmitted during the predetermined amount of time, the arbitration unit150calculates a QoS allocation percentage value indicating the percentage of the predetermined amount of time that was allocated to the transmission of WLAN traffic, and the arbitration unit160calculates a QoS allocation percentage value indicating the percentage of the predetermined amount of time that was allocated to the transmission of Bluetooth® traffic. In this implementation, the QoS allocation information included within the QoS allocation report messages includes at least the calculated QoS allocation percentage value. It is noted, however, that in other implementations the QoS allocation report messages may include additional information or different information, e.g., the QoS allocation report messages may instead include the number of transmitted data packets and the receiving device may calculate the QoS allocation percentage value.

At block440, it is determined whether a desired QoS allocation has been met during the predetermined amount of time. In one implementation, the desired QoS allocation indicates the desired QoS allocation percentage value for WLAN traffic and for Bluetooth® traffic. For example, a 50/50 desired QoS allocation may specify a 50% QoS allocation percentage value for WLAN traffic and a 50% QoS allocation percentage value for Bluetooth® traffic. In another example, a 60/40 desired QoS allocation may specify a 60% QoS allocation percentage value for WLAN traffic and a 40% QoS allocation percentage value for Bluetooth® traffic. It is noted that the desired QoS allocation may be programmable. If the desired QoS allocation has been met, the process loops back to the beginning and restarts. In one embodiment, the desired QoS allocation is considered to have been met if the actual percentage values are 3% higher or lower than the desired values. For example, if the desired QoS allocation is 50/50 and the actual QoS allocation is 53/47, then the desired QoS allocation is considered to have been met. It is noted, however, that in other embodiments, the desired QoS allocation is considered to have been met if the actual percentage values are a programmable percentage higher or lower than the desired values, e.g., 1% or 5%.

If the desired QoS allocation has not been met, at block450, the WLAN and/or Bluetooth® priorities are modified to change the actual QoS allocation to be more in line with the desired QoS allocation. For example, if the desired QoS allocation is 50/50 and the actual QoS allocation is 40/60, this indicates that the Bluetooth® throughput needs to be reduced and the WLAN throughput needs to be increased to improve the QoS allocation. In this example, the arbitration unit150may modify the priority associated with WLAN data traffic to help ensure that more WLAN operations are performed. In other words, WLAN operations may be assigned higher priorities than Bluetooth® operations so that more WLAN operations are performed and the QoS allocation percentage value associated with the WLAN traffic is increased (and the QoS allocation percentage value associated with the Bluetooth® traffic is decreased). In some cases, the arbitration unit160may similarly modify the priority associated with Bluetooth data traffic. It is noted that in other embodiments instead of or in addition to determining whether a desired QoS allocation has been met during the predetermined amount of time, it is determined whether a desired QoS allocation goal has been met for the time period since the QoS process was initiated.

FIG. 5depicts an example flow diagram of a method for providing a frequency report message to a Bluetooth® device for improving coexistence between the WLAN and Bluetooth® devices. In one embodiment, the WLAN device110sends a frequency report messages to the Bluetooth® device120to indicate a frequency range to avoid during Bluetooth® operations. The frequency report messages may be sent directly from the WLAN device110to the Bluetooth® device120via the data I/O line.

At block510, it is determined whether a predetermined amount of time has elapsed since the frequency reporting process was initiated or since the last frequency report message was sent. If the predetermined amount of time has elapsed, at block520, a frequency report message is generated indicating the current operating frequency range associated with the WLAN device110. For example, the arbitration unit150may generate a frequency report message indicating that the WLAN device is operating within the frequency band from 2402 MHz to 2424 MHz. It is noted that the predetermined amount of time may be programmable. At block530, the generated frequency report message is provided to the Bluetooth® device120.

If the predetermined amount of time has not elapsed, at block540, it is determined whether the operating frequency associated WLAN device110has been changed. If the operating frequency associated with the WLAN device110has not been changed, then the process loops back to the beginning and restarts. If the operating frequency has been changed, at block520, a frequency report message is generated indicating the current operating frequency range associated with the WLAN device110. Then, at block530, the generated frequency report message is provided to the Bluetooth® device120.

FIG. 6depicts an example flow diagram of a method for processing a frequency report message for improving coexistence between the WLAN and Bluetooth® devices. At block610, a frequency report message is received from the WLAN device110. For example, the arbitration unit160may receive a frequency report message from the arbitration unit150. At block620, an adaptive frequency hopping (AFH) algorithm implemented by the Bluetooth® device120is programmed to avoid the current frequency range associated with the WLAN device110based on the received frequency report message. For example, if the frequency report message indicates that the WLAN device110is operating in the frequency band from 2402 MHz to 2424 MHz, the arbitration unit160programs an AFH algorithm of the Bluetooth® device120to avoid the frequencies within the specified frequency band.

At block630, it is determined whether the Bluetooth device120is communicating with an associated Bluetooth® device. For example, the arbitration unit160determines whether the Bluetooth® device120is communicating with an associated Bluetooth® headset (e.g., Bluetooth® headset196). Since the associated Bluetooth® device may be transmitting data to the Bluetooth® device120, at block640, a notification may be sent to the associated Bluetooth® device to avoid the current frequency range associated with the WLAN device110. For instance, in the example described above, the arbitration unit160may cause the transceiver unit145of the Bluetooth® device120to send a notification signal to the Bluetooth® headset196to avoid the frequencies within frequency band from 2402 MHz to 2424 MHz.

It should be understood that the depicted flowcharts are examples meant to aid in understanding embodiments and should not be used to limit embodiments or limit scope of the claims. Embodiments may perform additional operations, fewer operations, operations in a different order, operations in parallel, and some operations differently. For instance, inFIG. 2, the operations represented by block230may be performed prior to or in parallel to the operations represented by block220. InFIG. 5, operations represented by block540may be performed in parallel to or separate from to operations represented by block510. Furthermore, the coexistence techniques described above may be implemented within other types of wireless devices, e.g., a WiMAX device.

Embodiments may take the form of an entirely hardware embodiment, a software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a “circuit,” “module” or “system.” Furthermore, embodiments of the inventive subject matter may take the form of a computer program product embodied in any tangible medium of expression having computer usable program code embodied in the medium. The described embodiments may be provided as a computer program product, or software, that may include a machine-readable medium having stored thereon instructions, which may be used to program a computer system (or other electronic device(s)) to perform a process according to embodiments, whether presently described or not, since every conceivable variation is not enumerated herein. A machine readable medium includes any mechanism for storing (“machine-readable storage medium”) or transmitting (“machine-readable signal medium”) information in a form (e.g., software, processing application) readable by a machine (e.g., a computer). The machine-readable storage medium may include, but is not limited to, magnetic storage medium (e.g., floppy diskette); optical storage medium (e.g., CD-ROM); magneto-optical storage medium; read only memory (ROM); random access memory (RAM); erasable programmable memory (e.g., EPROM and EEPROM); flash memory; or other types of medium suitable for storing electronic instructions. In addition, machine-readable signal medium embodiments may be embodied in an electrical, optical, acoustical or other form of propagated signal (e.g., carrier waves, infrared signals, digital signals, etc.), or wireline, wireless, or other communications medium.

FIG. 7depicts an example wireless device. In one implementation, the wireless device may be a WLAN device. The WLAN device includes a processor unit701(possibly including multiple processors, multiple cores, multiple nodes, and/or implementing multi-threading, etc.). The WLAN device includes memory707. The memory707may be system memory (e.g., one or more of cache, SRAM, DRAM, zero capacitor RAM, Twin Transistor RAM, eDRAM, EDO RAM, DDR RAM, EEPROM, NRAM, RRAM, SONOS, PRAM, etc.) or any one or more of the above already described possible realizations of machine-readable media. The WLAN device also includes a bus703(e.g., PCI, ISA, PCI-Express, HyperTransport®, InfiniBand®, NuBus, etc.), and network interfaces705that include at least one wireless network interface (e.g., a WLAN interface, a Bluetooth® interface, a WiMAX interface, a ZigBee® interface, a Wireless USB interface, etc.). The WLAN device also includes an arbitration unit725that implements the functionalities described above with reference to arbitration unit150ofFIGS. 1-6. Any one of the above described functionalities may be partially (or entirely) implemented in hardware and/or on the processing unit701. For example, the functionality may be implemented with an application specific integrated circuit, in logic implemented in the processing unit701, in a co-processor on a peripheral device or card, etc. Further, realizations may include fewer or additional components not illustrated inFIG. 7(e.g., additional network interfaces, peripheral devices, etc.). The processor unit701and the network interfaces705are coupled to the bus703. Although illustrated as being coupled to the bus703, the memory707may be coupled to the processor unit701. In another implementation, the example wireless device shown inFIG. 7may be a Bluetooth® device that comprises the components described above with reference toFIGS. 1-7and which includes an arbitration unit725that implements the functionalities described above with reference to arbitration unit160ofFIGS. 1-6.

While the embodiments are described with reference to various implementations and exploitations, it will be understood that these embodiments are illustrative and that the scope of the inventive subject matter is not limited to them. In general, the coexistence techniques as described herein may be implemented with facilities consistent with any hardware system or systems. Many variations, modifications, additions, and improvements are possible.