Personal Area Networks: Bluetooth or IEEE 802.11?nrlweb.cs.ucla.edu/publication/download/397/fulltext.pdfPersonal Area Networks: Bluetooth or IEEE 802.11? P. Johansson,1 R. Kapoor,1

1. INTRODUCTION

Networks of small handheld electronic devices willenable an environment where information may be ac-cessed, exchanged, and shared seamlessly among the de-vices in the network. Typically, such a network couldconsist of a cellular phone, a PDA, a notebook PC, a dig-ital camera, an mp3 player, a DVD player, etc., all ofwhich are devices that a person carries around in every-day life both for work and pleasure [8]. Often, this kind

of network is referred to as a personal area network(PAN). However, a PAN may, from time to time, alsoinclude devices that are not carried along with the user,e.g., an access point for Internet access or sensors locatedin a room. Moreover, devices from other users’ PANsmay also be interconnected to enable sharing of infor-mation, which could be anything from business cards tomultiplayer game interaction. Figure 1 depicts a PANuser who carries a laptop, a cellular phone, a PDA, anda digital camera.

In general, the nature of PANs implies a minimumof preconfiguration, i.e., it should be possible to establishthe network in an ad hoc fashion with minimum user in-tervention. In this context, Bluetooth has been tailored to

Personal Area Networks: Bluetooth or IEEE 802.11?

P. Johansson,1 R. Kapoor,1 M. Kazantzidis,1 and M. Gerla1

Interconnecting all our electronic devices we carry around, such as cellular phones, PDAs, and lap-tops, with wireless links requires a cheap, low-power radio technology that still delivers good per-formance. In this context, the Bluetooth wireless technology was developed to meet the require-ments introduced by these personal area networks(PANs). However, today we see a widespreaddeployment of wireless local area network (WLAN) radios (primarily IEEE 802.11b) also in smalldevices, such as PDAs. This paper will compare the PAN capabilities of a Bluetooth-based systemwith an IEEE 802.11b-based system. In order to focus the comparison on link and networking func-tionality, the IEEE 802.11b radio is assumed to be operating at the same power level as the Blue-tooth radio (i.e., assuming a 0 dBm radio). Results are obtained by means of simulations in whichthroughput and delay are measured for multihop and overlaid PANs. Estimations on power usageare also given in the simulations. The results indicate that as the number of PANs increases, theBluetooth-based PANs basically maintain the same bandwidth per PAN, while the correspondingIEEE 802.11-based PANs suffer significantly from the increased co-channel interference. However,for cases with a few co-channel-interfering PANs (2–3 PANs hosting about 10–15 nodes), the IEEE802.11b-based PANs offer a higher bandwidth per user than the corresponding Bluetooth PANs,which corresponds to the difference in link bandwidth between the two systems. At high interfer-ence levels, the Bluetooth PAN offers a higher capacity than the IEEE 802.11 PAN. The latter alsoshows unfairness among TCP connections in the PAN at high loads. The energy efficiency, definedas successfully transmitted bits per energy unit, decreases sharply for IEEE 802.11 with increasednumber of PANs, while Bluetooth maintains a constant level. Packet delays are also shown to bemore stable for the Bluetooth PAN than for the IEEE 802.11 PAN as the number of PANs increases.

KEY WORDS: Bluetooth; 802.11; PAN; scatternets; performance.

International Journal of Wireless Information Networks, Vol. 9, No. 2, April 2002 (© 2002)

891068-9605/02/0400-0089/0 © 2002 Plenum Publishing Corporation

1 University of California, Los Angeles, Computer Science Department,3803 Boelter Hall, Los Angeles, California 90095-1596. E-mail: {perj,rohitk, kazantz, gerla}@cs.ucla.edu

provide such functionality through its inherent ad hocdiscovery and connectivity capabilities. Also, it is likelythat most PAN devices will be battery driven, whichmakes efficient use of power an important issue. TheBluetooth piconet architecture enables the controllingmaster unit to apply a strict medium access controlthrough the use of a polling scheme. This gives a bettercontrol over power consumption and bandwidth usagecompared to a random access scheme, since slave unitstransmit only when scheduled by the master unit. Hence,the Bluetooth wireless technology provides functionsthat make it a natural choice for PAN connectivity.

However, in light of widespread use of wirelesslocal area network (WLAN) technology, such as IEEE802.11, also in smaller handheld devices, it becomes in-teresting to compare WLAN with Bluetooth as a tech-nology for PANs. The enhanced 11 Mbps version of thestandard, denoted IEEE 802.11b, is currently the mostwidely deployed standard for WLANs, and the study willfocus on this version. Typically, the topologies ofWLANs are based on network access points (APs) thatservice a number of mobile terminals (MTs)—for in-stance, notebook computers—within its coverage. Sev-eral APs may also be connected to a local area network(LAN, e.g., Ethernet) and can then service a larger areaby means of a handoff of MTs between the APs on theLAN. The IEEE 802.11 standard also specifies a peer-to-peer communication mode, i.e., an ad hoc mode, whichcan be used in most implementations available today.The ad hoc mode of the IEEE 802.11 standard has forseveral years been used as an experimental platform formobile ad hoc network (MANET) routing protocols,since it presents a fairly easy and cheap way to createmultihop packet radio networks [2].

Furthermore, the ad hoc mode provides the possi-bility of creating ad hoc PANs based on the IEEE 802.11standard, which is an application IEEE 802.11 was not

originally designed for but is the niche at which Blue-tooth is aiming. Note that though several small devicesare starting to be equipped with IEEE 802.11 interfaces,the main usage is still to connect to an AP to get networkaccess and not to create ad hoc PANs. It is the suitabil-ity for the latter that will be investigated in this paper.One key assumption made in this work is that the IEEE802.11b radio has its transmission power set to the samelevel as Bluetooth, i.e., 0 dBm, in order to give a faircomparison (13–20 dBm is the normal maximum outputpower). Since several implementations apply power con-trol, it is feasible to assume a low-power version of thesystem; e.g., the 802.11b MAC could possibly run on aBluetoothlike low-power radio. In this context it shouldbe pointed out that no such products have, to the authors’knowledge, been publicly announced at the time of thisstudy.

The low price claimed for a Bluetooth single-chipsolution (which aims at $5 for high volumes), comparedto the more expensive IEEE 802.11 multichip solutions,has been another motivation for using Bluetooth insmall, price-sensitive devices. However, the introductionof single-chip IEEE 802.11 CMOS solutions has beenannounced by several vendors, which will push down theprice for IEEE 802.11 solutions. Still, the more complexstructure of the 802.11 system is also expected to give amore expensive solution than Bluetooth in the future.The question is how far down the price can be pushed.Note that a difference of even a few dollars may be de-cisive for the choice of wireless technology for manylow-end, high-volume, and cheap devices, which favorsBluetooth for several high-volume markets.

The IEEE 802.11b system offers a raw link rate of11 Mbps (about 7 Mbps maximum user data rate), whileBluetooth offers a link rate of 1 Mbps per link (maxi-mum of 721 kbps user data rate). A claim that has beenmade in this context is that the Bluetooth piconet ap-proach gives a better channel efficiency than the randomaccess method used in IEEE 802.11b, if applied in an adhoc network environment. Issues related to this claimare, for instance

• At what traffic loads and node densities will the11 Mbps channel of IEEE 802.11b deliver a lowerrate than a corresponding case using the Blue-tooth 1 Mbps channels?

• How will the packet delays compare between thetwo systems?

• How will the power consumption change with theload in the two systems?

• How will the bandwidth fairness compare be-tween the systems?

90 Johansson, Kapoor, Kazantzidis, and Gerla

Fig. 1. Handheld and mobile devices interconnected in a PAN.

The work presented in this paper will address allthese issues in order to evaluate and make estimations ofthe circumstances where one system may be preferredover the other in an ad hoc PAN environment.

Related work in this context has, to the authors’knowledge, not focused on comparing the suitability forPANs. The issue of coexistence between Bluetooth andIEEE 802.11 has been studied in [4]. Moreover, the ar-chitecture and performance of Bluetooth PANs as suchhas also been analyzed in, for instance, [3].

The work presented herein is organized as follows.In Section 2, the protocols of both Bluetooth and IEEE802.11 are described to give a technical background forthe study. In Section 3, a discussion and a preliminarycomparison between the protocols is given in an ad hocPAN context. In Section 4, a simulation study of thePAN system candidates is presented and the results arediscussed. Finally, in Section 5 conclusions are drawnand an outline for further work is given.

2. PROTOCOL DESCRIPTIONS

2.1. Bluetooth

The Bluetooth wireless technology [1] is a low-power, low-cost, short-range RF technology that focuseson replacing cables between electronic devices. It uses afast frequency-hopping spread spectrum (FHSS) schemeand operates in the unlicensed Industrial Scientific-Medical (ISM) band at 2.4 GHz. Furthermore, the FHSSchannel is divided into time slots of 0.625 ms each thatdefine a time-division duplex channel (TDD), where onedownlink slot is immediately followed by an uplink slot.Several slots may be tied together in one direction to en-able longer data packets than can a single slot. The Blue-tooth network architecture is based on the piconet,a startopology, which is defined by two or more Bluetoothunits that share the same frequency-hopping channel.The gross data rate of the piconet channel is 1 Mbps, butwith overhead the maximum user rate becomes 721kbps. The central unit in a piconet (the master) may con-trol up to seven units (slaves). Any Bluetooth unit is ca-pable of becoming the master of a piconet.

Even though pure cable replacement with point-to-point radio links is perhaps the most obvious use forBluetooth, the capability of forming Bluetooth networksopens up a whole new arena for applications. In order tofurther enhance the networking capabilities of Bluetooth,piconets may be interconnected into scatternets,whichrequire some units to be present in two or more piconets.However, since a Bluetooth unit is expected to host onlyone radio transceiver, this presence needs to be handled

in a time-division manner, i.e., the interpiconet unit willswitch between the piconets. As the unit switches be-tween the piconets, it can act as slave in one or more butas master in at most one piconet. The interpiconet unitsmay also forward traffic between the piconets, i.e., oper-ate as gateways between piconets. Since the interpiconetunit cannot receive information from more than one pi-conet at a time, the need to coordinate the presence ofmasters and interpiconet devices in each piconet is nec-essary to achieve controlled performance.

Most of the published work on Bluetooth so far hasfocused on the single piconet and issues related to sched-uling of units within one piconet, e.g., [9,13]. Further-more, a thorough study of the Bluetooth link perform-ance for a case with several simultaneous overlaidpiconets is presented in [10]. This latter study clearly in-dicates the robustness of Bluetooth for dense network en-vironments. Some work has also looked at the task of ac-tual formation of Bluetooth piconets and scatternets, e.g.,[11,12,14].

2.1.1. Rendezvous Point Interpiconet Scheduling

An interpiconet unit (also named gatewayherein)negotiates a rendezvous point (RP) [3] with the master ofeach piconet it belongs to. An RP is essentially a pointin time where the master and the gateway will ren-dezvous; i.e., the master will poll the gateway and thegateway will listen in the master’s piconet. These RPsare repeated periodically with a time period referred toas a superframe,which is defined in number of Bluetoothslots. A gateway stays in a piconet from the time of itsRP with the master to its next RP with some other mas-ter. Thus, the RPs divide the time of the gateway be-tween more than one piconet.

In the algorithm used in this study, the RPs are as-signed so that they are as far from each other as possi-ble; i.e., the distance between the RPs is maximized,which is a very simple way to approximately divide thetime of the gateway equally between the piconets it be-longs to.

Consider a master node that wants to assign a newRP to a gateway. Suppose the gateway node belongs to iother piconets and has RPs r1, r2, . . . , ri with these pi-conets. The master node itself has j other gateways towhich it has assigned RPs ri11, ri12, . . . , ri1j. Note thatthese RPs repeat after every superframe. The master con-siders the ordered list of all the i 1 j RPs already estab-lished in both the master and gateway units and assignsa new RP that maximizes the distance with the previousones. Thus, the RP is chosen as the middle slot of thelargest interval between successive RPs.

Personal Area Networks: Bluetooth or IEEE 802.11? 91

2.2. IEEE 802.11

The IEEE 802.11 specification is a wireless LANstandard that specifies a wireless interface between aclient and a base station or access point, as well as be-tween wireless clients. IEEE 802.11 defines two physicalcharacteristics for radio-based wireless local area net-works: direct-sequence spread spectrum (DSSS) and fre-quency-hopping spread spectrum (FHSS), both of whichoperate on the 2.4 GHz ISM band. IEEE 802.11b defineshigh rate extensions up to 11 Mbps (raw link rate) for theDSSS channel and is the most commonly used standardtoday. In addition, IEEE 802.11b utilizes a dynamic rate-shifting functionality, allowing data rates to be automat-ically adjusted for noisy conditions. This means thatIEEE 802.11b devices will transmit at lower speeds—5.5Mbps, 2 Mbps, and 1 Mbps—depending on the signal-to-noise/ratio (SNR) at the receiver. When a device de-tects an improved SNR, the channel will automaticallyspeed up to the appropriate rate.

Recently, the Wireless Ethernet Compatibility Al-liance (WECA [6]) adopted the IEEE 802.11b specifica-tion to define the Wireless Fidelity (WiFi) standard forwireless LANs. WiFi enables access points and mobileterminals to interoperate across vendors.

Two network architecture modes have been definedin the IEEE 802.11 standard, namely, the point coordina-tion function (PCF) mode and the distributed coordina-tion function (DCF) mode. The former uses a centralizedapproach in which a network access point controls alltraffic in the network, including local traffic betweenwireless clients in the network. The DCF mode supportspeer-to-peer communication between wireless clients andis often referred to as the ad hoc mode. The media accesscontrol (MAC) layer uses the carrier sense multiple ac-cess with collision avoidance (CSMA/CA) algorithm. Aterminal operating in DCF mode that wants to send datalistens to make sure the channel is free and then waits fora randomly drawn period (backoff). If no other station at-tempts to gain access after this period of waiting, the ter-minal can gain access according to one of two modes:

