BLE Basics

Quick Cap

Bluetooth Low Energy (BLE) is a wireless protocol optimized for short-range, low-power data exchange between embedded devices. Unlike Classic Bluetooth (designed for continuous audio streaming), BLE is built for intermittent bursts of small data -- perfect for sensors, wearables, beacons, and IoT devices that must run on coin-cell batteries for months or years.

Interviewers test whether you understand the GAP/GATT split (discovery vs data exchange), can explain connection parameters and their power impact, and know when BLE is the right choice vs WiFi or Zigbee.

Key Facts:

• BLE vs Classic: BLE uses 40 channels (2 MHz each) vs Classic's 79 channels (1 MHz each); BLE optimizes for low duty cycle, not throughput
• GAP: Defines device roles (Central, Peripheral, Broadcaster, Observer) and manages advertising, scanning, and connection establishment
• GATT: Defines the data model -- services contain characteristics, characteristics contain values and optional descriptors
• Connection parameters: Interval (7.5 ms to 4 s), latency (skipped events), supervision timeout -- these directly control power consumption
• BLE 5.0: 2M PHY (doubled speed), Coded PHY (4x range), extended advertising (251 bytes vs 31 bytes)
• Security: Pairing (key exchange), bonding (storing keys), encryption (AES-128-CCM)

Deep Dive

At a Glance

BLE Protocol Stack Architecture

The BLE stack splits into two halves separated by the HCI (Host Controller Interface) boundary. The Controller (PHY + Link Layer) handles radio timing and is typically implemented in hardware or a dedicated radio IC. The Host (L2CAP, ATT, GATT, GAP, SMP) implements the protocol logic and runs in firmware on the application processor.

Understanding this split matters for interviews because it determines where bugs live: radio/timing issues are controller-side (often fixed by chip vendor updates), while application data issues are host-side (your responsibility). Most embedded BLE SDKs (Nordic SoftDevice, ESP-IDF BT, Zephyr) implement the full stack on a single chip, but the conceptual boundary remains.

Android Bluetooth Architecture

On Android platforms, the BLE stack has additional layers. The application interacts through the Android Bluetooth Framework API, which communicates with the Bluetooth process via Binder IPC. The native Bluetooth stack (Fluoride/Gabeldorsche) implements the host-side protocols, and the HAL (Hardware Interface Definition Language) layer bridges to the vendor-specific controller firmware.

This layered architecture is relevant for engineers working on Android-based embedded products (automotive infotainment, smart displays, Android Things-derived IoT devices) where BLE issues may span multiple layers from the Java API down to the radio firmware.

BLE vs Classic Bluetooth

This distinction is the starting point for any BLE interview conversation.

Dual-mode devices (like smartphones) support both Classic and BLE. Most embedded IoT devices are single-mode BLE only, which reduces silicon cost and power consumption. The Bluetooth SIG assigned BLE its own specification starting with Bluetooth 4.0 (2010).

GAP: Device Discovery and Connection

GAP (Generic Access Profile) controls how BLE devices find each other and establish connections. It defines four roles:

A device can switch roles or support multiple roles simultaneously (e.g., a gateway that acts as Central to sensors and Peripheral to a phone).

Advertising

Advertising is how peripherals announce their presence. The peripheral transmits advertising packets on three dedicated channels (37, 38, 39) at a configurable interval.

Advertising types:

Advertising data format: Each advertising packet carries up to 31 bytes of payload, structured as a sequence of AD (Advertising Data) structures. Each AD structure has a length byte, a type byte, and data bytes. Common AD types include Flags (0x01), Complete Local Name (0x09), 16-bit Service UUIDs (0x03), and Manufacturer Specific Data (0xFF).

Advertising Packet (31 bytes max):
[ AD1: Len | Type | Data... ] [ AD2: Len | Type | Data... ] [ ... ]

Example:
[ 02 | 01 | 06 ]  Flags: LE General Discoverable, BR/EDR Not Supported
[ 05 | 09 | 'T' 'e' 'm' 'p' ]  Complete Local Name: "Temp"
[ 03 | 03 | 0x1809 ]  16-bit Service UUID: Health Thermometer

A separate Scan Response packet (also 31 bytes) can provide additional data when a Central sends a scan request. This effectively doubles available advertising data to 62 bytes in BLE 4.x.

