New Router Grabs More 5 GHz Channels To Speed Up Your Wi-Fi

[sfx2000]

We agree, as users we don’t like channels being changed when we’re in the middle of something. Portal will actually avoid predictive channel changes (due to traffic) when it senses that users are in the middle of something like streaming a movie, playing a game, downloading a file, etc…. Portal can schedule channel changes for the long idle periods when no client devices are actively associated. Forced changes due to “radar event” are however unavoidable (consider it the cost of using the DFS channels) and by law they have to evacuate the occupied DFS channel within 200ms.

In DFS, it's pretty much transparent, as the channel change happens at the PHY, not at the MAC/Network layer, and it's pretty fast, users shouldn't even know it happens, as this timing is well within TCP and UDP framing time.

Even without resorting to 802.11 extensions - it's intrinsic in the base spec... but of course spec doesn't define implementation

There might be some buggy client drivers out there - and there are, and then there's not much you can do about that. Stupid is as stupid does with those vendors...

 

[sfx2000]

Portal's mesh uses 802.11s mesh, which operates at Layer 2 and uses dynamic PHY routing.

I certainly hope they know that 11s doesn't scale very well - might be fine for a few nodes, but once you get above a certain number - it falls apart due to overhead - and let's not get into WPA2 and auth - many trust issues there with key management and key escrow across the mesh, especially as Group Keys start to rotate - which for good security, they must - and handling client side Pairwise Keys as clients hop from node to node.

That's why it don't scale...

The other issue with 11s mesh is that IEEE can only do so much - in WiFi, they own the MAC layer and below in the OSI stack - IETF owns the upper layers, and there it's a real mess (or mesh, pardon the pun).

Interesting to note that most IoT initiatives are not doing mesh, they're hub and spoke, as it's easier to manage.

I have first hand experience with this stuff in early launch/well funded startup... perhaps Portal has a better way, but I'm not seeing it.

 

[terry_idl]

So, channel availabilty time scan is 60 seconds as per FCC (item <1> above) - it's during a detection event that we have 10 seconds to get out, and then set the occupancy timer to 30 minutes.

See FCC 905462 D02 UNII DFS Compliance Procedures, section 5.3

cool eh?