• Four-way handshake: The sending node sends arequest-to-send (RTS) packet to the receiving ter-minal. If the receiver accepts the request, itreplies with a clear-to-send (CTS) packet. If nocollisions have occurred, the sender then beginstransmitting its data.

• The sender immediately begins sending its data.This mode is used when the data packet is short.

In either mode, the receiver responds with an ac-knowledgement (ACK) packet if the packet is success-

fully received. The CSMA/CA mechanism is also activefor the PCF mode. However, because the access pointhas higher priority than terminals, it has total control ofthe channel. The IEEE 802.11 standard does not specifya method for multihop ad hoc networking. However,MANET-based IP routing has been used in several ex-perimental networks.

3. COMPARISON OF LINK AND NETWORKLAYER PROPERTIES

Under the assumption that the two systems can usea radio with similar performance regarding power con-sumption, it remains to compare the link and networklayer characteristics of the two systems. The assumptionmade here with regard to power consumption is that thetransceivers use the same energy to send a packet over agiven time period, thus a higher link rate gives lower en-ergy spent per bit. The same assumption is made for re-ceiving a packet. In the following, the properties of thetwo systems are discussed and initially compared in anumber of areas identified as vital for ad hoc PANs.Some of these areas are further analyzed by means ofsimulation.

Perhaps the most fundamental difference betweenthe systems is that Bluetooth is connection orientedwhile IEEE 802.11 is connectionless. Note that this con-cerns the link layer behavior: Bluetooth is based on con-nections between the units (master and slave(s)) and aconnection has to be set up before any data can be sent;for IEEE 802.11, any unit can send to any other unit di-rectly as long as it is within range. This difference af-fects, to a large extent, in what situations one protocolwill perform better than the other.

3.1. Medium Access Control and Radio ChannelManagement

The media access control used in Bluetooth is basedon a central controlling unit, the master, which polls theslaves in the piconet. This enables a tight control of thecapacity in the network since no packet collisions canoccur between the nodes of the same piconet. It also en-ables a controlled allocation of resources via the masterthat could be used to provide QoS support and efficientpower control in the piconet. The division of the spec-trum into piconets, each using its own FHSS channel, isnecessary, since using an overall central controlling unitwould not scale for a case with many mobile ad hocnodes and a short-range radio. Instead, each piconet hasits own master and the piconets run independently of


each other. The FHSS channel-management approachused in Bluetooth divides the spectra into narrow chan-nels to avoid collisions between piconets (79 hoppingchannels). A larger number of channels is better foravoiding collisions but leads to a smaller capacity perchannel (smaller slices), since the overall ISM spectrumis fixed. In addition, the higher-layer data packets arefragmented into shorter packets so as to allow a highhopping rate between the channels. This gives betterdelay properties for the resulting data stream in the caseof collisions.

For the IEEE 802.11, the random-access-orientedmedia access control (CSMA/CA) is intended to enablea distributed control of the radio channel, i.e., no centralcontrolling entity. It provides flexibility, since data canbe exchanged between any pair of nodes within range.The random access enables nodes wider channels in thesame frequency band, since no central control that allnodes need to hear is necessary. For IEEE 802.11b, theISM band is divided into three nonoverlapping DSSSchannels.2 However, no mechanism to form overlaidPANs using different channels exists today, which wouldenable a better utilization of the ISM band. One way toachieve this could be to use one of the three channels todetect other nodes and then decide on another, perhapsless “crowded” channel to use for the PAN traffic. This,however, introduces a similar issue as in Bluetoothwhere a node needs to switch between channels, i.e., aninterchannel switching similar to the interpiconet switch-ing in Bluetooth scatternets. The packet length in 802.11is a normal Ethernet packet (maximum of about 1500bytes) but since no frequency hopping is applied tocounter interference, the packet is in general not seg-mented into smaller units.

3.1.1. Comparison

The fundamental difference in access control is oneof the factors that distinguish the traffic characteristics ofthe two systems. Which system performs better dependsboth on the type of traffic (and quality requirementsthereof) and the network topology. Bluetooth has a bet-ter potential to handle traffic with QoS requirements in atopology with several overlaid (interfering) PANs thanIEEE 802.11, based on the reasoning earlier. However,in cases when the traffic does not require QoS support orat low traffic loads, the inherent higher bit rate of IEEE802.11b would give a better capacity than Bluetooth. Apure overprovisioned link may serve a real-time applica-

tion well with a minimum of QoS functionality, e.g., apriority scheme. The problem is that overprovisioning isdifficult to assure in an ad hoc PAN environment. Fur-thermore, the dynamic rate shifting in IEEE 802.11b mayalso decrease the actual link rate if the number of PANsincreases. However, work to enhance IEEE 802.11 withfurther QoS functionality is underway within the IEEE802.11e working group [5].

3.2. Neighbor Discovery

It is essential to discover other units both within andoutside the PAN3 in an ad hoc fashion in order to allowa simple and user-friendly usage of the PAN devices. Inthis respect, Bluetooth uses its INQUIRY and PAGEprocedures that enable interconnection without a prioriknowledge about other units within range. The connec-tion phase may take between a few milliseconds (PAGE)or up to several seconds (INQURY 1 PAGE), depend-ing on whether the units are known to each other or not.If the units are known to each other, i.e., the BluetoothMAC address (the Bluetooth Device Address,BD_ADDR) is known, only the PAGE procedure is re-quired to connect. This case would typically occur fordevices belonging to the same PAN, while connection toexternal devices would typically require the longerINQUIRY process.

For IEEE 802.11, any unit within radio range can bedirectly addressed without setting up a connection; thus,known devices are simply “discovered” if they are withinreach. External devices could be passively discovered bya unit by simply listening to other units sending packetswithin its coverage area. However, in this respect IEEE802.11 has no defined way to actively discover units, i.e.,nothing similar to the INQUIRY procedure in Bluetooth.One feasible way to get the neighboring node addresseswould be to use a broadcast procedure, where every unitadvertises its MAC address in either a periodic fashionor through a broadcast request to neighbors to send theirMAC addresses. This discovery function may also beinitiated from a network layer routing protocol, as for in-stance in the case of the Ad hoc On demand DistanceVector (AODV) MANET routing protocol [17], wherenetwork layer “Hello” messages, containing the IP ad-dress of the sending unit, are broadcast periodically fromall units.


2 Up to 14 separate DSSS channels exist for 802.11b in the ISM band,but since a 25 Mhz channel spacing is used it gives three nonover-lapping DSSS channels.

3 The definition of which units belong to the PAN is kept rather loosein this study. Typically, it is a security-based definition: Devices“owned” by the user are in the PAN; others are “guests” in the PAN.For the sake of this study, there is no crucial difference between thetwo systems in this respect.

Note that if the PAN is assumed to be IP based, theAddress Resolution Protocol will be used to find theMAC address for IP addressed units for both Bluetoothand IEEE 802.11. In that context, knowledge aboutMAC addresses of neighboring nodes prior to invokingthe address resolution procedure may enhance the ad-dress resolution for IP.

