I haven’t been able to get a positive confirmation from the different TTN, Semtech, and LoraAlliance docs, so I’d appreciate any pointers:
Do gateways route all LoRaWAN valid CRC packets to back-end (Network & Join Servers)?
Here is some context to clarify the reason for this question:
There are many LoRa implementations in San Francisco that could add load on the gateways: would a TTN gateway route all Loriot, Helium, Senetco, MachineQ, Sigfox, etc, valid CRC packets to the TTN Network and/or Join servers?
Short answer is yes. The NS will determine if it is a packet it can/should handle. In the case of some roaming or message exchange systems e.g. PacketBroker there may also be a decision to not handle a message directly in the NS associated with the receiving GW but rather to pass on to a known alternate ‘home’ network, otherwise message will simply be dropped. Some networks, including TTN, not only allow for use of own Net ID allocated dev adders but may also handle so called experimental nodes… nodes with Dev address starting 00… or 01…
GWs are supposed to just be transparent message handlers simply passing on any received messages, with some additional metadata tagged on…
They route all the valid CRC packets they receive.
However, receiving a packet requires both triggering the preamble sync word detector in order to assign a decoder, and then the decoder finding the rest of a packet that ends with a valid CRC.
Sigfox isn’t LoRa modulation at all.
As for those that are, it would depend on the settings these use. If they use the LoRaWAN public network sync preamble and the 2nd US 915 uplink band, then a TTN gateway would receive almost all in-range packets and report them up the backhaul.
But if they use the private preamble sync word (or some other sufficiently distinct pattern), the majority of the packets will never trigger the gateway’s “might be a packet” detector, and so will be ignored. A few will manage to trigger it despite the mismatch and those will get reported up.
Different sources have given conflicting guidance if the public sync word is only for public LoRaWAN networks, or if it is for LoRaWAN networks vs other LoRa network schemes.
Thanks much!
Is there a way to make sure that no one else is using a private preamble sync word? (i.e. is there a central repository of private preamble sync words, similar to IEEE Registration Authority controlling OUIs?)
No, that’s not workable, because there are relatively few patterns that would actually be distinct enough to be useful. Sync words don’t prevent on-air conflict, they’re just a crude means to optimize the decoder pool’s attention and backhaul bandwith anyway.
What you can maybe do in an (OFF TOPIC) private network context is potentially do device address prefix filtering if you have only OTAA devices. That’s not workable in TTN because people can register ABP devices with device addresses assigned outside of TTN’s unique address space block.
TTN gateways must submit all packets they receive, only the servers can decide which are TTN packets, so filtering is off topic on this forum.