(FYI - I'm a recovering IEEE standards engineer, gotta know how to read into the specs)

Just so we're all on the same page...

View attachment 6359

Timeline example below from Mark Briggs @ ElliotLabs whitepaper about DFS interpretation with regards to the EU side - this one is a bit dated, but still a nice walkthru...

View attachment 6360

--------------------
Thanks for the kind welcome, sfx2000. Very cool summary.

Agree with you, that folks have been doing DFS since 11a (I do remember, I was there). However, there are some fairly exotic aspects to DFS, and it isn't as easy as just opportunistic scan... otherwise we'd see DFS everywhere, right?

First off, you need a special detector and specialized algorithms to detect radar. It isn't enough to just opportunistically scan using the main Wifi receiver. Look at Table 5 of the FCC doc you referenced, you'll notice that the radar pulses are really short, as short as 1 microsecond. Compare that with WiFi 802.11ac packets, which are 40 microseconds or longer. You'll also notice that there are about 20,000 distinct radar patterns and you have to detect and classify them really fast. And there is no ack, retry or second chances, especially not during the CAC (Initial Channel Availability Check); you have to find the radar in just one pulse in some cases. Given the complexity of this, you can understand why not all WiFi chipsets come with such a detector nor does every vendor have the capability to implement the complicated detection and classification algorithms necessary to do this.

Second, the DFS spec doesn't allow you to do opportunistic scan during the critical CAC phase. By opportunistic scan, I mean that your main WiFi transmitter and receiver are still active and you're time-sharing the radar detection function. Take a look at 7.8.2.2 (c) of the same FCC doc you referenced; this is the initial CAC period (what I've previously called the 60 seconds quiet listen period). You need to do this for any DFS channel that you want to use and you need to do it immediately prior to using that channel. So, why is this so hard? You'll notice that the spec requires you to detect a single radar burst of just one pulse sent at a random time during this CAC period, and you have to do this for each of the Type 0-4 radar patterns. This is the radio equivalent of picking up a needle in a haystack with only one quick pass at the haystack. You can't possibly do this by opportunistic scan because (a) your radio is by definition on a different non-DFS channel and you can't possibly switch channels fast enough; and (b) even if you could switch channels very fast, you're going to be deaf every time you Tx, which may be alot depending on the number of clients associated and the data rate. In short, the only way that you can pass this test is to drop all your connections, park on the desired DFS channel, and listen 100% of the time for a full 60 seconds. Some routers, actually need up to 4 minutes to do this, usually because the detection threshold is so tight they have to do this in multiple passes.

Thirdly, you have to pass the test at the certification lab. Of all of the FCC Part 15 tests, DFS is currently the only spec that cannot be completed at an outside TCB lab (they can start, but it needs to be finished by the FCC themselves). This may be changing soon, but as of today the FCC insists on audit of nearly 100% of all DFS-capable routers at their facility in Columbia, Maryland; they can only do about one a day, making this a real bottleneck. Another reason why there aren't many DFS-capable routers in retail. They do give concession for companies who do DFS certification regularly, but this is mainly for the big guys like Cisco, not the consumer retail guys. We know this because we've been there. And you should see my bill for TCB lab time, this stuff isn't cheap and we have folks that literally live in the TCB lab.

My intention isn't to be pedantic or to shown off, I merely want to provide a glimpse into the complexity and difficult of DFS. If it was really as easy as opportunistic scan, we would have done it that way or picked something else more challenging to do. Hope this clarifies things.

 

[sfx2000]

Agree with you, that folks have been doing DFS since 11a (I do remember, I was there). However, there are some fairly exotic aspects to DFS, and it isn't as easy as just opportunistic scan... otherwise we'd see DFS everywhere, right?

First off, you need a special detector and specialized algorithms to detect radar. It isn't enough to just opportunistically scan using the main Wifi receiver

It's built into QCA, Broadcom, and Marvell chipsets... I suspect MediaTek and Realtek do as well - as it's kind of a requirement - if not from a regulatory side, perhaps from a business side...

Second, the DFS spec doesn't allow you to do opportunistic scan during the critical CAC phase. By opportunistic scan

Specs do not define implementation - implementation must meet spec - but that's where innovation comes from eh?

Thirdly, you have to pass the test at the certification lab.

Indeed - and most silicon does as a reference platform.

 

[terry_idl]

So if I'm understanding this correctly, any other manufacturer simply has to scan for an active radar event channel and block it 'permanently'. Then, the other DFS channels become available as normal channels (with the same 200ms 'kick off' time if a radar event (unlikely, according to the above discussion), occurs on that channel).

So, a continuous and simultaneous scan for other channels is not necessary (nor is the hardware for that needed either).

When things are explained like the above, it doesn't make sense the workarounds that are done to 'certify' equipment to make them 'auto' (which invariably means 'dumb', to me).

---------------
In theory, this would be a logical approach. However, that's not how things work in reality. If you read thru the FCC spec or similarly ETSI for Europe or MIC/ARIB for Japan, you'll see that all regulatory regions require continuous scan of the intended DFS channel before you use it, and continuously while you're using it. The first is called the CAC (Channel Availability Check) and the second is called ISM (In-Service Monitoring), and the CAC requires your router to be completely silent during the 60 second scan. And oh, you do need a specialized detector. Pull up the data sheet for any chipset that supports DFS and you'll notice a block in there usually labelled spectrum analyzer or radar detector.

As to the myth of the "auto" setting, it's what could be described as a necessary but not sufficient condition. If your router is capable of DFS, you have to set it to auto because in the event of a "radar event" the router has to have the ability to jump to another non-DFS channel without your input. Put another way, the router manufacturer is not permitted to allow you to pick a fixed DFS channel because they can't guarantee that it is or will always be free of radar; if you want to use the DFS band, you have to let the router do the channel picking for you. However, just because you put your router into auto doesn't mean that your router is DFS capable... that's the not sufficient part. If your router isn't DFS capable, putting it into 'auto' simply tells the router that you want it to pick the channel from a list of non-DFS channels.

You can prove this to yourself easily. Find a pre-2013 Apple Time Capsule and post-2013 Time Capsule. First pull up the FCC ID, you'll notice that the pre-2013 models are not authorized to operate in DFS whereas the post-2013 ones are. Then plug them in and set them both to 'auto'. They both use the same Airport Utility tool, so this is truly apples-to-apples (yes, pun intended). You'll notice that the pre-2013 model will always park in lower 5GHz or upper 5GHz, but never a DFS channel. And of course, the post-2013 model will often (but not always) find a DFS channel, usually channel 100. Same box, same maker, same software, same auto setting. Two different behaviors.

As to myth of simple firmware upgrade to get DFS, another good test is go order a Netgear R7800 from a US online store, and get a friend to pick you up the same Netgear R7800 from Europe. Same box, same specs, same configuration, but different certification. The US model is not DFS certified and cannot operate in DFS band, whereas the Europe model does. Try to upgrade the firmware? First open it up, you'll notice that they use completely different chipsets. Simple firmware upgrade won't work. And BTW: even if you could find a model for which firmware upgrade does work, it is illegal. Get caught and it's a very hefty fine. It's for this reason, all the mainstream router manufacturers put stiff locks on their software. And now the FCC is weighing in by banning the use of any user software (such as OpenWRT) that can manipulate the channel selection logic. If you want your router to be allowed to accept open source user software (like Linksys) you have to demonstrate to the FCC that there is no physical way for that software to select DFS bands unless it is so certified.

 

[terry_idl]

Also do keep in mind that the radar we are talking about here are safety and life critical equipment, they are what keeps you safe when you're landing in airports prone to weather conditions. These are not optional check-box features or "my router is faster than your router" specs. The FAA and FCC take this very seriously and do not allow any room for short cuts or workarounds, or worse folks cheating by installing user firmware. The proof is in the seeing it for yourself. Go out and buy yourself a dozen routers off the shelf from Best Buy, Amazon or Frys. Try it yourself, do a survey. You'll see that if it was so easy, DFS would be everywhere... but, it is not.

 

[sfx2000]

Not to do a MIC drop on you...

1) I've designed CPE for major telcos in my past roles
2) Those telcos were my customers, now the people I worked with are my vendors
3) I'm likely someone you want to do business with some day

