Wi-Fi Goes Long Range on New WiLo Standard
spectrum.ieee.org
spectrum.ieee.org
(edit) OK, I got a copy from ResearchGate, and I misunderstood! I had failed to grok the part of the article where LoRa is now supported by the sx128x (as opposed to the sx126x) on 2.4GHz.
https://www.researchgate.net/publication/383692369_WiLo_Long...
> In this article, we introduce a new algorithmic framework called WiLo, designed to enable directional communication from Wi-Fi to LoRa, which employs signal emulation techniques to enable off-the-shelf Wi-Fi hardware to produce a valid 2.4 GHz LoRa waveform.
So, critically, and as far as I can tell this isn't in the summary article, this is purely unidirectional; and so, this isn't about being able to build a network that upgrades the range of WiFi with some tradeoffs: this is about being able to send data from existing WiFi hardware to existing LoRa hardware using a relatively minimal set of changes (though I still don't appreciate how this would practically be done to the existing hardware, and they apparently only simulated this with software-defined radio).
> The core innovation of WiLo lies in the signal emulation technique used to generate a valid 2.4 GHz LoRa waveform. Through sophisticated signal processing algorithms, WiLo transforms the standard Wi-Fi signals into LoRa-like wave-forms, while ensuring compliance with the LoRa modulation specifications. This enables the LoRa hardware to decode WiFi signals without requiring any modifications to the hardware itself. The emulation of LoRa waveforms is achieved by carefully manipulating the parameters of the Wi-Fi signals, such as the modulation index, spreading factor, and BW, to closely match the characteristics of LoRa modulation.
> We would like to emphasize that WiLo is directly supported among commodity devices, and the USRP-B210 devices are used only for evaluation purposes to measure low-level PHY information, which is inaccessible by commodity devices. For example, a commodity Wi-Fi card such as the Atheros AR2425 can replace USRP-B210 devices as the sender.
This leads me to believe you could flip a switch and turn entire swaths of access points into a broadcast fabric for LoRa? Wifi networks meet software defined radio a bit.
It is my understanding that most modern baseband chips can effectively be considered "software defined radios", as most of the modulation/demodulation is performed by the firmware. While the researchers appear to have used a USRP (a dedicated SDR platform), it is conceivable their scheme could be accommodated in the firmware.
Is there a comparably-priced SDR that could be used for WiFi data transmit/receive with GNUradio?
However, knowledgeable people also pointed out that these cheaper options make tradeoffs in the RF hardware that make it harder to get reliable performance for non-trivial uses. Their opinion was that the time saved in working around those limitations was well worth the extra cost of a USRP.
It's possible with an FPGA-based software-defined radio though: https://github.com/open-sdr/openwifi
I've only heard of it, never used it. Not surprised to hear it is slow, but I am on the other piece.
It doesn't mean that this should be used, or should be the standard, but it absolutely does mean that this is possible to do within the terms of the 802.11g radio protocol spec, which no one had really realized and done the heavy lifting to demonstrate yet.
Physics lets me do that with no additional transmit power (shannon's channel capacity formula, combined with signal power dropping off as a function of distance squared).
If suitable modulation was chosen (ie. some kind of CDMA), then a setup which can give 100 Mbit at 100 yards should be able to do 322 kbits at 1 mile, and 3kbps at 10 miles!
There are huge regulatory moats around everything that costs $20-500/mo recurring and is incurred by large percentages of the population. Internet access is a huge one.
> RNodes can be made in many different configurations, and can use many different radio bands, but they will generally operate in the 433 MHz, 868 MHz, 915 MHZ and 2.4 GHz bands. They will usually offer configurable on-air data speeds between just a few hundred bits per second, up to a couple of megabits per second.
> [...]
> While speeds are lower than WiFi, typical communication ranges are many times higher. Several kilometers can be acheived with usable bitrates, even in urban areas, and over 100 kilometers can be achieved in line-of-sight conditions.
( https://unsigned.io/rnode/ )
> Reticulum is the cryptography-based networking stack for building local and wide-area networks with readily available hardware. Reticulum can continue to operate even in adverse conditions with very high latency and extremely low bandwidth.
However, this will also expose issues with encapsulation of "the connection", which can now vary exponentially in capacity. Operating systems and applications are coded to be 'carrier frequency agnostic', without any capability for a given connection to switch from "low data mode" (avoid unnecessary transmissions) to "high data mode" (do whatever you like), much less to "extremely low data mode" (i.e. push notifications and foreground app only) or to "extremely high data mode" (i.e. 4k / 240fps over 60GHz); all on a single dynamically-adjusting connection.
Cellular fakes this today by saying "5G high data permitted?" but not being able to downgrade OS and app behaviors gracefully when the 5G connection is hella weak or overloaded, i.e. not fetching mail or not autoplaying movies or etc.
You have to be close to a router the first time to connect to it.
And after that you both have some long (ie. 65536 bit) random key which is used as a modulation code for your transmissions.
The receiver demodulates with the key to get the data out. Different key can get different data out of the same airwaves at the same time.
Clock's need to be synced perfectly, which is in itself a big technical challenge.
As the article slides to, low power signal reception is also challenging.
> a setup which can give 100 Mbit at 100 yards should be able to do 322 kbits at 1 mile, and 3kbps at 10 miles!
That's not how noise floor works
Current stuff like LoRa works because there's not many users and the protocols are optimized, but if everyone was iMessaging we'd probably need more spectrum.
We can already do WiFi for miles with narrow beam antennas, we could make mesh network tech cheap if it was standardized and mass produced.
This could be used to implement bridges between LANs located at great distances one from the other. There were commercial products implementing such LAN bridges through WiFi.
When an access point must transmit and receive omni-directionally, to reach any station placed randomly around it, that diminishes a lot the achievable range.
Of course, if it's about managing that in a crowded network space.. but the article was extremely short on details.
Given big range of this technology, how this handle air congestion when we would have hundreds maybe thousands of devices in range?
I expect low througput of this technology and for IoT that's usually fine, but when we need to share this spectrum with lot of devices we might quickly make this non operational. And this is even assuming we do not have some devices that request much more bandwidth that others.
Wirh WiFi 2.4ghz we already struggle with air congestion and quick Google shows that lora have 13 + 8 channels and if I understand it correctly some of them are used explicitly for joining network (?)
I think this technology is really cool only if it won't get much popularity
I have 2 x 5ghz channels, 2 x 2.4 ghz channels, and then a repeater with another 2 and 2
In the evening there is so much congestion on every available channel on either band that I can’t watch 1080p tv
This long range thing sounds awful.
As for channel congestion, check if your WiFi repeater is in mesh mode or not. If not, it literally halves the throughput on your WiFi network, that seems to be already over-congested by whatever is messing with your channel settings. Based on your description of the area, if your 5GHz somehow ran out of space, something seriously weird is going on. Maybe some non-WiFi-device is using the 2.4/5.2GHz band to transmit data? I know stories of cheapo baby monitors wiping out entire neighbourhoods, for instance.
I can only assume that they sell "super-duper routers with greater bandwidth" where they make the box look like a spaceship and actually enable a useful channel selection algorithm? Is there an actually good reason for the channel selection being awful?
The only one I can think of, based on my experience back in the day, is to prevent people from picking 2.4GHz channels that aren't 1/6/11. Modern routers often come with visualisations to show why this is a bad idea, but I've seen plenty of cases where people went "wow, these 1/6/11 channels are super crowded, I'll just use channel 3 because nobody else is using that" and making the situation much worse by now overlapping and interfering with two common channels instead of just one.
Part of the spec also mandates that for wide 802.11n channels, you can't just force yourself into using a wide spectrum when there's not much spectrum to go around. On the 5.2+GHz band there are also legal restrictions (such as DFS, to not interfere with radars, and sometimes transmission power limits on specific subsections of the band).
Some larger corporate WiFi installations will automatically adjust channels across many access points to optimise coverage and minimise interference. Perhaps ISP APs will do something similar, as ISPs have a somewhat accurate map of what frequencies are used in a geographical area. That seems rather overbearing to me, though.
I still can't think of a reason to not let users pick one of the "good" bands themselves. Some kind of automatic frequency selection is a solid default, but I don't see why users shouldn't get the freedom to override that default.
The big limitation I see here, and where Wi-Fi has historically failed even with 802.11ah specifically built for the IoT use case and standardized back in 2015, is the "uses extra power" bit. Other protocols like LoRa are designed around minimizing power at the end stations. At the end of the day that's often a bigger deal than bandwidth for long IoT.
Don't have a Netflix file to test with but YT, the video data is 73KiB for the first second (tested by ffmpeg'ing the first second into a new file with codecs set to 'copy'). The page, however, seems to fetch about 9 megabytes in the first second of loading (various features still loading such as comments).
Reporting temperature, let's say it's super secure with IV and MAC headers and trailers and another nonce for replay protection (all in all 3x 32 bytes) plus the actual value and other metadata (like which device the report is from) of, say, another 32 bytes, plus IPv6 headers etc. is a couple hundred bytes. Call it 256. There are a gross ten minutes in a day, coming to 144×256 = 36 KiB.
Huh, that's pretty accurate when considering video data ("any second" rather than the first second specifically that needs to include the page weight). I had expected the video data to be vastly bigger compared to that sensor reporting just one value per ten minutes. That keyframe+video compression is really quite something; raw 24-bit would be 6 MiB rather than 73 KiB
Netflix actually gives the value of 3 GB/hour directly for high definition content https://help.netflix.com/en/node/87 which is ~833 KB in one second (or about an average 6 mbps plus some delivery overhead) which simplifies things quite a bit though.
Encryption is an interesting thought in that LoRaWAN will have encryption built in and the device would typically expect the gateway to handle producing that to IPv6 with traditional encryption and application headers. CTR is used so the packets don't gain much bloat, the minimum size is ~bytes and the maximum size is ~256 bytes. Temperature reports (4 byte float) typically fit in that 50 byte minimal packet category or 432 KB/day reporting every 10 seconds. So I suppose my estimate of 5x was a bit high after all, maybe 1-2x would have been more apt :). But it does beg the question, back to your point, what would that look like in this WiLo protocol? Standard Wi-Fi has a minimum frame size in the air is going to be closer to 100 bytes (minimum Ethernet length of 64 plus Wi-Fi bits). On top of that Wi-Fi doesn't usually act as the gateway like LoRa - does the IoT device now need to package everything in IPv6 + transport security itself and send it over the air with WiLo or is the expectation APs would be more gateway like for these clients? Dunno, wasn't able to read the actual paper in the link to see what is proposed :).
LoRa stuff is ... hell I can't remember when I've seen that stuff outside of monitoring for remote cabins and the likes.
The specs are open: https://resources.lora-alliance.org/technical-specifications
The Lora Alliance publishes their patent policy here: https://lora-alliance.org/wp-content/uploads/2021/01/LA-IPR-...
I encourage reviewing "7.4 LoRaWAN 1.0 Copyright License to Implementers", which appears responsive to your question.
A patent license is a horse of a different color. 7.4 explicitly denies that it serves as a patent license:
> This license shall not be deemed to grant any right under any patent, patent applications or similar intellectual property right.
Just because the specs are open it does not permit you to manufacture or sell the devices without a patent license.
Still at it, huh?
1. It is slow to connect, taking multiple seconds rather than a few milliseconds. (Wifi unreliability would have much less practical impact if there was rapid reconnect.)
2. The lack of a sufficiently flexible standard interface for logging in and accepting terms, leading to the terrible captive portal workaround.
I cannot for the life of me understand why the standards committee cares much about various other minor improvements when these issues are still unsolved after two decades. (Similar complaints can be made about Bluetooth.)
What is the reason for this?
- Discovery. You have to wait to see which saved networks are broadcasting. Broadcasting more often = less efficient airspace for already attached clients. Broadcasting less often = longer delay for clients to "see" the network when they start listening.
- External authentication. E.g. if you're doing RADIUS auth or MAC auth with an external database instead of a PSK exchange there is extra time in setting up this exchange and then waiting for the external authenticator to validate it.
- DHCP / NDP. Wi-Fi assumes you more or less want to emulate a standard Ethernet + IP session but over this new fangled air connection. This is an additional delay for an additional exchange with the services responsible for this. Typical clients e.g. Windows will also perform extra address duplication checks slowing things further.
There are some extensions in more modern Wi-Fi standards for clients that want to "sleep" for long periods, immediately do some stuff, then sleep for long periods (like IoT). Particularly TWT (target wait time). These, and more, are already found in purpose built protocols like LoRa/LoRaWAN though.
All the others, if properly implemented, are speed-of-light things. Eg. RADIUS auth to an external database on the same physical site should easily be doable within 1 millisecond. It's not like that database has a multi-second queue of other users to connect first.
The response time of an under-provisioned or poorly implemented API endpoint on a machine in the same rack can be multiple seconds though :(
As for how a RADIUS auth should take 1 ms... sure, and updating macOS on an M3 shouldn't take an hour either. I'm not saying how tech should be, I'm saying how it is and which steps often add significant latency as implemented. Even a dedicated Aruba ClearPass authentication server on prem scaled for 25k clients can't handle 1,000 auths/second (ignoring that AD would fall over before then).
Usually the drivers are also part of the problem (both on the AP and the client). Same with OS software around it. Things that should be instant just aren't. E.g. go try to disconnect and reconnect to the same SSID on macOS via the GUI. If you do that in ~1 second you should get an error - not a delay, an error that it hadn't synced up with its own connection state and couldn't possibly figure out how to try to connect. None of that is actually Wi-Fi, if you implement an IoT device with an embedded radio and sidestep a lot of those layers suddenly the protocol is much quicker to connect (still not as fast as some simpler ones though).
2. Been years since I've seen one of those. The use-case is pretty much being abroad or in a really remote area with bad cell reception. And even in those cases it seems those captive portals are going out of fashion.
All in all, so far down the list that I probably wouldn't think of them even if I tried.
I’m pretty sure every airport in the US has captive portal WiFi.
The US mobile infrastructure is an absolute sham, even in the outskirts of a large city. I can only imagine how some entire states fare.
Additionally mobile data tends to be expensive, so lots of people in the lower half of the income spectrum will go with a smaller data plan and use free wifi at every opportunity. Which encourages places to offer it to get those people as customers.
These are much bigger problems.
The fact that they haven’t been fixed is so glaring that one can attribute it to enemy action, not carelessness.
It's different people.
WiFi is a pretty wide field. There are plenty of people whose interests and/or qualifications only extend to part of it. Should they just sit around twiddling their thumbs if the parts they can contribute to aren't the parts with the biggest issues?
They have no control over crappy WiFi NIC cards that delay connections or how Apple displays captive portals.
Why are people working on improvements to wi-fi at all, when there are people around the world dying of hunger?
If you can answer that, I think you'll be able to answer your own question.
2. Wi-Fi is a transport layer; equally TCP and even HTTP do not offer a generic mechanism for logging in and accepting terms. This needs to be addressed at a different level, but I totally agree, it would be great to have a reasonable standard that's open and is better than a captive portal.
1 is kind of unavoidable if you want a massively shared medium, mildly reliable connections once set up, and decent throughput.
On 2, my question isn’t “why haven’t they fixed #2 for this use case?” it’s “where does the effort to address this relatively small use case come from while #2 remains unaddressed “?
And it is possible for the vast array of computer scientists in the world to work on more than one thing at a time; this particular work was done by a small team, whose specialties are in any case not suitable for work on better open authentication/consent protocols.
The catch: additional power consumption.