Improving simultaneous voice and data performance in Bluetooth systems

Abstract

In the Bluetooth system, isochronous applications, such as voice and audio, are carried by synchronous connection oriented (SCO) links. SCO packets are regularly scheduled every two, four, or six time slots and enjoy preemptive priority over data-bearing asynchronous connection-less (ACL) packets. The residual bandwidth available to simultaneous data services is often insufficient for many types of applications, even under perfect channel conditions. We introduce a novel methodology where isochronous audio traffic is carried over ACL links to obtain higher simultaneous data throughputs while strictly adhering to the 64 Kbps isochronous service quality guaranteed by SCO links. Simulation results are presented for a variety of channel conditions verifying that this technique improves both the throughput for data services and the quality of voice services.

Full text

Page 1

Abstract— In the Bluetooth system, isochronous applications,
such as voice and audio, are carried by Synchronous Connection
Oriented (SCO) links. SCO packets are regularly scheduled every
two, four, or six time slots and enjoy preemptive priority over
data-bearing Asynchronous Connection-Less (ACL) packets. The
residual bandwidth available to simultaneous data services is often
insufficient for many types of applications, even under perfect
channel conditions. In this paper, we introduce a novel
methodology where isochronous audio traffic is carried over ACL
links to obtain higher simultaneous data throughputs while
strictly adhering to the 64 Kbps isochronous service quality
guaranteed by SCO links. Simulation results are presented for a
variety of channel conditions verifying that this technique
improves both the throughput for data services and the quality of
voice services.

INTRODUCTION
Bluetooth enabled devices exchange data and voice with one
another over short distances. Application scenarios for
Bluetooth include data applications such as file transfers and
local area network (LAN) access, as well as audio applications
such as streaming music and voice calls, like those defined in
the Headset and Cordless Telephone Profiles [1] of the
Bluetooth specification [2].
Traditional support for isochronous audio services, such as
voice or music delivery, in Bluetooth exacts a heavy toll on the
bandwidth available for simultaneous data services. For
example, the maximal user throughput supported by Bluetooth
is 723.2 Kbps. However, using traditional audio delivery
methods over an ideal loss-less channel, the maximal user
throughput available to a data service operating simultaneously
with a 64 Kbps voice link is only 390.4 Kbps, as will be shown
later. This means that supporting one voice link, which
represents less than 9% of the total available bandwidth,
reduces the remaining available link capacity by over 46%.
This indicates a large inefficiency and motivates the search for
more efficient ways of handling simultaneous voice and data
services in realistic Bluetooth channels.
Earlier work has focused primarily on the effects of
scheduling while considering pure data applications without
addressing isochronous requirements [3][4]. In this paper, we
introduce the Voice over Asynchronous Connectionless Links
(VoACL) methodology that maintains isochronous quality
requirements, improves audio fidelity, and most importantly,
improves the throughput available to simultaneous data
services.
The paper is organized as follows; Section B provides an
overview of Bluetooth, Sections C and D introduce VoACL
and the VoACL algorithms, Section E describes the simulation

1 This work was supported by Toshiba America Research Inc. (TARI) and
the authors would like to thank TARI for their contributions and
encouragement.
I.
environment, Section F presents performance results, and
Section G concludes the paper.

THE BLUETOOTH SYSTEM II.
The Bluetooth system, architecture, and protocols are
defined in detail in [2] and expanded on in [5] and [6]. A brief
overview is provided here. Upper layer data is passed down to
the baseband and radio layers where it is placed in packets and
transmitted over the air interface. Information is modulated at
a rate of 1 Mbps and transmitted in one of 79 1-MHz channels
in the 2.402-2.480 GHz band. Signals are frequency hopped
through the 79 channels at the rate of 1600 hops per second
with one hop per time slot; making the length of each time slot
625 µsecs.
Bluetooth technology is based on a master-slave concept
where the master device controls data transmissions through a
polling procedure. The master is defined as the device that
initiates the connection. A collection of slave devices
associated with a single master device is referred to as a
piconet.
The master dictates packet transmissions within a piconet
according to a time-slot process. The channel is divided into
time slots that are numbered according to an internal clock
running on the master. A time division duplex (TDD) scheme
is used where the master and slaves alternatively transmit
packets, where even numbered time slots are reserved for
master-slave transmissions, while odd numbered time slots are
reserved for slave-master transmissions.
Bluetooth uses single-slot voice packets and multi-slot data
packets that can occupy one, three, or five time slots. During
the transmission of a packet the frequency remains constant; so
the frequency hop rate equals the packet transmission rate.
There are two classes of link-level connections in Bluetooth,
each with their own class of allowable baseband packets. Next
we describe each of these link-level connection types.

