A Novel Architecture and Coexistence Method to Provide Global Access to/from Bluetooth WPANs by IEEE WLANs

Transcription

1 A Novel Architecture and Coexistence Method to Provide Global Access to/from Bluetooth WPANs by IEEE WLANs Carlos de M. Cordeiro, Sachin Abhyankar, Rishi Toshiwal, and Dharma P. Agrawal Research Center for Distributed and Mobile Computing, ECECS University of Cincinnati, Cincinnati, OH USA {cordeicm, sabhyank, rtoshniw, Abstract Bluetooth is a radio technology for Wireless Personal Area Networking (WPAN) operating in the.4ghz ISM frequency band. So far, there has been little research on how Bluetooth-enabled devices can effectively and efficiently have uninterrupted access to wide area networks (WAN) such as the Internet. We introduce a novel Bluetooth architecture (BlueStar) whereby selected Bluetooth devices, called Bluetooth Wireless Gateways (BWGs), are also IEEE enabled so that these BWGs could serve as egress/ingress points to/from the IEEE wireless network. We propose mitigating interference between Bluetooth and IEEE 80.11, by employing a hybrid approach of adaptive frequency hopping (AFH) and Bluetooth carrier sense (BCS) of the channels. AFH labels channels as bad or good, and Bluetooth devices only access those channels in the good state, whereas BCS is used to avoid collision by sensing the channel prior to any transmission. By combining AFH and BCS, we drastically minimize the effect of the worst-case interference scenario wherein both a Bluetooth and an IEEE interface are co-located in a single device. BlueStar enables Bluetooth devices, belonging to either a piconet or a scatternet, to access the WAN through the BWG without the need for any fixed Bluetooth access points, while utilizing widely deployed base of IEEE networks. Moreover, we define the protocol stack employed by BlueStar as well as indicate how BWGs efficiently manage their capacity allocation through different systems. We also mathematically derive an upper bound on the number BWGs needed in a scatternet so that uninterrupted access to all Bluetooth devices could be provided. I. INTRODUCTION Bluetooth [1, 9] is a wireless communication technology that provides short-range, semi-autonomous radio network connections, and offers the ability to establish ad hoc networks, called piconets. It has also been chosen to serve as the baseline of the IEEE standard for wireless personal area networks (WPANs) []. A WPAN is defined as the connection of personal devices, allowing information exchange over short ranges. Eventually, this WPAN can be integrated with large wide area networks (WAN) to provide Internet connectivity in addition to access among these devices. As previous studies have pointed out [3, 7, 8, 10, 30], it is much likely that Bluetooth devices and IEEE [15] wireless local area networks (in this work we use the term WLAN and IEEE 80.11/80.11b interchangeably) operating in the.4 GHz ISM (Industrial-Scientific-Medical) frequency band should be able to coexistence as well as cooperate with each other, and access each other s resources. These technologies are complementary to each other and such an environment is envisioned such that many Bluetooth devices can access information from the WLAN, and ultimately the Internet. These cooperative communication requirements have encouraged us to propose an intuitive architecture, called BlueStar, whereby few selected Bluetooth devices, called Bluetooth wireless gateways (BWG), are also members of a WLAN, empowering low-cost, short-range devices to access the global Internet infrastructure through the use of WLANbased high-powered transmitters. It is also envisioned that Bluetooth devices might access the WAN through a 3G cellular infrastructure like Universal Mobile Telecommunication System (UMTS) and cdma000 []. However, from the point of view of cost and performance, it is advantageous for Bluetooth devices to have access to the WAN through a WLAN system where a WLAN infrastructure is available. In these scenarios, Bluetooth (or WPAN) devices would only make use of the cellular network infrastructure where WLAN coverage is not provided. An important challenge in conceiving the BlueStar architecture is that both Bluetooth and WLANs employ the same.4 GHz ISM band and this can significantly negatively impact the performance [5, 6, 9, 30]. The interference generated by WLAN devices over the Bluetooth channel is called persistent interference [30], while the presence of multiple piconets in the vicinity creates interference [3, 7, 8, 8, 30] defined as intermittent interference [8, 30]. To combat both of these interference sources and provide effective coexistence, we propose BlueStar to employ a unique hybrid approach of adaptive frequency hopping (AFH) [9] and a new mechanism called Bluetooth carrier sense (BCS). AFH seeks to mitigate persistent interference by scanning the channels during a monitor period and labeling them as good or bad based on whether the packet error rate (PER) of the channel is below or above a given threshold, respectively. BCS takes care of the intermittent interference by mandating that before any Bluetooth packet transmission, the transmitter has to sense the channel to determine whether there is activity going or not. This channel sensing is performed in the turn around time of the current slot, and it does not require any changes to the current Bluetooth slot structure. According to the IEEE Coexistence Task Group terminology [16], BlueStar would be classified as a noncollaborative solution in the sense that the Bluetooth and the WLAN system operate independently, with no exchange of information. This lack of information does not, however, have impact on the performance of BlueStar. In fact we show that by employing the BlueStar architecture, we can approximately double the performance of the regular Bluetooth. Other studies [3, 4] have proposed the use of Bluetooth access points (BAP) thereby making it totally dependent on a short-range fixed infrastructure. Our proposed BlueStar takes advantage of the current WLAN installed base as many organizations have spent hundreds of thousands of dollars (including personnel training) building their WLAN infrastructure, and for these organizations it is more advantageous to use the deployed WLAN infrastructure since it can easily support long-range, large scale mobility and provide uninterrupted access to Bluetooth devices. The architecture proposed here is an intuitive and practical solution to an ad hoc issue. This arrangement of Bluetooth and WLAN enabled devices has been evaluated in [10], while no mechanism or architecture has been used to mitigate interference of Bluetooth and WLAN. In this work we not only define an architecture and its protocol stack, but also identify and propose two mechanisms (AFH and BCS) that enable effective and efficient coexistence of Bluetooth and WLAN within a single device. The industry has also been making efforts towards the integration of Bluetooth and WLAN [19, 0, 1]. However, most recent solutions do not tackle the issue of simultaneous operation of Bluetooth and WLANs, that is, either Bluetooth or WLANs but not both can access (i.e., be active) the wireless medium at a time, as

2 only a single card is available. Moreover, this implies that additional integrated cards have to be acquired. The architecture we propose here enables simultaneous operation by using existing WLAN hardware infrastructure, while do relying on the availability of Bluetooth interfaces. The remainder of this paper is organized as follows. Section two provides an introduction to the Bluetooth technology, whereas section three elaborates on the proposed BlueStar architecture and its novel combination of AFH and BCS, to handle both intermittent and persistent interferences. Next, section four discusses our simulation environment. The performance of BlueStar in a Bluetooth-only scenario is then shown in section four, while section five evaluates BlueStar in a combined IEEE and Bluetooth environment. Section six discusses placement issues of BWGs. Finally section seven concludes this paper. II. BLUETOOTH OVERVIEW The details of the Bluetooth system, architecture and protocols are defined in [1]. A brief overview is provided here for completeness. Bluetooth is a short-range (up to 10m) wireless technology aimed at replacing cables that connect phones, laptops, and other portable devices. Bluetooth operates in the ISM frequency band starting at.40 GHz and ending at.483 GHz in USA and most European countries. A total of 79 RF channels of 1 MHz width are defined, where the raw data rate is 1 Mbit/s. A Time Division Multiplexing (TDD) technique divides the channel into 65s slots and, with a 1Mbit/s symbol rate, a slot can carry up to 65 bits. Transmission occurs in packets that occupy 1, 3 and 5 slots as depicted in Figure 1. Each packet is transmitted on a different hop frequency with a maximum frequency hopping rate of 1600 hops/s. Bluetooth operates on a Master-Slave concept wherein the Master periodically polls the Slave devices and only after receiving such a poll is a Slave allowed to transmit. The Master for a particular set of connections is defined as the device that initiated the connections. A Master device can directly control up to seven active Slave devices in what is defined as a piconet. Multiple piconets can be linked together through common Bluetooth devices to form a scatternet. The Bluetooth specification defines two distinct types of links for the support of voice and data applications, namely, SCO (Synchronous connection-oriented) and ACL (Asynchronous connectionless). The first link type supports point to point voice switched circuits while the latter supports symmetric as well as asymmetric data transmission. This work mainly considers the use of ACL packets since they are intended to support data applications and do not have prescribed time slot allocations as opposed to SCO packets. The ACL link allows the use of 1, 3, and 5-slot data packets (Figure 1) with the optional use of FEC (Forward Error Correction). DMx (data medium-rate) packets provide a /3 FEC Hamming code and DHx (data high-rate) packets carry no FEC coding at all, where x = 1, 3, or 5, depending on the number of slots it occupies. Table 1 presents the possible ACL link packet types with their respective characteristics. III. THE PROPOSED BLUESTAR ARCHITECTURE The proposed architecture is expected to be capable of accessing networked information, especially through a WAN such as the Internet. This allows dynamic content to be delivered to the piconets and to the devices that may not otherwise have such WAN access but can communicate with other Bluetooth devices that do have access, either within the piconet or scatternet. This would also enable network sharing among wireless and wired devices not only within the local network, but also across the WAN. We address this problem by a novel architecture called BlueStar to provide Bluetooth access to the WAN and take advantage of the existing IEEE WLANs. We call these selected devices which possess both a WLAN interface and a Bluetooth interface as Bluetooth Wireless Gateways (BWGs). BlueStar allows piconets to be formed around a portable device, such as a notebook or a laptop, and have wide-area connectivity as well. Figure (a) illustrates the BlueStar architecture with a scatternet, composed of total of four piconet, where each piconet has several slaves (indicated by the letter S i,j ) and one master (indicated by the letter M i ). In this figure, two BWGs provide the scatternet Bluetooth devices access to the local WLAN which, in turn, provides communication to the local LAN, MAN, or WAN, and possibly the Internet. BlueStar opens up new possibilities for the Bluetooth WPAN technology, as it enables Bluetooth devices to communicate with virtually any other entity on the Internet. 65sec 1-slot packet 3-slot packet 5-slot packet Figure 1 Packet transmission in Bluetooth The interaction between the Bluetooth network and the outside world is managed by the BWGs. Within the Bluetooth network, BlueStar transmits IP packets over PPP (see [1]) as shown in Figure (b), where the protocol stack adopted in our architecture is presented for each of its entities. As we can see, BlueStar reuses existing protocols wherever possible, while taking advantage of PPP as it is already implemented in most mobile devices [1]. Note that other optimized protocol stacks have been proposed to serve specific applications [5], while the architecture we adopt does not have such restriction. TABLE 1. ACL Packet Overview Type User Payload (bytes) FEC Symmetric (Kbps) Asymmetric (Kbps) DM Yes DH1 0-7 No DM Yes DH No DM5 0-4 Yes DH No In order to Bluetooth devices to be directly addressed, we assume that every Bluetooth device possesses an IP address (which can be obtained with the assistance of PPP) and that any of the wellknown routing algorithms [, 3] is available. Hence, we can conclude that the BWGs may be better served by a layer (either software or dedicated hardware) above the Bluetooth and WLAN radio cards which is responsible, among other things, for receiving packets and forwarding them through the corresponding wireless medium. The way BWGs multiplex their capacity has to be carefully coordinated. To do that, we employ a scheme where the time slice of a BWG in a system is proportional to the number of devices in that system. Our capacity management scheme is a variation of the one presented in [4]. A crucial challenge in the design of BlueStar is to enable an efficient and concurrent operation of both Bluetooth and WLANs as they both employ the same.4 GHz ISM band. To combat the interference sources, BlueStar employs a unique hybrid approach of an adaptive frequency hopping (AFH) and the Bluetooth carrier sense (BCS). Below we describe how such schemes are implemented in BlueStar. A. Bluetooth Carrier Sense (BCS)

3 IEEE WLAN IEEE WLAN TCP UDP IP PPP RFCOMM PPP RFCOMM IP Backbone to LAN, MAN, WAN Bluetooth scatternet LCAP LMP Baseband Baseb. Radio Bluetooth device piconet LCAP LMP Baseband Baseb. Radio MAC PHY BWG IP MAC PHY Access Point Figure (a) BlueStar proposed architecture Figure (b) Protocol stack for each entity f(k) f(k+1) f(k+) Sp,i sense f(k) turn around time sense f(k+) turn around time Piconet i Tp,i BCS Collision Sz,j turn around time sense f(k+1) turn around time Figure 3 Carrier sensing mechanism in Bluetooth sense f(k+3) BlueStar employs carrier sense so that intermittent-like interference can be avoided. The current Bluetooth specification [1] does not have any provision for carrier sensing. However, with increased receiver sensitivity and the widespread use of Bluetooth in unpredictable environments and new applications, it is quite likely that carrier sensing may have to be considered for inclusion in the Bluetooth specification. Moreover, carrier sensing is fundamental to any efficient interference mitigation with other technologies using the same ISM frequency band, and among Bluetooth piconets themselves. Contrary to IEEE 80.11, Bluetooth carrier sensing would be much simpler due to the nature of its MAC protocol [8, 8]. Therefore, we assume that Bluetooth devices possess sense capability. We incorporate BCS into Bluetooth without any modifications to the current slot structure. As stated in section, with a symbol rate of 1Mbit/s a Bluetooth slot can carry up to 65 bits. However, to allow the Bluetooth transmitter and Bluetooth receiver devices to change from Rx to Tx mode and make the frequency synthesizer tune to the next channel frequency, a 59s turn around time is left at the end of the last slot. With current improvements in the Bluetooth chip design [1], in the near future the Bluetooth device might keep part of this turn around time unused as idle, hence enabling it the perform some useful task. This turn around period is illustrated in the Figure 3. Figure 3 also shows our BCS proposal, where the dashed block denotes the sense window of size W BCS. Before starting packet transmission, the next channel is checked (i.e., sense) in the turn around time of the current slot. If the next channel is busy or becomes busy during the sense window, the sender simply withholds any attempt for packet transmission, skips the channel, and waits for the next chance. Otherwise, packet transmission is carried out. The direct consequence of this approach is that, eventually, an ARQ (Automatic Retransmission Request) packet will be sent when the slot is clear and the communication is carried out. Algorithms to guarantee that devices withdrawing their transmissions in a previous polling cycle will eventually have a fair share of time in the following cycles are out of scope of this paper, while we have used an approach similar to [4] for our implementation (detailed in section 4). Next, we analyze the nature of intermittent interference. As we have seen earlier, packet transmission in different piconets are Piconet j Figure 4 Timing of two Bluetooth packets on different piconets asynchronous and are transmitted with period T p, which depends upon the Bluetooth packet type p. For instance, if p is equal to DH1 or DM1 we have that T p = *slotsize, where slotsize is the size of a Bluetooth slot, and is equal to 65sec. Figure 4 illustrates the timing of two Bluetooth packets p and z generated at piconets i and j with sizes S p,i and S z,j, respectively. The probability of packet collision between piconets i and j, p c (i,j), is the probability of packet overlap both in time and frequency. Therefore, if we assume that any packet collision incurs packet loss (strong interference) [8, 30], we have that: S p, i Sz, j 1 pc ( i, j) (1) (max( slotsperpacket( p), slotsperpacket( z)) 1) slotsize C where C is the number of available frequency channels and is equal to 79 in most countries [1]. Moreover, the function slotsperpacket(x) gives the number of slots occupied by a Bluetooth packet X, and max(p, q) returns the largest value of two numbers p and q. We can extend this analysis by deriving the packet collision probability in a network comprised of N piconets. The packet collision probability with a packet originated at the ith piconet is given by: p c ( i) 1 (1 p c ( i, j)) N 1 Let us now derive the equations for BCS. For the ith piconet, the packet withdrawal probability is the probability of sense window overlap with the packet from any other piconets. Therefore, the packet withdrawal probability of Bluetooth with BCS can be written as: p w S z, j ( i) 1 (1 ( slotsperpacket( z) 1) slotsize Tz,j 1 ) C N 1 Figure 5 depicts the packet collision and withdrawal probabilities for all three Bluetooth slot length packets as a function of the number of piconets, and W BCS = 50s. Such an analysis of a high number of piconets (up to 00) is crucial given the new wave of applications of Bluetooth in Wireless Sensor Networks where thousand of sensors equipped with Bluetooth interfaces are () (3)

4 employed [6, 7], hence requiring hundreds of piconets to be formed and operate with minimum interference amongst each other [8]. Thus, the analyses we carry out in this paper also have these sorts of applications in mind. As we can see from Figure 5, even though both packet probabilities increase with the number of piconets, the packet withdrawal probability increases at a slower rate, indicating that a large fraction of packet collisions are being avoided with the adoption of BCS. Moreover, as with different slot length packets have specific probabilities, the rate of increase is also distinct. B. Bluetooth Adaptive Frequency Hopping (AFH) A careful observation reveals that some packet collisions are still not detected by BCS. Figure 6 shows two cases of potential packet collisions. Although the IEEE WLAN senses the channel before transmission, it cannot sense the Bluetooth activities [11], since the Bluetooth signal is narrowband and low power as compared to WLANs. Therefore, when the Bluetooth packet (from piconet i) is ahead of the WLAN, packet collision (with the next IEEE packet) takes place even after employing BCS. On the other hand, when the WLAN packet is ahead of the Bluetooth packet BCS successfully senses activity in the medium and withdraws packet transmission (see Figure 6). To cope up with this type of interference, called persistent interference, BlueStar employs AFH [9], which turns out to be an effective method for handling persistent interference. In our implementation of AFH, Bluetooth devices scan every T SCAN seconds for each of the 79 channels used by Bluetooth and collect PER statistics. If the PER is above a threshold PER THRES, it is labeled as bad ; otherwise it is labeled as good. All devices within a piconet carry out this procedure and when the piconet master request this, the slaves send their measured good and bad channel marks. The master, in turn, conducts a referendum process based on information collected by itself and provided by the slaves. The final mapping sequence is then determined and sent back to each slave device, which follow this new sequence thereafter. We have implemented this scheme by a bitmap comprising of 79 bits where a one indicates that a frequency can be used while a zero indicates otherwise [9]. Note that devices conduct the AFH procedure periodically in order to account for the case where the piconet or some piconet devices may have left WLAN radio coverage. The overall effect on Bluetooth is that the total number of available channels C decreases as some channels may be labeled as bad. The only impact on our previous analytical model of section 3.1 is that the value of C in equation () changes periodically with the reevaluation of the channels by the AFH mechanism, and will always be at most equal to 79. IV. SIMULATION OF BLUESTAR We have implemented all functionalities of BlueStar in the Network Simulator (ns-) [1] and BlueHoc [13], an open-source Bluetooth simulator provided by IBM. We have made considerable extensions to this simulator. It may be noted that, from now on, we consider an IEEE 80.11b DSSS (Direct Sequence Spread Spectrum) running at 11 Mbps for all our simulations and discussions. Also, we have developed a hybrid Bluetooth model that has been incorporated into the BWGs. Figure 8 depicts the packet collision and withdrawal probabilities obtained through simulation and the ones obtained analytically (section 3.1). As we can see, our simulation results closely match with the analytical ones. Bluetooth with BCS greatly reduces the number of collisions and defers packet transmission until a safe channel is found. Similarly, Figures 9(a) and 9(b) present the aggregate throughput for the scenario simulated corresponding to the ordinary Bluetooth and Bluetooth with BCS, respectively (the analytical values of the aggregate throughput can be easily derived) As we had already estimated by our analytical model, Bluetooth with BCS practically doubles the maximum bandwidth achieved by the normal Bluetooth implementation. While the maximum throughput achieved by Bluetooth is of the order of 8 Mbps when there are 60 piconets in the network, Bluetooth with BCS goes up to 15.5 Mbps for a total of 90 piconets. Thus, we see that not only BCS can drastically increase throughput but also enable efficient support of a larger number of co-located piconets. Packet collision 1-slot 5-slot Figure 5 Packet collision and withdraw probabilities for different slot length packets V. COMBINED BLUETOOTH AND WLAN SIMULATION ENVIRONMENT In this section we carry out experiments with both intermittent and persistent interferences. For that, we utilize the implementations of both BCS and AFH. A. TCP/IP Traffic Simulation 3-slot Packet withdrawal We now discuss details of BlueStar simulations in a real scenario where TCP/IP applications are put into use. A similar network model for evaluating Bluetooth and interference has been employed in [14]. In Figure 10, the horizontal plane depicts the Bluetooth plane with Bluetooth devices distributed uniformly in the plane in an area of 500m x 500m. Similar to earlier simulations, we have considered a network initially comprising of 10 piconets, and increase the number of piconets in steps of 10 till 00 piconets. The number of devices per piconet is uniformly chosen between 4 and 8, and we have only considered Bluetooth DH5 packets. In Figure 10, piconet 1 holds the slave device S assuming the role of BWG, and located at the center of the Bluetooth plane, which is also the intersection of the vertical WLAN axis, and the horizontal Bluetooth plane axis. This particular piconet has a slave in the logical origin of the plane and its master 5m away from it. Contrary to the previous simulations, the application layer of the piconet devices consists of FTP sessions established between masters and slaves using the same parameters. Within piconet 1, the BWG is responsible for relaying FTP packets forwarded by the master M to the WLAN AP, which in turn possesses a sink agent to receive these packets and perform measurements. In order words, the traffic between the WLAN AP and Bluetooth network also consists of FTP traffic. For this study, we set the offered load in each piconet to 30% of its total capacity, and assume Bluetooth stations to be stationary as currently assumed by BlueHoc [13].

5 IEEE packet Collision sense f(k) sense f(k + ) Piconet i f(k) f(k + 1) f(k + ) Withdrawal Bluetooth device piconet 00. piconet 1 piconet Maste r Slave Figure 6 Potential packet collisions between IEEE and Bluetooth Figure 7 Bluetooth-only network topology model Analytical Packet collision 1-slot 5-slot 3-slot Packet withdrawal Figure 8 Simulation of packet collision and withdraw probabilities We have selected and analyzed four possible scenarios as follows: Scenario A: The flow of data packets is from the WLAN AP to the BWG, reflecting an application where Bluetooth devices downloading contents from the WAN; Scenario B: This scenario is the opposite of the previous one with the Bluetooth devices uploading information to the WAN, i.e., the flow of data packets is from the BWG to the WLAN AP; Scenario C: A BWG might find itself in a situation where it simultaneously receives data packets from both the WLAN AP and the Bluetooth devices in order to synchronize information in the BWG; Scenario D: This scenario models the opposite situation as described in scenario C. In other words, it is the case where the BWG simultaneously transmits data packets to both the Bluetooth devices and the WLAN AP. As for the WLAN axis, it is composed of an AP, located at (0, 00)m, which has a radio range of 50m [15]. As employed in other studies [10], the WLAN packet payload is set to bits while the packet header is set to 4 bits, resulting in a total size of approximately 1.5 KByte. The analysis of the impact of the WLAN packet size on Bluetooth is out of scope of this paper (study of the performance of a WLAN network for different WLAN packet sizes can be found in [17]). Table shows the values used to configure the BlueStar simulation. Figures 11, 1, 13 and 14 shows two different views of the same simulation for the four scenarios considered. While Figures 11(a), 1(a), 13(a), and 14(a) depict the average link throughput achieved within piconet 1, Figures 11(b), 1(b), 13(b), and 14(b) show its relative PER (packet error rate) for the same scenarios. In general, we can see that the PER increases and the throughput decreases due to an increase in the interference level as more piconets are added. As we can see from the figures, for the regular Bluetooth implementation scenarios B and D experience a sizeable degradation in throughput as compared to scenarios A and C, with scenario B having the largest impact. This is because particularly true in these scenarios because when the BWG is transmitting data packets towards the AP, there is a high persistent interference in the Bluetooth network causing a high PER as depicted in the respective Figures 1(b) and 14(b). On the other hand, in scenarios A and C the BWG is sending acknowledgments (ACKs) to the AP, therefore reducing the probability of packets being corrupted. The reason why scenario B suffers a higher performance drop (and higher PER) than scenario D is because the WLAN transmissions corrupts the Bluetooth data packets in scenario B, while in scenario D only Bluetooth ACK packets are susceptible to be corrupted by WLAN transmissions. Therefore, since the ACK packets are small in size as compared to data packets, they are more likely to be successfully received during the off-cycle of the WLAN transmission, resulting in the scenario B experiencing an extremely high PER as can be seen from Figure 1(b). Now let us analyze the behavior the AFH, BCS, and BlueStar for the same scenarios B and D. Since these scenarios are more impacted by persistent interference, AFH is effective for a larger number of piconets until it reaches a point where the intermittent interference levels becomes significant. At these points, BCS performs better by effectively mitigating intermittent interference sources. Also note that, despite the high interference levels, BlueStar, employing both AFH and BCS, accomplishes enhanced performance by achieving the highest throughput and lowest PER. As for scenarios A and C, AFH is now effective only for a smaller number of piconets as the larger impact comes from intermittent interference. Similarly, BlueStar obtains best results, although it is slightly affected in scenarios B and D due to the high persistent interference levels. Note that in scenarios A and C (especially in scenario A) the regular Bluetooth implementation shows performance sometimes comparable to that of the AFH scheme, which is primarily due to the TCP congestion control mechanisms employed in the WLAN interface. When collisions in the WLAN traffic occur, the frame has to be completely retransmitted as IEEE WLANs do not employ any kind of FEC (forward error correction). Therefore, upon packet collision, the TCP timers expire, resulting in the congestion window being set to 1 MSS (Maximum Segment Size) and the slowstart algorithm being executed. This situation effectively allows Bluetooth devices to capture the channel and use them for its transmissions. At the time TCP reestablishes its transmission rate, the Bluetooth devices would have already performed its packet transmissions. This kind of situation has been more frequent in scenario A than in C because in scenario A the WLAN transmissions have been corrupting the Bluetooth ACK packets, while in scenario C Bluetooth data packets are more impacted. Moreover, it is also important to highlight the performance of AFH as it outperforms BCS under a small number of piconets, since most of the interference is of persistent type. However, as the number of piconets increase, and hence the intermittent interference level, the performance of AFH degrades and BCS becomes more efficient both in terms of PER and throughput. More specifically, in scenarios B and D AFH is more efficient than BCS up to 90 and 7 piconets respectively, whereas in scenarios A and C AFH performs better when the number of piconets is approximately less than 55. In all scenarios, BlueStar achieves the best throughput and the lowest PER by taking advantage of both AFH and BCS.

6 Analytical Analytical Figure 9(a) Aggregate throughput for ordinary Bluetooth TABLE. BlueStar simulation parameter setting W BCS 50s PER THRES 15% T SCAN 0s Bluetooth device (0,00) M S (0, 0) (5, 0) WLAN access point (AP) piconet 1 Figure 10 WLAN and Bluetooth network simulation model VI. DISCUSSION ON PLACEMENT AND NUMBER OF BWGS As a final topic of this paper, in this section we discuss how many BWGs are needed to provide efficient and uninterrupted coverage to all devices in a Bluetooth scatternet, as well as where to place these BWGs. We refer to these as the placement and the number problems. As a matter of fact, this is a very important and natural issue for any organization that aims to implement an architecture such as BlueStar in its domain. For this discussion, we do not consider the case where devices in one piconet may reach BWGs in other piconets by using some kind of multi-hop wireless routing protocol. Rather, we handle this problem by devising a model that gives us an upper bound on the number of BWGs that would be needed to efficiently provide full coverage to the Bluetooth devices. In other words, we carry out a worst-case analysis. We make few assumptions about the placement of a BWG within a piconet and the scatternet organization, as illustrated in Figure 15. As a matter of simplicity, we propose a model whereby the BWGs serve as bridge node between exactly two neighboring piconets (as also assumed in [18]) and, therefore, we place them along the border between two piconets as depicted in Figure 15(a). Furthermore, we assume that piconets have a circular shape and are centered on the master, and that piconet devices are uniformly distributed around the border of the piconet. This is a realistic assumption as Bluetooth devices possess omni directional antennas and the radio range covered by such antennas approximates a circle. The addition of another piconet to the scatternet of Figure 15(a) could result in two distinct configurations as depicted in Figures 15(b) and 15(c). While in Figure 15(b) the addition of a piconet Figure 9(b) Aggregate throughput for Bluetooth with BCS resulted in the addition of only one more BWG, the same piconet might also result in the addition of two more BWGs as shown in Figure 15(c). In other words, the topology of interconnection has influence on the number of resulting BWGs. However, since we are interested in an upper bound (worst-case) on the number of BWGs, our task is simplified by considering only the topology which results in the highest interconnection, as exemplified in Figure 15(d). In Bluetooth, it is possible to have all eight devices of a piconet working as bridge nodes. For mathematical simplicity, we impose a restriction that only the master device is not allowed to work as a BWG. Thus, among seven BWGs of a piconet, each BWG is shared by two piconets. It is clear that we can have at most 7n/ BWGs in a scatternet composed of n piconets. In fact, the total number of BWGs required will be fewer than these as there is no need to have a BWG on non-bridge devices as shown in the outer parts of Figures 15(c) and 15(d). We can formalize this fact by the following propositions that set the upper bound on the number of BWGs needed throughout a scatternet. Proposition 1 For a scatternet comprised of n (n > 0) piconets, where piconets have a circular (or near-circular) shape (see Figure 7n 15(b)), the number of BWGs needed is at most 4 4 n. Proof: Suppose that the radius of each piconet is R (see Figures 15(a) and 15(b)). Then, the total coverage of the n piconets is about n R. Since the piconets are organized as a circle whose radius R satisfies the equation R n R, or R n R, the estimated number of boundary piconets is: R' ( R' R) (4) 4 4 n R Since each boundary piconet has at least four non-bridge devices with other potential piconets (see Figure 16(d)), the number of bridge devices is at most E = 7n 44 n 4. Therefore, the maximum number of BWGs for a scatternet comprised of n circular (or near-circular) shaped piconets is E/ or: 7n 4 4 n Proposition For a scatternet comprised of n (n > 0) piconets, the 7n maximum number of BWGs needed is 4 4 n.

