Unclear what exactly is possible with LoRaWAN technology


(Stephen) #1

I really want to know exactly what is practically possible. You can tell me about TTN limitations, but I want to know the TECHNOLOGY.

Here is what I hear, 1KB/s~ish speed over many KMs of distance. Sounds okay, but I know that isn't the full picture. I've made some quick assumptions, please correct me. I don't really know much of network tech so please be gentle...

  1. Am I correct that 1KB/s is total available, not each? So 10 computers downloading different data "at once" means in practice only 0.1KB/s each on average is maximum possible in that scenario?

  2. Is the upload speed also the same speed?

  3. Does each computer 'own' the network while it uses it?

  4. Does that also mean uploading means all downloads are halted as well, except for the tower receiving? Meaning effectively the average total simultaneous speeds are 0.5KB/s up and 0.5KB/s down?

  5. What kind of latency ranges are expected? Is there a big variation? what varies it? Is there a lot of packetloss?

  6. If it is 1KB/s, does that mean the very maximum a tower can ever do, as both uploads and downloads combined, is 86.4MB per day?

  7. How does interference come into this? Can there be many networks side by side just with slightly tweaked frequency without issue? Is there a limit? Could this pose problems in the future if too many people use their own networks?

  8. Is having a separate dedicated upload and dedicated download network connected simultaneously out of the question?

  9. How does this work between other towers in a meshnet? person 1, through tower 1, to tower 2, to person 2. Does that effectively dedicate both towers for that amount of time? What if something had to travel down 10 towers? All 10 towers dedicated to that one transmission while it is being transmitted, or are there different frequencies involved?

  10. Are there any multicast ideas or implementations yet? Any hybrid implementations where maybe the TTN can dedicate some data that can be duplicated to all receivers? Or is that not really possible without abolishing encryption? I guess you could program it to turn it off for those packets right?

My goal in mind:

  • I'm interested in an always-on internet-as-a-newspaper kind of implementation that is received exactly as is to everyone connected. Can this work? Is there a limit to how many can receive? Does more receiving in the same area need more power output? Would I have to send the bulk of data at once, then communicate separately to send all the missed packets to each computer separately? Or I guess I could just put an error recovery thingy into the first bit of data right? But is there any reason why this tech can't give out the same 80MB a day to tons and tons of computers? at 900KB every 15 minutes, that is easily 8MB of uncompressed text. If prioritised correctly that is certainly enough data to cover a lot of things going on in the world.

Any comments welcome!


(Arjan) #2

It's much, much less than you expect:

  • Payload should be as small as possible. A good goal is to keep it under 12 bytes. [...]
  • Interval between messages should be in the range of several minutes [...]

(Hylke Visser) #3

First of all, with LoRaWAN we're not talking about computers, but about devices, nodes or motes. These devices are simple, low-power embedded systems with a simple function, such as measuring and transmitting sensor values.

  1. The burst data rate of a device is between 250 and 5470 bits per second where a lower speed will have a longer range. The problem (especially in Europe) is the duty-cycle of the devices, meaning that they are only allowed to transmit 1% of the time on a channel, so on average it's more like 1/100th of the burst speed.

  2. LoRaWAN is optimized for uplink (from the node to a server). For downlink there is 8 times less bandwidth available.

  3. A transmitter occupies a channel for the duration of the transmission. If other devices are transmitting simultaneously, the device with the strongest signal wins.

  4. A gateway can receive on 8 channels at the same time, but when it's transmitting the receivers are switched off.

  5. One-way latency is very low (depending on the network connection of the gateway). Round-trip latency is 1 or 2 seconds (this is because of receive windows).

  6. Look at @arjanvanb's message

  7. Networks can use slightly different channels, but yes there's definitely a limit. We hope both developers and network operators will follow the "don't be an asshole" policy and use the available bandwidth as efficiently as possible. We have to share it with everyone.

  8. If you have multiple gateways, gateway A can transmit on a channel to device B while gateway C receives from device D on the same channel.

  9. We're not doing mesh networking, but follow a star-of-stars topology.

  10. This is not impossible, but I don't think we'll see this in TTN any time soon.

For what you want to build, LoRaWAN is not your solution. With LoRaWAN you should talk about bytes, not even kilobytes and definitely not megabytes.


