See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/225131180

Bluetooth: Architecture, Protocols and Scheduling Algorithms

Article  in  Cluster Computing · April 2002

DOI: 10.1023/A:1013989524865 · Source: DBLP

CITATIONS READS

44 643

3 authors:

Raffaele Bruno Marco Conti

Italian National Research Council Italian National Research Council
115 PUBLICATIONS   1,570 CITATIONS    232 PUBLICATIONS   7,864 CITATIONS   

SEE PROFILE SEE PROFILE

Enrico Gregori
Italian National Research Council
135 PUBLICATIONS   4,313 CITATIONS   

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Mobile OpportunisTic Traffic Offloading View project

ESPRIT View project

All content following this page was uploaded by Raffaele Bruno on 24 November 2015.

The user has requested enhancement of the downloaded file.

 Cluster Computing 5, 117–131, 2002
 2002 Kluwer Academic Publishers. Manufactured in The Netherlands.

Bluetooth: Architecture, Protocols and Scheduling Algorithms

RAFFAELE BRUNO, MARCO CONTI and ENRICO GREGORI
Consiglio Nazionale delle Ricerche, Istituto CNUCE, Via G. Moruzzi, 1, Ghezzano 56010 Pisa, Italy

Abstract. The paper focuses on one of the emerging technologies for constructing a Mobile ad hoc network: Bluetooth. Bluetooth can be
exploited on small scales, to build ad hoc wireless Personal Area Networks (WPAN), i.e., networks that connect devices placed inside a
circle with radius of 10 m. The Bluetooth technology is just starting to appear on the market and its architecture and protocols are not widely
known. For this reason, the first part of the paper contains a tutorial-oriented description of the Bluetooth architecture and protocols. In
addition, in the paper we extensively discuss the performance of this technology by investigating, through simulation, the main performance
figures: the protocol efficiency (channel utilization), the response time, and the system power (i.e., the ratio between throughput and delay).
Specifically, the performance analysis focuses on the algorithms for scheduling the transmissions in a Bluetooth network. The Bluetooth
Specification indicates a Round Robin scheduler as possible solution, that is each slaves is polled in a consecutive order. For this reason,
we first study in depth the performance figures of a Bluetooth network with a Round Robin scheduler. Our results point out the inefficient
Bluetooth behavior under asymmetric traffic conditions. To solve this problem we propose and analyze an innovative scheduling algorithm
specifically tailored to the Bluetooth characteristic. This algorithm, named efficient double-cycle (EDC), dynamically adapts the polling
frequency to the traffic conditions. A performance study indicates that our EDC scheduler always outperforms the Round Robin scheduler.

Keywords: wireless PANs, ad hoc networks, MAC protocol, scheduling, performance evaluation

1. Introduction will be embedded not only in devices as cellular phones, mo-