3.2.1. Comparison

Bluetooth has the advantage of a standardized wayof obtaining the MAC address of new nodes in an ad hocfashion by using the INQUIRY procedure. In the case ofIEEE 802.11, such an initial discovery function needs tobe added to find the MAC addresses of neighbors that arein the vicinity. With respect to ad hoc discovery, Blue-tooth has an advantage over IEEE 802.11. However,once the MAC address of an IEEE 802.11 unit is found,packets may be sent directly to that unit using the ran-dom access CSMA/CA protocol. A Bluetooth nodeneeds to page (or be paged) and set up a connection toform a piconet before sending any packet. With respectto flexibility in sending to already discovered neigh-bors, IEEE 802.11 appears to have an advantage overBluetooth.

3.3. Multihop PANs

When two PAN nodes cannot reach each other di-rectly, packets need to be forwarded by one or more in-termediate units. This capability extends both the rangeand versatility of the PAN beyond a pure point-to-pointlink for cable replacement. With the introduction of mul-tihops, routing in the ad hoc PAN becomes an issue thatbelongs to the area of mobile ad hoc network routing,which has been dealt with in, for instance, the MANETWG in the IETF [2]. However, MANET deals mostlywith large-scale, military-type ad hoc networks, whilethe scope of the PAN will be rather limited and the rout-ing protocol could most likely be kept relatively simple.

Multihop in a Bluetooth PAN will, in the generalcase, involve scatternets, i.e., interconnected piconets,since multihop within one piconet is limited to only twohops: slave-master-slave. The properties of a multihoppath that goes across piconets and one that stays withina piconet may be quite different due to the interpiconetscheduling in the scatternet case. Each interpiconet nodeon the multihop path will introduce a delay that isstrongly correlated with the switching periods of the in-terpiconet scheduler. The shorter the periods are, theshorter the average delays will be, if packets are assumedto enter the interpiconet node at any time, but instead, the

overhead of switching piconets (frequency hop channel)will increase. Multihops within one piconet, on the otherhand, will most likely show smaller delays, since the in-trapiconet scheduler in the master node operates on thesame channel all the time. One exception to this wouldbe if one of the endpoints (slaves) were an interpiconetnode. In such a case, a slave may not be present when themaster tries to forward a packet from the originatingslave.

Multihop in an IEEE 802.11 network is ratherstraightforward since the nodes are peers, i.e., no under-lying topology of piconets and scatternets affects themultihop path. However, since all nodes use the samechannel, each additional hop that a packet makes adds tothe aggregate traffic on that channel. Nevertheless, it hasbeen shown, e.g., in [7], that a decreased power level,leading to multiple hops for a specific source-destinationpair, actually saves power and improves performancedue to the spatial reuse of the channel—the overall in-terference level is decreased in the same area.

3.3.1. Comparison

In cases where the distance is such that direct linkscan be used between the nodes in the PAN, an IEEE802.11-based system would tend to use these links. ForBluetooth, even if two slave nodes could be connecteddirectly, the piconet topology causes the packets to govia the master, which loads the piconet twice with thesame traffic. Direct Bluetooth links could, of course, beset up between any two nodes, i.e., a separate piconet perpair of nodes in the PAN. This would mean that nodeswould be taking part in many simultaneous piconets,which implies poor performance for the interpiconetnodes, since they need to switch between piconets. Thiswould only be an advantage if communication were con-centrated to one link (piconet) at a time—long enough tobring down the overhead of switching between the pi-conets. Thus, in the case where nodes in the PAN can bereached directly, IEEE 802.11 may have an advantageover Bluetooth due to its flexible, connectionless links.Again, however, as the number of simultaneous PANsincreases, Bluetooth’s piconet channel separation pro-tects against interference.

In cases where the distance between two nodes re-quires one intermediate node, the piconet architecturewith its central master unit will provide an efficient usageof the piconet capacity. Depending on the interferencesituation, IEEE 802.11 is typically less efficient in thiscase but may still give a higher resulting throughputsince it operates at a higher link rate than Bluetooth.However, if the number of simultaneous PANs is in-


creased, the simulations in this study show that the in-terference will cause IEEE 802.11 to share its singlechannel, while Bluetooth will have an almost linear in-crease of aggregated bandwidth as new PANs are addedto the “room.”

Finally, in cases where several multihop paths arerequired, the implications of paths over scatternets comeinto play for Bluetooth. For IEEE 802.11, the multihopad hoc network has been shown to be sensitive to hightraffic loads due to the uncoordinated random accessscheme. The simulations indicate that for the multihopcase, the throughput is actually comparable between thesystems, but IEEE 802.11 suffers from rather low energyefficiency.

3.4. Power Consumption

The design of the Bluetooth system is focused onproviding means for low power consumption. Thepolling approach used in the piconet gives the masterunit full control over the piconet capacity and avoidspacket collisions that waste capacity and power withinthe piconet. In addition, Bluetooth offers three power-saving modes: sniff, hold,and park modes. A slave insniff mode does not need to be present to receive apacket from the master at every slot in the TDD channel.Instead, sniff slots are defined at periodic time intervalsand the slave needs to be present at those slots. The timebetween the sniff slots can be used to save power in theslave unit. The hold mode applies a similar approach butinstead of periodic intervals between the polling slots, anew hold interval is set each time. In the park mode, theslave node goes in to the deepest level of “hibernation”and needs to be woken up by the master by means of aspecific unpark mechanism. When the slave is parked, itgives up its temporary 3-bit address and cannot be polledas a regular member of the piconet.

An IEEE 802.11 unit in ad hoc mode needs to beable to receive a packet from any node in the ad hoc net-work, which means that it needs to have its receiver ac-tive for long periods of time. However, once a pair ofunits has gained access to the channel, they announce thetime expected for their exchange of data. This means thatnodes that receive this information can choose to go intosleep mode for the duration of the packet exchange.

3.4.1. Comparison

Low power consumption is probably one of thestrongest arguments in favor of Bluetooth as opposed toIEEE 802.11 as the technology for PANs. The validity ofthis argument is investigated in the simulations that fol-

low, where the IEEE 802.11 transceivers are assumed tooperate at a low power (approximately 0 dBm) instead ofthe typical 13–20 dBm.

4. PAN SIMULATION ANALYSIS

Based on the discussions above, the question ofwhich system is best suited for PANs depends to a largeextent on the assumptions regarding traffic and the net-work scenario. The discussions do point out some areaswhere IEEE 802.11 could probably be improved to bet-ter serve a PAN, which is to be expected since it was notdesigned for such an application. In order to further clar-ify some of the issues addressed above, a set of PAN sce-narios is defined and then simulated using both Bluetoothand IEEE 802.11 models.

4.1. Simulation Model

The simulation environment used in the experi-ments is NS-2 [16]. NS-2 already includes several wire-less network models. In particular, it supports the IEEE802.11b standard (MAC and physical layers), which hasbeen used for simulating 802.11 in our experiments. Inaddition, a channel model is also part of the IEEE802.11b simulation model. For Bluetooth, a simulationmodel was added that has support for defining scatternetsand that models interference between piconets. Themodel contains most of the standard features of Blue-tooth, such as frequency hopping, multislot packets, andfast ARQ (Automatic Retransmission Query).

