@engelking perhaps that is your solution - I see you have V3 GW’s already and everyone should be in process of moving nodes to V3 anyhow so just add a pop up/new V3 GW in reasonable proximity to the problem GW and preference above will cut in and solve problem… 
One possibility would be to have instances of gateway hardware in the vehicle that weren’t actually connected to TTN, but rather fed a packet recording system and a parallel decode path for your nodes (you’d have to extract the node secrets from TTN to do your own decoding).
That way your nodes - and more importantly everyone else’s - tailor their behavior to the actual fixed TTN network, but if you happen to drive by and catch a packet from something that’s out of normal range, great, you get that too.
Just understand you can’t ever transmit towards the nodes from this alternate setup.
For the most part, notwithstanding, and positively with regards to the TTN Community such versatile GW’s as in dynamic while moving are debilitate as they are conceivably problematic to different clients. Best practice for (particularly static) hubs is to enabe ADR - the sign strength information for that can be purturbed by portable GW’s making the NS think the hub unexpectedly is in scope of a more grounded GW than typical, driving hub to change conduct, then, at that point causing signal loses when GW continues on or also a GW will report a deminishing sign which again makes NS change Node conduct to redress - consuming battery and diminishing field life.
Thanks
Aakil \working at Mr.furniture www . mr furniture . ae
Best use of a jargon generator I’ve seen in a long time.
Well done.
Naturally I’ve edited out the link to furniture in Dubai and suspended your account.
Expanding on this concept, what if we use a stationary gateway as a kind of middleman between the mobile gateway and TTN?
The mobile gateway act as a simple packet forwarder and would collect data and forward it to the stationary gateway via a secure data connection. This stationary gateway would then handle the transmission to the network server.
The potential ADR adjustment issues caused by the mobile gateway might be eliminated by implementing this approach.
Thanks
You still end up with the exact same effect, except rather than appearing to be in one place, the apparent location of the device shifts to where ever the stationary gateway is.
Assuming you can hack the code for a packet forwarder to be able to do that.
The simplest solution is to not use TTN but your own instance on TTI with gateways that aren’t peered via packet broker.
1 Like
In some ways it is interesting to revisit this in the context of avoiding disruption to a public netwok (mobile networks suprisingly common on private deployments (and you also have to plan carefully for is it mobile, as in moving, or mobile, as in relocatable (frequently?) - wont go into details here as focus of this forum is TTN - a public/community network where not always appropriate). 2-4+ years back the use case would be problematic for reasons previously explored but now you might consider, rather than a full mobile gateway, the use of a LoRaWAN relay under the released L-A specification and reflecting the recent emergence of devices in the market that provide for this functionality. Why might this work on a public network? - simply put white listing. The user would deploy the relay and part of the operation mode of such a device is the concept of ‘authorised’ and whitelisted ‘relayed’ end nodes that can communicate through and be responded to by the Relay. Any community or other public device not so ‘approved’ would be ignored and not communicated with thereby avoiding the previous network purterbation that was a major concern. For the Relay user their use case is potentially satisfied whilst for the rest of the community the Relay might as well not exist! 
1 Like
So you send from a device to another device to a gateway? You may as well white list traffic on the mobile gateway!
If the target LNS is TTN, then the prime question is how is this a community implementation? Because if it isn’t, then it is highly likely commercial and shouldn’t be on TTN.
A gateway owner has no way of knowing what is valid TTN (or TTI partner) traffic and what, even if rejected from TTN perspective, might actually be considered valid traffic through PacketBroker and/or peering arrangements. Hence we ask, and indeed require under the manifesto, that all traffic be treated ‘equally’ and that Community GW owners make no attempt to white-list. Relays the other hand are not Gateways, they are not ‘open’ in the classic sense and indeed might be considered to be closed to other none relayed traffic.
Who knows and it is not for your or me to guess, there are many clever people out there and the way they get creative and how they come to utilise LoRa/LoRaWAN continues to suprise, and sometimes even amaze, me even after some 11/12 years working with the technology!
Again we wont know and whilst I appreciate your embrace of the ‘non-commercial’ enforcer role its not for us to pre-judge or shut down on an assumption. Relay is not about supporting large volumes of nodes, (which a GW might) which is why I think it may be interesting as alternate to moving/mobile GW as then more likely still a fit with the low volume experimental (yes even Sandbox!?) aspect: (Quote)
Experiment and explore with The Things Network
Get hands-on experience with LoRaWAN®
Support your local IoT/LoRaWAN community...
etc....
I haven’t got seriously dirty with Relay as yet (I know you have looked at some implementations) so not in a position to say it can or cant work at this point, just keeping an open mind…
. 
.
1 Like