9 Device Discovery and Connection Setup
9.1 Start With the Story
A gateway is a device that passes data between a local device and another network. Picture a cold-room sensor that must tell a phone which gateway it should use. Seeing the sensor nearby is only the first step.
An advertisement is a short radio notice that says a Bluetooth device is present. A phone scans for that notice and may ask to connect. Pairing checks whether the two sides may trust each other. A service then groups the data and commands the app may use.
Follow the steps in order: see the right device, connect, prove trust, find the right service, send the setup value, and check the reply. Record where a retry begins and how the user can recover from a wrong choice or old trust record.
This simple chain treats one phone and one sensor at a time. Real products may have many services, link settings, phone rules, and security modes. The Practitioner section follows those choices. Under the Hood covers timing, radio events, and data rules in detail.
Try the setup with the door open and shut. Turn phone radio access off, then on. Choose the wrong device once. Cancel pairing once. Let the setup time out. At each fault, the app should say what failed and give a safe next step.
After setup, restart the phone and sensor. Move out of range and return. Remove an old trust record. The product should reconnect when it is safe or ask for trust again when it is not. Keep a log that shows which boundary passed.
A good final record says more than “connected.” It names the tested phone, sensor build, distance, security step, service, result, retry, and gateway join. It also states which phones and field sites were not tested.
Keep each message short for the user. “Device not found” points to the scan step. “Trust check failed” points to pairing. “Setup value not saved” points to the service write. These messages help the user act and help support find the same fault.
End the test by removing access. The old phone should not keep control after the product says it was removed.
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.
9.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.
9.2.1 The Setup Boundaries
Review whether the device can be found under the intended advertising, scanning, visibility, phone permission, enclosure, and radio conditions.
Review whether the expected initiator, advertiser, central, peripheral, or Classic role establishes the link with usable timing and recovery behavior.
Review whether pairing, bonding, authorization, privacy, and reset behavior match the product claim instead of only proving that a link came up once.
Review whether service discovery, characteristic permissions, notification setup, command handling, and app interpretation match the workflow.
9.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.
9.2.3 Overview Knowledge Check
9.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.
9.3.1 Connection Review Ledger
9.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.
9.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.
9.3.4 Practitioner Knowledge Check
9.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. Inspect Figure 9.1 to trace how discovery evidence becomes one selected link: a device starts from standby, one side runs inquiry, and a potential slave answers with identity and clock information before paging begins. Keep that ordered setup separate from the connected power states shown next.
-
Remi finds several nearby devices.
-
The phone picks the intended device, not just the loudest one.
-
The phone and device complete their trust check.
-
The phone finds the needed service and sets the link.
-
The phone subscribes to the value it needs.
-
One real value arrives. Now the session is usable.
In Figure 9.1, follow inquiry and its response first, then paging, the Frequency Hop Synchronization packet, active-member address assignment, and the transition to connected mode. Each boundary produces different evidence, so a friendly name discovered during inquiry does not prove that paging, address assignment, authentication, or profile setup succeeded. With the link established, turn to Figure 9.2 to see how the controller trades activity for power.
Read Figure 9.2 from standby through inquiry or paging into the connected state, then inspect active, sniff, hold, and park. Sniff schedules listening windows, hold pauses normal traffic for an agreed interval, and park gives up the active-member address until the master unparks the device. These transitions explain both controller scheduling and reconnection symptoms. They also show why Classic setup and BLE setup feel different in the field: timing depends on procedure, backoff, retries, and current radio conditions rather than a single guaranteed connection time.
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.
9.4.1 Classic inquiry and paging timers
Classic discovery is a rendezvous problem: the inquiring radio and the discoverable radio must land on the same carrier at the same time even though they do not yet share a piconet clock. The inquiry procedure visits a 32-carrier wake-up set drawn across the 79 one-megahertz Classic channels. A discoverable controller periodically opens an inquiry-scan window; a representative controller schedule uses an 11.25 ms window every 1.28 s. Those values describe the configured scan schedule, not a promise that every product will be found in 11.25 ms. If the inquiry transmission misses the window, it must continue hopping until a later overlap.
Once a scanner hears an inquiry ID packet, it does not let every nearby device answer in the same reply slot. It chooses an integer backoff uniformly from baseband slots. With a 625 microsecond slot, the added wait is therefore
so the random component ranges from 0 to 639.375 ms. After that wait, the device resumes inquiry scanning; when it receives a subsequent inquiry packet, it returns an FHS packet. The FHS response supplies the information the initiator actually needs for the next phase: the responder’s Bluetooth address and native-clock information from which a clock offset can be estimated. A friendly name may be fetched later and is not part of this timing proof.
Paging changes the question from “who is present?” to “can I synchronize with this particular address?” The pager transmits an ID packet containing the target’s Device Access Code (DAC) while following a page-hopping sequence derived from the target address and estimated clock. Be precise about the bit widths: the DAC access code is constructed from the target’s 24-bit lower address part (LAP); it is not merely a 24-bit address field on air. The target returns the first page response, the pager sends an FHS packet carrying the master’s clock and address information, and the target acknowledges with the second page response. Only then can both controllers use the master’s hop timing for the connection.
The final local identifier is the 3-bit active-member address, AM_ADDR. Values 1 through 7 identify the seven simultaneously active slaves in a Classic piconet; zero is reserved for broadcast traffic. Assignment of AM_ADDR is useful evidence that the paging exchange reached connected state, but it does not prove authentication, encryption, profile discovery, or application readiness.
| Phase | Radio action | Evidence produced | Timing or failure boundary |
|---|---|---|---|
| Inquiry scan | Listener opens a short window on its inquiry-scan hop sequence | The device was discoverable during an actual overlap | Scan interval, scan window, interference, and missed rendezvous |
| Inquiry response | Listener backs off, hears a later inquiry, then sends FHS | Address and clock-offset evidence become available | Random 0–1023-slot delay and response collision |
| Page | Initiator targets the DAC on a page-hop sequence | The chosen device, rather than any discoverable device, is addressed | Stale clock estimate, paging timeout, RF loss |
| FHS hand-off | Initiator sends master address and clock information | Both sides can derive the connection hop sequence | FHS loss or failed second page response |
| Connection | Master assigns AM_ADDR and may poll | Active piconet membership for this link | Authentication, profile, and application work still remain |
For a field trace, log the scan interval and window, inquiry duration, random-backoff behavior if exposed by the controller, FHS receipt, page timeout, assigned AM_ADDR, and the later security/profile result as separate events. That record turns “Bluetooth setup was slow” into a timer or state hypothesis that can be retested.
- 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.
9.4.2 Timer and State Retest Boundaries
9.4.3 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.
9.4.4 Under-the-Hood Knowledge Check
9.5 Discovery And Pairing Explorer
Start by naming the protocol family. BR/EDR inquiry and SDP, BLE advertising/scanning and GATT, and Bluetooth Mesh provisioning are different procedures. Do not use “beacon,” “pairing,” or “service discovery” as if they identify the same packets or security state.
For BLE, the primary advertising channels are 37, 38, and 39. They create discovery opportunities; they do not prove that every channel was heard or that the later connected data-channel map is healthy. Once connected, the link layer uses data channels and adapts its channel map. A review therefore keeps advertising visibility, connection establishment, pairing/bonding, GATT discovery, authorization, and sleep/reconnection as separate evidence rows.
Run the explorer twice with the same radio settings but different permission state, then with a shorter scan window. This separates an application-policy failure from a radio-duty-cycle trade-off. In the bench record, capture controller and OS versions, advertised identity and privacy behavior, channels observed by a sniffer, scan policy, permission prompt and denial path, pairing method, service/profile discovery, authorization result, current trace, reconnect after sleep, bond deletion, owner transfer, and factory reset.
9.6 BLE Connection Establishment Workbench
9.7 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.
9.8 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.
9.9 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.