4.1.1. Bluetooth Channel Model

An important feature of the simulator is the channelmodel. Frequency hopping is modeled as a pure pseudo-random sequence. If two or more transmissions occur onthe same frequency, the SIR (Signal-to-InterferenceRatio) is evaluated using the gain factor g of each radiochannel. The factor g is considered constant during thepacket transmission, and its value is obtained by consid-ering the following factors:

• Path loss due to distance: d2h, where d is the dis-tance and h ranges between 2 and 4.

• Shadowing:lognormal random variable s5 100.1«,where « is a Gaussian variable with s standarddeviation.

• Fading: exponential random variable (Rayleighfading) with mean 5 1.


• At the receiver i, the SIR is evaluated as

where gij is the gain factor between transmitter j and re-ceiver i, Pt is the transmitted power, and Pn is the noisepower in the signal bandwidth. The receiver determinesthe bit error probability based on the SIR value, takinginto consideration the modulation adopted and the FECcoding (if adopted). The Bluetooth slave polling strategythat we have used is the one given in [9]. It tries to as-sign slots to slaves based on their traffic history andactivity.

The Bluetooth model supports scatternets by defin-ing gateways according to the interpiconet schedulingscheme described in subsection 2.1.1. In the simulationmodel, however, these gateway units are always slaves;masters do not become gateways.

4.1.2. Network Topologies

The network topologies were generated in a sepa-rate “scatternet generator” system that can form Blue-tooth scatternets with a control regarding the number ofmasters, slaves, and gateway (interpiconet) nodes, asshown in Fig. 2. The results of this generation are thenfed into the actual NS Bluetooth simulator in a parame-ter file (a tcl script file).

The inputs given to the scatternet generator are:

# of Piconets:Number of piconetsTopology Expand Factor:Determines how close the pi-

conets will be. Its use is explained below.MAX # of Piconets per Gateway:Maximum number of

piconets a gateway may belong to. The value wasset to 2 for the simulations herein.

SIR 5Pt ?gii

Pn 1 SPt ?gji

MAX # of Gateways per Piconet:Maximum number ofgateways a piconet may have. We choose the valueof this parameter as 7, which is the maximum num-ber of slaves.

Superframe Length in Slots:The length of the super-frame. The value was set to 100 slots for the simu-lations in this study.

The area of the topology produced is a square andits size is determined as in Eq. (1). As shown in the equa-tion, the Expand Factordetermines how spread out thepiconets will be. The value of Rangeis taken to be 10 m.terX refers to the length of the square terrain.

(1)

Once the area for the scatternet is defined, the mastersare uniformly distributed in the terrain. Each master hasa random number of slave nodes around it, distributedrandomly within the range of the master, forming a pi-conet. Some of the slaves may be within range of morethan one master; these are the potential gateways. Suchpotential gateways are then connected to one other mas-ter within range, with the following two limitations setfor this study:

• Each gateway belongs to a maximum of two pi-conets.

• Two piconets may have only one gateway be-tween them.

When the gateway nodes have been selected, ren-dezvous points (RPs) are calculated between gatewaysand masters according to the “maximum distance” algo-rithm described in subsection 2.1.1. Lastly, connections(TCP or voice) are established between nodes. Thelength of these connections may vary from 1 to 4 hops.

terX 5 2 # Piconets * ExpandFactor * 2 * Range


Fig. 2. Scatternet simulator and interface with NS Bluetooth/scatternet model.

Note that a hop in this context refers to a connectionpassing over a gateway. This means that a 1-hop con-nection is internal to a piconet, a 2-hop connection goesthrough one gateway, a 3-hop connection through 2gateways, and so on. The proportion of 1-, 2-, 3-, and 4-hop connections is also specified, where the number ofhops between two nodes is determined by the shortestpath between them.

For the simulations of the IEEE802.11b PAN sys-tem, the same node placement and connections are used,but without any notion of Bluetooth-specific nodes orfunctionality (masters, slaves, IPs, etc.). The dynamicrate shifting in IEEE 802.11 is not modeled in these sim-ulations, which are likely to overestimate the rate forIEEE 802.11 in dense network cases.

In the simulations, the routing protocol used isAODV. Each simulation is run for 32 s. For power con-sumption, we use the value from the Socket Communi-cations Bluetooth card [19], which has a transmit and re-ceive power consumption of 247 mW and a standbypower consumption of 4.6 mW (transmit current of 75mA, standby current of 1.4 mA, and an operating volt-age of 3.3 V).

4.2. Piconets

In this section, the performance of IEEE 802.11 iscompared with Bluetooth piconets. The piconets areoverlaid on top of one another but do not connect to forma scatternet; i.e., TCP connections must stay within a pi-conet. A 10 m-by-10 m area is considered in this exper-iment. In the case of Bluetooth, masters of piconets aregiven random positions. For each master, five slaves areplaced at random positions within a distance of 10 mfrom the master. For the IEEE 802.11 case, the sameplacement of nodes as the one for Bluetooth is used.Since the total area is 10 m by 10 m, all nodes can in-terfere with each other.

A greedy TCP connection is established betweeneach slave and its master for Bluetooth (and between thecorresponding units for IEEE 802.11), which starts at 0.2s and goes till the end of the simulation. Each simulationruns for 32 s, and the number of piconets in the topologyis increased from 1 to 5. Note that all figures are plottedwith the “number of Bluetooth piconets” as the x-axis.Although the notion of piconets does not apply to IEEE802.11, the “number of Bluetooth piconets” is used asthe metric since the same topology is used both for Blue-tooth and IEEE 802.11. Moreover, each piconet is as-sumed to correspond to a PAN in this study and, thus, thenumber of piconets is equal to the number of PANs.

Figure 3 shows the total and average throughputs ofall the TCP connections for Bluetooth and IEEE 802.11against the number of Bluetooth piconets. As the numberof piconets (number of nodes for IEEE 802.11) in-creases, Bluetooth adds capacity due to overlaid pi-conets. IEEE 802.11, on the other hand, sees a largernumber of collisions, since the number of TCP connec-tions increases with an increasing number of piconets.This supports the discussion on MAC and channel man-agement in subsection 3.1 very well. It was expected thatIEEE 802.11 would provide a very good performance atlow loads but that Bluetooth would handle dense net-work conditions better. The TCP performance of IEEE802.11 is better until five overlaid PANs (piconets),which is about 30 nodes (6 nodes per piconet).

However, the performance of each individual TCPconnection for the IEEE 802.11 turns out to be very dif-ferent, indicating an unfair distribution of the sharedbandwidth of the channel. In Fig. 4, the TCP throughputfor each flow in the case of five PANs is shown. In thecase of Bluetooth, each TCP connection gets a through-put of approximately 0.132 Mbps (indicated by thedashed line in Fig. 4). For IEEE 802.11, on the otherhand, there is an unfairness in distribution of bandwidthdue to an interaction between the TCP end-to-end flowcontrol mechanism and the MAC of the IEEE 802.11.The MAC will introduce a high variability of packet de-lays and also a loss of packets. This causes TCP to backoff and issue fewer packets to the MAC layer that ex-pects a persistent flow of packets in order to be fair. Theresult is that the TCP connections that do manage to getmore credits (larger congestion windows) will “capture”more of the capacity, while those TCP connections thathave smaller congestion windows will keep trying to ac-


