Active, Hold, Sniff & Park Modes
+ Link Manager Protocol
From POLL packets in active mode to duty-cycle engineering in sniff mode — plus a full walkthrough of LMP PDU structure, roles, and the BlueZ implementation layer.
🔑 Key Terms in This Lecture
Where We Are in the Stack
Hello students in this lecture i will explain what is Active, Hold, Sniff & Park Modes + Link Manager Protocol In the previous lecture we established how devices discover each other and create a piconet connection. This lecture picks up from that point: the connection is active, and now we need to manage it efficiently. The central problem is power consumption vs. responsiveness. A device that listens at full power every slot drains its battery in hours; a device that sleeps too aggressively becomes unresponsive.
The Bluetooth specification defines a structured set of solutions: three in-connection modes (Active, Hold, Sniff) and one deeper standby variant (Park state). We examine all four in detail, including their real-world use cases and the engineering trade-offs each one involves.
We also step one layer up from the Baseband to introduce the Link Manager — the software entity that negotiates these modes, exchanges security credentials, and lets devices discover each other’s capabilities. Its protocol (LMP) is the control plane of every Bluetooth Classic connection.
Lecture Outline
Active mode is the baseline: Master and Slaves exchange packets every two slots. We study how the Master uses POLL packets to keep Slaves synchronised and how AM_ADDR identifies each Slave within the piconet.
Hold mode suspends ACL traffic for a negotiated duration. The Slave may use that window to scan, page, or join another piconet. Voice links continue unaffected.
The most widely deployed low-power mode. A sniff interval defines a periodic listening window — the device is absent between windows. Clock drift management over long sniff periods is a subtle but critical engineering concern.
Park state releases the AM_ADDR (freeing piconet capacity) while keeping the device synchronised via periodic beacon wakeups. Used when more than seven Slaves must share a single Master.
LMP is the control plane riding on top of the baseband. We study its PDU structure (TID, OpCode, Payload), the four major functional areas it covers, and how BlueZ implements it.
Figure 3.8 — Link Controller State Machine
Reproduced in structured text form from the Bluetooth Baseband specification. Arrows represent permitted transitions between states and substates.
Figure 3.9 — Inquiry State Messages & Transitions
This sequence diagram shows the packet types and state transitions on both the Master (inquiring) and Slave (discoverable) devices during the inquiry procedure.
Figure 3.10 — Connection & Disconnection Messages
This sequence diagram traces the full lifecycle: from STANDBY through the paging procedure to active data exchange and finally detach on either side.
(BD_ADDR + Clock for hop sync)
(First packet after connection)
(Reason code included in LMP payload)
§ 1 — Active Mode & the POLL Mechanism
Active mode is the default operating condition of a Bluetooth piconet in the CONNECTION state. At its core it is a simple time-division polling scheme: the Master owns the channel and decides which Slave gets to transmit in which slot.
Piconet Capacity: 1 Master + 7 Slaves
At any point in time, a piconet can have at most one Master and seven simultaneously active Slaves. The Master maintains this by assigning each active Slave a 3-bit Active Member Address (AM_ADDR). Since a 3-bit field can represent values 0–7 and value 0 is reserved for broadcast, only seven non-zero values remain — hence the hard limit of seven active Slaves.
POLL Packets: Keeping Slaves Synchronised
Even when the Master has no user data to send, it cannot simply go silent — if it does, Slaves will lose channel synchronisation and start to drift. Instead, the Master continuously transmits POLL packets addressed to each Slave in round-robin fashion. A POLL packet carries no user payload; its sole function is to probe a Slave and give it a transmission opportunity.
When polled, a Slave must respond within one slot. If the Slave has data queued, it sends the appropriate ACL data packet. If it has nothing to send, it responds with a NULL packet — a zero-payload acknowledgement that simply says “I received your poll and I am still here.”
Scheduling SCO/eSCO Alongside ACL
If one or more SCO or eSCO connections are active, the Master must reserve specific slots for them at the intervals they require (every 2 slots for HV3, every 1 slot for HV1). The remaining slots are available for ACL POLL/data exchanges. The Master’s scheduling function must balance these constraints without starving any Slave.
🔗 BlueZ: hci_conn.c — AM_ADDR assignment and active connection tracking
§ 2 — Hold Mode: Negotiated ACL Suspension
Hold mode allows the Master to tell a Slave: “we both agree to suspend ACL packet exchange for the next T slots.” During that window the Slave is freed from listening for POLL packets and can use its radio for other purposes.
What Continues During Hold
Hold mode only affects the ACL logical transport. Voice links — SCO and eSCO — are not interrupted. A phone call in progress continues without any audible gap even while the ACL control channel is frozen. This is a key design choice: voice is the latency-sensitive priority; data control traffic can wait.
What the Slave Can Do During Hold
The freed slots give the Slave a clean opportunity to:
- Enter a hardware low-power mode (clock-gate the radio, reduce CPU frequency).
- Perform an inquiry scan — make itself discoverable to other devices.
- Perform a page — connect to a different Master to join a second piconet.
- Perform paging on its own, acting as a temporary Master to bring up a new connection.
Waking Up on Hold Expiry
Both devices agree on the hold duration before entering hold mode — this is negotiated via an LMP message. On expiry, the Slave wakes and immediately begins listening on the Master’s polling schedule. Since both devices know exactly when hold ends (they computed it from the same clock offset), re-synchronisation is instantaneous with no extra handshake needed.
§ 3 — Sniff Mode: Duty-Cycle Power Saving
Sniff mode is by far the most widely deployed low-power mode in Bluetooth Classic devices. Unlike hold mode (which is negotiated once per hold event), sniff mode defines a recurring duty cycle — the Slave periodically wakes for a brief listening window and returns to sleep between windows.
How the Duty Cycle Works
Two parameters define the sniff duty cycle: the sniff interval (Tsniff, how often the device wakes) and the sniff attempt window (how many slots it listens each time it wakes). Between these windows the device is completely absent from the piconet — its radio is off and its controller is in a low-power sleep state.
Low sniff interval — high power saving
Tight sniff interval — low latency, higher power
Unlike Hold: SCO/eSCO Are Also Unaffected
Sniff mode, like hold mode, only affects the ACL logical transport. SCO and eSCO links continue at their normal cadence even while ACL is in sniff mode. The sniff windows are scheduled to avoid collisions with SCO slots.
Real-World Example 1: Bluetooth Headset
Consider a mono headset paired to a mobile phone. After the initial connection, there may be no active voice call for hours. Yet disconnecting and reconnecting for every call would introduce a noticeable delay (300–800 ms for connection establishment). Instead, the ACL link is left open but placed in sniff mode with a large interval (e.g., 1280 ms). The headset wakes briefly every 1.28 seconds to check for Master traffic. When an incoming call arrives, the Master sends a Connect SCO command in the next sniff window — call setup takes milliseconds rather than seconds.
Real-World Example 2: Bluetooth Keyboard
A Bluetooth keyboard may have no keystrokes for minutes at a time. After an inactivity timer expires (typically set by the host software), the HID profile driver sets the ACL link into sniff mode. The keyboard checks in at the sniff interval (e.g., every 100 ms). The moment a key is pressed, the keyboard sends a keystroke in the next available sniff window. The host exits sniff mode and returns to active polling for as long as typing continues, then re-enters sniff mode after the inactivity timer fires again.
Using Sniff Mode as a Scatternet Bridge
Sniff mode enables a device to be a member of two piconets simultaneously — a configuration called a scatternet. The device tunes its sniff parameters so that the absent-periods in piconet A align with the active-periods in piconet B. By carefully engineering both sniff intervals it can interleave participation in two completely independent piconets without either link dropping.
⚠️ Clock Drift: The Hidden Risk
Every Bluetooth device has a local crystal oscillator that drives its clock. No two crystals run at exactly the same frequency — there is always a small drift. Over short sniff periods (a few seconds) this drift is negligible. But for headsets that stay in sniff mode for hours on end, accumulated clock drift can shift the Slave’s wake window so far that it no longer aligns with the Master’s POLL slot — resulting in dropped packets or even link loss.
The specification and implementations address this by having the Slave controller periodically resynchronise with the Master even during sniff periods, using the received packet timing to re-calibrate the local clock offset. BlueZ exposes sniff resynchronisation through the HCI Sniff Subrating command.
🔗 Kernel Source: net/bluetooth/hci_request.c — Sniff mode HCI request 🔗 BlueZ mgmt-api.txt — Connection power mode management
§ 4 — Park State: Deep Synchronisation
Park state is the lowest-power in-piconet mode. A parked Slave has completely stopped transmitting and receiving ACL or SCO/eSCO traffic, yet remains synchronised to the piconet’s frequency-hopping sequence so it can quickly re-activate when needed.
Address Swap: AM_ADDR → PM_ADDR
When a Slave is parked, the Master reclaims its Active Member Address (AM_ADDR) and instead assigns a Parked Member Address (PM_ADDR). PM_ADDR is used only in broadcast messages from the Master to identify parked devices. The freed AM_ADDR slot can now be given to a new active Slave — this is the primary mechanism for exceeding the seven-active-Slave limit.
| Address Type | Bits | Used When | Purpose |
|---|---|---|---|
| AM_ADDR | 3 | Active mode (CONNECTION state) | Identifies Slave in packet headers; max 7 non-zero values |
| PM_ADDR | 8 | Park state | Identifies parked Slave in Master broadcast; up to 255 parked devices |
| AR_ADDR | 8 | Park state (Access Request) | Used by parked Slave to request unparking in the access window |
How Parked Devices Stay Synchronised
A parked Slave wakes up at regular beacon intervals determined by the Master. During each beacon window it listens to a broadcast message from the Master. The Master uses these broadcasts to:
- Provide clock information so parked Slaves can re-calibrate their local offsets.
- Announce any messages specifically addressed to one or more parked Slaves (via their PM_ADDR).
- Signal an unpark request for a specific Slave.
Between beacon intervals the Slave’s radio is completely off, making park state suitable for sensors that must maintain piconet membership indefinitely while consuming almost no power.
The >7 Slave Problem
A practical deployment scenario: a Bluetooth gateway managing a room full of sensors. More than seven sensors need to be logically associated with the gateway, but at any moment only a few are actively transmitting readings. The solution is to keep at most seven sensors in active mode and park the rest. When a parked sensor has data, the Master temporarily unparks it (swapping it with an active sensor that gets parked) for the duration of the transmission, then parks it again.
§ 5 — Link Manager Protocol (LMP)
The Link Manager (LM) is the software layer sitting directly above the Baseband Controller. Its job is to set up, maintain, and tear down connections — negotiating everything from packet types to encryption keys. It communicates with its peer on the remote device using the Link Manager Protocol (LMP).
Transport: ACL-C Logical Link via DM1 Packets
LMP messages ride on the ACL-C (Control) logical link — a separate logical channel within the ACL connection that carries only control data. User application data travels on the ACL-U (User) logical link. This separation ensures that link management traffic can always be delivered even when the ACL-U channel is congested with application data.
By default, LMP messages are carried in DM1 packets — the 1-slot, medium-rate packet type that we studied earlier. The small payload ceiling of DM1 (17 bytes) is not a limitation for LMP because most LMP PDUs are compact control messages. The one exception: if an HV1 SCO link is active and the LMP payload fits in 9 bytes or fewer, DV packets may be used — but this is rare in practice.
LMP PDU Structure
Every LMP message is a PDU (Protocol Data Unit) consisting of exactly three fields:
What is a Transaction?
A transaction is a complete unit of LMP work — it may require multiple PDUs going back and forth between the two Link Managers. All PDUs belonging to the same transaction carry the same TID value, so each side can associate responses with their initiating requests. For example, an encryption setup transaction may involve: LMP_encryption_mode_req → LMP_accepted → LMP_encryption_key_size_req → LMP_accepted → … and all of these share one TID.
The most common response PDUs are LMP_accepted (the requested operation is permitted) and LMP_not_accepted (the requested operation is refused, with a reason code in the payload).
The Four Functional Areas of LMP
Connection Control
Creation and removal of ACL connections, SCO/eSCO setup, mode negotiation (sniff, hold, park), power control, and detach procedures.
Security
Authentication (challenge-response using the link key), pairing (legacy PIN-based and Secure Simple Pairing), and link-layer encryption setup including key exchange.
Informational Requests
Capability exchange: version negotiation via LMP_version_req, feature discovery via LMP_features_req / _res, clock offset requests, and timing accuracy queries.
Role Switch
Swaps Master and Slave roles after a connection is established. The new Master’s clock becomes the piconet reference; an FHS packet is exchanged to re-synchronise the hop sequence.
Role Switch: A Practical Example
Consider a Bluetooth mouse connecting to a laptop. Because the mouse initiates the page, it becomes Master. But a laptop typically wants to be Master so it can control multiple peripherals (keyboard, mouse, headset) from a single piconet. After the connection is established, the laptop’s Link Manager sends an LMP_switch_req PDU. If the mouse accepts, they execute a synchronised role-swap: the laptop’s clock takes over as the piconet reference, the frequency-hop sequence re-centres on the laptop’s BD_ADDR, and both devices resume normal operation — now with the laptop as Master.
BlueZ: LMP PDU Handling
🔗 Kernel Source: net/bluetooth/hci_event.c — Remote feature event handling 🔗 BlueZ lib/bluetooth.c — Core utilities including address handling 🔗 Kernel Source: hci_conn.c — Role switch implementation
🎯 Self-Test Questions
Work through these before your next tutorial. Refer to the BlueZ source links above where relevant.
LMP_not_accepted to a LMP_switch_req? What does the TID field tell us in this exchange?hci_sniff_req(). What are the units of the max_interval and min_interval fields, and how would you set a sniff interval of approximately 1280 ms?Next Up: L2CAP & the Host Protocol Stack
With the Link Manager and baseband covered, we move upward: L2CAP multiplexing, segmentation & reassembly, and how profiles ride on top.