How Bluetooth Works: Classic, BLE, and Mesh Networking Explained

Bluetooth is a short-range wireless technology standard for exchanging data between devices over the 2.4 GHz ISM (Industrial, Scientific, Medical) band, managed by the Bluetooth Special Interest Group (SIG). What started in 1998 as a simple cable replacement for serial connections has evolved into three distinct protocol families: Bluetooth Classic (BR/EDR) for high-bandwidth audio and data streaming, Bluetooth Low Energy (BLE) for battery-efficient sensor and IoT communication, and Bluetooth Mesh for large-scale device networks. Each variant uses fundamentally different protocol stacks, connection models, and radio techniques, united only by their shared use of the 2.4 GHz band and the Bluetooth brand. Understanding the engineering beneath the pairing dialogs and device lists reveals a sophisticated system of frequency hopping, adaptive power control, and cryptographic key management.

The 2.4 GHz ISM Band and Frequency Hopping

Bluetooth operates in the 2.4000-2.4835 GHz ISM band -- the same spectrum used by WiFi, microwave ovens, Zigbee, and countless other wireless technologies. To coexist in this crowded spectrum, Bluetooth uses Frequency Hopping Spread Spectrum (FHSS): instead of transmitting on a fixed frequency, devices hop between 79 channels (Classic) or 40 channels (BLE), each 1 MHz wide, in a pseudo-random sequence.

In Bluetooth Classic, the hopping sequence is derived from the master device's Bluetooth address (BD_ADDR) and its clock. Both master and slave devices compute the same sequence independently, hopping 1,600 times per second (every 625 microseconds, one "slot"). This rapid hopping means that even if one channel is occupied by WiFi or another interferer, the Bluetooth connection only loses 1/79th of its capacity -- the next hop will likely land on a clear channel.

Adaptive Frequency Hopping (AFH), introduced in Bluetooth 1.2, makes this even smarter. Devices continuously measure the quality of each channel and classify them as good or bad. Bad channels (those consistently occupied by WiFi, for example) are removed from the hopping sequence. The minimum number of channels that AFH can use is 20 (out of 79), so even in heavily congested environments, Bluetooth can avoid interference while maintaining enough channels for frequency diversity.

BLE uses a different scheme: 40 channels of 2 MHz width, of which 37 are data channels and 3 are advertising channels (37, 38, 39), positioned at frequencies specifically chosen to avoid the three most common WiFi channels (1, 6, 11). BLE also uses AFH but only on data channels; advertising channels are always active because they must be scannable by any device.

Bluetooth Classic (BR/EDR)

Bluetooth Classic encompasses two radio modes: BR (Basic Rate) at 1 Mbps and EDR (Enhanced Data Rate) at 2-3 Mbps. Classic Bluetooth is connection-oriented: devices form a piconet with one master and up to seven active slaves. The master controls the hopping sequence and the timing -- slaves can only transmit when the master addresses them in a poll-response pattern.

The protocol stack for Classic Bluetooth is layered:

• Radio layer -- GFSK modulation (BR, 1 Mbps), pi/4-DQPSK (EDR 2 Mbps), or 8DPSK (EDR 3 Mbps). Transmit power classes: Class 1 (100 mW, ~100 m range), Class 2 (2.5 mW, ~10 m range, most common), Class 3 (1 mW, ~1 m range).
• Baseband -- Manages the piconet, frequency hopping, time-division duplexing (TDD, alternating TX/RX slots), packet types, and link control.
• LMP (Link Manager Protocol) -- Handles link setup, authentication, encryption negotiation, and power control between devices.
• L2CAP (Logical Link Control and Adaptation Protocol) -- Multiplexes higher-layer protocols over the baseband link, handles segmentation and reassembly, and provides quality of service.
• RFCOMM -- Provides a serial port emulation layer over L2CAP. Many Classic Bluetooth profiles (SPP, DUN, OBEX) are built on RFCOMM because legacy applications were designed for serial ports.
• SDP (Service Discovery Protocol) -- Allows devices to discover which profiles and services are available on a remote device.

Classic Bluetooth defines profiles that standardize how specific use cases work:

• A2DP (Advanced Audio Distribution Profile) -- High-quality stereo audio streaming. Uses SBC (Sub-Band Codec) as the mandatory codec, with optional support for AAC, aptX, LDAC, and LC3 (in newer versions). A2DP is the profile behind wireless headphones and car audio.
• HFP (Hands-Free Profile) -- Two-way audio for phone calls (car kits, headsets). Uses CVSD or mSBC codec at 8/16 kHz.
• HID (Human Interface Device) -- Keyboards, mice, game controllers. Low-latency input devices.
• SPP (Serial Port Profile) -- Virtual serial port over Bluetooth. Widely used in industrial and embedded applications.
• PAN (Personal Area Networking) -- IP networking over Bluetooth, allowing devices to form ad-hoc networks or share internet access.

