[HN Gopher] Wi-Fi Goes Long Range on New WiLo Standard
___________________________________________________________________
Wi-Fi Goes Long Range on New WiLo Standard
Author : thebeardisred
Score : 133 points
Date : 2024-10-06 09:54 UTC (13 hours ago)
(HTM) web link (spectrum.ieee.org)
(TXT) w3m dump (spectrum.ieee.org)
| malfist wrote:
| I'm curious what the speed would be, kinda strange the post
| mentions "mentioning speed" but not what speed is maintained
| nicpottier wrote:
| This looks to be about running LoRa like networks on WiFi
| hardware. Speed on LoRa is not something talked about much as
| it is more like SMS message passing or the like than IP
| networking.
| malfist wrote:
| Probably why it was taking about IoT use. 500 meters for a
| couple hundred baud connection doesn't seem too ground
| breaking. Off the shelf 900mhz radios can easily achieve that
| MostlyStable wrote:
| Yeah, the main draw seemed that you don't need a special
| receiver and that standard networking gear would work,
| but.....LoRa hardware is not very expensive or complicated.
| brookst wrote:
| It's about WiFi to LoRa interop, which is nice but not
| world changing.
| willcipriano wrote:
| For smart home applications this could be big. No longer
| need a hub.
| mschuster91 wrote:
| Most Smart Home stuff is either Zigbee, Bluetooth or
| Wifi.
|
| LoRa stuff is ... hell I can't remember when I've seen
| that stuff outside of monitoring for remote cabins and
| the likes.
| calibas wrote:
| Assuming it's the same as LoRa, up to 50 kbit/s.
| est wrote:
| tl;dr exsisting Wi-Fi devices goes long range with LoRa protocols
|
| The catch: additional power consumption.
| saurik wrote:
| I do not have access to the original paper, but I would want to
| see how this compares to 802.11ah "WiFi HaLow".
|
| (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.
| NewJazz wrote:
| I thought this was a HaLow competitor too... Thanks for
| checking on that.
| toomuchtodo wrote:
| > 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).
|
| 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.
| keeda wrote:
| > (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).
|
| 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.
| walterbell wrote:
| _> most modern baseband chips can effectively be considered
| "software defined radios"_
|
| Is there a comparably-priced SDR that could be used for WiFi
| data transmit/receive with GNUradio?
| keeda wrote:
| I'm not sure what you are asking it should be comparably
| priced to, but USRPs are on the higher end of the cost
| spectrum. Caveat: my experience here is extremely limited,
| but at one point I too was looking into affordable
| GNURadio-compatible SDR hardware that could transmit and
| receive (as opposed to the RTL-SDRs that can only receive)
| and I came across options like HackRF and LimeSDR.
|
| 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.
| stogot wrote:
| Are there mapped communities if SDR folks who I can
| connect with and want to build off-grid networks? I'd be
| interested in pursuing this
| nine_k wrote:
| OK, we have a Wi-Fi device that can talk to a LoRa device at a
| large distance. Now replace the LoRa device with _another_ Wi-
| Fi device that talks the LoRa protocol. If mission is not
| accomplished, what 's missing?
| szundi wrote:
| ... that LoRa is not Wifi, slow as hell and saturates the air
| quickly.
| fidotron wrote:
| You mean the LoRa bandwidth available in a given area is
| surprisingly low?
|
| I've only heard of it, never used it. Not surprised to hear
| it is slow, but I am on the other piece.
| saurik wrote:
| They didn't say they could have a WiFi device receive this.
| altairprime wrote:
| [delayed]
| Szpadel wrote:
| let's assume that this takes off and it will become standard
| addition for our WiFi devices.
|
| 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
| neuroelectron wrote:
| It could be silently adopted to allow longer distance for
| things like map apps that only need a few kilobytes for wifi
| triangulation.
| 486sx33 wrote:
| I live on a pretty standard density street , there are a few
| semi detached homes mixed in. I'd still call it light density.
|
| 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.
| sneak wrote:
| This means something is wrong with one or more of the
| stations on those bands. It's not normal.
| jeroenhd wrote:
| You don't need to watch 1080p TV to report the current
| temperature and humidity, or to receive a command to turn on
| a light bulb.
|
| 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.
| zamadatix wrote:
| People are responding to this with the mindset of watching
| 1080p TV not realizing 1 second of a 1080p Netflix stream will
| use 5x the total daily bandwidth of an IoT device reporting
| temperature once every 10 seconds for the whole day. It's
| entirely different use cases and the impact of congestion
| between the two is like talking about what matters to a garden
| on Mars vs Earth.
|
| 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.
| jessriedel wrote:
| The _overwhelming_ issues with WiFi are
|
| 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.)
| dataflow wrote:
| > It is slow to connect, taking multiple seconds rather than a
| few milliseconds.
|
| What is the reason for this?
| zamadatix wrote:
| For standard Wi-Fi the biggest factors for a fresh
| association are:
|
| - 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.
| londons_explore wrote:
| Discovery could take up to 100 milliseconds.
|
| 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.
| Two4 wrote:
| You've never dealt with enterprise networks where the
| auth server lived on a different continent
| nine_k wrote:
| A different continent is usually a few hundred
| milliseconds away. (The worst delay I had in my life was
| between me in Europe and the target machines in Japan,
| and the round-trip still was about a second.)
|
| The response time of an under-provisioned or poorly
| implemented API endpoint on a machine in the same rack
| can be multiple seconds though :(
| zamadatix wrote:
| While 100 milliseconds (well, slightly more actually -
| 100 time units != 100 ms, it's just very close) is the
| default beacon interval, most clients will scan for
| longer than that to ensure they hear the best SSID (and
| AP for that) before initiating a connection just to throw
| it away/immediately roam anyways. This allows higher
| beacon intervals to work without the clients thrashing
| themselves between advertising stations. Also, not every
| beacon will actually make it through heard so connections
| generally assume they shouldn't just go with the first
| time they hear it.
|
| 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).
| dataflow wrote:
| I feel like those don't explain it though. The most common
| delay people see is when they click Connect on a network
| without external authentication. It easily takes a few
| seconds, but surely that's not all due to DHCP etc.?
| tjoff wrote:
| 1. Can't remember when this had any effect on my use.
| Unreliability wouldn't improve either if you cut the connection
| and reconnected as it would bring down all open connections. No
| thanks.
|
| 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.
| habosa wrote:
| It's been years since you've seen a captive portal? I can't
| remember the last time I saw a WiFi network that didn't have
| a password that also had no captive portal.
|
| I'm pretty sure every airport in the US has captive portal
| WiFi.
| olyjohn wrote:
| I haven't seen one either. But I haven't needed to connect
| to a public WiFi point in years. That might be the
| difference. Usually where there is public WiFi I can just
| tether on my own phone.
| Marsymars wrote:
| I expect their point, which jives with my experience, is
| that cell coverage is now good enough that there's no need
| to connect to random wifi networks where you have to deal
| with their portals and contend with worse performance than
| your cell connection.
| johnnyanmac wrote:
| I can't even get "5g" in my own house. I had to order a
| signal strengthener (fortunately for no extra cost)...
| That connects to my wifi. And the speeds make me wonder
| if we really came that much farther from 3G.
|
| 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.
| nine_k wrote:
| I have an unlimited 5G plan in the US, works like a
| charm, etc. But once I cross an ocean, the connectivity
| is suddenly very limited, and mobile data is expensive.
| So, until I buy a local SIM card, or maybe for a few
| hours of a layover in an airport, is where airport Wi-Fi
| may be _really_ helpful.
| jayd16 wrote:
| Doesn't the cell antenna use significantly more power
| than WiFi?
| wongarsu wrote:
| In the US signal strengtheners seem to be common in
| public buildings. But in Europe it's common for big
| buildings (think convention centers, large multi-story
| shops, etc) to offer free wifi but have bad cell signal
| on the inside.
|
| 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.
| jltsiren wrote:
| And in some countries, mobile data is cheap and available
| almost everywhere. Many people don't connect their phones
| to a WiFi in their daily life. Which may then become a
| huge security issue, as the phone may not download
| software updates on mobile data with default settings,
| under the false assumption that mobile data is expensive.
| sneak wrote:
| It (almost always) lacks forward secrecy or, indeed, any
| encryption at all when using unauthenticated networks.
|
| 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.
| tzs wrote:
| > 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.
|
| 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?
| jessriedel wrote:
| You can re-phrase my main question as: why is there enough
| interest in doing these minor improvements when there is
| apparently little interest in fixing the major and long-
| lasting deficiencies?
| 14 wrote:
| I think what you call minor improvements would be
| considered significant to others who may benefit from it.
| MerManMaid wrote:
| In the context of this thread, IEEE aren't the ones who can
| improve such things. WiFi 6E and WiFi 7 both make
| considerable improvements on connect time but at the end of
| the day, they deal with the "backend" if you will.
|
| They have no control over crappy WiFi NIC cards that delay
| connections or how Apple displays captive portals.
| nine_k wrote:
| 1. Wi-Fi is of course capable of reconnecting fast, so you
| don't even notice it. When you see a multiple seconds worth of
| a connectivity gap, it's likely not because Wi-Fi is stupidly
| waiting. Most probably it's radio interference, or the access
| point can be overloaded and have not enough resources to
| service all the connections, so it drops some.
|
| 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.
| ajb wrote:
| Or it can be multiple access points on the same SSID without
| 802.11r set up properly
| jessriedel wrote:
| 1. When I have looked into this, it turns out the basic WiFi
| standard has rules about polling rate (allegedly to save
| power). Like, the standard is literally something like "poll
| for a few hundred microseconds every couple seconds".
| Macbooks even have special workarounds that decrease the
| connection time by ~half by mildly abusing the standard.
| azernik wrote:
| 2 is rather irrelevant to the intended use case: devices
| connecting to a network with pre-shared credentials. Think cash
| registers and crop humidity sensors connecting to the internet,
| not cafe wifi.
|
| 1 is kind of unavoidable if you want a massively shared medium,
| mildly reliable connections once set up, and decent throughput.
| jessriedel wrote:
| 1 is not unavoidable. I've never gotten a clear answer on the
| explanation, but the most reasonable ones involve power-
| saving and frequency-saving strategies (only poll for new
| connections for a few hundred microseconds per second). And I
| think these are eminently solvable.
|
| 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 "?
| brcmthrowaway wrote:
| Isnt there already 802.11ah?
| altairprime wrote:
| LoRaWAN (has no 802 spec) and Wi-Fi HaLow (802.11ah) both share
| a target market, but use different underlying protocols. This
| isn't meant to be "we have created a new standard" or "we
| prefer one or the other standard", this is simply "holy crap,
| we figured out how to make an 802.11g radio emit LoRaWAN
| packets?! and no one has ever written a paper about doing that
| before!".
| londons_explore wrote:
| I just want speed to degrade gracefully down to 1 kbps or even
| 100bps. Ie I should be able to be 1 mile from my house, but still
| be imessaging over my home wifi.
|
| 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!
| abracadaniel wrote:
| That's my dream network. A long range, low bandwidth,
| decentralized network. Mesh would be cool, but even just being
| able to exchange with neighbors at the scale of 1-10mi would be
| amazing.
| sneak wrote:
| It would be illegal (at least in the usa); you're not allowed
| to share your home internet, or function as a public utility.
|
| 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.
| johnnyanmac wrote:
| Well that would explain the sad estate of government
| sanctioned Wifi. They were bought out, as usual, from
| people who just want an extra buck instead of properly
| serving the public's needs.
| wilted-iris wrote:
| Citation? There are a few large public meshes in the US.
| I'm unaware of anything that makes them illegal to run.
| franek wrote:
| This sounds like what RNode devices for Reticulum networks
| appear to be able to do. (I haven't tried it for myself yet.)
|
| > 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.
|
| ( https://reticulum.network/ )
| altairprime wrote:
| WiFi 7 _finally_ extends wi-fi clients to be capable of bonding
| multiple radios together into a coherent link. This is critical
| to being able to bond in longer-range, lower-bandwidth channels
| _in the future_ , and I'm certain they are considering how they
| can bring all of the 802.11 wireless specifications under one
| umbrella.
|
| 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.
| sneak wrote:
| Isn't LoRa patented and proprietary?
| altairprime wrote:
| https://www.cs.wustl.edu/~jain/cse574-16/ftp/j_14ahl4.pdf is a
| good overview of the technical differences between WiFi HaLow
| (802.11ah) and LoRaWAN.
|
| 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.
| dzhiurgis wrote:
| Baffles me Starlink terminals don't ship with lora and halow.
| Maybe too soon, but obvious improvement for remote farms, etc.
| Eric_WVGG wrote:
| My god, who came up with this name?? "Wi-Lo" sounds like "LOW
| range"
| malfist wrote:
| And if you google it, google assumes you're searching for
| willow
| lloydatkinson wrote:
| > smart cities
|
| Still at it, huh?
| Tor3 wrote:
| Did I understand the article correctly in that they simply
| managed to reach 500 meters with wi-fi? If so, I don't see what
| they have actually achieved. In the early days of 802.11b I
| regularly connected my wifi-enabled (via dongle) Palm PDA to open
| networks that were sometimes hundreds of meters away, and the
| airport free wifi I could use from 1.5km away (at least - it
| could be longer, it's just that the place I frequented was that
| far away). The usable distance started to shrink drastically as
| the airways got more crowded, and as soon as you could see tens
| of networks at the time then suddenly the cafeteria network was
| only usable from inside whereas before you could use it a couple
| hundred meters away, across the large square.
|
| Of course, if it's about managing that in a crowded network
| space.. but the article was extremely short on details.
| altairprime wrote:
| No. They reached 500 meters with LoRaWAN (no 802 spec), using
| an 802.11g (WiFi 3) radio.
___________________________________________________________________
(page generated 2024-10-06 23:00 UTC)