How to run a city-wide wireless network from a drawer
thingsquare.com
thingsquare.com
https://futureprepping.com/mobile-phone-mesh-networks/
The radio dongles are superfluous and I can't think of any engineering reason why all cell phones can't just communicate with others nearby already. Maybe not for cellular voice and data, but certainly for something akin to AppleTalk back in the 80s:
https://en.wikipedia.org/wiki/AppleTalk
When I got to college in 1995, all of the Macs were on the campus-wide LAN and lots of Mac users had their public folders shared. There were tons of apps and games and even little personal BBS-style areas where people posted stories and you could share files to their drop box. It was all free and open and frictionless and stands out vividly in my mind as a vision of what we thought the internet was going to be.
If we had that, it would be trivial to run something like IPFS to bypass the ISPs, even without paid cellular service. Then anyone could connect through their tunnel provider of choice and bypass any privacy concerns. The speed would be proportional to the number of nodes, so many thousands of times faster than internet today is, or ever can be.
With the debates around net neutrality and the cost of streaming, it's like we've forgotten that the only cost of the internet could be the electricity required to run a cell phone.
And it’s not so much the power that it requires but that the extremely low energy density of lithium batteries means we have to minimize power usage as much as possible.
If you were relaying a lot of traffic for approved peers, then sure you are going to have a higher power profile. However, if you are doing this on an ongoing basis you are probably not battery-constrained (eg. you are connected to a larger power supply such as a vehicle, etc.) and you are potentially talking lower signal strength and closer peers. So it's really an application-specific concern.
For instance, the popular ESP8266 chip uses roughly 1mA in sleep mode, 15mA when the CPU is awake but the radio is off, 50mA when receiving, and 100-200mA when transmitting.
Nordic Semi's comparable nRF52810 uses less power, but follows a similar pattern: <1mA sleeping, 2mA with CPU active, 6mA receiving, 8mA transmitting.
So if you tell the radio hardware to discard packets that aren't addressed to you, you may be able to save a small amount of power by avoiding unnecessary CPU activity, but you will still be using dramatically more power than a non-mesh network in which your node could go to sleep when not in use.
In order to have any chance of getting reasonable battery life from a small mobile device, you need a protocol that establishes short time slots for devices to wake up and find out if they have any incoming data, so that they can spend as much time as possible with their radios turned off. This is difficult to achieve in a decentralized mesh.
Also, relatively speaking, modern wireless transfer rates are very fast and therefore transmissions will only be sporadic, and 200mA is not a lot of power. Ignoring other factors, napkin says you would have to hold 200mA consumption solidly for 15 hours to deplete a modern smartphone's 3000mAh battery. Most mobile mesh networking use cases will have long since concluded by that point.
According to a 2017 PhD dissertation[0] on a sample device cellular eats way more than wifi in the normal idle mode (p56). Therefore, if we ditch cellular there may actually be power budget savings when idle. However, all radio communications are totally dwarfed by display power (p58, p67, p72), especially at high brightness levels (p59).
[0] https://trustworthy.systems/publications/papers/Carroll%3Aph...
In wifi, this is handled by the base station if I'm correct. It assigns slots for the associated receivers. Assigning slots in a mesh network without coordination is effectively a graph coloring problem and difficult to solve.
My professor for my master thesis was the author of LMAC, which attempted to assign slots to each node. It worked great in theory, but not so much in practice.
To take up the tangent, it seems to me that the graph coloring problem can either be (1) solved universally (any local mesh will have distinct boundaries which make absolute coordination feasible) by adding some sort of explicitly negotiated or progressively developed shared state to act as a coordination layer (2) solved temporarily, for example by implementing a best-effort failover/fallback (CSMA/CD feeds back to "color") (3) Ignored.
Solution class 1 is obviously challenging to apply to for mobile and ad-hoc mesh networks. Solution class 2 seems more realistic for this category of use case. Solution class 3 works well if you have full control of the application layer (eg. wireless sensor network is push-only with short packets with high temporal tolerance for retransmissions).
Feels a bit like "Energy optimization / throughput / ad-hoc topology / traffic generality. Choose any three."
Google is not willing to allow ad-hoc wifi (at least last time I checked).
If you try to ban the future, it will just happen elsewhere. - Paul Graham (2017)
1) Filesharing went from “harmless, only a few geeks do it” to “theft on a level that will put ‘us’ out of business”
1a) Media companies and device makers merged which means that device makers are now beholden to the copyright regime. Previously they argued “we just make tools, we can’t be responsible for how people use them” but we’ve lost those allies.
2) Openly sharing folders by default was great when everyone knew what they were doing, but the public now recognizes that there are real consequences when people don’t know what they are doing. From being “exposed as an imposer” (harmless and common imposter syndrome) to all manner of life/death consequences. It’s a whole different landscape.
3) No protocol is secure forever. Having all devices communicate with each other means that it’s only a matter of (usually a short) time before people can view other people’s personal information, and that leads right to point 2.
4) Similar to point 1, service providers have deals with device manufacturers and those providers don’t want people to be able to bypass them. They even write terms of service that say you’re not allowed to share with your neighbours so that even in the densest cities they can charge all 500 households that are within wifi range of each other though that creates a worse experience as the signals clobber each other.
A city-sized IPv6 mesh network built out of handheld-sized devices was science fiction 25 years ago. Metricom's Ricochet showed it was possible, without the IPv6, about 23 years ago. And after decades of resistance and sandbagging from regulators, Thingsquare is finally making it happen in real life.
"Mining HNT with Hotspots is done via radio technology, not expensive or wasteful GPUs. … Hotspots work together to form a new global wireless network and undertake ‘Proof-of-Coverage’."
"Tokens & Data Credits: The network uses two units of exchange: HNT, a new cryptocurrency, and Data Credits. Proof-of-Coverage: Our novel proof-of-work algorithm enables Hotspots to be rewarded trustlessly. Helium LongFi: LongFi combines the low-power, long-range LoRaWAN wireless protocol with the Helium Blockchain."
I get the impression is it's to create a cryptocurrency motivation for providing good network coverage. I don't get how it works but assume, like all things involving blockchain, there are externalities or unintended effects that make it not a good solution.
Helium is the quintessential example of Blockchain doing obvious social good when all traditional means of accomplishing the same goal had failed.
I've not really dug into the details as to what solutions Helium has, but it is quite interesting to see how this experiment will play out.
A much more realistic risk is sudden insolvency of a specific vendor (who are also responsible for maintaining firmware). There are about 30 approved vendors, growing monthly, but some have a larger share of the mining pool than others. The community is anticipating long term business risks and devising mechanisms to prevent a sudden loss of a large percentage of nodes due to business risk.
I firmly believe there is a significant flywheel developing here and I recently left my FAANG job to build in this ecosystem.
I was disappointed to see that the network seems intended for transmitting very small amounts of data. For example, by my messing around with their calculator, transmitting a gigabyte of information would cost ~400 dollars.
The network gets global utilization processing about 40M packets a day. Not big in terms of dollar $ yet, but people are indeed using it. Definitely nobody is suggesting you watch YouTube or even send emails with it.
Do you have a source for the 40m packets number? Does that include the packets that the miners send to each other for proof of coverage?
I'm having trouble imagining the uses for an expensive, slow, unreliable, bespoke network that's limited to the areas with helium miners nearby. If you have an example of someone using this I'd love to read more.
You can measure this yourself at etl.dewi.org
The idea is that if you are designing and selling a product, say, a dog collar, you can build Helium(*) capabilities into your product by including a LoRa chip in it. Your customers can then use the Helium(*) network to communicate with the dog collar, for example to locate a missing dog. The fees for this service then flows to the people that have deployed the base stations that facilitate this communication.
To me, this seems like a great way both to build an access network and to get people invested in (and excited in) the process. There are now also a bunch of companies who are taking advantage of this network for their products.
(What we at Thingsquare is doing, and what is discussed in the article, is a little different from what Helium(*) is doing. We are providing a single-purpose network for one system/product, such as a street lighting system. That entire system is connected using its own mesh network, and that mesh network is typically not used for anything but that product's communication needs.)
*: Helium recently changed their name to Nova Labs but I'm not sure exactly how that will effect the naming of the Helium network: https://blog.helium.com/elevating-the-helium-network-with-ne...
Zoom in on your neighborhood and look at the number of nodes.
Here's my small town in Northern Maine: https://explorer.helium.com/hotspots/hex/882b1a06a5fffff
There are three hotspots available for a relatively obscure IoT network. Not only that, if you look at the data tab on these, they're actually getting use. Really cool.
https://www.pexels.com/photo/aerial-view-of-city-during-nigh...
Implications: elevated access within mesh network, capturing traffic between clients and the mesh network, localized disruption of mesh network due to unstable connection caused by duplicate MAC addresses on a single network
And I'm out. Mesh networkers really should spend a bit of time re-learning all the lessons from decades of ham radio packet networks.
It sounds like the criticism hints at the hidden node problem. (Briefly: One of the largest problems in wireless networking. A and B can hear each other, B and C can hear each other, but A and C can't. So when C wants to talk to B, how does it know if A is already transmitting and B's receiver is already listening? In large networks this gets hugely important.)
But it sounds like the simulation is already maximally pessimistic about it -- there's no RF attenuation in the drawer, so all the devices occupy the radio channel whenever they're transmitting. So I would imagine that software that works well in this case, would probably also do decently in the real world. (As opposed to software tested on a naively-simplified network of RF cabling and attenuators, which would not model the hidden node problem's complexities very well.)
So, while the real world will surely be more complex than they hint at in their sentence, I think the simulation drawer is also better than you hint at in yours.
There are nuances, of course, and frankly there are RF network simulators they could be using, but I think the presented MAC-filter approach is not terrible.
It is possible to take these issues into consideration, but as you say, that requires a very different infrastructure than what this article is talking about. The way we do it at Thingsquare is to use a software-based simulator where we can both emulate the software on the devices and have full control of the simulated radio medium - if we need it. Sometimes using RF attenuators and/or cabling is useful.
In the end, what it comes down to that each tool has one or more use cases where it shines, but there is no one tool that fits all.