Asynchronous Connection-Oriented Link

Description

The Asynchronous Connection-Oriented Link (ACL) is a fundamental Bluetooth transport mechanism that provides reliable, connection-oriented data communication between a master device and one or more slave devices in a piconet. Unlike Synchronous Connection-Oriented (SCO) links designed for isochronous voice traffic, ACL links handle asynchronous data transfer with built-in error detection and retransmission capabilities. ACL operates on a master-slave architecture where the master device controls timing and polling of slave devices, allocating time slots for bidirectional or unidirectional data transmission.

ACL connections use a time-division duplex (TDD) scheme where the master and slave alternate transmission in consecutive time slots. The master initiates communication in even-numbered slots, and the addressed slave responds in the following odd-numbered slot. This polling mechanism allows the master to maintain connections with up to seven active slaves in a piconet. ACL packets support various payload sizes and data rates, with the base rate offering 723.2 kbps asymmetric or 433.9 kbps symmetric data transfer. Enhanced Data Rate (EDR) modes introduced in later Bluetooth versions significantly increase throughput.

Error control in ACL links employs Automatic Repeat Request (ARQ) mechanisms with cyclic redundancy check (CRC) and forward error correction (FEC) for certain packet types. The master device uses a stop-and-wait ARQ protocol where each transmitted packet must be acknowledged before sending the next. Unacknowledged packets are retransmitted until successful delivery or until a timeout occurs. ACL supports multiple packet types with different levels of error protection, allowing trade-offs between reliability and throughput based on application requirements.

ACL links coexist with SCO links in Bluetooth networks through time multiplexing. The master device schedules both link types within the same piconet, with SCO links receiving priority for their time-critical voice traffic. ACL traffic fills the remaining time slots, providing efficient bandwidth utilization. This dual-link architecture enables Bluetooth devices to simultaneously support voice calls and data transfer applications. ACL also forms the foundation for advanced Bluetooth profiles and services requiring reliable data transport.

Purpose & Motivation

ACL was created to provide reliable data communication in Bluetooth networks, addressing the need for error-free transfer of application data alongside voice traffic. Before Bluetooth standardization, wireless data transfer often relied on proprietary protocols with inconsistent reliability mechanisms. ACL introduced a standardized approach to asynchronous data transport with guaranteed delivery, enabling interoperable data applications across different manufacturers' devices.

The technology solves the problem of maintaining data integrity over error-prone wireless channels while efficiently sharing bandwidth with synchronous voice connections. Previous wireless data solutions either lacked proper error correction or used inefficient retransmission schemes that degraded overall network performance. ACL's combination of ARQ, FEC, and flexible packet types provides adaptable error protection suitable for various data types and channel conditions.

ACL's creation was motivated by the growing need for cable replacement technologies that could handle both voice and data applications reliably. By providing connection-oriented data transport with sequencing and acknowledgment mechanisms, ACL enabled Bluetooth to support file transfer, network access, synchronization, and other data-intensive applications. This made Bluetooth suitable for broader use cases beyond simple voice headsets, contributing to its widespread adoption in mobile devices, computers, and IoT applications.

Key Features

• Reliable data transfer with ARQ retransmission
• Connection-oriented communication with sequencing
• Support for asymmetric and symmetric data rates
• Coexistence with SCO links through time multiplexing
• Multiple packet types with varying error protection
• Master-controlled polling of slave devices

Evolution Across Releases

Defining Specifications