Feels a bit like an advertisement here for Weightless-P. I assume you are involved? I’ve built an adaptive RS codec that runs very fast on Cortex-M. You’ll want to update your PHY, though, to make the best use of any type of error correction. It’s sort of odd to me that 802.15.4g – and IIRC Weightless-P – specify convolutional code FEC but then specify MAC frames that make them less effective than they should be. At least this is something LoRa gets right, even if (as I’ve been told) in present silicon there a glitches in some of the coding modes.
Anyway, you can find me pretty easily if you want to chat more, either through this forum or even by googling my username. I’d be happy to chat.
Apart from the technical difficulties of using LBT with DSSS and FHSS, I’m guessing that LoRaWAN, like others don’t specify LBT (when not mandated) because of the prisoner’s dilema - at a crowded dinner party if you wait for a pause in the conversation you almost never get to speak. If you stick your fingers in your ears and talk over someone else then there is still a good chance you will be heard so long as your target is nearer to you. The third party’s message may also get through as well.
On the other hand, if you don’t get to talk because you’re too polite to interrupt others, your message has zero chance of being heard. Perhaps not good for overall spectrum capacity but it would need the regulators to get involved to maximise that. Also LBT is not fair to those in the centre of a cluster of active transmitters compared to those at the edges. I’m not aware of any rules which prevent you from adopting both strategies though to take advantage of the greater LBT DC when traffic is light and reverting to shouting with lower DCs when contention increases.
@jpnorair Indeed I am involved in Weightless-P, but this does not prevent from being unbiased (or trying to).
I am not sure I get your point about MAC frame not taking most advantage of CC FEC, may you elaborate on this?
I remember we exchanged before (I believe on LinkedIn), RS is interesting, especially for long transmission time like LPWAN, and we may get in touch later.
I got confused after read all the discussion here how to calculate that how many sensors can be severed by a gateway. If we take 24 hours as the time period, and all the 8 channels are used at a gateway, duty cycle is 5%, and SF is 7-12. If we assume the packet arrival data is \lambda which follows PPP. How to get a theoretical value for the maximal number of sensors covered by a single gateway? @Thomas
@aliekens@scle
If we look at the joining message, it’s is totally up to the end-device to choose the SF and central frequency to send a joining request to gateway. The collisions for joining message must be very high. Joining message delay is also comparatively large. Even in the case, where there are only 5 devices under a gateway sending joining request message, the message will collide. Did you simulate for that? What are your views about it?
Here’s a conclusion from a recent article regarding LoRaWAN scalability:
“Do Long Range (LoRa) Low-Power Wide-Area Network(LPWAN) scale? According to our study presented in the paper current installations based on LoRaWAN do not. (…) However, our study also shows that LoRa networks can scale quite well if they use dynamic transmission parameter selection and/or multiple sinks. For both aspects more work is required as protocols for dynamic transmission parameter selection and strategies for useful sink deployment must be developed”
Interestingly, the article doesn’t mention Adaptive Data Rate (ADR), at least not in those words. Possibly because it’s not implemented in current networks (e.g. see https://github.com/TheThingsNetwork/ttn/issues/265 )
Exactly, which is why I wrote “at least not in those words”. I was under the impression that ADR was the terminology that Semtech / Lora Alliance generally used for this - so I was a bit surprised they didn’t mention that term when the whole article revolves around this topic, almost as if they didn’t realize this is already being developed (and possibly already in place in some implementations?).
Well written article. As the authors say, indeed an impartial and fair overview of the capabilities and limitations of LoRaWAN.
some small remarks:
The 500kHz channel the authors mention is not available in Europe, and in the US it’s only used for downlink. Therefore the max data rate is actually a bit lower.
The authors only consider 3 channels. During a join, the network configures 5 additional channels (bringing the number to 8). Using MAC commands we could configure even more channels if the gateway is configured to handle those.
I’m puzzled by the scale in packets/hour they’ve chosen
Most applications I’ve seen for LoRaWAN requires a packet every 1 to 15 minutes (so 4 to 60 pkt/h) but for whatever reason the authors of the article chose to show curves for up to several thousands of packets/hour. Do they thinks it’s some kind of “long range Wifi”? Thousands of packets/hour also mean draining a battery fast, and it’s not what those class of networks were designed for, it’s even in the name: LPWAN, for Low Power Wide Area Network.
Sylvain, the discussion is not about how many messages a device can send, but how many a gateway can receive. Considering that a gateway has a range of multiple kilometers, it is not unthinkable in an urban setting that there are 1000 devices sending 1 message per minute. At these rates, the public ether becomes plugged up.
Don’t forget a gateway picks up all messages from all networks. E.g. your TTN gateway will also pick up the messages from other telco’s operating a LoraWan network in the same region and vice versa.
Thousands of devices per gateway isn’t unreasonable. E.g. in a mid-sized Western European city, there are around 2.000 utility meters per square kilometer. If a utilities company chooses LoraWan to communicate quarter-hourly meter readings, you’re looking at 4.000 messages/hour/km², for this application alone.