I've been in this business for over 30 years, and there tidbits of my code in every 3g/4G/LTE phone in the world.

Don't tell me I'm wrong.

I totally get DFS - and the WiFi community has been doing it for several years - consumer grade, perhaps not, but the technology has always been there.

 

[thiggins]

SFX: No need to make this personal. Take a breath.

Terry: Is SFX' assertion about DFS detection being built into today's Wi-Fi chipsets correct? And does chipset level certification carry into end product use?

 

[L&LD]

---------------
In theory, this would be a logical approach. However, that's not how things work in reality. If you read thru the FCC spec or similarly ETSI for Europe or MIC/ARIB for Japan, you'll see that all regulatory regions require continuous scan of the intended DFS channel before you use it, and continuously while you're using it. The first is called the CAC (Channel Availability Check) and the second is called ISM (In-Service Monitoring), and the CAC requires your router to be completely silent during the 60 second scan. And oh, you do need a specialized detector. Pull up the data sheet for any chipset that supports DFS and you'll notice a block in there usually labelled spectrum analyzer or radar detector.

As to the myth of the "auto" setting, it's what could be described as a necessary but not sufficient condition. If your router is capable of DFS, you have to set it to auto because in the event of a "radar event" the router has to have the ability to jump to another non-DFS channel without your input. Put another way, the router manufacturer is not permitted to allow you to pick a fixed DFS channel because they can't guarantee that it is or will always be free of radar; if you want to use the DFS band, you have to let the router do the channel picking for you. However, just because you put your router into auto doesn't mean that your router is DFS capable... that's the not sufficient part. If your router isn't DFS capable, putting it into 'auto' simply tells the router that you want it to pick the channel from a list of non-DFS channels.

