8 Piconets, Scatternets and Power Classes
8.1 Start With the Story
Picture a sports hall with thirty heart sensors, one coach’s tablet, and a display by the door. Some data belongs in a private link. Some may be sent to many listeners. Other devices may need a relay to reach the edge of the hall.
Start with the conversation, not the Bluetooth label. Mark who sends, who listens, how often data moves, and which device may make a decision. Then choose a network shape that fits those roles. Test it when the room is busy, a relay leaves, or the tablet sleeps.
Record range, delay, battery use, and recovery. A link that works with two devices on a desk does not prove that thirty devices can share the air. A mesh can extend a path, but it adds relay work and delay. A broadcast can reach many listeners, but it does not create a private reply path by itself.
Go deeper in two steps. The Practitioner section builds the Bluetooth Architecture Record. Under the Hood explains scheduling, range, and the changes that should trigger a new test.
Make a role card for each device. Mark send, listen, relay, sleep, and control. A device may hold more than one role, but each role uses time and power. Draw the normal path in one colour. Draw the recovery path in another.
Now make a short test list. Start with one sender. Add the expected group. Add a busy nearby radio. Move a listener to the edge. Turn off a relay. Let a phone sleep and wake. Record loss, delay, join time, and battery cost for each step.
Review the shape when the space changes. A new wall, more tags, a new phone model, or a moved gateway can change the result. Keep a trigger beside the design record. That trigger tells the team when old proof is no longer enough.
A room full of tags, phones, gateways, and relays can look simple on a diagram while failing in motion. The architecture choice decides who initiates, who listens, who relays, who sleeps, and what happens when the space changes.
Read this chapter as a shape decision. Start with the installed environment, then choose central/peripheral roles, broadcast behavior, piconets, or mesh only after the reliability, power, and maintenance evidence fits the job.
8.2 Choose the Bluetooth Shape That Matches the Job
Bluetooth network architecture review starts by naming the communication shape. Classic Bluetooth piconets use one controller to schedule a small set of active devices. BLE central-peripheral links are usually better for phone-to-device setup, small sensor reads, notifications, and duty-cycled local exchange. Bluetooth Mesh is a managed many-node control architecture with provisioning, relay, security, and operations requirements.
The architecture decision is only valid inside its evidence boundary. A piconet diagram does not prove capacity. A phone connection does not prove fleet behavior. A mesh label does not prove relay placement, low-power node support, or maintainability after a device moves.
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 topology claim with its band, its trade, and the room measurement that proves it.
Worked example - clinic temperature tags. Suppose twenty BLE temperature tags report every five minutes, two hallway gateways are mains-powered, and nurses occasionally use tablets for setup. The smallest credible shape is not a Classic piconet: the tags do not need a Classic profile and should not stay scheduled as active members of one controller. It is also not automatically Bluetooth Mesh: the tags only publish small readings, and making battery tags participate in mesh roles would add provisioning and friend/low-power evidence before the team has proved it needs building-wide relay.
A stronger first architecture is BLE collection. Tags advertise or connect briefly; gateways scan known rooms, de-duplicate readings, and forward data upstream; tablets use local BLE setup only during commissioning. The review then asks measurable questions: how long does discovery take at the far room, how many duplicate readings are tolerated, what advertising interval meets the battery target, who owns gateway replacement, and which site change forces a retest? If later requirements add room-to-room group control for mains-powered devices, that is a new mesh claim with its own relay, key, and operations evidence.
The clinic example uses BLE collection, but a legacy Classic design needs a different capacity and dependency review. Use Figure 8.1 to distinguish membership inside one scheduled piconet from the bridge role that joins piconets. The diagram is worth inspecting now because those two relationships create different failure boundaries; merely counting all visible devices as one Bluetooth network would conceal them.
Begin Figure 8.1 at Piconet 1 and use the Device Roles legend to decode its M, S, and I nodes: one master schedules the participating slaves, while an idle device is drawn nearby without becoming another active scheduled member. Move next to Piconet 2 and locate the node stamped M/S Bridge. Its two role letters matter—it participates in more than one piconet and must time-share those memberships rather than merging their slot schedules. Finally compare Piconet 3 with the first two and read the note that multiple piconets connected through an M/S bridge form a scatternet. That ordered inspection turns the topology into review questions about controller dependency, active membership, bridge latency, and recovery. It also reconnects the Classic case to the clinic decision: BLE gateways or Bluetooth Mesh should not be justified by treating this legacy bridge structure as their capacity model.
If you only need the intuition, this layer is enough: approve the topology behavior that was observed, not the topology name. Then write the role, capacity, range, power, owner, and retest trigger.
8.2.1 Architecture Choices
Review the controller role, active-device limit, time-slot scheduling, profile fit, range expectation, and whether the product really needs Classic behavior.
Review who advertises, who scans, who connects, how long the connection stays open, and what GATT behavior supports the product claim.
Review bridge custody, time-sharing, latency, failure behavior, and why a legacy bridge is better than simpler gateways or BLE Mesh.
Review provisioning, relay behavior, friend and low-power roles, message scope, key ownership, monitoring, and operations support.
8.2.2 Beginner Examples
- A small gateway collecting occasional BLE sensor readings does not need a Classic piconet just because both technologies are Bluetooth.
- A Classic piconet can be acceptable for a bounded legacy profile, but the active-device limit and controller dependency should be explicit.
- A mesh claim is strongest when relay placement, low-power node behavior, message scope, and recovery ownership are recorded.
8.2.3 Overview Knowledge Check
8.3 Build the Bluetooth Architecture Record
A practical Bluetooth architecture record starts from the product job: local setup, sensor collection, audio or legacy profile, gateway handoff, room-scale control, building automation, or diagnostics. It then chooses the smallest Bluetooth shape that supports that job and records the evidence that would make the decision stale.
The record should be specific about roles. Classic Bluetooth uses a scheduled piconet model. BLE connected operation has central and peripheral roles. BLE advertising has broadcaster and observer behavior. Mesh adds provisioner, relay, friend, low-power, and managed key roles. Mixing those roles in one claim makes the review hard to maintain.
8.3.1 Architecture Evidence Ledger
8.3.2 Worked Review: Room Sensors and Gateways
A clinic wants room-level temperature tags, staff tablets, and a few mains-powered hallway gateways. The tags send small readings and do not need direct tag-to-tag communication. A BLE gateway collection pattern is a stronger first decision than a Classic piconet: tags can advertise or connect briefly, gateways can own nearby rooms, and the review can focus on discovery latency, duplicate readings, battery draw, and gateway coverage.
Bluetooth Mesh may still be useful for mains-powered infrastructure if room-to-room relay behavior or group control becomes part of the job. It should not be approved simply because the tag count is large. Mesh adds provisioning, relay, key, and operations evidence that small battery tags may not be suited to carry.
8.3.3 Worked Review: Legacy Piconet Boundary
A legacy peripheral may require Classic Bluetooth profile behavior. The architecture record can accept a bounded piconet claim when the controller role, active-device count, profile behavior, range expectation, and failure recovery are known. The record should state what happens when the active-device count grows, a controller is replaced, or the product needs peer-to-peer or many-node behavior outside the piconet.
Older material may describe this as a master/slave piconet. The useful engineering point is the scheduling boundary: the controller owns the clock, hopping sequence, and transmission opportunities, so active devices synchronize to that schedule and do not get arbitrary direct slave-to-slave traffic. That makes the seven-active-device limit, the controller dependency, and bridge or scatternet behavior part of the capacity claim rather than trivia.
Remi’s Signal Check
- Band: a Classic piconet schedules up to seven active devices under one controller’s clock and hopping sequence.
- Trade: that scheduling buys synchronized slots, not arbitrary slave-to-slave traffic — capacity is a controller-dependency claim, not trivia.
- Room test: record what happens when the active-device count grows or the controller is replaced — that is the retest trigger.
8.3.4 Practitioner Knowledge Check
8.4 Scheduling, Range, and Architecture Drift
Under the hood, Bluetooth architecture is shaped by scheduling and duty cycle. Classic piconets are controlled by a central scheduler, so active member count and controller dependency matter. BLE devices can spend much of their life advertising, scanning, connecting briefly, or sleeping, so connection parameters and retry behavior matter. Mesh nodes add relay and managed-flood behavior, so message scope and relay placement matter.
Range evidence should be treated as installed evidence, not only a catalog number. Inspect Figure 8.2 to compare the three Classic power classes as planning shorthand, then test whether walls, bodies, equipment, enclosures, antenna orientation, interference, and receiver behavior change the effective boundary. A power class, PHY, or transmit setting is only one part of the review.
Read Figure 8.2 from Class 1 through Classes 2 and 3, comparing transmit power in dBm and milliwatts before looking at the rough line-of-sight ranges. Then move to the evidence band: enclosure and body loss, interference, antenna orientation, receiver behavior, and retries can overturn the catalogue shorthand. This is why the architecture record carries a measured site walk and security perimeter rather than promising range from power class alone.
Remi’s Signal Check
- Band: Class 1 ~+20 dBm / 100 mW / ~100 m; Class 2 ~+4 dBm / 2.5 mW / ~10 m; Class 3 ~0 dBm / 1 mW for very short links.
- Trade: a power class is a planning input, not acceptance proof — the catalog number and the installed link are different claims.
- Room test: log the transmit setting and the measured range together before approving the site.
8.4.1 Drift and Retest Triggers
8.4.2 Diagnosis Pattern
- Name the architecture claim. Separate Classic piconet capacity, BLE collection, gateway handoff, and mesh relay claims.
- Preserve the role evidence. Record controller, central, peripheral, broadcaster, observer, provisioner, relay, friend, and gateway roles before changing firmware.
- Retest the changed boundary. A moved gateway, new enclosure, changed connection interval, phone OS update, or mesh relay removal invalidates different evidence.
- Narrow the approval. Approve the tested topology behavior and record which scale, range, power, recovery, or ownership claim remains unproven.
8.4.3 Under-the-Hood Knowledge Check
8.5 Summary
- Bluetooth network architecture review starts by naming the topology behavior: Classic piconet, BLE central-peripheral, advertising collection, bridge, gateway, or mesh.
- Classic piconet claims need controller, active-device, scheduling, profile, range, and recovery evidence.
- BLE collection claims need advertising, scanning, connection timing, GATT path, battery, gateway, and phone-scope evidence.
- Bluetooth Mesh claims need provisioning, relay, key, message-scope, low-power node, and operations evidence.
- Installed range and power evidence should be retested after enclosure, placement, firmware, gateway, phone, traffic, or ownership changes.
8.6 Key Takeaway
Approve a Bluetooth architecture only when the reviewed roles, topology, capacity, timing, range, power behavior, ownership, and retest triggers match the product job.
8.7 See Also
Review the broader Bluetooth fit decision across Classic, BLE, roles, profiles, security, power, and evidence boundaries.
Connect architecture decisions to Classic, BLE, advertising, connection, GATT, security, and recovery fundamentals.
Follow services, characteristics, notifications, indications, permissions, and app meaning after the link shape is chosen.
Review advertising, scanning, connection setup, pairing, bonding, parameters, and reconnection evidence in detail.