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

[pete y testing]

But for a client - it's really about searching and finding an AP - so an AP operating if DFS space - the client just has to passively scan for beacons in those channels,

hmm im a little confused here , i have a fritzbox that a german unit and only uses lower and mid range channels on 5 gig

because the pce-ac68 can only see the low and high ranges when connected to the fritzbox it then only see's the low 5 gig and nothing else

whereas the tp link t9e can only see the low and mid range channels on 5 gig and does not see the high channels as in it does not show up as being detected if the router is set to say ch 153

 

[thiggins]

Thanks for the DFS details, SFX. I was regurgitating information given to me by the IDL guys. You clearly know more than I here.

 

[RMerlin]

the regs state that unless its actively scanned the 30 minute rule applies

Sounds like a loophole then. As they never stop scanning, they can switch back at any time they want, as soon they see the channel frees itself.

 

[pete y testing]

Sounds like a loophole then

not sure if its a loop hole or what the regulations state as until now we havnt had a device that actually actively had a specific radio to monitor and control the specific channel range , so its prob following a specific part of the regulation that states under a certain set of conditions this can be done if the above applies

 

[RMerlin]

not sure if its a loop hole or what the regulations state as until now we havnt had a device that actually actively had a specific radio to monitor and control the specific channel range , so its prob following a specific part of the regulation that states under a certain set of conditions this can be done if the above applies

I didn't imply it in a negative sense.

 

[sfx2000]

Thanks for the DFS details, SFX. I was regurgitating information given to me by the IDL guys. You clearly know more than I here.

NP - QC-Atheros, along with the IDL's folks should be applauded for bringing this in, as the DFS gaps and blacklisted channels (due to reg domain reqt's) make things a bit challenging..

Remember, most Vendors don't allow DFS channels to be manually selected due to the listen before transmit requirement, and also because of that requirement, it makes things hard for the user ("I changed the channel, and now it doesn't work...) and Customer Care/Tech Support.

 

[pete y testing]

wonder if and how this will also deal with tpc ( transmit power control ) as here those channels are both dfs and tpc regulated

 

[sfx2000]

wonder if and how this will also deal with tpc ( transmit power control ) as here those channels are both dfs and tpc regulated

It will - it has to...

so in some markets - it will be a bit better than others, depending on regulatory domain constraints...

 

[remixedcat]

I've had a few adapters even refuse to connect or even see the APs if they were in DFS channels... Realtek adapters specially.

 

[remixedcat]

I've seen a lot of snake oil. If this technology works well, it has more practical potential than a lot of the other "innovations" being foisted on us.

Keep an open mind.

Like the 160Mhz nastiness?

 

[terry_idl]

thats fine for the states and canada where its not allowed atm but in europe they already use those channels but not the higher ones

those channels will also start to get congested if this technology takes off just like initially the lower 5 gig and now the upper 5 gig channels are in congested areas , everything look great when its the first on the block but once everyone else moves in as well its back to the same same

these dfs channels also dont have the same power tranmit levels as the higher 5 gig do they ?

im just not sure i like the idea of being switched to a new channel while im in the middle of something as i assume it wont be a true seamless change

like i said i will sit on the fence and see what eventuates , looks like we wont get them here anyway

-------------
Hi guys, I'm new to the SNB forum. Glad to be participating in this conversation. I'm one of the co-founders of Ignition Design Labs, the makers of Portal. I wanted to contribute additional details to the discussion. I will try to keep the marketing bs to a minimum.

The upper 5GHz band (5.725-5.825 GHz) is actually forbidden to use in Europe. It's why they appear to not use the upper 5GHz bands. Without DFS, they can only use the lower 5GHz (5.15-5.25 GHz) where all 802.11ac traffic is crowded onto a single overlapping channel. It’s the same situation in Japan.

Yes, agree with you. The upper 5GHz band in the US is also becoming crowded just like the lower 5GHz already is. If nothing is done, even the DFS bands will start to get crowded once folks start using it; although there is 3x more spectrum here so it will take longer for the DFS band to get overcrowded. One of the other technologies we're trying to introduce in Portal is coordination between routers to spatially allocate channels to avoid overlap; it’s a technique called frequency re-use or network load balancing, and it’ll significantly increase the efficiency of the spectrum and in theory could prevent overcrowding for a very long time.