A mobile ad hoc network is a system of wireless mobile nodes
dynamically self-organizing in arbitrary and temporary net-
work topologies. People and vehicles can thus be internet-
worked in areas without a pre-existing communication in-
frastructure, or when the use of such infrastructure requires
wireless extension [1].
Bluetooth technology [2] is a de-facto standard for Wire-
less Personal Area Networks (WPAN). A WPAN is an ad hoc
network constituted by connected devices placed inside a cir-
cle with radius of 10 m. The Bluetooth specification is re-
leased by the Bluetooth Special Interest Group (SIG). In ad-
dition, the IEEE 802.15 Working Group for Wireless Personal
Area Networks has started a project to publish and approve a
standard derived from the Bluetooth Specification.
The Bluetooth technology is just starting to appear on the
market and its architecture and protocols are almost unknown.
Currently, to understand the details of this technology a reader
must spend a lot of time analyzing Bluetooth SIG documents
or reading some of the recently appeared books [2–4]. For
this reason in this paper we also include a tutorial-oriented
description of the Bluetooth architecture and protocols. This
description is directly obtained by synthesizing the standard
documents pointing out the aspects that are relevant to under-
stand the Bluetooth behavior and to study its performance.
The technologies for WPANs offer a wide space for inno-
vative solutions and applications that could bring to a radical
change in everyday life. In particular, the Bluetooth technol-
ogy is much more than a wireless connection for a nomadic
access to the Internet or for cable replacement, but it wants
to be an enabling technology for the global mobility of de-
vices and services. We can foresee that a Bluetooth module
bile computers, GPS navigator, PDAs and so on, but in every
digital device where computing and wireless connectivity fea-
tures could be used for providing innovative services. Obvi-
ous applications arise from the possibility of forming ad hoc
networks with our workspace electronic devices. Let us imag-
ine a PDA that automatically synchronizes with our desktop
computer and transfers e-mails, files and schedule informa-
tion. It is out the office that the most innovative applications
can be thought, introducing services with innovative charac-
teristics that will be totally different from traditional services.
For example, let us imagine to have an electronic device that,
when we are arriving at home, automatically unlocks the door.
When we are getting in, it can also turn on the house lights and
adjust the heat or air-conditioning to our pre-set preferences.
The Bluetooth applications so far presented, before they
can be deployed, need a considerable effort from the research
community to resolve several technical issues. One impor-
tant issue is the concrete coexistence of Bluetooth technology
with other wireless ad hoc technologies designed for using
the same radio spectrum, like IEEE 802.11, [10]. Further-
more, most of the application scenarios considered require
a high density of Bluetooth networks in relatively small ar-
eas. Therefore, other researches have studied the mutual in-
terference due to the frequency reuse of overlapping networks
[11–13]. A field that is critical is the management of the lim-
ited available bandwidth as Bluetooth networks deliver much
lower bandwidth than wired networks, i.e., 1 Mbps vs. 10–
100 Mbps [6]. In this paper we primarily concentrates on this
last issue. Since Bluetooth relies on a common transmission
medium, the transmissions of the network stations must be
coordinated by the Medium Access Control (MAC) protocol.
118
This coordination is achieved by means of control informa-
tion that is carried explicitly by control messages traveling
along the medium. Specifically, the Bluetooth MAC behaves
as a polling system [8]. Hence, the MAC protocol schedul-
ing algorithm by determining the order in which stations are
polled, is the main element to determine the network effi-
ciency. The Bluetooth Specification indicates a Round Robin
scheduler as a possible solution, i.e., each slave is polled in a
consecutive order. However our performance studies, with a
Round Robin scheduler, indicate an inefficient Bluetooth be-
havior when the traffic in the network is asymmetric. The
original contribution of this paper is the proposal and eval-
uation of an efficient scheduling algorithm named Efficient
Double-Cycle (EDC). Our algorithm preserves the fairness
typical of a Round Robin scheme but reduces the polling
overheads. This is achieved by tuning the polling order to
the network traffic conditions to limit the channel-bandwidth
wastage caused by the polling of empty stations. A perfor-
mance study indicates that our EDC scheduler outperforms
the Round Robin scheduler. Specifically, we show that our
algorithm (when compared with Round Robin) increases the
network efficiency and at the same time reduces the user re-
sponse time.
The design of a scheduler suitable for the Bluetooth MAC
layer was also considered by Johansson et al. that propose
a Fair Exhaustive Polling (FEP) [14]. Similarly to our al-
gorithm, FEP tries to avoid the polling of inactive stations.
Specifically, they define the meaning of active and inactive
state for the slaves, and introduce polling sub cycles where
only the active slaves are polled in a Round Robin fashion.
Our algorithm further extends this idea (i) by separating the
scheduling of the uplink and downlink transmissions, and
(ii) by adopting a truncated binary exponential-backoff algo-
rithm to determine the amount of time an inactive slave is
removed from the polling cycle.
The paper is organized as follows. Section 2 introduces
the Bluetooth technology. In particular we concentrates on
physical and data link layers. Then, section 3 presents a com-
plete performance analysis for a Bluetooth piconet adopting
a Round Robin polling scheme for the channel access. In
section 4 we propose and evaluate our scheduling algorithm.
Concluding remarks are summarized in section 5.
2. Bluetooth technology architecture and protocols
The Bluetooth system is operating in the 2.4 GHz Industrial,
Scientific, and Medicine (ISM) band. It is based upon a low-
cost, short-range radio link, integrated into a microchip, en-
abling protected ad hoc connections for wireless communica-
tion of voice and data in stationary and mobile environments.
The Bluetooth Special Interest Group (SIG) is working
to impose the Bluetooth technology as the de-facto wire-
less standard for personal area wireless communication. The
architecture and protocols presented in this paper refer to
the Bluetooth 1.0B Specification released in December of
1999 [2].
BRUNO, CONTI AND GREGORI
Bluetooth devices adopt the 48-bit addressing scheme de-
fined by the IEEE 802 standard. From a logical standpoint,
Bluetooth belongs to the contention-free token-based multi-
access networks. In a Bluetooth network, one station has the
role of master and all other Bluetooth stations are slaves. The
master decides which slave is the one to have the access to
the channel. More precisely, a slave is authorized to deliver
a single packet to the master only if it has received a polling
message from the master. The units that share the same chan-
nel (i.e., are synchronized to the same master) form a piconet,
the fundamental building block of a Bluetooth network. A pi-
conet has a gross bit rate of 1 Mbps that represents the chan-
nel capacity before considering the overhead introduced by
the adopted protocols and polling scheme.
A piconet contains a master station and up to seven active
(i.e., participating in data exchange) slaves contemporarily.
Independent piconets with overlapping coverage areas form a
scatternet when at least a unit participates to data exchange
in more than one piconet. It is worth pointing out that a unit
can be active in more than one piconet, but can be master into
only one. A slave may communicate with different piconets
only in a time-multiplexing mode. This means that, for any
time instant, it can only transmit on a single piconet because it
has to change its synchronization parameters before listening
to different channels.
2.1. The Bluetooth architecture
The main aim of the Bluetooth Specification is to guarantee
the interoperability between different applications by support-
ing any kind of service and providing the mean to imple-
ment them (service discovery, connection oriented, connec-
tion less links). This is achievable only if a common Blue-
tooth data link and physical layer is used. As we can see
in figure 1, the complete protocol stack contains a Bluetooth
core of Bluetooth-specific protocols (dark green protocols in
the figure) and non-Bluetooth-specific protocols.
The Bluetooth core protocols comprise exclusively Blue-
tooth-specific protocols. In the next subsections we describe
in details the Bluetooth Baseband and Radio layers. The radio
layer provides the physical links among Bluetooth devices,
while the Baseband layer provides a transport service of pack-
ets on the physical link. This service is exploited by the other
Bluetooth data link layer protocol, i.e., the L2CAP, to permit
Figure 1. Bluetooth protocol stack.
BLUETOOTH
to higher-level protocols and applications to transmit and re-
ceive their messages. The main features supported by L2CAP
are:
(i) protocol multiplexing: the L2CAP uses a protocol type
field to distinguish between upper layer protocols;
(ii) segmentation and reassembly: this feature uses two bits
in the payload header, and is required because the Base-
band packet size is smaller than the usual size of packets
used by higher layer protocols;
(iii) group management, i.e., the capability to map transpar-
ently groups of addresses, i.e., groups of devices, onto
piconets without the need of knowing the Baseband rou-
tines;
(iv) quality of service assurance: the L2CAP connection es-
tablishment permits the exchange of quality of service
parameters, and the L2CAP would monitor the resource
to assure the respect of agreed QoS.
The LMP protocol is responsible for the set-up and man-
agement of physical links. The management of physical links
consists of several activities: (i) putting a slave in a particular
operating state (i.e., sniff, hold or park mode), (ii) monitor-
ing the status of the physical channel and assuring a prefixed
Quality of Service (e.g., LMP settles transmission power, the
maximum poll interval, etc.). LMP also implements security
capabilities at link level.
Finally, RFCOMM is a serial line emulation protocol, i.e.,
a cable replacement protocol. It emulates RS-232 control and
data signals over Bluetooth Baseband, providing transport ca-
pabilities for upper level services that use serial line as trans-
port mechanism.
The other protocols presented in the figure are application-
oriented protocol enabling applications to run over Bluetooth
devices. In addition to this protocol layers, the Specification
also defines a Host Controller Interface that provides a com-
mand interface to the baseband controller, link manager, and
access to hardware status and control registers.
2.1.1. The Bluetooth physical layer
A Bluetooth unit consists of a radio unit operating in the
2.4 GHz band. In this band are defined 79 different Radio Fre-
quency (RF) channels that are spaced of 1 MHz. The physical
layer utilizes as technique of transmission a frequency hop-
ping spread spectrum (FHSS) where the hopping sequence is
a pseudo-random sequence of 79-hop length, and it is unique
for each ad hoc network we can establish. Therefore, the es-
tablishment of a physical channel is associated to the defin-
ition of a channel frequency hopping sequence which has a
very long period length and which does not show repetitive
patterns over short time interval. It’s possible to do it by ex-
ploiting the actual value of master clock and its unique Blue-
tooth device address, a 48-bit address compliant to the IEEE
802 standard. The FHSS system has been chosen to reduce
the interference of nearby system operating in the same range
of frequency (for example, IEEE 802.11 WLANs) and make
119
Figure 2. Multi-slot packet transmissions.
the link robust [8,9]. The nominal rate of hopping between to
consecutive RF is 1600 hop/s.
A Time Division Duplex (TDD) scheme of transmission is
adopted. The channel is divided into time slots, each 625 µs
in length, and each slot corresponds to a different RF hop fre-
quency. The time slots are numbered according to the Blue-
tooth clock of the master. The master can transmit in even
numbered time slots. Odd numbered time slots are reserved
for slaves’ transmissions. The frame structure is shown in
figure 2. The transmission of a packet nominally covers a
single slot, but it may last up to five consecutive time slots.
For multi-slots packets the RF hop frequency to be used for
the entire packet is the RF hop frequency assigned to the time
slot in which the transmission has begun. The changing of
RF used after transmitting or receiving a packet reduces the
interference from signals coming from other radio modules.
The Bluetooth antenna has a nominal power that permit a
range for radio link from 10 cm to 10 m. This range can be
extended up to 100 m increasing the transmit power.
2.1.2. The Bluetooth Baseband layer
The Baseband layer is responsible for: (i) the set-up of the
physical connections between master and slaves; (ii) the send-
ing and receiving of different packets upon the physical chan-
nel (channel access); (iii) the synchronization of devices be-
longing to a piconet on master clock, and (iv) the manage-
ment of the different power saving state which the device can
stay in. In the following we will describe in depth points (i)
and (ii).
Connections’ type. There are two types of physical links
that can be established between Bluetooth devices: a Syn-
chronous Connection-Oriented (SCO) link, and an Asynchro-
nous Connectionless (ACL) link. The first type of physi-
cal link is a point-to-point, symmetric connection between
the master and a specific slave. It is used to deliver delay-
sensitive traffic, mainly voice. In fact the SCO link rate is
64 kbps and it is settled by reserving a couple of consecutive
slots for master-to-slave transmission and immediate slave-to-
master response. The SCO link can be considered as a circuit-
switched connection between the master and the slave. The
second kind of physical link, the ACL link, is a connection
between the master and all slaves participating to the piconet,
and it can be considered as a packet-switched connection be-
tween the Bluetooth devices that supports point-to-multipoint
transmissions from the master to the slaves. The ACL chan-
nel guarantees the reliable delivery of data: a fast Automatic
120 BRUNO, CONTI AND GREGORI