Bluetooth Low Energy (BLE)

BLE (introduced in Bluetooth 4.0 in 2010) is a completely separate protocol stack designed from scratch for ultra-low power operation. A BLE device can run for months or years on a coin cell battery. BLE achieves this through extremely short transmission bursts, long sleep intervals, and a simplified connection model.

BLE's key characteristics differ from Classic in almost every dimension:

• Data rate -- 1 Mbps (BLE 4.x), 2 Mbps (BLE 5.0 2M PHY). Much lower than Classic EDR's 3 Mbps, but sufficient for sensor data, notifications, and control messages.
• Connection interval -- BLE devices negotiate a connection interval (7.5 ms to 4 seconds) that determines how often they wake up to exchange data. Between intervals, the radio is completely off. A sensor reporting temperature every 5 seconds might use a 1-second connection interval, waking the radio for ~3 ms per interval -- a duty cycle well under 1%.
• Packet size -- BLE 4.x: 27 bytes maximum payload per packet (after Bluetooth 4.2 Data Length Extension: 251 bytes). BLE 5.0: up to 251 bytes. This small packet size is deliberate -- it keeps transmissions short and the radio on for minimal time.
• Range -- BLE 5.0 introduced a Coded PHY (S=8 mode) that uses forward error correction to extend range to 400+ meters at the cost of data rate (125 kbps effective throughput). The standard 1M PHY achieves 30-100 m depending on environment and power level.

GATT: The BLE Data Model

BLE uses a data model called GATT (Generic Attribute Profile) built on top of the ATT (Attribute Protocol). GATT organizes data into a hierarchy:

• Profile -- A collection of services that define a use case (e.g., Heart Rate Profile, Proximity Profile). Profiles are defined by the Bluetooth SIG or can be custom.
• Service -- A collection of related characteristics, identified by a UUID. Standard services have 16-bit UUIDs (e.g., 0x180D for Heart Rate Service); custom services use 128-bit UUIDs.
• Characteristic -- A single data value with associated metadata. Each characteristic has a UUID, a value, and properties (read, write, notify, indicate). For example, the Heart Rate Measurement characteristic (0x2A37) contains the current heart rate value.
• Descriptor -- Additional metadata about a characteristic. The most important is the Client Characteristic Configuration Descriptor (CCCD), which the client writes to enable notifications or indications.

The GATT model defines two roles: the GATT Server (the device with data to expose, e.g., a heart rate monitor) and the GATT Client (the device reading that data, e.g., your phone). After connecting, the client performs service discovery -- reading the server's attribute table to find available services and characteristics. The client can then read values, write values, or subscribe to notifications/indications for automatic updates when values change.

Notifications vs. indications: a notification is a one-way push from server to client (no acknowledgment required). An indication requires the client to acknowledge receipt. Notifications are preferred for high-frequency data (sensor readings) because they avoid the round-trip latency of acknowledgments.

BLE Advertising and Discovery

BLE devices make themselves discoverable by broadcasting advertising packets on the three advertising channels (37, 38, 39). An advertising event consists of sending the same packet on each of the three channels in quick succession, then sleeping until the next advertising interval (20 ms to 10.24 seconds). The advertising packet contains:

• Preamble and Access Address -- Fixed values that allow receivers to identify the packet as a BLE advertisement
• PDU (Protocol Data Unit) -- Contains the advertiser's address (public or random), the advertising type (connectable, scannable, non-connectable), and up to 31 bytes of advertising data (extended to 255 bytes in BLE 5.0 with extended advertising)
• Advertising data -- Structured as type-length-value (TLV) entries. Common types include: device name, TX power level, service UUIDs (to indicate what services are available), manufacturer-specific data (used extensively by Apple iBeacon and Google Eddystone), and flags (indicating BLE-only, dual-mode, etc.)

A scanner (e.g., your phone looking for nearby devices) listens on the advertising channels. Passive scanning simply listens for advertisements. Active scanning sends a Scan Request to the advertiser, which responds with a Scan Response containing additional data (another 31 bytes). This doubles the amount of data a device can broadcast without establishing a connection.

BLE 5.0 introduced extended advertising, which uses the advertising channels only to announce the presence of extended advertising data on data channels. This allows advertising payloads up to 255 bytes (or fragmented across multiple packets) without consuming valuable advertising channel time.

Pairing, Bonding, and Security

Bluetooth security is built on pairing (establishing a shared secret between two devices) and bonding (storing that secret for future use). The security model has evolved significantly across Bluetooth versions, driven by a series of discovered vulnerabilities.

