GB2468540A - Arbitrating between a plurality of wireless devices requestin g access to a common frequency band - Google Patents

Abstract

An apparatus comprising means for receiving a plurality of requests from a plurality of wireless devices for access to a common wireless frequency band and means for arbitrating between said requests based on a priority of an application associated with respective requests and based on information which is based on an amount of time at least one of said devices has previously been granted access to or its history of usage of said common frequency band. It aims to overcome the problem of interference which concurrency causes when WLAN and Bluetooth standards use the same frequency band.

Description

METHOD AND APPARATUS

The present invention relates to a method and apparatus and in particular but not exclusively to a method and apparatus for arbitration.

The success of wireless technology has lead to the proliferation of wireless devices and radio standards. Some examples of standards are as follows: IEEE Standard 802.11 - 2007: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications; Specification of the Bluetooth System V2.1; IEEE 802.16e Air Interface for Fixed and Mobile Broadband Wireless Access System; and ECMA -368 High Rate Ultra-Wide PHY and MAC Standard. These standards are aiming to address the consumer's need to communicate or access information and entertainment.

The same device may offer multiple options to connect wirelessly and all or some of these options may be exercised at the same time. For example, a smart phone may be connected to a WLAN (Wireless Local Access Network) access point to connect to the Internet whilst at the same time stereo music is streamed to Bluetooth headphones. The two wireless connections used at the same time may be related. For example, a mobile telephone can be used to engage in a VoIP (Voice over Internet Protocol) call over WLAN arid use the Bluetooth headset to answer the call.

The concurrency of wireless connections which may or may not be interrelated increases the possibility for new applications. However, since radio standards such as WLAN and Bluetooth use the same 2.40Hz ISM (Industrial, Scientific and Medical) frequency band, concurrency causes interference which leads to degradation in the quality of service.

Some embodiments of the present invention may to be arranged to address or at least mitigate this.

Broadcom in a white paper entitled BCM 4325 Bluetooth and WLAN coexistence has provided a proposal for coordinating the access point behavior for the period when the Bluetooth, collocated with the WLAN station is using a shared medium.

Philips has proposed in a white paper entitled "How 802.11 bIg WLAN and Bluetooth can play". In this paper, there is a discussion about how Bluetooth and WLAN devices eollocated on the same chip die exchange information on who can access the medium next. A protocol is defined for handing over the medium from Bluetooth to WLAN and vice versa on a per packet basis.

Aspects of the invention can be seen from the appended claims.

For a better understanding of the present invention and as to how the same may be carried into effect, reference will now be made by way of example only to the accompanying drawings in which: Figure 1 shows a device using a packet traffic arbitrator PTA; Figure 2 shows an example of a traffic pattern in six cases of concurrent Bluetooth and WLAN operation at a first rate of operation; Figure 3 shows a traffic pattern in six cases of concurrent Bhietooth and WLAN operation, at a lower rate of operation; Figure 4 shows a device with a controller embodying the present invention; Figure 5 shows a finite state machine for the controller of Figure 4; and Figure 6 shows a system in which embodiments of the present invention can be incorporated.

Before describing some embodiments of the present invention, reference is first made to Figure 1 which shows a packet traffic arbitration (PTA) collaborative coexistence meàhanism. In the arrangement shown in Figure 1, two radios 2 and 4 reside on the same device 30 which may be a mobile device. The small form factor may make frequency avoidance techniques like adaptive frequency hopping less effective because of front end loading in that higher transmission power combined with the proximity of antennas is enough to saturate and desensitise the front end of the Bluetooth or WLAN RF (radio IS frequency) chains. Accordingly, time division based techniques may be employed.

Furthermore, cost considerations often lead manufacturers to multiplex a single antenna between WLAN and Bluetooth devices which means that a time division mechanism can be used to implement sharing.

The IEEE Standard 802.15.2 (Coexistence of wireless personal area networks with other wireless devices operating in the unlicensed frequency bands) describes schemes for the coexistence of IEEE 802.15 WPAN (Wireless Personal Area Network) devices such as Bluetooth devices with other wireless devices, for example those operating in accordance with IEEE 802.11 WLAN. These devices may operate in the same unlicensed ISM band.

One of the collaborative coexistence mechanisms described in the IEEE document is packet traffic arbitration, PTA which is illustrated in Figure 1.

Figure 1 shows a single device 30 which comprises a WLAN device 2 and a WPAN device 4 within the same physical unit. That coimnon physical unit 30 can, for example be a wireless device such as a mobile telephone or the like.

The WLAN device 2 comprises a media access control MAC unit 6 and a PLCP (Physical Layer Convergent Protocol) and Physical layer unit 10. Both unit 6 and unit 10 operate in accordance with, for example the IEEE Standard 802.11. The WPAN device 4 comprises a link manager unit 8 and a baseband unit 12. Both the link manager unit 8 and the base band unit 12 operate in accordance with, for example the IEEE Standard 802.15.1.

The device 30 comprises a PTA controller 14. Each device 2 and 4 is arranged to send respective requests 24 and 18 to the PTA controller 14. The PTA controller 14 is arranged to send respective responses 22 and 16 to the associated requests. The PTA controller 14 is arranged to allow or deny the requests based on, for example the known status of both of the radio devices. As can be seen from Figure 1, PTA controller 14 is arranged to receive respective status information 26 and 20 from the two devices. In the known IEEE 802.15.2 Standard, the logic which allows or denies a packet transmit request uses priority comparisons. A priority is assigned to each request. This IEEE recommendation is for any WPAN device.

S

The per packet authorisation mechanism described above enables control over which device can transmit when. However, there is an absence of any global perspective which can mean that coexistence between the Bluetooth (BT) and WLAN applications can suffer drastically.

