With over 100 million Bluetooth-enabled products shipping in 2004 and predictions of over 200 million for 2005, Bluetooth (BT) has well and truly arrived. Questions of "Will there be devices to connect with?" have been replaced by "How well will my device interoperate with your device?"
Until recently, BT audio transmission was fairly straightforward. The BT specification only defined one mechanism, and there were few options to complicate matters. Now, the release of the BT 1.2 specification and a new high-quality audio profile has complicated this once simple feature. Because streaming data is the basis of all digital audio transmissions, the available methods differ in transport mechanism, encoding method, data rate, packet length, and error detection/recovery.
Bluetooth is a packet-based, frequency-hopping protocol using a time slot of 625-ms duration. In each pair of communicating BT devices, one is the connection master, and the other is the slave. Generally, a slave device may transmit data to the master in the slot following receipt of a packet from the master. Bluetooth defines two basic mechanisms for audio-data transmission.
The original BT audio transport mechanism is the synchronous-connection-oriented (SCO) channel, which supplies full-duplex data with a 64-kbit/s rate in each direction. In the absence of RF interference, SCO audio quality is similar to that of a typical cellular phone. This is to be expected since Bluetooth was developed with phone-headset applications in mind. SCO data is transmitted in dedicated time slots, which guarantees bandwidth and a fixed arrival time for the packets.
Bluetooth transmits nonsynchronous data using the Logical Link Control and Adaptation Protocol (L2CAP). L2CAP multiplexes all nonsynchronous transmissions over available BT bandwidth. These include serial data (for example, AT commands and responses), service discovery data, and isochronous data used to support streaming audio and video channels. Figure 1 shows a protocol layer diagram.
The introduction of the Bluetooth 1.2 specification, which enhanced Bluetooth's quality-of-service (QoS) features, greatly improved the utility of isochronous data. These improvements enable applications to request bandwidth and latency guarantees for their data streams.
Selecting The Right SCO Channel
SCO channels offer little in the way of customizable features. The bit rate is fixed, and while three coder-decoders (codecs) are defined, only one-Continuously Variable Slope Delta (CVSD)-is used in practice. The other codecs (A-law and µ-law) offer better sound quality but don't tolerate data errors as well as CVSD. Since the SCO channel offers limited error detection/correction and no packet retransmission, CVSD is the safer choice.
SCO provides full-duplex audio. The connection master will send one packet of data to the slave, which will respond in the next time slot. The specific packet type used is typically left up to the link manager firmware in the BT chip set, though there is a way to select a specific type. Bluetooth defines four packet types for transmitting SCO data (see the table).
Whether selected by the chip set or the system designer, there are tradeoffs to consider when selecting an SCO packet type. HV1 packets, while producing better error recovery than other types, accomplish this by consuming the entire bandwidth of a Bluetooth 1.1 connection. HV3 packets supply no error detection, but they only consume two of every six slots. The device can then establish other connections while maintaining an SCO connection. This isn't possible when using the HV1 packet type for the SCO data. Figure 2 depicts an SCO timing chart.
Under optimal conditions, packet type won't affect audio quality. The data transmitted is exactly the same in all three cases. HV1 and HV2 packets allow for some bit-error correction. But typically, bit errors don't significantly degrade audio quality. Dropped packets are the most likely cause of poor audio quality.
A BT packet contains an access code, a header, and a payload. While a 1/3 forward-error-correction (FEC) code and an error-checking code protect the header, low signal strength or local interference may result in a packet arriving with an invalid header. In this case, the entire packet is discarded. Because there's no mechanism to request retransmission of an SCO packet, the data is simply lost.
If the link uses HV1 packets, less data is lost, so there will be less audio pop energy in one lost packet. If the packets are lost due to narrow-band or short-duration interference, HV1 may offer better audio quality than HV2 or HV3 packets. This isn't a certainty, as HV1 also transmits more packets and therefore has a higher potential for packet loss in a noisy environment.
The Bluetooth 1.2 specification adds capabilities that improve SCO audio in the face of local interference. A good example is IEEE-802.11b, which occupies a band of approximately 22 MHz in the ISM band, or 22 channels of the Bluetooth spectrum.
Bluetooth uses 79 channels, spaced at 1-MHz intervals. Adaptive Frequency Hopping (AFH), added in the 1.2 specification, allows a pair of BT devices to avoid channels that are known to be blocked. The two devices can develop a channel map in real time, or it can be supplied to the radio from upper-layer software. The latter model enables easier coexistence in devices that contain both Bluetooth and 802.11b nodes. The device software can supply the BT module with a new frequency map that prevents the use of channels in the range occupied by the 802.11b node. With fewer packets lost to interference, audio quality is improved. The hopping algorithm used by AFH can operate with as few as 20 good channels. The downside to AFH is that reducing the operational channels increases the probability of interference from nearby Bluetooth connections.
Extended SCO Channels
Another addition to the Bluetooth 1.2 specification is the Extended SCO (eSCO) channel, which offers more flexibility in channel parameters and permits retransmission of bad packets. These extensions, combined with AFH, deliver better audio performance than the BT 1.1 standard SCO channel.
In the simplest case, an eSCO channel operates very much like an SCO channel, albeit with a new packet type. Audio data is broadcast in single-slot packets containing from one to 30 data bytes, but eSCO adds two enhancements. First, the packet contains a CRC code used to check the data's validity. (This is not present in the HV3 SCO packet.) Second, if an error is detected, the receiving device may be able to request retransmission of the faulty data. This depends on how the channel was configured, since frames must be reserved for possible retransmissions.
The downside to retransmitting packets is an increase in power consumption by both devices. Using AFH can minimize this effect. If packets are being lost due to a fixed-band interferer, such as 802.11b, AFH allows the BT devices to avoid the known bad channels, reducing the need to retransmit packets. Designers also need to consider data latency, since retransmitted data will arrive at least 1.2 ms after its scheduled arrival time.
Reprints
)
)