Repeat Request (ARQ) scheme is adopted to assure data in-
tegrity.
Channel access. As stated before, the channel access is
managed according to a polling scheme. The master decides
which slave is the only one to have the access to the channel
by sending to him a packet. The master packet may contain
data or can simply be a polling packet. When the slave re-
ceives a packet from the master it is authorized to transmit
in the next time slot. For SCO links the master periodically
polls the corresponding slave. Polling is asynchronous for
ACL links.
Figure 3 presents a possible pattern of transmissions in a
piconet with a master and two slaves. Slave1 has both a SCO
(dark-gray packets) and an ACL (light-gray packets) link with
the master, while Slave2 has an ACL link only (medium-gray
packets). In this example the SCO link is periodically polled
by the master every six slots, while ACL links are polled asyn-
chronously. Furthermore, the size of the packets on an ACL
link is constrained by the presence of SCO links. For ex-
ample, in the figure the master sends a multi-slot packet to
Slave2, which, in turn, can reply with a single-slot packet
only, because the successive slots are reserved for the SCO
link.
The general format of Bluetooth packets is shown in fig-
ure 4. As we can observe three main parts characterize the
packet. The Access Code (AC) is used for synchronization
Figure 3. Packet transmissions on SCO and ACL links.
and identification. In particular, after a physical link is estab-
lished, it is identified through a Channel Access Code (CAC)
that is derived from the master clock and its Bluetooth de-
vice address. The CAC permits the devices to identify pack-
ets coming from a piconet which they don’t belong to. The
header integrity is doubly protected. Firstly, a HEC is intro-
duced, and then the total header is encoded with a rate 1/3
FEC.
The AM_ADDR, that is the address, is 3-bit long, and
hence it is possible to have only seven active slaves (the all
zero sequence is a broadcast address). The ARQN and SEQN
bits are used for the ARQ scheme and are meaningful only
for ACL packets. The different kinds of packets, i.e., con-
trol packets, ACL packets and SCO packets, are distinguished
through the TYPE bits.
The SCO packets, denoted by HVy, are never retransmit-
ted and the payload isn’t protected by a CRC. The subscript
y indicates how many SCO connections may be concurrently
active. In addition, to these three pure SCO packets, a DV
packet is defined which can carry asynchronous data but is
still recognized on SCO links.
The ACL packets are of two different groups, one denoted
DMx and the other one denoted DHx. The former has a pay-
load encoded with a rate 2/3 FEC and the latter hasn’t got a
FEC encoding. The subscript x stands for the number of slots
that are necessary to transmit the packet. All ACL packets
have a CRC field for checking the payload integrity. ACL
packets have also a payload-header and a payload-CRC field.
The payload header is one or two bytes long, depending on
packet type, and it specifies: (i) the logical channel (i.e., if
the packet is a LMP message, or the start of an L2CAP mes-
sage, or the continuation fragment of an L2CAP message),
(ii) the user payload length, and (iii) the flow control on the
logical channels. Tables 1 and 2 summarize SCO and ACL
packet characteristics, respectively. In addition, the tables re-
port, assuming a piconet with two only devices, the maximum

Table 1
SCO packets.

Type User payload FEC CRC Symmetric max rate

(bytes) (kbps)

HV1 10 1/3 no 64.0

HV2 20 2/3 no 64.0
HV3 30 no no 64.0
DVa 10 + (0–9)D 2/3 D yes D 64.0 + 57.6 D

Figure 4. Bluetooth packet structure (fields’ length in bits). a Items followed by “D” relate to data field only.

Table 2
ACL packets.

Type User payload FEC CRC Symmetric max rate Asymmetric max rate (kbps)
(bytes) (kbps) Forward Reverse

DM1 0–17 2/3 yes 108.8 108.8 108.8

DM3 0–121 2/3 yes 258.1 387.2 54.4
DM5 0–224 2/3 yes 286.7 477.8 36.3
DH1 0–27 no yes 172.8 172.8 172.8
DH3 0–183 no yes 390.4 585.6 86.4
DH5 0–339 no yes 433.9 723.2 185.6
BLUETOOTH
channel throughput for symmetric and asymmetric communi-
cations.
2.1.3. Baseband routines for the ad hoc networking
The Bluetooth technology has been devised for providing a
flexible wireless connectivity among digital devices. Before
starting a data transmission a Bluetooth unit needs to discover
if any other Bluetooth unit is in its operating space. To do
this, a Bluetooth unit enters the inquiry state. In this state,
it continuously sends an inquiry message, i.e., a packet with
only the access code. A station responds to the inquiry by
exploiting a random access protocol.
After an inquiry, a Bluetooth unit has discovered the Blue-
tooth addresses of the other Bluetooth units located in its radio
coverage area, and has collected an estimation of their clocks.
If it wants to activate a new connection it has to distribute its
own Bluetooth device address and clock, and this is the aim of
paging routines. The unit that starts paging is automatically
elected the master of the new connection, and the paged unit
is the slave.
When a connection is established, the active slaves have
to maintain the synchronization. This is carried out by ac-
tive slaves simply listening to the channel at every master-to-
slave slot because only the CAC is necessary and every kind
of packets is usable for this purpose. Further details about the
ad hoc networking features for the Bluetooth technology, can
be found in [2].
3. Performance evaluation of Bluetooth
The maximum asymmetric throughput of 723.2 kbps reported
in table 2 is only a reference value. The real through-
put depends on many factors, e.g., flow-control mechanisms
adopted by upper layers (preliminary results can be found in
[15,16]), characteristics of ingoing traffic, segmentation over-
head introduced by each layer, and so on. The main target of
this work is not to analyze the interaction of the Bluetooth
technology with transport mechanisms of upper layer pro-
tocols, but to evaluate the Bluetooth Baseband layer perfor-
mances in a WPAN environment where several point-to-point
connections are established.
Hereafter, the performance evaluation of Bluetooth has
been carried out by simulation. Results presented in this sec-
tion have been obtained by applying the independent replica-
tion technique with a 90% confidence level. In the following
sections we will describe the network and traffic models, and
the performance indices.
3.1. The piconet model
The simulated network topology is constituted by a single
piconet with a master and six slaves. Each slave has an IP
packet generator. When an IP packet is created (according to
a specific arrival process) by the slave, it is encapsulated into
an L2CAP packet that adds the 4-byte L2CAP header, and it
is sent to the local transmission queue. This local queue has a
121
finite size BS and the queued packets are served according to a
FCFS policy. Large L2CAP packets must be segmented into
smaller Baseband packets before their transmission. A new
L2CAP packet cannot be served till all fragments (generated
during the segmentation) of the previous L2CAP packet have
been successfully transmitted. The segmentation procedure
is accomplished, just before the transmission, in such a way
to generate the minimum number of Baseband packets. In
particular let be xL2CAP the number of bytes to be sent, then
a new DHx packet will be created with a user payload UP,
according to the following procedure:
xL2CAP
27 ⇒ DH1 with UP = xL2CAP,
27 < xL2CAP
183 ⇒ DH3 with UP = xL2CAP , (1)
xL2CAP > 183 ⇒ DH5 with UP = min{xL2CAP, 339}.
Within the master N local transmission queues are imple-
mented, where N is the number of active slaves. Each master
local queue has a finite size BM and the queued packets are
served according to a FCFS policy. When an L2CAP packet
is completely received by the master, the master accomplishes
the reassembly procedure, then it extracts the encapsulated IP
packet and forms a new L2CAP packet for the slave that is
the destination of that IP traffic. The master puts the new
L2CAP packet in the local queue reserved to the slave that is
the destination of that packet. In the transmission phase the
master behaves in the same way of slaves. The master and the
slaves transmit the ACL packets according to the Bluetooth
transmission scheme described in the previous sections.
The slave to be polled by the master is selected by the
scheduling algorithm. The Bluetooth Specification indicates
as possible solution the Round Robin polling algorithm:
slaves are polled in a cyclic order. In our simulator we have
implemented both the Round Robin polling algorithm and the
Efficient Double-Cycle (EDC) algorithm that is explained in
section 4.
3.2. Traffic characterization
A realistic characterization of the traffic in a PAN is quite
difficult due to the lack of an exact knowledge of the future
applications based upon the Bluetooth technology. What we
have modeled is the distribution of the traffic among the slaves
in a piconet, rather than the correlation between the arrival
times of consecutive packets. The ability to effectively react
to various traffic distributions among slaves is one of the most
important features of a scheduling algorithm in an highly dy-
namic scenario like a Bluetooth piconet.
We have modeled the intra-piconet communications, i.e.,
no traffic comes (goes) from (to) the outside of the piconet.
Each slave is a source of IP packets and the interarrival
times between consecutive packet generations are exponen-
tially distributed, hence the IP packet arrival process is Pois-
sonian. The packet length is uniformly distributed in the
range from 500 to 1500 bytes.
Let us introduce some notation adopted hereafter. For each
slave Si , i = 1, . . . , N, we denote with γUPi the average of-
122
fered load of Si towards the master, and with γDW i the average
offered load of the master towards Si . We will refer to the ag-
gregated offered load from all slaves towards the master with
OLUP , and we will refer to the aggregated offered load from
the master towards all slaves with OLDW . Since we have con-
sidered only a closed piconet, i.e., all the traffic is generated
by the slaves, we have OLUP = OLDW . If we indicate with
x(i) the fraction of OLUP that is generated by Si , then we
have:


