[DESIGN RFC] EHT/UHR Critical update handling
Manish Dharanenthiran
manish.dharanenthiran at oss.qualcomm.com
Wed Jun 24 22:03:26 PDT 2026
Hi,
This RFC outlines a proposed approach for handling EHT/UHR Critical Update (CU)
procedures across different driver models. The focus is on ensuring correct and
consistent behavior of beacon and management frames, while addressing timing
constraints and scalability challenges observed in the previously discussed
approaches.
================================================================
Background and Motivation
================================================================
For handling EHT/UHR Critical Updates (CU) across both beacon offload and
non-offload drivers, Johannes previously proposed a design in [1], where the
responsibility for managing CU-related updates resides entirely in
user space (hostapd). In this approach, the kernel/driver provides timing
information (e.g., TSF and TBTT), which hostapd uses to compute and update
beacon contents. As part of the CU procedure, hostapd is expected to update
beacon contents at every beacon interval until the CU session completes.
While this approach is functionally applicable to both offloaded (where
firmware handles beacon transmission) and non-offloaded drivers, but it
introduces scalability concerns. Specifically, in real-time scenarios involving
low-power chipsets operating at high load (e.g., supporting up to 256 clients
with multiple virtual interfaces), repeatedly processing CU updates in user space
at every beacon interval can incur significant overhead. This may impact system
efficiency and responsiveness, particularly under constrained resources.
[1] https://lore.kernel.org/all/1cf0ae795b0e3e95b38cb7abf84ffad34c187fdf.camel@sipsolutions.net/
==================================================================
Prior Alternative and Limitations
==================================================================
An alternative approach was proposed in [2], where mac80211 would take
responsibility for stitching or updating beacon contents during CU. This design
aimed to address timing constraints by moving the processing closer to the
driver, thereby reducing reliance on user space scheduling and latency.
However, this proposal was not accepted, primarily due to concerns about
increasing complexity and processing overhead within mac80211. The consensus was
that such logic is better suited for user space, keeping mac80211 lightweight
and focused on its core responsibilities.
[2] https://lore.kernel.org/all/20250717045540.27208-1-aditya.kumar.singh@oss.qualcomm.com/
Problem Statement:
===================
Given the above, there remains a gap between:
- Meeting strict timing requirements for CU operations, and
- Avoiding excessive overhead in either user space (hostapd) or
kernel(mac80211).
Additionally, any solution must work seamlessly across both:
* Beacon offload drivers (firmware-driven beaconing), and
* Non-offload drivers (e.g., hwsim and similar mac80211-based drivers).
Proposed Direction:
===================
To address these challenges, a new design is proposed that strikes a balance
between timing accuracy, scalability, and implementation complexity.
The objective is to:
- Minimize per-beacon processing overhead in user space,
- Avoid adding significant processing burden to mac80211, and
- Ensure compatibility across both offloaded and non-offloaded driver models.
This approach is designed to meet CU timing requirements efficiently, while
remaining scalable for high-density and resource-constrained deployments.
======================================================================
ATH12K Design
======================================================================
Currently in the ath12k driver [3], beacon updates during an ongoing CU session
are handled entirely by firmware. The firmware is responsible for
composing (“stitching”) the beacon contents based on inputs provided by
userspace.
For example, consider a Multi-Link (ML) reconfiguration scenario where Link A
initiates a link removal. In this case:
- Link A includes the Multi-Link Reconfiguration element in its beacon.
- At the same time, Link B also incorporates the same element in its beacon
and updates the BPCC value within the Reduced Neighbor Report (RNR)
corresponding to Link A.
Link A and Link B (part of MLD) originally beaconing just fine:
┌──────────────────────────────┐ ┌───────────────────────────────┐
│ Link A's beacon │ │ Link B's beacon │
│ │ │ │
│...... │ │...... │
│┌────────────────────────────┐│ │┌─────────────────────────────┐│
││RNR Element: ││ ││RNR Element: ││
││ TBTT INFO: ││ ││ TBTT INFO: ││
││ MLD INFO: ││ ││ MLD INFO: ││
││ LINK ID: B ││ ││ LINK ID: A ││
││ BPCC: 1 ││ ││ BPCC: 1 ││
│└────────────────────────────┘│ │└─────────────────────────────┘│
│...... │ │...... │
│┌────────────────────────────┐│ │┌─────────────────────────────┐│
││MULTI LINK Element: ││ ││MULTI LINK Element: ││
││ COMMON INFO: ││ ││ COMMON INFO: ││
││ LINK ID: A ││ ││ LINK ID: B ││
││ BPCC: 1 ││ ││ BPCC: 1 ││
││ ││ ││ ││
││ Basic STA profile count: 0││ ││ Basic STA profile count: 0 ││
│└────────────────────────────┘│ │└─────────────────────────────┘│
└──────────────────────────────┘ └───────────────────────────────┘
Link A started link removal, during link removal, the beacon would look like
┌──────────────────────────────┐ ┌──────────────────────────────┐
│ Link A's beacon │ │ Link B's beacon │
│ │ │ │
│┌────────────────────────────┐│ │┌────────────────────────────┐│
││Capabilities Info: ││ ││Capabilities Info: ││
││ BIT 6: CU Bit: True ││ ││ BIT 6: CU Bit: True ││
│└────────────────────────────┘│ │└────────────────────────────┘│
│ │ │ │
│┌────────────────────────────┐│ │┌────────────────────────────┐│
││RNR Element: ││ ││RNR Element: ││
││ TBTT INFO: ││ ││ TBTT INFO: ││
││ MLD INFO: ││ ││ MLD INFO: ││
││ LINK ID: B ││ ││ LINK ID: A ││
││ BPCC: 1 ││ ││ BPCC: 2 ││
│└────────────────────────────┘│ │└────────────────────────────┘│
│ │ │ │
│┌────────────────────────────┐│ │┌────────────────────────────┐│
││MULTI LINK Element: ││ ││MULTI LINK Element: ││
││ COMMON INFO: ││ ││ COMMON INFO: ││
││ LINK ID: A ││ ││ LINK ID: B ││
││ BPCC: 2 ││ ││ BPCC: 1 ││
││ ││ ││ ││
││ Basic STA profile count: 0││ ││ Basic STA profile count: 0││
│└────────────────────────────┘│ │└────────────────────────────┘│
│┌────────────────────────────┐│ │┌────────────────────────────┐│
││MULTI LINK Element: ││ ││MULTI LINK Element: ││
││ Type: Reconfiguration (2) ││ ││ Type: Reconfiguration (2) ││
││ Per-STA Profile 1 ││ ││ Per-STA Profile 1 ││
││ Link ID: <Link A's ID> ││ ││ Link ID: <Link A's ID> ││
││ STA Info: ││ ││ STA Info: ││
││ Length: ││ ││ Length: ││
││ AP Removal timer: ││ ││ AP Removal timer: ││
│└────────────────────────────┘│ │└────────────────────────────┘│
└──────────────────────────────┘ └──────────────────────────────┘
>From the user space perspective, hostapd constructs the Multi-Link
Reconfiguration element and conveys only the relevant element to the firmware.
The firmware then integrates this element into the corresponding beacon frames
for all affiliated links and continues transmitting updated beacons within the
configured TBTT window for the CU session.
Firmware Notifications:
=====================
During the CU lifecycle, the firmware provides explicit notifications to both
kernel and user space to ensure proper synchronization:
STARTED:
--------
Indicates the initiation of the link reconfiguration process. This notification
allows both kernel and user space to transition into the CU handling state.
COMPLETED:
----------
Triggered after the final beacon corresponding to TBTT = 1 is transmitted. At
this point, the firmware removes the Multi-Link Reconfiguration element from
all affiliated AP MLD links and signals completion to kernel and user space.
RX MGMT Event:
-------------
While a CU session is in progress, if a Probe Request or (Re)Association
Request is received on the AP MLD, the firmware forwards an RX management
event to userspace. This event includes the current TBTT and BPCC values,
which hostapd uses to construct appropriate Probe or (Re)Association Response
frames.
[3] https://lore.kernel.org/all/20240807034521.2091751-1-quic_mdharane@quicinc.com/
======================================================================
DESIGN PROPOSAL
======================================================================
Introduction:
=============
The design proposal ensures that during an ongoing Critical Update (CU) session,
beacon frames are dynamically updated by the driver or firmware to include the
required CU elements and indication bits. It establishes coordination between
kernel, driver, and user space to track CU state, handle lifecycle notifications
(start/completion), and maintain consistency. Additionally, management responses
such as Probe and (Re)Assoc are updated with accurate CU parameters
(e.g., TBTT), ensuring synchronized signaling without requiring full state
re-transmission from user space.
Beacon Update Handling:
=============================
For non-offload drivers (e.g., hwsim), beacon updates during a CU session are
handled in a manner analogous to firmware-assisted designs. The driver is
responsible for stitching the required EHT/UHR CU elements into the beacon
prior to transmission.
Assumptions:
===========
- A mechanism can be added to notify the driver when a CU session is active.
- A common interface can be added to retrieve the required Critical Update
elements from mac80211.
Compiling Beacon frame:
======================
Upon receiving the reconfiguration element from hostapd, the driver retrieves
the beacon template using ieee80211_beacon_get(). If a CU session is in
progress, the beacon is updated as follows:
1) Retrieve the base beacon using ieee80211_beacon_get()..
2) Compute the updated length: size_t new_len = skb->len + ie_len;
3) Allocate new_skb:
struct sk_buff *new_skb = dev_alloc_skb(hw->extra_tx_headroom + new_len);
4) Insert the new element in the respective position.
5) Set the CU indication and transmit the updated beacon for the duration of
the TBTT window.
6) Remove the CU flag after the DTIM beacon is sent out.
Notifying user-space:
=====================
Since user space (hostapd) primarily initiates the CU procedure, the kernel is
expected to provide explicit notifications for CU lifecycle events:
* STARTED — Indicates that the CU session has begun.
* COMPLETED — Indicates that the CU session has ended.
For instance, in ML reconfigure, hostapd can trigger a BTM frame to let the
associated stations know that this link will be removed after a period
indicated by TSF offset.
Thus, adding a notification framework for indicating started/completed will be
helpful for user-space to take necessary actions like sending BTM broadcast
frame with link removal imminent bit set after link reconfiguration removal is
started.
Example design flow for link reconfigure in the proposed model:
* (Initiate ML reconfigure)
*
* [*] = New NL command/attribute
*
* +---------+ +---------------------------+ +-------+
* | hostapd | | nl80211/cfg80211/mac80211 | | hwsim |
* +----+----+ +-------------+-------------+ +---+---+
* | | |
* |--. | |
* | Initiate ML reconfigure | |
* | + build ML Reconfig | |
* | element | |
* |<--' | |
* | | |
* +-------------------------+ |
* | [*] | |
* | NL80211_CMD_CRITICAL_UPDATE |
* | attrs: | |
* | NL80211_ATTR_MLO_LINK_ID, |
* | NL80211_ATTR_AP_REMOVAL_COUNT, |
* | NL80211_ATTR_IE, | |
* | NL80211_ATTR_CU_TYPE (e.g |
* | reconfig/TTLM/UHR) | |
* +-------------------------+ |
* | | |
* NL80211_CMD_CRITICAL_UPDATE |
* |-------------------------> |
* | | |
* | |--. |
* | | Based on CU_TYPE |
* | | (EHT [Reconfigure/ |
* | | TTLM etc.]/UHR |
* | | params), choose |
* | | nl80211_remove_ |
* | | link() for link |
* | | reconfigure |
* | |<--' |
* | |--------------------->|
* | +--------------------------------+ |
* | | [NEW] Send element to hwsim | |
* | | driver via ops | |
* | +--------------------------------+ |
* | |--------------------->|
* | | |--.
* | | | Compile
* | | | beacon
* | | | with new
* | | | element
* | | | and CU
* | | | bit set
* | | |<--'
* | | |
* +-----------------------------------------------+|
* | [*] NL80211_CMD_CRITICAL_UPDATE_NOTIFY |
* +-----------------------------------------------+|
* | | |
* | |<---------------------|
* | | notify started with|
* | | tbtt set to > 0 |
* |<------------------------| |
* | | |
* | EVENT_LINK_REMOVE_STARTED |
* | <start BTM and other respective actions |
* | that need to be completed before TBTT window |
* | ends> |
* | | |
* | | |
* | | |--.
* | | | Remove CU
* | | | bit after
* | | | DTIM
* | | | period
* | | |<--'
* | | |
* | |<---------------------|
* | | notify completed |
* | | after beacon with |
* | | tbtt=1 is sent |
* | | <completed will be |
* | | denoted by setting|
* | | tbtt=0 while |
* | | sending to user- |
* | | space> |
* | | |
* | | |--.
* | | | Remove
* | | | reconfigure
* | | | element
* | | | from
* | | | partner
* | | | profile
* | | |<--'
* |<------------------------| |
* | | |
* | EVENT_LINK_REMOVE_COMPLETED |
* | | |
* |--. | |
* | (cleanup/disable/ | |
* | remove link) | |
* |<--' | |
* | | |
* |------------------------>| |
* | Set beacon for all | |
* | enabled BSSs | |
* | | |
Note: If a new CU update is triggered while an existing CU session is ongoing,
hostapd only provides the delta (i.e., the new element). The driver (or firmware,
where applicable) is responsible for combining this with the existing state when
generating subsequent beacons. Re-sending previously applied CU parameters from
user space is not required. Also, it would internally handle the MBSSID
cases as well.
Adding current TBTT in Probe/(Re)Assoc response:
================================================
In the proposed model, the driver/firmware is responsible for maintaining the
current TBTT state while updating beacon frames during an ongoing CU session.
Consequently, any Probe Response or (Re)Association Response transmitted during
this period must also carry the corresponding CU element with the correct and
up-to-date TBTT value.
Two approaches are considered:
1) Updating TBTT in Probe/(Re)Assoc response in mac80211:
=========================================================
In this approach, mac80211 updates the TBTT value before transmitting management
responses:
When hostapd queues a Probe/(Re)Assoc Response via NL80211_CMD_FRAME, mac80211
checks if a CU session is active. If active, mac80211 retrieves the latest TBTT
from the driver/hwsim. The TBTT value in the response frame is then updated
before passing the frame to the driver for transmission.
To support this, NL80211_CMD_FRAME is extended to include an array of offset
attributes indicating where TBTT values must be updated within the frame. This
is required to handle:
Multiple concurrent CU contexts (e.g., EHT ML reconfiguration and UHR CU), and
Updates within per-STA profiles (e.g., partner link CU scenarios).
For updating associated counters two options exist:
1) Fetch the latest value from the driver at the time of transmission, or
2) Pass the value from lower layers along with the frame.
The former is preferred, as it ensures the most accurate state at transmission
time.
+-----------+ +------------+ +----------------+
| hostapd | | mac80211 | | firmware/hwsim |
+-----------+ +------------+ +----------------+
| | |
| | |
|<-----------------------------| |
| NL80211_CMD_FRAME | |
+---->| Probe/(Re)Assoc request | |
| | | |
Compile | | |
response | | |
- | | |
+---->|----------------------------->| |
| NL80211_CMD_FRAME | |
| Probe/(Re)Assoc response | |
| | |
+------------------------------+ |
|*NL80211_ATTR_CU_TBTT_OFFSET | |
| | |
| Array of offset attributes | |
| to denote the TBTT | |
| placeholder for updating the | |
| latest count | |
+------------------------------+ |
| |----+ |
| | v |
| |Update |
| |response frame |
| | ^ |
| |----+ |
| | |
| |----------------->|
| | Queue response |
| | frame |
| | |
2) Propagating TBTT to user-space:
==================================
To reduce per-frame processing in mac80211, this approach propagates the
current TBTT value to user space:
The kernel includes the current TBTT and CU type as part of
NL80211_CMD_CRITICAL_UPDATE notifications. Hostapd uses this information to
construct Probe/(Re)Assoc Responses with the appropriate TBTT values before
sending them via NL80211_CMD_FRAME.
While this avoids additional processing in mac80211, it introduces potential
latency issues. Specifically:
The response may be transmitted after the CU state has changed
(e.g., TBTT progressed or CU completed), resulting in stale parameters. The
driver/firmware must therefore handle such cases, including rejecting frames
containing outdated CU information if the CU session has already completed.
A similar user space–driven model was previously proposed in [4]. While it
requires refactoring to align with the current design, it provides a high-level
reference for propagating CU state to user space.
[4] https://lore.kernel.org/all/20240403162225.3096228-1-quic_rrchinan@quicinc.com/
With this design of stitching beacon in hwsim/firmware, we believe the proposed
design can effectively meet real-time requirements, including high client
density scenarios on low-power chipsets, while also enabling validation through
simulation-based test environments (e.g., hwsim) for various Critical Update
cases.
Please let us know your thoughts on the same.
[Note: EHT Link reconfiguration is used as an example to depict the
proposed design. The same will be used across other Critical Update
(EHT/UHR) handling.]
More information about the ath12k
mailing list