901  Bluetooth Connection Establishment

901.1 Learning Objectives

By the end of this chapter, you will be able to:

  • Explain the Classic Bluetooth discovery process (inquiry and paging)
  • Understand BLE connection establishment through advertising and scanning
  • Configure connection parameters for optimal power and latency
  • Implement connection event handling in BLE applications
  • Troubleshoot connection issues using state machine knowledge

901.2 Prerequisites

Before diving into this chapter, you should be familiar with:

901.3 Classic Bluetooth Discovery

Classic Bluetooth uses a two-phase discovery and connection process:

901.3.1 Phase 1: Inquiry (Discovery)

The inquiry phase allows devices to find each other:

Process:

  1. Central broadcasts inquiry packets over 32 carriers
  2. Pseudo-random hopping over 79 MHz band
  3. Peripheral listens 11.25ms every 1.28s (when discoverable)
  4. Peripheral responds with address and clock offset

Timing:

  • Typical discovery time: 1-10 seconds
  • Peripheral must be in “discoverable” mode
  • Central learns peripheral’s BD_ADDR and clock for paging

901.3.2 Phase 2: Paging (Connection)

Once discovered, the central pages the peripheral to establish a connection:

Process:

  1. Central uses peripheral’s address to calculate hopping sequence
  2. Central transmits page packets on expected channels
  3. Peripheral responds and synchronizes clocks
  4. Piconet established with shared timing

Timing:

  • Typical paging time: 100ms - 3 seconds
  • Depends on peripheral’s scan interval
  • Faster if peripheral is in “connectable” mode

901.4 BLE Connection Establishment

BLE uses a simpler, more power-efficient discovery mechanism based on advertising channels.

901.4.1 Advertising Phase

The peripheral broadcasts its presence:

Advertising Channels:

  • Channels 37, 38, 39 (dedicated for advertising)
  • Positioned between Wi-Fi channels 1, 6, 11 for coexistence
  • Peripheral cycles through all three each advertising event

Advertising Packet:

  • Device name
  • Service UUIDs
  • Manufacturer data
  • TX power level (for distance estimation)

Advertising Parameters:

Parameter Range Default Impact
Interval 20ms - 10.24s 100ms Power vs discovery time
TX Power -20 to +20 dBm 0 dBm Range vs power
Mode Connectable, Scannable, Non-connectable Connectable Functionality

901.4.2 Scanning Phase

The central listens for advertisements:

Scanner Parameters:

Parameter Description Typical Value
Scan Interval How often to scan 100-200ms
Scan Window Duration of each scan 30-50ms
Scan Type Active (request more data) or Passive Active

Active vs Passive Scanning:

  • Passive: Just listen for advertisements
  • Active: Send scan request, receive scan response with additional data

901.4.3 Connection Request

When the central finds a suitable peripheral:

  1. Central sends CONNECT_IND packet on advertising channel
  2. Packet includes connection parameters:
    • Connection interval (7.5ms - 4s)
    • Peripheral latency (0-499 events)
    • Supervision timeout (100ms - 32s)
  3. Both devices switch to data channels
  4. Frequency hopping begins using agreed sequence

901.4.4 Connection Sequence

Peripheral                    Central
    |                           |
    |---[ADV_IND (Ch 37)]------>|  Advertising
    |---[ADV_IND (Ch 38)]------>|
    |---[ADV_IND (Ch 39)]------>|
    |                           |
    |<--[SCAN_REQ]--------------| Active scan
    |---[SCAN_RSP]------------->|
    |                           |
    |<--[CONNECT_IND]-----------| Connection request
    |                           |
    |---(Switch to data ch)-----|
    |                           |
    |<---[Empty PDU]------------| First connection event
    |----[Empty PDU]----------->|
    |                           |
    |---[Data exchange begins]--|

901.5 Connection Parameters

BLE connection parameters significantly affect power consumption and responsiveness.

901.5.1 Connection Interval

How often central and peripheral exchange data:

Interval Events/sec Use Case Power Impact
7.5ms 133 Gaming controllers Highest
30ms 33 Interactive apps High
100ms 10 Wearables Medium
500ms 2 Sensors Low
4000ms 0.25 Infrequent updates Lowest

Formula: Interval in 1.25ms units (e.g., 80 = 100ms)

901.5.2 Peripheral Latency

Number of connection events the peripheral can skip:

Example:

  • Connection interval: 100ms
  • Peripheral latency: 4
  • Effective wake rate: 100ms x 5 = 500ms (peripheral wakes every 5th event minimum)

Use Case:

A sensor that only sends data every 30 seconds can use high peripheral latency to skip most connection events, dramatically reducing power consumption.

// Connection parameters for a temperature sensor
// Updates every 30 seconds, needs quick response to phone requests
ble_gap_conn_params_t params = {
    .min_conn_interval = 80,    // 100ms minimum
    .max_conn_interval = 800,   // 1000ms maximum
    .slave_latency = 30,        // Can skip 30 events
    .conn_sup_timeout = 600     // 6 second supervision timeout
};
// Effective: wakes at least every 31 seconds (1000ms x 31 = 31s)

901.5.3 Supervision Timeout

Maximum time without successful exchange before disconnecting:

  • Minimum: 100ms
  • Maximum: 32 seconds
  • Must be > (1 + latency) x interval x 2

Example: With 100ms interval and latency 4, minimum timeout = (1+4) x 100ms x 2 = 1 second

901.6 Connection Event Handling

Proper handling of connection events is crucial for robust BLE applications.

901.6.1 Connection Callbacks