N 3.3. Performance indices
γUPi = x(i) · OLUP , x(i) = 1, i = 1, . . . , N.
i=1
Furthermore, if we indicate with pij the fraction of ongoing
traffic from Si that is addressed to Sj , and by noting that Si
cannot send traffic towards itself, we have:


N

N
γDW i = pj i γUPj , pii = 0, pij = 1,
j =1 j =1
i = 1, . . . , N.
Now we can easily define a vectorial notation by introducing
the following quantities:
– vectors of uplink loads and downlink loads as:
T
γUP = [γUP1 . . . γUPN ], T
γDW = [γDW1 . . . γDWN ];
– vector of uplink loads distribution and addressing matrix
as:
 
x T = x(1) . . . x(2) , P = {pij }.
By exploiting this compact notation, the distribution of on-
going traffic from the slaves and ingoing traffic towards the
slaves is exhaustively described by the following expressions:
γUP = OLUP x, γDW = PT γUP .
Each different couple of addressing matrix and vector of up-
link loads distribution will correspond to different profiles for
the uplink and downlink loads. In the section related to the
performance analysis we have considered two different sce-
narios that can be recognized as representative of completely
different applications. The first scenario has been called Sym-
metric Case because all slaves produces the same amount of
traffic, and distribute their ongoing traffic uniformly among
all possible destinations. The second scenario has been called
Asymmetric Case because a single station produced the 90%
of OLUP . As in the symmetric case, the slave-generated traffic
is uniformly spread among all possible destinations.
We believe that the symmetric case models a typical coop-
erative application were each participant has the same role
(e.g., during multicasting video-streaming), and the asym-
metric case models an application that operates in a typical
server-client fashion (e.g., during information retrieval). Ta-
ble 3 summarizes the vector components of uplink loads dis-
tribution and the addressing matrix elements that correspond
to the previous described scenarios.
BRUNO, CONTI AND GREGORI
Table 3
Description of traffic scenarios.
Symmetric case Asymmetric case
Uplink loads distribution
x T = [1/N, . . . , 1/N ] x T = [0.9, 0.1/(N − 1), . . . , 0.1/(N − 1)]
Addressing matrix
pij = 1/(N − 1) pij = 1/(N − 1)
One of the performance indices we use to evaluate the effi-
ciency of the MAC protocol is the channel utilization, which
is defined as the fraction of channel bandwidth used by suc-
cessfully transmitted messages. This fraction is known as the
utilization of the channel, and the maximum value it can at-
tain is known as the capacity of the MAC protocol [7,8]. It is
worth noting that by multiplying the capacity and the channel
speed we obtain the network maximum throughput. For this
reason in the following we refer to the throughput figures to
measure the protocol efficiency.
The capacity is used to evaluate the efficiency of MAC pro-
tocol algorithms, however from the user standpoint other per-
formance figures are needed to measure the Quality of Service
(QoS). The most commonly used performance measure is the
delay, which can be defined in several forms [5,8] depending
on the time instants considered during its measurement (ac-
cess delay, queuing delay, propagation delay, etc.). In com-
puter networks the response time, defined as the time between
the generation of a message at the sending station and its re-
ception at the destination station, is the best figure to measure
the QoS perceived by the users. However, it depends on the
amount of buffering inside the network and it is not always
meaningful to evaluate a shared-medium technology. For ex-
ample, during congested periods, the buffers fill up and the
response time does not depend on the network technology but
it is just a function of the buffer length. For this reason, in
this paper, we also estimate the MAC delay. The MAC delay
of a station in a LAN is the time between the instant at which
a packet comes to the head of the station transmission queue
and the end of the packet transmission [8].
The two main indices we have identified, throughput and
response time, cannot be both maximized at the same time.
We can try to increase as much as possible the throughput in
order to maximize the bandwidth utilization, but it would be
also reasonable to decrease the response time in order to im-
prove the promptness of the transmission service perceived
by the users. These two different targets are competing each
other: an increase in the system utilization deteriorates the
response time. A single combined measure of these two per-
formance indexes is the power that is defined as the ratio be-
tween the throughput and the response time of the system [9].
The power can be considered a nice criterion for the evalua-
tion of scheduling algorithms because its maximum value is a
trade-off between promptness and efficiency. In the following
we will formalize the power concept for a Bluetooth piconet.
BLUETOOTH 123

Let us now introduce some notations. We define as
MACUPi and MACDW i the average MAC delay experienced
by the IP packets that traverse the link from Si to the mas-
ter, and from the master to Si , respectively. In particular the
power PUPi is associated to the link from Si to the master, and
the power PDW i is associated to the link from the master to Si .
PUPi and PDW i have the following definitions:
γUPi γDW i
PUPi = , PDW i = . (2)
MACUPi MACDW i
Equations (2) define the power index for a link analyzed in
isolation. The definition of a power index that expresses the
behavior of the overall piconet requires the introduction of the
average aggregate throughput γ and of an average delay D of
the system. In fact we can consider the following definition
for the system power:
γ sible to determine the set (k) of ACL packets that are gener-
PSystem = , (3)
D (k)
where γ is equal to the sum of and γDW i , with i = 1, . . . , N.
The choice of D leaves some degree of freedom as different
definitions for D may highlight different aspects of the sys-
tem. The simplest choice for D is to consider the average
system response time τ . It is worth noting that τ corresponds
to the average end-to-end delay experienced by IP packets. In
this case, equation (3) can be written as:
N
[γUPi + γDW i ]
P1 = i=1 .
τ Pr{τIP = m}, i.e., the probability mass function of τIP , for
P1 provides a criteria to analyze the system performance
from the user standpoint as the delay added to its data-packet
stream is the most important figure for the single user. More-
over, we want to evaluate the effectiveness of scheduling al-
gorithms that operate at the Baseband layer. So we introduce
a second definition for the power. In this second case D is the
weighted sum of MACUPi and MACDW i , where the weights
are the fraction of total bandwidth used by each link, that is:
1

