3 Bluetooth: BLE Profiles and Operations

3.6 Bluetooth Fundamentals for IoT

Start with the behaviour, not the logo. Classic Bluetooth usually carries steady streams such as audio and supports older, well-known device profiles. BLE usually carries short exchanges such as sensor reports, beacons, phone setup, and small control messages. A duty cycle is the share of time for which the radio is active. Short duty cycles let a BLE device sleep for longer. Bluetooth Mesh is a managed way for many devices to pass control messages. It is not simply one phone connection made larger.

The key idea is that “Bluetooth works” is not one claim. Discovery means that another device can find it. Pairing creates a trusted relationship. Connection setup opens a data path. GATT services describe the data available on that path. Timing, power use, privacy, phone support, and recovery after failure each need their own test.

Radio Remi

“Range, power, and data-rate is a triangle — pick two honestly, then measure the third in the real room.”

Through this chapter, Remi tags each Bluetooth behavior with its band, its trade, and the room measurement that proves it.

Inspect Figure 3.1. It shows that Classic and BLE share basic controller and radio functions. Their higher-level rules are different. The figure turns the vague phrase “Bluetooth support” into a set of parts that can be tested.

Read Figure 3.1 from the 2.4 GHz radio at the bottom upward. The controller runs the radio. A host interface connects that controller to the main software. On the BLE side, L2CAP carries the rules used by ATT/GATT and SMP. GAP defines how devices are found and which role each device takes. Classic Bluetooth uses different higher-level rules for steady streams. This explains a practical choice. A shipping logger can send short announcements and offer brief GATT reads, so BLE fits. A headset sends steady audio, so it needs different evidence for its profile, timing, compatibility, and power use.

One product may use several of these behaviours. During warehouse setup, a phone may act as the central device and write settings. During transport, gateways may only listen for announcements. During service, a technician may connect and read fault details. Calling all three cases “BLE support” hides important differences. Record the behaviour being approved, the other device involved, the data that moves, and the change that would require another test.

3.7 Build the Bluetooth Fundamentals Record

A practical Bluetooth fundamentals record explains why the chosen Bluetooth behavior fits the IoT job. It should show the device role, traffic pattern, receiver population, service model, timing, security ceremony, power expectation, and retest trigger. This keeps design review from sliding between Classic, BLE, advertising, connection, GATT, mesh, and gateway claims.

Use this record early. Before writing firmware, it catches mismatches such as selecting BLE for sustained high-rate traffic, using a beacon when the app needs acknowledged commands, or assuming a phone setup flow works across every phone and permission state.

3.8 Radio, Link, GATT, and Operations Boundaries

Bluetooth behavior moves through several evidence boundaries. A device may be visible during advertising, connect as the expected role, expose services through GATT, exchange an application value, and then recover after disconnection. Each boundary can pass or fail independently.

That separation matters because the fix changes by boundary. A scan problem may involve advertising interval, phone permissions, or RF placement. A read problem may involve pairing, service discovery, characteristic properties, or app mapping. A power problem may involve connection interval, retry behavior, sleep state, or a failed reconnection loop.