Limitation of Transmission of Data in one day

[sumitsirmewar]

Hello to all,
I am working on the LoRaWAN network.
I have some doubts about the transmission of data through the end device to the gateway.
How many times data will transmit in one day?
There is any limitations of transmission.?
Or there is any kind of command through this I can set limit?
So can anyone give me a solution for this?

[LoRaTracker]

See here;

Fair Use Policy explained

For The Things Network’s public community network the Fair Access Policy limits the data each end-device can send, by allowing: An average of 30 seconds uplink time on air, per 24 hours, per device. At most 10 downlink messages per 24 hours, including the ACKs for confirmed uplinks. A good goal is to keep the application payload under 12 bytes, and the interval between messages at least several minutes. An online airtime calculator can give you some insight. The following regulations apply a…

At the shortest distance from a Gateway you might be using a high data rate (SF7) and under the policy above your limit is approx 12,500 bytes of data per day.

If your a long distnce from a Gateway you might be using a low data rate (SF12) and under the policy above your limit is approx 525 bytes of data per day.

You really need to plan for using low data rates unless you are really really really sure you are close enough to a gateway to use higher data rates.

[sumitsirmewar]

Hello @LoRaTracker,
Now for testing purposes, I’m sending 31 bytes of data, no of times in a day at SF12BW125.
So can u tell me,
1)How many I can transmit this data to the gateway?
2) There is any indication to find an error, if is limit exceed?
The data size is between 30-35 byte

[LoRaTracker]

@LoRaTracker

If your a long distance from a Gateway you might be using a low data rate (SF12) and under the policy above your limit is approx 525 bytes of data per day.

Well if you sending 35 bytes of ‘data’ then add 15 bytes for the packet overhead and you have a 50 bytes packet, so 10 per day.

There is no error indication if you exceed the limit, at the moment.

There is no exception to the rules for ‘testing purposes’.

[sumitsirmewar]

@LoRaTracker Thank u for this information.
I have some more questions,

1. When the end device is joined to the network, and at the time of transmission it failed to transmit data, then that transmission is countable?
2. If that transmission is countable then how can I transmit data to the network after limit reach?

[LoRaTracker]

If your planning to breach the fair access limits, contact The Things Industries (TTI) and pay for access perhaps ?

[sumitsirmewar]

no, I’m not breaching, I’m just asking.
My question is that,
if end device is connected to gateway and if transmission is not completed then this unsucessful transmission can be countable in daily transmission count?

[kersing (Jac Kersing)]

@sumitsirmewar

unsucessful transmission can be countable in daily transmission count?

Generally speaking a node does not know if a transmission has been successfully received. So it must act like it is with regards to fair access and duty cycles. For data redundancy it should act like the data might be lost and include some mechanism to recover from the loss (or ignore that possibility if a specific data point is not relevant and some loss is acceptable)

The only way for a node to know if a transmission was received is to use acknowledged transmission however every node is only allowed 10 downlinks (required for acknowledgement) a day.

[sumitsirmewar]

Thank you @kersing

[AlainD]

A question about handling the limitations:

Sending fewer “bigger” msg’s does have less overhead (13 bytes per msg + radio overhead). If that’s possible is this the recommended way of doing things?

In some use cases it’s very acceptable to send measurement every 4 hours, even if the measurements itself are every 15 minutes.

[kersing (Jac Kersing)]

@AlainD

Sending fewer “bigger” msg’s does have less overhead (13 bytes per msg + radio overhead). If that’s possible is this the recommended way of doing things?

If your use case allows for it that would be good. Keep in mind the allowed message size decreases when the spreading factor goes up. And include some redundancy to negate the impact of a lost packet.