Yes, it’s true that Europeans have been using DFS channels longer than us here in the USA. But even in Europe, our approach to DFS in Portal is quite different; and we're getting quite a bit of traction there because quite frankly the current DFS solutions the Europeans have is quite unreliable. Almost all of the current DFS-capable routers are only capable of operating on a single “static” channel. Yes, I know that’s an oxymoron. It’s static in the sense that the router has to select this channel a priori (meaning ahead of time, usually at startup) and can only stay on this one fixed channel until either (a) it gets kicked off this channel because it encounters a “radar event”; or (b) the user resets the router. And when it’s kicked off the DFS channel, it is kicked out of the DFS band altogether and has to revert back to a crowded non-DFS channel (usually lower 5GHz) and stays there until the user resets the router. It’s better than nothing, but you can see that it’s not a reliable solution. And BTW, this “emergency evacuation” of the DFS channel is mandatory and the user has no choice. It’s one of the key provisions of the regulations and the FCC actually tests for this during certification. It’s the main reasons that not every router uses DFS because it really is a big pain (and expensive) to get certified.

The Portal solution is different because it's continually scanning all of the DFS channels simultaneously, not just one. If Portal encounters a “radar event” (which you can’t avoid, think of it as “cost” of using the DFS band), it simply jumps to another DFS channel and stay in the uncrowded DFS band. This also allows Portal to change channels on demand because it employs real-time traffic monitoring and and very fast agile radios. In demos, we show channel switch and settle within 500ms which is imperceptible to streaming video, even ultraHD, and file transfers. In short, you get all the benefits of using the DFS bands without having to suffer the penalties or cumbersomeness.

Actually, the DFS channels allow for higher EIRP power with TPC than the non-DFS channels.

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 such a case, Portal mitigates the unpleasantness of this event by switching to a new DFS channel, usually within 500ms. In the case of streaming movies or FTP file download, that’s not enough to cause any perceivable disruption.

Hope this helps clarify things. If any of you are in the Bay Area, I would be happy to host you in our lab and let you try Portal for yourself. Bring your own client device and "take it for a spin".

 

[terry_idl]

What allows this product to avoid this rule? Is that a regulation rule, or just that other DFS implementation decide to only rescan every 30 minutes, for performance reasons?

---------
The 30 minute “non-occupancy time” rule is actually part of the DFS specifications. The regulatory agencies actually tests for the spec, and all DFS-capable routers must comply. Conventional DFS routers, when they encounter a “radar event”, they have evacuate the occupied DFS channel within 200ms then stay off that channel for minimum of 30 minutes, then in order to get back onto another (or the previous) DFS channel, it has to drop all connections in order to go into a quiet listen-only state and do a continuous scan for between 1 and 4 minutes. In short, a real pain which most router manufacturers avoid by simply limiting their equipment to operate in non-DFS channels only.

Portal is fully compliant with this rule, and has to follow the 200ms evacuation (channel closing) time and 30 minute non-occupancy period same as every other DFS-capable router. The trick to Portal is that it is continuously scanning all of the DFS spectrum and keeps 3 other DFS channels warmed up and ready-to-go, so it simply jumps to one of the ready-to-go channels very quickly within 500ms so it doesn’t interrupt your video or file downloading session. In short, Portal avoids the penalty of the 30 minute wait (and the 1-4 minute re-scan) by keeping multiple DFS channels available… in effect, a form of fail-over redundancy.

 

[terry_idl]

another factor i just thought about is the adapters , many dont support the dfs channels anyway , eg my pce-ac68 only supports upper and lower channels on 5 gig , the tp link T9E however only supports lower 5 gig and dfs channels and not the upper 5 gig channels , i know thats in the drivers but that to comply with the regs

i havent see an adapter yet that can or will cover the entire spectrum

---------------
I don’t know about PCIE adapters specifically. But we do know that all mobile clients like iPhone 5 and 6, iPad 3 onwards, most Android smartphones and tablets after 2013 (like Samsung Galaxy S3), MacBooks and most newer Windows laptops (with built-in Centrino, BRCM or Qualcomm/Atheros WiFi) do already support the full DFS spectrum. All of the demos with Portal have been done with off-the-shelf smartphones, tablets and PCs without any special software.

If you're in the Bay area, you can come to our lab and try out Portal for yourself with your favorite mobile client device.

 

[terry_idl]

Is there a way to adjust the time limit, e.g., from 30 minutes, to 30 milliseconds?
I wonder if there are cases where a radar system may spam a bunch of crap over a wide range of frequencies, and how DFS will behave in such a case.
I just worry about the reliability of DFS, as the way I see it, if you have a need for those channels, then it is hard to trust the reliability of the connection since 100% availability is not guaranteed. The last thing you want is to be in a situation where you must use WiFi, and the router decides to switch channels while you are in the middle of a multiplayer game.

-------------
See the response for #11 above. The 30 minute non-occupancy rule is part of the DFS specifications and cannot be changed by user. And yes, it is minutes... that's an exceedingly long time.

