just had some discussion about the TTN gateways from kickstarter. Can somebody tell me if the forwarder in the gateway can send info to more and/or different backend-servers.
1 Like
The Things Gateway will forward to one backend server. In that server, you would be able to distribute the traffic further. This is exactly what happens in TTN’s public community network, where the Router component distributes the traffic to different Brokers:
Although some forwarders support multiple backends, it’s bad practice. When forwarding to 2 backends, you double the internet traffic of the gateway, leading to more packet loss. Additionally (if you’re in Europe), your gateway will no longer be compliant with European radio spectrum regulations.
I might not understand the answer fully but…
the gateway forwards the packets to the backend over TCP/IP, so yes the internet-traffic (which is hardly a factor on a broadband-connection) will double -which is still only a trickle on broadband-
but… how does that influence the radio spectrum? -its over TCP/IP or not?-
didn’t the poly-packet-forwarder (for instance the multitechs) send the packets to 2 or 3 backend’s at the same time? (wasn’t that one compliant with Europian radio Spectrum regulations??)
[i am a bit confused]
The problem is that the backend is responsible for keeping track of the gateway’s duty cycle. A backend will stop sending downlink when the gateway reaches 100%, so if you’re forwarding to 3 backends, they will stop scheduling downlink when they think the gateway is at 100%, while actually, the gateway is already at 300%.
Gateways that run the existing poly_forwarders are indeed not compliant.
Hmm, I disagree. The forwarders are not compliant if:
- Forwarding to multiple back-ends and
- Multiple on those back-ends generate downlink data.
Using the poly forwarder to forward data to TTN and gatewaystats.org (the latter to get data on the usage of the gateway) does not in any way make the gateway not compliant.
Forwarding to for instance semtech and TTN puts the gateway at risk because both generate downlink traffic.
I understand TTN want gateways to connect to TTN only, FUD is not the way… 
2 Likes
Of course. When a backend doesn’t send downlink, you have nothing to worry about. But when you send to multiple backends that can send downlink, there is no way of preventing a gateway from going over its duty cycle, as the gateway doesn’t keep track of its own duty cycle.
2 Likes
Why not?
Because it’s stupid 
Even if a gateway keeps track of its own duty cycle, then still the backend needs to do that as well: otherwise the backend cannot decide which gateway should be used for downlinks. Next, if the gateway would accept downlinks from multiple backends and adjust its duty cycle to that, then a specific backend cannot rely on its own administration any longer, as a gateway might refuse a downlink while the backend thinks it can still handle it.
2 Likes
Just for my understanding… some cases:
If a gateway has only 1 single node that sends information to 1 single backend… with acknowledge… than the duty-cycle would be 50% (or nearly 50%)…
That would not be a problem because the radio-band is not obstructed by to much traffic… so duty-cycle is not an absolute measurement but depending on overal traffic… measured in absolute transmission-time…
if i would poly-forward the traffic of a gateway with only 10 nodes… to 2 backends (which would make it not compliant)… measured in absolute transmission-time the duty-cycle would probably be <1% (if the nodes are not transmitting ALL the time)
Declaring that poly-forwarding is ‘illegal’ is a very black&white statement… transmission-time is not solely depending on single-forwarding or poly-forwarding (like Jac stated: even if we forward to 10 backends… as long as we stay under 864 seconds transmitting-time per day for the gateway… we comply to the 1% duty-cycle-law)
Correct?
and would that not imply that simply by monitoring the transmit-time in a gateway one can decide to place a second gateway in the region (if tt>850 seconds/day;instal new gateway) (hopefully nearer to a number of nodes so transmission-time will decrease overall)
or are my preassumtions incorrect?
No, it all depends on how many packets need to be sent by the gateway, and how much air time each packet needs.
How did you come up with 50%? It seems you might be mistaking duty cycle for something else?
It’s not a daily total, it needs to be taken into account each time you send:
The LoRaWAN enforces a per sub-band duty-cycle limitation. Each time a frame is transmitted in a given sub-band, the time of emission and the on-air duration of the frame are recorded for this sub-band. The same sub-band cannot be used again during the next Toff seconds where:
Toffsubband = (TimeOnAir / DutyCyclesubbband) - TimeOnAir
As for your example with one node and one gateway:
-
Assuming a node needs to keep below a maximum duty cycle of 1%, and assuming that the acknowledgement packet is smaller than the node’s original packet and that it’s using the same data rate†, then a gateway that’s only responding to that one node could never exceed the 1% duty cycle either.
-
If the node sends once per hour, then in your example the gateway needs to transmit an acknowledgement once per hour too. If that message takes, say, 165 milliseconds, after which the gateway does not need to do anything for the next hour, then you could say its actual duty cycle is something like 165 / (60 × 60 × 1000) = 0.0046%. Still then, after sending for 165 ms, it needs to keep quiet for about 16 seconds if its maximum duty cycle is 1%.
So, the backends need to know when each gateway has sent last. If multiple backends give the gateways messages to send, then how can a backend know if a gateway is available?
† For the sake of completeness: in real life, TTN prefers RX2 with SF9, so may need more air time than the node. But it can also use a higher maximum duty cycle of 10% in RX2.
if a gateway sends once per hour for 1 second insn’t that 1/(60*60)=0.028% duty cycle? (only sending 1 second out of 3600)
But that is what I stated: duty-cycle is measured in time sending versus resting as opposed to messages sent versus messages received.
We are saying the same thing… the only difference is that I am totalising it per day (max 864 seconds of sending per 86400 seconds in a day)
The problem i am noticing is that if indeed a “restingperiod for sending” is enforced after each send (from the gateway) in your example 0,5 sec. sending should be followed by 49,5 sec. of silence from the gateway… we will have a problem relatively fast with OTAA -and other- messages queueing up (and if nodes are using their 10 downlinks per day even faster)… because after registering one node a gateway has to rest quiet a long time to be able to send the next… while maybe other times of day there is hardly traffic on the downlink…
You state it is not a daily total… i understand… it was just ment as an example to calculate the max-capacity for 1 channel over a day.
Question: if one gateway has downlink messages queued up are downlinkpackages then rerouted to an other gateway which is also in range of the node? (if the original package is received by multiple gateways) as a sort of relief to the first gateway?
You are correct when you ask the question “how can a backend know when a gateway ia available”… the other way around is also true: when using multiple backends on one gateway does not automaticaly imply duty-cycle will go over 1%. It could be solved by a “send-queue-maxedout-flag” in the gateway which would be sent to the backends to signal that for the comming 5 minutes (or another value depending on the send-queue-depthsetting) no sending will be possible.
I was just fixing that when you responded. 
And I explained a bit more in my edit above.
Indeed, see Activation not valid - no gateways available. Note that it cannot listen and send simultaneously either, so it’s good it has time to listen too.
Not re-routed, but TTN waits as long as possible before it tells a specific gateway to send a downlink. Like for a Join Accept, which is to be sent 5 or 6 seconds after receiving the Join Request, TTN will only send it to a gateway shortly before these 5 or 6 seconds expire.
I guess that’s true. But as long as gateways are just dumb forwarders, that doesn’t exist. And what benefit is there to have multiple backends try to control the same network?
so @htdvisser - how would i be able to distribute packets from my TTN gateway to another server from the TTN server?
we’re running a seperate statistics server in our community to monitor it’s usage in the area where all the (raspi based) easily can forward to - but it seems rather impossible to do with the TTNgw 
thanks,
markus.
1 Like