Instead of a trivial use-case of existing technology it would be far more beneficial to model (1) RF subscriber characteristics and how an unmanaged network of point-to-point devices can support crisis communications when a potentially (very) large number of devices can flip over to long-range point to point. How is congestion managed and mitigated? how is available spectrum, channel space and bandwidth most effectively used?
And (2) The paper mentions an upstream message board and the underlying networking features provided by DTN7 describe a range of routing protocols. If nodes are taking part in a self-organising mesh network that can route in and out to central services then the management of layer-1 & layer-2 is crucial to maintain a working network. It doesn't model any of the characteristics of the medium and any strategies for how the underlying physical characteristics can be leveraged to support a mesh.
LoRa is excellent at long range, but with Long Range transmission comes a greater opportunity to interfere with other transmissions. Sure you can reach a long way so a low number of rural casualties can be serviced effectively, but what happens when you have a dense urban scenario and there are 10's/100's/1000's of nodes all hitting refresh on twitter and they are all interfering with each other and the few low-bandwidth gateway nodes are attempting to carry the traffic?
> 10's/100's/1000's of nodes all hitting refresh on twitter
That's not going to happen with Lora. This it completely different scale of messaging. Your message is limited in bytes and takes multiple seconds to transmit. You can assume the messages will be significantly delayed if 100 people around are actively using it.
But it's designed for a specific purpose and there's no active refreshing/polling that's going to happen.
Exactly. How many people could this support? My guess it would be a small proportion of an urban population.
> no active refreshing/polling
Maybe not twitter specifically, but the paper mentions a centralised message board like twitter, so we can assume some sort of interactive service would be suggested.
My main point is this that for such a specific bearer (bandwidth, channel plan, duty cycle, range etc) it is important to model the capabilities. I’m not sure how well this would support a crisis (notably free of central management) when there is the potential for large numbers of nodes.
Mostly what we need is fewer restrictions on some better radio frequencies. Legalizing encrypted Ham radio would be a good start. If there was an ecosystem of infrastructure around those frequencies, we would have no problem whatsoever building robust mesh networks with higher bandwidth that could operate uninterrupted through crisis scenarios.
As it is, we've been left with scraps; and this article describes an amazing tool which shouldn't have to exist.
I used to think that allowing encrypted ham radio would be a good idea, but the more I think about it, it isn't. It's supposed to be a place for radio hobbyist experimentation. To permit encryption there would see it used for commercial applications pretending to be hobbyists, and other exploitation outside its purpose.
I feel that other solutions would be better, for example having bands for community mesh networking or similar that has different restrictions to the ISM bands. No idea really how the mechanics would work, but I feel that allowing encryption on ham bands would just see it abused to the detriment of its actual goal.
This would just be part of the ecosystem. We've already learned to coexist in the shorter-range wifi spectrum. There's no reason only hobbyists should be able to access the spectrum, since that means that commercial applications would be disallowed from operating with robust tools when crisis comes.
What exactly is wrong with commercial use coexisting with hobbyist use? And what is the experimentation supposed to lead to? If we allow commercial application, then we might actually see an effective mesh network set up. I mean, if I could build a meshnet in the Ham radio spectrum and sell access, I'd do it: I'd be able to build it right, it would be reliable, and people would be glad it existed. But it's not worth the years of effort if it can't be commercial.
By commercial, I mean commercial users using hobbyist spectrum. These would interfere with the hobbyist use. Instead, if you're a commercial user you go to your RSM or whatever and licence a bit of spectrum.
If you want to design and build something meshy, go for it. If you're licensed and obeying the rules, you can use the ham radio spectrum for your experimentation. I'd encourage that. But when you want to take it commercial by selling access, licence some spectrum to use for it and then you don't have to use callsigns, can use encryption, etc to your heart's content.
The purpose of the ham band allocations is to be a place where people can experiment with radio (or ragchew if that's more their thing), they're qualified to some degree so are less likely to interfere with others doing the same, and they're not being stomped on by companies using it as a space to do their ISP wireless data backhaul or whatever.
By "build a meshnet in the Ham radio spectrum and sell access" you're taking something that's a public good (with some conditions) that others had access to and reselling it, making it harder for others to do the same.
We can design radios that use spread-spectrum / low-probability-of-intercept / below-the-noise-floor techniques that can make the services both harder to identify, and (more importantly) far, far less likely to interfere with anything else on the same frequencies, which is what the FCC actually cares about.
If this is useful, and if people actually want to use it, they will, and then the cat will be out of the bag and we can make a case for legalization.
It's easier to ask for forgiveness than permission. They're never going to give you permission for something theoretical. People have to be using it and not willing to give it up, like uber, and then they'll go "gee, I guess we need to figure out how to make this work."
This. The original hackers didn't bother with the legality of what they did - it was interesting and awesome, and some of them went to jail for it, but it was worth it.
Where I come from (.au) that’d mean somehow taking back the bottom half of the 915MHz band we sold off to the mobile phone network operators... Not happening any time soon... :sigh:
I think selling it as a communicator for skiing/hiking is maybe a better idea than as a disaster radio, solely because a disaster radio is never really going to be used. If it's a useful, well used system that happens to be highly resiliant, that makes it much more likely to be available when a disaster hits.
yep - I'm one of the meshtastic devs and that was our thought as well.
* use off the shelf hardware, so user can just buy a finished device from China
* make it cheap
* Make something useful for people in general (without disaster) - then they will have it when the disaster happens.
One of the paper authors here and the one mainly responsible for the rf95modem firmware.
The idea was not only to provide another msg app but a platform that can easily be used for different applications. One use-case in the paper is the chat app, the dtn part is not directly connected to the chat app but also uses the LoRa modem.
The modem firmware (initially developed in 2017/2018) is even more general purpose and is currently used in many different ways in different projects and prototypes. The main selling point is that one can easily connect cheap LoRa hardware to smartphones and desktop computers without microcontroller programming or providing specific device drivers.
Thus, the same modem can be used for messaging as well as environmental monitoring or other IoT applications without the need to reprogram the LoRa modules.
GoTenna is definitely similar in its use-case and appearance.
The problem with GoTenna is similar to FireChat for offline communication: they are closed ecosystems, single purpose and cannot easily be changed to fit specific needs.
If you need something consumer-grade, ready to use: go for GoTenna (or Sonnet or maybe even a Garmin InReach or Spot X).
We propose different proof of concepts in the paper that are nowhere near the product quality of commercial solutions. Also, the chat application is single-hop and does not yet use a DTN underlay, at least not in the published version.
But all code is open and can easily be extended. Even better, the rf95modem firmware is designed to be used as-is. Once loaded on a LoRa board anyone can implement anything over device-to-device LoRa, be it a msg app, local news broadcast, IoT monitoring. This works via AT commands over USB serial interface, local esp32 WiFi or BLE.
That's great! A known shortcoming of Gotenna is that it assumes civilization (play/app store, Internet access) in order to set it the device, which isn't totally reassuring to go off into the wilderness with (its primary use case).
I like the solar integration. My ideal product would be a programmable LoRa transceiver integrates into a waterproof battery bank with solar, gps and a small touch screen. Should be about the size of a large handheld which could mounted on a house, tree, mast or carry it in a pocket/bag. Apps could be, SOS messages, chat and weather information. If it’s extensible (e.g. something like an app store or package manager), I’m sure folks will dream up additional uses.
Sort of like a more hackable/accessible phone and long range radio.
So... what exactly is the crisis scenario this is modeled for?
I can't come up with a reasonable situation where mobile networks are completely f*cked, yet my smartphone is still running medium- to long-term. Maybe I'm not creative enough.
(The only thing that comes close is a large-scale power outage, but then after a day or two my smartphone battery is dead too. Also, the same measures to revive the smartphone [solar backup, generators, etc.] can also be used to revive the mobile network...)
[Add.: what definitely makes sense is a _dedicated_ LoRa-based emergency network, which uses dedicated user agents with low power draw and long-term batteries. Just ditch the smartphone?]
> An opkg (for e.g. OpenWRT) with this mesh software would make it possible to use WiFi/LTE routers with a LoRa transmitter/receiver connected over e.g. USB or Mini-PCIe.
I don't understand what the contribution of this paper is. The most important thing, a scability test, is missing. You don't need 16 pages to describe a LoRa-based device-to-device messaging application.
LoRa is excellent at long range, but with Long Range transmission comes a greater opportunity to interfere with other transmissions. Sure you can reach a long way so a low number of rural casualties can be serviced effectively, but what happens when you have a dense urban scenario and there are 10's/100's/1000's of nodes all hitting refresh on twitter and they are all interfering with each other and the few low-bandwidth gateway nodes are attempting to carry the traffic?