Hacker News new | comments | ask | show | jobs | submit login

Here is the actual study - it is an interesting read: http://apps.fcc.gov/ecfs/document/view?id=60001078145

In a nutshell; the LTE transmission cycles on and off on a regular cadence without sensing if the channel is clear. This tramples over the 802.11 frames and results in higher utilization of the medium than that which is claimed by Qualcomm

Well the good news is that LTE-U appears to be for the 5 GHz band, not 2.4 GHz. You would think that it would be easier to put micro cells in the home gateways (using the bands they already own) vs. rolling out a new capabilities on the 5 GHz band in the client (I mean won't they have to wait for Apple/Android to switch to a new generation of chips?).

I guess the bad feeling is that the unlicensed bands would be used for a subscription service, whereas WiFi is controlled by the consumer (though in practice each ISP ends up using WiFi).

> Well the good news is that LTE-U appears to be for the 5 GHz band

I worry that it could make the 5G band look like 2.4G looks now. I too like the idea of a piece of spectrum used mainly by consumers or small businesses and not saturated by the big commercial gorillas. If today they are desperate enough to consider running their precious services on the wild unregulated bands then sooner or later they will be desperate enough to squeeze every last bit out of them.

Another thing is that once they are allowed in and their bottom line starts to depend on WiFi bands, they will fight to the death to stay there forever and only grow.

Where I live we have 2 WISPs - the 5GHz band already looks like the 2.4 band. This would potentially just wreck internet service for thousands of people.

Are the WISPs attaching WiFi APs to (or near) their antennas to provide service to the surrounding area?

If they aren't, then -AIUI- 5GHz (and 40GHz) gear commonly used by WISPs is highly directional and requires somewhat careful alignment in order to work. (I've heard the term "pencil beam" thrown around to describe the antenna pattern.)

The latest Wi-Fi standard 802.11ac, which has been shipping for the past 2 years, already works only in the 5GHz band. There has been a push for Wi-Fi to work in the 5GHz band ever since the 802.11n years with the "dual-band" routers, mainly because the 2.4GHz band was getting too crowded/routers were interfering with each other through walls too easily.

Well, some of us live in homes with rooms and walls, and so 5GHz is pretty useless.

...5 GHz WiFi is more than capable of going through walls. In fact, 802.11ac has significant improvements to multipath rejection, meaning it should perform better in environments with many reflections than the protocols that offer 2.4GHz operation.

Which is not to say you may not have had a bad experience with 5 GHz routers/access points -- there are plenty of commercial APs that are frankly terribly designed.

Thanks. Maybe I'll give 5GHz another try.

More capable than 2.4GHz? It's not so much about reflections, but going through solid objects. I imagined the larger wavelength of 2.4GHz dissipates less when travelling through solid objects, but this is hardly scientific. I also read stuff from internet searches that seemed to confirm this, but I don't remember nor have a link to a scientific explanation.

If you look up actual measurements of 2.4GHz vs 5GHz penetration through common household materials, it's clear that it makes far less difference than the conventional wisdom seems to indicate. I think a lot of it comes down to two major factors: pre-802.11ac devices being designed to prioritize 2.4GHz antenna performance over 5GHz, and people having their networks arranged to account for where the dead spots are on the 2.4GHz band and acting as though they should be in the same places for the 5GHz band.

Precisely. The big problem with 5GHz's reputation is that most access points, by default, pick channels where only low power is allowed. Lower power than 2.4GHz == lower range than 2.4GHz.

Although I believe all channels are high-power channels now (as of late last year or early this year?), switching to one of the old high-power-allowed channels can help. 149 is recommended.

I have yet to see any scientific paper that says 5GHz penetrates structural elements worse than 2.4GHz. Rain, yes. Walls, no.

> Although I believe all channels are high-power channels now...

If they are, my Linux systems aren't yet aware of the change.

They make the claim that the only ranges with a 30dBm transmit power are 2402 - 2472MHz and 5735 - 5835MHz. All other WiFi bands are 23dBm. (Though it does seem like the transmit power in the 5.49 - 5.73 GHz range got increased from 17 to 23dBm somewhat recently.)

> I have yet to see any scientific paper that says 5GHz penetrates structural elements worse than 2.4GHz.

I can't point you to any studies, but -anecdotally- I've found that (at the same transmit power, and all other things being equal) a 5GHz link provides a lower SNR than a 2.4GHz link. Before I switched to an AP with better antenna and radio, I found that I would not-infrequently permanently lose the 5GHz connection in my bathroom [0][1], but the 2.4GHz connection could be reliably established in the bathroom and remained solid.

Even after I've switched APs, I get a substantially better signal [2] from the 2.4GHz connection than the 5GHz one.

[0] My bathroom is tile covered, filled with pipes, and the furthest point in the apartment from my AP.

[1] "Permanently" as in "once I left the bathroom I could reestablish the 5GHz connection".

[2] Obviously, a better signal doesn't guarantee a faster connection. At my site, 2.4GHz is so overcrowded as to be nearly useless.

Regarding footnote [2], this is where 5GHz really helps. With 80MHz channels, you'll be using 1/4 the airtime to send the same amount of data.

2.4GHz is to be avoided if at all possible.

Also, measuring SNR is interesting, but you should really run a speed test of some sort. A team I work with wrote this to let access points speedtest clients without any code on the client:


(Only really tested with ath9k and ath10k. Could possibly work with other chips.)

Of course, there are many variables on translating link quality to actual throughput. Rate control algorithms are essential, and often wrong. For example, consider sending at 10x the speed and losing 2x the data. Most rate control algorithms will avoid that scenario, even though it's actually faster and conserves valuable airtime.

This is good reading on that subject: https://wireless.wiki.kernel.org/en/developers/documentation...

> Also, measuring SNR is interesting, but you should really run a speed test of some sort.

No doubt. Next time I find myself in something similar to my apartment, but in the middle of nowhere so's the three or four-dozen 2.4GHz APs that surround me don't confound the results, I'll do just that. :)

FWIW, the SNR measurements were taken with a UBNT SR-71E (802.11agn ath9k-driven) client that Linux reports as an AR928X.

I'll make a note to look at that wifiblaster program later this week. That could be pretty useful. Unrelated to that, how's the ath10k driver looking? Does it work most of the time for most supported cards these days, or does it still come with a boatload of caveats?

I think the open source ath10k driver is in a pretty good state. We're using it for the Google Fiber routers, and it's working pretty well. OnHub is also using ath10k.

That said, now that the drivers are working, it's old technology. 4x4ac is all the rage now, and ath10k is 3x3.

Some of us live in apartment complexes where a lot of APs are broadcasting in a small area, and the 3 non-overlapping channels in 2.4ghz are pretty limiting.

considering 2.4ghz is basically unusable where i live this isn't really good news.


My understanding is, just bad news: not only the LTE-U as it is now interferes with WiFi, it would also cause any phone connected to the WiFi to drain the battery faster, according to the papers.

It surely should not be allowed until it's significantly improved.

How is that good news?

Your link doesn't work by the way.

It didn't work for me either. Maybe it times out? This works, at least for now: https://webcache.googleusercontent.com/search?strip=1&q=cach...

works fine here?

Yeah weird, works for me too. Here is it on Slideshare though too: http://www.slideshare.net/zahidtg/15-105-06112015-google-inc...

I get "The requested object does not exist on this server."

not here :(

I think the worst thing are the 802.11 frame errors that results.

Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact