Hello together,
i’m new to TTN and want to know if it’s possible to reboot a Gateway remote from TTN ?
Or if there is any management feature for gateways in the business editions from TTN only ?
Thx for answersc.
Steffen
Remote gateway management does not have a standard LoRa Alliance Specification yet. So this is entirely dependent on the APIs provided by each individual gateway manufacturer.
At the moment, The Things Stack does not have native support for Remote gateway management.
But based on demand and gateway support, we can look into it.
Thanks for your answer.
Does that mean, when we would have an subscription plan with support, we could get a feature for remote support of gateways in the future ?
Yes, when we implement it, Gateway Management will be a proprietary feature and will require an enterprise subscription or license.
I think it would be a killer feature for all enterprise users.
Is it possible to move gateways and sensors from the community edition to the enterprise solution and are the gateways in the enterprise solution still accessible for everyone in the community, or are they completely isolated ?
Rather than ‘in band’ control through e.g. TTN, many GW’s especially those targeted at eneterprise or telecoms like deployment have provision for side channel/out of band management - after all they are usually connected over a standard internet link supporting tcp-ip, http, https or what ever and offer some level of remote management. You need to look at the gw’s you are considering and read doc’s/manuals to assess capabilities. as Krishna says no specific LA spec yet - and given other bodies cover the topics of internet device security, remote management etc., woudl you want L-A diverting attention and attempting to dable in an area outside scope (and expertise at scale?). I know some have introduced e.g. TR-069 capabilities (Laird?) and other more full function remote management/control/connectivity implementations. Heck even the humble Raspberry Pi based systems come with a VPN solution (VNC) pre-installed! And others can quickly and easily be installed (OpenVPN, Wireguard etc.) 
→ Terminal/Command window - > 'sudo shutdown -r < now> ’ for the win!
Also I think some of the GW/fleet management/deployment tools allow for remote updates/management/control (e.g. Balena? IIRC)
Hi Jeff, thx for your reply.
We are considering in building up our LoRa Environment based on TTN, but not sure which way to start with. Community based for the first steps or go all in for the enterprise solution.
As i mentioned above, it’s importand for me to unterstand if it’s possible to move gateways and sensors from the community edition to the enterprise solution and are the gateways in the enterprise solution still accessible for everyone in the community, or are they completely isolated ?
If you are commercial, test things out on a Discovery instance - TTN is for community use and whilst it’s very robust, it doesn’t have an SLA, it is community support from volunteers only here and once you get to about 20/30 devices and you have a user name as you do, then @rish1 will talk to you about a proper setup.
As for moving gateways, that’s simple enough, TTI have a whole suite of tools to move things over for those that were learning about LoRaWAN and need to do it for clients. And very definitely yes, you can set gateways on a TTI instance to share with TTN.
Your very best route to explore would be to put a couple of gateways & devices on to TTN and register for a Discovery instance (free) and put a gateway (you can only have one on the free TTI tier) and a couple of devices on that. And then explore. The CLI will be your friend.
As for remote management of gateways, what do you anticipate needing to do - they are a relatively closed system that once setup don’t need much looking after. If you are anticipating power issues it would be worth looking at solutions to sustain power during outages. At worst having a “descartes special” device that acts as a gateway canary and can figure out if a power cycle is required and/or be told to power cycle the gateway or the backhaul is somewhere in the bottom of my toolbox.
1 Like
Clearly you are going down the commercial use case route which (at scale) would take you outside the current/emerging Community use case and charter so best to talk to @rish1 and the TTI Core team. Selfishly as a Community user and provider of shared infrastructure (~50 GW’s under my own account + ~150 other through friends, colleagues, clients and collaborators) I would always encourage atleast some Community use and contribution perhaps start and test using TTS(CE) - TTN Community deployment - then scale out to a private instance. Even with your private instance I would then also always encourage companies to peer with the Community network - will help you fill gaps in your network and gives something back to the Community. Example case in point in UK would be e.g. the Berkshire/Reading Council deployments (120+ GW’s & counting) which peers and provides Community coverage, or say Norfolk & Suffolk County Councils, Gwynnedd, Pembrokshire etc. If unwilling to peer all gw’s I believe this can be done selectively so perhaps ‘decimate’ your network - allow 10% (pref more (20%, 25%, 50%?!) to peer.
I get the sense this chap is willing - but this does raise the potential for a planning tool such that basic gateway coverage is made up of non-peered gateways supplemented with gateways on community or peered so that any one device has at least two gateways in range (even if it has to run though fallback of DR to get there).
Thank you very much for the responses !
I think we start with the community thing and make the step mid term to TTI.
Thx!
I get the impression from the questions that you’ve not done too much with TTN and by inference, LoRaWAN. The onion layers go down so far I’ve both lost count and at least once a month I get reminded by some technical wrinkle that someone spots that I’ve yet to see the centre. All of a sudden a whole pile of “meh” from a previous project has to be re-classified as me shooting myself in the foot.
Remote management of gateways isn’t a thing for me. If it’s running off robust Flash (ie not a Pi SD Card) and plugged in to a reasonable backhaul, it just keeps on going. It may be for @Jeff-UK, but as he likes to scatter them around the UK, like 3+ hours drive away, but yet he rarely ventures up north to see me, he seems to get by without it.
The typical challenge for gateways is device coverage - so easy to deploy two gateways and then find there are some dead patches that need some in-fill units.
So I’d very strongly recommend going through all the Learning materials the TTN provide and get some kit up & running so you have some context to all of this.
As long as you are aware that mid-term in the community perspective if pretty much 50 or more paying devices. And that if you face an issue with a few hundred that have come unglued, we’ll try to help but it’s all best endeavours here.
If you have a serious business model, there now appears to be a 1,000 device with support option for €300/month - direct support more than covers the costs of developer downtime whilst “stuff” gets figured out. Particularly if you need to do something cute in bulk and your are wielding the precision axe that is the CLI!
Dont worry - should be up to see you ‘soon’! (more threat than promise I guess!)
This:
:+1 (Though I’m not too concerned wrt Pi SD cards as the handful of failures over the years have almost always come back to unscheduled power issues so to your advice I would add:
…and plugged in to a reasonable backhaul and resilient power sources, it just…)
Absolutely - Densification for the win! In the early days with $1000+ GW’s costs for coverage were high but no excuse to not densify straight off these days - 2 decent GW’s in an area with maybe 1,2,3 very low cost infill devices wins out and gives great redundancy…and additional capacity in the face of e.g. downlinks causing capacity problems
For me its important to know if there are some easy to handle migration tools, to migrate gateways and applications from TTN (Community) to TTI (Enterprise Solution, Cloud Based by TTI) or do i have the problem that i have to start completely new with all the stuff. eg. reset all sensors to join the new network an so on.
At the moment we have about 2 Gateways and 40 Sensors Nodes in the city for evaluation, the LNS Server is hosted from an commercial partner of us.
But we want to make the move to TTN / TTI.
I have no Problem at the actual state to config all the stuff new. But when we have about 30 Gateways and 200 Sensor Nodes configured in TTN Community for example and there ist no possibility to migrate them to TTI, that would be…not so good
(Full disclosure; I’m part of the core team at The Things Industries)
The Things Stack Community Edition and The Things Stack Cloud (enterprise) are indeed different networks, moving between which requires migration.
Migration of sensors/gateways can be anywhere from very easy to impossible dependent on the choice of sensors and gateways.
We have over 3 years of experience in migration of production devices/gateways and it’s often not pretty.
If you do plan on a future migration, the difficult part is the End Devices.
I would recommend having devices that do a “link check” and trigger a rejoin procedure after X failed checks. The best case for sensors is if a rejoin can be triggered via a downlink. This will vastly reduce the migration time and loss of data.
For Gateways, I would highly recommend ones that can be remotely accessible (even if on an individual basis). However, data received by gateways connected to The Things Stack Community Edition can be forwarded to The Things Stack Cloud via the Packet Broker. This offers you a lot of flexibility in migrating your gateways but this also might create latency since the data has to travel multiple extra hops before reaching the target Network Server/Application Server.
If you already have plans to scale your network and/or need an enterprise quality of service, I’d recommend already starting with The Things Stack Cloud.
We have a free discovery tier that allows 1 gateway and 10 devices I think.
Based on the situation, our sales guys would also be happy to extend the discovery to allow a few extra devices/gateways for evaluation.
I’d recommend reaching out to our sales team (sales@thethingsindustries.com) who can suggest your next steps based on the situation.
@hdh-smartcitymanagem Given ambition may be best - but please dont forget the Community (and your corporate ESG goals!) and do
In reverse - with your GW’s helping the Community by routing via PacketBroker from your LNS implementation to TTS(CE) so all can benefit (the Community often is less concerned by an extra hop and a few mS latency c/w the overall benefit of extra coverage)
Remember it also ALL started with the Community and the vast pool of knowedge and experience that is available to you through the Community Forum (use Forum search!) and its users/volunteers and that usually makes it to the top of any Google (insert your favourite SE here!) search only exists because we have deployed, shared and got our mutual fingers burnt along the way! 
Please share back!..
2 Likes
Copy & pasta from messages, yay!
Don’t know how often @KrishnaIyerEaswaran2’s moved stuff but with some preparation & practise the CLI hits the spot for me.
I’ve moved a few thousand devices that had proper LinkCheck on from v2 to v3 and everything that was running on v2 came back plus a few presumed dead devices.
And moving devices with session works just fine.
It’s not an activity for the faint hearted and those that try without running some tests and scripting usually end up with challenges - which is good for my wallet if they want the problem to go away, assuming the conditions are in fact fixable without going round cycling the power on each device.
If you don’t know the details of the LoRaWAN specifications & the various revisions of regional parameters well enough to find the detail that’s causing a hold up in processing a transfer it will be a very very shallow learning curve. So starting out in the right place would be a good idea.
Thank you all for your respones, that helped me allot !!!
Thread can be closed