ESP32-C5 per-packet PHY rate selection for esp_wifi_80211_tx (IDFGH-18194)

[zavdimka]

[Feature Request] Per-packet PHY rate/MCS selection for esp_wifi_80211_tx() on ESP32-C5

Is your feature request related to a problem?

We are developing a low-latency point-to-point video link based on two ESP32-C5 devices. Video data is transmitted using raw non-QoS IEEE 802.11 frames through esp_wifi_80211_tx().

The link needs several predefined PHY profiles:

• A robust control and feedback profile, for example legacy OFDM at 6 Mbps.
• Three to six data profiles using progressively higher MCS rates.
• Dynamic profile selection based on packet-loss reports received from the other ESP32-C5.

An example transmission sequence is:

Robust CONTROL frame
High-rate DATA burst
Robust END frame
Robust reverse REPORT frame

The modulation does not need to change inside a single PPDU. Switching the PHY profile between separate raw frames or short packet bursts would be sufficient.

The documented esp_wifi_config_80211_tx_rate() API appears to be intended for configuration after esp_wifi_init() and before esp_wifi_start(). Therefore, it is unclear whether changing the rate at runtime, while raw packet transmission is active, is supported.

The internal esp_wifi_internal_set_fix_rate() API explicitly states that it does not support frames transmitted through esp_wifi_80211_tx().

As a result, there does not appear to be a supported way to select one of several PHY rates for each raw frame or packet burst without stopping and restarting Wi-Fi.

Describe the solution you'd like

We would like a supported ESP32-C5 API that allows an application to select the PHY rate or one of several predefined PHY profiles for every frame transmitted through esp_wifi_80211_tx().

One possible solution would be an extended raw TX API with a per-packet configuration:

typedef struct {
    wifi_phy_rate_t rate;
    wifi_bandwidth_t bandwidth;
    bool short_gi;
    uint8_t retry_count;
    bool require_ack;
} wifi_raw_tx_config_t;

esp_err_t esp_wifi_80211_tx_ex(
    wifi_interface_t ifx,
    const void *buffer,
    size_t length,
    bool en_sys_seq,
    const wifi_raw_tx_config_t *config
);

Another potentially simpler solution would be to configure several PHY profiles before Wi-Fi starts and select a profile ID for each transmitted frame:

esp_wifi_raw_tx_profile_config(0, WIFI_PHY_RATE_6M);
esp_wifi_raw_tx_profile_config(1, WIFI_PHY_RATE_MCS0_LGI);
esp_wifi_raw_tx_profile_config(2, WIFI_PHY_RATE_MCS3_LGI);
esp_wifi_raw_tx_profile_config(3, WIFI_PHY_RATE_MCS7_LGI);

esp_wifi_80211_tx_with_profile(
    WIFI_IF_STA,
    frame,
    frame_length,
    true,
    profile_id
);

Preconfigured profiles may be preferable if changing arbitrary PHY parameters for each frame would add significant driver overhead.

We need at least the following functionality:

• At least four selectable PHY rate/MCS profiles.
• Profile selection for every raw frame or short packet burst.
• No call to esp_wifi_stop() or esp_wifi_start() between profile changes.
• Deterministic packet ordering when profiles are changed.
• Compatibility with promiscuous reception on another ESP32-C5.
• Switching latency suitable for short packet bursts.
• Support for both legacy OFDM rates and higher 802.11n/ac/ax MCS rates, where supported by the selected band.
• Preferably configurable retry and ACK behavior.
• Preferably a TX completion callback containing the PHY profile used and the final transmission status.

Is there already a supported API on ESP32-C5 for changing the raw IEEE 802.11 TX rate at runtime or per packet?

If no public API currently exists, could Espressif provide or consider one of the following?

1. A per-packet PHY configuration passed to an extended esp_wifi_80211_tx() API.
2. Several PHY profiles configured before Wi-Fi starts, with a profile ID selected for every transmitted packet.
3. A supported engineering/internal API for runtime raw TX rate selection.
4. A Wi-Fi binary library build that provides this functionality for ESP32-C5.
5. Confirmation that calling esp_wifi_config_80211_tx_rate() at runtime is safe and supported, if the current driver already allows it.

Describe alternatives you've considered

We considered calling esp_wifi_config_80211_tx_rate() before each packet burst. However, the documented API lifecycle appears to require calling it after esp_wifi_init() and before esp_wifi_start(). It is therefore unclear whether runtime calls are supported, thread-safe, and guaranteed to affect packets that are already queued.

We also considered using:

esp_wifi_internal_set_fix_rate()

However, its documentation explicitly states that it does not support esp_wifi_80211_tx().

Another possible workaround is to use WIFI_MODE_APSTA and configure the STA and AP interfaces with different fixed rates. Robust control frames could then be transmitted through one interface and high-rate data frames through the other. However:

• This would provide only two PHY profiles.
• STA and AP use different MAC addresses.
• Both interfaces share the same physical radio and TX resources.
• It is unclear whether the ESP32-C5 driver preserves separate raw TX rates for the two interfaces.
• It would not allow adaptive selection between four or more data rates.

Stopping and restarting Wi-Fi whenever the PHY rate changes was also considered, but the resulting interruption and latency make this unsuitable for a low-latency video link.

Using the normal connected Wi-Fi rate-control mechanism is not ideal for this application because we need explicit and predictable control over the PHY profile used for each raw packet burst.

Additional context

The intended application is a low-latency point-to-point video link with application-level packet-loss feedback.

The receiver periodically reports:

• The number of expected packets.
• The number of successfully received packets.
• A bitmap or sequence range describing lost packets.
• Average and minimum RSSI.
• A recommended PHY profile.

The transmitter uses this information to select one of several predefined PHY profiles. The expected adaptation period is approximately 10–20 ms. We do not require modulation changes inside a single IEEE 802.11 frame.

The intended radio protocol resembles:

TX -> RX: robust CONTROL frame
TX -> RX: high-rate DATA frames
TX -> RX: robust END frame
RX -> TX: robust packet-loss REPORT frame

The control and feedback frames should use a robust low-rate profile, while video packets should use one of several faster profiles selected according to the current channel quality.

A related older issue is:

#8406: Rate is ignored for esp_wifi_80211_tx

Target information:

• SoC: ESP32-C5
• Radio band: primarily 5 GHz, with possible 2.4 GHz support
• Transmission API: esp_wifi_80211_tx()
• Reception mode: promiscuous mode on another ESP32-C5

We would appreciate clarification on whether the current ESP32-C5 Wi-Fi binary driver can select one of several preconfigured PHY rates for each esp_wifi_80211_tx() frame.

If this is not currently possible through the public API, is such functionality technically feasible in the existing ESP32-C5 Wi-Fi driver, and could Espressif expose it through a supported API?