We have a MR52 which the datasheet claims supporting 160MHz channel width. However I couldn't figure out how to set it up. Then I come up with this article from Meraki, which mentions that 160 MHz is not suitable for enterprise deployments or supported in the Meraki dashboard.
For me this sounds suspicious. I would assume the claim from the datasheet is false advertisement if there is no way to enable 160MHz.
https://community.meraki.com/t5/Wireless-LAN/MR52-and-MR53-ports/m-p/36143/highlight/true#M5712
😞
We were just talking about this yesterday. Seriously though, 160MHz channels are utterly useless. There's pretty much no actual place you can implement them that's practical. I agree, if they say they can do it then it should be there... But do yourself a favour and don't ever enable it.
Unless your doing this for at home, then I agree with @jdsilva
It has no place in enterprise until maaaaaybe one day when UNII-4/5/6/7 become a reality, and even then I doubt it.
From support though, they stated that it is not something that is available yet via software, but that it will be eventually.
@AZAzure I agree with @jdsilva that 160MHz channels is not a "thing" yet, until there's more spectrum allocated. 160MHz channels are supported by the APs but not yet enabled through firmware. Today there isn't enough spectrum to have 160MHz channels AND have a meaningful channel re-use plan, at least for enterprise deployments. Is there a problem you are trying to solve with 160 MHz channels? Not many clients will even support 160MHz channels today. Unless you have mostly or all 160 MHz clients, using 160MHz channels is probably going to have a negative impact on the RF environment (increased noise floor, increased contention).
@MerakiDave wrote:
Got it, understood. Hang in there, it'll be there eventually but unfortunately I don't have a timeline. 26.1 just because the latest beta but it's not there yet, keep an eye on the release notes though.
Please don't go there. It is a waste of time, it performs poorly, it will never be usable because most of the time the channels will overlap, to some extend with the DFS, APC, CAC channels, so there will be frequent outages of up to 60 minutes.
Much better if Meraki devotes more resource to developing 802.11ad networks (including mesh), distance in the 60GHz spectrum is improving all the time. Meshing will work because there is plenty of bandwidth for backhaul as well as connecting to client devices.
The 5GHz portion of the spectrum is overcrowded, there are numerous more pressing use cases than static WiFi, it is headed towards completely autonomous configuration, weighted towards overall spectrum usage efficiency rather than individual requirements. Anybody interested in this stuff should attend the ITU World Congresses. The future of fixed PTMP WiFi is pretty dystopian.
Here is a challenge for you - try and find a client with a 160Mhz capable radio to be able to use it.
@PhilipDAth wrote:Here is a challenge for you - try and find a client with a 160Mhz capable radio to be able to use it.
Nobody asks you that down the pub . . .
You'd better check this:
https://ark.intel.com/products/99446/Intel-Wireless-AC-9560
AC 9560 is a 2x2 wireless card that supports 160 MHz. I believe it is integrated into multiple mobile platforms. And actually I'm using that card.
And I also have a challenge for you:
Find ANY device that supports 4x4 MIMO. Integrating 4 antennas is much more difficult than replacing a current wireless card with an AC9560.
Hate to necro this thread but just occurred to me, that I now have an Intel AX200 chip which supports 160MHz.
At home I have an MR52, on 26.7, and I still don't see 160MHz support.
I actually wanted to test it at home (and only at home lol)
Any update @MerakiDave ?
Maybe just a way to 'only' have support enable it which should alleviate any potential harm it would most certainly introduce to non-IT folk.
Have you seen this - https://www.smallnetbuilder.com/wireless/wireless-features/33210-160-mhz-wi-fi-channels-friend-or-fo...
I regularly use dual 80MHz channels, as I test what happens as the ever present radars cut in. Sometime the Apache helicopters pick up the signal and they turn and look at me, which sets the dogs off . . . Luckily, they have been told what I am doing. The weirdest stuff I pick up are the Antonovs flying overhead when they have livestock onboard and they are under 5,000 metres, they usually send trip the system, as do the Russian navy when they pass through the channel, going south.
Now is a good time for testing, almost no air activity. I have apps on the phone so checking what is causing problems is easier.
@NolanHerring sorry the 160MHz support isn't there yet but should be in the future, I don't have visibility into the timeline though. So for now it cannot be enabled on the back end by Support. Like you indicated, until more spectrum becomes available the demand for 160MHz would be light. But don't let that discourage conversations and use cases that your Cisco/Meraki team can being back to the MR PM team.
Hey @MerakiDave , just curious, is the 160MHz support that's coming just contiguous 160MHz channels or also 80+80 (80p80) mode too?
You're definitely right in that a 160MHz channel is rather impractical especially given how it forces you to incorporate at least 80MHz within a DFS range. I've seen some good bandwidth out of an 80p80 config but unfortunately a lot of client devices have trouble with this setup.
All in all, as others have already said, it's one of those things that sounds neat on paper, but I doubt it will go beyond just a science experiment in the real world.
I believe the plan is for 80+80 (at least initially) but like you and the others have said, there's still poor client support and it's rather impractical with the current spectrum allocation. For the time being I expect it will mainly be useful in single AP deployments (like in the home lab) and perhaps to make us unpopular with the neighbors 🙂
Queue - Spice Girls
the future is 802.1adthe future is 802.1adthe future is 802.1adthe future is 802.1adthe future is 802.1adthe future is 802.1adthe future is 802.1adthe future is 802.1adthe future is 802.1adthe future is 802.1adthe future is 802.1adthe future is 802.1ad
Got the message manufacturers of WiFi.
Manufacturers of WiFi APs and WiFi enabled devices are:
All joking apart - there are lots of other user groups that have a really strong case for more access to the 5GHz portion of the radio spectrum. Don't fight it switch. One of the benefits is that there is sufficient available spectrum to allow really efficient mesh networks with high bandwidth back haul. Plus it encourages the deployment of many non-interfering, low powered APs, so easier to scale out . . .
802.11ad - you know you want to do it
I'm more excited about the release of 6Ghz spectrum for use with the existing WiFi6 system.
https://www.wi-fi.org/news-events/newsroom/wi-fi-alliance-brings-wi-fi-6-into-6-ghz
By existing you mean brand new APs and clients 😄
It might be time to bring back modular APs again, I feel it is getting really wasteful to chase after the latest wifi specs. Each generation provides meaningful benefits but it also involves throwing away a lot of perfectly good hardware that didn't change.
>involves throwing away a lot of perfectly good hardware that didn't change.
That holds up and retards the new technology.
Sure we could still allow horses on our main state highways, but if we didn't stop all these perfectly good horses it would retard all the newer technology cars.
It doesn't have to be that way. As far as I can see the MR55 and MR56 is literally just a matter of IPQ8078 vs IPQ8078v2.
Having PCIe radio modules might get us a little closer to the concept that you don't have to toss out an entire AP in order to upgrade.
If there's a new species of horse every year or a new car every year that justifies junking all the existing ones, I'm sure we would balk a bit about that.
I'm not saying I'm clutching onto my 802.11b AP, all I'm saying is that the rate of new technology between 802.11ac wave 2, 802.11ax draft, 802.11ax certified, and now Wifi 6e (and then probably .ax wave 2) is getting to the point of being very difficult to justify chasing the standard which makes it worse for everyone in terms of being relegated to APs that don't efficiently use the precious spectrum we have.
>By existing you mean brand new APs and clients
It's hard to say how much of the existing hardware won't be able to use the new spectrum with a software upgrade. A lot of kit uses software-defined radios these days.
The new 6Ghz block is much much bigger than the existing 5Ghz band.
I suspect for WiFi6 5Ghz spectrum will become like the current 2.4Ghz spectrum - no one will want to use it. Everyone will want to jump into the much larger 6Ghz spectrum which can only be used by WiFi6 devices.
No legacy issues. Horses can be left using 5Ghz.
Perhaps I'm being dense but I'm not following how wifi 6e might be all or nothing. I expect the most capable devices will end up being tri-band both on the AP and client side.
I'm not sure why I'd want to buy a wifi enabled device that only speaks Wifi 6e and cannot connect to 5GHz or 2.4GHz...
When all are available, we end up in this situation again where there's a lot of band options and a combination of AP and client knowledge drives roaming and cell selection decisions.
Luckily we live in an era where we know a lot of tools from both sides. APs report QBSS elements to tell clients about their load and the channel utilization they see. APs can supply hints about where neighbors are. Unfortunately for clients (which I have a lot of personal experience developing), some APs do a terrible job of 802.11k reports and report APs that are no longer there or an incomplete list of neighbors.
But at any rate, there's no getting around that adding a third band with its own nuances will make things challenging. Do I connect to a 5GHz AP that's got a really strong RSSI or a moderately weak AP on 6GHz? Even to this day, we don't have a good answer to problems like that. I've got a wifi 5 AP in a bedroom and two Wifi 6 APs elsewhere and I frequently see clients make suboptimal decisions due to this heterogenous network where they could get higher throughput by switching to a different BSSID. But that is a really hard problem to solve and I don't expect it to magically go away.
Ah, I think we are just communicating different aspects of 6GHz vs 5GHz and not disagreeing with each other! This has been a really insightful conversation.
I am curious too when Wifi 6e APs are announced, whether they will end up being tri-band or dual band (as in, whether 6GHz will be handled by an independent radio or just a single 5GHz radio will operate in both modes).
As an aside, technically these Meraki APs all use Qualcomm chips capable of their SON feature where an 8x8:8 radio can be split into two 4x4:4 radios (popularized in the consumer meshing world). I've always wondered why certain vendors have elected not to try out that approach, as I have zero 8SS products and even zero 4SS products, it seems like I might benefit more from the dual 5GHz radio approach for additional frequency domain capacity.
@MerakiDave Hi Dave
It's 2021 - Wifi 6 is pretty much a standard in the market now.
It has such a better speed & stability improvements when handling large amounts of data transfers
WHY is it not on the dashboard yet??
Inside an office where it can be used to help employees transfer large amounts of data to nas unit instead of being chained to cables is such a huge improvement!
Can we do something about it please??
Sorry I'm being so blunt, but this is some serious bad false advertising if Cisco is promoting products for 160Mhz capable devices yet they are not actually enabling users to use it.
Not to mention this is 2 years old+ Topic. WHY????
btw - Just started using MR44 here looks promising, I want to get everyone to work wirelessly as possible, and this seems like a show stopper to me.
Looking forward to hear your thoughts about this.
@AvielC wrote:Just started using MR44 here looks promising, I want to get everyone to work wirelessly as possible, and this seems like a show stopper to me.
I'd rather have happy users accessing the network in a consistent manner without issues caused by events I have little or no control over.
I agree with you completely mate.
Yet having an access point that is capable of doing more (and is advertised as one) yet not allow whoever purchases those AP the ability to test and see if it works well or is causing more issues than it should
(which just means it shouldn't be integrated inside the AP in the first place - but that's a whole different story)
I think it's our right as customers.
a small analogy to it:
purchasing a phone that is said to have 5x optical zoom - but because it may look blurry on the edges the company decided to disable the zoom feature entirely - can you see the equivalent point of view here?
Sorry for the delay in reply, forgot to circle back on this one. Trying not to disagree but this is not false advertising. Meraki has always followed an MVP philosophy and the hardware typically has greater capabilities than what is supported in the firmware at FCS. Many times the additional hardware capacity is leveraged in time, but sometimes not.
The APs are capable of supporting 160MHz channels, it simply wasn't implemented due to lack of demand and it never became practical in typical enterprise deployments. As you pointed out this thread is a couple years old and 160MHz channels (still) have not become a thing in 5GHz. There has never been significant client support for this, and there are too many issues (DFS overlap, etc) that have prevented 160MHz channels from ever being useful or practical for real-world channel plans.
We do all love the idea of 160MHz channels, and with WiFi6E it'll be great in the 6GHz space, but 160MHz in the 5GHz spectrum IMHO was more of a headache than it was worth. And with the limited client support there never was much demand for it and 80MHz channels was basically where the technology topped out (practical perspective, not theoretical of course).
I'm not on the development team but I can imagine there wasn't any reasonable ROI to develop, test and deploy 160MHz on that generation of APs and firmware.
Sorry Dave
I'll be blunt and short as I honstly thing you're avoiding the point here.
If you advertise it supports 160mhz channel but the development team for any reason decided it's not worth testing and worse, deploying that (160mhz existed & was used by me back on LInksys AC3200 - this is double the age of that post if not older) - It wasn't the most stable (home environment I know) but it existed.
Currently on Wifi6 Router at home - using 160Mhz - it just works, coverage, stability and speed (even though its theoretical - it's amazing to see 2.5GBPS wireless speeds! )
So why on earth WHY?? You advertise 160mhz, which is what actually provides those theoretical speeds that are part of the advertisement (AX3000\AX1800) if in actual, no one can reach over 866mbps over wifi????? CAN YOU SEE HOW WRONG IT IS?
I'm sorry, as a customer - this is false advertising mate. you say you're giving us speeds and what not, while actually, "it's more of a headache", Really?? but it wasn't a headache to put it down in the advertisement so everyone will buy it.
Come on Dave. I think customers deserve a better answer, or better yet. a solution.
Thanks.
Why?
I think you need a little context friend, no idea what are you referring to.