2 The Bluetooth Landscape
2.1 Start With the Story
Imagine a wearable sensor beside a phone. A successful scan proves only that a radio was nearby; it does not yet prove the product has the right power budget, data contract, security boundary, or failure behavior.
Read this overview from that first observation outward. Separate Classic Bluetooth, BLE, profiles, roles, and mesh by the evidence each one can provide, then choose the path that matches the IoT job instead of the familiar brand name.
2.2 What Bluetooth Is Good For
Bluetooth is a short-range wireless family for devices that need local connectivity rather than direct Internet reach. The name covers several design choices: Classic Bluetooth for sustained streams, Bluetooth Low Energy for small duty-cycled data, and Bluetooth Mesh for managed many-to-many lighting and building-control use cases.
The first review question is not “does it support Bluetooth?” The useful question is which Bluetooth behavior is being approved: audio streaming, a connected BLE sensor, a connectionless beacon, a phone-based commissioning path, or a mesh control network. Each behavior has a different power, topology, security, and interoperability record.
Worked example - one product, three Bluetooth claims. A smart door sensor may use BLE advertising to announce wake-up events, a short GATT connection for configuration from a phone, and a bonded encrypted link for owner-only settings. Those are not one generic “Bluetooth works” claim. The advertising claim needs interval, payload, receiver, privacy, and battery evidence. The configuration claim needs phone population, permissions, pairing method, timeout, and recovery evidence. The ownership claim needs bonding, key reset, lost-phone handling, and a way to transfer the device without exposing it to the next passer-by.
The same discipline prevents over-choosing technology. If the sensor only reports to a nearby gateway every few minutes, BLE collection may be enough. If the product streams audio, Classic Bluetooth or an audio profile is the relevant review boundary. If mains-powered lights must relay group commands through rooms, Bluetooth Mesh becomes a separate architecture decision with provisioner, relay, friend, low-power, key, and support responsibilities. A good overview record names the behavior first, then narrows the evidence to range, power, security, application meaning, and the change that reopens the review.
If you only need the intuition, this layer is enough: choose Bluetooth when the product needs short-range local interaction, phone access, low-power sensor exchange, or a standard profile. Do not treat the word “Bluetooth” as proof of range, battery life, security, or application compatibility.
2.2.1 The Core Bluetooth Choices
Best suited to sustained streams and established profiles such as audio, headsets, input devices, and serial-style links where continuous connection behavior is expected.
Best suited to sensors, wearables, beacons, locks, labels, commissioning, and phone-adjacent IoT devices that can sleep between short radio events.
Application meaning comes from profiles, services, characteristics, permissions, notifications, indications, and writes, not from the radio label alone.
Pairing, bonding, key custody, privacy behavior, firmware changes, phone-OS changes, and retest triggers define whether a deployment remains reviewable.
2.2.2 Beginner Examples
- A heart-rate wearable is usually a BLE problem because it sends small measurements and spends much of its time sleeping.
- A speaker playing phone audio is usually a Classic Bluetooth or Bluetooth audio-profile problem because the stream is continuous.
- A beacon that only announces an identifier may never need a connection, but it still needs advertising interval, privacy, battery, and receiver evidence.
- A phone setup flow proves a commissioning path only for the tested phones, OS versions, permissions, and recovery behavior.
2.2.3 Overview Knowledge Check
2.3 Build the Bluetooth Design Record
A practical Bluetooth design record should let another engineer repeat the choice. It states the use case, traffic pattern, radio mode, role, profile or service model, security ceremony, power budget, coexistence assumption, receiver population, and the change that reopens the decision.
Early design may record assumptions. A release review should replace assumptions with observations from representative devices, enclosures, phones, firmware, site conditions, and failure cases. Keep the approval narrow when evidence is narrow.
2.3.1 Worked Review: Battery Sensor to Phone
A battery sensor reports temperature to a phone app every few minutes. The safe design record names BLE peripheral behavior, the central phone population, the GATT service and characteristic, notification or read behavior, advertising interval, connection interval, reconnection path, pairing rule, sleep current assumption, and the phone or firmware changes that require retest.
The approval should not claim general Bluetooth compatibility. It should say that this sensor, app, firmware, phone set, and power budget support the reviewed reporting workflow under the tested conditions.
Phoebe’s Why
The battery sensor above reduces to “sleep current” plus “advertising interval,” but a coin cell does not experience either as a clean spreadsheet number. Every advertising or connection burst is a real current pulse that sags the cell’s terminal voltage through its own internal resistance, the nameplate mAh keeps eroding from self-discharge through every second of sleep, and a design margin has to come off the top before mAh becomes a trustworthy Wh budget. This is exactly why the “Diagnosis Pattern” below tells a reviewer to inspect intervals and wake behavior before blaming the cell – the interval, not the cell chemistry, usually decides which term in that energy chain dominates.
The Derivation
Internal resistance sags the terminal voltage under every burst, and only a derated charge becomes a trustworthy energy budget:
\[V_{term} = V_{oc} - I\,R_{int}, \qquad E_{usable}(\mathrm{Wh}) \approx Q_{usable}(\mathrm{Ah})\times V, \qquad Q_{usable}=f_{derate}\times Q_{nominal}\]
Average current from a periodic short radio burst, plus baseline sleep current:
\[I_{avg} = I_{sleep} + f_{event}\times t_{event}\times I_{active}\]
Antenna gain sets how much conducted power – and therefore active current – a fixed EIRP cap requires:
\[\mathrm{EIRP(dBm)} = P_t(\mathrm{dBm}) + G(\mathrm{dBi})\]
Worked Numbers: A Coin-Cell Advertising Budget
The chapter names no cell or interval, so take a standard/typical CR2032 (3.0 V, 220 mAh, \(R_{int}\approx15\ \Omega\)) advertising once per second (a common battery-conscious interval), with a standard/typical BLE SoC (~5.4 mA active during ~0.9 ms of three-channel legacy advertising, ~2 \(\mu\)A sleep):
- Energy per advertising event: \(0.0054\times3.0\times0.0009 = 14.6\ \mu\text{J}\); charge per event: \(0.0054\times0.0009 = 4.86\ \mu\text{C}\)
- At 1 Hz (86,400 events/day): active energy \(=1.26\) J/day, active charge \(=0.117\) mAh/day
- Sleep contribution: \(2\ \mu\text{A}\times3.0\ \text{V}=6.00\ \mu\text{W} \Rightarrow 0.518\) J/day, \(0.048\) mAh/day
- Total: \(1.78\) J/day, \(0.165\) mAh/day; derated budget at 80%: \(Q_{usable}=176\) mAh, \(E_{usable}=1900.8\) J
- Life estimate (charge basis): \(176/0.165=1067\) days \(=2.93\) years – confirmed by the energy basis: \(1900.8/1.78=1068\) days \(=2.93\) years
Now apply the antenna-gain line from the “Operations” retest trigger above. If enclosure detuning costs 2 dBi of gain, holding the same EIRP needs +4 dBm more conducted power, which roughly doubles active current on this SoC class (a commonly cited ~5 mA to ~10 mA step from 0 to +4 dBm). Active energy doubles to 2.52 J/day, total rises to 3.04 J/day, and life falls to \(1900.8/3.04=625\) days \(=1.71\) years – a battery claim moving by more than a year from an antenna change alone, exactly why “antenna” sits on the same retest-trigger line as “battery.”
2.3.2 Worked Review: Local Commissioning Path
A device uses BLE only for setup before it joins another network. That is a commissioning claim, not a permanent data-network claim. Review device discovery, ownership transfer, authentication, timeout, recovery after failed setup, privacy behavior, and what happens when the phone app is absent or permissions change.
The safe approval statement is narrow: BLE is acceptable for the reviewed setup workflow if the device can recover from partial provisioning and if the security record prevents unauthorized reconfiguration.
2.3.3 Practitioner Knowledge Check
2.4 Layer Handoffs and Failure Boundaries
Bluetooth failures are often misdiagnosed because several layers are visible at once. A phone may discover a device but fail to pair. A link may be encrypted but still expose the wrong characteristic permission. A notification may arrive correctly but drain the battery because the connection schedule is too aggressive. A beacon may be visible in a lab and unreliable in a crowded RF site.
The review should preserve the handoff from radio behavior to role behavior to application meaning to security custody to operations. That does not require packet-level proof for every lesson. It does require enough separation that a later engineer can tell where the claim stopped being proven.
2.4.1 Diagnosis Pattern
- Name the failing layer. Separate discovery, connection, pairing, service discovery, data exchange, power, and application interpretation before changing design assumptions.
- Check the closest proof below the symptom. If notifications stop, confirm link and subscription state before rewriting application parsing. If battery drains, inspect intervals and wake behavior before blaming the cell.
- Retest with one variable changed. Phone model, OS version, app permissions, enclosure, antenna position, firmware, and RF environment can each change the observed Bluetooth behavior.
- Write the unsupported claim. If only one phone, one room, one firmware, or one service was tested, keep the approval limited to that boundary.
2.4.2 Under-the-Hood Knowledge Check
2.5 Summary
- Bluetooth design starts with a bounded behavior claim, not with the protocol label.
- Classic Bluetooth, BLE connections, BLE advertising, Bluetooth Mesh, profiles, and services support different IoT jobs.
- A review record should preserve use case, mode, role, profile or service model, security, power, receiver population, and retest triggers.
- Discovery evidence does not prove connection, pairing, GATT behavior, application meaning, or long-term battery life.
- Power claims require duty-cycle and wake-behavior evidence from the actual device, not just a BLE label.
- Operational readiness depends on ownership, recovery, lost-device handling, app or phone changes, and firmware retest boundaries.
2.6 Key Takeaway
Approve Bluetooth only when the reviewed behavior is tied to mode, role, application model, security custody, power evidence, receiver population, owner, and retest boundary.
2.7 See Also
Compare sustained Classic behavior with duty-cycled BLE behavior for IoT traffic, latency, and battery trade-offs.
Trace radio, link, L2CAP, ATT, GATT, profiles, and service evidence through a Bluetooth design.
Review discovery, advertising, scanning, pairing, bonding, parameters, and reconnection behavior.
Review pairing methods, encryption, authorization, privacy behavior, ownership transfer, and retest boundaries.