Classic Bluetooth pairing:

• Legacy pairing (pre-2.1) -- Uses a shared PIN code (typically "0000" or "1234") to derive a link key. This is vulnerable to offline brute-force attacks because an eavesdropper who captures the pairing exchange can try all possible PINs.
• Secure Simple Pairing (SSP, Bluetooth 2.1+) -- Uses Elliptic Curve Diffie-Hellman (ECDH) for key exchange, making passive eavesdropping insufficient to derive the link key. SSP supports four association models:
  • Numeric Comparison -- Both devices display a 6-digit number; the user confirms they match. Protects against MITM.
  • Passkey Entry -- The user enters a passkey displayed on one device into the other. MITM protection.
  • Just Works -- No user interaction. Uses ECDH for encryption but provides no MITM protection. Used when devices lack displays or keyboards.
  • Out of Band (OOB) -- Key exchange via NFC, QR code, or other non-Bluetooth channel. Strongest MITM protection.

BLE pairing:

• LE Legacy Pairing (BLE 4.0-4.1) -- Uses a Temporary Key (TK) derived from a passkey or Just Works (TK=0). Vulnerable to passive eavesdropping because the TK is used directly in key generation. An attacker who captures the pairing exchange can brute-force the 6-digit passkey (only 1 million possibilities) and derive all encryption keys.
• LE Secure Connections (BLE 4.2+) -- Uses ECDH key exchange (P-256 curve), making passive eavesdropping ineffective. The Long Term Key (LTK) is derived from the ECDH shared secret, not from a passkey. The same four association models as SSP are available. This is the recommended pairing method for all new BLE devices.

Bonding stores the derived keys (LTK for BLE, Link Key for Classic) in non-volatile memory so devices can reconnect without repeating the pairing process. Bonded devices also exchange Identity Resolving Keys (IRKs) that allow them to recognize each other even when using random MAC addresses (a privacy feature that prevents tracking).

BLE supports four security levels:

1. Level 1 -- No security (no authentication, no encryption)
2. Level 2 -- Unauthenticated encryption (Just Works pairing -- encrypted but no MITM protection)
3. Level 3 -- Authenticated encryption (Numeric Comparison, Passkey, or OOB -- encrypted with MITM protection)
4. Level 4 -- Authenticated LE Secure Connections with 128-bit encryption key (highest level, requires BLE 4.2+)

GATT services and characteristics can require specific security levels for access. A heart rate characteristic might be readable at Level 1, but a glucose measurement (medical data) might require Level 3 or Level 4.

BLE Connection Lifecycle

A BLE connection follows this sequence:

1. Advertising -- The peripheral broadcasts advertising packets.
2. Scanning -- The central device listens for advertisements.
3. Connection Request -- The central sends a CONNECT_IND packet to the peripheral on an advertising channel, specifying connection parameters (connection interval, slave latency, supervision timeout).
4. Connected -- Both devices switch to a shared hopping sequence on data channels. The central is the master (initiates each connection event), the peripheral is the slave.
5. Service Discovery -- The central reads the peripheral's GATT attribute table to discover services and characteristics.
6. Data Exchange -- The central reads/writes characteristics, subscribes to notifications.
7. Disconnection -- Either side can terminate. The peripheral resumes advertising if it wants to be reconnectable.

Connection parameters significantly impact power consumption and performance:

• Connection interval -- How often devices exchange data (7.5 ms to 4 seconds). Shorter intervals = lower latency but higher power consumption.
• Slave latency -- Number of connection events the slave can skip if it has no data to send. A slave latency of 4 with a 100 ms connection interval means the slave only needs to wake up every 500 ms when idle.
• Supervision timeout -- How long to wait without a response before considering the connection lost (100 ms to 32 seconds).

Bluetooth Mesh

Bluetooth Mesh (introduced in 2017) extends BLE to support many-to-many device communication in large-scale networks. Unlike Classic and BLE's point-to-point (or star) topologies, Mesh creates a flood-based network where messages can reach devices anywhere in the mesh through multi-hop relay.

Bluetooth Mesh is designed for building automation (lighting, HVAC, access control), industrial IoT, and smart home applications. Key architectural concepts:

