Adding IEEE802.11ah compatibility

[irongiant33]

Hi Bastian,

I have been working on building a SDR receiver for Wi-Fi HaLow, a.k.a. IEEE 802.11ah. You can find my documentation and some GRC flowgraphs here: https://github.com/irongiant33/gr-halow.

The implementation is far from complete, but I have been using gr-ieee802-11 as the basis for my changes. By opening this pull request, I hope you'll see something that I am missing in terms of getting a fully running receive flow. My current approach breaks your implementation of IEEE 802.11a/g, but I intend to go back and ensure gr-ieee802-11 is fully compatible with 802.11a/g/ah when my code actually works. I just thought it would be easiest to modify in place to compare the diff first before making a separate PR for the addition of 802.11ah functionality.

Why?

I think that it is way more achievable for a real-time SDR implementation of 802.11ah than 802.11a/g, especially with more affortable SDRs like the PlutoSDR or HackRF. Unlike the high bandwidth and data rate for 802.11a/g, 802.11ah operates at 10x lower bandwidth/rates than 802.11a. Instead of 20, 40, 80 and 160 MHz bandwidths, HaLow operates with 1, 2, 4, 8, and 16 MHz channels. The devices I have currently only support the 1, 2, and 4 MHz channels.

If the purpose of HaLow is extending mesh network reach as well as number of devices available on the network, I think adding SDR transceiver functionality can expose more hobbyists and developers to its benefits and make HaLow more accessible.

Current Approach

I have been reading upon IEEE Std 802.11-2020 to compare your implementations of 802.11a/g with 802.11ah. So far, you can see I mostly have been redefining constants except for the frame equalizer implementation where I am actually trying to pull out information from the SIG field of the PPDU. For the time being, I am considering that even pulling data from the SIG field is a win. At that point, I would ensure compatibility with 802.11a/g before making a pull request here and then going on to add MAC logic to the receive chain for getting information from the data field.

Lingering Questions/Problems

I'll add comments directly to code as necessary, but in general, if you see anywhere I might be falling short based on your implementation of ieee802-11 I'd appreciate your insight

[irongiant33]

Where do you get this array from? https://github.com/bastibl/gr-ieee802-11/pull/412/files#diff-91c264c8b16fa2e3de166f93e05cd89098c6e02e45f90e8f1344848ba73629d6L257-L290

Initially, I thought it was from p.4170 of the 802.11-2020 spec, but that section only corresponded to this array: https://github.com/bastibl/gr-ieee802-11/pull/412/files#diff-4dc901ae703564f5a6774a2f7c6fcdc47eb988e5182bd3a9e6957667b46ee7c9L24-L28

[bastibl]

Hi, great to see work on HaLow! The approach makes sense. Unfortunately, the link to the array in question does not seem to work for me. Maybe you could link to the current file and not the PR, which might change if you push more commits.

[irongiant33]

sorry that the link disappeared, the array below is the one I am not sure where it comes from in the standard.

[irongiant33]

essentially, I am trying to get down to the root of the HaLow synchronization problem that I am trying to discuss here: https://github.com/irongiant33/gr-halow/blob/main/docs.md#wifi-synchronization. For some reason, my modifications to sync long and sync short are not producing output and I'm trying to figure out why. No point in trying to fix the frame equalizer yet if no data ever reaches it haha

[bastibl]

See this script: https://github.com/bastibl/gr-ieee802-11/blob/maint-3.10/utils/sync_words.py IIRC, in the standard the preambles are only specified in frequency domain.

[irongiant33]

you are correct, but the file seems to be this R script instead of the Python script you mentioned. https://github.com/bastibl/gr-ieee802-11/blob/maint-3.10/utils/create_long.R. I'll keep digging from here and let you know if I have some more questions, thanks!

[irongiant33]

@bastibl What was your intention for the sync_short and sync_long blocks? Was it for sync_short to perform coarse frequency correction and roughly labels the start of the wifi frame on the short training sequence, and then sync_long does fine frequency synchronization and timing correction then re-tags the start of the wifi frame to be more accurate on the long training sequence? Hence the tag propagation policy of "do not propagate".

Reason for asking is because I believe that I may be getting thrown off by the IEEE specification overloading the terms "SHORT" and "LONG". I reviewed the specification for clauses 17 (802.11a) and 19 (802.11g) and I think that short and long in your context (802.11a/g) refer to the training sequences in the preamble, but 802.11ah it has multiple meanings.

Where the "short" and "long" terms get overloaded with HaLow is on p.3197, section 23.3.2 of the specification "S1G PPDU format" that defines three formats for the S1G PHY: S1G_SHORT, S1G_LONG, and S1G_1M. Each of these formats then has a short and long training sequence.

On the bright side, it is looking like I am roughly getting close to synchronization after sync_short, but I might need to dig into sync_long some more to figure out why it looks so weird.

• Time plots after the sync_short and sync_long blocks showing the correct number of tags, as well as correct tag placement
• Zoomed in time plot showing that sync_short appears to be roughly synchronized, whereas sync_long looks to be off

[bastibl]

Short is for frame detection and a first frequency offset correction. It uses the plateau of the auto correlation of the short training field to trigger frame detection. It's computationally efficient but not precise.

Once a frame is detected, Long searches for the precise frame start by cross correlating with the long training symbol and aligns the FFT window accordingly. It also removes the cyclic prefix, does another frequency offset correction.