Tsvetan Usunov (Olimex) Was was saying recently in a talk that LoraWan has started to be unusable in Sofia because no one cares about duty cycles and they completely saturate the network…
Does the network server implement logic of duty cycle or gateway implements it?. If multiple gateways are present , then how network server calculates it?
The challenge here is generally the Node behaviour and that is in the hands of the users/makers/developers/manufacturers. Some modules have s/w stacks that enforce duty cycle policies other dont (but not FUP implementations that is generally a user issue). DC for the Gateways is calculated and enforced via the NS - that is one of its primary functions. If a NS decides that a given GW has reached or is reaching its download (Tx) limit it will queue messages or where messages are time critical e.g response to a RX1 or RX2 windows, join accept priority etc. It may re-order the queue, or where practical and where there are others in range, it may decides to route the downlink message via a neighbouring GW to share the load. This is one of the reasons why it is not usually considered practical to have a GW associated with more than one NS or Network provider, as each is then unable to assess how much DL capacity has been consumed by the other other operator, unless you start getting into complex GW set-ups with GW derived stats, flags and semaphore systems… a nightmare to implement reliably/effectively
1 Like
That means gateway doesn’t have any intelligence to follow DC limitations or RX windows timing. Everything is implemented in NS itself?
Basically yes that is correct - there are some higher end GW’s that monitor and manage as I understand it but the NS is princial arbiter. Also you can have the NS built into the GW to act as self contained units - example being the Multitech Conduit/MCAP or the original Semtech IoT Starter Kit ref design (now obsolete/unsupported/end off life), many self build (e.g. RPi based) GW’s - typically used for private deployments etc.indeed these are often fully integrated with their own App servers in built or with e.g. internal MQTT broker to connect to external App servers etc.
The fact that the GW is ‘managed’ and downloads queued by the NS is one of the reasons why you need generally low/predictable latency backhaul connections - reflected by e.g. TTN instances distributed globally to increase resilience & reduce ping times - and why sometimes Cellular and almost always Satellite backhaul fails or needs careful set up and timing back-off/mitigation.
2 Likes
The Semtech LoRa calculator will tell you the on air time for a particular spreading factor and packet length.
Assuming your 100 bytes grows to say 120 bytes by the time its sent by TTN , then best case, for nodes that are close is 197mS per packet and worst case 3874mS.
So best case is 567 seconds of air time per day and worse case is 11,157 seconds of air time per day.
The fair access limit is 30 seconds per day.
So best case you would be 19 times the limit, worse case 371 times the limit.
3 Likes
Its also worth pointing out that even the best case scenario, SF7, is running at around 0.7% duty cycle, the restriction is 1%.
So you would need to hard code each node to ensure it could only transmit at SF7, if any shifted to SF8 you would be breaching the restrictions on duty cycle.
1 Like
And be highly unsocial when using a shared medium like airwaves.
4 Likes
For anyone finding this discussion at some point in the future:
The usage described would be illegal in Europe as it exceeds allowed transmission time for the 868MHz (sub)band used for LoRaWAN by TTN (and by Loriot as well given their response).
If you want to break the law, don’t be surprised if at some point in time someone will knock on your door telling you to shut things down, they might impose a fine for illegal radio spectrum use as well.
3 Likes
I am no expert with duty cycle limitations but i have an important question. You mentioned “Every device has the same duty cycle”. When creating a simple LoRa PHY node to node (one node act as gateway) system where the sender node collects some sensing data and sends to receiver node using LoRa. My question is: Are there any duty cycle limits imposed in such LoRa PHY layer devices with regards to the amount of data and transmission time for messages in a day?
Are the LoRa node and Gatewway on TTN ?
1 Like
Duty Cycle: In Europe, any equipment (regardless of its role - end device, repeater, gateway, beacon, …) that transmits radio signals in the 868 MHz band must respect the European duty cycle regulations. Other regions may have similar duty cycle regulations, so make sure to check with your national regulator. Exceeding these regulations is punishable by law.
Fair Access Policy: On The Things Network’s public community network we have transmission guidelines to make sure that our resources can be shared in a fair way between community members. Any production end device should respect TTN’s fair access policy, which means limiting consumption to 30 seconds of uplink airtime per day, and to 10 downlink messages per day. For development purposes it may be acceptable to exceed the fair access policy. If your production devices need to transmit or receive more, a private network is likely more suitable for you (we can help you with that).
On private networks running The Things Network Stack, the fair access policy does not apply, but the duty cycle limitations are imposed by law for a specific region (Europe) and always apply.
7 Likes