Metadata Gateway

Hello, I want to know if it is possible to access through MQTT the data that the keep alive of the gateway sends, I am interested in the gps data, since it is a mobile gateway.


1 Like

Please don’t connect mobile gateways to TTN.

They cause terrible issues with the automatic adjustment of data rates, since nodes which move to faster shorter range modes can take hours to days to fall back to longer range modes when that gateway moves out of ideal range.

Unfortunately, TTN doesn’t have any way to accept “random contributions” from a LoRaWan gateway, without assuming that said gateway will remain in operation at the same location.

When movement (or even de-activation) of the gateway makes that assumption invalid, performance of the communicate network seriously suffers.

Thanks for your answer, first I use a the things stack, lorawan private server, second that the nodes move with the gateway, I cannot give more details since it is a private product.
So is there a way to access the metadata of the gateway?

That kind of stretches the mission of this forum…

@kapotik no you have to use GW server for that via web API

But having GW meta data via MQTT would be very nice to have

Sorry Chris but no option other than to do that especially when trialing different potential deployment sites around a given area or if doing location surveys - by definition the GW’s then become mobile as they change location - sometime may change 2/3 times in a day or may get deployed for months on end to test under different load conditions & check local environment - also some Solar GW’s may need different placements to optimise sun supply and test over seasons before changing - but still effectively then ‘mobile’! :slight_smile: I often get called in by Systems Integrators or potential end users (Local/County Councils, business park owners, university campuses, industrial sites etc.) to carry out a few days, weeks or months of LoRa/LoRaWAN surveying & trials - will often deploy a fully integrated ‘box’ to act as combined GW/NS/APPS etc. but most often will hook up to TTN to demonstate value of TTN and/or TTI and try to get client to consider adding their infrastructure to benefit the community longer term vs just staying private :slight_smile: Sorry but these are then temporary/moble deployments…I also typically add a disclaimer in TTN Console description that location may change and not get (quickly) updated in the Console if its is temporary or mobile if someone checks out the GW after say a TTN Mapper session.

There are also use cases for mobile/lone workers/small teams where they may travel to area swithout a GW - by equiping their vehicle with a (by definition) mobile GW they can take coverage with them when they then wander off for say forestry, agritech or dam inspection work etc.

I am simply asking how to extract the metadata of the gateway from the stack of things, I do not see that it is breaking any rules here

There are definitely use cases for mobile gateways. In fact, we’re already seeing production deployments with gateways on ships, trains and even satellites. We have an open issue about ignoring mobile gateways in the ADR algorithm: Data pushed by mobile gateways should be excluded from the ADR algorithm · Issue #545 · TheThingsNetwork/lorawan-stack · GitHub, and with that we don’t have to worry so much about mobile gateways potentially messing with network performance.

To answer the original question: If your gateway uses an authenticated connection and sends location updates in status messages, The Things Stack will store the latest location in the database. Furthermore, if you set the location of your gateway to “public”, it will be added to the metadata of each uplink message.

You can not use MQTT to subscribe to location updates specifically.

1 Like

I understand, but I depend on the time in which the end node transmits to update the position, that is why I wanted to access the metadata of the gateway, since it sends its keep alive more often

This is also valid for The things Industries, private lorawan server?

This will, when implemented, land in all The Things Stack editions and deployments.

So what solution will be given to gateways located for example on a ship? Will they be rejected by the server? Or will they just not update their position but if they will continue to upload messages from the end nodes? Could you please clarify this for me.

This particular issue is about marking a gateway as “unreliable for ADR”. That doesn’t mean uplinks will get rejected, or downlinks will not be scheduled on this gateway. Just that the signal quality reported by this gateway will not be used to optimize the data rate of end devices around it. This will mostly be useful in public networks. Since you already indicated that you’re using a private server, you can decide for yourself if it makes sense for you.

If we’re considering the example having a gateway on a ship, connected to a private network server, with end devices measuring shipping containers or something, it does in fact make sense to enable ADR, because those end devices may be on the ship for hours/days/weeks, and you’d want them to optimize their data rates. So in this case, you wouldn’t use that “unreliable for ADR” indicator.

If we’re considering @Jeff-UK’s example, with a gateway connected to a public network, that is only at a given location for a short time, it doesn’t make a lot of sense to try optimizing the data rate of end devices around it. In this case you would set that “unreliable for ADR” indicator.


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.