#4

Is there any exception still fitting fair use for short term experiments ? I think about things like mapping a certain area with ttnmapper it could be very useful to transmit for instance every 30 seconds during a half an hour trip.

Since afaik the fair use policy is not enforced it would be possible at the moment anyway, but what is generally considered 'fair' in this kind of situations?


(Hylke Visser) #5

We're not enforcing the policy yet, and with the current traffic on the network, it's unlikely that you'll have a negative impact on other users when you're transmitting a lot during a 30 minute drive for ttnmapper.


(Stephen) #6

Ah I see :\ . Thanks for that clarification though.


(Hylke Visser) #7

Sorry to disappoint you. LoRa is unfortunately not free 4G


(Stephen) #8

It's not even free 2G, or even 1/5th of 2G.


(Arjan) #9

Even 2/5thG would require much more power to transmit, so LoRaWAN surely has many use cases for standalone sensors, that need to send data while no user with an internet connection is around. Unlike some "always-on internet-as-a-newspaper kind of implementation" where the user would probably be carrying some 3G/4G connected device anyhow, which also will be recharged often, to allow for receiving all day long.


#10

You inspired us to write this post today: http://www.link-labs.com/use-cases-and-considerations-for-lorawan/

Many people want to use LoRaWAN for uses other than intended.


#11

Thank you for this very useful document for the non technical initiated. May be in the end TTN is a technology that is more beneficial for smart rural areas than for smart cities??


(Hylke Visser) #12

Nice post! I'll read some more about Symphony Link when I have time. I think it might be a lot more suitable for @Stephen's use case than LoRaWAN.

Small note: At the top of the post you say that Symphony Link is an alternative protocol for LoRa. Somewhere else on the website is stated that Symphony Link uses the LoRa PHY. Is this a mistake? (otherwise, could you clarify this?)


#13

Sure. LoRa is an interesting technology, because it a combination of pure PHY, plus packetization and error correcting. It is a really nice system for bundling up messages and sending them with great link budget. The baseband processor (SX1301) is a very easy way to receive a bunch of these messages at the same time.

LoRaWAN builds a wireless system out of this. LoRaWAN is the protocol (really layers 2-6) that take these on the air messages and build a wireless system out of it.

Symphony Link starts with the same fundamental building blocks, but goes in a very different direction. Symphony Link is design in a more traditional way, where the gateway controls the network it is providing (like WiFi, in a way).

Right now, Symphony Link is only available in the 900 MHz countries, but we should have some very exciting announcements in the 860 MHz band later this year.

I'm happy to answer any technical questions, if you have them.


(Arjan) #14

So Symphony Link and LoRaWAN both use LoRa? But wouldn't they interfere then?


(val) #16

what is exactly possible with emerging technology.. however, the questions open the suspended discussion of the media that LoRaWAN used. it is not a technology but physical entity - few megahertz band from the sub-gigahertz ICM spectrum.. the throughput of such medium is extremely limited having in mind that LoRa is a long range connection.. in contrast, Wi-Fi and BTL has very short range and use wider spectrum allocation.. subsequently, you could stream HD video or Hi-Fi audio.. wide range means a lot of nodes 10k or so, and that fact limits the throughput of the net dramatically.. LoRa is not about broadcasting data.. what use of such network? .. nobody knows.. the list of promising applications is very short.. however, has been someone able to predict all applications of GSM network 20 years ago?


#17

Symphony Link inverts I/Q in its uplink and downlink opposite of LoRaWAN, so they don't interfere with one another. In the EU Symphony Link uses a different part of the band also, which has the additional benefit of removing the duty cycle limitation.


(Arjan) #18

LoRaWAN gateways invert I/Q compared to LoRaWAN nodes, right? So then one protocol's uplink is interfering with the other's downlink, and vice versa, right? :smile:

And then, in places where Symphony Link uses the same frequencies, Symphony Link's multicast would be interfering with LoRaWAN uplinks, and the other way around?


#19

Yes, if we were using the same channel map, which we aren't.


(Thomas Telkamp) #20

Interesting. Can you elaborate on that?


(Micfox001) #21

I have a quick question:

Can LoRaWan support the video transmission given its limited data rate?