flowchart LR
standby([Standby])
advertising[Advertising]
initiating[Initiating]
connected[Connected]
standby --> advertising
advertising --> connected
standby --> initiating
initiating --> connected
connected --> standby
7 Device Discovery and Connection Setup
bluetooth-ble
connection
establishment
7.1 Start With the Story
A useful Bluetooth connection starts before the first value is read. Discovery, filtering, pairing, service discovery, parameters, subscriptions, and reconnection all have to line up before the device can be trusted in the field.
Use this chapter as a handshake trace. Follow one device from advertisement to usable session, and mark where the product accepts, rejects, retries, or asks the user for evidence.
7.2 Treat Connection Setup as a Chain of Evidence
Bluetooth connection establishment is the path from “a device might be nearby” to “the right application data can move under the reviewed conditions.” Classic Bluetooth and Bluetooth Low Energy use different discovery and connection procedures, but the review habit is the same: name the boundary that has actually been proven.
For BLE, discovery usually starts with advertising and scanning. A central may then initiate a connection, negotiate link behavior, complete security steps when required, discover GATT services, and subscribe to notifications or exchange reads and writes. Each step can pass while a later step fails.
Worked example: a cold-room sensor is commissioned by a phone before it joins the building gateway. The phone first has to see the setup advertisement, then connect while the sensor is still in setup mode, then complete the required pairing or authorization prompt, then discover the commissioning service, then write the gateway identifier and check the response. If the product promises setup in a 10-second user flow, the review should not record only “connected.” It should record whether the advertisement was visible with the door open and closed, whether retries still fit the setup window, whether failed pairing leaves the device in a recoverable state, and whether the app proves the credential write through a response or later gateway join.
That example also shows why a boundary label matters. “Phone saw the device” proves the discovery boundary. “Phone connected” proves a link boundary for the tested peers. “Credentials accepted and gateway join confirmed” proves the application handoff. Keeping those labels separate makes field debugging sharper: a later report of “setup failed” can be placed against advertising visibility, phone permissions, stale bonds, service discovery, credential write, or gateway handoff instead of becoming a vague Bluetooth complaint.
If you only need the intuition, this layer is enough: a successful Bluetooth connection is useful evidence, but it is not the same as proving discovery speed, pairing safety, GATT correctness, battery behavior, reconnection, or user recovery.
7.2.1 The Setup Boundaries
Discovery
Review whether the device can be found under the intended advertising, scanning, visibility, phone permission, enclosure, and radio conditions.
Connection
Review whether the expected initiator, advertiser, central, peripheral, or Classic role establishes the link with usable timing and recovery behavior.
Security
Review whether pairing, bonding, authorization, privacy, and reset behavior match the product claim instead of only proving that a link came up once.
Application handoff
Review whether service discovery, characteristic permissions, notification setup, command handling, and app interpretation match the workflow.
7.2.2 Beginner Examples
- A phone seeing a BLE advertisement proves discovery under tested conditions, not connection, GATT access, or battery life.
- A successful pairing flow proves a security ceremony only for the reviewed devices, user prompts, ownership model, and reset path.
- A connected sensor that never sends notifications may have a GATT subscription or authorization problem, not a discovery problem.
- A device that reconnects in the lab may still need field evidence for phone sleep behavior, RF shadows, firmware updates, and failed setup recovery.
7.2.3 Overview Knowledge Check
7.3 Build a Connection Review Record
A practical Bluetooth connection review record says what setup path is being approved and what would make that approval stale. It should show the initiating device, discoverability state, connection role, security ceremony, negotiated behavior, GATT or profile handoff, failure recovery, and retest trigger.
This record prevents teams from treating “connected once” as a broad release claim. A setup-only BLE workflow, a background sensor link, a Classic profile connection, and a mesh provisioning path all need different evidence.
7.3.1 Connection Review Ledger
Decision Area
Review Question
Evidence To Capture
Weak Claim
Discovery path
How does the intended peer find the device?
Advertising or inquiry state, scan behavior, device visibility, receiver permissions, enclosure, placement, and timeout expectation.
"A lab phone saw it once, so all users can find it."
Connection behavior
Which roles and timing are in scope?
Central, peripheral, initiator, advertiser, Classic role, connection interval behavior, retry policy, supervision timeout behavior, and reconnect rule.
"The link came up, so timing and recovery are solved."
Security ceremony
What trust decision happens during setup?
Pairing method, bonding rule, authorization, owner transfer, privacy behavior, lost-device handling, and reset procedure.
"Pairing occurred, so future ownership and privacy are automatically correct."
Application handoff
What proves the connection supports the product job?
Profile or service discovery, characteristic properties, permissions, notification or indication setup, command response, app state, and error handling.
"Connected means the app exchanged the right value."
7.3.2 Worked Review: Setup-Only BLE
A device uses BLE only to receive Wi-Fi credentials during first-run setup. The connection record should say when the device advertises setup mode, who is allowed to connect, what user proof or authorization is required, how credentials are protected, what timeout ends setup mode, and how the user recovers after partial setup.
The approval should not say that BLE is the product network. It should approve the reviewed commissioning path for the tested phones, app permissions, firmware, reset behavior, and recovery states.
7.3.3 Worked Review: Background Sensor Link
A wearable sends periodic measurements to a phone. The record should distinguish discovery, connection, bonding, notification subscription, missed-notification recovery, and phone sleep behavior. A central may reconnect successfully while the application still fails if the client does not resubscribe, the value format changed, or the authorization state expired.
7.3.4 Practitioner Knowledge Check
7.4 State Machines, Timers, and Reconnection
Under the hood, connection establishment is a sequence of state transitions. A device may advertise or become discoverable, a peer scans or inquires, the initiator requests a link, the controllers schedule connection events, security procedures establish trust when needed, and the application discovers services or profiles before doing useful work.
Classic Bluetooth is a useful contrast because its setup path is explicit: a device starts from standby, one side runs inquiry to discover nearby devices, and a potential slave answers with identity and clock information. The master then pages the chosen device, sends the Frequency Hop Synchronization packet, assigns the active member address used inside the piconet, and moves the link into connected mode. A connected device may be active, or it may save power through sniff, hold, or park behavior. Those states are not only implementation trivia: they explain why a piconet master schedules traffic to slaves and why slaves do not send directly to other slaves in the same piconet.
For a Classic review record, capture the device identity evidence separately from the friendly name. The Bluetooth device address (BD_ADDR) is a 48-bit value normally written as twelve hexadecimal digits; the upper 24 bits identify the manufacturer allocation and the lower 24 bits identify the device within that allocation. Friendly names are user-facing labels and can be duplicated, renamed, or include only part of the address for disambiguation, so they are not a substitute for address-level inventory evidence.
The inquiry and paging timers are also evidence. Classic inquiry uses wake-up carriers and inquiry-scan windows so undiscovered devices do not need to listen continuously. Paging then uses the discovered address and clock information to converge on the target’s hopping sequence. A setup failure can therefore sit in discoverability, inquiry scan timing, paging, piconet address assignment, pairing, or profile discovery; the review should name which boundary actually failed.
- Standby to Advertising: start advertising.
- Advertising to Connected: connection request accepted.
- Standby to Initiating: scan then connect.
- Initiating to Connected: link established.
- Connected to Standby: disconnect or supervision timeout.
Connection parameters and supervision behavior are operational evidence, not tuning trivia. Long gaps between radio events can save energy but make interaction slower. Aggressive timing can improve responsiveness but increase wakeups and failure sensitivity. The review should tie those choices to the product workflow, not to a generic “fast” or “low power” label.
7.4.1 Timer and State Retest Boundaries
Boundary
What It Proves
What It Does Not Prove
Retest Trigger
Advertising or inquiry
The device can be noticed by the reviewed peer under the tested visibility and radio conditions.
Pairing, bonding, GATT access, notification delivery, or long-term battery behavior.
Advertising policy, scan policy, enclosure, antenna, phone permission, site layout, or firmware change.
Link setup
The expected peer can establish the link and maintain initial timing under reviewed conditions.
Correct service data, authorization, recovery after sleep, or support across all phones and gateways.
Connection timing, peer population, controller firmware, retry policy, gateway placement, or sleep behavior change.
Security and bonding
The reviewed devices complete the intended trust and key-persistence behavior.
That lost phones, owner transfer, factory reset, privacy rotation, or stale bonds are handled safely.
Pairing method, user interface, bond storage, ownership model, reset process, or privacy requirement change.
Application readiness
The application can discover the expected service or profile and complete the reviewed read, write, command, or subscription.
That future schemas, app versions, phone permissions, or disconnected recovery paths remain compatible.
Service schema, characteristic property, app mapping, permission model, notification policy, or reconnect rule change.
7.4.2 Diagnosis Pattern
- Place the failure. Decide whether the symptom is discovery, link setup, security, service discovery, subscription, application interpretation, power, or reconnection.
- Keep proven boundaries. Do not erase evidence that advertising and scanning worked while debugging a later GATT or security failure.
- Change one variable. Phone permissions, advertising policy, connection timing, firmware, enclosure, bonding state, and app version should be tested separately.
- Record the retest trigger. A new phone OS, enclosure, connection schedule, service schema, or ownership process can invalidate the old connection evidence.
7.4.3 Under-the-Hood Knowledge Check
7.5 BLE Connection Establishment Workbench
7.6 Summary
- Bluetooth connection establishment should be reviewed as a chain of evidence: discovery, link setup, security, application handoff, and recovery.
- Classic Bluetooth and BLE use different setup procedures, so the review should name the exact behavior being approved.
- A visible advertisement or one successful connection does not prove pairing safety, GATT correctness, battery behavior, or reconnection recovery.
- Pairing, bonding, authorization, privacy, timeout behavior, and ownership transfer need explicit evidence when they are part of the product claim.
- Retest triggers should be recorded for phone, firmware, enclosure, timing, service schema, app, permission, ownership, and site changes.
7.7 Key Takeaway
Approve Bluetooth connection setup only when the reviewed discovery path, role, timing, trust flow, application handoff, recovery behavior, and retest triggers match the product job.
7.8 See Also
Review the Classic, BLE, advertising, connection, GATT, power, and evidence boundaries behind each setup path.
Follow the service, characteristic, permission, notification, indication, and application data model after connection.
Connect setup evidence to the larger topology choice: piconet, central-peripheral, gateway, bridge, or mesh.
Deepen the trust-flow review across pairing methods, bonding, authorization, privacy, and MITM boundaries.