Advertising interval controls the trade-off between discoverability and power. Shorter intervals (20-100 ms) make the device discoverable faster but drain the battery. Longer intervals (1-10 s) save power but make discovery slower. Typical IoT devices use 100-1000 ms.

Connection Establishment

When a Central wants to connect to an advertising Peripheral:

1. Central scans and discovers the Peripheral's advertising packet
2. Central sends a CONNECT_IND packet on the advertising channel
3. Both devices switch to a data channel and begin exchanging data per the agreed connection parameters
4. The entire process takes as little as 3-5 ms -- far faster than Classic Bluetooth's multi-second inquiry process

GATT: The Data Model

GATT (Generic Attribute Profile) defines how data is organized and exchanged over a BLE connection. It uses a client-server model built on top of ATT (Attribute Protocol).

GATT hierarchy:

Profile (e.g., Heart Rate Profile)
  └── Service (e.g., Heart Rate Service, UUID 0x180D)
        ├── Characteristic (e.g., Heart Rate Measurement, UUID 0x2A37)
        │     ├── Value (the actual data)
        │     ├── Properties (Read, Write, Notify, Indicate)
        │     └── Descriptor (e.g., CCCD for enabling notifications)
        └── Characteristic (e.g., Body Sensor Location, UUID 0x2A38)
              ├── Value
              └── Properties (Read)

Key concepts:

• Service: A collection of related characteristics. Identified by a UUID (16-bit for SIG-defined, 128-bit for custom). Examples: Battery Service (0x180F), Heart Rate Service (0x180D), Device Information Service (0x180A).
• Characteristic: A single data point with a value, properties, and optional descriptors. Properties define what operations are allowed (Read, Write, Write Without Response, Notify, Indicate).
• Descriptor: Metadata about a characteristic. The most important is the Client Characteristic Configuration Descriptor (CCCD) -- a client writes to this to enable/disable notifications or indications.
• Notifications vs Indications: Notifications push data from server to client without acknowledgment (faster). Indications require acknowledgment (reliable but slower). The client must enable either one by writing to the CCCD.

GATT roles:

Connection Parameters

Connection parameters directly control the trade-off between responsiveness, throughput, and power consumption. They are negotiated during or after connection establishment.

Example trade-offs:

The Peripheral can request updated connection parameters via an L2CAP Connection Parameter Update Request. The Central decides whether to accept. If rejected, the Peripheral is stuck with the Central's chosen parameters -- this is a common source of interoperability issues.

BLE 5.0 Features

BLE 5.0 (released 2016) introduced three major improvements relevant to embedded systems:

2M PHY does not double the range -- it doubles the bit rate. The range actually decreases slightly because faster modulation is more sensitive to noise. The real benefit is reducing radio-on time: sending the same data in half the time means the radio sleeps more, reducing average current.

Coded PHY adds redundancy (forward error correction) at the cost of data rate. S=2 coding halves the data rate for approximately 2x range improvement. S=8 coding reduces data rate to 1/8 but achieves approximately 4x range. This is critical for applications like agricultural sensors or building monitoring where devices are far apart.

Extended Advertising uses the 37 data channels (not just the 3 advertising channels) to transmit longer advertising packets. This enables richer beacon data, periodic advertising (synchronized broadcasts), and advertising sets (multiple independent advertisements from one device).

Security: Pairing, Bonding, and Encryption

BLE security has three phases:

1. Pairing: The process of establishing a temporary security context. The two devices negotiate a Temporary Key (TK) using one of these methods:

   • Just Works: No user interaction, vulnerable to MITM (man-in-the-middle) -- acceptable for low-security devices
   • Passkey Entry: User enters a 6-digit code on one or both devices -- provides MITM protection
   • Numeric Comparison (BLE 4.2+): Both devices display a 6-digit number, user confirms they match -- provides MITM protection
   • Out of Band (OOB): Keys exchanged via NFC or other channel -- strongest MITM protection

2. Bonding: Storing the exchanged keys in non-volatile memory so devices can reconnect without re-pairing. A bonded device reconnects in milliseconds using a Long Term Key (LTK).

3. Encryption: After pairing, the link is encrypted using AES-128-CCM. All subsequent data is encrypted and authenticated. BLE 4.2 introduced LE Secure Connections, which uses Elliptic Curve Diffie-Hellman (ECDH) for key exchange -- significantly stronger than the legacy pairing in BLE 4.0/4.1.

BLE for Embedded Platforms

