Mobile Networks and Applications 9, 409–422, 2004 2004 Kluwer Academic Publishers. Manufactured in The Netherlands.
BlueStar: Enabling Efficient Integration between Bluetooth WPANs and IEEE 802.11 WLANs CARLOS DE M. CORDEIRO ∗ , SACHIN ABHYANKAR, RISHI TOSHIWAL and DHARMA P. AGRAWAL OBR Research Center for Distributed and Mobile Computing, Department of ECECS, P.O. Box 210030, University of Cincinnati, Cincinnati, OH 45221-0030, USA
Abstract. Bluetooth is a radio technology for Wireless Personal Area Networking (WPAN) operating in the 2.4 GHz 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 architecture (BlueStar) whereby selected Bluetooth devices, called Bluetooth Wireless Gateways (BWGs), are also IEEE 802.11 enabled so that these BWGs could serve as egress/ingress points to/from the IEEE 802.11 wireless network. We propose mitigating interference between Bluetooth and IEEE 802.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 802.11 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 802.11 networks. Moreover, we define the protocol stack employed by BlueStar as well as indicate how BWGs efficiently manage their capacity allocation through the different systems. We also mathematically derive an upper bound on the number BWGs needed in a Bluetooth scatternet so that uninterrupted access to all Bluetooth devices could be provided. Keywords: analytical modeling, architecture, Bluetooth, carrier sensing, frequency hopping, gateway, IEEE 802.11, interference, protocol stack, simulation
1. Introduction Bluetooth [1,5] is a wireless communication technology that provides short-range, semi-autonomous radio network connections, and offers the ability to establish ad hoc networks [8], called piconets. It has also been chosen to serve as the baseline of the IEEE 802.15.1 standard for wireless personal area networks (WPANs) [3]. A WPAN is defined as the connection among personal devices, allowing information exchange over short ranges. Eventually, this WPAN can be integrated with large wide area networks (WANs) to provide Internet connectivity in addition to access among these devices. As previous studies have pointed out [7,11,13,23,34], it is much likely that Bluetooth devices and IEEE 802.11 [19] wireless local area networks (WLANs) stations (in this work we use the term WLAN and IEEE 802.11/802.11b interchangeably) operating in the 2.4 GHz ISM (industrialscientific-medical) frequency band should be able to coexist as well as cooperate with each other, and access each other’s resources. These technologies are complementary to each other and such an integrated environment is envisioned that Bluetooth devices obtain information through the WLAN, and ultimately the Internet. These cooperative 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 ∗ Contact author.
WLAN, empowering low-cost, short-range devices to access the global Internet infrastructure through the use of WLANbased high-powered transmitters. It is also possible that Bluetooth devices might access the WAN through a 3G cellular infrastructure like Universal Mobile Telecommunication System (UMTS) and cdma2000 [3]. 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 readily 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 defining the BlueStar architecture is that both Bluetooth and WLANs employ the same 2.4 GHz ISM band and can possibly impact the performance [1,7,12,17]. We refer to the interference generated by WLAN devices over the Bluetooth channel as persistent interference [7], while the presence of multiple piconets in the vicinity creates interference [7,9,11,23,34] referred to as intermittent interference [7,9]. To combat both of these interference sources and provide effective coexistence, we propose to employ a unique hybrid approach of adaptive frequency hopping (AFH) [14] and a new mechanism called Bluetooth carrier sense (BCS) in BlueStar. AFH seeks to mitigate persistent interference by scanning the channels during a monitoring 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.
410
BCS takes care of the intermittent interference by mandating that before any Bluetooth packet transmission, the transmitter has to sense the channel to determine the presence of any ongoing activity. This channel sensing is performed during 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 802.15 Coexistence Task Group 2 terminology [18], BlueStar would be classified as a non-collaborative solution in the sense that the Bluetooth and the WLAN system operate independently, with no exchange of information (as a matter of fact, this is required by the Federal Communications Commission regulations for the license-free bands). This lack of information does not, however, have any 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 [2,23] 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 widely available WLAN installed base as many organizations have spent hundreds of thousands of dollars (including personnel training) building their WLAN infrastructure, and it is advantageous to use pre-existing WLAN infrastructure. This can easily support long-range, large-scale mobility as well as provide uninterrupted access to Bluetooth devices. The architecture of Bluetooth and WLAN enabled devices proposed here is an intuitive and practical solution to this ad hoc issue, and even though such an arrangement has been evaluated in [13], no mechanism or architecture has been used to mitigate interference between the Bluetooth and the WLAN. Here, 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 integrating Bluetooth and WLAN [25,27,28]. 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 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 relying on the availability of Bluetooth interfaces. The remainder of this paper is organized as follows. Section 2 provides an introduction to the Bluetooth technology, whereas section 3 elaborates on the proposed BlueStar architecture, including a novel combination of AFH and BCS to handle both intermittent and persistent interferences, as well as it presents the capacity allocation scheme employed in BlueStar. Next, section 4 discusses our simulation environment. The performance of BlueStar in a Bluetooth-only scenario is then shown in section 5, while section 6 evaluates BlueStar in a combined IEEE 802.11 and Bluetooth environment. Section 7 discusses placement issues of BWGs. Finally section 8 concludes this paper.
CORDEIRO ET AL.
2. Bluetooth overview The details of the Bluetooth system, architecture and protocols are defined in [5]. A brief overview is provided here for completeness. Bluetooth is a short-range (up to 10 m) wireless technology aimed at replacing cables that connect phones, laptops, and other portable devices. Bluetooth operates in the ISM frequency band starting at 2.402 GHz and ending at 2.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 625 µs slots and, with a 1 Mbit/s symbol rate, a slot can carry up to 625 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 2/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.
Figure 1. Packet transmission in Bluetooth. Table 1 Asynchronous connectionless (ACL) packet overview. Type
User payload (bytes)
FEC
Symmetric (Kbps)
DM1 DH1 DM3 DH3 DM5 DH5
0−17 0−27 0−121 0−183 0−224 0−339
Yes No Yes No Yes No
108.0 172.8 256.0 384.0 286.7 432.6
Asymmetric (Kbps) 108.8 172.8 384.0 576.0 477.8 721.0
108.8 172.8 54.4 86.4 36.3 57.6
BLUESTAR: ENABLING EFFICIENT INTEGRATION
3. 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 802.11 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 personal digital assistant (PDA), and have wide-area connectivity as well. Figure 2(a) illustrates the BlueStar architecture with a scatternet, composed of total of four piconet, where each piconet has several slaves (indicated by the letter Si,j ) and one master (indicated by the letter Mi ). 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. The interaction between the Bluetooth network and the outside world is managed by the BWGs. Two possible protocol stacks to carry IP packets over Bluetooth could be employed within BWGs. The first option is to transmit IP packets over point-to-point protocol (PPP) over RFCOMM [5], by taking advantage of the fact that PPP is already implemented in most mobile devices. However, such arrangement has been found to be highly inefficient given its redundancy [5]. Therefore, the Bluetooth SIG [5] has published a native way for carrying IP traffic over Bluetooth by a protocol called Bluetooth network encapsulation protocol (BNEP) wherein IP packets are encapsulated in Ethernet packets which are then carried over Bluetooth links. In BlueStar we have opted for the latter and such architec-
(a)
411
ture is shown in figure 2(b), where the protocol stack is presented for each of its entities. As we can see, BlueStar reuses existing protocols wherever possible. Note that other optimized protocol stacks have been proposed to serve specific applications [29], while the architecture we adopt does not have such restriction. In order for Bluetooth devices to be directly addressed, we assume that every Bluetooth device possesses an IP address and any of the well-known routing algorithms [20,26] 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 (including routing) them through the corresponding wireless system. 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 2.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. 3.1. Bluetooth carrier sense (BCS) BlueStar employs carrier sense so that intermittent-like interference can be avoided. The current Bluetooth specification [5] 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 802.11, Bluetooth carrier sensing would be much simpler due to the nature of its MAC protocol [9,11,22]. Therefore, in this work we assume that Bluetooth devices possess a sensing capability. We incorporate BCS into Bluetooth without any modifications to the current slot structure. As stated in section 2, with a symbol rate of 1 Mbit/s a Bluetooth slot can carry up to 625 bits. However, to allow the Bluetooth transmitter and
(b) Figure 2. (a) BlueStar proposed architecture. (b) Protocol stack for each entity.
412
CORDEIRO ET AL.
Figure 3. Carrier sensing mechanism in Bluetooth.
Figure 4. Timing of two Bluetooth packets on different piconets.
Bluetooth receiver devices to change from Rx to Tx mode and make the frequency synthesizer tune to the next channel frequency, a 259 µs turn around time is left at the end of the last slot. With current improvements in the Bluetooth chip design [5] and the need for backward compatibility, the Bluetooth device in the near future will keep part of this turn around time unused as idle, hence enabling it to perform some other useful tasks. This turn around period is illustrated in the figure 3 as well as our BCS proposal, where the dashed block denotes the sense window of size WBCS . 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. A 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 [15] 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 asynchronous and are transmitted with period Tp , which depends upon the Bluetooth packet type p. For instance, if p is equal to DH1 or DM1 we have that Tp = 2 · slotsize, where slotsize is the size of a Bluetooth slot, and is equal to 625 µsec. Figure 4 illustrates the timing of two Bluetooth packets p and z generated at piconets i and j with sizes Sp,i and Sz,j , respectively. The probability of packet collision between piconets i and j , pc (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) [7,9], we have that: pc (i, j ) = (Sp,i + Sz,j )/ max slotsperpacket(p), 1 (1) slotsperpacket(z) + 1 · slotsize · , C where C is the number of available frequency channels and is equal to 79 in most countries [5]. 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
BLUESTAR: ENABLING EFFICIENT INTEGRATION
413
Figure 5. Packet collision and withdrawal probabilities for different slot length packets.
of N piconets. The packet collision probability with a packet originated at the ith piconet is given by:
p¯c (i) = 1 − 1 − pc (i, j )
N−1
.
(2)
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 (i) = 1− 1−
WBCS + Sz,j 1 · (slotsperpacket(z) + 1) · slotsize C
N−1 .
(3) Aggregate throughput is another important performance measure when you consider a collection of piconets operating in a proximity. In Bluetooth, data packets are followed by an acknowledgement in the opposite direction from the recipient. Thus, we can obtain the aggregate throughput of N piconets relative to a Bluetooth packet X as given by: S(X)=µ(X)N 2(ACKinbits(X) + sizeinbits(X)) 1 N−1 × 1− · , (slotsperpacket(X) + 1) · slotsize C (4) where ACKinbits(X) and sizeinbits(X) are the size in bits of the acknowledgement and data packet type X, with µ(X) being the nominal throughput of X (see table 1). The acknowledgement information is included in the header of the return packet, and hence called piggy-backing. In our analysis, we consider the case where acknowledgements do not carry payload information, thereby making ACKinbits(X) in equation (4) always equal to 126 bits [5]. Similarly, the ag-
gregate throughput for Bluetooth with BCS becomes: SBCS (X) = µ(X)N ACKinbits(X) + sizeinbits(X) + 2WBCS 1 N−1 · . × 1− (slotsperpacket(X) + 1) · slotsize C (5) 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 WBCS = 50 µs. Such an analysis of a high number of piconets (up to 200) is crucial given the new wave of applications of Bluetooth in wireless sensor networks [21,24,31] where thousands of sensors equipped with Bluetooth interfaces are to be employed, hence requiring hundreds of piconets to be formed and operate with minimum interference amongst each other [9]. Thus, the analyses carried out in this paper also have these sorts of scalable 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, the rate of increase is also distinct for different slot length packets. Figures 6(a) and 6(b) respectively illustrate the aggregate throughput for ordinary Bluetooth and Bluetooth with BCS for the same value of WBCS . A mere glance of these two figures reveals that Bluetooth with BCS practically doubles the available throughput for most packet types. For instance, using DH3 packets with ordinary Bluetooth, the maximum attainable throughput with 60 piconets is of 8.03 Mbps, whereas Bluetooth with BCS achieves a bandwidth of up to 15.2 Mbps with 110 piconets in the network. Thus, Bluetooth with BCS not only significantly increases the overall throughput but also enables a larger number of nearby piconets to operate efficiently.
414
CORDEIRO ET AL.
(a)
(b)
Figure 6. (a) Aggregate throughput for ordinary Bluetooth. (b) Aggregate throughput for Bluetooth with BCS.
Figure 7. Potential packet collisions between IEEE 802.11 and Bluetooth.
3.2. Bluetooth adaptive frequency hopping (AFH) A careful observation reveals that some packet collisions are still not detected by BCS. Given that a IEEE 802.11 DATA frame has a maximum size of up to 2346 octets [19] and a Bluetooth slot occupies 625 bits (with 366 bits of actual transmitted data), we conclude that, in the worst case, a IEEE 802.11 DATA frame can overlap with up to 30 Bluetooth slots (RTS-CTS-ACK are much smaller in size and hence do not overlap with so many Bluetooth slots). Figure 7 shows two potential cases of packet collisions. Although the IEEE 802.11 WLAN senses the channel before transmission, it cannot sense the Bluetooth activities [6], 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 802.11 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 7). To cope up with this type of interference, called persistent interference, BlueStar employs AFH [14], 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 PERTHRES , 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 [14]. 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 (2) changes periodically with the re-evaluation of the channels by the AFH mechanism, and will always be at most equal to 79. 3.3. Capacity allocation scheme 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 (this scheme is an enhanced version of the one presented in [15]). In the BlueStar architecture, the
BLUESTAR: ENABLING EFFICIENT INTEGRATION
415
BWGs have to act as forwarding units between the wireless systems besides serving as source or destination for their own applications. Thus, a BWG must spend a proportional amount of time in receiving data as in forwarding it. Obviously, because of mismatch in packet sizes and the eventual segmentation and reassembly overheads, the time spent in one network may not be exactly the time spent in the other. Since a BWG can be present only in one piconet at a time, the total capacity a BWG can provide to the users it serves is bounded by half the piconet capacity. This prevents the fair distribution of the capacity when a BWG serves more than half the total number of users in the scatternet. For example, consider now a BWG of a piconet, say P1 , in the network. If this BWG serves a fraction f of the slaves, then it spends a fraction of time equal to the minimum of f and 0.5 in P1 . Thus, if f is greater than 0.5, the slaves served by the BWG gets less than their fair share. As explained earlier, the total time spent by the BWG in, say, two other piconets it belongs to should be equal to that spent in P1 . This time is distributed between these two piconets in a fair manner, depending upon the total number of users served by each of them, where the total number of users is the sum of the users in the piconet and those served by the other BWG in the piconet. Therefore, the system divides its bandwidth amongst the slaves as fairly as possible. In particular, if the number of slaves in the piconets is distributed in a uniform manner (i.e., the number of slaves served by one BWG is not greater than half of the total number of slaves), the system gives each slave an equal amount of bandwidth towards the IEEE 802.11 network. If there is a change in the number of slaves in any piconet, the polling cycle and the capacity allocation are adjusted as described.
4. Simulation of BlueStar We have implemented all functionalities of BlueStar in the network simulator (ns-2) [33] and BlueHoc [4], an opensource Bluetooth simulator provided by IBM. Since BlueHoc only provides the basic functionality of Bluetooth, we have made considerable extensions to this simulator. In addition, we consider that the interfering range of Bluetooth devices is
about two times larger than the transmission range [10,32]. More specifically, in our simulations we consider the transmission range to be 10 m and the interfering range to be 22 m. It may be noted that, from now on, we consider an IEEE 802.11b DSSS (Direct Sequence Spread Spectrum) running at 11 Mbps for all our simulations and discussions. Also, we have developed a hybrid Bluetooth-802.11 model that has been incorporated into the BWGs.
5. Bluetooth-only simulation environment Our initial experiment employs an environment comprised of only Bluetooth devices without any external sources of interference. Therefore, since we are mainly concerned with intermittent interference and BCS, AFH is not employed. Figure 8 illustrates the topology used for this evaluation which is similar to the one employed in [9]. Within a total area of 500 m × 500 m, we have considered a network composed initially of 10 piconets. For each of the twenty simulation runs, we increase the number of piconets by 10 up to a total of 200 piconets, where each piconet comprises of four devices. During each simulation, each piconet master establishes a CBR (constant bit rate) connection with each of its slaves with a MTU (maximum transfer unit) of 512 bytes (thus, segmentation is performed into Bluetooth baseband packets), and the transmission lasts for the entire simulation length of 300 seconds. Regarding the BCS implementation, we set the sense window size WBCS = 50 µs. Figure 9 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 one. Bluetooth with BCS greatly reduces the number of collisions and defers packet transmission until a safe channel is found. Similarly, figures 10(a) and (b) present the aggregate throughput for the scenario simulated corresponding to the ordinary Bluetooth and Bluetooth with BCS, respectively. 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
Figure 8. Bluetooth-only network topology model.
416
CORDEIRO ET AL.
Figure 9. Simulation of packet collision and withdrawal probabilities.
(a)
(b)
Figure 10. Aggregate throughput for (a) ordinary Bluetooth; (b) Bluetooth with BCS.
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. 6. 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. 6.1. TCP/IP traffic simulation 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 802.11 interference has been employed in [16]. In figure 11, the horizontal plane depicts the Bluetooth plane with Bluetooth devices distributed uniformly in the plane in an area of 500 m × 500 m. 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 200 piconets. The number of devices per piconet is uniformly chosen between 4 and 8, and we have only considered Bluetooth DH5 packets. In figure 11, 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 5 m away from it. Contrary to the previous simulations, the application layer of the piconet devices consists of FTP sessions established be-
BLUESTAR: ENABLING EFFICIENT INTEGRATION
tween 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 other 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 [4]. 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;
417
• 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, 200) m, which has a radio range of 250 m [19]. As employed in other studies [13], the WLAN packet payload is set to 11776 bits while the packet header is set to 224 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 [35]). For each simulation, we conducted a total of five 300 seconds iterations, and these runs are averaged to give the final results. Table 2 shows the values used to configure the BlueStar simulation, while table 3 summarizes the WLAN parameters. Figures 12–15 show two different views of the same simulation for the four scenarios considered. While figures 12(a), 13(a), 14(a), and 15(a) depict the average link throughput achieved within piconet 1, figures 12(b), 13(b), 14(b), and 15(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 sizeTable 2 BlueStar simulation parameter setting. 50 µs 15% 20 s
WBCS PERTHRES TSCAN
Table 3 IEEE 802.11/WLAN simulation parameter setting. CW_min CW_max Packet header Payload size
16 1024 224 bits 11776 bits
Figure 11. WLAN and Bluetooth network simulation model.
(a)
(b) Figure 12. (a) Throughput in scenario A. (b) PER in scenario A.
418
CORDEIRO ET AL.
(a)
(b) Figure 13. (a) Throughput in scenario B. (b) PER in scenario B.
(a)
(b) Figure 14. (a) Throughput in scenario C. (b) PER in scenario C.
(a)
(b) Figure 15. (a) Throughput in scenario D. (b) PER in scenario D.
able degradation in throughput as compared to scenarios A and C, with scenario B having the largest impact. This is 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 13(b) and 15(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)
BLUESTAR: ENABLING EFFICIENT INTEGRATION
419
(a)
(b) Figure 16. Aggregate throughput in (a) scenario C; (b) scenario D.
than scenario D is because the WLAN transmissions corrupt 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 13(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 802.11 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 slow-start 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 sce-
nario A the WLAN transmissions have been corrupting the Bluetooth ACK packets, while in scenario C Bluetooth data packets are more impacted. Therefore, scenario A performs slightly better due to the shorter and less frequent duration of the ACK packets. 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 72 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. As a final experiment, we have selected scenarios C and D and have collected the aggregate throughput for the entire Bluetooth network for the same simulation set up. The results are shown in figures 16(a) and (b). Similar to earlier results, we observe a higher drop in throughput for scenario D, especially for the ordinary Bluetooth implementation. As expected, AFH outperforms BCS when most of the interference is of persistent type, however degrades nearly at the same rate as the ordinary Bluetooth implementation when the number of piconets become larger than 50 and 65 for scenarios C and D, respectively. Likewise, BlueStar approximately doubles the throughput achieved in Bluetooth by combining AFH and BCS.
7. Discussion on placement and number of BWGs In this section we discuss how many BWGs are needed to provide adequate 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 is-
420
CORDEIRO ET AL.
(a)
(b)
(c)
(d) Figure 17. 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.
sue 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 multihop 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 17. 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 [30]) and, therefore, we place them along the border between two piconets as depicted in figure 17(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 17(a) could result in two distinct configurations as depicted in figures 17(b) and (c). While in figure 17(b) the addition of a piconet 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 17(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 the sketch of figure 17(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/2 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
BLUESTAR: ENABLING EFFICIENT INTEGRATION
421
non-bridge devices as shown in the outer parts of figures 17(c) and (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 17(b)), √ the number of BWGs needed is at most 7n/2 − 24 n − 4. Proof. Suppose that the radius of each piconet is R (see figures 17(a) and (b)). Then, the total coverage of the n piconets is about n · πR 2 . Since the piconets are organized as a circle whose√radius R satisfies the equation πR 2 ≈ n · πR 2 , or R ≈ n · R, the estimated number of boundary piconets is: √
πR 2 − π(R − 2R)2 = 4 n−4 . (6) πR 2 Since, according to our earlier assumption, each boundary piconet has at least four non-bridge devices with other potential piconets (see figure 17(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/2 or: √
7n −2 4 n−4 . (7) 2 Proposition 2. For a scatternet comprised of n (n > 0) piconets, √ the maximum number of BWGs needed is 7n/2 − 24 n − 4. 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 UBWG = −2 4 n−4 . 2 Proposition 2 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 cost-effective nor practical. We have shown by propositions 1 and 2 that we can do better while still providing full coverage to all Bluetooth devices.
8. Conclusions and future work There has been very little work on how Bluetooth-enabled devices can have seamless and uninterrupted access to global networks such as the Internet. This paper introduces a novel 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 802.11 wireless networks by assigning selected Bluetooth devices, called Bluetooth wireless gateways (BWG), with IEEE 802.11 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 IEEE 802.11. Future work in BlueStar includes defining a more elaborate capacity allocation algorithm. In addition, we plan to investigate the correlation amongst the various simulation parameters in order to assess their impact on BCS and AFH. Mobility of both IEEE 802.11 and Bluetooth devices and its impact on both systems are also part of our future research.
Acknowledgements This work has been supported by the Ohio Board of Regents Doctoral Enhancement Funds and the National Science Foundation under grant CCR-113361. We would like to thank the anonymous referees for their valuable comments and suggestions.
References [1] D. Agrawal and Q.-A. Zeng, Introduction to Wireless and Mobile Systems (Brooks/Cole, 2002). [2] M. Albrecht, M. Frank, P. Martini, M. Schetelig, A. Vilavaara and A. Wenzel, IP services over Bluetooth: leading the way to a new mobility, in: LCN’99 (1999) pp. 2–11. [3] C. Bisdikian, An overview of the Bluetooth wireless technology, IEEE Comm. Magazine (December 2001) 86–94. [4] BlueHoc, IBM Bluetooth simulator, http://oss.software. ibm.com/developerworks/opensource/bluehoc/. [5] Bluetooth SIG, Bluetooth specification, http://www. bluetooth.com. [6] R. Braley, I. Gifford and R. Heile, Wireless personal area network: an overview of the IEEE P802.16 working group, Mobile Computing and Comm. Review 4(1) (1999) 20–27. [7] C. Cordeiro and D. Agrawal, Employing dynamic segmentation for effective co-located coexistence between Bluetooth and IEEE 802.11 WLANs, in: IEEE GLOBECOM, Taiwan (November 2002). [8] C. Cordeiro and D. Agrawal, Mobile ad hoc networking (a tutorial), in: 20th Symposium on Computer Networks (May 2002) pp. 125–186, http://www.ececs.uc.edu/∼cordeicm/. [9] C. Cordeiro, D. Agrawal and D. Sadok, Piconet interference modeling and performance evaluation of Bluetooth MAC protocol, IEEE Transactions on Wireless Communications 2(6) (2003).
422
[10] C. Cordeiro, S. Das and D. Agrawal, COPAS: Dynamic contentionbalancing to enhance the performance of TCP over multi-hop wireless networks, in: IEEE IC3 N (October 2002). [11] 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 (2001). [12] M. Fainberg and D. Goodman, Analysis of the interference between IEEE 802.11b and Bluetooth systems, in: The IEEE VTC Fall 2001 (October 2001). [13] D. Famolari, Link performance of an embedded Bluetooth personal area network, in: Proceedings of ICC’01, Helsinki (June 2001). [14] H. Gan and B. Treister, Adaptive frequency hopping implementation proposals for IEEE 802.15.1/2 WPAN, IEEE 802.15-00/367r0 (2000). [15] M. Gerla, Y. Lee, R. Kapoor, T. Kwon and A. Zanella, UMTS-TDD: A solution for Internetworking Bluetooth piconets in indoor environments, in: Proceedings of ISCC (July 2002). [16] N. Golmie, R.E. Dyck and A. Soltanian, Bluetooth and 802.11b interference: simulation model and system result, IEEE 802.15/195r0 (2001). [17] N. Golmie and F. Mouveaux, Interference in the 2.4 GHz ISM band: Impact on the Bluetooth access control performance, in: Proceedings of the IEEE ICC’01, Helsinki, Finland (June 2001). [18] IEEE 802.15 Coexistence Task Group 2, http://www.ieee802. org/15/pub/TG2.html. [19] IEEE Std. 802-11, IEEE standard for wireless LAN medium access control (MAC) and physical layer (PHY) specification (June 1997). [20] D. Johnson, D. Maltz, Y.-C. Hu and J. Jetcheva, The dynamic source routing protocol for mobile ad hoc networks (DSR), IETF InternetDraft, draft-ietf-manet-dsr-06.txt (November 2001) (work in progress). [21] O. Kasten and M. Langheinrich, First experiences with Bluetooth in the Smart–Its distributed sensor network, in: Proceedings of the Workshop on Ubiquitous Computing and Communications (PACT) (October 2001). [22] Y. Kim, B. Zhen and K. Jang, Hybrid of listen-before-talk and adaptive frequency hopping for coexistence of Bluetooth and IEEE 802.11 WLAN, in: Proceedings of IEEE International Conference on Wireless LANs and Home Networks (December 2001). [23] Y. Lim, J. Kim, S. Min and J. Ma, Performance evaluation of the Bluetooth-based public Internet access point, in: Proceedings of 15th International Conference on Information Networking (2001). [24] V. Mehta and M.E. Zarki, A Bluetooth based sensor network for civil infrastructure health monitoring, Wireless Networks 10(4), Special Issue on Ad-Hoc Networking (2004) 401–412. [25] Mobilian, Mobilian TrueRadio, http://www.mobilian.com. [26] C. Perkins, E. Royer and S. Das, Ad hoc on demand distance vector routing (AODV), Internet Draft (March 2001) (work in progress). [27] Possio, Possion PX20, http://www.possio.com. [28] Red-M, Genos wirelessware, http://www.red-m.com. [29] N. Rouhana and E. Horlait, BWIG: Bluetooth web Internet gateway, in: Proceedings of ISCC (July 2002). [30] T. Salonidis, P. Bhagwat, L. Tassiulas and R. LaMaire, Distributed topology construction of Bluetooth personal area networks, in: Proceedings of INFOCOM’2001 (April 2001). [31] F. Siegemund and M. Rohs, Rendezvous layer protocols for Bluetoothenabled smart devices, in: Proceedings of the 1st International Conference on Architecture of Computing Systems (April 2002). [32] J. Sobrinho and A. Krishnakumar, Quality-of-service in ad hoc carrier sense multiple access wireless networks, IEEE J-SAC 17(8) (1999) 1353–1368. [33] The network simulator (ns-2), http://www.isi.edu/nsnam/ ns/. [34] S. Zurbes, W. Stahl, K. Matheus and J. Harrtsen, Radio network performance of Bluetooth, in: Proceedings of IEEE ICC’2000, Vol. 3, pp. 1536–1567. [35] J. Zyren, Reliability of IEEE 802.11 Hi Rate DSSS WLANs in a high density Bluetooth environment, White Paper, Harris Semiconductors (June 1999).
CORDEIRO ET AL.
Carlos de Morais Cordeiro received his Ph.D. in computer science and engineering in 2004 from the University of Cincinnati, OH, and his M.S. and B.Sc. in computer science in 1998 and 2000, respectively, from the Federal University of Pernambuco, Brazil. He is presently a research associate in the Center for Distributed and Mobile Computing at the University of Cincinnati. His research interests and papers are mostly in the area of wireless and mobile communications including ad hoc and sensor networks, routing and MAC protocol design and evaluation, directional antenna systems, multicast, TCP over wireless, and short-range radio communication such as Bluetooth. He has pending patents involving Bluetooth and IEEE 802.11, and has delivered tutorials in areas such as wireless broadband and mobile ad hoc and sensor networks. He has prior work experience with IBM in San Jose, CA, and is an IEEE member. E-mail:
[email protected] Sachin Abhyankar has concluded B.S. and M.S. in computer science. He worked as a software engineer for couple of years before joining the M.S. program at the University of Cincinnati, where he worked as a research assistant in the Center for Distributed and Mobile Computing in the area of wireless ad hoc networks. He has published various papers related with wireless networks in magazines and conferences. Presently, he is working as a software developer for Qualcomm. E-mail:
[email protected]
Rishi Toshniwal has concluded B.S. and M.S. in computer science. He worked as a software engineer for couple of years before joining the M.S. program at the University of Cincinnati, where he worked as a research assistant in the Center for Distributed and Mobile Computing in the area of wireless ad hoc networks. Besides his thesis on “Dynamic configuration and load balancing in Bluetooth personal area networks”, he has published various papers related with wireless networks in magazines and conferences. Presently, he is working as a software developer in Epic Systems Corporation in Madison. E-mail:
[email protected] Dharma P. Agrawal is the Ohio Board of Regents Distinguished Professor of computer science and computer engineering and the founding director of the Center for Distributed and Mobile Computing at the University of Cincinnati, OH. He has been a faculty member at the N.C. State University, Raleigh, NC (1982–1998) and the Wayne State University, Detroit (1977–1982). His current research interests include wireless and mobile networks, distributed processing, and scheduling techniques. He has authored a textbook Introduction to Wireless and Mobile Systems published by Brooks/Cole in August 2002. Dr. Agrawal is an editor for the Journal of Parallel and Distributed Systems and the International Journal of High Speed Computing. He has served as an editor of the IEEE Computer Magazine, and the IEEE Transactions on Computers. He has been the Program Chair and General Chair for numerous international conferences and meetings. He has received numerous certificates and awards from the IEEE Computer Society. He was selected for the “Third Millennium Medal” by the IEEE for his outstanding contributions. He is a fellow of the IEEE, the ACM, and the AAAS. E-mail:
[email protected]