Reference will now be made to Figures 2 to 6 which show embodiments of the present invention.

Reference is now made to Table 1

Table 1

BLUETOOTH

music streaming voice call image transfer W video E.g. downloading You-Tube streaming videos and using fiT headset to L listen to the music. I A VoIP E.g. answering Skype or e.g. fiT data Iransfer VaIP call using fiT headset (ssnchronizing.) while

N

11 answering VoIP call III local file E E.g. listening to music on fiT E.g. norrnol voice call on fiT data tronsfer together transfer headset while performing file fiT, while performing a file with WLAN FTP transfer transfer on WLAN. IV transfer on WLAN. V VI Table 1 shows a concurrency matrix for simultaneously operating Bluetooth and WLAN applications. For example, the Bluetooth applications includes music streaming, voice call and image transfer. The WLAN applications can include video streaming, VoIP arid local file transfer. Illustrated in this table are six different scenarios. These will be discussed in more detail hereinafter. It should be appreciated that these applications are by way of example only. Different applications, fewer applications and/or more applications may be provided.

The six scenarios illustrated in Table 1 are as follows.

I. Downloading videos via WLAN and using the Bluetooth headset to listen to the music.

II. Answering a VoW call using a Bluetooth headset.

III. Bluetooth data transfer while answering a VoW call.

IV. Listening to music on a Bluetooth headset whilst performing a file transfer on WLAN.

V. Normal voice call on Bluetooth while performing a file transfer on WLAN.

VI. Bluetooth data transfer together with WLAN FTP (File Transfer Protocol) transfer Table 2 shows the traffic characterisation for applications over Bluetooth and WLAN at a physical rate of 65Mbps.

Table 2

music streaming l Application characteristic: 400kbps, 44.1 kH4 MP3-L2 packets.

Transmission characteristic: Advanced Audio Distribution Profile (A2DP), 1 employing 3-Did (data handling) 3 packets which can provide a maximum forward throughput of 1766 kbps and occupies 3TN+ I RN slots.

C

C

cktarwcupyemeWnmfor4tS.Then12 are free (for IEEE 802.11 or other BT traffic) and after that another 4 slots of music.

There will be pcrformsnce degradation if consecutive packets are dropped.

voice call I Application characteristic: 64kbps in each direction Transmission characteristic: Hands Free Prolile, employing 2V3 (a BT traffic class) eSCO (synchronous connection oriented) packets which can carry 1-30 information bytes EV3 packets have retransmission. However, when the headset is legacy then 1-IV3 (a BT traffic class) packets are used which hsve no retransmission.

In that case, any packet loss causes voice quality degradatinn.

Conclusion: One EV3 packet evesy six slnt, means 30181 (6*625)41000 khps (equal i to 64kbps). Therefore, the traffic will he 2 slots (TX-RX) every 6 slots.

image transfer i Application characteristic: heal effort Transmission characteristic: variety of packet types can be employed.

Conclusion: Occasionally, BT may he denied access to the medium intemet video streaming Application characteristic: offered load 4Mbps; MSDU (MAC service data unit) sise: 512 Bytes; maximum delay 200ms; maximum Packet toss Rate (PLR) I.OOE-

II I

