An enhanced and energy efficient communication architecture for ...

ADHOC 89

No. of Pages 22, DTD = 5.0.1

ARTICLE IN PRESS

16 August 2004; Disk Used

Ad Hoc Networks xxx (2004) xxx–xxx

An enhanced and energy efficient communication architecture for Bluetooth wireless PANs

2 3

Carlos de M. Cordeiro

4 5 6 7 8

a,*

, Sachin Abhyankar b, Dharma P. Agrawal

PR

TED

c

c

a Nokia Research Center, Tampere, Finland Qualcomm Incorporated, San Diego, CA, United States OBR Center for Distributed and Mobile Computing, Department of ECECS, University of Cincinnati, Cincinnati, OH, United States b

10 Abstract

EC

Bluetooth is a radio technology for Wireless Personal Area Networking (WPAN) operating in the 2.4 GHz ISM frequency band, and allows devices to be connected into short-range ad hoc networks. The Bluetooth medium access control protocol is based on the Master/Slave paradigm wherein any communication between slave devices has to go through the Master. While this model provides for simplicity, it incurs a longer delay between any two slave devices due to far from optimal packet forwarding, the use of double the bandwidth, and also additional energy wastage at the Master. Moreover, if more than two devices want to communicate as a group, this can only be achieved by either multiple unicast transmissions or a piconet-wide broadcast, clearly resulting in inefficiency. In this paper, we propose a novel Dynamic Slot Assignment (DSA) scheme whereby the Master device dynamically assigns slots to Slaves so as to allow them to communicate directly with each other without any Master intervention. This proposed communication architecture also provides for Quality of Service (QoS) requests, admission control, and multi-device conversation by which a multicast-like communication is implemented within a piconet. Through extensive simulation, we observe that DSA drastically enhances Bluetooth performance in terms of delay and throughput, while significantly reducing power consumption at the master and the overall piconet. 2004 Elsevier B.V. All rights reserved.

RR

11 12 13 14 15 16 17 18 19 20 21 22 23 24

OO F

www.elsevier.com/locate/adhoc

*

CO

25 Keywords: Bluetooth; Energy efficiency; Communication architecture; Performance evaluation 26

UN

Corresponding author. Address: Department of ECECS, University of Cincinnati, 2920 Scioto St. #406, Cincinnati, OH 45219, United States. Tel.: +513 556 3437. E-mail addresses: [email protected] (Carlos de M. Cordeiro), [email protected] (S. Abhyankar), [email protected] (D.P. Agrawal).

1. Introduction

27

Bluetooth [1,22,24] is a wireless communication technology that provides short-range, semi-autonomous radio network connections in the 2.4 GHz

28 29 30

1570-8705/$ - see front matter 2004 Elsevier B.V. All rights reserved. doi:10.1016/j.adhoc.2004.07.002

ADHOC 89 16 August 2004; Disk Used

RO

OF

By virtue of the Master/Slave communication model, the Bluetooth medium access provides for simplicity, low power (as compared to other standards), and low-cost, these being the major forces driving the usefulness of the technology. However, this design choice also brings in major shortcomings, such as the inability for slaves to communicate directly with each other since their packets must be forwarded through the master device [1,22,24]. Moreover, there is no built-in support in Bluetooth for applications which require group communication [17,27], while this can only be achieved by either multiple unicast packets or by a piconet-wide broadcast. As a result, packet forwarding among slaves in Bluetooth is sub-optimal, bandwidth is wasted by forwarding through the master, end-to-end packet delay increases, and power consumption is significantly increased at the master unit due to its frequent medium access for both transmission and reception. Therefore, the adoption of the Master/Slave paradigm in its present form does not seem to be the most adequate solution. To overcome these issues and address the shortcomings of the current Bluetooth Master/Slave communication model, we propose a novel Dynamic Slot Assignment (DSA) scheme to be coordinated by the master of a piconet [35,36]. Based on the piconet traffic patterns, the master device dynamically allocates slots for direct communication between slaves. This way, packets do not need to be forwarded by the master while it periodically re-evaluates slot assignments and changes it accordingly. This novel communication architecture enables for not only direct slave-to-slave communication but also serves as multi-slave communication, hence emulating a group (i.e., multicast-like) communication within the piconet. We have carried out extensive simulations of DSA and observe a drastic enhancement in current Bluetooth performance. In unicast scenarios, piconet throughput increases by up to 300%, delay is reduced to one-third, and overhead is halved, whereas in multicast-like communication throughput boosts up to 500%, delay decreases to approximately one-thirtieth, and overhead is merely oneseventh of existing Bluetooth implementations. Additionally, we have also shown that power con-

CO

RR E

CTE

Industrial-Scientific-Medical (ISM) band, and can establish ad hoc networks, called piconets. It has also been chosen to serve as the baseline of the IEEE 802.15.1 standard for Wireless Personal Area Networks (WPANs) [2], which can support both synchronous traffic such as voice, and asynchronous data communications. In Bluetooth, two or more devices using the same channel form a piconet, where one unit operates as a master and the others (at most seven active at a time) act as slaves. Bluetooth operates on a Master/ Slave concept wherein the Master periodically polls the Slave devices and only after receiving such a poll is a Slave allowed to transmit. A Master device can directly control up to seven active Slave devices in what is defined as a piconet, with the Master transmitting in even numbered slots and the Slaves in odd numbered slots. Multiple piconets can be linked together through bridge devices to form what is called a scatternet. So far, we can envision three waves of Bluetooth-based applications. Initially, Bluetooth was designed to enable a wide range of devices such as laptops, PDAs, mobile phones, and headsets, to form ad hoc networks in a semi-autonomous fashion [1]. The second wave of applications was the development of access points (with functionality similar to IEEE 802.11 access points) enabling hundreds of Bluetooth units to access the wired network in places such as theaters, stadiums, conferences, pavilions, and so on [28,29]. However, in the third wave of applications, the low cost, effortless and instant connection provided by Bluetooth technology has also become attractive for automatically forming an ad hoc network of a large number of low-power sensor nodes [30,31]. These sensor network applications are characterized by thousands of nodes embedded in the physical world, and a Bluetooth RF link to enable them to form a network by only bridging these sensor nodes within radio range [22,32,33]. These calls for solutions to be developed that are applicable to both small scale and large scale Bluetooth networks, while keeping interference at minimum levels [21,23] due to the large number of piconets. As we shall see, DSA satisfies such scalability requirements as opposed to existing solutions.

UN

31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77

Carlos de M. Cordeiro et al. / Ad Hoc Networks xxx (2004) xxx–xxx

DP

2


ARTICLE IN PRESS

78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125

ADHOC 89


ARTICLE IN PRESS



140 2. Bluetooth overview and motivation

RR

EC

TED

The details of the Bluetooth system, architecture and protocols are defined in [1]. A brief overview is provided here for completeness. Bluetooth is a short-range (up to 10 m) wireless link technology aimed at replacing cables that connect phones, laptops, PDAs, and other portable devices. Bluetooth operates in the ISM frequency band starting at 2.402 GHz and ending at 2.483 GHz in the USA and most European countries. A total of 79 RF channels of 1 MHz width are defined, where the raw data rate is 1 Mbit/s. A Time Division Duplex (TDD) technique divides the channel into 625 ls slots and, with a 1 Mbit/s symbol rate; a slot can carry up to 625 bits. Transmission occurs in packets, where DHx (without forward error correction) and DMx (with forward error correction) packets are usually employed for data traffic, while HVx packets are used for voice applications. Here, x represents the number of slots and can be equal to 1, 3 or 5.

CO

141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160

The Bluetooth specification [1] defines two different types of links for data and voice applications. The first link type Synchronous Connection Oriented (SCO) is treated as a circuit-switched, point-to-point traffic, whereas the second link type Asynchronous Connectionless Link (ACL) acts as a packet-switched, point-topoint data traffic. Usually, SCO links are used for audio applications with strict quality of service requirements where packets are transmitted at predefined regular intervals, while ACL links are often used in data applications where there is no such strict requirement on end-to-end delay. At most, three SCO connections can be supported within a piconet and the polling cycle varies when connections of such a type are present, ranging from 6 for HV3 packets to 3 for HV1 packets. Stating that SCO packets from a given connection have a polling cycle of 6 slots means that one SCO packet has to be sent in every 6 slots, so as to achieve the 64 Kbps bandwidth required for voice applications. On the other hand, ACL connections do not have such requirements and the polling cycle can be expanded or shrunk according to the number of slaves in a piconet and their traffic demands. For simplicity, we assume that every SCO connection uses HV3 packets which have a polling cycle of 6 slots, even though our scheme is applicable to any SCO packet type. Fig. 1 illustrates a full polling cycle highlighting the use of 1, 3 and 5-slot packets. Fig. 2 depicts a Bluetooth piconet comprised of five devices. Fig. 2(a) illustrates the case where the slave device S1 communicates with another slave S3, and all packets have to be forwarded through the master device M. Here, the packet forwarding between S1 and S3 is clearly sub-optimal, bandwidth is wasted by forwarding through the master

OO F

