We are currently working on a use case involving multicast audio transmission over IEEE 802.11ah (HaLow) and are using the MM6108 chipset (Version 0-rel_1_11_3_2024_Mar_28) for this purpose.
In our implementation, the transmission method (unicast vs. multicast/broadcast) is dynamically selected based on the number of connected clients. When sending via unicast, the Minstrel or Morse rate control (RC) effectively adapts the MCS based on client range and signal quality.
However, when transmitting multicast or broadcast traffic, we have observed that frames are always sent using MCS 0. While this is ideal for distant or low-SNR clients, some of our use cases involve clients in close proximity where using a higher MCS (e.g., MCS 1–7) for broadcast/multicast would be beneficial in terms of efficiency and reduced airtime.
We attempted to set a fixed MCS using the following command:
[root@nixos:~]# morsectrl -i morse1 txrate enable -m 7
Set the following transmission rate parameters:
MCS index: 7
However, this setting appears to only affect unicast transmissions, and multicast/broadcast frames continue to be sent at MCS 0.
In our past work with Newracom’s HaLow solution, we had the flexibility to configure the MCS for multicast/broadcast traffic, which proved valuable in similar scenarios.
Could you please confirm whether there is an option in morsectl (or an equivalent method) to configure the MCS for broadcast/multicast frames on MM6108?
Per 802.11, broadcast is sent at the lowest required minimum basic rate configured on the SSID. Multicast is sent at the highest required minimum basic rate. Unicast is adaptive and will use the highest rate and MCS the link can handle.
Thank you for your response.
Yes, I understand the logic behind setting these mcs for unicast and multicast/broadcast.
I would like to know if there is any option for us to set mcs for multicast/broadcast?
Following command works for unicast.
morsectrl -i morse1 txrate enable -m 7
If you’re using the Linux driver, I believe you can set enable_mcast_rate_control=1 (as a module parameter) on the AP (or mesh point, for that matter). This should make multicast use the lowest MCS of the connected stations instead of the lowest possible rate (as bward mentioned is the standard), but I haven’t personally used this parameter; do report if you’re having issues with it and we can look into it further.
If you’re not using the Linux driver, let us know what you’re using and I’ll look into it.
Thank you for the response.
We are using Linux-based drivers with the Morse driver version 1.11.
From what I see in our build, we are not using the Morse rate control; instead, Minstrel is used:
As per my understanding, Minstrel only handles “unicast” frames. For multicast/broadcast, the rate is applied directly by the Morse firmware, not by the rate control algorithm.
I also searched through our driver code and did not find any reference to an enable_mcast_rate_control parameter.
Could you please confirm if this option exists in version 1.11, or if it is perhaps available only in a different driver version or branch? Any additional details about where and how to enable it would be helpful.
As the option would indicate, this should force multicast to use rate control.
We also strongly suggest using CONFIG_MORSE_RC=y, as this will provide much better rate control for HaLow than minstrel. For the latest version of the driver, this is the default behaviour.
We have recently integrated the new Morse driver v1.16 along with the corresponding firmware.
We also noticed that multicast rate control is disabled by default. For our testing, we enabled it using the following module parameter:
module_param(enable_mcast_rate_control, bool, 0644);
MODULE_PARM_DESC(enable_mcast_rate_control,
“Enable multicast rate control tracking to transmit at highest possible rate, bandwidth and GI”);
We conducted several tests using multicast audio traffic and observed issues with MCS adaptation for multicast frames. Our setup consists of two Morse devices (MM6108) connected via an 802.11s mesh link.
Summary of Observations
When only multicast traffic is transmitted and the nodes move farther apart, the multicast MCS does not adapt as expected. It remains fixed at the initial MCS level instead of reducing with distance.
However, when multicast traffic is sent alongside unicast traffic, MCS adaptation functions correctly.
Test 1 – Multicast + Unicast Traffic
Traffic:
Multicast audio (~100 kbps)
Unicast UDP traffic via iperf (~100 kbps)
Topology: Static node → Moving node
Observation:
Multicast audio is received properly until near disconnection range. MCS adaptation behaves as expected.
Both nodes transmit multicast audio alternately (one at a time)
No unicast traffic present
Observation:
Multicast audio stops working at a much shorter distance (~20% of Test 1 range). Packet capture confirms that MCS remains fixed at 7 and does not decrease with link degradation.
It appears that multicast rate control is not adapting the MCS properly when multicast is the only traffic present. The presence of unicast traffic seems to trigger or assist the rate control algorithm, allowing multicast MCS adaptation to function correctly.
Could you please check this and provide patch if the issue reproduced at your end.
The enable_mcast_rate_control setting effectively causes multicast traffic to use the minimum of the current best unicast rates across all devices tracked by the rate control algorithm.
Because multicast traffic is not acknowledged, the transmitting device has no visibility into whether it was successfully received, and therefore multicast frames do not directly influence the rate control algorithm. Unicast traffic is acknowledged. When acknowledgments begin to fail consistently for any device, the rate control algorithm lowers that device’s unicast rate. Since multicast (with this setting enabled) uses the lowest of these per-device best rates, it is reduced as well.
Thank you for your response. We understand the logic behind this behavior and the dependency on unicast acknowledgments for rate adaptation.
As a workaround, we plan to introduce small unicast frames periodically across mesh peers to provide acknowledgment feedback. However, we have a concern regarding scalability: when the number of devices increases (e.g., 10–20 nodes), the cumulative unicast traffic exchanged purely for rate control purposes may introduce noticeable bandwidth overhead in the mesh network.
Since each device is already transmitting beacons, would it be feasible (now or in future releases) to infer link quality from beacon RSSI or similar metrics and use that information to adjust the minimum multicast MCS? We are wondering if beacon-based or RSSI-based heuristics could partially mitigate the need for additional unicast probe traffic in multicast-heavy scenarios.