Architecture pattern: On most embedded BLE platforms, the BLE stack runs in a separate context (separate core, or protected firmware region) from the application. The application communicates with the stack via an API or IPC mechanism. Nordic's SoftDevice, for example, is a precompiled binary that handles all BLE protocol processing -- the application calls SoftDevice APIs and receives events through callbacks.

Power Consumption and Battery Life

BLE's power advantage comes from its low duty cycle. A typical sensor might advertise for 1-3 ms every second and sleep the rest of the time.

Power budget estimation (advertising only):

Advertising event:
  - TX burst: ~10 mA for 1 ms on each of 3 channels = 3 ms active
  - Average current = (10 mA * 3 ms) / 1000 ms = 30 uA

CR2032 coin cell capacity: ~230 mAh
Battery life = 230 mAh / 0.030 mA = 7,666 hours = ~10 months
  (excluding self-discharge and sleep current)

Power optimization strategies:

• Increase advertising interval (100 ms vs 1 s = 10x power difference)
• Use Peripheral Latency to skip connection events when no data is pending
• Use 2M PHY to reduce radio-on time per transaction
• Minimize GATT read/write operations -- prefer notifications (server-initiated, no polling)
• Enter deep sleep between connection events (requires fast wake-up MCU)

BLE Mesh Basics

BLE Mesh (introduced 2017) enables many-to-many communication over BLE using a managed flood approach. Unlike Zigbee's routed mesh, BLE Mesh uses relay nodes that rebroadcast messages. Every message has a TTL (time to live) that limits propagation.

Key concepts: Nodes (devices on the mesh), Elements (addressable entities within a node), Models (define behavior -- e.g., Generic OnOff Server), Publish/Subscribe (nodes publish to groups, subscribers receive). BLE Mesh is used in commercial lighting systems (replacing DALI/DMX) and building automation, though it has higher latency and lower throughput than Zigbee mesh due to the flooding approach.

Debugging Story: The Disappearing Notifications

A wearable fitness band paired with a phone app and worked perfectly during development. In the field, users reported that heart rate notifications would stop after 10-15 minutes, even though the BLE connection remained active.

The root cause was the phone's operating system. On Android, when the app moved to the background, the OS suspended the GATT client. The CCCD write (enabling notifications) was stored in the phone's RAM but not persisted by the BLE stack on the peripheral. When the phone's BLE stack internally recycled the connection (a low-level reconnection invisible to the app), the CCCD value reset to "notifications disabled" on the peripheral side, but the app assumed notifications were still enabled.

The fix was twofold: (1) the peripheral firmware checked whether the CCCD was enabled at every connection event and sent a Service Changed indication if not; (2) the app re-enabled notifications on every reconnection event, not just the first connection.

Lesson: BLE notification state is not persistent across reconnections by default. Always re-subscribe to notifications after reconnection, and design the peripheral to handle clients that forget to re-enable CCCDs.

What interviewers want to hear: You understand that BLE is fundamentally different from Classic Bluetooth -- designed for low duty cycle, not streaming. You can explain the GAP/GATT split: GAP handles discovery and connection, GATT handles data modeling. You know the GATT hierarchy (service, characteristic, descriptor) and the role of the CCCD. You can discuss connection parameter trade-offs (interval vs power vs latency) with concrete numbers. You are aware of BLE 5.0 improvements (2M PHY for speed, Coded PHY for range, extended advertising for larger payloads). You understand BLE security levels and know that "Just Works" provides encryption but not MITM protection.

Interview Focus

Classic Interview Questions

Q1: "What is the difference between GAP and GATT in BLE?"

Model Answer Starter: "GAP and GATT serve different purposes. GAP controls how devices find each other and establish connections -- it defines roles like Central and Peripheral, manages advertising and scanning, and handles the connection process. GATT defines how data is structured and exchanged after a connection is established -- it organizes data into services and characteristics using a client-server model. Think of GAP as the phone directory and dialing process, and GATT as the conversation format once the call connects. They are layered independently: GAP Central is usually the GATT Client, but this is convention, not a requirement."

Q2: "How do BLE connection parameters affect power consumption?"

