6 Piconets, Scatternets and Power Classes
Piconets, Scatternets, and Power Classes
bluetooth, piconet, scatternet, central-peripheral, power class, network topology
6.1 Start With the Story
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.
Phoebe’s Why
A milliamp-hour rating counts charge – how many electrons the cell can push through a circuit – but it says nothing about voltage, so it is not yet energy. Energy is charge times the voltage that pushes it, which is why a 3 V coin cell and a 3.7 V lithium pouch cell with the same mAh number store different amounts of usable work. A real cell is also not a perfect voltage source: it has an internal resistance, so the instant current flows the terminal voltage sags below the open-circuit value, and that sag grows as the cell ages. The same dB arithmetic that sizes a Class 1 or Class 2 radio’s transmit power also decides how hard each transmit burst pulls on that sagging battery.
The Derivation
Energy from charge and voltage:
\[E = V \times Q\]
Terminal voltage under load, with internal resistance \(R_{int}\) (Thevenin model):
\[V_{term} = V_{oc} - I R_{int}\]
A power class in dBm converted to linear transmit power:
\[P(\text{mW}) = 10^{P_{dBm}/10}\]
Remaining charge after \(t\) self-discharge intervals at rate \(r\) per interval:
\[Q(t) = Q_0 (1-r)^t\]
Worked Numbers: A Coin-Cell BLE Tag
- Catalog-typical CR2032: \(V_{oc}=3.0\) V, \(Q_0=220\) mAh (nameplate). Energy \(E = 3.0\times0.220 = 0.660\) Wh \(= 660\) mWh.
- dBm check against this chapter’s power classes: Class 1, \(10^{20/10}=100\) mW – matches the +20 dBm / 100 mW figure above; Class 2, \(10^{4/10}=2.51\) mW – matches the +4 dBm / 2.5 mW figure.
- Voltage sag, fresh cell: assume a catalog-typical 7.5 mA draw during a Class 2 (+4 dBm) transmit burst and \(R_{int}\approx10\ \Omega\) fresh – \(\Delta V = 0.0075\times10 = 0.075\) V, terminal \(=2.925\) V. Barely noticeable.
- Voltage sag, aged cell: the same 7.5 mA burst against a catalog-typical end-of-life \(R_{int}\approx200\ \Omega\) – \(\Delta V = 0.0075\times200 = 1.50\) V, terminal \(=1.50\) V. The open-circuit voltage can still read a healthy 3.0 V on a meter, but under the transmit burst the rail collapses toward half the nameplate voltage.
- Self-discharge: at a catalog-typical \(r\approx1\%\)/year, \(220\times0.99^{5}=209\) mAh remains after 5 years – a 10.8 mAh (4.90%) shelf loss before the radio has sent a single advertisement, which is why a deployment budget should derate the nameplate mAh rather than spend it all.
6.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.
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.
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.
6.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.
6.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.
6.2.3 Overview Knowledge Check
6.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.
6.3.1 Architecture Evidence Ledger
6.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.
6.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.
6.3.4 Practitioner Knowledge Check
6.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. Walls, bodies, equipment, enclosures, antenna orientation, interference, and phone behavior can change the effective boundary. A power class, PHY, or transmit setting is only one part of the review.
Classic power classes are planning inputs, not acceptance proof. Class 1 radios are commonly associated with about +20 dBm / 100 mW and roughly 100 m line-of-sight conditions; Class 2 with about +4 dBm / 2.5 mW and roughly 10 m consumer-device conditions; and Class 3 with about 0 dBm / 1 mW for very short local links. The installed review still has to measure the real enclosure, body loss, interference, retry behavior, and security perimeter.
6.4.1 Drift and Retest Triggers
6.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.
6.4.3 Under-the-Hood Knowledge Check
6.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.
6.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.
6.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.