N
D= [γUPi MACUPi + γDW i MACDW i ]. (4)
γ
i=1
it should avoid treating unfairly slaves with small amounts of
traffic with respect to heavily-loaded slaves.
3.4. Numerical results
The performance evaluation of Round Robin polling algo-
rithm has been carried out by simulations in which we assume
an ideal channel with no transmission errors. This assump-
tion has been done in order to analyze the protocol in ideal
conditions and to highlight the constraints due to the adopted
transmission scheme. Within each simulation we have uti-
lized the DH type for ACL packets, and the buffer sizes are
BS = 15000 bytes and BM = 15000 bytes. The use of buffers
with a finite size is necessary to perform correct simulations
of steady state even in overload conditions.
By exploiting (1), given an IP packet of length k, it is pos-
ated by its segmentation. We indicate with Nx(k) the number of
(k) packets of type DHx , and with τIP the time (expressed
as a number of time slots) the channel is used to transmit an
(k)
IP packet. Hence, τIP has the following expression:
(k)


τIP = x · Nx(k) .
x∈{1,3,5}
Finally, to determine the number of time slots to transmit
an IP packet, τIP , we need to select the IP packet-length
distribution. For example, in figure 5 we have plotted the
an IP packet-length uniformly distributed in the range from
500to 1500 bytes. The mean value of τIP , say τ̄IP , is equal
to m m Pr{τIP = m}. In the considered case, we have
τ̄IP = 15.998 time slots.
The maximum values of aggregate throughput, γMAX , and
MAC (i.e., average aggregate MAC delay) are obviously ob-
tained in the asymptotic condition, i.e., when there is always a
queued packet in the master and in the slaves local queues. In
this case no NULL packets are sent and the channel is com-
pletely loaded.

It is worth noting that (4) is equivalent to the aggregate MAC

delay, that is the mean value of MACUPi and MACDW i , here-
after called MAC. By exploiting (4), we can write equation (3)
as:
γ2
P2 = N .
i=1 [PUPi (MACUPi ) + PDW i (MACDW i )2 ]
2

P2 highlights that it is not desirable to increase the system

power by increasing the power of a single link and deterio-
rating excessively the MAC delay of the others. However,
it is worth noting that polling a slave with an empty trans-
mission queue does not decrease its MAC delay but cause
a waste of bandwidth. Hence, a policy more efficient than
the Round Robin polling algorithm would be one that avoids
polling slaves with empty transmission queues. Furthermore, Figure 5. τIP probability mass function.
124 BRUNO, CONTI AND GREGORI

In asymptotic conditions the channel is continuously used

by the stations to transmit the IP-packet fragments. On aver-
age, a station uses the channel for a τ̄IP · ts time (ts being the
slot duration) to transmit a complete IP packet. Hence, the
maximum aggregate throughput is equal to:
E[IP packet length]
γMAX = = 800.1 kbps.
τ̄IP · ts
The maximum value of MAC is defined by the following
lemma.

Lemma 1. In a Bluetooth piconet with N active slaves and a

Round Robin scheduling algorithm, by denoting with τ̄IP · ts
the average time the channel is used for an IP packet trans-
mission time, the maximum value of MAC is

MACMAX = 2 × N × τ̄IP · ts . Figure 6. Throughput performance of a single piconet.

Proof. The maximum value of MAC is obtained when all slaves E[Fi ] = E[F ] where E[F ] is the average length of a
slaves and the master queues always contain at least a packet fragment. Hence,
ready for transmission. In this case, given a tagged queue,
say i, and by denoting with MACi,m the MAC delay of the MACi = 2N · E[F ] · E[]. (L.6)
mth IP packet transmitted from queue i, and with MACi the Finally, by applying the same type of reasoning we used to
average MAC delay of queue i, it follows that derive (L.4) from (L.1) we can show that E[F ]·E[] = τ̄IP ·ts
MACi,1 + MACi,2 + · · · + MACi,h and hence the lemma is proved. 
MAC = MACi = lim .
h→∞ h
(L.1) By applying, the Lemma 1 in our case study with N = 6
Now we note that active slaves we have:

MACi,m = C1(i,m) + C2(i,m) + · · · + C

(i,m)
, (L.2) MACMAX = 2 × N × τ̄IP × ts = 119, 9625 ms.
m

where m is the number of fragments required to transmit the It is worth noting that these analytical results derived for a
mth IP packet, and Cj(i,m) is the polling cycle during which is completely loaded piconet (i.e., a piconet where there is al-
transmitted the j th fragment of the mth IP packet. Hence, ways at least a packet waiting to be transmitted in all the
 slaves’ and master’s queues) are confirmed by the following
MACi = lim C1(i,1) + C2(i,1) + · · · + C (i,1)
1
+ C1(i,2) simulative analysis.
h→∞ In figure 6 we plot the aggregate throughput that is achiev-
(i,2) (i,2) (i,h)
+ C2 + · · · + C2 + · · · + C1 able in the symmetric and asymmetric case. It is known that

(i,h) 
the Round Robin polling algorithm is the best policy when the
+ C2(i,h) + · · · + C h
h . (L.3) system is symmetric and completely loaded, and the plotted
curves confirm that. However, it is also clear that the Round
Let us now divide the numerator and the denominator of (L.3) Robin polling algorithm is very inefficient under asymmet-
by n, where n is the number of polling cycles required to ric condition because the master continues to poll slaves that
transmit the h IP packets. Hence, (L.3) becomes have no traffic to send, and this behavior implies a bandwidth
MACi = E[C] · E[], (L.4) wastage. In the asymmetric scenario the Slave1 local queue
saturates, i.e., there are packet losses due to buffer overflow,
where E[C] is the average length of a polling cycle and E[] when the offered load is equal to 400 kbps. By increasing the
is the average number of fragments in which an IP packet is OL beyond 400 kbps, the throughput performance increases
segmented, or, in other words, the average number of polling very slowly.
cycles required to transmit an IP packet. In figures 7(a) and (b) we plot the MAC measured in

2N  the symmetric and asymmetric case, respectively. Moreover