sumption at the master is dramatically reduced due to lesser number of transmissions/receptions, and in certain scenarios up to 80% reduction is achieved. The rest of this paper is organized as follows. Section 2 gives an overview of the Bluetooth technology and also provides the motivation for our work, while Section 3 describes our proposed Dynamic Slot Assignment scheme. Next, Sections 4 and 5 present the simulation methodology and results of extensive runs, along with comparisons of our scheme with existing Bluetooth. Related work is then given in Section 6. Finally, the paper is concluded in Section 7.

PR

126 127 128 129 130 131 132 133 134 135 136 137 138 139

3

Polling cycle 1

Polling cycle 2

625µsec ...

3-slot packet

...

5-slot packet

...

UN

1-slot packet

Fig. 1. Packet transmission in Bluetooth.

161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198



S4

S1

(a)

S2

M S4

S1 to S4

S3

(b)

S2

S3

Fig. 2. Master/Slave communication in Bluetooth: (a) forwarding is done through the master; (b) communication with more than one device.

RR E

225 3. The Dynamic Slot Assignment (DSA) scheme To address these major shortcomings in the Bluetooth design while keeping the simplicity of the Master/Slave paradigm, we propose a novel Dynamic Slot Assignment (DSA) scheme [35,36]. The basic idea behind DSA is to appropriately manage the polling cycle conducted by the master of the piconet. As devices initiate or terminate communication with each other within the piconet,

UN

226 227 228 229 230 231 232 233

234 235 236 237 238 239 240 241 242 243 244 245 246 247 248

3.1. Connection request, release and admission control

249 250

In order for the piconet master to optimally assign and reserve slots for piconet devices, it should know the Quality of Service (QoS) requirements for each connection. In DSA, whenever a slave device wishes to establish a connection with another device (whether another slave or the master itself), it sends a CONNECTION_REQ message to the piconet master, specifying in its payload: (i) the destination (if unicast) or destinations (if multicast) address to which the device wants to establish a connection; (ii) the baseband packet type to be used in its transmission; (iii) desired transmission rate; and (iv) acceptable transmission rate. For instance, when slave S1 in Fig. 2(a) wants to establish an FTP connection with slave S3, it could send a connection request to its master M, as CONNECTION_REQ(S3, DH5, 30, 50), while it would send a CONNECTION_REQ(S3, S4, DH5, 30, 50) for a multicast FTP connection to slaves S3 and S4. The transmission rate defines the frequency (in number of slots) a device desires to transmit. In our last example, slave S1 notifies the master that it desires to transmit one DH5 packet every 30 slots, but it can accept to transmit in every 50 slots if the desired transmission rate cannot be supported. When a connection request arrives at the master, it takes the requesting slave address (contained in the packet header), the packet type—which identifies the type of connection (voice or data) re-

251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279

CTE

M, end-to-end packet delay increases, and, as shown later, power consumption is significantly increased at the master unit due to its frequent medium access for both transmission and reception. Therefore, we believe that for existing wireless and mobile devices which possess limited battery power and for application efficiency, the Master/ Slave paradigm of Bluetooth should not be adopted in its current form. In case slave S1 wants to send packets (e.g., a business card) to both S3 and S4, it has to send two unicast packets as illustrated in Fig. 2(b). On top of that, these multi-slave packets may have to be kept in a deviceÕs buffer for as many polling cycles as is the number of recipients, since a device can only address one other unit in a given polling cycle. Note that a piconet-wide broadcast may be a feasible option, however as the master is the only device capable of sending a broadcast, packets will still have to be forwarded by it. Additionally, the trade-off between when to employ multiple unicasts or a broadcast is still unclear since slaves within a piconet are stateless. Hence, given the importance and wide applicability of multicasting, a basic support for group communication should also be provided.

CO

199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224

we restructure the piconet polling cycle (expanding it with a new connection or shrinking it upon termination), build the transmission schedule for each unit, and then propagate the resulting schedule to the members of the piconet. This way, slaves know exactly in which slot to transmit and/or to listen. Therefore, not only direct communication between slave devices is supported, but also a multicast-like communication is achieved by having destination slaves listen to the same slot. If we assume a uniform distribution of connection requests within a piconet, approximately 75% of all connections would constitute slave-to-slave communication [35], thereby stressing the need for supporting and optimizing such cases.

OF

to S3

RO

M

DP

4


ARTICLE IN PRESS

ADHOC 89


ARTICLE IN PRESS



328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351

3.2. Slot scheduling and assignment

352

Every time the master of a piconet receives either a connection request or termination, it computes a new schedule for devices. This schedule contains information about which slot(s) belong to which device, and in which slot(s) a given slave needs to listen. With this mechanism, devices are able to directly talk to each other in either a unicast or multicast-like communication. The schedule has to be transmitted to all the slave devices so that each one of them can determine when to transmit and when to listen. For that, we have defined a new broadcast message called SLOT_SCHED, which has a format depicted in Fig. 3 and is described in detail in Section 3.3. For simplicity, we assume that broadcast messages are reliable. Several approaches could be used to achieve reliability such as broadcasting the same message more than once or employing some sort of reliable broadcast. In our implementation, reliability is achieved by retransmission of the same broadcast message three times.

353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373

PR

OO F

nation of the communication between S1 and S3, the slave S1 would simply send a CONNECTION_REL(C1,3) to the master device M. The master M would free the slot allocated previously to this connection, calculate the new schedule for the remaining slaves and redistribute the new schedule within the piconet. Also, the master associates an idle timer (TIDLE) with each connection to handle the case when a device moves out of range or the connection is idle for too long. Upon expiration of TIDLE, the connection is terminated and its resources are freed up. Note that the master keeps track of all connections within the piconet in order to assign slots to the devices; however, it is not generally believed [21] that piconets, which are capable of having at most eight devices [1], will have a large number of connections. Given that, in our design, we assume that at most CONNTHRES = 16 connections can be simultaneously present in a piconet, which can be said to be a very reasonable number for most piconet applications. In the following section, we give details on how the slot scheduling and assignment is performed in DSA.

CO

RR

EC

TED

quested, the destination address contained in the payload, and the transmission rates. If the master can grant this request, it allocates a unique identifier to the connection, recalculates the appropriate schedule (detailed in the following subsection), and broadcasts the scheduling information to all active slaves. If the connection cannot be supported with this QoS level, the master returns a CONNECTION_REJ message back to the source. In our earlier example, having requested a DH5 packet does not guarantee that the slaveÕs request will be granted. As explained later, based on the current traffic and schedule, the master decides which packet is the best and propagates this information to all slaves with a broadcast. Also, we shall see that the traffic type influences the slot assignment, as SCO packets have to be scheduled periodically due to their time constraints, while no such restriction is present for ACL connections. An important issue arises in the case of bi-directional flows (e.g., TCP traffic) as slots have to be reserved for the reverse traffic. In this case, it is up to the destination (here, destination is a broadly defined term and can be a Bluetooth device, a TCP entity, or an application) to similarly make a slot reservation in the reverse direction through a CONNECTION_REQ message. However, as this message is sent in response to a bi-directional flow, it is handled differently by the master who immediately allocates the required slots specified within the request (e.g., DH3 for TCP ACKs) to be used in the reverse direction. If the master cannot satisfy this reverse connection request due to absence of enough resources, it returns a CONNECTION_REJ message back to the source and also drops the associated forward connection, along with its reserved slots, which generated this bidirectional flow. We note that this special TCP support is optional in DSA and has to be configured/requested by an external agent in order to become effective. Similar to connection requests, slaves also send connection termination messages to the master device. A slave transmits a CONNECTION_REL message, specifying the connection identifier as originally allocated by the master. Returning to the previous example of Fig. 2(a) where we assume C1,3 as being the connection identifier, upon termi-

UN

280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327

5


6


ARTICLE IN PRESS