You can prove this to yourself easily. Find a pre-2013 Apple Time Capsule and post-2013 Time Capsule. First pull up the FCC ID, you'll notice that the pre-2013 models are not authorized to operate in DFS whereas the post-2013 ones are. Then plug them in and set them both to 'auto'. They both use the same Airport Utility tool, so this is truly apples-to-apples (yes, pun intended). You'll notice that the pre-2013 model will always park in lower 5GHz or upper 5GHz, but never a DFS channel. And of course, the post-2013 model will often (but not always) find a DFS channel, usually channel 100. Same box, same maker, same software, same auto setting. Two different behaviors.

As to myth of simple firmware upgrade to get DFS, another good test is go order a Netgear R7800 from a US online store, and get a friend to pick you up the same Netgear R7800 from Europe. Same box, same specs, same configuration, but different certification. The US model is not DFS certified and cannot operate in DFS band, whereas the Europe model does. Try to upgrade the firmware? First open it up, you'll notice that they use completely different chipsets. Simple firmware upgrade won't work. And BTW: even if you could find a model for which firmware upgrade does work, it is illegal. Get caught and it's a very hefty fine. It's for this reason, all the mainstream router manufacturers put stiff locks on their software. And now the FCC is weighing in by banning the use of any user software (such as OpenWRT) that can manipulate the channel selection logic. If you want your router to be allowed to accept open source user software (like Linksys) you have to demonstrate to the FCC that there is no physical way for that software to select DFS bands unless it is so certified.

I think you misread what I wrote (or at least have the 'intent' of what I originally wrote, wrong).

I am confident after re-reading all relevant posts that if the info presented was accurate, my conclusion was too. sfx2000 seems to agree with me too?

 

[sfx2000]

SFX: No need to make this personal. Take a breath.

Terry: Is SFX' assertion about DFS detection being built into today's Wi-Fi chipsets correct? And does chipset level certification carry into end product use?

Ok, had a chance to calm down a bit...

Chipset firmware runs it's own RTOS - sometimes is it a "binary blob", sometimes it's burned into the chip directly via ROM/EEPROM - and that firmware has many options that a vendor (or third party dev) can peek and poke into - it's a private little sandbox that the vendor owns. That RTOS isn't visible normally to the main Router/SOC, except to send events, and expect inputs - it's out of band from WiFi and the main networking stack - it talks to the SoC at a kernel/driver level - this is how most STA drivers work. And AP or Client, they're all STA's

To Terry's Point - OEM's can drive a config into the chip when it boots - and this is actually the reason why certain changes can cause a WiFi network to restart, as that RTOS reads at boot up of the chip - dynamic changes need to be addressed as part of that config pushed in at boot - but that's all implementation - I can't speak more to this as there are concerns that neither Terry or myself can disclose.

(FWIW - it's driving those params into the chip that is currently the issue with the US FCC Firmware lockdown conversation)

That being said - this is why many vendors don't enable this option in the consumer space - it's the customer experience, and some of the vendor SDK's, seeing a DFS event, reboot rather than just do a dynamic re-tune.

Many times this is not the wifi chipset itself, but how it's integrated with the rest of the board support package.

Looks like Ignition Design labs, along with their partners, have sorted this out for a consumer level product.

nicely done

 

[sfx2000]

Chipset firmware runs it's own RTOS - sometimes is it a "binary blob", sometimes it's burned into the chip directly via ROM/EEPROM

FWIW - not trying to side track the discussion - a lot of folks were pretty excited with the RaspPI when Broadcom actually opened up the kimono a bit - documenting their GPU, as that chip boots the firmware RTOS first for the GPU, and then loads from there - hint, hint...