in figure 7(b) we plot also the MACUP for Slave1 (heavily
E[C] = E Fi = 2N · E[Fi ], (L.5)
loaded) and Slave2 (lightly loaded). We can notice that in
i=1
the symmetric case, when the OL is equal to the maximum
where Fi is the length of a fragment transmitted from queue i throughput, the MAC reaches its maximum value. It could
and 2N is the number of queues in our piconet with N active appear erroneous that the MAC decreases when the piconet is
slaves. As the IP packet-length distribution is the same for all heavily loaded, but this is a side effect of the finite buffer size.
BLUETOOTH
(a)
(b)
Figure 7. MAC delay performance of a piconet (a) symmetric case and
(b) asymmetric case.
In fact, when the piconet is heavy loaded the local queues are
saturated and the probability to discard long packets is higher
than the probability to discard short packets. This means that
the average length of queued packets decreases, hence even
the MAC decreases (in the symmetric case, with an OL that
is two times γMAX , we have measured an average length of
queued packets equal to 850 bytes).
In the asymmetric case the MAC curve shows a flat slope
for OL grater than 400 kbps because the throughput in-
creases very slowly. Moreover, the MACUP1 is lower than the
MACUP2 . This is due to the fact that, during the transmission
of an IP packet generated in a lightly loaded slave, it is high
the probability to have a contemporary transmission of an IP
packet generated in the heavily loaded slave. On the other
hand, during the transmission of an IP packet generated in
heavily loaded slave, the probability to have a contemporary
transmission on an IP packet generated in a lightly loaded
slave is very small. The average aggregate MAC, MAC, is
lower than MACUP1 and MACUP2 . This happens because
MAC is computed taking into consideration also the transmis-
sions on the downlink and MAC delays in the downlink are
lower than the MAC delays in the uplink.
In figures 8(a) and (b) we plot the average end-to-end de-
lay measured in the symmetric and asymmetric case, respec-
125
(a)
(b)
Figure 8. End-to-end delay performance in a piconet (a) symmetric case and
(b) asymmetric case.
tively. Moreover, in figure 8(b) we plot also the end-to-end
delay for IP packets generated by Slave1 (heavily loaded) and
Slave2 (lightly loaded). We can notice that the end-to-end
delay increases together with the offered load, due to the in-
crease in the number of queued packets. The end-to-end delay
for Slave1 is significantly higher than the one for Slave2 be-
cause in the Slave2 local queue there are few packets than in
the Slave1 local queue.
To summarize this set of numerical results in figures 9(a)
and (b) we plot P1 and P2 , respectively. The P1 curves present
a maximum that corresponds to the optimal operating point
from the P1 -index standpoint. We can observe that in the
asymmetric case the optimal condition is reached for a lower
offered load than the symmetric case. Moreover, the P1 curve
in the asymmetric case is above the P1 curve in symmetric
case only for heavily loaded piconet.
The P2 curves show a different behavior. In particular,
we can observe that in the symmetric case a maximum for
the power still exists, and it is reached for an OL equal to
400 kbps, whereas in the asymmetric case the P2 curve is
a growing function. We believe that this behavior is due to
the inefficiency of Round Robin algorithm for the asymmet-
ric scenario that implies piconet is very far from optimum op-
erating point with respect to the P2 -index standpoint. This
126
(a)
(b)
Figure 9. Power performance of a piconet (a) P1 vs. offered load and (b) P2
vs. offered load.
hypothesis will be better justified when a more efficient algo-
rithm will be presented in the next section. Finally, we can
observe the P2 curve in the asymmetric case is always above
the P2 curve in the symmetric case, due to the low MAC delay
experienced in the former case.
4. The Efficient Double-Cycle (EDC) algorithm
The Efficient Double-Cycle (EDC) algorithm is based upon
two main ideas: first of all it is necessary to avoid NULL
transmissions towards and from the slaves; furthermore the
fairness typical of a Round Robin scheme should be pre-
served. These targets can be accomplished if the selection
of the slave to be polled takes into consideration the master
knowledge of local queues occupancy. It is worth noting that
the master has a deterministic knowledge of the state of its
local queues, i.e., the queues containing the ongoing traffic
towards the slaves. On the other direction (i.e., traffic in-
coming from the slaves), we only assume that the master has
a probabilistic knowledge based on the feedback the master
gets when polling the slaves. Therefore, the master can only
estimate the probability that a slave will send a NULL packet
by exploiting the knowledge of the slave behavior in the pre-
vious polling cycles.
BRUNO, CONTI AND GREGORI
An additional problem to have a fair and efficient schedul-
ing in Bluetooth is due to the coupling between the transmis-
sion in uplink and downlink (i.e., a master to slave transmis-
sion implies also a polling of the slave and hence a – possi-
bly NULL – slave to master transmission). Therefore, it is
not possible to remove a slave from the polling cycle without
blocking at the same time the master transmissions towards
this slave. To introduce a (partial) decoupling in the schedul-
ing of the transmissions in uplink and downlink we introduce
the idea of a double polling cycle: an uplink polling cycle,
hereafter called CycleUP , and a downlink polling cycle, here-
after called CycleDW . During both of these cycles the master
selects a subset of slaves that are eligible for the polling. For
the sake of brevity we will refer to the subset of eligible slaves
selected during a CycleUP as E(Up), and to the subset of el-
igible slaves selected during a CycleDW as E(Dw). E(Dw) is
calculated considering only the state of master local queues,
i.e., the ongoing traffic loads, whereas E(Up) is calculated
considering only the estimated slaves’ activity, i.e., the ingo-
ing traffic loads. The distinction between polling rules for the
downlink, and polling rules for the uplink permits to preserve
a separate fairness.
4.1. EDC specification
Firstly, let us introduce the variables used by the EDC algo-
rithm. The outcome of our polling algorithm is the next slave
to be polled, i.e., its AM_ADDR (in the EDC specification it
is referred as next). Because there is a double cycle, we have
a nextUp calculated during a CycleUP , and a nextDw calcu-
lated during the CycleDW . A polling interval ci , and a polling
window wi are associated to each Si . These variables are used
to estimate the slave activity, and to implement a truncated
binary exponential backoff mechanism to control the slaves
polling frequency during a CycleUP , as explained afterwards.
The variable Cycle_End indicates if the previous cycle is
completed, i.e., if all the slaves which belong to E(Up) or
E(Dw) have been polled. The variable Curr_Cycle stores
the type of cycle the master is executing.
One of the most important task that is accomplished by
the master at the beginning of each cycle is the updating of
E(Up) and E(Dw) according to its most up-to-date knowledge
about traffic loads. E(Up) is constituted by all slaves Si that
have ci = 0 at the beginning of a CycleUP . Because the
ci are decreased before the beginning of each CycleUP , if
Si has a ci = n, then n · CycleUP must elapse before Si is
polled during a CycleUP . E(Dw) is constituted by all slaves Si
to which the master has traffic to send at the beginning of a
CycleDW , i.e., slaves corresponding to the not-empty master
local queues.
In the rest of this section we provide a pseudo-code de-
scription of the EDC algorithm, and we comment it.
At the beginning of each new master transmission, accord-
ing to the piconet timing, the master executes the following
actions:
BLUETOOTH 127

1. begin In the lines 21–44, EDC prepares a transmission for a

