Hi @hmullerenersa. There are problems with cross-region routing. You should try and use the handler that is in the same region as your gateway. So use either:
ttn-handler-brazil and ttn-router-brazil
or
meshed-hander and meshed-router
Probably Brazil is a better match for you.
We have seen problems before where routing stops working, usually between meshed-router and asia-se-hander or eu-handler, but probably with any handler. The TTN Core team are aware of the issue, but it’s unlikely to get fixed, since V3 will probably address this.
Hi Andrew
What a pleasure to receive a response from you, yesterday I discovered that the meshed-router was located in Australia, physically speaking, and that there was a separate console for this router.
In my experience, I started using the handler in Australia, because here in Argentina we use the AU915 frequency plan.
On the other hand, I used the Brazilian router, ttn-router-brazil because until yesterday, I was the only one that offered me integrations with Cayenne and DataStorage, as I was using the standard TTN console (the only one I knew until yesterday), I didn’t see the integrations when choosing the router meshed-router.
Well, after knowing the existence of the alternative console (https://console.thethings.meshed.com.au/), I set option 2 and it is working!
My configuration, which worked correctly, was meshed-handler + ttn-router-brazil but on Sunday, August 4, it suddenly stopped routing.
Initially I thought I had been penalized by FUP, because as I am in the development phase, I may have exceeded the limits during the tests, but I also read a very interesting post from you that confirmed that there were no penalties currently or bans.
I take advantage of your knowledge to clarify a great doubt:
If my gateway and devices are working on AU915, can I choose any combination of handler + router, preferably from the same node, or should I choose how I did that of the meshed-router due to the assigned frequency plan?
Or put another way, when the gateway connects, does it download directives for the channels it must activate and deactivate, based on the frequency plan of the handler?
It is a great doubt that I have. If the frequency plan is only defined in the gateway or if it must be matched in the handler and router.
Thanks in advance, I hope my doubt has been understood.
No, depending on the software on the gateway it will use the local configuration file (global_conf.json usually) or it will download the channel plan based on the configuration (Frequency plan variable) you specified in the console.for the gateway. The frequencies used do not depend on the handler chosen.
Hi Jac
I currently use two Kerlink Gateways, one iBTS and one iFemtoCell. Both have the global_conf.json file with the AU915 frecuency plan.
I don´t understand that mechanism use, and what kind of gateway do this, to download frequency plan and from where is downloaded eventually. Can you give me some example to understand better this frequency plan update mechanism
So, then I can register my gateway on any handler with their correspondent router, based on the minor network transit time independently of the frequency plan used?
@hmullerenersa In El Salvador (Central Americas) We are giving the users the instruction to use the router with less network hops to reduce network latency. In our case the closer router is the US router.
In general the gateways only Forward packets to the cloud infraestructure, the frequency depends on two things:
global_config.js defines the frequencies that the Gateway operates both for Uplink and Downlink, the frequencies are globally defined by the LoRaWAN alliance for each region, and you should expect that they are not going to change soon.
The “Frecuency Plan” selected on the Gateway Configuration on The Things Network Console.
The region must match between this two settings and the end-nodes to be able to route packets. It doesn’t matter if the region used uses a different band-plan it is going to answer to the node with the frequencies applicable for the specified Frecuency Plan.
Because the answers for down-links are time-critical you should would want to use the region that is physically closer to your physical location.
We hope that some day we could have a back-end for Central Americas located in Guatemala or Panama because they are the two countries with better global connectivity, meanwhile we are instructing the local gateway owners to use US-WEST even if the region uses a different band-plan.
Kerlinks do not update the configuration so you need to make sure the configuration is right. Examples of gateways downloading the frequency plan are The Things Gateway (original), The Things Indoor Gateway (TTIG) and some Raspberry Pi based gateways. The source of the frequency plan is the account server.
Yes. Please do. Network delays should be as small as possible to prevent them interfering with the LoRaWAN timing.
The infrastructure is hosted in the azure cloud which does not support ping. Selecting the closest one geographically should work. See the suggestions of @hackerspacesv
As you can see on this map. For the Central Americas region it doesn’t make a lot of sense to connect to any other endpoint rather than the one located in the US.
Yes, I am a network specialist engineer, but that map (https://www.submarinecablemap.com/) corresponding to submarine optical cables, does not indicate anything about the route that the packets are going to take, this is defined at the logical level of routing and may not be the shortest path, nor the closest geographically.
From Argentina exist almost one direct path to europe for example https://www.submarinecablemap.com/#/submarine-cable/atlantis-2 …
Regarding that Azure does not support Pings, allow me to dissent, it is a matter of definition, any service in the cloud is configurable with respect to whether or not to accept ICMPs, at the virtual machine firewall level.
If by security definition, TTN servers have the response to ICMP blocked, this consists of a definition, not a limitation or imposition of Azure.
I will try to make a traceroute through auxiliary services to see which router is more convenient from Argentina, if I find a solution to the dilemma, I will update it here.
TTN uses load balancers in Azure which do not have ICMP enabled. I don’t know if that can be changed (and I don’t manage that infrastructure so I don’t care).
BTW, Azure has firewalls in front of VMs so enabling anything at VM level won’t help if you don’t configure the intermediate firewalls to allow the traffic as well.
An aproximmate tracert may be obtained using TCPTraceroute, https://www.websitepulse.com/tools/tcp-traceroute-test# This traceroute to port 80, without using ICMP, from 3 predefined sources (New York, Germany or Australia). With two traceroutes is posible to have an aproximation, i think…
Example: tracing from Australia to thethings.meshed.com.au 52.62.83.250, return 12mSeg, and it´s logical.
That’s really good for you! We are pretty locked to the US routes. Almost all ISPs route our traffic through Miami (Only God knows why). For us getting to Australia always implies taking several hops via US or South Americas.
@hackerspacesv 12mSeg is testing with the online TCPtraceroute tool “FROM AUSTRALIA” “TO AUSTRALIA”, is not the time from Argentina to Australia. I wish it was like that
Any issues currently with your TTN meshed forwarder? Our nodes are hitting our gateway and says its getting to meshed, but no MQTT output from TTN for the nodes since around 130am this morning.
We had the same issue about a week ago at about 240am in the morning, then the nodes started sending MQTT data that afternoon at aroun 330~4pm.
Same issue here. My devices last update was at same time as yours, 1.30 am Jan 9th. I’m in Melbourne.
You mentioned you are using meshed router (your gateways will connect to this) but is your application handler located elsewhere? I.E you are not using meshed handler for your app.
I was using Asia handler (ttn-handler-asia-se) for my app and figured forwarding from meshed router wasn’t working to Asia handler. I have other lora deployments (other applications) using meshed handler, and they were not effected. Hence my reasoning.
I tried a few apps with different handlers (not meshed) and all failed to show device updates. Could only get it working using meshed handler.
I moved my devices to a new application using meshed handler and restored comms and working now. A bit messy as to changing he handler deletes all devices, so must back up device details first.
There have been issues with cross region use of gateways and applications for a long time and in V2 of the TTN stack those issues will not be solved. The official statement from TTN is to use an application using the same region (handler) the gateways use to avoid issues.