Carlos de M. Cordeiro et al. / Ad Hoc Networks xxx (2004) xxx–xxx 3*(# Destinations) 3

Header

New Connection Info

SCO/ACL

# Destinations

Conn. # i

# Slots Assigned

# ACL Conn. 4

...

New Conn. Number

New and Existing ACL Connections Info

3

1

...

TxSlot 8

4*(# ACL Conn.)

Slot-Cycle 8

RO

Format:

Dest. i Add.

4

OF

Source Add.

2

Fig. 3. Scheduling message format (numbers expressed in bits).

CO

RR E

CTE

Fig. 3 illustrates the proposed format for the scheduling message employed by DSA, with the size of each field in bits as indicated. With this single message format, we can provide both unicast and multicast-like communication within a piconet. As we can see from Fig. 3, the scheduling message consists of three parts: the header, the information about the new connection request which caused the scheduling of this new message, and information about the slot assignment in the new and existing ACL connections. As we shall see, SCO connections are treated differently since they have a fixed scheduling. The header part of the message is composed of three fields. The first field indicates whether the connection request, that caused the transmission of this new scheduling broadcast, corresponds to either ACL or SCO connection. Alternatively, this field determines whether the information about the new connection contained in the second part of the message is related to an SCO or ACL connection. This makes a difference in the slot scheduling as ACL connections can be scheduled at any time, while SCO connections have to appear at every polling cycle, where a polling cycle is equal to 6 in Bluetooth (see Section 2). The second field of the header indicates the number of destinations addressed by this new connection request. In case of a slave-to-slave communication, this field would be equal to one, whereas it would be equal to the

UN

375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404

group size in a multi-device communication. If this broadcast message is the result of a connection termination, this field contains zero. The third and final field in the header indicates the number of ACL connections contained in the third part of the scheduling message (to be soon described). In other words, this field is used to determine the boundaries of the message. The second part of the scheduling message provides information about the connection request that has caused the generation of this scheduling broadcast, and absence of this part implies a connection termination. As mentioned earlier, both unicast and multicast-like communications are supported by this scheduling message. With this in mind, the first field indicates the source of data for the connection (i.e., the device which generated the connection request), followed by as many destination devices as specified in the number of destinations field contained in the header. Since each Bluetooth active member address is 3 bits [1], the size of this field is a multiple of 3. Next is the field which indicates how many slots have been allocated by the master for transmission by the source of the connection. Recall from Section 3.1 that together with the connection request message, the requesting device also specifies the type of packet it wishes to use in its transmissions. Depending upon the traffic pattern and the presence or absence of SCO connections, the master may or may not meet the deviceÕs request. For example, assume that a device S1 is currently engaged in a

DP

374 3.3. Slot scheduling message format

405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436

ADHOC 89


ARTICLE IN PRESS



OO F

mit and/or receive. Here, polling_cycle depends upon the SCO packet in use and is equal to 6 in case of HV3 packets, index_in_list is the index where the deviceÕs associated connection identifier appears in the first field of the third message part, and TxSlot is as described earlier.

To better illustrate the dynamics of DSA, consider again Fig. 2(a) where we have a piconet composed of 5 devices, one master M and four slaves labeled Si, for 0 < i < 5. For simplicity purposes, we do not include transmission rate in our discussion here, but note that QoS admission control is currently incorporated into DSA implementation, and consider unidirectional traffic only while bidirectional traffic is also presently supported by DSA. Assume that no traffic currently exists in the piconet, at which time slave S1 sends a connection request to the master M in order to establish an ACL connection with slave S2, specifying DH5 as the desired packet for its transmissions. Upon receipt of the connection request, the master M allocates a connection identifier, say C1,2, to the connection between S1 and S2 and calculates the scheduling message to be broadcast as follows. Initially, when there is no traffic, the slot cycle in the piconet is equal to 6 as polling is the only activity and is carried out by the master M. Fig. 4(a) illustrates this scenario, where slots are numbered from 1 to 6. Upon receipt of the aforementioned ACL connection request, the master M increases slot cycle by 6—making it 12—and assigns the first slot cycle for direct communication between the requesting device S1 and destination S2, while it always keeps the last slot cycle for polling (see Fig. 4(b)). Therefore, we see that the slot cycle is directly proportional to the number of ACL connections existing within a piconet, being always a multiple of 6. During the last slot cycle used by the master for standard polling, priority is given to those devices currently without open connections in order to achieve fairness, while those devices engaged in traffic connections are polled last. The master also has to indicate the source and destination slaves (S1 and S2 in our example) the

492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530

PR

491

EC

RR

CO

485 486 487 488 489 490

3.4. Example scenario

TED

SCO connection with device S2. In the mean time, another slave S3 requests to establish a connection with slave S4 for a file transfer by employing DH5 packets. It is well known that SCO connections are periodically scheduled in every polling cycle due to their strict QoS requirements. Since the Bluetooth slot cycle is equal to 6 and two out of these 6 slots are already being used for a SCO connection between S1 and S2, the master cannot satisfy slave S3Õs request to use DH5 packets, as only 4 slots out of 6 are available. Therefore, in this case, the master would respond with a value 3 in this field, thus indicating that slave S3 can use at most 3-slot packets. Finally, the last field of this message part is devoted to assigning a unique connection identifier to each connection within the piconet. The allocation of this identifier is managed by the master and communicated to the slaves in this broadcast message. This is the number that is used by the source slave when sending a connection release message to the master, and is also employed in the third part of the message scheduling. The third and last part of the scheduling message contains the information about the schedule itself, that is, when each device is supposed to transmit and/or receive. The first field(s) contains lists of all the connection identifiers currently present in the piconet, and the order in which a connection identifier appears in this field determines the order in which devices associated with this identifier (either as source or destinations) have their slots assigned. To indicate to the slaves the starting slot for transmission (in case of the source of a connection) or reception (in case of the destination(s)), we use the field called TxSlot (transmit slot). The values permitted for TxSlot are 1, 3, or 5, depending upon the type of packet a connection uses. Lastly, as we have already mentioned, in DSA we employ a scheme where we expand or shrink the slot-cycle according to the number of ACL connections in the piconet. Therefore, conveying the slot cycle information to all slaves is the objective of the last field, called Slot-Cycle, as shown in Fig. 3. This field is always a multiple of 6, as this value is the required periodicity of SCO connections. Based on that, a device determines the slot—slots = polling_cycle · index_ in_list) + Txslot—in which it is supposed to trans-

UN

437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484

7



CTE

DP

RO

OF

8


ARTICLE IN PRESS

Fig. 4. Dynamic assignment of slots and expanding slot cycle: (a) no traffic (base slot cycle); (b) one ACL connection (slot cycle expanded); (c) two ACL connections (slot cycle expanded); (d) two ACL connections and one SCO connection (SCO traffic is scheduled periodically).

CO

RR E

index within the assigned slot cycle where source (S1) is supposed to transmit and the destination (S2) is supposed to listen. This is accomplished by the field TxSlot where, in our example, the master M would set TxSlot to 1 as to allow slave S1 to use the entire slot cycle for the transmission of its DH5 packets. The scheduling message is then broadcast to all slaves. If, for instance, another ACL connection request to employ DH3 packets from slave S3 to S4, arrives at the master M, it proceeds in a similar manner, by assigning a connection identifier, say C3,4, increasing the slot cycle from 12 to 18 to accommodate the new connection, building the new schedule, and broadcasting it throughout the piconet. This new schedule is illustrated in Fig. 4(c). Assume now that a SCO connection request from device S1 to S3 arrives at the master M. Given the periodicity of SCO traffic which has to be present in each and every slot cycle, the master now

UN

531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550

has to reorganize the slot assignments. In our example, the connection C1,2 will no longer be allowed to use DH5 packets as this would prevent SCO packets from being sent during this slot cycle, while the connection C3,4 could continue employing the same packet type. To incorporate the SCO traffic within the schedule, the master changes the value of TxSlot from 1 to 3 indicating to all ACL connections that they will, from now on, transmit starting at slot 3, while the SCO connection is assigned the first two slots of every slot cycle. As a matter of fact, in DSA, SCO connections always use the first slots of a cycle while ACL connections follow next. Furthermore, note that contrary to ACL connections which have their polling cycle expanded according to the number of existing connections, the slot cycle of SCO connections is always 6, which means that SCO packets have to be transmitted in every slot cycle and hence need not be specified in the scheduling

551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570

ADHOC 89


ARTICLE IN PRESS



CO

RR

EC

TED

In this section we elaborate on some very important issues regarding DSA. We begin with the multicast address allocation, followed by multicast and scatternet support in DSA, overhead analysis, impact on existing Bluetooth architecture and, finally, the relation of DSA with the IEEE 802.15.3 standard. A very important issue to be discussed regards the multicast addressing in DSA given that every Bluetooth packet contains a single three bit active member address (AM_ADDR), where seven of these addresses are used by the slaves and the remaining one is employed for broadcast. In the design and implementation of DSA, we considered two options to tackle this problem: we could increase the AM_ADDR field in the Bluetooth packet from three to four bits and use one out of these four bit addresses for multicasting, or we could simply temporarily allocate one of the three bit addresses for this purpose. The first option would make DSA incompatible with current Bluetooth specifications. Therefore, we have selected the second option, where we temporarily allocate the broadcast address for the purpose of multicasting. However, note that by allocating the broadcast address for multicasting does not imply that all devices will receive such a packet since the packet is discarded once the device realizes it is not supposed to listen at that particular slot as specified in the slot scheduling message currently in effect. Hence, only the actual multicast members (specified in the slot scheduling message) will accept the corresponding packet. On the other hand if the packet is actually to be broadcast throughout the piconet, then the given slot carrying the broadcast packet will not be present in the slot scheduling message, resulting in all piconet devices accepting such packet. As explained in Section 3.1, connection request messages always arrive at the master and are not propagated to the destination. Implicitly, we assume that the destination device will always accept

UN

575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616

OO F

574 3.5. Comments and observations

new connection requests. This can be extended to include the destination in the connection request exchange. However since the master has information about all connections in the piconet, we opted to omit this additional transmission at the expense of the destinationÕs willingness to accept the connection. Also, note that when a device requests to employ DH1 or DH3 packets for a connection and no SCO traffic is present in the piconet, they will always be granted an entire slot cycle even if they do not make full use of it. In these cases, the master uses the free slots for polling, hence preventing wastage (see Fig. 4(c)). In the previous section, we have only provided a scenario where unicast communication takes place. However, note that multicast-like transmission does not require any more changes than to specify the entire list of destinations in the second part of the scheduling message format. In this case, all devices belonging to the list of destinations would record the slot cycle and TxSlot, resulting in all of them tuning to the same slots and hence receiving the same message. It is important to note that we have chosen a sender-initiated approach to support multicasting over Bluetooth, as it is optimal for small groups [18] where the sender has information about all the destinations. It contrasts with receiver-oriented approaches [17,27] where receivers initiate group membership, and are best applicable for medium-to-large groups. Also, while we have restricted our discussion to piconet multicasting, note that DSA could be used to support scatternet multicasting with some extensions. For that, we basically need to include the bridge node in the piconet multicast and have it convey the packets to its other associated piconets. In addition, we could synchronize slot assignments of neighboring piconets for enhanced performance. It is worth commenting on the overhead of our DSA scheme. In most cases, the scheduling message of Fig. 3 can be transmitted using a DH1 packet, that is, by using only one slot we can implement DSA over current Bluetooth and virtually eliminate its major shortcomings. We discuss this again in the performance evaluation section.

PR

571 message. This way, we adhere to the requirements 572 of the Bluetooth specification [1]. This new sched573 ule is illustrated in Fig. 4(d).

9

617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663


681 682 683 684 685 686 687 688

with the addition of a beacon period. In addition, contentionless access in 802.15.3 is provided by guaranteed time slots which can be of variable size. Clearly, all these and other features found in 802.15.3 are not present in Bluetooth. Therefore, we have developed DSA specifically to the existing Bluetooth technology, taking its design and slot structure into consideration.

689 3.6. Analysis of DSA and new piconet per 690 connection

CO

An alternative scheme to DSA is to create an individual piconet for every new connection [14,28], and hence seek to optimize aggregate throughput at the expense of increased interference. Here, we refer to this technique as New Piconet Per Connection (NPPC). To better understand the trade-offs of NPPC and DSA, it becomes inevitable to study the nature of inter-piconet interference [21,28], also referred to as intermittent interference [23], and compare the schemes with respect to this aspect. Numerical re-

UN

691 692 693 694 695 696 697 698 699 700 701

OF

S p;i þ S z;j 1 ; ðmaxðslotsperpacketðpÞ; slotsperpacketðzÞÞ þ 1Þ slotsize C

where C is the number of available frequency channels and is equal to 79 in most countries [1]. Moreover, the function slotsperpacket(X) gives the number of slots occupied by a Bluetooth packet X, and max(p, q) returns the largest value of two numbers p and q, or any of them if p = q. We can extend this analysis by deriving the packet collision probability in a network comprised of N piconets. The packet collision probability with a packet originated at the ith piconet is given by pc ðiÞ ¼ 1 ð1 pc ði; jÞÞN 1 :

702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718

ð1Þ

CTE

pc ði; jÞ ¼

sults, proof of correctness, and details of the analytical model presented here briefly can be found in [34]. In Bluetooth, packet transmissions in different piconets are asynchronous and are transmitted with period Tp, which depends upon the Bluetooth packet type p. For instance, if p is equal to DH1 or DM1 we have that Tp = 2* slotsize, where slotsize is the size of a Bluetooth slot, and is equal to 625 ls. The probability of packet collision pc(i, j) between any two piconets i and j is the probability of packet overlap both in time and frequency. Therefore, if we assume that any packet collision incurs packet loss (strong interference) [21], the packet collision probability between packets p and z of piconets i and j with sizes Sp,i and Sz,j, respectively, is given by

RO

We would also like to analyze the impact of the implementation of DSA within the current Bluetooth architecture. Basically, the changes would be confined to the Link Manager Protocol (LMP) and Baseband layers. At the LMP level, messages such as connection request, release, the slot scheduling, and timers would be incorporated. However, the functionally of DSA as to when to transmit/listen would be better placed at the Baseband layer. Finally, the IEEE 802.15.3 standard for WPANs also supports direct communication between devices. However, the design of 802.15.3 is considerably different from DSA. First, 802.15.3 devices possess clear channel assessment capability which enables a contention-based access period. Also, 802.15.3 is based in a superframe structure

RR E

664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680


DP

10


ARTICLE IN PRESS

719 720 721 722 723 724 725 726 727 728

ð2Þ

Aggregate throughput is another important performance measure when you consider a collection of piconets operating in proximity. In Bluetooth, data packets are followed by an acknowledgement in the opposite direction from the recipient. Thus, we can obtain the aggregate throughput of N piconets relative to a Bluetooth packet X as given by N 1 2ðACKinbitsðX ÞþsizeinbitsðX ÞÞ 1 SðX Þ ¼ lðX ÞN 1 ; ðslotsperpacketðX Þþ1Þslotsize C

ð3Þ

731 732 733 734 735 736 737

ADHOC 89


ARTICLE IN PRESS



1 1 slot 3 slot 5 slot

0.9

0.7 0.6 0.5 0.4 0.3

• As the number of piconets are increased so as to improve the aggregate throughput (Fig. 5(b)), the packet collision probability rises rapidly as depicted in Fig. 5(a). Thus a larger number of packets will have to be re-transmitted, incurring a higher delay and increased energy consumption due to frequent transmissions/receptions. This is not true for audio connections, where lost packets are not re-transmitted. Hence, the increase in the interference level will drastically affect the performance and quality of the connection. This can also impact TCP performance by continuously adjusting the congestion window due to packet drops for FTP-type of applications. Moreover, TCP may interpret packet loss due to interference as congestion and inadverdently apply its congestion control algorithms, hence negatively affecting throughput. • Usually, it is really difficult to know how many piconets exist in a scatternet, unless a rough estimate is extracted by measuring the interference. We plan to investigate this as a future research topic. • Creating a new piconet for every connection arrival might result in a condition where interpiconet communication has to be addressed and could possibly lead to dynamic and continuous joining/leaving of the nodes in the piconets. • Previous results [23] show that a considerable amount of time is wasted in switching from one piconet to another if a single node is involved in more than one traffic connection either as a source, a destination or both. That is, NPPC will eventually suffer from inter-piconet communication issues.

764 765 766 767 768 769 770 771 772 773 774 775 776 777 778 779 780 781 782 783 784 785 786 787 788 789 790 791 792 793 794 795 796 797 798 799 800 801 802

0.1 0 0

20

40

60

80

(a)

100

120

EC

0.2

140

160

180

200

Number of Piconets

RR

5000

DM1 DH1 DM3 DH3 DM5 DH5

4500 4000 3500 3000 2500 2000 1500 1000

UN

500

CO

Aggregate Useful Throughput (kbps)

755 756 757 758 759 760 761 762 763

TED

Packet Collision Probabilities

0.8

0 0

(b)

creases with the number of piconets, while the aggregate throughput increases only up to a certain number of piconets as shown in Fig. 5(b). Thus, an obvious enhancement to the basic NPPC scheme could be to keep on partitioning the piconet for every new connection until the point where an additional piconet will deteriorate the aggregate throughput. However, there are some problems with this solution:

OO F

where ACKinbits(X) and sizeinbits(X) are the size in bits of the Baseband acknowledgement and data packet type X, with l(X) being the nominal throughput of X [1]. The acknowledgement information is included in the header of the return packet, and hence called piggy-backing. In our analysis, we consider the common case where Baseband acknowledgements do not carry payload information, thereby making ACKinbits(X) in Eq. (3) always equal to 126 bits [1,34]. Fig. 5(a) depicts the packet collision probabilities for all the three slot sizes of Bluetooth packets as a function of the number of piconets. As we can see, the packet collision probability always in-

PR

741 742 743 744 745 746 747 748 749 750 751 752 753 754

20

40

60

80 100 120 140 Number of Piconets

160

180

200

Fig. 5. Packet collision probability and aggregate througput in Bluetooth: (a) packet collision probability; (b) aggregate throughput.

11


821 4. Simulation environment and methodology

846 847 848 849 850 851 852 853 854 855 856 857 858 859 860

To evaluate the flexibility of DSA, both slaveto-slave and multi-slave communications have been studied where we vary the number, packet type, and bandwidth requirement of each connection. In order to cover a broad range of scenarios, we have run our simulations with FTP, Telnet, and SCO (voice) traffic, where FTP and Telnet connections use DHx and DMx packets, respectively, while SCO traffic employs HV2 and HV3 packets. Each traffic connection is pair-wise distinct nodes, and we consider up to three connections of each type. To achieve reliability in the broadcast of the DSA scheduling message (Section 3.2) and at the same time determine an upper bound in the overhead of the DSA scheme, we perform the broadcast of a slot-scheduling message three times in all simulation runs. This number has been reached after extensive simulations under various traffic scenarios, where we have noted that three broadcasts suffice to cover up all piconet devices. Thus, we believe it to be a reasonable number of broadcasts to compare our DSA with existing Bluetooth, and to serve as a worst-case analysis.

861 862 863 864 865 866 867 868 869 870 871 872 873 874 875 876 877 878 879 880 881 882 883 884

5. Simulation results

885

Results for unicast communication and multicast-like communications are given separately.

886 887

RR E

CTE

To evaluate our proposed DSA scheme, we have implemented it in the Network Simulator (ns-2) [19] and BlueHoc [20], an open-source Bluetooth simulator provided by IBM. Since BlueHoc only provides the basic functionality of Bluetooth, we have made considerable extensions to this simulator in order to conduct our experiments including the support for direct slave-to-slave and multicast-like communication. The simulation experiments share the same network topology. It uses a single piconet comprised of eight devices placed randomly within a 7 m · 7 m region. Radio propagation range is taken as 10 m, and nominal channel capacity is set to 1 Mbps. We have thoroughly compared our DSA scheme with the existing Bluetooth under the following metrics:

CO

822 823 824 825 826 827 828 829 830 831 832 833 834 835 836 837 838 839

• Overhead—This measures the efficiency of the scheme. It relates the total number of data and control bytes sent to the total number of data bytes received by all devices. • Power consumption—With this metric, expressed in Megabytes/Joule (Mbytes/J), we evaluate the power efficiency of DSA as compared to Bluetooth. Bluetooth radios operate at 2.7 V and 30 mA, resulting in a 115 nJ/bit for transmission [1,25]. Moreover, measurements have shown [26] that receive:send ratio is usually 1:1.4, while power consumption in idle times is negligible. In our simulations, we have used these relations to compute power consumption for the Bluetooth devices.

OF

Therefore, in the design of DSA, we have decided not to create a new piconet for each connection, even when the number of piconets are within acceptable interference level. Our goal is not to always achieve the maximum possible aggregate throughput, but to keep interference at acceptable levels, effectively and efficiently support the three waves of Bluetooth-based applications (see Section 1) with their increased scalability requirements, and re-organize piconet scheduling so that application needs can be satisfied. Moreover, as we show in Section 5, the greedy throughput approach taken by NPPC is observed to drastically increase interference levels in medium to large network sizes, hence not being scalable. On the other hand, DSA is shown to effectively handle networks of varying sizes.

RO

803 804 805 806 807 808 809 810 811 812 813 814 815 816 817 818 819 820


DP

12


ARTICLE IN PRESS

UN

840 • Aggregate throughput—This is the average 841 number of data bytes correctly received by all 842 piconet devices per unit time. 843 • Delay—This measures the delay per bit in trans844 ferring data from a given source to a given 845 destination.

ADHOC 89


ARTICLE IN PRESS



13

Table 2 Scenario B connection pattern

889 890 891 892 893 894 895 896 897

Connection

CONNECTION_REQ

S1 M S3 S5 M S6

S1: (S3, HV3, 4, 6) S5: (S6, HV2, 4, 6)

Connection S1 M S4 S3 M S2 S5 M S6

tance as it contains a mix of SCO and ACL traf- 924 fic, hence requiring DSA to handle 925 heterogeneous traffic connections. 926

Connection

CONNECTION_REQ

S1 M S3 S0 M S4 S5 M S6

S1: (S3, DH5, 12, 18) S0: (S4, DH3, 6, 18) S5: (S6, DM1, 12, 18)

927

5.2. Aggregate throughput

928

Fig. 6(a)–(c) depict the aggregate throughput for DSA and existing Bluetooth for the scenarios under consideration. In general, we can observe that DSA always achieves higher throughput than existing Bluetooth. On an average, DSA experiences up to 300% improvement. The reason is simple: while in Bluetooth all traffic has to go through the master, path becomes non-optimal and bandwidth is wasted, hence compromising the number of data bytes received per unit time. On the other hand, DSA employs direct slave-to-slave communication, thus avoiding additional delay due to packet transmission, propagation time, and queuing, and hence boosting the number of data packets received per unit time. In Fig. 6(a), we see that with one FTP connection Bluetooth can still provide a performance comparable with that of DSA as the delay effects are minimized. However, when the number of connections increases to two and three, Bluetooth can no longer sustain the same performance whereas DSA scales approximately linearly.

929 930 931 932 933 934 935 936 937 938 939 940 941 942 943 944 945 946 947 948 949 950

EC

RR

CO

UN

Table 1 Scenario A connection pattern

CONNECTION_REQ S1: (S4, DH3, 18, 24) S3: (S2, DM3, 12, 18) S5: (S6, HV3, 4, 6)

TED

898 • Scenario A—In this scenario, a total of three 899 FTP connections are considered where each con900 nection is initiated consecutively in different 901 points in time. Table 1 depicts the connection 902 endpoints employed in this scenario, as well as 903 shows the various connection requests issues by 904 the slave devices. As we can see, each FTP con905 nection has a different packet type and demand 906 for bandwidth allocation, thus exercising the 907 flexibility of DSA with respect to ACL traffic; 908 • Scenario B—This scenario is devoted to analyze 909 voice traffic performance. It employs a total of 910 two SCO connections also initiating consecu911 tively at different points in time. Various con912 nection requests and their demands for this 913 scenario are illustrated in Table 2. With this sce914 nario we evaluate the flexibility of DSA with 915 respect to SCO traffic; 916 • Scenario C—This scenario considers a mixed 917 case of connections. Total of three connections 918 are initiated consecutively where the first one is 919 a SCO connection, the second one a Telnet, and 920 the third one an FTP. Table 3 describes the 921 characteristics of the various connections 922 employed in this scenario. Most importantly, 923 we note that this scenario is of major impor-

Table 3 Scenario C connection pattern

PR

In what follows, we study the behavior of our four selected metrics under three different traffic scenarios which could reflect various applications such as multi-party gaming where connections are not biased towards particular devices. We note, however, that even in scenarios where certain connections are more likely than others, we expect to see a considerable improvement with the use of DSA [35]. These scenarios considered here are:

OO F

888 5.1. Unicast communication


Carlos de M. Cordeiro et al. / Ad Hoc Networks xxx (2004) xxx–xxx x 106

12 FTP Connection III

8 6

FTP Connection II

1.6 1.4 1.2

SCO Connection I

0.8 0.6 0.4

2

0.2 0 50

100

150

200 250 Time (Sec)

300

10

x 10

350

400

(b)

With DSA Current Bluetooth

7 6 5

1 0 0

250

300

350

SCO

50

100

150

RR E

(c)

150 200 Time (Sec)

Telnet

FTP

2

100

CTE

Data Bytes Received (Bytes)

8

3

50

6

9

4

0

DP

0

SCO Connection II

1

4

0

(a)

FTP Connection I

6


1.8

14

10

x 10

OF


16 Data Bytes Received (Bytes)

2


18

RO

14


ARTICLE IN PRESS

200 250 Time (Sec)

300

350

400

Fig. 6. Aggregate throughput for the three scenarios considered: (a) scenario A; (b) scenario B; (c) scenario C.

951 5.3. Delay

CO

The delay experienced in each of the three scenarios are illustrated in Fig. 7(a)–(c) respectively. Due to the direct communication between slaves, and hence optimal communication path, DSA is shown to provide reduced delay in all scenarios, with delays being as low as one-third of the current delay in Bluetooth. Note that in scenarios A and C where we have traffic connections involving TCP, the delay increases as we increase the number of connections. This is due to the burstiness of TCP traffic which increases the average queue length in every burst.

UN

952 953 954 955 956 957 958 959 960 961 962 963

On the other hand, this is not the case in scenario B where only SCO connections are considered and the traffic pattern follows a constant bit rate (CBR) stream. Here, the delay for DSA is constant due to our direct slave-to-slave communication, while in Bluetooth the delay initially increases rapidly and then tends to stabilize. Note that in all scenarios, the delay experienced by the DSA scheme is dramatically lower than that of Bluetooth.

964 965 966 967 968 969 970 971 972 973

5.4. Overhead

974

Fig. 8(a)–(c) compare the overhead of Bluetooth and DSA for scenarios A, B, and C respec-

975 976

ADHOC 89


ARTICLE IN PRESS



1.2

x 10–3

1

15

x 10–3 Avg Delay With DSA Avg Delay Current Bluetooth

Avg Delay With DSA Avg Delay Current Bluetooth

1

FTP 3 FTP 1

0.8

FTP 2

0.6

0.6

0.4

OO F

Delay (Sec)

Delay (Sec)

0.8

SCO Connection II

0.4

SCO Connection I

0.2

0.2

0 0

50

100

150

200 250 Time (Sec)

2

x 10

300

350

400

(b)

0 0

50

100

150 200 Time (Sec)

250

300

350

PR

(a)

–3

Avg Delay With DSA Avg Delay Current Bluetooth Delay FTP with DSA Delay Telnet with DSA Delay SCO with DSA Delay FTP Current Bluetooth Delay Telnet Current Bluetooth Delay SCO Current Bluetooth

1.8 1.6

TED

Delay (Sec)

1.4 1.2 1 0.8 0.6 0.4

0

(c)

0

EC

0.2 50

100

150

200 250 Time (Sec)

300

350

400

CO

tively. Here, we see that although DSA transmits three broadcasts for each scheduling message, the associated overhead is always approximately half that of Bluetooth for the three scenarios considered. The reason for this is that BluetoothÕs overhead is present for every packet since all of them have to be forwarded by and routed through the master hence incurring an additional transmission. In DSA, the overhead is only tied to the broadcast message while all data packets are directly sent to the intended destination. In Fig. 8(b), we can see that the overhead of Bluetooth for scenario B remains nearly the same as in DSA while only one SCO connection is present in the piconet, whereas it increases rapidly

UN

977 978 979 980 981 982 983 984 985 986 987 988 989 990 991

RR

Fig. 7. Delay for the three scenarios considered: (a) scenario A; (b) scenario B; (c) scenario C.

when the second SCO connection arrives while DSA maintains a proportional grade of service. The reason being that the current Bluetooth can support at most three simplex SCO connections, that is, having the master as either a source or a destination of SCO traffic. Therefore, when it comes to duplex connections, that is, from slaveto-slave, Bluetooth can support only one SCO connection. With our DSA scheme employing direct slave-to-slave communication, we overcome this restriction by supporting up to three duplex SCO connections within a piconet. This is one major improvement due to our proposed DSA scheme. As a result, an additional SCO connection initiated in the piconet disturbs current traffic

992 993 994 995 996 997 998 999 1000 1001 1002 1003 1004 1005 1006


16


ARTICLE IN PRESS

Carlos de M. Cordeiro et al. / Ad Hoc Networks xxx (2004) xxx–xxx x 107

2.5

x 106



2 Total Bytes Sent (Bytes)

Total Bytes Sent (Bytes)

2

1.5 Slope ~2 FTP Connection I

1 FTP Connection III

0.5

1.5 Slope ~2 SCO Connection II

1

Slope ~1

0.5

Slope ~1 FTP Connection II

4

6 8 10 12 14 Data Bytes Received (Bytes)

9

18 x 106

0

(b)

0

0.2

x 106 With DSA Current Bluetooth

8 Total Bytes Sent (Bytes)

16

7 6 5 4

RO

2

0.4

0.6 0.8 1 1.2 1.4 1.6 Data Bytes Received (Bytes)

1.8

2 x 106

DP

0

SCO Connection II

CTE

0

(a)

OF

2.5

Slope ~2

3

Slope ~1

2 1 0

0

1

2 3 4 5 Data Bytes Received (Bytes)

RR E

(c)

6

7 x 106

Fig. 8. Overhead for the three scenarios considered: (a) scenario A; (b) scenario B; (c) scenario C.

1007 which incurs increased overhead in existing Blue1008 tooth, while it achieves a proportional overhead 1009 in DSA.

Fig. 9 shows the power consumption comparison of DSA and Bluetooth for the three scenarios under evaluation. We can clearly notice a drastic reduction in power consumption at the master device as a result of the proposed DSA scheme. As we can see from Fig. 9, the master does not get involved in the communication between slaves in DSA, resulting in a significant increase in the energy efficiency (Mbytes/J). Table 4 illustrates the

UN

1011 1012 1013 1014 1015 1016 1017 1018 1019

CO

1010 5.5. Power consumption

average power consumption improvement of DSA both at the master as well as in the slaves for the scenarios analyzed. As can be seen from Table 4, the average energy saved at the slaves is mainly due to reduction in the number of polls by the master device, as these slaves are involved in data communication. Hence, power consumption at the slaves is much less as compared to the master device where energy conservation is substantial as a result of DSA (see Table 4). Finally, it is important to note the energyper-byte improvement ratio of DSA over Bluetooth in Fig. 9. In other words, with the adoption of DSA, a significantly larger amount of data can be transmitted with the same energy. A direct con-

1020 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031 1032 1033 1034

ADHOC 89


ARTICLE IN PRESS



3 Each Slave DSA ~ 31 MBytes/Joule

2.5 2 Master ~ 4.5 MBytes/Joule Each Slave ~ 31 MBytes/Joule

1.5

Master with DSA All Slaves with DSA Master with current Bluetooth All Slaves with current Bluetooth

0.9

1

Power Consumption (Joules)

3.5 Power Consumption (Joules)

1

Master with DSA All Slaves with DSA Master with Current Bluetooth All Slaves with Current Bluetooth

0.8 0.7 0.6 0.5

Each Slave DSA ~ 16 MBytes/Joule

0.4 0.3

Master DSA ~ 8 MBytes/Joule

0.2 0.5

0.1 Master DSA ~ 35 MBytes/Joule

0

2

4

6

(a)

8 10 12 Data Received (Bytes)

14

16

18 x 106

0

2 Master with DSA All Slaves with DSA Master with current Bluetooth All Slaves with current Bluetooth

0.2

0.4

0.6

1.6

0.8 1 1.2 1.4 Data Received (Bytes)

1.6

1.8

2 6 x 10

Each Slave DSA ~ 25 MBytes/Joule

1.4 1.2

TED


1.8

0

(b)

PR

0

Master ~ 1.2 MBytes/Joule Each Slave ~ 8 MBytes/Joule

OO F

4

17

1


0.8 0.6 0.4

Master DSA ~ 35 MBytes/Joule

0.2

EC

0

0

1

2

(c)

3 4 5 Data Received (Bytes)

6

7 x 106

RR

Fig. 9. Power consumption comparison of DSA and Bluetooth: (a) scenario A; (b) scenario B; (c) scenario C.

Table 4 Energy improvement of DSA over Bluetooth

Slaves

83.06% 43.62% 54.36%

2.12% 8.95% 6.60%

CO

Scenario A Scenario B Scenario C

Master

UN

1035 sequence of this fact is that the piconet has its life1036 time drastically increased. 1037 5.6. Multicast communication 1038 In this section, we study the multicast support 1039 in DSA and compare it with the native way of

implementing group communication in Bluetooth by multiple unicasts. For this experiment, we consider two multicast sessions wherein each of the two multicast sources has exactly three other devices as group members. Here, the first multicast session is initiated at simulation startup, while the second is initiated 100 seconds later. Exponential traffic sources are considered.

1040 1041 1042 1043 1044 1045 1046 1047

5.7. Aggregate throughput

1048

Fig. 10 depicts the aggregate throughput of both DSA and Bluetooth. As expected, DSA greatly outperforms Bluetooth by employing a single transmission for all group members, while Bluetooth transmits a packet per destination. As

1049 1050 1051 1052 1053


Carlos de M. Cordeiro et al. / Ad Hoc Networks xxx (2004) xxx–xxx x 106 Muilticast With DSA Multiple Unicast with Current Bluetooth

4 3.5 3

2

Multicast Connection II

Multicast I & Multiple Unicast I

1.5 1 0.5 0

Multiple Unicast Connection II (Rejected)

0

50

100

150 200 Time (Sec)

250

300

350

Fig. 10. Aggregate throughput comparison of DSA and Bluetooth.

a matter of fact, most of the well-known benefits of multicasting [17,27] over multiple unicasts are embodied in the DSA, making it more efficient than Bluetooth. DSA improves the average throughput by up to 500% as shown in Fig. 10.

1059 5.8. Delay

Delay is another aspect in which the multicasting mechanism built in DSA, brings it to a minimum level. As we can see from Fig. 11, the delay in DSA is practically constant due to its direct one-to-many communication, whereas it is approximately 30 times higher in Bluetooth. 5

RR E

1060 1061 1062 1063 1064 1065

x 103

5.10. Power consumption

1074

Finally, Fig. 13 presents the power consumption comparison of Bluetooth and DSA. Similar to the unicast case, multicasting with DSA also significantly reduces the power consumed at the master device as well as at all slaves. On average, the master experiences a 54.17% reduction in energy consumption, while the slaves have a 33.05% reduction. As a consequence of this fact, we can see from Fig. 13 that the energy efficiency (Mbyte/J) ratio of DSA overwhelms that of current Bluetooth, hence prolonging the lifetime of the overall network.

1075 1076 1077 1078 1079 1080 1081 1082 1083 1084 1085 1086

5.11. Performance comparison of DSA and NPPC

1087

In this section, we return to the comparison of DSA and NPPC. In order to obtain a deeper insight between their pros and cons, Fig. 14(a) and (b) compare the performance of the two schemes

1088 1089 1090 1091

3

Avg Delay With DSA Avg Delay Current Bluetooth

CO

4

3

2

UN

Delay (Sec)

1067 1068 1069 1070 1071 1072 1073

CTE

1054 1055 1056 1057 1058

As Bluetooth employs multiple unicasts in order to provide a group-like communication mechanism, it is expected to have a much higher overhead than DSA. Fig. 12 confirms this assertion by revealing that DSA experiences around one-seventh the overhead of Bluetooth, despite the control messages broadcasted in DSA.

OF

2.5

1066

1

50

100

150 200 Time (Sec)

2.5

2 Slope ~ 2

1.5

1

0.5 Slope ~ 0.33

0

0

x 106 With DSA Current Bluetooth

Total Bytes Sent (Bytes)


4.5

5.9. Overhead

RO

5

DP

18


ARTICLE IN PRESS

0 250

300

Fig. 11. Delay comparison of DSA and Bluetooth.

350

0

0.5

1 1.5 Data Bytes Received (Bytes)

2

2.5 x 106

Fig. 12. Overhead comparison of DSA and Bluetooth.

ADHOC 89


ARTICLE IN PRESS


Carlos de M. Cordeiro et al. / Ad Hoc Networks xxx (2004) xxx–xxx 0.9

0.7 0.6 Each Slave DSA ~ 22 MBytes/Joule

0.5 0.4

OO F


the other hand, NPPC is noted to increase network interference levels for every new connection, and this behavior becomes increasingly unacceptable as network size grows larger. Analyzing the throughput comparison of both DSA and NPPC in Fig. 14(b) reinforces this fact. Here, NPPC is only observed to surpass DSA on network sizes of 60 nodes or less, while DSA outperforms NPPC in all other scenarios as NPPC starts experiencing high levels of interference. In summary, this is to say that the approach taken by NPPC does not scale to medium (meaning 60 nodes or more) or large network sizes, whereas DSA is observed to give overall superior performance by keeping interference at minimum possible levels and making better use of piconets. We also note that the greedy throughput approach taken by NPPC does not reflect practical applications where traffic is usually bursty. Therefore, continued creation of piconets may render the piconets being idle most of the time, whereas DSA seeks to better utilize piconet resources by supporting a larger number of connections through appropriate scheduling of channels. However, this is not to say that DSA cannot be employed in conjunction with some modified version of NPPC where partitions would occur not for every new connection, but according to aspects such as QoS parameters, number and type of traffic connections, and so on. We have investigated this issue and the results can be found in [35].

Master with DSA All Slaves with DSA Master with current Bluetooth All Slaves with current Bluetooth

0.8


0.3 0.2

Master DSA ~ 5.5 MBytes/Joule

0

0

0.5

1 1.5 Data Received (Bytes)

2

2.5 x 106

PR

0.1

Fig. 13. Power consumption of DSA and Bluetooth.

EC

TED

for different network sizes (represented by the different number of nodes) and increasing number of connections. For this performance evaluation, we have considered a uniform node distribution of 6 per piconet and Bluetooth DH5 packets only. Also, given the fact that the interfering range of Bluetooth devices can go up to 24 m and the density of nodes can be as high as 20 nodes/m3 [38], we have considered that any transmission can interfere with any other hence reflecting some high-density application scenarios. As we can see from Fig. 14(a), DSA is much more resilient to interference than NPPC given its more conservative approach of rearranging piconet schedules instead of partitioning them. On

60 Nodes DSA 60 Nodes NPPC 120 Nodes DSA 120 Nodes NPPC 240 Nodes DSA 240 Nodes NPPC 480 Nodes DSA 480 Nodes NPPC

0.7 0.6 0.5 0.4

UN

0.3

4000 3500 3000 2500 2000 1500 1000

0.2 0.1

(a)

0

1 2 Number of Connections per Piconet

60 nodes DSA 60 nodes NPPC 120 nodes DSA 120 nodes NPPC 240 nodes DSA 240 nodes NPPC 480 nodes DSA 480 nodes NPPC

4500

CO

Packet Collision Probability

0.8

5000

Aggregate Throughput (kbps)

0.9

RR

1092 1093 1094 1095 1096 1097 1098 1099 1100 1101 1102 1103 1104 1105 1106

19

500 0

3

(b)

0

1 2 Number of Connections per Piconet

Fig. 14. Performance comparison of DSA and NPPC: (a) packet collision probability; (b) throughput.

3

1107 1108 1109 1110 1111 1112 1113 1114 1115 1116 1117 1118 1119 1120 1121 1122 1123 1124 1125 1126 1127 1128 1129 1130 1131 1132 1133 1134 1135 1136 1137



RR E

CO

OF

1185 1186 1187 1188 1189 1190 1191 1192 1193 1194 1195

7. Conclusions

1196

By virtue of the Master/Slave communication model, Bluetooth medium access provides for simplicity, low-power, and low-cost, these being the major forces driving the technology. However, this medium access scheme brings in several problems such as inefficient packet forwarding and wastage of bandwidth by forwarding through the master, increased end-to-end packet delay, and additional power consumption at the master unit due to frequent medium access. Moreover, multicast-like communication is not supported which could be employed by many applications envisioned for WPAN environments. With that in mind, we proposed a dynamic scheduling scheme in this paper with two novel approaches, namely, the implementation of direct communication between any two slaves within a piconet, and support for multicast-like transmissions for group communication. Through extensive simulation, we have shown DSA to greatly outperform existing Bluetooth implementation by providing optimal bandwidth usage, lower delay, and low overhead. More importantly, we have shown DSA to be an extremely energy efficient scheme for Bluetooth as this is decisive for the success of envisioned WPAN applications. We believe this work will lead to new research directions. It is worth mentioning that the DSA scheme is simple and can be easily incorporated into current Bluetooth architecture.

1197 1198 1199 1200 1201 1202 1203 1204 1205 1206 1207 1208 1209 1210 1211 1212 1213 1214 1215 1216 1217 1218 1219 1220 1221 1222 1223 1224 1225 1226

CTE

Recent research studies have tackled the issue of Bluetooth piconet performance improvement from different angles. From the scheduling perspective, [3–6] pointed out the drawbacks of existing scheduling techniques and several modifications are suggested to enhance the polling mechanism from the master device. However, the issue of packet forwarding through the master device is not addressed, leading to the problems already mentioned in this paper. [7–12] proposes algorithms to generate the scatternet topology with properties such as limiting the maximum roles and degrees of any node, evenly distributing topology generation, limiting the number of piconets and the maximum number of hops between any pair of devices, and so on. However, the major shortcoming of these approaches is the disregard of traffic characteristics when building the topology. That is, even if any two slaves need to communicate frequently, there is no guarantee that they will be within the same piconet in the resulting scatternet. As we have discussed, another solution would be piconet partitioning (e.g., NPPC), wherein a pair of slaves form a piconet by themselves if frequent communication is taking place between them [14]. However, as we have seen, this approach incurs additional problems such as scatternet scheduling, and, more importantly, this cannot be done indefinitely as interference levels may become unacceptable [16,21,23]. Additionally, this solution makes a very unlikely built-in assumption that all connections are pair-wise distinct nodes in order to piconet partitioning to be successful, and also it cannot support multicast communication. An enhanced pseudo master–slave switch and pseudo piconet partitioning algorithms are presented in [37]. We note, however, that the algorithms in [37] complement the ones we present here and could, therefore, operate in conjunction. Finally, [15] proposes a time-slot leasing approach where the master device allocates slots to slaves for direct communication. While this scheme has a few points in common with our proposal, there are fundamental differences. Firstly, SCO connections are not evaluated. While this

UN

1139 1140 1141 1142 1143 1144 1145 1146 1147 1148 1149 1150 1151 1152 1153 1154 1155 1156 1157 1158 1159 1160 1161 1162 1163 1164 1165 1166 1167 1168 1169 1170 1171 1172 1173 1174 1175 1176 1177 1178 1179 1180 1181 1182 1183 1184

greatly simplifies design, as periodic scheduling of SCO packets has not to be taken into account, it is unrealistic to assume that SCO traffic will not be present [2]. Second, the mechanism in [15] does not provide for multicast-like communication, while this has been a major concern of our DSA scheme. Third, this scheme does not provide any mechanism to adjust bandwidth allocation as traffic demand increases or decreases, while our proposed DSA mechanism dynamically adjusts the slot cycle so as to meet traffic needs.

RO

1138 6. Related work

DP

20


ARTICLE IN PRESS

ADHOC 89


ARTICLE IN PRESS



[13].

1229 Acknowledgement 1230 This work has been supported by the Ohio 1231 Board of Regents Doctoral Enhancement Funds 1232 and the National Science Foundation under grant 1233 CCR-113361.

1234 References

CO

RR

EC

TED

[1] Bluetooth SIG, Bluetooth Specification, . [2] C. Bisdikian, An overview of the Bluetooth wireless technology, IEEE Communications Magazine (2001) 86– 94. [3] M. Kalia, S. Garg, R. Shorey, Efficient policies for increasing capacity in Bluetooth: an indoor pico-cellular wireless system, in: Proceedings of IEEE VTC, May 2000. [4] A. Capone, M. Gerla, R. Kapoor, Efficient polling schemes for Bluetooth piconets, in: Proceedings of IEEE ICC, June 2001. [5] M. Kalia, D. Bansal, R. Shorey, Data scheduling and SAR for Bluetooth MAC, in: Proceedings of IEEE VTC, May 2000. [6] M. Kalia, D. Bansal, R. Shorey, MAC scheduling and SAR policies for Bluetooth: a master driven TDD Picocellular wireless system, in: MoMuC, May 1999, pp. 384– 388. [7] L. Ramachandran, M. Kapoor, A. Sarkar, A. Aggarwal, Clustering algorithms for wireless ad hoc networks, in: Proceedings of the 4th International Workshop on Discrete Algorithms and Methods for Mobile Computing and Communications, 2000. [8] T. Salonidis, P. Bhagwat, L. Tassiulas, Proximity awareness and fast connection establishment in Bluetooth, in: Proceedings of MobiHoc, 2000. [9] T. Salonidis, P. Bhagwat, L. Tassiulas, R. LaMaire, Distributed topology construction of Bluetooth personal area networks, in: Proceedings of IEEE Infocom, 2001. [10] C. Law, A. Mehta, K. Siu, Performance of a new Bluetooth scatternet formation protocol, in: Proceedings of the ACM Symposium on Mobile Ad Hoc Networking and Computing, October 2001. [11] C. Law, K. Siu, A Bluetooth scatternet formation algorithm, in: Proceedings of the IEEE Symposium on Ad Hoc Wireless Networks, November 2001. [12] G. Zaruba, I. Chlamtac, S. Basagni, Bluetrees—scatternet formation to enable Bluetooth-based ad hoc networks, in: Proceedings of IEEE ICC, June 2001.

UN

1235 1236 1237 1238 1239 1240 1241 1242 1243 1244 1245 1246 1247 1248 1249 1250 1251 1252 1253 1254 1255 1256 1257 1258 1259 1260 1261 1262 1263 1264 1265 1266 1267 1268 1269 1270 1271 1272 1273

OO F

1228

[13] Z. Wang, R. Thomas, Z. Haas, Bluenet—a New Scatternet Formation Scheme, in: Proceedings of the 35th HICSS, Big Island, Hawaii, January 2002. [14] W. Zhang, H. Zhu, G. Cao, On improving the performance of Bluetooth networks through dynamic role management, Technical Report, CSE-01-018. , May 2001. [15] W. Zhang, H. Zhu, G. Cao, Improving Bluetooth network performance through a time-slot leasing approach, in: Proceedings of WCNC, 2002. [16] C. Cordeiro, D. Agrawal, Mitigating the effects of intermittent interference on Bluetooth ad hoc networks, in: 13th IEEE International Symposium on Personal, Indoor and Mobile Radio Communications (PIMRC), Lisbon, Portugal, September 2002. [17] H. Gossain, C. Cordeiro, D. Agrawal, Multicast: wired to wireless, in: IEEE Communications Magazine, June 2002, pp. 116–123. [18] L. Ji, M.S. Corson, Differential destination multicast—a MANET multicast routing protocol for small groups, Infocom (2001) 1192–1202. [19] The Network Sumulator (ns-2). . [20] BlueHoc, IBM Bluetooth Simulator. . [21] C. Cordeiro, D. Agrawal, D. Sadok, Piconet interference modeling and performance evaluation of Bluetooth MAC protocol, in: IEEE Transactions on Wireless Communications, vol. 2, no. 6, November 2003. [22] D. Agrawal, Q.-A. Zeng, Introduction to wireless and mobile systems, Brooks/Cole Publishing, 436 pp., ISBN 0534-40851-6, 2003. [23] C. Cordeiro, D. Agrawal, Employing dynamic segmentation for effective co-located coexistence between Bluetooth and IEEE 802.11 WLANs, in: IEEE GLOBECOM, Taiwan, November 2002. [24] Y. Bin Lin, I. Chlamtac, Wireless and Mobile Network Architectures , John Wiley, October 2000, ISBN: 0471394920. [25] W. Heinzelman, A. Chandrakasan, H. Balakrishnan, Energy-efficient communication protocol for wireless microsensor networks, in: Proceedings of HICSS, January 2000. [26] W. Ye, J. Heidemann, D. Estrin, An energy-efficient MAC protocol for wireless sensor networks, in: Proceedings of IEEE Infocom, June 2002. [27] C. Cordeiro, H. Gossain, D. Agrawal, Multicast over wireless mobile ad hoc networks: present and future directions, in: IEEE Network, Special Issue on Multicasting: An Enabling Technology, January/February 2003. [28] Y. Lim, S. Min, J. Ma, Performance evaluation of the Bluetooth-based public internet access point, in: Proceedings of the 15th ICOIN, 2001, pp. 643–648. [29] N. Rouhana, E. Horlait, BWIG: Bluetooth web internet gateway, in: Proceedings of IEEE Symposium on Computer and Communications, July 2002.

PR

1227 8. Uncited reference

21

1274 1275 1276 1277 1278 1279 1280 1281 1282 1283 1284 1285 1286 1287 1288 1289 1290 1291 1292 1293 1294 1295 1296 1297 1298 1299 1300 1301 1302 1303 1304 1305 1306 1307 1308 1309 1310 1311 1312 1313 1314 1315 1316 1317 1318 1319 1320 1321 1322 1323 1324 1325 1326 1327 1328 1329


OF

TCP over wireless, cellular networks, and short-range radio communication such as IEEE 802.15. He is the author of the book Ad Hoc and Sensor Networks: A Reality to be published in 2004, and has authored many book chapters in the wireless area. He holds pending patents involving Bluetooth and IEEE 802.11, has delivered tutorials in areas such as wireless broadband and mobile ad hoc and sensor networks. He has received two best paper awards from refereed conferences in networking and was the recipient of the 2003/2004 The Nation DeanÕs List Award. He worked for IBM in San Jose, CA, and is an IEEE member.

RO

Sachin Abhyankar has concluded BS and MS in Computer Science. He worked as a software engineer for couple of years before joining the MS program at the University of Cincinnati, where he worked as a research assistant in the Center for Distributed and Mobile Computing in the area of wireless ad hoc networks. He has published various papers related with wireless networks in magazines and conferences. Presently, he is working as a software developer for Qualcomm.

Dharma P. Agrawal is the Ohio Board of Regents Distinguished Professor of Computer Science and Computer Engineering and the founding director of the Center for Distributed and Mobile Computing at the University of Cincinnati, OH. He has been a faculty member at the NC State University, Raleigh, NC (1982–1998) and the Wayne State University, Detroit (1977–1982). His current research interests include wireless and mobile networks, distributed processing, and scheduling techniques. He has authored a textbook on Introduction to Wireless and Mobile Systems published by Brooks/ Cole in August 2002. He is an editor for the Journal of Parallel and Distributed Systems and the International Journal of High Speed Computing. He has served as an editor of the IEEE Computer magazine, and the IEEE Transactions on Computers. He has been the Program Chair and General Chair for numerous international conferences and meetings. He has received numerous certificates and awards from the IEEE Computer Society. He was selected for the ‘‘Third Millennium Medal’’ by the IEEE for his outstanding contributions. He is a fellow of the IEEE, ACM, and AAAS.

CTE

[30] O. Kasten, M. Langheinrich, First experience with Bluetooth in the smart-its distributed sensor network, in: Proceedings of the Workshop in Ubiquitous Computing and Communications (PACT), October 2001. [31] F. Siegemund, M. Rohs, Rendezvous layer protocols for Bluetooth-enabled smart devices, in: Proceedings of International Conference on Architecture of Computing Systems, April 2002. [32] D. Estrin, R. Govindan, J. Heidmanm, New century challenges: scalable ordination in sensor networks, in: ACM Mobicom, 1999, pp. 263–270. [33] J. Kahn, R. Katz, K. Pister, New century challenges: mobile networking for smart dust, in: ACM Mobicom, 1999, pp. 271–278. [34] C. Cordeiro, S. Abhyankar, R. Toshiwal, D. Agrawal, BlueStar: enabling efficient integration between Bluetooth WPANs and IEEE 802.11 WLANs, in: ACM/Kluwer Mobile Networks and Applications (MONET) Journal, Special Issue on Integration of Heterogeneous Wireless Technologies, vol. 9, no. 4, August 2004. [35] C. Cordeiro, S. Abhyankar, D.P. Agrawal, Design and Implementation of QoS-driven dynamic slot assignment and piconet partitioning algorithms over Bluetooth WPANs, in: IEEE INFOCOM, March 2004. [36] C. Cordeiro, S. Abhyankar, D.P. Agrawal, A novel energy efficient communication architecture for Bluetooth ad hoc networks, in: Proceedings of Personal Wireless Communication (PWC), Venice, Italy, September 2003. [37] S. Abhyankar, R. Toshiwal, C. Cordeiro, D. Agrawal, On the application of traffic engineering over Bluetooth ad hoc networks, in: ACM MSWiM, in conjunction with ACM Mobicom, September 2003. [38] I.F. Akyildiz, W. Su, Y. Sankarasubramaniam, E. Cayirci, A survey on sensor networks, IEEE Communications Magazine 40 (8) (2002).

RR E

1330 1331 1332 1333 1334 1335 1336 1337 1338 1339 1340 1341 1342 1343 1344 1345 1346 1347 1348 1349 1350 1351 1352 1353 1354 1355 1356 1357 1358 1359 1360 1361 1362 1363 1364 1365


DP

22


ARTICLE IN PRESS

UN

CO

Carlos de M. Cordeiro is a senior research engineer at Nokia Research Center working on wireless networking. He received his PhD in computer science and engineering in 2004 from the University of Cincinnati, OH, USA, and his MS and BSc in computer science in 1998 and 2000, respectively, from the Federal University of Pernambuco, Brazil. His research interests and numerous papers are in the broad area of computer networks with emphasis on wireless and mobile communication including ad hoc and sensor networks, routing and MAC protocols, directional antenna systems, multicast,