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.

3

Thank you for the clarification.

We understand that the rate control behaviour in low/moderate throughput scenarios is being actively improved beyond v1.16, and that the current limitation is related to insufficient sampling at low packet rates.

We will proceed to test the same mobility scenario on v1.17 and share our observations, particularly focusing on MCS recovery behavior under low unicast traffic conditions.

Could you also please let us know the expected timeline for the 1.17 release (for MM6108) that includes the additional rate control improvements you mentioned?

Looking forward to validating the improvements.

Thanks again for your support.

Regards,
Kumar M.

4

1.17, for the MM6108 specifically, is currently in the final stages of testing for release, if all goes well it should be out in the next couple of weeks.

Hopefully it improves your MCS recovery issues.

I’ll reiterate though, 1.17 has a few of the low/moderate throughput MCS related fixes in it, however the release following 1.17 will have the additional fixes that didn’t make the tag. That will take some time to be released compared to 1.17 so ideally you’ll see some improvement with 1.17.

Best of luck,
Michael