Fig. 3. TCP throughput of PANs using IEEE 802.11 and Bluetoothpiconets. Note that no scatternets are used in this simulation.

cess the high-load channel with the few packets theirTCP congestion windows allow for. The result is a ran-domly unfair TCP performance for IEEE 802.11 in thedense ad hoc PAN environment.

Figure 5 shows the energy efficiencyof IEEE802.11 and Bluetooth against the number of piconets.The energy efficiency is defined as the number ofmegabits of user data transferred in the network, dividedby the total amount of energy (in joules) consumed by allnodes. We can see that Bluetooth becomes more energyefficient than IEEE 802.11 when the number of piconetsis greater than three. An interesting point to note here isthat the energy efficiency for Bluetooth nodes stays ap-proximately the same with increasing piconets, whereasthe energy efficiency of IEEE 802.11 nodes falls rapidly.

Moreover, for Bluetooth, the amount of energy con-sumed by slaves is, in general, much lower (about 1/5, inthese experiments) than that consumed by masters sincea slave may go to sleep if a packet is not intended for it.Thus, some nodes (masters) in Bluetooth consume moreenergy than others (slaves), whereas in IEEE 802.11, allnodes consume similar energy. From a practical point ofview, some units (laptops, etc.) in a PAN may have ahigher battery capacity compared to other, smaller units(headsets, mp3 players, etc.). Thus, the pattern of energyusage in Bluetooth may be considered more suited to thenonhomogenous units of a PAN.

4.3. Scatternets

In this section, the performance of IEEE 802.11 iscompared with Bluetooth scatternets in the PAN sce-nario. The Bluetooth scatternets are generated as ex-plained in Section 4.1.2.

4.3.1. All Nodes Within Range

An area of 10 m by 10 m is first considered, suchthat all nodes are within range of each other. Bluetoothscatternets are created, with the number of piconets vary-ing from 4 to 16, hosting a total number of greedy TCPconnections equal to twice the number of piconets. TheTCP connections are 1, 2, 3, or 4 hops in the ratio of0.4:0.3:0.2:0.1, respectively, where the number of hopsis as explained in Section 4.1.2. Note that in the four pi-conets case, the longest TCP connections were three-hop; i.e., there were no 4 hop connections. Moreover, theIEEE 802.11 can still use direct links and avoid multihopTCP connections.

Figure 6 shows the total and average throughputs ofall the TCP connections for Bluetooth and IEEE 802.11


Fig. 4. TCP throughputs of individual flows in the IEEE 802.11 casewith 5 PANs (solid), compared with the performance of the corre-sponding Bluetooth case (dashed).

Fig. 5. The energy efficiency for the IEEE 802.11 and BluetoothPANs. The Bluetooth PANs use piconets only, which means that TCPconnections stay within the piconets.

Fig. 6. TCP throughput of PANs using IEEE 802.11 and Bluetoothscatternets. All the nodes are within radio range of each other.

against the number of Bluetooth piconets. As can beseen, Bluetooth adds capacity as the number of piconetsincreases and does better than IEEE 802.11 when thenumber of piconets is more than 12. Note that thethroughput in this case would be very dependent on themix of 1-, 2-, 3-, and 4-hop connections. A rather largenumber of the TCP connections are expected to be be-tween master and slaves of the same piconet; hence, thepercentage of 1-hop connections has been chosen to be40%. These simulations indicate that the introduction ofscatternets, and thereby multihop TCP connections, willresult in less performance for Bluetooth compared toIEEE 802.11.

Figure 7 shows the energy efficiency of IEEE802.11 and Bluetooth against the number of piconets.Bluetooth is more energy efficient than IEEE 802.11when the number of piconets is more than 6. Since Blue-

tooth uses multihop connections to carry the traffic, moreenergy is used than in the pure piconet case.

The previous experiment was repeated with a mixof TCP and voice traffic. Again, the number of connec-tions is equal in number to twice the number of piconets.Out of these, 50% are greedy TCP and 50% are voiceconnections. The voice connections are modeled accord-ing to the Brady model [18]. In particular, the voice con-nections are “on-off” sources. The on and off times areexponentially distributed, with mean 1 s and 1.35 s, re-spectively. The voice-coding rate is 8 kbit/s and thepacketisation period is 20 ms, which gives a payload sizeof 20 bytes. Header compression is assumed for voicepackets in Bluetooth, and the total packet size is 30bytes. Voice packets are sent using RTP over UDP. Notethat the voice connections in the Bluetooth case use ACLlinks and that some connections pass through interpi-conet gateways, which add a rather significant delay.Typically, such connections would carry streaming audiorater than interactive voice.

Only the voice results are shown here since the TCPresults are very similar to the results presented earlier.Figures 8(a) and (b) show the cumulative distributionsfor voice delay in IEEE 802.11 and Bluetooth, respec-tively, for different numbers of Bluetooth piconets.When the network becomes dense (larger number ofBluetooth piconets), voice packets suffer larger delays inIEEE 802.11 compared to Bluetooth. In Bluetooth, onthe other hand, voice delays are largely unaffected by in-creasing network density. The controlled access to thechannel and polling in Bluetooth ensure low voice de-lays. These figures do not show the complete picture,though, since only voice packets that reach the destina-tion are represented. Some voice packets may bedropped due to queue overflow or retransmission limit


Fig. 7. The energy efficiency for the IEEE 802.11 and BluetoothPANs. The Bluetooth PANs use scatternets, which means that the TCPconnections may traverse several hops across the scatternet.

Fig. 8. Cumulative distribution for voice delay traffic in the PAN.

(as in IEEE 802.11). Table I shows the packet loss ratesfor voice for IEEE 802.11 and Bluetooth. The loss ratesare significantly higher in IEEE 802.11 than in Blue-tooth. When the network is very dense, IEEE 802.11tends to drop a high percentage of voice packets, whileBluetooth still delivers more than 80% of the packets.

4.3.2. All Nodes Not Within Range

In this set of experiments an area of 40 m by 40 mis considered such that all nodes are not within range ofeach other and radio multihops need to be used. Blue-tooth scatternets are created as described in subsection4.1.2, with the number of piconets varying from 12 to 20.The number of connections is equal to twice the numberof piconets. The type of connection is TCP or voice inthe ratio 1:1, and these connections traverse 1, 2, 3, or 4hops in the ratio 0.4:0.3:0.2:0.1, respectively.

Table II shows the total throughputs obtained byTCP connections for IEEE 802.11 and Bluetooth for dif-ferent numbers of piconets. As can be seen, the through-puts for IEEE 802.11 and Bluetooth are very similar. Itis interesting to note that IEEE 802.11 also adds capac-ity as the number of piconets increases. Since the area(40 m by 40 m) is larger than the assumed low-powerrange of IEEE 802.11, spatial reuse of the channel resultsin this increase. However, Fig. 9 shows that the energyefficiency of Bluetooth is clearly higher than that ofIEEE 802.11 in this environment. Thus, in spite of thescatternet scheduling overhead, the Bluetooth channelmanagement principles provide a more efficient way tocarry the information over multiple hops.