It is unlikely (pretty much impossible) for radar to “spam a bunch of crap” over wide frequencies. Radar systems are highly tuned and well maintained, they are also very narrow band. If there is radar present in your area, it is localized to just one channel. Portal’s secret sauce is it can scan the full DFS spectrum continuously and simultaneously, so if a radar is present or even intermittent, it can find it and exclude that channel permanently; the other three remaining DFS channels will be clean and stable, and once settled on one of these channels your router is unlikely to move. And even if that channel becomes crowded over time, Portal’s predictive traffic monitoring and dynamic channel selection won’t make a channel change while you’re in the middle of a game. Portal will wait until it sees a long idle period before it does (say 6am in the morning).

More importantly, for gaming over WiFi, staying in a congested channel will cause much worse gaming experience over a long period of time compared to a channel change. Interference is the major cause for severe lags and will make gaming truly un-enjoyable.

Alot of the Portal guys, myself included, are big-time gamers, so this stuff is important to us.

 

[terry_idl]

hmm im a little confused here , i have a fritzbox that a german unit and only uses lower and mid range channels on 5 gig

because the pce-ac68 can only see the low and high ranges when connected to the fritzbox it then only see's the low 5 gig and nothing else

whereas the tp link t9e can only see the low and mid range channels on 5 gig and does not see the high channels as in it does not show up as being detected if the router is set to say ch 153

---------
European certified equipment are actually forbidden to use the upper 5GHz band (5.725-5.825 GHz). This is probably why your Fritz box access point only operates in low 5GHz and mid-5GHz (DFS).

Your Pce-ac68 PCIe client was probably certified for international operation so can operate in the upper 5GHz in US (when it sees a US-certified router which are all capable of both lower and upper 5GHz band). Some clients are actually DFS-disabled, but this is not the norm and quite frankly unnecessary (likely a cost savings exercise to avoid paying the few extra hours it takes during certification testing. In our experience, many of the Asus branded PCIe and USB clients are like this…. it’s a very odd practice.

Your TP-Link t9e is more conventional (not DFS-disabled) so it can operate in the mid 5GHz (DFS) band if it finds a suitably capable and certified DFS router like your Fritz box. It probably can operate in both upper and lower 5GHz also, but it’s likely not seeing the upper 5GHz because your Fritz box cannot operate there. As a rule, the client device follows the router; if the router can do it so can the client, if the router can’t then neither can the client.

 

[RMerlin]

Sounds like a well-thought solution. Thanks for the very detailed explanations - it makes a lot of sense.

 

[sfx2000]

The 30 minute “non-occupancy time” rule is actually part of the DFS specifications. The regulatory agencies actually tests for the spec, and all DFS-capable routers must comply. Conventional DFS routers, when they encounter a “radar event”, they have evacuate the occupied DFS channel within 200ms then stay off that channel for minimum of 30 minutes, then in order to get back onto another (or the previous) DFS channel, it has to drop all connections in order to go into a quiet listen-only state and do a continuous scan for between 1 and 4 minutes. In short, a real pain which most router manufacturers avoid by simply limiting their equipment to operate in non-DFS channels only.

Terry - thank you for stopping by - I'm wishing the team at Ignition Design Labs all the best, and congratulations on bringing innovation into a somewhat stagnant market (bigger/faster, but really not much changed in design/implementation since the WRT54G's from years back).

DFS and the keep out - EU and FCC are similar in this regards - see the FCC requirements/test plan here...

Normally what happens is opportunistic scanning of candidate channels - initialize on a non-DFS channel, and then scan in on a periodic basis - and here's where some folks misinterpret the spec...

If a Radar source is detected - then you must stop transmitting in that channel and leave it for a minimum of 30 minutes. And then, as part of that 30 minutes timer, one does an opportunistic listen only scan, and if energy is still found, you reset the 30 minute timer for channel occupancy..

Nothing exotic here - vendors have been doing this for a very long time, since the advent of 802.11n (and it was also implemented by many 11a vendors).

 

[sfx2000]

The 30 minute “non-occupancy time” rule is actually part of the DFS specifications.

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...

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...

 

[L&LD]

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).

 

[sfx2000]

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).

Exactly - you're on track...

We don't let users select those DFS channels in manual mode, because they don't know there is a radar (or other primary user in that channel), so we limit them to the channels where WiFi is the primary user dependent on the regulatory region.

The DFS testing is a pain, it's long, and it's expensive... there's only a few 3rd party labs that are certified to do this for regulatory approval - and few vendors are self-certified for FCC/CE/etc... as a result, only the big players tend to even consider going into DFS space with their firmware, mostly due to cost considerations for approval.

Interesting to note that in many regions - the AC3200/AC5300 class devices, in order to enable that secondary radio, must go into auto mode to enable the DFS scan process..

@terry_idl - sorry to rain on this picnic....