2. if (Cycle_End==FALSE) then CycleDW . If E(Dw) is an empty set [line 22], then EDC de-
3. if (Curr_Cyle==Up) creases the polling interval variables, it updates E(Up) and a
then goto Up_Cycle; new CycleUP begins [lines 24–27]. This behavior corresponds
4. else goto Dw_Cycle;
to have a CycleDW with null duration.
5. if (Cycle_End==TRUE) then
All the Si that belongs to E(Dw) are polled in a cyclic or-
6. if (Curr_Cyle==Up) then
7. begin der (i.e., we adopt a Round Robin policy for the E(Dw) set).
8. Cycle_End = FALSE; nextDw is incremented [line 42] until EDC finds a slave el-
9. Curr_Cycle = Dw; igible, and when this happens nextDw is incremented again
10. <update E(Dw)>; [line 34]. After a slave has been polled it is extracted from
11. goto Dw_Cycle; E(Dw) [line 32]. Therefore a CycleDW is completed only
12. end when E(Dw) becomes empty [lines 35–39].
13. else
14. begin
45. Up_Cycle:
15. for (i = 1; i
N; i++)
46. if (E(Up)=={0}) then
do ci = max{0, (ci - 1)};
47. if (E(Dw)=={0}) then goto Empty_Cycle;
16. Cycle_End = FALSE;
48. else
17. Curr_Cycle = Up;
49. begin
18. <update E(Up)>;
50. <update E(Dw)>;
19. goto Up_Cycle;
51. Curr_Cyle = Dw;
20. end
52. goto Dw_Cycle;
53. end
If the cycle is not finished EDC determines if the next 54. Search_Up:
transmission belongs to a CycleUP or a CycleDW [lines 2–4]. 55. if (SnextUp ∈ E(Up)) then
If the previous cycle is finished and it was a CycleUP , then 56. begin
EDC updates E(Dw) and a new CycleDW begins [lines 6–11]. 57. E(Up) = E(Up) - SnextUp ;
Otherwise, if the previous cycle is finished and it was a
58. next = nextUp;
CycleDW , then EDC decreases the polling interval variables
59. nextUp = nextUp+1;
[line 15], it updates E(Up) and a new CycleUP begins [lines
60. if (E(Up)=={0}) then
16–19];
61. begin
62. nextUp = 1;
21. Dw_Cycle: 63. Cycle_End = TRUE;
22. if (E(Dw)=={0}) then 64. end
23. begin 65. exit
24. for (i = 1; i
N; i++) 66. end
do ci = max{0, (ci - 1)}; 67. else nextUp = netxUp+1;
25. Curr_Cycle = Up; 68. goto Search_Up;
26. <update E(Up)>; 69. exit
27. goto Up_Cycle;
28. end
29. Search_Dw: In the lines 45–69, EDC prepares a transmission for a
30. if (SnextDw ∈ E(Dw)) then CycleUP . If E(Up) and E(Dw) are empty sets [lines 46–47]
31. begin EDC has no information to discriminate a slave from the oth-
32. E(Dw) = E(Dw) - SnextDw ; ers, then EDC jumps to the Empty_Cycle, where a strict
33. next = nextDw; Round Robin polling rule is applied. If only E(Up) is an
34. nextDw = nextDw+1; empty set then E(Dw) is updated and a new CycleDW begins
35. if (E(Dw)=={0}) then [lines 50–52]. This behavior corresponds to have a CycleUP
36. begin with null duration.
37. nextDw = 1;
All the Si that belong to E(Up) are polled in a cyclic or-
38. Cycle_End = TRUE;
der (i.e., we adopt a Round Robin policy for the E(Up) set).
39. end
40. exit In fact, nextUp is incremented [line 67] until EDC finds a
41. end slave eligible, and when this happens nextUp is incremented
42. else nextDW = nextDw+1; again [line 59]. After a slave has been polled it is extracted
43. goto Search_Dw; from E(Up) [line 57]. Therefore, a CycleUP is completed only
44. exit when E(Up) becomes empty [lines 61–64].
128 BRUNO, CONTI AND GREGORI

70. Empty_Cycle: 4.2. Numerical comparison between Round Robin and EDC
71. next = (next + 1)MOD N ;
72. Cycle_End = TRUE; In this section we report the numerical results obtained with
73 exit EDC in the same set of simulations performed in section 3.4.
By exploiting these numerical results we will point out the
The master polls the next slave [line 71]. Cycle_End is performance enhancement achieved by EDC, with respect to
settled TRUE [line 72] in order to execute an update of E(Dw) the performance indices introduced in section 3.3. During all
and E(Up) at the beginning of next cycle. simulations we have assumed wMAX = 32.
At the end of each Sk ’s packet reception, the master up- In figures 10(a) and (b) we plot the aggregate throughput
dates its polling interval ck and its polling window wk with achieved by the Round Robin algorithm and EDC in the sym-
the following procedure: metric and asymmetric case, respectively. We can observe
that in the symmetric case EDC behaves exactly as the Round
74. if (<payload>==NULL) Robin algorithm from a throughput standpoint. Instead in the
then wk = min{wMAX , (2 × wk )}; asymmetric case EDC is much better than the Round Robin
75. else wk = 1; algorithm because it reduces the number of NULL messages
76. ck = wk ; received by the master from the lightly loaded slaves.
77. end In figures 11(a) and (b) we plot the MAC achieved by the
Round Robin algorithm and EDC in the symmetric and asym-
If Sk sends a packet with a null payload, then its polling win- metric case, respectively. In the symmetric case, EDC be-
dow wk is doubled till a maximum value wMAX is reached; haves exactly as the Round Robin algorithm only if the pi-
otherwise wk is settled to be 1. The polling interval ck takes conet is heavy loaded, because in this case with probability
the wk value. one we always have a packet in the master and slaves’ local

(a) (b)
Figure 10. Aggregate throughput comparison (a) symmetric case and (b) asymmetric case.