Table III shows the loss rates for voice for IEEE802.11 and Bluetooth. Since the loss rates are very high,no voice delay graphs are shown since these will not be

representative of actual voice behavior. Both Bluetoothand IEEE 802.11 have very high voice loss rates in thisscenario. Note that we have used the ACL link for voice inBluetooth; use of the SCO link may give different values.

Figure 10 shows the average throughput obtainedby TCP connections going over different numbers ofhops for the 20 piconet case, where a hop in a scatternetis as defined in subsection 4.1.2. In the case of IEEE802.11, these connections may not traverse as many hopsas in Bluetooth, since there is no underlying scatternetdictating which nodes have a link between them. Thus,in IEEE 802.11, two nodes can directly exchange data ifthey are within radio range, while this may not be truefor Bluetooth. As seen in Fig. 10, large-hop connectionsin Bluetooth get less throughput than in IEEE 802.11,while small-hop connections do better than in IEEE802.11. This is mainly due to the fact that connections inIEEE 802.11 may traverse a smaller number of hops thanin Bluetooth.

5. CONCLUSIONS AND FURTHER WORK

This study was motivated by the foreseen availabil-ity of IEEE 802.11 radios in small handheld devices suchas PDAs and potentially also in other typically low-power devices (game terminals, cameras, etc.). This de-


Table I. Packet Loss Rates for the Voice Traffic.

Piconets IEEE 802.11 Bluetooth

4 0 08 0.203984 0

12 0.392624 0.16706716 0.644025 0.1885

Table II. Throughput Values for the TCP Connections in theMultihop Scenario.

Piconets IEEE 802.11 Bluetooth

12 3.455 3.43216 4.07 4.47220 4.792 4.98

Fig. 9. The energy efficiency in the multihop case (40 m by 40 m) forBluetooth and IEEE 802.11 for a dense PAN scenario. Clearly, Blue-tooth provides the best energy efficiency.

Table III. Packet Losses for Voice for Bluetooth and IEEE 802.11in the Multihop PAN Scenario (Both systems show a significant loss

at high network densities.).

Number of Bluetooth Piconets IEEE 802.11 Bluetooth

12 0.305625 0.04302116 0.552902 0.4418320 0.568281 0.519875

velopment is primarily driven by the fact that these de-vices are capable of operating as IP hosts; i.e., they cantake part in an IEEE 802.11-based Internet access infra-structure. The deployment of the latter is currently a fast-growing trend in homes, offices, and also in publicplaces. Thus, Internet access is currently the driver toequip these devices with an IEEE 802.11 radio. How-ever, the IEEE 802.11 standard also enables the termi-nals to operate peer-to-peer in an ad hoc manner andcould potentially be used to create PANs and provideconnectivity between the handheld devices.

In the PAN context, Bluetooth is seen as the pre-ferred technology since it promises a lower price andpower consumption than IEEE 802.11. However, the re-cent product developments of IEEE 802.11 radio mod-ules (CMOS single-chip solutions) may decrease boththe price gap as well as the power consumption gap be-tween these technologies quite significantly. The issuethen becomes what impact other characteristics (apartfrom price and transceiver output power) have on thePAN performance, which was also the focus of thisstudy. Given that the IEEE 802.11 radio has comparablepower consumption to the Bluetooth radio, their differ-ences in MAC principles, spectrum management, andnetworking become decisive for PAN performance invarious environments.

The simulation experiments herein reveal that oneimportant property of Bluetooth lies in its ability to addcapacity as the number of units (piconets) increases.However, the higher link rate of IEEE 802.11 makes itan interesting alternative when the network is sparse(fewer nodes, low number of connections). This arisesfrom the difference in how the spectrum is managed.IEEE 802.11 uses a wider broadcast channel (22 MHz)and applies a random access scheme (CSMA/CA) thatworks well when few nodes compete for access. When

the traffic load increases, the resulting user capacity de-creases rather rapidly due to an increase in the number ofpacket collisions between nodes contending for access.Bluetooth, on the other hand, uses a rather narrow chan-nel of 1 Mhz per piconet and applies a FHSS scheme toavoid collisions. This gives an underutilized spectrum,i.e., low data rates, when the network has few activenodes but provides a very robust and predictable user ca-pacity as the network traffic and number of nodes in-creases.

The reasoning above also has a considerable impacton the power consumption in the two systems. The factthat the energy efficiency of Bluetooth remains the sameeven as the network becomes dense makes it more pre-dictable, as opposed to IEEE 802.11, whose energy effi-ciency falls rapidly due to the increased number ofpacket collisions, thereby wasting power. However, atlow traffic loads, IEEE 802.11 shows a better energy ef-ficiency than Bluetooth. In addition, the master unit ofBluetooth will in general consume more energy than theslaves due to its packet forwarding role within the pi-conet. Note that the study assumes the IEEE 802.11 radiois operating at the same power level as Bluetooth (0dBm), which may be a best case for the IEEE 802.11radio; a slightly higher power consumption may be ex-pected for the IEEE 802.11 radio.

When the overall, averaged throughput was compa-rable between the systems, an unfair capacity sharingcould be observed between the TCP connections in IEEE802.11 PANs. This arises from an interaction betweenthe MAC and the TCP flow-control mechanism in hightraffic load conditions, such as in a dense PAN. Blue-tooth will, under the same conditions, offer a very fairdistribution of the TCP capacity among the TCP con-nections. Thus, the robustness property of Bluetooth withrespect to network traffic load applies to TCP fairness aswell. Moreover, Bluetooth may be able to provide bettersupport for voice connections (QoS, etc.), though in asparse network, again, IEEE 802.11 is able to supportvoice due to its superior link rate. Also, PANs will, ingeneral, consist of dissimilar nodes with different batterycapacity. For example, a laptop may have a largeramount of energy than other, smaller units and the natureof Bluetooth’s energy consumption, in which one unit(the master) consumes more energy than other units, mayprove to be a better fit for a PAN.

An area that needs to be investigated further and in-troduced to the PAN analysis is the performance whennodes are mobile. Bluetooth’s Inquiry procedures maymake handoffs very time-consuming and may also causelong periods of network partitioning. IEEE 802.11, beingconnectionless, is not expected to have too much of drop


Fig. 10. Average TCP throughput as function of the number of hopsfor the same connection in the Bluetooth case. Note that the IEEE802.11 connections may pass fewer hops.

in performance in the face of mobility. This study alsoidentified some opportunities to improve the IEEE802.11 ad hoc functionality in order to mitigate some ofits deficiencies pointed out in the analysis. Moreover, thedynamic rate shifting with increasing channel errors inIEEE 802.11b is not modeled in the simulator. This func-tionality is expected to give IEEE 802.11 an even steeperdecline in the simulated throughput as the interference(number of PANs) increases.

