In LoRa modulation, it seems there is no maximum transmission unit (MTU).
however in most communication system, MTU is generally standardized.
Depending on SFs in LoRa, I know that datarate and maximum payload size changes.
if node select one SF and suppose maximum payload size is quite big.
depending on current LoRa, node transmits that big packet continuously, right?
It seems that small error would corrupt whole packet resulting in heavy retransmissions which is fatal.
why LoRa doesn’t have any fragmentation & reassembly (MTU defined) in terms of this mechanism?
MTU is a concept from packet based communication protocols, while LoRaWAN is more message based communication. Your entire message should fit in one transmission, and after transmission the transmitter should stay silent for a long period.
I just wonder about how long transmitter should be silent.
many documents said just “long enough” (a few minutes), however
i want to know which factor mandates transmitter to wait that much and how to calculate the period.
more fundamentally, why LoRaWAN select
system…? In my opinion, this kind of communication would be weak for collisions among multiple transmissions from many nodes because each node transmit entire message in one transmission(long air-time).
No, not long air-time but short messages… Before starting this discussion I guess you need to read about what LoRaWAN can do, and about its message limitations, and determine if LoRa(WAN) is suitable for your use case.
I just wonder about how long transmitter should be silent.
many documents said just “long enough” (a few minutes), however
i want to know which factor mandates transmitter to wait that much and how to calculate the period.
more fundamentally, why LoRaWAN select [/QUOTE]
You should start by reading the wiki, especially the part about duty cycle.
[quote]In my opinion, this kind of communication would be weak for collisions among multiple transmissions from many nodes because each node transmit entire message in one transmission(long air-time).
any advice?[/quote]
Yes. Place more gateways.
LoRaWAN does not scale well if people transmit very long messages on high spread factors very often. In this scenario hundreds of nodes can easily lead to so much collision that communication is practically impossible. LoRaWAN is meant to transmit two, three dozen of bytes every few minutes to a gateway located not that far away (so it can use a low SF). In this scenario it will take thousands of nodes to lead to enough collisions to disrupt communication.
LoRaWAN gateways are commodity priced so it’s very easy to expand the network, making the nodes switch to lower SF (if they support ADR) and freeing up airtime.
So, how long node should be silent depends on such regulation?
I want to know this kind of silent time is whether inevitable or not in just Lora modulation. (assuming just P2P communication, not LoRaWAN)
because many communication systems (wifi, ble, zigbee) don’t have this weird silent time.
All the examples of communication protocols you just provided have this ‘weird silent time’ aka duty cycle limitations. It is inherent to the (ISM) frequency bands they use and if they don’t comply with it you can’t sell, use or certify them. The only difference is that the protocols you cite have such high bandwidth you don’t really notice these ‘silent times’. E.g. it would only take BLE 0,6ms to transfer the same message LoRaWAN would do in 1,2s (150 bytes on SF12), meaning the ‘silent time’ of BLE would also be 2.000 times shorter.
Remember that you are sharing one frequency channel with possibly thousands of other transmitters. If there aren’t any duty cycle limitations, one device could occupy the entire frequency channel for all the time, effectively reducing the capacity of the channel to one transmitter. Compare it to an office that only has one phone. You don’t want one person to constantly occupy it, because this would mean you wouldn’t be able to receive incoming calls and other personnel wouldn’t be able to make their outgoing calls. Each person (transmitter) must have the opportunity to use the phone (frequency channel) every once in a while (duty cycle).
Or: one phone line, to which many telephones are wired in parallel, so anyone who picks up the receiver can talk, and hear what others are saying. If multiple people use this at the same time, no-one will be heard, including those who are abusing the maximum duty cycle regulations.
I know the limitation of channel usage among multiple nodes.
so, there are many contention or division mechanisms (csma, tdma, fdma, ofdma). in most protocols, there is no duty cycle limitation itself, as far as i know. duty cycle they have is just an outcome of upper MAC.
However, in terms of PHY regardless of MAC(LoRaWAN), LoRa itself seems to have such silent time. that’s my question. where that silent time comes from?
LoRaWAN or LoRa PHY itself? depending on the truth, there is a chance to propose such new MAC (not LoRaWAN…)
The frequencies used by LoRa require (at least in EU due to government regulations) the quiet time. You can propose a new MAC (there are others around) but it still requires silent time as the regulations are the same for all uses of these frequencies.
Duty cycle is dependent on the (inter)national regulation of the frequency band you use. It is also dependent on the range, e.r.p. and application. E.g. a short range 2.5GHz application must not observe any duty cycle, while a long range application might have to comply with 15% duty cycle. The frequency bands and application type LoRaWAN uses have a 1% duty cycle.
Well, at least in Europe. A quick Google search showed that US FCC regulation seem to be much less strict, with practically no duty cycle limits in any ISM band. Here you could use the Listen Before Talk access scheme, which is also supported by LoRaWAN. However, TTN still enforces a 0.1% fair access duty cycle, afaik even when using LBT.
well, when i check the KR region, “silent time” is not fundamentally needed.
in KR region, when LBT is successful, nodes just could transmit messages. it means there isn’t transmit interval time (silent time), and I think LoRa Phy itself doesn’t need such time to send messages continuously. such requirements are just from government or regulations.
So, in country like Korea, a node can send a bunch of messages if other nodes are silent.
Apparently LBT requires an additional FPGA not available in most gateways (although I think the Kerlink has it, maybe @kersing knows?), and only the RN2903 with the latest (beta?) firmware supports it as a node.
Mind you that the TTN network server (or any other LoRaWAN NS) might still enforce a fair use duty cycle (0.1% in TTN).
Ok, I believe that silent times and duty cycle issues are now well understood by everyone. So, can you please help me discussing about the fragmentation?
Since the maximum payload may vary a lot depending on the data rate, even having an application based on short messages (lets say 60 bytes), may not be enough to fit in one transmition. And actual smaller MaxPayload can be as low as 11 bytes!
So, if you dont deal with fragmentation at some point you can’t take advantage of the possible 250bytes long maximum payload that may be achieved in some data rates, and maybe will have to set a very restritive limitation on the payload size.
This way, I believe that a standardization regarding the fragmentation would be very important to encourage the better using of the channel.
This is a common design dilemma. If you want a node that works under all circumstances, you will need to trim down the payload so you don’t violate the duty cycle even under the worst RF conditions. Do you want a product that can send a large payload then you will have to make sure the RF conditions remain good (e.g. better antenna), or do some on the fly optimalisations.
You can design a vehicle to go very fast or lift heavy stuff, but not both .
Hahaha, nice idea comparing this tradeoff with the strength x speed capacity, @Epyon! Maybe you got my point here.
But my dilemma has both a practical and a philosophical question: I know that LoRa/LoRaWAN can handle my communication issue. I mean, I don’t need high data rate nor high volumes of data. But, I may need sometimes to send “big” data frames, let’s say of 100 - 200 bytes long.
One approach could be to limit my network architecture in order to have a link budget (dealing with distance and antenna gains) big enough to make sure that I can use a data rate that support this payload size.
The other would be to limit the payload (at my application) to the lower maximum payload possible (11 bytes on the AU915 channel plan).
So, in my oppinion, none of them are good options. At the 1st one we can’t take advantage of the great ability of LoRa about dealing with long distances, minimizing the quantity of gateways needed to cover an area. On the other hand, the 2nd approach leads to a subutilization and a very bad payload/overhead ratio wich obviously is a bad usage of the RF channel.
This leads to my current belief that the only effective approach being the packet fragmentation / defragmentation, so one can send bigger packages in any data rate / payload limitation, taking advantage of all LoRa capacities. If this is correct, I believe that LoRaWAN should provide a fragmentation standard so we don’t finish up with a lot of proprietary and uncompatible solutions. Also, having this standardized will lead to manufacturers and the developper comunity to integrate this on the stack, encouraging everyone to use it and therefore helping to achieve a better overall RF channel usage.
I’m not quite sure what you mean by ‘fragmentation’, but in any case the problem you describe is to be solved at the application layer, not at the physical to network layer where LoRa(WAN) is defined. The LoRa(WAN) spec can support the needs you require, but the specific problems your application creates (sometimes larger payloads) should be addressed by the application itself.
.