First of all sorry if I ask a very dumb question…
I just installed my first LoRa gatway. Its a Mikrotik wAP8 and its located in Germany.
Its working and I’m very happy with it.
However,
the gateway received about 15 packets in the last 6 hours and all of them was dropped because there were no broker associated to them,
I received an interesting packet with the network id NNNCo (0x19)… I do not think that this packet came from Australia…
Can anyone please answer these questions:
Is it possible to join other networks simultaneously with the Mikrotik wAP8? Is it a good idea?
How come that I can see such NNNCo transmissions in Europe? Isn’t it regulated?
No & no, gateways can only connect to one network server.
A gateway is merely a conduit between radio waves and the LoRaWAN, which leads to
anyone can transmit any form of data packet, so this may be just LoRa which will mostly fail CRC or it may be someone who made up some id’s because they don’t know better.*
In theory the use of EUI’s is regulated but it’s not particularly the law - you buy a block of EUI’s but how you’d stop someone hijacking some I have no idea without involving The Terminator or similar.
Clearly you are very happy with your gateway, the ‘watching uplinks’ effects wear off in a few days.
There could be evil intent here, but as per Hanlon’s razor, “Never attribute to malice that which can be adequately explained by stupidity”
at step 7 you can define multiple servers… (My gateway already had 2 servers preinstalled.)
at step 9 you can select multiple Network Servers…
Or maybe, MikroTik implemented the protocol wrongly…
My initial idea was that I add a few servers to this gateway and by that I could then forward the received packets to multiple Network Servers (even to my future ChirpServer)…
Give it a try then - it may be that the GUI supports something that was never implemented - or they were ahead of the game, so don’t try it too hard until someone else chimes in - it’s just I’ve not seen any packet_forwarders or gateways do this - not to say that it can’t. Mr Google doesn’t find any results on doing this either.
As for the two entries as shipped, I’d not be clear how they work as they use different frequency plans.
Also note that MikroTik by default logs (and forwards, it seemed) packets with invalid CRCs. Because LoRa can decode packets below the noise floor it also hears slightly valid looking packets in the noise, but the CRC check filters nearly all of them out.
There is an option in the config to exclude the CRC failed packets, from memory, or at least not to list them in the traffic logs (sorry, I forgot which). I would suggest turning that on, it’s an odd decision by Mikrotik to have that option at all, let alone turned off.
Enjoy your gateway. I particularly enjoy watching unknown devices on SF12 slowly recognize my gateway is giving better coverage and fall down to lower (faster) SFs.
This sort of speculation is neither accurate nor helpful.
There are in fact many existing threads here about the possibilities and issues in a gateway connecting to multiple network servers, and much of the point of the “poly packet forwarder” is to do exactly that.
However, as extensively covered here previously, while it is easy to report uplinks to multiple network servers, there’s no very easy way for one network server to know when another has already commanded a gateway to transmit at a particular time, or to know how much of the gateways airtime budget (where applicable) has been consumed. Because current protocols for communication between a gateway and a network server don’t really support a “reject” there’s no way for a network server to instead assign a downlink to a 2nd best choice gateway… and with only 1 second RX1 delay, there’s not a lot of time to work all of that out.
Currently the incumbent idea is the “packet broker” where servers will cooperate in sorting some of this out between themselves; personally I think using a more reasonable RX1 delay and implementing a “decline” and even an advance “no downlinks right now” on submitted uplinks may be a better path… but that’s another topic…
With no deconfliction between network servers, things work reasonably well with light loads but not when traffic gets busy; in that situation a gateway dropping assigned transmit requests due to time and or allotment conflict ends up being a denial of service if there was another -gateway to which the transmission could have been assigned (and the actual air signals would not interfere - something that is possible but far from certain with a diversity of downlink channels and spreading factors)
Once more, not sure which bit exactly in the quoted paragraph you are referring to. Not implemented, preparing for the future or any systems ACTUALLY do this?
Definitely more practical than a link to “possibilities” which gets expanded out in to the pitfalls of why it isn’t really a thing - the OP’s original question seemed rather implementation focused.
And Mr Google, to be more specific, yields no actual results on having two network servers working for the MikroTik - just the info on the product support that you can enter two or more and how it is setup when shipped - no obvious reports of having this running.
NNNCo is a commercial LoRaWAN operator (like Actility, Loriot, Orbiwise, etc.) and has a global NetID registered just like TTN:
0x32/0x33 World: NNNCo (0x19)
Their background is providing services to public utilities in Australia and they are actively extending this to business in Europe. Seeing this traffic is perfectly normal.
Once again, you’re not only making false claims about a subject on which you are obviously uninformed, but doubling down on the error even after being confronted with the truth.
Gateways reporting to multiple network servers “is a thing” It also has the issues explained above, and again as explained above, it is something that has been discussed here at length in the past, including by people who are actually doing it.
In addition to general study and debugging, another non-problematic reason to do it would be to run a second decode-only server to make sure that you get the data from your nodes that arrives at your own gateways, even if TTN’s servers are down.
The MikroTik gateway can probably forward to multiple backends, however doing so with multiple backends that might want to transmit is a very bad idea that TTN discourages. So please don’t. If you want to know why read @cslorabox’s message or search the forum for the existing topics on the subject.
The microtik gateway can forward to multiple servers with no problem. Because of dutycycle restrictions by the regulator only one server can account for it. 2 or more servers do not know of each others dutycycle house keeping an may result in a gateway that violates the dutycycle constraints.
Technically and from a regulatory point of view this is true however in practice, with low number of downlink packets the probability is low.
This is the reason why TTN discourages this.