Synchronous Connection Oriented (SCO) Links
Synchronous Connection Oriented (SCO) links are intended
to carry isochronous voice traffic and require that a SCO-type
packet occupy every two, four, or six Bluetooth time slots.
There are three types of SCO packets defined thus far in the
Bluetooth specification namely, HV1, HV2, and HV3 packets2,
which carry 10, 20, and 30 bytes of user information
respectively. All SCO packet types occupy one slot length.
These values and slot arrangements where chosen to meet an
isochronous quality target of 64 Kbps speech. It should be
noted that using an HV1 packet type, which requires a

2 Bluetooth also specifies a dual voice/data packet, called a DV packet,
which carries at most 10 bytes of user data along with 10 bytes of voice
information. We do not consider DV packets in this work.
Improving Simultaneous Voice and Data Performance in Bluetooth
Systems
David Famolari and Farooq Anjum
Telcordia Technologies1
445 South St, Morristown, NJ 07960

Page 2

transmission every second Bluetooth time slot, precludes the
use of any other services in that piconet.
Three features distinguish SCO links. First, SCO packets
enjoy preemptive priority over all other Bluetooth packets used
to convey user information. This feature guarantees SCO links
a minimum level of access to the channel. Second, SCO
packets do not contain a CRC value, are not acknowledged, are
never retransmitted, and are never discarded. Packets that are
corrupted by channel errors are simply played out as they are
received; so bit-errors in SCO packets result in degraded voice
quality. Lastly, SCO links do not follow the normal master-
slave polling scheme. A slave participating in a SCO
connection does not require a poll by the master device before
transmitting a SCO packet.

Asynchronous Connection-Less (ACL) Links
The second class of link-level connections in Bluetooth is
Asynchronous Connection-Less (ACL) links. These links
employ packets that occupy one, three, and five time slots.
ACL packets come in two varieties, a high-rate variety that
employs no Forward Error Control (FEC) and a low-rate
variety that sacrifices some user information for error
resiliency by employing a 2/3 FEC code in its payload. The
high-rate ACL packets are referred to as DH1, DH3, and DH5
packets, distinguished by the number of slots they occupy, and
carry 27, 183, and 339 bytes of user payload information
respectively. The low-rate ACL packets are referred to as
DM1, DM3, and DM5 packets, which carry 17, 121, and 224
bytes of user payload respectively.
ACL connections are not regularly scheduled and are
governed by explicit notification through the master device.
Slave devices can only transmit ACL packets when they have
been specifically addressed in the preceding master-slave
transmission slot.
Each ACL packet contains a 16-bit CRC code for error
detection. ACL packets require explicit acknowledgement
from the receiver and will be retransmitted under a stop-and-
wait ARQ scheme until they are successfully delivered or reach
a system-defined time out value.
The simultaneous operation of SCO links with ACL links
limits the throughput available to data applications. This is
because SCO packets enjoy a preemptive priority over ACL
packets and are guaranteed access to every second, fourth, or
sixth time slot. An active SCO link precludes the use of five-
slot packets for data-bearing ACL links, leaving only the less
efficient one- and three-slot packets. This is an unfavorable
situation with respect to active data links. Even using the most
data friendly HV3 SCO packets and considering an ideal loss-
less channel, the maximal bandwidth that can be achieved
occurs when one DH3 packet is sent between consecutive HV3
packets. This results in transferring 183 payload bytes every
six Bluetooth timeslots, or 3.75 ms, for a total bit rate of 390.4
Kbps. This is a drop-off of more than 46% from the maximal
Bluetooth link rates of 723.2 Kbps and motivates more
efficient techniques for the simultaneous support of data and
voice.