[Transmission characteristic: A pscket every I ms. At PHY rate of 65Mbps, the 1 packet duration is I OSus. Total time: (DIPS (Distributed Inter-Frame Space) Average Back off+ Data + SIPS (Short Inter-Frame Spsce)+ ACK) -((I 6+29) � I (9'15/2)+ 108 + lS+40)=265.Sus Conclusion: WLAN may occupy the medium 1/4 of the time I VoW flApplication characteristic: offered load 96kbps; MSDIJ size: 120 Bytes; maximum I delay 3Oms; maximum Packet Loss Rate (PLR) SE-02 Transmission characteristic: A packet every 10 its. Al PitY rate of 65Mbps, the packet duration is 6Ous. Total time: (DIFS � Average Bkoff+ Data SIPS + ACK) I ((I6+29) + (9*15/2) + 60 + 16 + 40) 217.Sus Conclusion: The medium occupancy is tow (2 t 7ua every I dma) Lccal file transfer Application characteristic: offcred load 30Mbps; MSDU size: ISOOBytes; maximum delay 3000ms Transmission characteristic: A packet every 400 us. At PHY rate of 65Mbps, the packet duration is 230us. Total time: (DIPS + Average Bkuff + Data + SIPS + ACK) = ((16+2*9) + (9*] 5/2) + 60 � 16 + 40) 387.Sus Conclusion: The medium occupancy is extremely high (387us every 400ua) In particular, the table lists the characteristics, (e.g. offered load), transmission characteristics, (e.g. packet size, transmission duration and protocol dependent timing) and provides some conclusions with respect to medium demand and occupancy.

Reference is now made to Figure 2 which based on the information shown in Table 2 provides a traffic pattern for each of the six scenarios illustrated in Table 1. At the top of the Figure is shown a time slot structure 40. As can be seen, each time slot is 625 microseconds. For each of the six scenarios, the Bluetooth traffic is shown on a first line with the WLAN traffic on the second line. For convenience, each first line is referenced 42 and each second line is referenced 44. It should be appreciated that Figure 2 is based on a physical rate of 65Mbps.

As can be seen from the scenarios illustrated in Figure 2, some of the WLAN applications have small requirements, such as the scenarios shown in cases 1, II and III. Other of the scenarios, for example when there is a WLAN FTP transfer, requires much greater use of the bandwidth. Likewise, some of the Bluetooth applications have a greater requirement for use of the bandwidth. For example, Bluetooth image transfer has a relatively high requirement for the bandwidth as compared to, for example the Bluetooth voice requirements.

Reference is made to Figure 3 which shows the traffic pattern in a case of concurrent Bluetooth and WLAN usage, but at 6 Mbps operation. As with Figure 2, the time slots 46 are shown, As with Figure 2, each time slot lasts for 625 microseconds. Again, for each of the six cases, the first line 48 illustrates the Bluetooth connection and the second line 50 illustrates the WLAN connection.

Prom Figure 2, it can be seen that except for the Bluetooth image transfer and the WLAN FTP connection, i.e. case VI, the antenna remains relatively free and any conflicts will be largely due to bad scheduling or timing. In Figure 3, the same is true except additionally the WLAN video at 4Mbps is impractical and a lower rate is required.

Consider the six cases discussed in relation to Table 1 in more detail.

Case 1 (Bluetooth music -WLAN video): As WLAN video streaming can sustain delays of up to 200 ms (Table 1), rejecting WLAN requests when Bluetooth is active will result in manageable delays (2ms-3ms) for the WLAN. WLAN packets can be transmitted once the Bluetooth transmission is over. For WLAN@PY_RATE 6Mbps, the video application rate of 4Mbps is not sustainable since in that case the WLAN device will need to occupy the medium all the time. A lower video streaming rate is required.

Case II (Bluetooth voice -WLAN VoIP): From Table 1, note that the maximum sustainable delay for WLAN VoIP is 3Oms. If WLAN requests are rejected when Bluetooth voice traffic is on-going, the delay to WLAN traffic will be in the range of 1- 2ms. This is again within the 3Oms limit.

Case III (Bluetooth image transfer -WTLAN VoIP): Rejecting WLAN VoIP requests while Bluetooth is active can be problematic, as the time that Bluetooth is not on the air is only 625us, every 625*6us period. The average VoIP packet duration is only 217us, and the WLAN device has to contend with other stations. Therefore, in this case, a higher priority is given to WLAN VoIP packets over Bluetooth image related traffic.

Case IV (Eluetooth music -WLAN FTP): In this case WLAN requests are rejected while Bluetooth is active.

Case V (Bluetooth voice -WLAN FTP): In this case WLAN requests are rejected while Bluetooth is active.

Case VI (Bluetooth image transfer -WLAN FTP): Alternating between Bluetooth and WLAN may be an option. However, Bluetooth and WLAN do not occupy the medium for the same duration (Bluetooth duration being considerably longer). A scheme that can potentially divide the time equally is used.

Reference is now made to Figure 4 which shows a schematic view of a device 60 embodying the present invention. The device 60 comprises a Bluetooth device 62 and a WLAN device 6& A PTA controller 66 is provided which is connected via connection 78 to the Bluetooth device 62 and via connection 84 to the WLAN device 64.

A PTA high level controller 70 is provided. This high level controller 70 is connected via connection 86 to the WLAN device 64. Additionally, the high level controller 70 has a first connection 80 and a second connection 82 to the PTA 66. The device further comprises a host 68 which is connected via connection 90 to the Bluetooth device 64 and via connection 88 to the WLAN device 64.

When the Bluetooth requires the medium, to transmit or receive, the Bluetooth device generates an explicit request to the PTA 66. The PTA operates on a per packet authorisation basis. In this case, IEEE 802.1 1 WLAN uses an asynchronous system so the WLAN device will not know when it will be receiving a packet. Thus, when the Bluetooth is idle, WLAN is allowed access to the medium. If the WLAN device is transmitting or receiving a packet, an appropriate priority value is attached by the WLAN device. Similarly, each Bluetooth request is accompanied by a priority value. It is left to the Bluetooth link manager (see Figure 1) and the WLAN MAC (See Figure 1) to decide what priority to associate with each packet. Thus, as priority labelling is done independently by the Bluetooth and WLAN devices, it is possible that there will be a mismatch between the priority levels.

A WLAN FTP packet may have a higher priority level than the Bluetooth object push profile packet. If FTP packet traffic is intense, Bluetooth traffic may be completely choked by the WLAN traffic.

Suppose there is music streaming over BT and FTP over WLAN, In general, BT music packets should have higher priority than WLAN FTP packets. However, if all WLAN transmissions were to be interrupted by the BT device, it is likely that the WLAN link would be dropped leading to poor user-experience. On the other hand, if WLAN FTP packets start overriding too many of the BT music transmission and re-transmissions, then there is poor coexistence from an application concurrency point of view.

Several other problematic scenarios can occur if all that was done was to compare priority levels independently set by the Bluetooth and WLAN devices to determine who is granted the medium next.

Tn the device of Figure 4, the Bluetooth and WLAN devices may share an antenna or have their own antenna.

It should be appreciated that in Figure 4, the PTA 66 will be comparing the priority level of the requests received from the Bluetooth device 62 and the WLAN device 64.

The high level controller 70 plays the role of a centralised agent to moderate the priority levels and apply other controls so that the antenna is shared in a more balanced way between the Bluetooth and WLAN devices. The HLC 70 moderates the priority levels set by the Bluetooth and WLAN devices and applies other controls so that both Bluetooth and WLAN devices are able to give a reasonable performance without impacting the traffic of the other device. The HLC uses a more global perspective based on the current and past activity of the BT and WLAN devices.

Thus the PTA makes real-time, packet-wise decisions based on a priority-comparison.

The HLC operates over a wider time-horizon. It provides a scheme whereby the priority values attached to individual BT and WLAN requests are modulated and controls on BT/WLAN usage are adjusted, so there is more balanced sharing of the medium. Based on the analysis of the traffic patterns for commonly occurring BT-WLAN coexistence scenarios, a user-experience maybe enhanced through the operation of the HLC.

The HLC 70 has a finite state machine FSM 72, a Bluetooth antenna occupancy monitor AOM 24 that tracks the percentage of airtime that the Bluetooth device has had in the past 0CC_REP_PERIOD milliseconds and a WLAN traffic manager 76 that receives performance related messages from the WLAN device and passes it to HLC.

In one embodiment of the present invention, the HLC controls on the following basis. A Bluetooth link should occupy the medium on average for at least x percent of the time if the Bluetooth link is to support high quality voice and music. Hosvever, the Bluetooth link should not be allowed to occupy the medium for more than y percent of the time if the WLAN connection is also contending for the medium and is unable to retain it successfttlly.

The values for x and y may vary from situation to situation. For example, x may be greater than 33 which means that the music and voice traffic can be transmittcd without hindrance and y may be less than 70 to ensure that WLAN video streaming applications run at good quality. The medium occupancy averaging time may be around 50 milliseconds to ensure that the coexistence engine (the FSM) reacts quickly to change but does not overreact and keep changing the arbitration policy too rapidly.

Thus, the PTA 66 acts on a packet by packet basis whereas the HLC 70 considers the situation over a longer term.

Table 4 below includes various parameters which influence the behaviour of the HLC.

Table 4

PARAMETER RANUE DEFAULT INTERPRETATION

H2L LIMIT 0-100 70 if BT occupies the antenna for a duration exceeding this percentage value, more constraints may be placed on BT acquiring and retaining the antenna L2H_LIMIT 0 -1 00 10 If BT occupies the antenna for duration lesser than this percentage valoe, more conatraints may he placed on WLAN acquiring and retaining the antenna 0CC_REP_PERIOD [-1000 10 The (in ma) time between two consecutive antenna occupancy reports EFPIL1NIIT 0-100 25 Extremely Poor Performance Indication-a percentage value PPILIM1T 0-100 40 Poor Performance Indication-a percentage value LP1LJ 0-100 55 Low Perfoance Indication -a percentage value Reference is made to Figure 5 which shows the finite state machine 72 of the high level controller. The finite state machine 72 is illustrated in Figure 5. An initial state 100 is the default state of the controller. When the high level controller is reset, the initial state is activated. In this initial state, the high level controller initialises the PTA 66 with initial values. After initialisation, the controller transits to the Bluetooth mid state 106.

In the arrangement shown in Figure 5, there are five states shown. There is the Bluetooth S ultra-high state 102, the Bluetooth high-state 104, the Bluetooth mid-state 106, the Bluetooth 108 low-state and the Bluetooth ultra-low state.

When the condition BTOCC<L2H_LIMIT is satisfied, then the Bluetooth state will transit to the next higher Bluetooth state. For example, a transition will be made from the Bluetooth ultra-low state 110 to the Bluetooth low-state 108. Similarly, a transition will be made from the Bluetooth low state 108 to the Bluetooth mid-state 106 and so on. The condition effectively indicates that the Bluetooth occupies the antenna for a duration which is less than the L2H limit. In the example set out in Table 4, this would be 10% of the time.

The transition from the Bluetooth ultra-high state 102 to the Bluetooth high state 104, this will occur if any of the following four conditions occur.

1. BT_OC>CSH2L_LIMIT -(CS is configuration setting, i.e. configuration or parameter settings used to influence behaviour of HLC) that is the Bluetooth occupancy of the anteima percentage is greater than the H2L default value set out in Tablc 4. In the example shown in Table 4, the default value is 70%. That is if the antenna is occupied by the Bluetooth device for more than 70% of the time, the Bluetooth device will transit to the lower state. This same criteria will cause a transition from any one Bluetooth state to the next lower Bluetooth lower state.

2. The second criterion which is used for transiting from the Bluetooth ultra-high state to the Bluetooth high-state 104 is if the WLAN EPPI message is present, i.e. an "Extremely Poor Performance Indicator" message is received from WLAN and the Bluetooth occupancy is greater than the EPPI limit. In the example shown in Table 4, the EPPI limit is 25%, If this condition is satisfied, the Bluetooth ultra-high state 102 transits to the next lowest Bluetooth state, that is the Bluetooth high-state 104.

This condition if satisfied, will also cause transiting from the Bluetooth high-state 104 to the Bluetooth mid-state 106, from the Bluetooth mid-state 106 to the Bluetooth low-state 108 and from the Bluetooth low-state 108 to the Bluetooth ultra-low state 110.

3. A third condition is if the WLAN PPI (WLAN Poor Performance Indicator) message is received from the WLAN device and the Bluetooth occupancy is greater than the PPI limit (see Table 4), then again the Bluetooth ultra-high state 102 will transit to the Bluetooth high-state 104. This condition also causes a transition from the Bluetooth high-state 104 to the Bluetooth mid-state and from the Bluetooth mid-state to the Bluetooth low-state.

4. The fourth condition is that the WLAN LPI (Low Performance Indicator) message is received from WLAN device and the Bluetooth occupancy is greater than the low performance limit LPI_LIMIT. See Table 4 for an example for the LPI value. When that occurs, the Bluetooth ultra-high state 102 will transit to the Bluetooth high 104 state.

Similarly, satisfaction of that criteria will also cause the transit from the Bluetooth high-state to the Bluetooth mid-state 106.

The EN limit, the PPI limit and the LPJ limit are all set in terms of Bluetooth antenna occupancy. The WLAN antenna occupancy is 100% minus Bluetooth_Antenna_Occupancy. In this embodiment BT occupancy value is used as the variable, instead of having two variables (BT occupancy and WLAN occupancy) which are in fact non-independent. In alternative embodiments of the invention, the variable may be WLAN antenna occupancy. In a further embodiment of the invention, there may be two variables, a WLAN antenna occupancy variable and a BT antenna occupancy variable.

Table 5 below summarises for each state of the FSM, the control and register settings for transiting to the state above and the state below. This is as discussed previously.

Table 5

STATE CONTROL & REGISTER SETTING5

INIT

UT_MID alter all initialization is complete BT_UI-IIGI-I BTHIGH: IF UT 0CC > I-I2L LIMIT or ([WLAN EPPI] sod UT 0CC > EPPI_L1MIT) Or ([WLAN_PPI] aod UT 0CC> lPL LIMIT) or ([WLAN LVI] and UT 0CC> LVI LIMIT) BTI-IIGH UT_MID IF UT 0CC > I-12L LIMIT or ([WLANEPPI] snd 13T_OCC > EPPI LIMIT) or ([WLAN_PPII sod UT 0CC> PPI LIMIT) or ([WLAN 1211 snd UT 0CC> LVI LIMIT) UT_UHIGH: IF UT 0CC C L2EI LIMIT BI MID El LOW: IF BTOCC> H2L LIMIT or ([WLAN EPPfl and BT_OCC > EPPI_LL\IiT) or ([WLAN_PPI] and -BTOCC> PP1 LIMIT) El_HIGH: IF DI DCC C L2H LIMIT BT LOW BIULOW: IF BT_OCC > 112L LIMIT or ([WLAN EPFJ3 and Dl 0CC> FPPI_L[MIT) BTMID: IF BT_OCC C L2HLLMIT BT LOW: IF BT 0CC C L2H LIMIT :BT_0W --In the above table, the state transitions are given. The state transitions are given between the Bluetooth ultra-high state 102 and Bluetooth ultra-low state and all the states in between occur under the following conditions as described previously. The Bluetooth antenna occupancy report BT_OCC from the antenna occupancy monitor 24 is provided every OCQREP_PERIOD milliseconds which reports Bluetooth occupancy of the antenna over the last period. Further warning messages are also provided, e.g. WLAN EPPI from the V/LAN device of the inability to acquire/retain the antenna to sustain acceptable throughput.

The BT occupancy is compared against thresholds to determine if the transition should indeed occur. The detailed analysis on the thresholds will be described in more detail below. The conclusion of the analysis, however, is the following relationship: H2L_LIMIT > LPI_LIMIT > PPI_LIMIT > EPPI_LIMIT > L2H_LIMIT. The values H2L_LIMIT and L2H_LTMTT are obtained directly from host (otherwise, a default value is used). The remaining parameters are calculated as: PPI LIMIT = L2H_LIMIT + ((H2L_LIMIT -L2H_LIMIT)>> 1) LPI_LIMIT = PPI_LTM1T + ((H2L LIMIt -PPT_LTMIT)>> 1) EPPI LIMIT = L2H LIMIT + ((PPI LIMIT -L211 LIMIT)>> 1) The BT Antenna Occupancy Monitor 24 records the occupancy of the medium by the Bluetooth device. Each time the BT device makes a request that is granted, the period for which the BT occupied the antenna is recorded. Every 0CC_REP_PERIOD, this module sends a report to the FSM controller 72 about the percentage of time that the BT device occupied the antenna since the last time the report was sent.

The WLAN traffic monitor 76 can notify the FSM if it is unable to communicate satisfactorily with the Access-Point. Performance related messages (WLAN_EPPL WLANPPI and WLANLPI) demand more air-time for the WLAN device. These notifications may be used to cause the FSM 72 to transit to a more constrained state. The table below provides some suggestions.

Table 6

MESSAGE TYPE INTERPRETATION

WLANEPPI Extremely Poor Performance indication -e.g. WLAN was unable to successfully transmit (with ACK) any packet during the last 30 ms.

WLANPPI Poor Performance Indication -e.g. WLAN was unable to successfiully transmit (with ACK) any packet during the last 20 ms.

WLANLPI Low Performance Indication -e.g. WLAN was unable to successfully transmit (with ACK) any packet during the last 10 ms.

The WLAN device decides how to utilize this feature. To prevent over-reacting to such notifications, the WTM 76 may adopt the following policy. Once it has reacted to a warning-message from WLAN, the WTM shall ignore further warning-messages for the next 20 ms.

For one embodiment, appropriate values and relations between the parameters: H2L Limit, EPPI_Limit, PPI Limit, LPI Limit and L2H Limit are discussed. The following relationship is respected: H2L_Limit> LPI_Limit> PPI_Limit> EPP I_Limit> L2H_Limit.

A state in the HLC FSM is more constrained if it contains more restrictions with respect to BT transmission compared to another state. For example, ST_MID is more constrained than BT_HIGH because in the state BT_MID, for instance, the BT transmissions can be interrupted to give the antenna to the WLAN device. Going down the states of the state machine, it gets more and more difficult for the BT device to get the antenna when the WLAN device is active. Inversely, up the chain, the BT device has more freedom to obtain the antenna compared to the WLAN device.

Relation between H2L_Limit and L2H Limit If the average percentage of time the antenna remains with the BT device exceeds the H2L Limit, the HLC FSM 72 makes a transition to a more constrained state. On the other hand, if the average percentage of time the antenna remains with the BT device is lower than the L2H_Limit, the FSM 72 makes a transition back from the more constrained state to a less constrained one.

For example, if H2L_Limit = 60%, the current state is BT UHIGH and the current BT antenna occupancy is 61%, then the state machine transits from BT_UHIGH to BTHIGH. Now, moving back from the more constrained BT_HIGH to the less constrained BT_UHIGH makes sense only if the BT antenna occupancy drops significantly. Therefore, H2L_Limit> L2H Limit. The H2L Limit>> L2_Limit in one embodiment so there is a margin within which the FSM 72 remains stable in a state.

Relation between EPPILimit, PPI_Limit and LPI_Limit The message WLAN_EPPI is a signal to the coexistence engine that WLAN is suffering under extremely poor performance. The message WLAN_PPI, similarly, signals a poor performance (limited success) of the WLAN device in receiving and transmitting data.

The order of urgency in the WLAN messages is EPPI (highest), PPI and LPI (lowest).

Whichever state currently in, there should be a stronger motivation to move to a more constrained BT state upon receiving a WLAN EPPI message, compared to receiving a WLAN_PPI message. To put it in another way, the EPP i_Limit is tighter than PPILimit, i.e. LPI_Limit > PPI Limit > EPPI Limit.

Once the restrictions on the BT device are already high (e.g. current state is BT_Low), WLAN messaging on low performance (WLAN_LPI) really is a issue of the WLAN device wanting more and more time with the antenna when the BT device itself is having limited access. So messages like WLAN_LPI may be ignored if the restrictions on the BT device are already substantial. If the BT antenna occupancy is high, then there is an independent check for this.

Relation between {BPPI_Limit, PPI Limit, LPI Limit} and (H2L Limit, L2HLimit} The limit H2L_Limit is used to compare, periodically, against the current BT occupancy.

In case a WLAN message is received such as WLAN_LPI, the comparison of BT occupancy is made with LPI_Limit to see if a transition to a more constrained state is necessary. If LPI_Limit > H2L_Limit then the WLAN message effectively is not achieving anything, since its check-limit is more relaxed than even the periodic H2L Limit. Therefore, H2L_Limit> LPI Limit.

Suppose the current state is BT_HIGH, EPPI Limit equals 35%, BT occupancy is 36% and a WLAN_EPPI message is received. Given that BT occupancy is greater than the EPP1 Limit, a transition to nT_MID state is made. Now, to transit back from BT_M1D to BT_HIGH, the BT occupancy limit check (L2H_Limit) should be no greater than EPPI_Limit otherwise the same situation will be recreated, by reducing the constraints on the BT device, that generated the WLAN_EPPI message in the first place. Therefore, EPPI Limit >L2H_Limit.

In one embodiment, the H2L_Limit is different for each state transition: H1 for transition from BT_UHIGH to BT HIGH, H2 from BT_HGH to BT_MID, H3 from BT_MID to BTLOW and so on.

Suppose, H1 = 60%, H2 = 70% and H3 = 80%. The consequence is that more restrictions are placed on the BT device having the antenna, the level of tolerance is increased before tightening the constraints thrther. For instance if the current state is BT UHIGH and BT is occupying 61% of antenna-time, since 61 > H1 restrictions are imposed on the BT device getting access to the antenna by transiting to state BT HIGH. However, in state BT_HIGH the BT device uses the antenna for up to 70% of the time, before increasing the restrictions frirther. Such a scheme could be supported once already in a tightly constrained state, the BT device being still able to obtain the medium indicates the high priority of its current traffic. Alternatively, the WLAN device could be struggling to send data because of some discrepancy in it prioritizing the traffic correctly, and in the absence of messages from the WLAN device there may be a problem and more constraints on the BT device should be applied.

Suppose H1 = 80%, H2 = 70%, H3 = 60%, the current state is BT_UHTGH and BT occupancy of the antenna is 85%. Since 85 > H1, a transition to BT_HIGH is made. Since new constraints have been imposed on the Bluetooth device, suppose the BT occupancy was reduced to 75%. Again, since 75 > H2, a transition to BT_MED is made. As new constraints have been imposed on the BT device, BT occupancy could be reduced further to 65%. So a transition to BT_LOW is made where the occupancy limit is even lower.

Therefore, H1 H2 �= H3 and setting different limits for each transition has some advantages in some embodiments of the invention.

The states from BTUHIGH down to BT_ULOW, represent increased levels of constraints on the BT device's ability to acquire and retain the medium.

Conversely, the states BTUHIGH down to BT_ULOW represent reduced levels of constraints on WLAN device's freedom to acquire or retain the medium. That is, a request by the BT device for the antenna, while the WLAN device is also competing, is more likely to be refused in state BT_ULOW than in BT_UHIGH.

Generally speaking, when the BT traffic is over-whelming and the WLAN device is unable to transmit or receive successfully, the FSM will transit from, say, BT UHIGH to BT_HIGH to allow the WLAN device more ability to acquire and retain the medium.

Conversely, when WLAN traffic is over-whelming and the BT device is unable to transmit or receive, the transition will be in the reverse direction.

Through its interference engine the HLC FSM 72 attempts to find the right balance in allocating the antenna to BT and WLAN devices. In other words, the controller tries to find the right state. That right state, which is time and BT-WLAN application scenario dependent, provides a trade-off in air-time for BT and WLAN traffic.

The priority level of the requests from the PTA takes the form of integer values between A and B. For example the BT priority can be between 0 and 7 (similarly WLAN priority is 0,1, 2, . .. up to 7) In one embodiment of the invention, the values shown in table 7 below are used to alter the BT device's priority asserted in the respective request. In alternative embodiments of the invention, the values could be used to alter the WLAN device's priority asserted in the respective request. The priority adjustment may be subject to maximum priority level of 7 (3 bits) and a minimum of 0. The adjustment information is provided to the PTA which carries out the arbitration using the adjusted priority values The values of Table 7 and their meaning will be discussed in more detail below: Table 7 STATE! FEATURE BTUJ-IIOFI BT_I-ITOH BTMID ST LOW BTULOW PRIORITY ADJUSTMENT' +2 -i-i 0 -1 -2 F_ORANT_BT y F_PROTECT_WLAN_ACK_TX y Y FPROTECTWLAN_ACK_RX Y y y The controls that the FSM 72 can change in the PT 66, based on controller states are described next: * PRIORITY ADJUST: The priority value accompanying each BT request can be adjusted up or down. For example, suppose both WLAN. and BT devices are competing for the medium and the BT device has requested at priority level 3 and the WLAN device at priority level 4. If HLC FSM 72 is in state BT_LJHIGH then the BT priority is pulled up by the +2. In other words, the BT device will now be effectively requesting at priority value 3+2 = 5 and then compared with WLAN priority (i.e. 4) to determine who is awarded the medium. Tn this case, the BT device wins the antenna although with its original priority level it would have lost to the WLAN.

F_PROTECT WLAN_ACK_RX: If the WLAN device is currently receiving an acknowledgement to a packet it has already transmitted, the controller could force the WLAN device to retain the medium if the pending BT request is below a certain priority value (after adjustment). Typically, FPROTECT_WLANJiCK_RX would be switched on in states where it is desired that the WLAN device wins the arbitration over the BT device (e.g. state BTULOW). In the example shown in Table 7, the states for which this is switched on are marked Y and are the BT MID to BT ULOW states.

* F PROTECT WLAN ACK TX: If the WLAN device is currently transmitting an acknowledgement to a packet it has already received, the controller could force the WLAN device to be retain the medium if BT request is below a certain priority value (after adjustment). Typically, F PROTECT_WLAN_ACK_TX would be switched on in states where it is desired that the WLAN device win the arbitration over the BT device (e.g. state BT_ULOW). In the example shown in Table 7, the states for which this is switched on are marked Y and are the BTHIOH to BTULOW states.

* F_GRANT_BT: In case of poor BT performance (e.g. in state BT_UHIGH), the controller can force certain BT requests (e.g. eSCO packets) to be always granted.

In the example shown in Table 7, the state for which this is switched on is marked Y and this is the BT UHIGH state.

It should be appreciated that the above-mentioned controls are some examples of controls which can be used. It should be appreciated that there are other controls which can be similarly defined and applied in addition to or instead of the above-mentioned controls.

Reference is made to Figure 6 which schematically shows a system in which embodiments of the present invention can be incorporated. The device 60 having both the Bluetooth and WLAN device incorporated therein comprises a common antenna 62 which is shared by both the Bluetooth and the WLAN devices. The device 60 is connectable to a Bluetooth node 130 via a wireless connection 134. Similarly, the device is connectable to a WLAN node 132 via a radio wireless connection 136.

In the described embodiment, a single device comprises a WLAN device and a Bluetooth device. It should be appreciated that this is by way of example only. Embodiments of the present invention may apply where there are two devices contending for a single resource.

The two devices may be of the same technology, for example two WLAN devices or two Bluetooth devices or can be different devices. Of course, the devices may be other than WLAN devices andlor Bluetooth devices. The two devices may be in the same physical* device or may be separate. The two devices may share an antenna or each has their own antenna.

The state machine shown in Figure 5 has five states. This is by way of example only.

Alternative embodiments of the present invention may have fewer than five states or more than five states. tn the described embodiment shown in Figure 5, the initial state is shown as transiting to the middle state. Again, this is by way of example only and alternative embodiments may part at any of the five states.

In the described embodiment of the present invention, the control of the state machine has been defined as terms of the occupancy by the Bluetooth device of the antenna and messages from the WLAN device. This is by way of example only and could use any other parameter such as traffic quantity, traffic type, quality of service, beacon missing (e.g. for WLAN devices), link maintenance problems (e.g. for BT devices), packet drop, voice packet drop, jitter, jitter in voice etc. to control the transitions between the states.

Embodiments of the invention can use a plurality of terms which could be combined to provide a control parameter for the transitions.

it should be appreciated that more or less parameters may be defined. The numeric values associated with the various parameters and limits is by way of example only.

S Different numeric values may be used in alternative embodiments of the present invention.

The described embodiments define a PTA-HLC (Packet Traffic Arbitration High-Level Controller) for efficient coexistence between Bluetooth and WLAN. The mechanism described here complements the PTA scheme described in IEEE 802.15.2 document. The PTA makes real-time, packet-wise decisions based on priority-comparison. The PTA-HLC operates over a wider time-horizon, It introduces a scheme whereby the priority values attached to individual BT and WLAN requests are modulated and controls on BT/WLAN usage are adjusted, so there is more balanced sharing of the medium. Based on the analysis of the traffic pattern for commonly occurring BT-WLAN coexistence scenarios, embodiments of the invention may provide and enhanced user-experience.

In general, the various embodiments of the invention may be implemented in hardware or special purpose circuits, software, logic or any combination thereof For example, some aspects may be implemented in hardware, while other aspects may be implemented in firmware or software which may be executed by a microprocessor or other computing device, although the invention is not limited thereto.

The embodiments of this invention may be implemented by computer software executable by a data processor, or by hardware, or by a combination of software and hardware. The software may be stored on such physical media as memory chips, or memory blocks implemented within the processor, magnetic media such as hard disk or floppy disks, and optical media such as for example DYD and the data variants thereof, CD.

S The memory may be of any type suitable to the local technical environment and may be implemented using any suitable data storage technology, such as semiconductor-based memory devices, magnetic memory devices and systems, optical memory devices and systems, fixed memory and removable memory.

Embodiments of the inventions may be practiced in various components such as integrated circuit modules. In one embodiment of the invention, the HLC controller and the PTA may be implemented in an integrated circuit or by a chipset.

The foregoing description has provided by way of exemplary and non-limiting examples a ftill and informative description of the exemplary embodiment of this invention. However, various modifications and adaptations may become apparent to those skilled in the relevant arts in view of the foregoing description, when read in conjunction with the accompanying drawings and the appended claims. However, all such and similar modifications of the teachings of this invention will still fall within the scope of this invention as defined in the appended claims.

Claims (38)

1. CLAIMS1. An apparatus comprising: means for receiving a plurality of requests from a plurality of wireless devices for access to a common wireless frequency band; and means for arbitrating between said requests based on a priority of an application associated with respective requests and based on information which is based on an amount of time at least one of said devices has previously been granted access to said common frequency band.
2. 2. An apparatus as claimed in claim 1, wherein said means for arbitrating receives a priority indication in each request.
3. 3. An apparatus as claimed in claim 2, wherein said means for arbitrating is arranged to adjust the priority of at least one request from at least one of said devices based on said information.
4. 4. An apparatus as claimed in any preceding claim, wherein said information is determined based on an amount of time one of said devices has occupied an antenna.
5. 5. An apparatus as claimed in any preceding claim, wherein said information is determined based a warning message about a least one of said devices.
6. 6. An apparatus as claimed in claim 5, wherein said apparatus is configured to receive one of a plurality of warning messages from at least one of said devices, wherein the warning message received is dependent on the length of time for which the said at least one device has been unable to transmit.
7. 7. An apparatus as claimed in any preceding claim, comprising means for providing said information.
8. 8. An apparatus as claimed in claim 7, wherein said means for providing said information comprises a state machine having a plurality of states.
9. 9. An apparatus as claimed in claim 8, wherein said information is provided in dependence on which state said state machine is in.
10. 10. An apparatus as claimed in claim 8 or 9, wherein said state machine is arranged to transit between states in dependence on at least one of: an amount of time at least one of said devices has previously been granted access to said common frequency band; and a warning message about a least one of said devices.
11. 11. An apparatus as claimed in claim 9 or 10, wherein at least one condition is defined for changing from one state to another.
12. 12. An apparatus as claimed in claim 11, wherein different conditions are defined for transiting between different states.
13. 13. An apparatus as claimed in claim 11 or 12, wherein a condition comprises at least one of a threshold and a warning condition.
14. 14. An integrated circuit comprising an apparatus as claimed in any preceding claim.
15. 15. A device comprising: a first wireless device; a second wireless device; and an apparatus as claimed in any of claims ito 13.
16. 16. An apparatus as claimed in claim 15, comprising a common antenna.
17. 17. An apparatus comprising: means for receiving a plurality of requests from a plurality of devices for access to a shared wireless resource; and means for arbitrating between said requests based on a priority associated with each request and at least one parameter indicative of usage previously of said shared resources by said respective devices.
18. 18. An apparatus comprising: means for receiving from a plurality of wireless devices which share the same wireless bandwidth a plurality of requests, each request having an associated priority; means for changing a priority of at least one request based on i. a history of usage of the wireless medium by at least one of said wireless devices and ii. a current requirement of a respective wireless device to gain access to said wireless medium.
19. 19. An apparatus as claimed in claim 18, wherein information on said current requirement is provided by a performance indicator message from at least one device.
20. 20. A controller comprising: means for providing information to an arbitration means, said information for changing a priority being determined based on a history of usage of a wireless medium by at least one of a plurality of wireless devices and a current requirement of a respective wireless device to gain access to said wireless medium.
21. 21. A method comprising: receiving a plurality of requests from a plurality of wireless devices for access to a common wireless frequency band; and arbitrating between said requests based on a priority of an application associated with respective requests and based on information which is based on an amount of time at least one of said devices has previously been granted access to said common frequency band.
22. 22. A method as claimed in claim 21, comprising receiving a priority indication in each request.
23. 23. A method as claimed in claim 22, comprising adjusting the priority of at least one request from at least one of said devices based on said information.
24. 24. A method as claimed in any of claims 21 to 23, comprising determining said information based on an amount of time one of said devices has occupied an antenna.
25. 25. A method as claimed in any of claims 21 to 24, comprising determining said information based a warning message about a least one of said devices.
26. 26. A method as claimed in claim 25, comprising receiving one of a plurality of warning messages from at least one of said devices, wherein the warning message received is dependent on the length of time for which the said at least one device has been unable to transmit.
27. 27. A method as claimed in any of claims 21 to 26, comprising providing said infonnation.
28. 28. A method as claimed in claim 27, wherein providing said information comprises using a state machine having a plurality of states.
29. 29. A method as claimed in claim 28, comprising providing said information in dependence on which state said state machine is in.
30. 30. A method as claimed in claim 28 or 29, comprising causing said state machine to S transit between states in dependence on at least one of: an amount of time at least one of said devices has previously been granted access to said common frequency band; and a warning message about a least one of said devices.
31. 31. A method as claimed in claim 29 or 30, comprising defining at least one condition for changing from one state to another.
32. 32. A method as claimed in claim 31, comprising defining different conditions for transiting between different states.
33. 33. A method as claimed in claim 31 or 32, wherein a condition comprises at least one of a threshold and a warning condition.
34. 34. A method comprising: receiving a plurality of requests from a plurality of devices for access to a shared wireless resource; and arbitrating between said requests based on a priority associated with each request and at least one parameter indicative of usage previously of said shared resources by said respective devices.
35. 35. A method comprising: receiving from a plurality of wireless devices which share the same wireless bandwidth a plurality of requests, each request having an associated priority; and changing a priority of at least one request based on iii. a history of usage of the wireless medium by at least one of said wireless devices and iv. a current requirement of a respective wireless device to gain access to said wireless medium.
36. 36. A method as claimed in claim 35, wherein information on said current requirement is provided by a performance indicator message from at least one device.
37. 37. A method comprising: means for providing information to an arbitration means, said information for changing a priority being determined based on a history of usage of a wireless medium by at least one of a plurality of wireless devices and a current requirement of a respective wireless device to gain access to said wireless medium.
38. 38. A computer program comprising program code means adapted to perform any of the steps of claims 21 to 37 when thc program is run on a processor.