When multiple wireless devices communicate within a small personal area network, they organize into short-range groups with defined roles. One common question is what to call slave devices that are connected to a piconet and are sending transmissions within that group.
Understanding the precise terminology helps engineers, developers, and technical managers configure reliable Bluetooth and similar networks. The following sections clarify the standard naming, behavior, and configuration options for these participating devices.
| Role Name | Direction | Typical Usage | Connection Logic |
|---|---|---|---|
| Active Slave | Receives and sends | Audio streaming, HID input | Scheduled in dedicated slots |
| parked | Low power, no data | Saves energy while maintaining membership | Reserves channel for quick return |
| sniff | Periodic receive and send | Low-priority background traffic | Extended inter-slot intervals |
| Hold | Pauses activity | Temporary traffic freeze | Maintains link supervision without scheduling |
Active Participation in the Piconet
In a Bluetooth piconet, one master coordinates timing and channel access while supporting nodes take on specific tasks. Devices labeled as slaves that are connected to a piconet and are sending transmissions follow the master schedule but still originate their own packets.
These nodes are commonly referred to as active slaves because they regularly transmit data, respond to polling intervals, and participate in bidirectional traffic. Their activity level directly affects latency, throughput, and battery usage in the overall network.
Parked and Sniff Modes for Efficiency
To balance power consumption with responsiveness, the protocol defines low-duty states for slave devices that are connected to a piconet and are sending transmissions over time. Parked devices stop sending and listening unless explicitly requested, while sniff-mode devices reduce listening frequency to conserve energy.
These modes are negotiated based on traffic patterns, quality of service requirements, and device capabilities managed by the master. Network designers must account for transition delays when selecting these modes for real-world applications.
Channel Access and Timing Behavior
Bluetooth uses a time-division duplex scheme where each slot is assigned to a specific participant, including any slave devices that are connected to a piconet and are sending transmissions. The master polls active slaves, and slaves may use reserved or negotiated slots to transmit control frames or user data.
By tuning page scan intervals, hold offsets, and sniff lengths, engineers can shape latency and throughput while preserving radio efficiency. This timing discipline is critical for synchronized audio, reliable file transfer, and responsive human interface devices.
Configuration and Role Switching
Stack implementations expose APIs to change the role of a node without disconnecting the underlying physical link. A device initially acting as a slave can be promoted to a temporary master in scatternet scenarios, while other slaves continue their assigned tasks.
Robust implementations monitor link quality, interference, and buffer occupancy to decide when to park, place in sniff mode, or reactivate full active participation. These decisions are exposed through connection parameters and event notifications for higher-layer optimization.
Key Takeaways for Network Designers
- Use Active Slave for nodes that must transmit and respond in real time.
- Leverage Parked state for devices that require minimal signaling and long idle periods.
- Apply Sniff mode for periodic, low-priority reporting with lower duty cycles.
- Monitor connection events to detect inefficient slot usage and rebalance scheduling.
- Test role-switching scenarios to ensure stability across different traffic loads.
FAQ
Reader questions
What is the formal Bluetooth term for a node that follows a master and can send data in a piconet?
In the Bluetooth Core Specification, the formal term is an Active Slave, which indicates a device participating in scheduled communication and capable of both transmitting and receiving under the master’s clock.
Can a parked device still be considered a slave even if it is not sending traffic right now?
Yes, a parked device remains a slave because it retains membership in the piconet and can be quickly reactivated, though it does not send or receive user data while parked.
What happens to a slave in sniff mode when it needs to send a high-priority packet? The slave and master negotiate a temporary change to active-slave slots, allowing the node to transmit immediately while preserving overall power efficiency for background traffic. How can I identify whether my device is in active, parked, or sniff state during debugging?
Use vendor-specific diagnostics or HCI inspection tools to query the connection state, channel map, and timing parameters, which reveal whether the device is actively transmitting, parked, or operating in sniff mode.