III. VOACL
The VoACL technique improves voice quality while
allowing greater simultaneous bit rates, by intelligent
scheduling of voice-bearing packets. This flexibility is made
possible by the use of ACL links as a voice bearer.
Bluetooth typically uses 64 Kbps log PCM voice coding
with either A-law or µ-law compression. It maintains 64 Kbps
by transmitting 30 bytes every 3.75 ms. VoACL maintains the
required 64 kbps by extending the 3.75 ms time horizon to 20
ms and sending 160 voice bytes within that time. A 20 ms
frame is a common frame size found in other wireless voice
systems such as IS-95 cellular CDMA based systems [7]. In
the Bluetooth technology, 20 ms corresponds to exactly 32
time slots. We refer to these 32 slots as a superframe.
The goal of VoACL is to use ACL packets to convey voice
information at the start of every superframe. ACL packets can
carry more information and incur less overhead penalties than
SCO packets. VoACL then uses the remainder of the
superframe to transmit user data. This frees the piconet link
from the preemptive priority of SCO packets and allows
simultaneous data services greater access to the medium, which
increases data throughputs. Furthermore, voice information
sent in this fashion is protected by a CRC code and can be
retransmitted in the event of channel errors while maintaining
the strict isochronous delivery requirements. Under a SCO
voice delivery scheme, voice information is never retransmitted
and is always delivered to the audio device regardless of bit
errors. However, with VoACL a balance can be struck
between offering good quality voice and high throughputs by
employing retransmission limits.
It should be noted that employing VoACL requires slight
buffering at the receiver that will add to the overall delay of the
system.

IV. VOACL ALGORITHMS

The VoACL algorithm will construct an ACL packet from
native voice bytes at the start of every superframe. We refer to
these packets as VoACL-voice packets, and each one carries
160 voice bytes. Three ACL baseband packet types have
sufficient payloads to carry this voice load in a single packet,
namely DH5, DM5, and DH3 packets. The DH5 packets,
however, offer no benefit over DH3 packets for this type of
transaction and waste two baseband slots. Therefore we
consider only the cases where VoACL-voice packets are of
type DH3 and DM5. We refer to these packets as VoACL-
DH3 and VoACL-DM5, respectively.
A packet cycle is defined as the minimum number of slots
used to convey both an ACL packet and its acknowledgement.
This represents the minimum amount of time that must
transpire between two consecutive ACL packet transmissions.
The packet cycle for 3-slot and 5-slot packets is then four and
six slots, respectively.
A superframe always begins with the transmission of a
VoACL-voice packet. In the VoACL-DH3 case there will be
28 (32 - 4) slots remaining in the superframe, while the
VoACL-DM5 case leaves 26 (32 - 6) slots. The VoACL

Page 3

algorithm uses these residual slots to provide simultaneous data
services. Figure 1 illustrates this concept for both the VoACL-
DM5 and VoACL-DH3 cases. Also shown is the traditional
SCO voice delivery method using HV3 packets.
Packets in Figure 1 labeled V1, V2, etc., denote voice-
bearing packets, while packets labeled D1, D2, etc., denote
data-bearing packets. The baseband packets used to deliver
data were chosen to maximize the amount of data transmitted
in the superframe. In the simulations that follow we allow for
different arrangements of the data-bearing packets.

Figure 1: VoACL slot arrangements
A.
VoACL Voice traffic
A variety of scheduling strategies can be employed within
the residual superframe slots. We discuss two specific
mechanisms that assign a transmission priority to either voice
or data traffic.

1.
VoACL - Voice Priority
Operating in the voice priority mode, lost VoACL-voice
packets will be retransmitted until received correctly, or until
the superframe ends. This scheduling scheme places a higher
priority on delivering voice information than on providing
simultaneous data throughputs and will exhaust an entire
superframe, if necessary, to deliver a single VoACL-voice
packet. This may be a favorable approach when transferring
important voice information in bad channels, as it affords at
least eight transmission attempts in the case of VoACL-DH3
and five in the case of VoACL-DM5.

