Hello everyone, I am currently working on a solution for locating animals. Now it occurred to me that to complement stationary gateways I should also use mobile gateways that are located in the vehicle. The simple question is whether there is already any experience with this. Unfortunately, I have not yet found anything on this. Any hint is welcome 
When you say ‘lora’ gateways, do you mean LoRaWAN\TTN gateways ?
Perhaps you can take a closer look at the Mikrotik LtAP Lora Kits.
Very sturdy device and already prepared for powering from automative powersources.
Uplink can be realized with LTE.
1 Like
By mobile do you mean relocatable or GW’s that are providing service whilst vehicle (train, truck, car etc.) moving.
Relocatable is generally ok - you have to be able to set up test gw’s check coverage then reposition to optimise if needed - prefereably deploying for extended periods of time each time (think weeks & months).
In isolation - say on a container ship or cruise liner - were GW(s) servicing the then local traffic associated with that large vessel, again considered ok - indeed Marine IoT is an emerging category for the industry and has been much discussed on the Forum esp in context of 2.4Ghz LoRa/LoRaWAN
Some private networks use mobile/on vehicle gw’s e.g for the rail industry - again servicing local on vehicle traffic or helping to capture trackside data whilst in transition and assisting in very remote area.
Generally, however, and certainly in the context of the TTN Community such mobile GW’s as in active whilst in motion are discouraged as they are potentially disruptive to other users. Best practice for (especially static) nodes is to enabe ADR - the signal strength data for that can be purturbed by mobile GW’s making the NS think the node suddenly is in range of a stronger GW than normal, forcing node to change behaviour, then causing signal loses when GW moves on or similarly a GW will report a deminishing sign which again causes NS to change Node behaviour to compensate - burning battery and reducing field life. So whilst Mobile is valid in a priviate network where such behaviour is understood in the context of the Community network they are highly discouraged for obvious resaons…
Indeed that is common for Mobile and relocatable offerings, but again remember that if GW is mobile it may be going in and out of bachaul coverage areas, switching between cells etc and so highly likely to drop packets or miss sending downlinks etc that then becomes disruptive to the community as above - do not use mobile GW’s on the community (please!)
Almost any GW can be used not just a Mikrotik or other unit with cell access embedded - just tether GW to a mobile wifi/MiFi type device e.g. over WIfi - if GW is in benign envornment it doesnt even need to be outdoor rated, just with possible external antenna…
Remote workers - e.g. Forestry, large scale remote agriculture, or slow moving/temporary construction industries (think motorway builds/refurbs, skyscraper builds etc.) also likely to consider a relocatable/temporary (vs actually mobile) GW to service local needs as projects develop.
Missing cellcoverage of one provider is an advantage of the mentioned device. You are able to use three different simcards to optimize uplink availability.
1 Like
I use a gateway Dragino LIG16 as a mobile device. But in fact it doesn’t work as a gateway because its not connected to any server. I use it as a LoRa-receiver to detect what is going on around me and to receive signals of other nodes. With a Mini-Circuits ZAPD-21 Coupler (power splitter) it uses the same antenna as my node.
Thanks a lot! A LtAP LR8 LTE Kit is already on my Desktop, and I was even able to make a first set up (based on my local Wifi,). I was (or am) simply still unsure whether I can actually use the device as a “driving” network extension, as intended. So, before “just trying” I assume its good to receive communities feedback.
Wow! so many answers in such a short time first of all thanks to all! If I may summarize it briefly: in principle it should work, but mobile gateways probably interfere with the reception logic of other participants (keyword ADR). Is this correct? Would a proprietary network be a solution?I don’t want to bother you with all the details of “my cat tracking”, just this: use case is the following: To increase the chances that a node located at a cat can deliver its collected position information, “randomly” passing parcel carriers, delivery services, enthusiasts etc. should be able to receive it. In addition, status information should be able to be sent to these Nodes.
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.