Model Answer Starter: "Three parameters control the power trade-off. Connection Interval sets how often the radio wakes up -- a 1-second interval uses roughly 100x less power than a 10 ms interval. Peripheral Latency lets the peripheral skip connection events when it has no data -- a latency of 4 means it only wakes every 5th event, reducing power by approximately 5x. Supervision Timeout sets how long to wait before declaring a disconnect. For a battery-operated sensor reporting every 30 seconds, I would use a long interval (1-2 seconds), high latency (10-20 events), and a generous timeout (20-30 seconds). For an interactive device like a game controller, I need a short interval (7.5-15 ms) and zero latency."

Q3: "Explain the GATT data model and what a CCCD is."

Model Answer Starter: "GATT organizes data hierarchically: a Profile defines a use case, a Service groups related data points, and a Characteristic is a single data point with a value and properties like Read, Write, and Notify. A CCCD -- Client Characteristic Configuration Descriptor -- is a special descriptor attached to notifiable characteristics. The client writes 0x0001 to the CCCD to enable notifications or 0x0002 for indications. Without writing to the CCCD, the server will not push data even if the characteristic supports Notify. This is a common source of bugs -- if you connect but forget to enable the CCCD, you receive nothing."

Q4: "What are the key differences between BLE 4.x and BLE 5.0?"

Model Answer Starter: "BLE 5.0 introduced three major features. First, 2M PHY doubles the over-the-air data rate to 2 Mbps, which either increases throughput or reduces radio-on time for the same data -- saving power. Second, Coded PHY adds forward error correction, trading data rate for range -- S=8 coding achieves roughly 4x the range of 1M PHY, critical for long-range agricultural or industrial sensors. Third, Extended Advertising increases advertising payload from 31 bytes to 251 bytes using data channels, enabling richer broadcast data without a connection. A key nuance: 2M PHY does not increase range -- it actually slightly reduces it because faster modulation is more sensitive to noise."

Q5: "How does BLE security work, and what is the difference between pairing and bonding?"

Model Answer Starter: "Pairing is the process of establishing a temporary security context -- the two devices negotiate encryption keys. BLE offers four pairing methods: Just Works (no user interaction, no MITM protection), Passkey Entry (user enters a code, MITM protected), Numeric Comparison (user confirms displayed numbers match), and Out of Band (keys exchanged via NFC or similar). Bonding is storing those keys in non-volatile memory so devices can reconnect securely without re-pairing. After pairing, the link is encrypted with AES-128-CCM. For medical or access-control devices, Just Works is insufficient because an attacker can MITM the pairing -- I would use Passkey Entry or OOB."

Trap Alerts

• Don't say: "BLE is just a low-power version of Bluetooth" -- it is a completely different protocol stack, not a power-reduced Classic Bluetooth.
• Don't forget: The CCCD -- notifications do not work until the client explicitly enables them by writing to the CCCD. This is the number one BLE debugging issue.
• Don't ignore: Connection parameter negotiation -- the Central has final say. A peripheral can request parameters, but the Central can reject them, which causes real-world interoperability problems.

Follow-up Questions

• "How would you debug a BLE device that pairs successfully but cannot discover services?"
• "What is the maximum theoretical throughput of BLE 5.0 with 2M PHY and DLE?"
• "How does BLE Mesh differ from Zigbee mesh in terms of routing?"
• "What happens if a BLE peripheral advertises with a 10-second interval -- what are the consequences?"

Practice

Real-World Tie-In

Agricultural Sensor Network -- A soil moisture monitoring system deployed BLE 5.0 sensors across a 500-meter greenhouse. Using Coded PHY (S=8) with a 2-second advertising interval, each sensor ran on a CR2032 coin cell for over 14 months. The gateway (Nordic nRF52840) connected to sensors sequentially -- reading data, then disconnecting -- to avoid maintaining multiple simultaneous connections that would exhaust its RAM.

Wearable Health Monitor -- A continuous glucose monitor used BLE notifications with a 30 ms connection interval and zero latency to stream real-time glucose readings to a phone app. During the BLE certification process, testing revealed that certain Android phones rejected the connection parameter update requests, forcing a 50 ms interval. The firmware was updated to detect the phone model via the device name in the scan response and skip the parameter update request for known-problematic devices.

Retail Beacon System -- A chain of 200 stores deployed iBeacon-compatible BLE broadcasters (non-connectable advertising) for indoor positioning. Using a 100 ms advertising interval, each beacon consumed approximately 30 uA average current and lasted 8-10 months on two AA batteries. Switching to BLE 5.0 extended advertising allowed embedding store map data directly in the advertising payload, eliminating the need for an internet connection on the customer's phone to download map data.