2.
VoACL – Data Priority
The data priority scheme places a premium on supporting
simultaneous data applications. In this scheme, VoACL-voice
packets are not retransmitted and all of the residual superframe
slots are devoted to the transfer of data. This ensures that a
voice application will not interfere with simultaneous data
applications and guarantees a minimum level of access to the
medium for data traffic.
When a received VoACL-voice packet does not pass the
CRC test in the data priority mode, it will not be retransmitted.
One way to handle such an instance is to silently discard the
packet, and in fact this is what the Bluetooth specification
requires for ACL packet types. However, we also explore an
alternative fate for corrupted VoACL-voice packets where they
are not dropped, but rather have their contents passed to the
audio device, which is how SCO packets are handled. We
refer to this case as the delivered case to distinguish it from the
normal ACL mode of operation, or dropped case.

VoACL Data Traffic
Any of the ACL baseband packets can be used to carry data
information within the VoACL strategy. We specifically
address the case where data is carried primarily with DH5,
DM5, DH3, and DM3 packet types. These packet types will
leave some extra slots at the end of the superframe; the five-
slot packets will leave two-slots in each superframe, while the
three-slot packets will leave 4-slots. We choose to fill these
residual superframe slots with DH1 packets.

V. SIMULATIONS

We consider a single piconet comprised of a master and a
single slave. The master has infinite amounts of native voice
and data traffic to send to the slave. We consider a perfect
reverse channel such that all acknowledgements are received
correctly. This can be justified based on the small size of the
return packets used for acknowledgement.
The channel was modeled by a bit-error-rate (BER)
randomly chosen from a Rayleigh distribution with a fixed
parameter. All bits within a single packet were considered to
be statistically independent of one another. Since all packet
types have the same overheads, we considered only the packet
payloads when determining packet losses. A new channel
instance was chosen for each Bluetooth packet transmission
from the same Rayleigh distribution. The Rayleigh parameter
used to generate the distribution was then varied upwards to
10e-4 to simulate a range of channel conditions from ideal
(error-free) to highly error-prone. MATLAB was used to
simulate each of the different scenarios and all simulation
points are the average of 25 trials taken over 3200 slots.

VI. RESULTS
B.
Figures 2 and 3 show the resulting throughput performance
of the data connection when data packets are of DH5 and DM5
type respectively. The x-axis represents the Rayleigh
parameter used to represent the channel. The HV3 case
represents a traditional SCO link, sending DH3 data packets,
and provides a baseline for judging performance.
Here we can see that in good channels (small Rayleigh
parameters) all VoACL strategies perform better than the
standard HV3 voice method. As the channel worsens,
however, the VoACL strategy where DH5 packets are used for
data begins to under-perform the standard HV3 voice method.
This is due to the increased number of data packets that are lost
and require retransmission.
When DM5 packets are used for data, as in Figure 3, the
degrading channel has a less pronounced effect. DM5 packets
are more resilient and require fewer retransmissions. The
VoACL-DH3 voice priority case exhibits the most dramatic
decline in quality because frequent errors in the DH3 VoACL-
voice packets consume more superframe slots for voice

Page 4

retransmission. However each of VoACL voice strategies
outperforms the baseline HV3 case when data packets are of
type DM5.


Figure 2: Data throughput for DH5 data packets

Figure 3: Data throughput for DM5 data packets
In Figures 4 and 5 we plot the data throughputs observed
when DH3 and DM3 packets are used for data traffic,
respectively. In each case the baseline HV3 packets are used
with either DH3 data packets, as in Figure 4, or DM3 data
packets, as in Figure 5. Both show that when DM5 is used to
carry VoACL-voice, there is very little difference between
voice and data priority modes. This is due to the improved
error rejection capability of DM5 packets relative to DH3
packets. DM5 packets are almost always delivered correctly
the first time, and thus there is no perceived difference between
the voice and data priority modes.
Comparing Figures 2 and 4 we can get a sense of the effect
that data packet size has on throughput in the VoACL schemes.
Only in very good channels (those with Rayleigh parameters
below 2e-4) does it make sense to carry voice traffic on DH5
packets. Since DH5 packets are longer then DH3 packets, they
have a higher packet loss rate for a given bit-error rate. Using
DH3 packets for data transmission will improve throughputs as
the channel deteriorates.

