
Lora-based device-to-device smartphone communication for crisis scenarios [pdf] - oliver2213
https://dtn7.github.io/assets/hoechst2020lora.pdf
======
robshep
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?

~~~
viraptor
> 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.

~~~
robshep
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.

------
ColanR
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.

~~~
kitotik
It’s sad that the likelihood of legal encrypted Ham is decreasing. This would
be such a fun and useful platform to start spinning up services on.

~~~
ohazi
We should build the services anyway.

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."

~~~
ColanR
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_.

I'm with you on this idea.

------
leoedin
This sounds similar to this project:
[https://www.meshtastic.org/](https://www.meshtastic.org/) which was featured
on HN a few weeks ago.

[https://news.ycombinator.com/item?id=22540066](https://news.ycombinator.com/item?id=22540066)

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.

~~~
punkgeek
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.

~~~
gh0st42
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.

------
fragmede
This sounds quite similar to GoTenna, which was founded back in 2013 and has
had multiple successful kickstarters.

[https://gotenna.com/](https://gotenna.com/)

~~~
gh0st42
One of the paper's authors here.

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.

~~~
fragmede
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).

------
nanomonkey
Sudomesh has been working on one of these devices, disaster radio:
[https://disaster.radio](https://disaster.radio)

~~~
state_less
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.

~~~
westurner
Unfortunately, the Earl tablet never made it to market: [https://blog.the-
ebook-reader.com/2015/01/26/video-update-ab...](https://blog.the-ebook-
reader.com/2015/01/26/video-update-about-earl-an-e-ink-survival-tablet/)

Earl specs: Waterproof; Solar charging; eInk; ANT+; NFC; VHF/UHF transceiver
(GMRS, PMR446, UHFCB); GPS; Sensors: Accelerometer, Gyroscope, Magnetometer,
Temperature, Barometer, Humidity; AM/FM/SW/LW/WB

LTE, LoRa, 5G, and Hostapd would be great

Being able to plug it into a powerbank and antennas for use as a fixed or
portable e.g. BATMAN mesh relay would be great

------
eqvinox
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?]

------
westurner
"LoRa+WiFi ClusterDuck Protocol by Project OWL for Disaster Relief"
[https://news.ycombinator.com/item?id=22707267](https://news.ycombinator.com/item?id=22707267)

> _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._

------
tralarpa
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.

------
pabs3
I wonder when smartphones will start to support LoRa without external
hardware.

------
crtlaltdel
happy to see this. as a rf tech, lora was promising when i first ran into it
cira 2014/15

