BlueStar: Enabling Efficient Integration between Bluetooth WPANs and IEEE 802.11 WLANs
←
→
Page content transcription
If your browser does not render page correctly, please read the page content below
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 WLAN, empowering low-cost, short-range devices to access
the global Internet infrastructure through the use of WLAN-
Bluetooth [1,5] is a wireless communication technology that based high-powered transmitters. It is also possible that Blue-
provides short-range, semi-autonomous radio network con- tooth devices might access the WAN through a 3G cellular
nections, and offers the ability to establish ad hoc net- infrastructure like Universal Mobile Telecommunication Sys-
works [8], called piconets. It has also been chosen to serve tem (UMTS) and cdma2000 [3]. However, from the point of
as the baseline of the IEEE 802.15.1 standard for wireless view of cost and performance, it is advantageous for Blue-
personal area networks (WPANs) [3]. A WPAN is defined tooth devices to have access to the WAN through a WLAN
as the connection among personal devices, allowing informa- system where a WLAN infrastructure is readily available. In
tion exchange over short ranges. Eventually, this WPAN can these scenarios, Bluetooth (or WPAN) devices would only
be integrated with large wide area networks (WANs) to pro- make use of the cellular network infrastructure where WLAN
vide Internet connectivity in addition to access among these coverage is not provided.
devices. An important challenge in defining the BlueStar architec-
As previous studies have pointed out [7,11,13,23,34], it ture is that both Bluetooth and WLANs employ the same
is much likely that Bluetooth devices and IEEE 802.11 [19] 2.4 GHz ISM band and can possibly impact the perfor-
wireless local area networks (WLANs) stations (in this mance [1,7,12,17]. We refer to the interference generated
work we use the term WLAN and IEEE 802.11/802.11b in- by WLAN devices over the Bluetooth channel as persistent
terchangeably) operating in the 2.4 GHz ISM (industrial- interference [7], while the presence of multiple piconets in
scientific-medical) frequency band should be able to coexist the vicinity creates interference [7,9,11,23,34] referred to as
as well as cooperate with each other, and access each other’s intermittent interference [7,9].
resources. These technologies are complementary to each
To combat both of these interference sources and provide
other and such an integrated environment is envisioned that
effective coexistence, we propose to employ a unique hybrid
Bluetooth devices obtain information through the WLAN,
approach of adaptive frequency hopping (AFH) [14] and a
and ultimately the Internet. These cooperative requirements
new mechanism called Bluetooth carrier sense (BCS) in Blue-
have encouraged us to propose an intuitive architecture, called
Star. AFH seeks to mitigate persistent interference by scan-
BlueStar, whereby few selected Bluetooth devices, called
ning the channels during a monitoring period and labeling
Bluetooth wireless gateways (BWG), are also members of a
them as “good” or “bad”, based on whether the packet error
∗ Contact author. rate (PER) of the channel is below or above a given threshold.410 CORDEIRO ET AL.
BCS takes care of the intermittent interference by mandating 2. Bluetooth overview
that before any Bluetooth packet transmission, the transmitter
The details of the Bluetooth system, architecture and proto-
has to sense the channel to determine the presence of any on-
cols are defined in [5]. A brief overview is provided here
going activity. This channel sensing is performed during the
for completeness. Bluetooth is a short-range (up to 10 m)
turn around time of the current slot, and it does not require any
wireless technology aimed at replacing cables that connect
changes to the current Bluetooth slot structure. According to
phones, laptops, and other portable devices. Bluetooth op-
the IEEE 802.15 Coexistence Task Group 2 terminology [18],
erates in the ISM frequency band starting at 2.402 GHz and
BlueStar would be classified as a non-collaborative solution
ending at 2.483 GHz in USA and most European countries.
in the sense that the Bluetooth and the WLAN system operate
A total of 79 RF channels of 1 MHz width are defined, where
independently, with no exchange of information (as a matter
the raw data rate is 1 Mbit/s. A Time Division Multiplexing
of fact, this is required by the Federal Communications Com-
(TDD) technique divides the channel into 625 µs slots and,
mission regulations for the license-free bands). This lack of
with a 1 Mbit/s symbol rate, a slot can carry up to 625 bits.
information does not, however, have any impact on the per-
Transmission occurs in packets that occupy 1, 3 and 5 slots
formance of BlueStar. In fact we show that by employing the
as depicted in figure 1. Each packet is transmitted on a differ-
BlueStar architecture, we can approximately double the per-
ent hop frequency with a maximum frequency hopping rate
formance of the regular Bluetooth.
of 1600 hops/s.
Other studies [2,23] have proposed the use of Bluetooth ac-
Bluetooth operates on a Master-Slave concept wherein the
cess points (BAP), thereby making it totally dependent on a
Master periodically polls the Slave devices and only after re-
short-range fixed infrastructure. Our proposed BlueStar takes
ceiving such a poll is a Slave allowed to transmit. The Mas-
advantage of the widely available WLAN installed base as
ter for a particular set of connections is defined as the device
many organizations have spent hundreds of thousands of dol-
that initiated the connections. A Master device can directly
lars (including personnel training) building their WLAN in-
control up to seven active Slave devices in what is defined as
frastructure, and it is advantageous to use pre-existing WLAN
a piconet. Multiple piconets can be linked together through
infrastructure. This can easily support long-range, large-scale
common Bluetooth devices to form a scatternet.
mobility as well as provide uninterrupted access to Bluetooth
The Bluetooth specification defines two distinct types of
devices. The architecture of Bluetooth and WLAN enabled links for the support of voice and data applications, namely,
devices proposed here is an intuitive and practical solution SCO (synchronous connection-oriented) and ACL (asynchro-
to this ad hoc issue, and even though such an arrangement nous connectionless). The first link type supports point to
has been evaluated in [13], no mechanism or architecture has point voice switched circuits while the latter supports sym-
been used to mitigate interference between the Bluetooth and metric as well as asymmetric data transmission. This work
the WLAN. Here, we not only define an architecture and its mainly considers the use of ACL packets since they are in-
protocol stack, but also identify and propose two mechanisms tended to support data applications and do not have prescribed
(AFH and BCS) that enable effective and efficient coexistence time slot allocations as opposed to SCO packets. The ACL
of Bluetooth and WLAN within a single device. link allows the use of 1-, 3-, and 5-slot data packets (figure 1)
The industry has also been making efforts towards inte- with the optional use of FEC (forward error correction). DMx
grating Bluetooth and WLAN [25,27,28]. However, most (data medium-rate) packets provide a 2/3 FEC hamming code
recent solutions do not tackle the issue of simultaneous op- and DHx (data high-rate) packets carry no FEC coding at all,
eration of Bluetooth and WLANs, that is, either Bluetooth where x = 1, 3, or 5, depending on the number of slots it oc-
or WLANs – but not both – can access (i.e., be active) the cupies. Table 1 presents the possible ACL link packet types
wireless medium at a time, as only a single card is available. with their respective characteristics.
Moreover, this implies that additional integrated cards have
to be acquired. The architecture we propose here enables si-
multaneous operation by using existing WLAN hardware in-
frastructure, while relying on the availability of Bluetooth in-
terfaces.
The remainder of this paper is organized as follows. Sec-
tion 2 provides an introduction to the Bluetooth technology,
whereas section 3 elaborates on the proposed BlueStar ar- Figure 1. Packet transmission in Bluetooth.
chitecture, including a novel combination of AFH and BCS Table 1
Asynchronous connectionless (ACL) packet overview.
to handle both intermittent and persistent interferences, as
well as it presents the capacity allocation scheme employed Type User payload FEC Symmetric Asymmetric
(bytes) (Kbps) (Kbps)
in BlueStar. Next, section 4 discusses our simulation envi-
ronment. The performance of BlueStar in a Bluetooth-only DM1 0−17 Yes 108.0 108.8 108.8
DH1 0−27 No 172.8 172.8 172.8
scenario is then shown in section 5, while section 6 evaluates DM3 0−121 Yes 256.0 384.0 54.4
BlueStar in a combined IEEE 802.11 and Bluetooth environ- DH3 0−183 No 384.0 576.0 86.4
ment. Section 7 discusses placement issues of BWGs. Finally DM5 0−224 Yes 286.7 477.8 36.3
DH5 0−339 No 432.6 721.0 57.6
section 8 concludes this paper.BLUESTAR: ENABLING EFFICIENT INTEGRATION 411
3. The proposed BlueStar architecture ture is shown in figure 2(b), where the protocol stack is pre-
sented for each of its entities. As we can see, BlueStar reuses
The proposed architecture is expected to be capable of access- existing protocols wherever possible. Note that other opti-
ing networked information, especially through a WAN such mized protocol stacks have been proposed to serve specific
as the Internet. This allows dynamic content to be delivered applications [29], while the architecture we adopt does not
to the piconets and to the devices that may not otherwise have have such restriction. In order for Bluetooth devices to be
such WAN access, but can communicate with other Bluetooth directly addressed, we assume that every Bluetooth device
devices that do have access, either within the piconet or scat- possesses an IP address and any of the well-known routing
ternet. This would also enable network sharing among wire- algorithms [20,26] is available. Hence, we can conclude that
less and wired devices not only within the local network, but the BWGs may be better served by a layer (either software or
also across the WAN. We address this problem by a novel dedicated hardware) above the Bluetooth and WLAN radio
architecture called BlueStar to provide Bluetooth access to cards which is responsible, among other things, for receiving
the WAN and take advantage of the existing IEEE 802.11 packets and forwarding (including routing) them through the
WLANs. We call these selected devices – which possess both corresponding wireless system.
a WLAN interface and a Bluetooth interface – as Bluetooth A crucial challenge in the design of BlueStar is to enable
wireless gateways (BWGs). BlueStar allows piconets to be an efficient and concurrent operation of both Bluetooth and
formed around a portable device, such as a notebook or a per- WLANs as they both employ the same 2.4 GHz ISM band. To
sonal digital assistant (PDA), and have wide-area connectiv- combat the interference sources, BlueStar employs a unique
ity as well. Figure 2(a) illustrates the BlueStar architecture hybrid approach of an adaptive frequency hopping (AFH) and
with a scatternet, composed of total of four piconet, where the Bluetooth carrier sense (BCS). Below we describe how
each piconet has several slaves (indicated by the letter Si,j ) such schemes are implemented in BlueStar.
and one master (indicated by the letter Mi ). In this figure,
two BWGs provide the scatternet Bluetooth devices access 3.1. Bluetooth carrier sense (BCS)
to the local WLAN which, in turn, provides communication
to the local LAN, MAN, or WAN, and possibly the Internet. BlueStar employs carrier sense so that intermittent-like in-
BlueStar opens up new possibilities for the Bluetooth WPAN terference can be avoided. The current Bluetooth specifi-
technology, as it enables Bluetooth devices to communicate cation [5] does not have any provision for carrier sensing.
with virtually any other entity on the Internet. However, with increased receiver sensitivity and the wide-
The interaction between the Bluetooth network and the spread use of Bluetooth in unpredictable environments and
outside world is managed by the BWGs. Two possible new applications, it is quite likely that carrier sensing may
protocol stacks to carry IP packets over Bluetooth could have to be considered for inclusion in the Bluetooth specifi-
be employed within BWGs. The first option is to trans- cation. Moreover, carrier sensing is fundamental to any ef-
mit IP packets over point-to-point protocol (PPP) over ficient interference mitigation with other technologies using
RFCOMM [5], by taking advantage of the fact that PPP is the same ISM frequency band, and among Bluetooth piconets
already implemented in most mobile devices. However, such themselves. Contrary to IEEE 802.11, Bluetooth carrier
arrangement has been found to be highly inefficient given its sensing would be much simpler due to the nature of its MAC
redundancy [5]. Therefore, the Bluetooth SIG [5] has pub- protocol [9,11,22]. Therefore, in this work we assume that
lished a native way for carrying IP traffic over Bluetooth Bluetooth devices possess a sensing capability.
by a protocol called Bluetooth network encapsulation pro- We incorporate BCS into Bluetooth without any modifi-
tocol (BNEP) wherein IP packets are encapsulated in Eth- cations to the current slot structure. As stated in section 2,
ernet packets which are then carried over Bluetooth links. with a symbol rate of 1 Mbit/s a Bluetooth slot can carry up
In BlueStar we have opted for the latter and such architec- to 625 bits. However, to allow the Bluetooth transmitter and
(a) (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 Next, we analyze the nature of intermittent interference.
and make the frequency synthesizer tune to the next chan- As we have seen earlier, packet transmission in different pi-
nel frequency, a 259 µs turn around time is left at the end conets are asynchronous and are transmitted with period Tp ,
of the last slot. With current improvements in the Bluetooth which depends upon the Bluetooth packet type p. For in-
chip design [5] and the need for backward compatibility, the stance, if p is equal to DH1 or DM1 we have that Tp =
Bluetooth device in the near future will keep part of this turn 2 · slotsize, where slotsize is the size of a Bluetooth slot, and
around time unused as idle, hence enabling it to perform some is equal to 625 µsec. Figure 4 illustrates the timing of two
other useful tasks. This turn around period is illustrated in Bluetooth packets p and z generated at piconets i and j with
the figure 3 as well as our BCS proposal, where the dashed sizes Sp,i and Sz,j , respectively.
block denotes the sense window of size WBCS . Before starting The probability of packet collision between piconets i
packet transmission, the next channel is checked (i.e., sense) and j , pc (i, j ), is the probability of packet overlap both in
in the turn around time of the current slot. If the next channel time and frequency. Therefore, if we assume that any packet
is busy or becomes busy during the sense window, the sender collision incurs packet loss (strong interference) [7,9], we
simply withholds any attempt for packet transmission, skips have that:
the channel, and waits for the next chance. Otherwise, packet
pc (i, j ) = (Sp,i + Sz,j )/ max slotsperpacket(p),
transmission is carried out. A direct consequence of this ap-
1
proach is that, eventually, an ARQ (automatic retransmission slotsperpacket(z) + 1 · slotsize · , (1)
request) packet will be sent when the slot is clear and the C
communication is carried out. Algorithms to guarantee that where C is the number of available frequency channels and
devices withdrawing their transmissions in a previous polling is equal to 79 in most countries [5]. Moreover, the function
cycle will eventually have a fair share of time in the following slotsperpacket(X) gives the number of slots occupied by a
cycles are out of scope of this paper, while we have used an Bluetooth packet X, and max(p, q) returns the largest value
approach similar to [15] for our implementation (detailed in of two numbers p and q. We can extend this analysis by de-
section 4). riving the packet collision probability in a network comprisedBLUESTAR: 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 gregate throughput for Bluetooth with BCS becomes:
originated at the ith piconet is given by:
SBCS (X) = µ(X)N
N−1
p̄c (i) = 1 − 1 − pc (i, j ) . (2) ACKinbits(X) + sizeinbits(X) + 2WBCS 1 N−1
× 1− · .
(slotsperpacket(X) + 1) · slotsize C
Let us now derive the equations for BCS. For the ith pi- (5)
conet, the packet withdrawal probability is the probability
of sense window overlap with the packet from any other pi- Figure 5 depicts the packet collision and withdrawal proba-
conets. Therefore, the packet withdrawal probability of Blue- bilities for all three Bluetooth slot length packets as a function
tooth with BCS can be written as: of the number of piconets, and WBCS = 50 µs. Such an analy-
sis of a high number of piconets (up to 200) is crucial given
N−1 the new wave of applications of Bluetooth in wireless sen-
WBCS + Sz,j 1
p̄w (i) = 1− 1− · . sor networks [21,24,31] where thousands of sensors equipped
(slotsperpacket(z) + 1) · slotsize C
(3) with Bluetooth interfaces are to be employed, hence requiring
Aggregate throughput is another important performance hundreds of piconets to be formed and operate with minimum
measure when you consider a collection of piconets operat- interference amongst each other [9]. Thus, the analyses car-
ing in a proximity. In Bluetooth, data packets are followed ried out in this paper also have these sorts of scalable applica-
by an acknowledgement in the opposite direction from the re- tions in mind. As we can see from figure 5, even though both
cipient. Thus, we can obtain the aggregate throughput of N packet probabilities increase with the number of piconets, the
piconets relative to a Bluetooth packet X as given by: packet withdrawal probability increases at a slower rate, in-
dicating that a large fraction of packet collisions are being
S(X)=µ(X)N avoided with the adoption of BCS. Moreover, the rate of in-
crease is also distinct for different slot length packets.
2(ACKinbits(X) + sizeinbits(X)) 1 N−1 Figures 6(a) and 6(b) respectively illustrate the aggregate
× 1− · ,
(slotsperpacket(X) + 1) · slotsize C throughput for ordinary Bluetooth and Bluetooth with BCS
(4) for the same value of WBCS . A mere glance of these two
figures reveals that Bluetooth with BCS practically doubles
where ACKinbits(X) and sizeinbits(X) are the size in bits of the available throughput for most packet types. For instance,
the acknowledgement and data packet type X, with µ(X) using DH3 packets with ordinary Bluetooth, the maximum at-
being the nominal throughput of X (see table 1). The ac- tainable throughput with 60 piconets is of 8.03 Mbps, whereas
knowledgement information is included in the header of the Bluetooth with BCS achieves a bandwidth of up to 15.2 Mbps
return packet, and hence called piggy-backing. In our analy- with 110 piconets in the network. Thus, Bluetooth with BCS
sis, we consider the case where acknowledgements do not not only significantly increases the overall throughput but also
carry payload information, thereby making ACKinbits(X) in enables a larger number of nearby piconets to operate effi-
equation (4) always equal to 126 bits [5]. Similarly, the ag- ciently.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) as “good”. All devices within a piconet carry out this proce-
dure and when the piconet master request this, the slaves send
A careful observation reveals that some packet collisions are their measured “good” and “bad” channel marks. The master,
still not detected by BCS. Given that a IEEE 802.11 DATA in turn, conducts a referendum process based on information
frame has a maximum size of up to 2346 octets [19] and collected by itself and provided by the slaves. The final map-
a Bluetooth slot occupies 625 bits (with 366 bits of actual ping sequence is then determined and sent back to each slave
transmitted data), we conclude that, in the worst case, a IEEE device, which follow this new sequence thereafter. We have
802.11 DATA frame can overlap with up to 30 Bluetooth implemented this scheme by a bitmap comprising of 79 bits
slots (RTS-CTS-ACK are much smaller in size and hence do where a one indicates that a frequency can be used while a
not overlap with so many Bluetooth slots). Figure 7 shows zero indicates otherwise [14]. Note that devices conduct the
two potential cases of packet collisions. Although the IEEE AFH procedure periodically in order to account for the case
802.11 WLAN senses the channel before transmission, it can- where the piconet – or some piconet devices – may have left
not sense the Bluetooth activities [6], since the Bluetooth sig- WLAN radio coverage. The overall effect on Bluetooth is that
nal is narrowband and low power as compared to WLANs. the total number of available channels C decreases as some
Therefore, when the Bluetooth packet (from piconet i) is channels may be labeled as “bad”. The only impact on our
ahead of the WLAN, packet collision (with the next IEEE previous analytical model of section 3.1 is that the value of C
802.11 packet) takes place even after employing BCS. On the in equation (2) changes periodically with the re-evaluation of
other hand, when the WLAN packet is ahead of the Bluetooth the channels by the AFH mechanism, and will always be at
packet BCS successfully senses activity in the medium and most equal to 79.
withdraws packet transmission (see figure 7).
To cope up with this type of interference, called persistent 3.3. Capacity allocation scheme
interference, BlueStar employs AFH [14], which turns out to
be an effective method for handling persistent interference. The way BWGs multiplex their capacity has to be carefully
In our implementation of AFH, Bluetooth devices scan every coordinated. To do that, we employ a scheme where the time
T SCAN seconds for each of the 79 channels used by Blue- slice of a BWG in a system is proportional to the number of
tooth and collect PER statistics. If the PER is above a thresh- devices in that system (this scheme is an enhanced version of
old PERTHRES , it is labeled as “bad”; otherwise it is labeled the one presented in [15]). In the BlueStar architecture, theBLUESTAR: ENABLING EFFICIENT INTEGRATION 415
BWGs have to act as forwarding units between the wireless about two times larger than the transmission range [10,32].
systems besides serving as source or destination for their own More specifically, in our simulations we consider the trans-
applications. Thus, a BWG must spend a proportional amount mission range to be 10 m and the interfering range to be 22 m.
of time in receiving data as in forwarding it. Obviously, be- It may be noted that, from now on, we consider an IEEE
cause of mismatch in packet sizes and the eventual segmenta- 802.11b DSSS (Direct Sequence Spread Spectrum) running
tion and reassembly overheads, the time spent in one network at 11 Mbps for all our simulations and discussions. Also,
may not be exactly the time spent in the other. Since a BWG we have developed a hybrid Bluetooth-802.11 model that has
can be present only in one piconet at a time, the total capacity been incorporated into the BWGs.
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 5. Bluetooth-only simulation environment
of users in the scatternet.
For example, consider now a BWG of a piconet, say P1 , in Our initial experiment employs an environment comprised of
the network. If this BWG serves a fraction f of the slaves, only Bluetooth devices without any external sources of inter-
then it spends a fraction of time equal to the minimum of f ference. Therefore, since we are mainly concerned with inter-
and 0.5 in P1 . Thus, if f is greater than 0.5, the slaves served mittent interference and BCS, AFH is not employed. Figure 8
by the BWG gets less than their fair share. As explained ear- illustrates the topology used for this evaluation which is sim-
lier, the total time spent by the BWG in, say, two other pi- ilar to the one employed in [9]. Within a total area of 500 m
conets it belongs to should be equal to that spent in P1 . This × 500 m, we have considered a network composed initially
time is distributed between these two piconets in a fair man- of 10 piconets. For each of the twenty simulation runs, we
ner, depending upon the total number of users served by each increase the number of piconets by 10 up to a total of 200 pi-
of them, where the total number of users is the sum of the conets, where each piconet comprises of four devices. During
users in the piconet and those served by the other BWG in the each simulation, each piconet master establishes a CBR (con-
piconet. stant bit rate) connection with each of its slaves with a MTU
Therefore, the system divides its bandwidth amongst the (maximum transfer unit) of 512 bytes (thus, segmentation is
slaves as fairly as possible. In particular, if the number of performed into Bluetooth baseband packets), and the trans-
slaves in the piconets is distributed in a uniform manner (i.e., mission lasts for the entire simulation length of 300 seconds.
the number of slaves served by one BWG is not greater than Regarding the BCS implementation, we set the sense window
half of the total number of slaves), the system gives each slave size WBCS = 50 µs.
an equal amount of bandwidth towards the IEEE 802.11 net- Figure 9 depicts the packet collision and withdrawal prob-
work. If there is a change in the number of slaves in any abilities obtained through simulation and the ones obtained
piconet, the polling cycle and the capacity allocation are ad- analytically (section 3.1). As we can see, our simulation re-
justed as described. sults 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,
4. Simulation of BlueStar figures 10(a) and (b) present the aggregate throughput for
the scenario simulated corresponding to the ordinary Blue-
We have implemented all functionalities of BlueStar in the tooth and Bluetooth with BCS, respectively. As we had al-
network simulator (ns-2) [33] and BlueHoc [4], an open- ready estimated by our analytical model, Bluetooth with BCS
source Bluetooth simulator provided by IBM. Since BlueHoc practically doubles the maximum bandwidth achieved by
only provides the basic functionality of Bluetooth, we have the normal Bluetooth implementation. While the maximum
made considerable extensions to this simulator. In addition, throughput achieved by Bluetooth is of the order of 8 Mbps
we consider that the interfering range of Bluetooth devices is 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 network model for evaluating Bluetooth and 802.11 interfer-
see that not only BCS can drastically increase throughput but ence has been employed in [16]. In figure 11, the horizontal
also enable efficient support of a larger number of co-located plane depicts the Bluetooth plane with Bluetooth devices dis-
piconets. tributed 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
6. Combined Bluetooth and WLAN simulation of piconets in steps of 10 till 200 piconets. The number of de-
environment vices per piconet is uniformly chosen between 4 and 8, and we
In this section we carry out experiments with both intermit- have only considered Bluetooth DH5 packets. In figure 11, pi-
tent and persistent interferences. For that, we utilize the im- conet 1 holds the slave device S assuming the role of BWG,
plementations of both BCS and AFH. and located at the center of the Bluetooth plane, which is also
the intersection of the vertical WLAN axis, and the horizon-
6.1. TCP/IP traffic simulation tal Bluetooth plane axis. This particular piconet has a slave in
the logical origin of the plane and its master 5 m away from it.
We now discuss details of BlueStar simulations in a real sce- Contrary to the previous simulations, the application layer of
nario where TCP/IP applications are put into use. A similar the piconet devices consists of FTP sessions established be-BLUESTAR: ENABLING EFFICIENT INTEGRATION 417
tween masters and slaves using the same parameters. Within • Scenario D: This scenario models the opposite situation
piconet 1, the BWG is responsible for relaying FTP pack- as described in scenario C. In other words, it is the case
ets forwarded by the master M to the WLAN AP, which in where the BWG simultaneously transmits data packets to
turn possesses a sink agent to receive these packets and per- both the Bluetooth devices and the WLAN AP.
form measurements. In other words, the traffic between the
As for the WLAN axis, it is composed of an AP, located at
WLAN AP and Bluetooth network also consists of FTP traf-
(0, 200) m, which has a radio range of 250 m [19]. As em-
fic. For this study, we set the offered load in each piconet
ployed in other studies [13], the WLAN packet payload is set
to 30% of its total capacity, and assume Bluetooth stations to
to 11776 bits while the packet header is set to 224 bits, result-
be stationary as currently assumed by BlueHoc [4]. We have
ing in a total size of approximately 1.5 KByte. The analysis
selected and analyzed four possible scenarios as follows:
of the impact of the WLAN packet size on Bluetooth is out of
• Scenario A: The flow of data packets is from the WLAN scope of this paper (study of the performance of a WLAN net-
AP to the BWG, reflecting an application where Bluetooth work for different WLAN packet sizes can be found in [35]).
devices downloading contents from the WAN; For each simulation, we conducted a total of five 300 seconds
iterations, and these runs are averaged to give the final results.
• Scenario B: This scenario is the opposite of the previous
Table 2 shows the values used to configure the BlueStar sim-
one with the Bluetooth devices uploading information to
ulation, while table 3 summarizes the WLAN parameters.
the WAN, i.e., the flow of data packets is from the BWG
Figures 12–15 show two different views of the same simu-
to the WLAN AP;
lation for the four scenarios considered. While figures 12(a),
• Scenario C: A BWG might find itself in a situation where 13(a), 14(a), and 15(a) depict the average link through-
it simultaneously receives data packets from both the put achieved within piconet 1, figures 12(b), 13(b), 14(b),
WLAN AP and the Bluetooth devices in order to synchro- and 15(b) show its relative PER (packet error rate) for the
nize information in the BWG; same scenarios. In general, we can see that the PER increases
and the throughput decreases due to an increase in the inter-
ference level as more piconets are added.
As we can see from the figures, for the regular Blue-
tooth implementation, scenarios B and D experience a size-
Table 2
BlueStar simulation parameter setting.
WBCS 50 µs
PERTHRES 15%
TSCAN 20 s
Table 3
IEEE 802.11/WLAN simulation parameter setting.
CW_min 16
CW_max 1024
Packet header 224 bits
Payload size 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 PER as depicted in the respective figures 13(b) and 15(b). On
and C, with scenario B having the largest impact. This is par- the other hand, in scenarios A and C the BWG is sending
ticularly true in these scenarios because when the BWG is acknowledgments (ACKs) to the AP, therefore reducing the
transmitting data packets towards the AP, there is a high per- probability of packets being corrupted. The reason why sce-
sistent interference in the Bluetooth network causing a high nario 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 nario A the WLAN transmissions have been corrupting the
the Bluetooth data packets in scenario B, while in scenario D Bluetooth ACK packets, while in scenario C Bluetooth data
only Bluetooth ACK packets are susceptible to be corrupted packets are more impacted. Therefore, scenario A performs
by WLAN transmissions. Therefore, since the ACK packets slightly better due to the shorter and less frequent duration of
are small in size as compared to data packets, they are more the ACK packets.
likely to be successfully received during the off-cycle of the Moreover, it is also important to highlight the performance
WLAN transmission, resulting in the scenario B experiencing of AFH as it outperforms BCS under a small number of pi-
an extremely high PER as can be seen from figure 13(b). conets, since most of the interference is of persistent type.
Now let us analyze the behavior the AFH, BCS, and However, as the number of piconets increase, and hence the
BlueStar for the same scenarios B and D. Since these scenar- intermittent interference level, the performance of AFH de-
ios are more impacted by persistent interference, AFH is ef- grades and BCS becomes more efficient both in terms of PER
fective for a larger number of piconets until it reaches a point and throughput. More specifically, in scenarios B and D AFH
where the intermittent interference levels becomes significant. is more efficient than BCS up to 90 and 72 piconets respec-
At these points, BCS performs better by effectively mitigat- tively, whereas in scenarios A and C AFH performs better
ing intermittent interference sources. Also note that, despite when the number of piconets is approximately less than 55.
the high interference levels, BlueStar, employing both AFH In all scenarios, BlueStar achieves the best throughput and
and BCS, accomplishes enhanced performance by achieving the lowest PER by taking advantage of both AFH and BCS.
the highest throughput and lowest PER. As for scenarios A As a final experiment, we have selected scenarios C and
and C, AFH is now effective only for a smaller number of D and have collected the aggregate throughput for the entire
piconets as the larger impact comes from intermittent inter- Bluetooth network for the same simulation set up. The results
ference. Similarly, BlueStar obtains best results, although it are shown in figures 16(a) and (b). Similar to earlier results,
is slightly affected in scenarios B and D due to the high per- we observe a higher drop in throughput for scenario D, es-
sistent interference levels. pecially for the ordinary Bluetooth implementation. As ex-
Note that in scenarios A and C (especially in scenario A) pected, AFH outperforms BCS when most of the interference
the regular Bluetooth implementation shows performance is of persistent type, however degrades nearly at the same rate
sometimes comparable to that of the AFH scheme, which as the ordinary Bluetooth implementation when the number
is primarily due to the TCP congestion control mechanisms of piconets become larger than 50 and 65 for scenarios C
employed in the WLAN interface. When collisions in the and D, respectively. Likewise, BlueStar approximately dou-
WLAN traffic occur, the frame has to be completely retrans- bles the throughput achieved in Bluetooth by combining AFH
mitted as IEEE 802.11 WLANs do not employ any kind of and BCS.
FEC (forward error correction). Therefore, upon packet colli-
sion, the TCP timers expire, resulting in the congestion win-
dow being set to 1 MSS (maximum segment size) and the 7. Discussion on placement and number of BWGs
slow-start algorithm being executed. This situation effec-
tively allows Bluetooth devices to capture the channel and use In this section we discuss how many BWGs are needed to
them for its transmissions. At the time TCP reestablishes its provide adequate and uninterrupted coverage to all devices in
transmission rate, the Bluetooth devices would have already a Bluetooth scatternet, as well as where to place these BWGs.
performed its packet transmissions. This kind of situation has We refer to these as the placement and the number problems.
been more frequent in scenario A than in C because in sce- 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 architec- range covered by such antennas approximates a circle. The
ture such as BlueStar in its domain. For this discussion, we addition of another piconet to the scatternet of figure 17(a)
do not consider the case where devices in one piconet may could result in two distinct configurations as depicted in fig-
reach BWGs in other piconets by using some kind of multi- ures 17(b) and (c). While in figure 17(b) the addition of a
hop wireless routing protocol. Rather, we handle this problem piconet resulted in the addition of only one more BWG, the
by devising a model that gives us an upper bound on the num- same piconet might also result in the addition of two more
ber of BWGs that would be needed to efficiently provide full BWGs as shown in figure 17(c). In other words, the topology
coverage to the Bluetooth devices. In other words, we carry of interconnection has influence on the number of resulting
out a worst-case analysis. BWGs. However, since we are interested in an upper bound
We make few assumptions about the placement of a BWG (worst-case) on the number of BWGs, our task is simplified
within a piconet and the scatternet organization, as illustrated by considering only the topology which results in the highest
in figure 17. As a matter of simplicity, we propose a model interconnection, as exemplified in the sketch of figure 17(d).
whereby the BWGs serve as bridge node between exactly two In Bluetooth, it is possible to have all eight devices of a
neighboring piconets (as also assumed in [30]) and, there- piconet working as bridge nodes. For mathematical simplic-
fore, we place them along the border between two piconets ity, we impose a restriction that only the master device is not
as depicted in figure 17(a). Furthermore, we assume that pi- allowed to work as a BWG. Thus, among seven BWGs of a
conets have a circular shape and are centered on the master, piconet, each BWG is shared by two piconets. It is clear that
and that piconet devices are uniformly distributed around the we can have at most 7n/2 BWGs in a scatternet composed
border of the piconet. This is a realistic assumption as Blue- of n piconets. In fact, the total number of BWGs required
tooth devices possess omni directional antennas and the radio will be fewer than these as there is no need to have a BWG onBLUESTAR: ENABLING EFFICIENT INTEGRATION 421
non-bridge devices as shown in the outer parts of figures 17(c) 8. Conclusions and future work
and (d). We can formalize this fact by the following proposi-
tions that set the upper bound on the number of BWGs needed There has been very little work on how Bluetooth-enabled
throughout a scatternet. devices can have seamless and uninterrupted access to global
networks such as the Internet. This paper introduces a novel
Proposition 1. For a scatternet comprised of n (n > 0) pi- architecture called BlueStar, which employs a combination
conets, where piconets have a circular (or near-circular) shape of adaptive frequency hopping and Bluetooth carrier sensing
(see figure 17(b)), to efficiently provide advanced wide area services to Blue-
√ the number of BWGs needed is at most
7n/2 − 24 n − 4. tooth devices. BlueStar can take advantage of the existing in-
stalled base of IEEE 802.11 wireless networks by assigning
Proof. Suppose that the radius of each piconet is R (see fig- selected Bluetooth devices, called Bluetooth wireless gate-
ures 17(a) and (b)). Then, the total coverage of the n piconets ways (BWG), with IEEE 802.11 capabilities. These BWG are
is about n · πR 2 . Since the piconets are organized as a circle responsible for providing uninterrupted access to the WAN,
whose√radius R satisfies the equation πR 2 ≈ n · πR 2 , or such as the Internet, to the entire Bluetooth network (piconet
R ≈ n · R, the estimated number of boundary piconets is: or scatternet). BlueStar is observed to greatly outperform ex-
isting Bluetooth under different traffic conditions. The in-
πR 2 − π(R − 2R)2 √ corporation of BlueStar into Bluetooth is simple, does not
= 4 n−4 . (6)
πR 2 incur much overhead, and hence is an excellent enabler for
Since, according to our earlier assumption, each boundary co-existence and cooperation of Bluetooth and IEEE 802.11.
piconet has at least four non-bridge devices with other poten- Future work in BlueStar includes defining a more elabo-
tial piconets (see figure 17(d)), the number of bridge devices rate capacity allocation algorithm. In addition, we plan to
√ investigate the correlation amongst the various simulation pa-
is at most E = 7n − 44 n − 4. Therefore, the maximum
number of BWGs for a scatternet comprised of n circular (or rameters in order to assess their impact on BCS and AFH.
near-circular) shaped piconets is E/2 or: Mobility of both IEEE 802.11 and Bluetooth devices and its
impact on both systems are also part of our future research.
7n √
−2 4 n−4 . (7)
2
Acknowledgements
This work has been supported by the Ohio Board of Regents
Proposition 2. For a scatternet comprised of n (n > 0) pi- Doctoral Enhancement Funds and the National Science Foun-
√ the maximum number of BWGs needed is 7n/2 −
conets, dation under grant CCR-113361. We would like to thank the
24 n − 4. anonymous referees for their valuable comments and sugges-
tions.
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. References
According to the basic geometry theory, for a given coverage
area equal to that covered by n piconets, a circle will have the [1] D. Agrawal and Q.-A. Zeng, Introduction to Wireless and Mobile Sys-
shortest perimeter. This means a circle will have the fewest tems (Brooks/Cole, 2002).
[2] M. Albrecht, M. Frank, P. Martini, M. Schetelig, A. Vilavaara and
boundary piconets among all possible shapes. Therefore, the
A. Wenzel, IP services over Bluetooth: leading the way to a new mo-
upper bound on the number of BWGs (U BWG ) needed in a bility, in: LCN’99 (1999) pp. 2–11.
circular-shaped scatternet is also the upper bound on the num- [3] C. Bisdikian, An overview of the Bluetooth wireless technology, IEEE
ber of BWGs needed in any-shaped scatternet. From proposi- Comm. Magazine (December 2001) 86–94.
tion 1, we have that this upper bound is: [4] BlueHoc, IBM Bluetooth simulator, http://oss.software.
ibm.com/developerworks/opensource/bluehoc/.
7n √ [5] Bluetooth SIG, Bluetooth specification, http://www.
UBWG = −2 4 n−4 . bluetooth.com.
2
[6] R. Braley, I. Gifford and R. Heile, Wireless personal area network: an
Proposition 2 means that any other shaped scatternet topol- overview of the IEEE P802.16 working group, Mobile Computing and
ogy will require fewer BWGs as compared to the circular one. Comm. Review 4(1) (1999) 20–27.
[7] C. Cordeiro and D. Agrawal, Employing dynamic segmentation for
Therefore, through these last two propositions we have found effective co-located coexistence between Bluetooth and IEEE 802.11
a logical bound on the number of BWGs to be placed within WLANs, in: IEEE GLOBECOM, Taiwan (November 2002).
a scatternet. Of course, one possible configuration would be [8] C. Cordeiro and D. Agrawal, Mobile ad hoc networking (a tutorial),
to have each and every Bluetooth device with a WLAN inter- in: 20th Symposium on Computer Networks (May 2002) pp. 125–186,
face, but this is neither cost-effective nor practical. We have http://www.ececs.uc.edu/∼cordeicm/.
[9] C. Cordeiro, D. Agrawal and D. Sadok, Piconet interference modeling
shown by propositions 1 and 2 that we can do better while and performance evaluation of Bluetooth MAC protocol, IEEE Trans-
still providing full coverage to all Bluetooth devices. actions on Wireless Communications 2(6) (2003).422 CORDEIRO ET AL.
[10] C. Cordeiro, S. Das and D. Agrawal, COPAS: Dynamic contention- Carlos de Morais Cordeiro received his Ph.D. in
balancing to enhance the performance of TCP over multi-hop wireless computer science and engineering in 2004 from the
networks, in: IEEE IC3 N (October 2002). University of Cincinnati, OH, and his M.S. and B.Sc.
[11] C. Cordeiro, D. Sadok and D. Agrawal, Piconet interference modeling in computer science in 1998 and 2000, respectively,
and performance evaluation of Bluetooth MAC protocol, in: Proceed- from the Federal University of Pernambuco, Brazil.
ings of IEEE GLOBECOM, San Antonio, USA (2001). He is presently a research associate in the Center for
[12] M. Fainberg and D. Goodman, Analysis of the interference between Distributed and Mobile Computing at the University
IEEE 802.11b and Bluetooth systems, in: The IEEE VTC Fall 2001 of Cincinnati. His research interests and papers are
(October 2001). mostly in the area of wireless and mobile communi-
[13] D. Famolari, Link performance of an embedded Bluetooth personal cations including ad hoc and sensor networks, rout-
area network, in: Proceedings of ICC’01, Helsinki (June 2001). ing and MAC protocol design and evaluation, directional antenna systems,
[14] H. Gan and B. Treister, Adaptive frequency hopping implementation multicast, TCP over wireless, and short-range radio communication such as
proposals for IEEE 802.15.1/2 WPAN, IEEE 802.15-00/367r0 (2000). Bluetooth. He has pending patents involving Bluetooth and IEEE 802.11,
[15] M. Gerla, Y. Lee, R. Kapoor, T. Kwon and A. Zanella, UMTS-TDD: and has delivered tutorials in areas such as wireless broadband and mobile
A solution for Internetworking Bluetooth piconets in indoor environ- ad hoc and sensor networks. He has prior work experience with IBM in San
ments, in: Proceedings of ISCC (July 2002). Jose, CA, and is an IEEE member.
[16] N. Golmie, R.E. Dyck and A. Soltanian, Bluetooth and 802.11b in- E-mail: cordeicm@ececs.uc.edu
terference: simulation model and system result, IEEE 802.15/195r0
(2001).
[17] N. Golmie and F. Mouveaux, Interference in the 2.4 GHz ISM band: Sachin Abhyankar has concluded B.S. and M.S.
Impact on the Bluetooth access control performance, in: Proceedings in computer science. He worked as a software en-
of the IEEE ICC’01, Helsinki, Finland (June 2001). gineer for couple of years before joining the M.S.
[18] IEEE 802.15 Coexistence Task Group 2, http://www.ieee802. program at the University of Cincinnati, where he
org/15/pub/TG2.html. worked as a research assistant in the Center for Dis-
[19] IEEE Std. 802-11, IEEE standard for wireless LAN medium access tributed and Mobile Computing in the area of wire-
control (MAC) and physical layer (PHY) specification (June 1997). less ad hoc networks. He has published various
[20] D. Johnson, D. Maltz, Y.-C. Hu and J. Jetcheva, The dynamic source papers related with wireless networks in magazines
routing protocol for mobile ad hoc networks (DSR), IETF Internet- and conferences. Presently, he is working as a soft-
Draft, draft-ietf-manet-dsr-06.txt (November 2001) (work in progress). ware developer for Qualcomm.
[21] O. Kasten and M. Langheinrich, First experiences with Bluetooth in E-mail: sabhyank@ececs.uc.edu
the Smart–Its distributed sensor network, in: Proceedings of the Work-
shop on Ubiquitous Computing and Communications (PACT) (October
Rishi Toshniwal has concluded B.S. and M.S. in
2001).
computer science. He worked as a software en-
[22] Y. Kim, B. Zhen and K. Jang, Hybrid of listen-before-talk and adap-
gineer for couple of years before joining the M.S.
tive frequency hopping for coexistence of Bluetooth and IEEE 802.11
program at the University of Cincinnati, where he
WLAN, in: Proceedings of IEEE International Conference on Wireless
worked as a research assistant in the Center for
LANs and Home Networks (December 2001).
Distributed and Mobile Computing in the area of
[23] Y. Lim, J. Kim, S. Min and J. Ma, Performance evaluation of the
wireless ad hoc networks. Besides his thesis on “Dy-
Bluetooth-based public Internet access point, in: Proceedings of 15th
namic configuration and load balancing in Bluetooth
International Conference on Information Networking (2001).
personal area networks”, he has published various
[24] V. Mehta and M.E. Zarki, A Bluetooth based sensor network for civil
papers related with wireless networks in magazines
infrastructure health monitoring, Wireless Networks 10(4), Special Is- and conferences. Presently, he is working as a software developer in Epic
sue on Ad-Hoc Networking (2004) 401–412. Systems Corporation in Madison.
[25] Mobilian, Mobilian TrueRadio, http://www.mobilian.com. E-mail: rtoshniw@ececs.uc.edu
[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. Dharma P. Agrawal is the Ohio Board of Re-
[28] Red-M, Genos wirelessware, http://www.red-m.com. gents Distinguished Professor of computer science
[29] N. Rouhana and E. Horlait, BWIG: Bluetooth web Internet gateway, in: and computer engineering and the founding
Proceedings of ISCC (July 2002). director of the Center for Distributed and Mobile
[30] T. Salonidis, P. Bhagwat, L. Tassiulas and R. LaMaire, Distributed Computing at the University of Cincinnati, OH. He
topology construction of Bluetooth personal area networks, in: Pro- has been a faculty member at the N.C. State Uni-
ceedings of INFOCOM’2001 (April 2001). versity, Raleigh, NC (1982–1998) and the Wayne
[31] F. Siegemund and M. Rohs, Rendezvous layer protocols for Bluetooth- State University, Detroit (1977–1982). His current
enabled smart devices, in: Proceedings of the 1st International Confer- research interests include wireless and mobile net-
ence on Architecture of Computing Systems (April 2002). works, distributed processing, and scheduling tech-
[32] J. Sobrinho and A. Krishnakumar, Quality-of-service in ad hoc car- niques. He has authored a textbook Introduction to Wireless and Mobile Sys-
rier sense multiple access wireless networks, IEEE J-SAC 17(8) (1999) tems published by Brooks/Cole in August 2002. Dr. Agrawal is an editor for
1353–1368. the Journal of Parallel and Distributed Systems and the International Journal
[33] The network simulator (ns-2), http://www.isi.edu/nsnam/ of High Speed Computing. He has served as an editor of the IEEE Computer
ns/. Magazine, and the IEEE Transactions on Computers. He has been the Pro-
[34] S. Zurbes, W. Stahl, K. Matheus and J. Harrtsen, Radio network per- gram Chair and General Chair for numerous international conferences and
formance of Bluetooth, in: Proceedings of IEEE ICC’2000, Vol. 3, meetings. He has received numerous certificates and awards from the IEEE
pp. 1536–1567. Computer Society. He was selected for the “Third Millennium Medal” by the
[35] J. Zyren, Reliability of IEEE 802.11 Hi Rate DSSS WLANs in a high IEEE for his outstanding contributions. He is a fellow of the IEEE, the ACM,
density Bluetooth environment, White Paper, Harris Semiconductors and the AAAS.
(June 1999). E-mail: dpa@ececs.uc.eduYou can also read
