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.