Figure 4: Data throughput for DH3 data packets

Figure 5: Data throughput for DM3 data packets
We demonstrate the effect that VoACL has on voice quality
in Figures 6 and 7. Here the number of corrupted bits
delivered to the audio device is shown for each of the voice
strategies versus an increasing Rayleigh parameter. The two
methods for dealing with corrupted VoACL-voice packets that
can no longer be retransmitted, due to either operating in the
data priority mode or reaching the end of a superframe, are
shown.
Figure 6 illustrates the case where these packets are silently
discarded, and thus no information is presented to the audio
decoder. We represent this case by considering the entire
voice payload to be corrupted. Figure 7 illustrates the case
where these packets are delivered to the audio device despite
the fact that their payloads do not pass a CRC check.
However, in this situation we determine the number of bit
errors actually present in the payload and consider all the other
bits as useful voice information.

Page 5

implemented easily in VoACL by allowing a varying number
of retransmissions within a superframe. In this sense, we can
better blend the isochronous benefits of SCO delivery
mechanisms with the greater flexibility and throughputs offered
by ACL links.
VoACL allows for audio samples to be retransmitted,
improving the quality of the audio output, while still adhering
to the real-time delivery requirements. Simulation results show
a marked reduction in the number of voice bit errors delivered,
as well as significant improvements in simultaneous data
throughputs, as compared to the standard SCO methods.
VoACL, therefore can be an effective tool in improving
performance of simultaneous voice and data applications in
Bluetooth.

REFERENCES

[1] Specification of the Bluetooth System, Volume 2,
version 1.1, February 22, 2001.
[2]
Specification of the Bluetooth System, Volume 1,
version 1.1, February 22, 2001.
[3] A. Das, A. Ghose, A. Razdan, H. Saran, R. Shorey,
“Enhancing performance of asynchronous data traffic over
the Bluetooth wireless ad-hoc network”, IEEE INFOCOM
'2001, Alaska, USA, April 2001.
[4] A. Capone, M. Gerla, R. Kapoor, “Efficient polling
schemes for Bluetooth piconets”, IEEE ICC 01, Helsinki,
Finland, June 2001.
[5] B. Miller and C. Bisdikian. Bluetooth revealed.
Prentice Hall, NJ, 2001.
[6] J. Bray and C.F. Sturman. Bluetooth: Connect without
cables. Prentice Hall, NJ, 2001
[7] TIA/EIA/IS-2000-2-A, Physical Layer Standard for
cdma2000 Spread Spectrum Systems.
Figure 6: Number of voice errors when VoACL-voice
packets are discarded

Figure 7: Number of voice errors when VoACL-voice
packets are delivered

Both the figures show that DM5 voice delivery methods
deliver excellent quality voice that is significantly better than
the standard SCO HV3 delivery method. This is achieved by
leveraging the retransmission mechanisms and FEC coding of
DM5 packets.
The DH3-data priority VoACL method, on the other hand,
tends to deliver significantly worse voice quality compared to
the baseline HV3 method for all types of channels. This is due
to the large number of uncorrectable voice errors that occur
within the DH3 VoACL-voice packet.
By delivering packets to the audio device despite the fact
that they have failed their CRC tests can improve the voice
fidelity considerably. Figure 7 shows that the number of errors
played out by the audio device in the VoACL-DH3 data
priority case are reduced significantly. This technique also
further separates the voice-priority techniques from the
baseline HV3 method, particularly as the channel conditions
deteriorate.

VII. CONCLUSION
In this paper we introduced a series of VoACL algorithms
that use the ACL links to provide native voice support to
Bluetooth devices. SCO links are traditionally used to deliver
native voice and audio, however they require access to the
shared medium on a frequent basis and limit the bandwidth, as
well as the packet sizes, available to simultaneous data
applications. VoACL offers a way to support both isochronous
voice and data intensive applications by extending the time
horizon and payload requirements so that 160 bytes of voice
information is delivered every 32 Bluetooth slots. By using
ACL links, VoACL offers a greater degree of scheduling
freedom for larger sized packets, which dramatically improves
the bandwidth available to simultaneous data applications.
Flexible priority assignments between voice and data can be