Perhaps the most important contribution of thisstudy is the message that the choice of technology forPAN may not be obvious. It depends to a very large ex-tent on the expected network environment and applica-tions for PANs:

If PANs operates in very dense environments that havevery high interference and the applications require astable, sustained performance in terms of both delayand throughput, e.g., interactive services (voice,video), Bluetooth would be a good candidate. More-over, Bluetooth also gives a robust power con-sumption, which is almost independent of the inter-ference level—a battery will last the same amountof time in both a low as well as a high interferenceenvironment.

If PANs mostly operate in environments with a ratherlow node density or low interference levels and theapplications in the PAN require high peak rates in arather bursty manner, e.g., download-type serviceswith limited real-time requirements, the IEEE802.11 could be a good candidate. Moreover, if thedevices are mobile, the random access of IEEE802.11 makes it easier to find new neighboringnodes. In addition, devices of a PAN based on IEEE802.11 can directly access any IEEE 802.11-basedinfrastructure, using the same interface. However, itshould be pointed out that the power consumptionand link rate estimates versus number of interferingnodes presented in this study is most likely a “best-case” scenario for IEEE 802.11. More detailedmodels of IEEE 802.11 may give less favorable re-sults.

REFERENCES

1. Specification of the Bluetooth System - Core vol. 1 v1.1,www.bluetooth.com

2. Mobile Ad hoc Networks (MANET). URL: http://www.ietf.org/html.charters/manet-charter.html. (2001-10-11). (Work inProgress).

3. P. Johansson, M. Kazantzidis, R. Kapoor, and M. Gerla, Bluetooth:An enabler for personal area networking, IEEE Network,Vol. 15,No. 5, September 2001.

4. IEEE 802.15 Coexistence Task Group 2 (TG2) for Wireless Per-sonal Area Networkse. URL: http://www.ieee802.org/15/pub/TG2.html (2001-10-11). (Work in Progress).

5. IEEE 802.11e, MAC Enhancements for Quality of Service, URL:http://www.ieee802.org/11/ (2001-10-11). (Work in Progress).

6. Wireless Ethernet Compatibility Alliance, URL: http://www.weca.net/ (2001-10-11).

7. M. Frodigh, P. Johansson, and P. Larsson, Wireless ad hoc net-working—The art of networking without a network, Ericsson Re-view,No. 4, 2000.

8. J. C. Haartsen, Bluetooth: A new radio interface providing ubiqui-tous connectivity, IEEE VTC, 2000—Spring, pp. 107–111.

9. A. Capone, R. Kapoor, and M. Gerla, Efficient polling schemes forBluetooth picocells, ICC, 2001.

10. S. Zürbes, W. Stahl, K. Matheus, and J. Haartsen, Radio networkperformance of Bluetooth, Proceedings of International Confer-ence of Communications,New Orleans, June 2000.

11. T. Salonidis, P. Bhagwat, L. Tassiulas, and R. LaMaire, Distrib-uted topology construction of Bluetooth personal area networks,Proceedings of IEEE INFOCOM 2001,Anchorage, Alaska, USA,April 22–26, 2001.

12. S. Basagni, I. Chlamtac, and G. V. Záruba, Bluetrees—Scatternetformation and routing in Bluetooth-based ad hoc networks, Pro-ceedings of IEEE INFOCOM 2001,Anchorage, Alaska, USA,April 22–26, 2001.

13. A. Das, A. Ghose, A. Razdan, H. Saran, and R. Shorey, Enhanc-ing performance of asynchronous data traffic over the Bluetoothwireless ad-hoc network, Proceedings of IEEE INFOCOM 2001,Anchorage, Alaska, USA, April 22–26, 2001.

14. G. Miklós, A. Rácz, Z. Turányi, A. Valkó, and P. Johansson, Per-formance aspects of Bluetooth scatternet formation, Poster sessionMobihoc 2000,Boston, Massachusetts, August 11, 2000.

15. N. Johansson, U. Körner, and L. Tassiulas, A distributed schedul-ing algorithm for a Bluetooth scatternet, Seventeenth InternationalTeletraffic Congress, ITC’ 17,Salvador da Bahia, Brazil, Septem-ber 24–28, 2001.

16. Network simulator (NS-2), www-mash.cs.berkeley.edu/ns/17. C. Perkins and E. Royer, Ad-hoc on-demand distance vector rout-

ing, Mobile Computing Systems and Applications, 1999, Proceed-ings, WMCSA ’99,Second IEEE Workshop, 1999, pp. 90–100.

18. P. T. Brady, A model for generating on-off speech patterns in two-way conversation, Bell System Technical Journal,pp. 2445–2471,Sept. 1969.

19. Socket Communications Bluetooth Card specifications,http://www.socketcom.com/product/bluetoothcard.htm

Per Johansson([email protected]), Tekn. Lic., is asenior researcher of Ericsson Corporate Research, Stockholm, Sweden.He joined Ericsson in 1992 to work in the areas of traffic managementand performance analysis of ATM networks. He later moved into re-search on wireless systems, where his research has focused on ad hoc


networks and, in particular, on Bluetooth ad hoc networking. Since1998 he has managed a research team at Ericsson Research that focuseson IP networking aspects of Bluetooth. Currently, he is a visiting re-searcher at the Wireless Adaptive Mobility Lab at the University ofCalifornia, Los Angeles (UCLA), where he takes an active part in theBluetooth ad hoc networking research.

Manthos I. Kazantzidis ([email protected]) received hisdiploma degree in computer engineering and informatics in 1995 fromthe University of Patras, Greece. He received his M.S. in computer sci-ence in 1998 from the University of California, Los Angeles, and iscurrently a Ph.D. candidate at UCLA. His research focuses on adaptivemultimedia over networks with wireless and mobile links, and he is amember of the Wireless Adaptive Mobility Lab at UCLA.

Mario Gerla ([email protected]) is a professor in the ComputerScience Department at UCLA. He received his graduate degree in en-gineering from the Politecnico di Milano in 1966, and his M.S. andPh.D. degrees in engineering from UCLA in 1970 and 1973, respec-tively. He joined the faculty of the UCLA Computer Science Depart-ment in 1977. His current research is in the area of analysis, design,and control of communication networks. Ongoing projects include thedesign and evaluation of QoS routing and multicast algorithms for IPdomains, the design and evaluation of all-optical network topologiesand access protocols, the design of wireless mobile, multimedia net-works for mobile computing applications, and the development ofmeasurement methods and tools for evaluating the performance ofhigh-speed networks and applications.


Rohit Kapoor ([email protected]) received his B.E. in com-puter science in 1999 from the University of Roorkee, India. He is cur-rently a Ph.D. candidate at the University of California, Los Angeles(UCLA). His research focuses on performance issues in Bluetooth pi-conets and scatternets. He is a member of the Network Research Labat UCLA.

Documents

Personal Area Networks: Bluetooth or IEEE 802.11?nrlweb.cs.ucla.edu/publication/download/397/fulltext.pdfPersonal Area Networks: Bluetooth or IEEE 802.11? P. Johansson,1 R. Kapoor,1