(a) (b)
Figure 11. Aggregate MAC delay comparison (a) symmetric case and (b) asymmetric case.
BLUETOOTH
queues. When the piconet is lightly loaded EDC overcomes
the Round Robin algorithm due to the dynamic adaptation
of the slaves’ polling-frequency to the slaves activity. In the
asymmetric case, the EDC efficiency is evident. We can ob-
serve a halving of the aggregate MAC delay measured in the
piconet.
The dynamic behavior of a polling system is quite com-
plex, and to better understand it in figures 12(a) and (b) we
plot the MAC delay measured in the uplink and downlink for
the Slave1 (heavily loaded) and Slave2 (lightly loaded), re-
spectively. It is worth noting that the station MAC delay can
be viewed as the speed at which the master serves the slave’s
local transmission queue.
From figure 12(a) we observe that EDC is able to adapt
to the different rates of the slaves’ packet generators. On av-
erage, Slave1 produces a traffic load nine times greater than
Slave2, hence EDC makes a significant difference between
the polling frequency allotted to slaves in the uplink direc-
tion. As the ongoing traffic from the master is distributed
quite uniformly among all slaves, EDC makes no significant
(a)
Figure 12. Slaves’ MAC delay comparison (a) uplink and (b) downlink.
(a)
Figure 13. End-to-end delay comparison (a) symmetric case and (b) asymmetric case.
129
differences between the polling frequency of the slaves in the
downlink direction, how we can observe in figure 12(b). It is
worth noting that MACDW i is halved for all slaves.
The increase in the MAC delay experienced by the traffic
generated in the lightly loaded slaves does not imply a de-
crease in the transmission service perceived by the users. This
is clearly shown by the performance figures based on the end-
to-end delay. In particular in figures 13(a) and (b) we plot
the average end-to-end delay achieved by the Round Robin
algorithm and EDC in the symmetric and asymmetric case,
respectively. We have adopted a logarithmic scale for the y-
axis to highlight the improvement achieved with EDC both in
the lightly loaded piconet (i.e., with small end-to-end delay)
and in the heavily loaded piconet (i.e., with high end-to-end
delay). These results point out that the improvement in the
aggregate throughput is not achieved by means of worsening
the delay performances perceived by users, but by using more
efficiently the channel bandwidth. We can observe that, in
the symmetric case, the end-to-end delay achieved with EDC
is lower than the one achieved with the Round Robin algo-
(b)
(b)
130
(a)
Figure 14. Power performance comparison (a) P1 vs. offered load and (b) P2 vs. offered load.
rithm even when the piconet is heavily loaded. We can ex-
plain this phenomenon by considering the probability to have
an empty local queue in the master. In particular, when OL is
equal to 120% of γMAX , by applying the Round Robin and the
EDC algorithms, the master local queue reserved for trans-
missions towards Slave1 is empty with probability 0.06394
and 0.10017, respectively.
We summarize this wide set of results by considering the
power indices. In figures 14(a) and (b) we plot P1 and P2 ,
respectively. We observe that, by adopting EDC, when OL is
lower then γMAX , the P1 curves for the symmetric and asym-
metric scenarios are overlapping. This means that the trans-
mission service offered by the MAC layer it is the same, no
matter of the traffic distribution. Furthermore, the maximum
power achievable with EDC is significantly higher than the
one achievable with the Round Robin algorithm in both sce-
narios, due to the better resource utilization granted by EDC.
Similar considerations arise from the analysis of P2 curves.
In particular, it is worth highlighting that with EDC also in
the asymmetric case it is possible to find a maximum for the
P2 function.
5. Conclusions
The paper, after providing a tutorial description of the Blue-
tooth technology has studied the performance evaluation of
the Baseband transmission procedures. In particular we have
analyzed the efficiency of a Round Robin scheme for the
Medium Access Control protocol. This analysis has clearly
shown the ineffectiveness of this scheme to face the require-
ments of a WPAN highly dynamic scenario. Therefore, we
have proposed a new scheduling algorithm, named EDC that
exploits master knowledge of local queues’ occupancy to
avoid NULL packet transmission. EDC employs two polling
cycles with different polling rules in such a way to guar-
antee a separate and fair treatment of uplink and downlink
connections. At the same time, when compared to Round
Robin, EDC increases for aggregate network throughput and
decreases the (MAC and End-to-End) delays.
BRUNO, CONTI AND GREGORI
(b)
Results obtained are very promising but several research
issues need to be further investigated. Specifically we are
currently working in two main directions: optimal scheduler,
TCP over Bluetooth.
In this paper we have shown that EDC is a promising di-
rection for improving the efficiency of a Bluetooth network.
However, EDC has been designed by adopting only a heuris-
tic criterion, i.e., reducing the number of polling attempts that
do not produce useful transmissions. What we are now look-
ing for is a criterion that formally identifies the optimal per-
formance that can be achieved for a given traffic characteriza-
tion. More precisely we are working on analytical models to
identify, given a traffic characterization, the polling order that
maximizes the power index. With this criterion we will try to
construct a scheduler that mimics the behavior of the optimal
one.
The performance study presented in this paper has been
carried out without taking into consideration the impact of the
Internet protocols on the traffic characteristics. Specifically
we have assumed that the packet size corresponds to a typical
IP packet but we have not taken into consideration the impact
of TCP control messages (ACK), and the impact of TCP flow
and congestion control mechanisms on the spacing between
IP packets. This choice was done to study in a general case the
properties of the scheduling algorithms. It is left for further
studies the performance of TCP when Bluetooth is the access
technology to Internet.
References
[1] M. Scott Corson, J.P. Macker and G.H. Cirincione, Internet-based mo-
bile ad hoc networking, IEEE Internet Computing (July–August 1999)
63–70.
[2] Specification of the Bluetooth System, Version 1.0B, December 1999.
[3] B.A. Miller and C. Bisdikian, Bluetooth Revealed (Prentice Hall,
2000).
[4] J. Muller, Bluetooth Demystified (McGraw-Hill, 2000).
[5] J.L. Hammond and P.J.P. O’Reilly, Performance Analysis of Local
Computer Networks (Addison-Wesley Publishing Company, 1988).
[6] W. Stallings, Local & Metropolitan Area Networks (Prentice Hall,
1996).
BLUETOOTH
[7] J.F. Kurose, M. Schwartz and Y. Yemini, Multiple access protocols and
time constraint communications, ACM Computing Surveys 16 (1984)
43–70.
[8] M. Conti, E. Gregori and L. Lenzini, Metropolitan Area Networks,
Springer Verlag Limited Series on Telecommunication Networks and
Computer Systems (Springer, 1997).
[9] L. Kleinrock, Power and deterministic rules of thumb for probabilistic
problems in computer communications, IEEE Transactions on Infor-
mation Theory (1979).
[10] J.C. Haartsen and S. Zurbes, Bluetooth voice and data performance
in 802.11 DS WLAN environment, Technical Report, Ericsson, May
1999.
[11] S. Galli, K.D. Wong, B.J. Koshy and M. Barton, Bluetooth technology:
Link performance and networking issues, in: Proc. European Wireless
2000, Dresden, Germany, September 2000.
[12] S. Zurbes, Consideration on link and system throughput of Bluetooth
networks, in: Proc. PIMRC 2000 (London, 2000) pp. 1315–1319.
[13] N. Johansson, U. Korner and P. Johansson, Wireless ad-hoc networking
with Bluetooth, in: Proc. Proceedings of Personal Wireless Communi-
cations, Copenhagen, March 1999.
[14] N. Johansson, U. Korner and P. Johansson, Performance evaluation of
scheduling algorithm for Bluetooth, in: Proc. IFIP Broadband Com-
munications, Hong Kong, November 1999.
[15] N. Johansson, M. Kihl and U. Korner, TCP/IP over Bluetooth wireless
ad-hoc network, in: Proc. IFIP Networking 2000, Paris (1999) pp. 799–
810.
[16] M. Gerla, P. Johansson, R. Kapoor and F. Vatalaro, Bluetooth: “Last
Meter” technology for Nomadic wireless internetting, in: Proc. 12th
Tyrhennian International Workshop on Digital Communications.
Raffaele Bruno has received his Laurea degree in
telecommunications engineering from the University
of Pisa, Italy, in 1999. He is currently working to-
ward his Ph.D. degree at the CNUCE Department in
the National Council of Research, Pisa, Italy. His
research interests are in the areas of wireless and
mobile networks with emphasis on efficient wireless
MAC protocols, scheduling algorithms for Internet
traffic integration and QoS.
E-mail: Raffaele.Bruno@guest.cnuce.cnr.it
View publication stats
131
Marco Conti received the Laurea degree in com-
puter science from the University of Pisa, Italy, in
1987. In 1987 he joined the Networks and Dis-
tributed Systems department of CNUCE, an insti-
tute of the Italian National Research Council (CNR)
where is currently a senior researcher. He has writ-
ten over 80 research papers in the areas of design,
modeling and performance evaluation of computer-
network architectures and protocols. His current
research interests include Internet architecture and
protocols, wireless networks, mobile computing,
multimedia systems, and QoS in packet switching
networks. He is co-author of the book “Metropol-
itan Area Networks” (Springer, London 1997). He
was the coordinator of two minitracks (“Mobile ad-
hoc networking” and “QoS in Web Services”) at the
HICSS-34 conference. He is serving as a Co-Guest
Editor for IEEE Transactions on Computers (special
issue on “Quality of Service issues in Internet Web
Services”) ACM Mobile Networks & Applications
Journal (MONET) (special issue on “Mobile Ad-hoc
Networks”) and the Cluster Computing Journal (spe-
cial issue on “Mobile Ad-hoc Networking”). He is a
member of the IEEE and IFIP WG 6.3 and WG 6.8.
E-mail: Marco.Conti@cnuce.cnr.it
Enrico Gregori received the Laurea in electronic engineering from the Uni-
versity of Pisa in 1980. He joined CNUCE, an institute of the Italian National
Research Council (CNR) in 1981. He is currently a CNR research director.
In 1986 he held a visiting position in the IBM research center in Zurich work-
ing on network software engineering and on heterogeneous networking. He
has contributed to several national and international projects on computer
networking. He has authored a large number of papers in the area of com-
puter networks and has published in international journals and conference
proceedings. His current research interests include: wireless access to Inter-
net, wireless LANs, quality of service in packet-switching networks, energy
saving protocols, evolution of TCP/IP protocols. He is on the editorial board
of the Cluster Computing Journal. He is a member of the IEEE.
E-mail: Enrico.Gregori@cnuce.cnr.it