|
|
|
|
|
|
by drvdevd
3539 days ago
|
|
|
Thank you for your efforts! This is great. I personally don't know a ton about wireless but am not opposed to digging in and contributing or testing when/if I have time/hardware. Which leads me to a question: what about 11ac is revolutionary if it's just a few bits away from a completed 11n codebase? Just curious. |
|
|
You have MCS0->9, and then you have 1->n spatial streams. It's like 11n, but they didn't make the MCS numbers just keep going up above MCS15, MCS23, etc. Negotiation is easier - you have to do MCS0..7, then you can say whether you also do 8 and 9.
Everything is block-acked when you negotatiate it - even individual frames. It still negotiates AMPDU and AMSDU like 11n, but then everything is BA'ed versus 11n where some frames are and some frames aren't. The 11ac AMPDU is almost the same as 11n, but it adjusts the maximum AMPDU sizes to be much bigger.
It's still MIMO, and you can implement multi-user MIMO when you're ready. You don't have to out of the gate. This makes it easier to do basic 11ac bringup before you have to do more useful optional bits. There are some extra IEs to handle in beacons, probe request/resp, etc, which isn't all that scary.
The trouble(!) is it kinda forces one to tidy up their 11n codebase first. The way we represent channels in net80211, for example. We have one channel for each PHY type and frequency - so, say channel 36. There's 36/a, 36/ht20, 36/ht40. For 1, it's 1/b, 1/g, 1/ht20, 1/ht40. For 11ac we're going to have to add say, 36/vht20, 36/vht40, 36/vht80. Now, 80+80 becomes painful because the other 80MHz slice can be anywhere and that's not easily represented without a massive explosion in the number of channels. So, how channels are fetched/accessed/etc needs to be changed.
There's also the situation where we currently support a "global" channel for a device, rather than one channel per vap, separate scanning state per VAP for full offload devices, etc. That has to change for full offload devices (iwn, iwm, ath10k, rsu, etc) which can do scans in firmware without the stack being involved.
Linux mac80211/cfg80211 solved this with the concept of "channel contexts" - they used to do exactly what we did in net80211 (one channel struct entry per PHY type + channel combo) but fixed it when 11ac came along. Every driver needed modification, so that's going to take some time to plan out and implement.
There's also some tidying up to do with notifying the upper layers about frames. Eg - NICs does AMSDU offload now in the 11ac world. AMSDU is multiple MSDUs in one frame - ie, multiple ethernet frames in a single 802.11 frame. So, you have to tag received frames with some information that states it's a de-cap'ed AMSDU frame with the sequence number, crypto info, etc of the single big 802.11 frame you received. This is problematic because the stack right now expects each frame to have its own sequence number, crypto IV, etc and does duplication detection. I just started committing some newer pieces to the net80211 RX path so we can handle cases like this when AMSDU offload happens - which is very soon now.
So yeah, it's "a few bits away", but since the four of us actively doing wifi stuff in FreeBSD are unpaid volunteers, things happen at the rate of spare time. If you're interested in learning about this stuff and aren't afraid of a C compiler than hit me up (adrian@freebsd.org) and let's hack on this.