I’m capturing 902.11ah traffic between an AP and 1 STA (both Halowlink-1s). Running an iperf server on the AP, and iperf client on the STA, set as “iperf3 -c 192.168.69.1 -u -i 1 -p 5201 -b 1M -t 0”. I have high enough SNR to achieve MCS7 with no packet loss. I have a spectrum analyzer in Zero-Span with RBW = BW of the halow channel. I’m seeing what I believe to be, an extremely long delay between frame end and ACK, as well as extremely long ACK duration—200us for each. Is there a way to decrease the duration of both ACK duration and delay before ACK?
We believe this is likely reducing the overall throughput of our system since ACKs have large overhead w.r.t. data transmissions.
This looks to be a standard 802.11ah ACK duration. The IEEE standard SIFS is 160us, which is what you are measuring at delta three, likely with an extra 20us in some measurement error.
The -b 1M in iperf3 -c 192.168.69.1 -u -i 1 -p 5201 -b 1M -t 0 will be forcing the throughput to 1 Mbps. Are you seeing lower than 1 Mbps? What throughput are you measuring? Use -b 0 to push the bandwidth limit as high as it can go.
As a side note, if you’re running the iperf3 client on an HL1, you may want to use something like -b 25M/40 (the /40 will send packets in bursts, which will reduce iperf3 CPU usage).
Can you please point me to where in the 802.11ah standard that it dictates standard ack duration? As I understand the ack needs to be transmitted at <= the MCS rate of the transmission. We are not seeing lower than 1Mbps throughput. Changing desired throughput on iperf did not change ack duration, 1M was used for ease of displaying measurement. Hard setting different MCS indexes with morse_ctrl did not chang ack duration either.
The ACK format in 802.11ah is defined in 23.3.12 of IEEE802.11-2024. These are sent as NDP CMAC PPDUS and differ in length depending on whether it’s 2MHz or 1MHz transmission. MCS rate of the transmission does not come into consideration. For 2MHz they are 6 symbols long, and for 1MHz they are 14 symbols long (including the STF and LTF field), each symbol is 40us, which becomes 240us for 2MHz, and 560us for 1MHz.
Hi, I work with mpsini, and have a follow up regarding the ACKs on the HalowLink1s. We’ve noticed that we are liable to run into adjacent channel interference issues when attempting maximum range at 8MHz bandwidth for a multi-antenna system. I measured the strength of the ACKs and noticed that it was roughly 19dBm output power. The isolation between adjacent APs is roughly 50dB, and with a 10dB ACR, that leaves a min received power of -41dBm before we start self-jamming. I’ve confirmed this theory with experimentation. Are there any mechanisms that we can use to lower the output power of the ACK frames? Would this be controlled by the BCF setting for MCS0? Thanks,