7 Figure 11(a) Throughput in Scenario A Figure 11(b) PER in Scenario A Figure 1(a) Throughput in Scenario B Figure 1(b) PER in Scenario B Figure 13(a) Throughput in Scenario C Figure 13(b) PER in Scenario C Figure 14(a) Throughput in Scenario D Figure 14(b) PER in Scenario D

8 BWG Bluetooth device Piconet master R R R R (a) (b) (c) (d) Figure 15 Scheme for the number of BWGs. (a) One BWG for each pair of two piconets. (b) New piconet resulting in the addition of one more BWG. (c) New piconet resulting in the addition of two more BWGs. (d) A scatternet composed of 19 piconets. Piconet Proof: This follows directly from the previous proposition. Fewer boundary piconets imply fewer non-bridge devices or, in other words, more bridges and thus more required BWGs. According to the basic geometry theory, for a given coverage area equal to that covered by n piconets, a circle will have the shortest perimeter. This means a circle will have the fewest boundary piconets among all possible shapes. Therefore, the upper bound on the number of BWGs (U BWG ) needed in a circular-shaped scatternet is also the upper bound on the number of BWGs needed in any-shaped scatternet. From Proposition 1, we have that this upper bound is: 7n U 4 4 n (5) BWG Proposition means that any other shaped scatternet topology will require fewer BWGs as compared to the circular one. Therefore, through these last two propositions we have found a logical bound on the number of BWGs to be placed within a scatternet. Of course, one possible configuration would be to have each and every Bluetooth device with a WLAN interface, but this is neither costeffective nor practical. We have shown by Propositions 1 and that we can do better while still providing full coverage to all devices. VII. CONCLUSIONS Recently, there has been very little research on how Bluetoothenabled devices can have seamless and uninterrupted access to global networks such as the Internet. This paper introduces a novel Bluetooth architecture called BlueStar, which employs a combination of Adaptive Frequency Hopping and Bluetooth Carrier Sensing to efficiently provide advanced wide area services to Bluetooth devices. BlueStar can take advantage of the existing installed base of IEEE wireless networks by assigning selected Bluetooth devices, called Bluetooth Wireless Gateways (BWG) with IEEE capabilities. These BWG are responsible for providing uninterrupted access to the WAN, such as the Internet, to the entire Bluetooth network (piconet or scatternet). BlueStar is observed to greatly outperform existing Bluetooth under different traffic conditions. The incorporation of BlueStar into Bluetooth is simple, does not incur much overhead, and hence is an excellent enabler for co-existence and cooperation of Bluetooth and REFERENCES [1] Bluetooth SIG, Bluetooth Specification, [] C. Bisdikian, An Overview of the Bluetooth Wireless Technology, IEEE Comm. Magazine, December 001, pp.: [3] Y. Lim, J. Kim, S. Min, and J. Ma, Performance evaluation of the Bluetoothbased public Internet access point, Proceedings of 15th International Conference on Information Networking, 001. [4] M. Albrecht, M. Frank, P. Martini, M. Schetelig, A. Vilavaara, A. Wenzel, IP services over Bluetooth: leading the way to a new mobility, in LCN 99, 1999, pp.: -11 [5] N. Golmie and F. Mouveaux, Interference in the.4 GHz ISM band: Impact on the Bluetooth access control performance, in Proc. of the IEEE ICC 01, Helsinki, Finland, June 001. [6] M. Fainberg, and D. Goodman, Analysis of the Interference Between IEEE 80.11b and Bluetooth Systems, in the IEEE VTC Fall, October 001. [7] S. Zurbes, W. Stahl, K. Matheus and J. Harrtsen, Radio network performance of Bluetooth, in IEEE ICC 000, vol. 3, pp [8] C. Cordeiro, D. Sadok and D. Agrawal, Piconet Interference Modeling and Performance Evaluation of Bluetooth MAC Protocol, in Proceedings of IEEE GLOBECOM, San Antonio, USA, 001. [9] H. Gan and B. Treister, Adaptive frequency hopping implementation proposals for IEEE / WPAN, IEEE /367r0, 000. [10] D. Famolari, Link Performance of an Embedded Bluetooth Personal Area Network, in Proc. of ICC, Helsinki, June 001. [11] R. Braley, I. Gifford, and R. Heile, Wireless personal area network: an overview of the IEEE P80.16 working group, Mobile Computing and Comm. review, vol.4, no. 1, pp.: 0-7, [1] The Network Sumulator (ns-), [13] BlueHoc, IBM Bluetooth Simulator, [14] N. Golmie, R.E. Dyck, and A. Soltanian, Bluetooth and 80.11b interference: simulation model and system result, IEEE 80.15/195r0, 001. [15] IEEE Std IEEE Standard for Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specification, June [16] IEEE Coexistence Task Group, [17] J. Zyren, Reliability of IEEE Hi Rate DSSS WLAN in a High Density Bluetooth Environment, White Paper, Harris Semicond., June [18] T. Salonidis, P. Bhagwat, L. Tassiulas, and R. LaMaire, Distributed Topology Construction of Bluetooth Personal Area Networks, in Proc. of INFOCOM, April 001. [19] Mobilian, Mobilian TrueRadio, [0] Possio, Possion PX0, [1] Red-M, Genos wirelessware, [] C. Perkins, E. Royer, and S. Das, Ad Hoc On Demand Distance Vector Routing (AODV), Internet Draft, March 001 (work in Progress). [3] D. Johnson, D. Maltz, Y.-C. Hu, and J. Jetcheva, The dynamic source routing protocol for mobile ad hoc networks (DSR), IETF Internet-Draft, draftietf-manet-dsr-06.txt, work in progress, Nov [4] M. Gerla, Y. Lee, R. Kapoor, T. Kwon, and A. Zanella, UMTS-TDD: A Solution for Internetworking Bluetooth Piconets in Indoor Environments, In Proc. of ISCC, July 00. [5] N. Rouhana and E. Horlait, BWIG: Bluetooth Web Internet Gateway, In Proc. of ISCC, July 00. [6] O. Kasten, and M. Langheinrich, First Experiences With Bluetooth in the Smart-Its Distributed Sensor Network, in Proc of the Workshop on Ubiquitous Computing and Communications (PACT), Oct [7] F. Siegemund, and M. Rohs, Rendezvous Layer Protocols for Bluetooth- Enabled Smart Devices, in Proc. 1st International Conference on Architecture of Computing Systems, April 00. [8] C. Cordeiro, D. Agrawal, and D. Sadok, Piconet Interference Modeling and Performance Evaluation of Bluetooth MAC Protocol, in IEEE Transactions on Wireless Communications, accepted for publication. [9] D. Agrawal and Q-A. Zeng, Introduction to Wireless and Mobile Systems, Brooks/Cole Publishing, 438 pages, ISBN , 00. [30] C. Cordeiro and D. Agrawal, Employing Dynamic Segmentation for Effective Co-located Coexistence between Bluetooth and IEEE WLANs, in IEEE GLOBECOM, Taiwan, November 00.