• Managed flood -- Messages are broadcast and relayed by relay nodes. Every relay node that receives a message rebroadcasts it once (with a TTL counter to prevent infinite loops). This is simpler than routing-based mesh protocols but consumes more bandwidth. The mesh is designed for small, infrequent messages (e.g., "turn on light group 3"), not for streaming data.
• Nodes and elements -- A node is a device provisioned into the mesh. Each node has one or more elements (functional endpoints). A light fixture with RGB control might have three elements: one for each color channel.
• Models -- Standardized behaviors that elements implement. The Generic OnOff Server model handles on/off state, the Light Lightness Server handles brightness. Models define the messages an element can send and receive.
• Publish/Subscribe -- Nodes publish messages to group addresses and subscribe to groups they care about. A light switch publishes to group "Kitchen Lights"; all lights subscribed to that group respond. This decouples senders from receivers.
• Provisioning -- Adding a new device to the mesh network. The provisioner (typically a phone app) authenticates the device, assigns it a unicast address, and distributes network and application keys.
• Security -- Bluetooth Mesh uses two layers of encryption: the network key (NetKey) encrypts the network layer (all nodes in the network share it), and the application key (AppKey) encrypts the application payload (only nodes authorized for a specific application share it). This means relay nodes can forward messages they cannot decrypt at the application layer -- they only need the NetKey for network-layer processing.

A significant limitation of Bluetooth Mesh is throughput. Because it uses managed flooding over BLE advertising channels, the aggregate bandwidth of the mesh is limited. In a dense mesh with many relay nodes, message collisions increase. For applications requiring high throughput or real-time streaming, Wi-Fi Mesh, Thread, or Zigbee may be more appropriate. Bluetooth Mesh's strength is in its massive installed base (any BLE 4.0+ device can potentially support mesh with a firmware update) and its mature security model.

Bluetooth 5.x and Beyond

Recent Bluetooth versions have focused on BLE improvements:

• Bluetooth 5.0 (2016) -- 2M PHY (2 Mbps, double throughput), Coded PHY (long range, 125-500 kbps), extended advertising (255 bytes), advertising sets (multiple independent advertising instances).
• Bluetooth 5.1 (2019) -- Direction finding using Angle of Arrival (AoA) and Angle of Departure (AoD). By using antenna arrays, devices can determine the direction of a BLE signal to within a few degrees, enabling centimeter-level indoor positioning.
• Bluetooth 5.2 (2020) -- LE Audio, a complete rearchitecture of Bluetooth audio. Introduces the LC3 (Low Complexity Communication Codec) which delivers equal or better audio quality than SBC at half the bit rate. Also introduces Isochronous Channels for time-synchronized audio streams, enabling true wireless stereo (TWS) earbuds to receive independent audio streams rather than relaying one to the other. Auracast uses BLE broadcast to stream audio to unlimited receivers (think airport announcements, gym TVs).
• Bluetooth 5.3 (2021) -- Connection subrating (dynamically changing connection parameters), channel classification improvements, and periodic advertising enhancements.
• Bluetooth 5.4 (2023) -- Periodic Advertising with Responses (PAwR) for efficient bidirectional communication in large-scale networks (e.g., electronic shelf labels). Encrypted advertising data for improved privacy.
• Bluetooth 6.0 (2024) -- Bluetooth Channel Sounding for centimeter-level distance measurement (ranging), enabling secure keyless entry and spatial audio. Decision-based advertising filtering for more efficient scanning.

Bluetooth Coexistence Challenges

Sharing the 2.4 GHz band with WiFi creates real-world problems. A 20 MHz WiFi channel occupies 20 of Bluetooth's 79 channels. When both technologies are active in the same device (a smartphone using WiFi and Bluetooth simultaneously), they can physically interfere because the radio hardware must time-share the antenna and RF front-end.

Modern devices use coexistence mechanisms to mitigate this:

• Packet Traffic Arbitration (PTA) -- A hardware interface between the WiFi and Bluetooth chipsets that coordinates access to the antenna. When WiFi is transmitting a frame, it signals Bluetooth to defer. When Bluetooth has a time-critical packet (e.g., HFP audio), it can preempt WiFi.
• AFH channel avoidance -- Bluetooth's AFH marks channels occupied by the device's own WiFi connection as bad and avoids them.
• TDM (Time Division Multiplexing) -- Some implementations alternate between WiFi and Bluetooth activity in a time-interleaved pattern, ensuring both get predictable access to the radio.

In practice, coexistence is imperfect. Users commonly experience Bluetooth audio dropouts when downloading large files over WiFi, or reduced WiFi throughput when streaming high-quality Bluetooth audio. Using the 5 GHz WiFi band (which does not overlap with Bluetooth) eliminates the interference entirely.

Bluetooth and Network Infrastructure

Bluetooth is fundamentally a personal area network (PAN) technology -- it connects devices within arm's reach. But increasingly, BLE devices are gateways to wider networks. A BLE sensor connects to a phone or gateway, which relays data over WiFi or cellular to cloud services, whose IP addresses are part of prefixes announced by autonomous systems via BGP. You can trace the network path from any BLE gateway's cloud backend to your location using the god.ad looking glass.