[Berlin-wireless] Alternate radio internet network

[Christian Hammel]

> You might use the LORA Wan stuff …

mmh. Probably not.

1.
The LoRaWAN protocol does not cover meshing or peer to peer Networking.
It is designed to use a central infrastructure (end-device --> gateway
--> Internet --> packet broker (central server) and some more central
elements --> user's application and vice versa) End-device -->
end-device or end-device --> gateway --> end device ist not part of the
protocol. Workarounds would probably fail because of the end to end
encryption of the packets.
For LoRa as a physical layer (without LoRaWAN) some p2p examples are known.

2.
I have no idea, how to force answers within 0,1 s at the LoRaWAN level.
If intended this would probably have to be implemented in the
server-sided (user's-)application. In addition to that a particular
amount of packet losses is always probable in the ISM band even when
they were sent in the timing windwow. And (even worse): If you don't
implement it in your device or in your application LoRaWAN does not ACK
packets (workaround known) and the packet's payload is only some 40bytes
(TTN) or less (Helium). Aditionally downstream messages are more
restricted than upstream.

3.
LoRa is not exactly "free": The chirp radio behind LoRa is IP-protected
by semtech's patents.  The LoRaWAN standard is published but also owned
by semtech or the LoRaWAN alliance, respectively. For using a specific
network your packets must have a network ID in their headers in order to
be accepted, forwarded or dismissed by the network operator's packet
broker. A network ID for your own LoRaWAN-Network must be bought or
leased for (much) money. Using other people's LoRaWAN networks (and
their IDs) is for free but restricted by a a fair use policy (TTN) or
costs transmission fees (Helium and other Cryptomining-IoT-Networks).
In all cases LoRaWAN networks are far away from Freifunk's pico peering.

4.
Are you aware of IoT networks like LoRaWAN, Sigfox and others beeing
extremly narrow-banded? They are usually good for transferring some
bytes like the readout of a thermometer and begin to reach their limits
already with transferring characters. Depending on what is intended to
do, 0,1 s response time might not be the biggest problem with these
technologies.




>> Because assuming I only need to design a protocol, I just need to
>> create a web server of a certain kind. People can share the locations
>> of their servers, exactly like a URL for HTTP, or an email address for
>> IMAP. As long as it conforms to the “standards” in a way (I’m not sure
>> how to enforce that, like a protocol in Swift or an interface in
>> Java), it’s a valid server - just like a REST API I believe can be
>> written in any language but it just respond to things like GET
>> requests and so on.
In a narrowband world you would make your device send it's
GPS-Coordinates every some minutes or so to a database and fetch the
coordinates from there via the internet and not adress the GPS-sensor of
your device directly (whether with LoRaWAN or something alike or not) by
GET requests. It's also safer because it avoids direct communication
between third parties and your device.

Christian