TX MCS not recovering after RSSI improvement under low unicast traffic (MM6108)

Software
1

Dear Morse Micro Team,

We are currently using the MM6108 chipset with Morse driver/firmware version v1.16 in an 802.11ah mesh deployment.
During mobility testing, we observed that TX MCS does not recover appropriately after RSSI improvement when unicast traffic load is low.

Experiment Description

A controlled mobility experiment was conducted where one mesh node was physically moved away from its peer to progressively degrade RSSI and then moved back towards the peer to restore link quality. This resulted in a clear signal degradation–recovery cycle, allowing us to observe the rate adaptation behavior during both phases.

Observed Behavior

During link degradation:

  • TX MCS decreases as expected when RSSI drops

  • Rate adaptation appears responsive to worsening channel conditions

During link recovery (node moving closer):

  • RSSI improves significantly (e.g., from ~-90 dBm to ~-25 dBm). However, TX MCS does not recover proportionally when unicast traffic load is low. TX MCS remains at low values (often near MCS 0–1) for extended duration. Please refer to the following graph.

This behavior suggests that rate adaptation may be strongly dependent on unicast traffic volume.

Expected Behavior

We expect the rate control mechanism to:

  • Probe higher MCS levels when channel conditions improve

  • Adapt primarily based on link quality rather than traffic density

  • Maintain reasonable PHY efficiency even under sparse traffic conditions

Could you please:

  • Confirm whether this behavior is expected in the current rate control implementation, Advise if any configuration or tuning parameters are available, Indicate whether this issue has been addressed in newer firmware releases

Thank you for your support.

Regards,
Kumar M.

mcs_unicast_test_with_100kbps_iperf
mcs_unicast_test_with_100kbps_iperf1046×393 56.1 KB

mcs_unicast_test_with_10kbps_iperf
mcs_unicast_test_with_10kbps_iperf1055×393 46.6 KB

mcs_unicast_test_with_ping
mcs_unicast_test_with_ping1055×393 51.2 KB

2

Hi Kumar,

Rate control for low/moderate throughput scenarios is an area that we have been actively working on since 1.16.

1.16 is missing some notable improvements. 1.17 is our most recent release and may have a few of the fixes, but there’s a few recently implemented for the next release.

Unfortunately I don’t believe there are any tweakable parameters for the rate control algorithm that’ll improve this, the fixes we’ve implemented are algorithmic improvements rather than configuration adjustments.

Regardless the MCS should recover given enough time. The 1.16 rate control sampling operating with ~1-2 packets per second (assuming a 1kB packet size with iperf) is less than ideal for the 1.16 iteration.