// Server (Peripheral) callbacks
class MyServerCallbacks : public BLEServerCallbacks {
    void onConnect(BLEServer* pServer) {
        deviceConnected = true;
        connectionCount++;

        // Get connection handle for parameter updates
        uint16_t connId = pServer->getConnId();

        // Log connection
        Serial.println("Client connected!");
    }

    void onDisconnect(BLEServer* pServer) {
        deviceConnected = false;

        // Restart advertising for next connection
        pServer->startAdvertising();
        Serial.println("Client disconnected, advertising restarted");
    }
};

901.6.2 MTU Negotiation

After connection, negotiate larger packet sizes:

void onConnect(BLEServer* pServer) {
    // Request MTU exchange for larger payloads
    // Default MTU is 23 bytes (20 usable)
    // Request up to 517 bytes for efficiency

    esp_ble_gattc_send_mtu_req(gattc_if, conn_id);
}

void onMtuChanged(uint16_t mtu) {
    Serial.printf("MTU negotiated: %d bytes\n", mtu);
    // Usable payload = MTU - 3 (ATT header)
    maxPayload = mtu - 3;
}

901.6.3 Connection Parameter Updates

Dynamically adjust parameters based on activity:

// Workout mode: responsive updates
void enableWorkoutMode() {
    ble_gap_conn_params_t workout = {
        .min_conn_interval = 12,   // 15ms
        .max_conn_interval = 24,   // 30ms
        .slave_latency = 0,        // Respond every interval
        .conn_sup_timeout = 200    // 2 seconds
    };
    ble_gap_conn_param_update(conn_handle, &workout);
}

// Daily mode: power saving
void enableDailyMode() {
    ble_gap_conn_params_t daily = {
        .min_conn_interval = 80,   // 100ms
        .max_conn_interval = 400,  // 500ms
        .slave_latency = 10,       // Skip up to 10 events
        .conn_sup_timeout = 600    // 6 seconds
    };
    ble_gap_conn_param_update(conn_handle, &daily);
}

901.7 Bluetooth Addresses

Every Bluetooth device has a unique 48-bit address (BD_ADDR):

Structure:

  • Upper 24 bits: Organization Unique Identifier (OUI) - manufacturer ID
  • Lower 24 bits: Device-specific identifier
  • Format: 12-digit hex with colons (e.g., A4:C1:38:12:34:56)

Address Types (BLE):

Type Description Use Case
Public Fixed, IEEE registered Traditional devices
Random Static Fixed per boot, not registered Privacy-focused
Random Private Resolvable Changes periodically, resolvable by bonded devices Maximum privacy
Random Private Non-Resolvable Changes periodically, not resolvable Beacons

BLE Privacy:

BLE supports address rotation for privacy:

  1. Device generates random address periodically (every 15 minutes)
  2. Bonded devices can resolve address using stored IRK (Identity Resolving Key)
  3. Prevents tracking by unauthorized parties

901.8 Bonding and Pairing

901.8.1 Pairing

Creates temporary security for current session:

  • Authenticates devices
  • Generates session encryption keys
  • Enables encrypted communication

901.8.2 Bonding

Stores pairing information for future reconnection:

  • Auto-connect when in range
  • No user interaction needed for subsequent connections
  • Stores Long Term Key (LTK) for encryption

Pairing Methods:

Method Security Requirements Use Case
Just Works Basic Button only Simple devices
Numeric Comparison High Display on both Smartphones, tablets
Passkey Entry High Display + Keyboard One device has display
Out of Band Highest NFC, QR code Maximum security

Security Levels:

Level Encryption Authentication MITM Protection
1 None None No
2 Encrypted None No
3 Encrypted Authenticated Yes
4 LE Secure Connections Authenticated Yes

901.9 Troubleshooting Connection Issues

901.9.1 Common Issues and Solutions

Device not discovered:

  • Ensure advertising is active
  • Check advertising interval (too long = slow discovery)
  • Verify scan parameters on central
  • Check TX power and range

Connection fails immediately:

  • Verify connection parameters are valid
  • Check supervision timeout > (1 + latency) x interval x 2
  • Ensure both devices support the requested parameters

Connection drops frequently:

  • Increase supervision timeout
  • Reduce peripheral latency
  • Check for RF interference
  • Move devices closer together

Slow data transfer:

  • Negotiate larger MTU
  • Reduce connection interval
  • Set peripheral latency to 0 during transfers
  • Use notifications instead of indications

901.9.2 Debug Logging

void logConnectionParams(BLEServer* pServer) {
    uint16_t connId = pServer->getConnId();
    uint16_t mtu = pServer->getPeerMTU();

    Serial.printf("Connection ID: %d\n", connId);
    Serial.printf("Peer MTU: %d bytes\n", mtu);
    Serial.printf("Max payload: %d bytes\n", mtu - 3);
}

901.10 Summary

This chapter covered Bluetooth connection establishment:

  • Classic Bluetooth uses two-phase discovery (inquiry + paging)
  • BLE uses advertising/scanning with three dedicated channels (37, 38, 39)
  • Connection parameters (interval, latency, timeout) trade off power vs responsiveness
  • MTU negotiation enables efficient large data transfers
  • Dynamic parameter updates allow adapting to activity levels
  • Bonding stores security keys for seamless reconnection
  • Address privacy in BLE prevents tracking through random address rotation

901.11 What’s Next

The next chapter, Bluetooth Protocol Stack, explores the layered architecture from PHY to application profiles, including GATT services and characteristics for standardized data exchange.