You should keep an eye of the drawbacks for the community as @Jeff-UK has mentioned.
I have already used a mobile gateway for demonstration purpose or for reliable joining otaa devices after service (battery replacement) in areas with bad coverage.
1 Like
A mobile GW can be useful for helping track down a rogue node that is disrupting the network, esp if triangulating with a number of fix location GW’s - but that is a rare exception/use-case to normal Community deployment. Go private if you want to go mobile as @wolfp mentions. You can also get GW’s with NS and even basic AS embedded so a closed Private LoRaWAN deployment that can be mobile and not impact anyone else - just the kind of system I use when doing demoes or coverage tests for clients… I just dont hook it up to TTN 
2 Likes
I have problems with “rogue” stationary gateways which do not forward downlinks.
Any device in range is not able to join near these gateways.
Messing the owner does not succeeded. So i use my mobile Gateway or leave TTN completely.
Perhaps the second one is the better choice.
So a rogue GW is disrupting your experience with TTN, and your solution is to add more disrupting solutions? …Or you leave?!
How about you work with the community and the ‘rogue’ GW user to identify the problem and fix it?
I had a problem with a ‘rogue’ GW a couple of years back - basically a beligerant user deployed a SCPF and insisted on keeping it up vs taking down and replacing it with a real LoRaWAN GW. Solution was working with local clients (inc the local council!) surround it with 3 full cheap GW’s and rendering its feed into TTN irrelevant c/w to the feed from the 3. Eventually the SCPF was turned off and the spacing of the 3 widened out slightly to provide additional, now redundant, coverge for the local community…
I would suspect that in your case the Rogue GW may well be a SCPF also as behaviour (not passing on DL’s) also occurs with them. Can you disclose more on the location and GWs in area - sadly with V2 now RO and much of the user and noc data inaccessible or simply not available nailing such issues is harder, but can be done. It sounds like you know who the user/GW owner is?
No it is not a SCPF.
The owner, in two different cases, are local public utility companys.
One Gateway was taken offline. A month after i have stopped my engagement near this City (Porta Westfalica).
The second one is eui-00007076ff030f66 and is located were the Stadtwerke Schaumburg Lippe has a site.
Both did not respond on e-mail nor was i able to get a responsible person on phone on multiple attempts.
I suppose they use gateways with semtech udp packet forwarder behind a corporate firewall without port 1700 mapped.
I can see the Buckeburg M-Station GW mapped as a V2 GW, not yet on V3 so using port 1700 yes I would expect, however, corp firewall or not blocking would mean it didnt work for up or down links so that isnt the issue. I can see that it has had some mapping activity so obviously operational and last hear time is this evening so currently active. If it isnt handling Downlinks correctly then it may be they have none compliant nodes on V2 that dont rely on DL’s (Joins, MAC Commands etc.) but likely they will then ‘come a cropper’ as we say in the V2 sunset and with V3 transition. The other possibility if missing DL is an intermittent problem is the GW may be servicing lots of high demand/high maintenance nodes - lots of traffic or confirmed uplinks such that the GW keeps running out of duty cycle air time (GW’s have legal limits just as do nodes) and if GW has exhausted downlink Tx time then best will in the world it can’t Tx and may end up denying you a DL - that would not make it a ‘Rogue’ GW just an exhausted one! - in that case best option would be another GW in reasonably close proximity to densify the network and burden share.
I will try to find a way to identify the user owner of the GW…as volunteers we Mods do not have direct access to TTN account info…
I can see why you ref
certainly the signal strength/likely use of SF7 concentrated close to there but also I see adjacent to the M-Bahnhof Parkplatz - do you know if they have parking space sensors there? Would account for a high volume of traffic and potential capacity issues…if space count updates too frequently data may colllide of get missed but will likely catch up quickly enough for the parking application to catch up and give close enough to real time data but an external device, especially one just passing by, may get starved of a message and be more noticeable!
Also given the historic links between TTN & DBahn/LoRaWAN prototyping development, having a GW servicing the station/surroundings would not be a suprise… Sadly with v2 RO & Noc changes can no longer see owner directly…
Calling @KrishnaIyerEaswaran2 @htdvisser or @laurens I was hoping to use account.thethingsnetwork.org/api etc as a mechanism to check for user/owner of GW eui-00007076ff030f66 located in Buckeburg however I get “code 404” and ““Gateway with ID eui-0000…ff030f66 does not exist””
even though it looks to be live on both the Community Map and on TTN Mapper … hoping to check the Owner ID and Username fields so we can reach out to them as above… can you advise?
@engelking I assume the other GW you reference above was eui-00007076ff030276 ?
I see that was located around Stadtewerk Porta Westfalica and TTN Mapper indicates last seen early July - perhaps matching your timeline and it has similar MAC structure/EUI to the one you call out suggesting same manufacturer/model?
TTI Core team that one also does not show in the account.thethings… api tool and may help us triangulate user(s) and cause of problem?
If the API returns a 404 for a gateway, it’s not registered. In V2 it was possible to connect a gateway without registering it; we don’t allow that anymore in V3. So I’m afraid there’s not much we can do here to help.
Ah yes. Hopefully problem will resolve with V2 sunset unless gw routing continues, if as likely they are using UDP. Guess they must only have registered nodes…
Guess only way to get a response is if they happen to read the forum or if you temporarily block/drop traffic from that gw forcing them to investigate, but then that would breach TTN Manifesto?!
Another option would be to look at a sample of receiving nodes/applications that use that gw and identify likely owners from node registration data?
If we’re bringing the TTN Manifesto into this, let me quote part of the last bullet point (emphasis mine):
- Anyone making use of the network is allowed to do so for any reason or cause, possibly limited by local law, fully at own risk and realizing that services are provided “as is” and may be terminated for any reason at any moment.
All of The Things Network is “best effort”, so nobody is entitled to uplink or downlink capacity on any gateway. Some gateways located at good locations receive a lot of uplinks, but they are still limited by their downlink capacity (and downlink duty cycle). I don’t know if this is the case here, but it’s possible.
It’s also possible that downlink on this particular gateway is broken. If we can prove that this is the case (I don’t know how; perhaps the community could come up with some kind of standardized test for this), we could disable downlink on a gateway. However, disabling downlink on specific gateways is currently only possible in V3, which won’t work now since this particular gateway seems to connect to V2.
Also: V2 gateways not sending downlinks for V3 devices should typically not be too big of a problem. A V3 network will always prefer sending downlinks to gateways on the same V3 network. It will only send the downlink via the gateway on V2 (through Packet Broker) if there is no other option. So if this area is covered by V3 gateways, those will be preferred for downlink anyway.
@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…