# Application and gateway region selection **URL:** \ **Category:** TTN Network and Services\ **Created:** [May 30, 2018, 2:06am UTC](https://www.thethingsnetwork.org/forum/t/application-and-gateway-region-selection/14654 "2018-05-30T02:06:07Z")\ **Posts on this page:** 1\ **Showing post:** 5
**Author:** ![johan](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/johan/32/45177_2.png) [@johan](https://www.thethingsnetwork.org/forum/u/johan)\ **Post date:** [December 22, 2021, 8:33am UTC](https://www.thethingsnetwork.org/forum/t/application-and-gateway-region-selection/14654/5 "2021-12-22T08:33:55Z")
@tomtobback thanks for bringing this old thread up. The way it works is that we have three TTSCE (community) clusters; `nam1`, `eu1` and `nam1`, the same three for TTSC (commercial) plus `eu2`, and we have three Packet Broker clusters that are serving Americas, EMEA and Asia Pacific. The Packet Broker clusters do all the routing between clusters, but there is no interconnection between Packet Broker clusters. So traffic from `eu1` does not show up on `au1` or `nam1`, but `eu1` and `eu2` works. The short term solution is that people in all Asia use the `au1` cluster for now. That region is connected to Packet Broker Asia Pacific which will be used for all Asian traffic. The medium term solution is that we add one or two Asian clusters to provide enough saturation and clarity what to use where. The long term solution is that we implement interconnectivity between Packet Broker clusters, so that traffic from the future `as1` can flow to `eu1` and `nam1`. We didn’t do that for now because we don’t see LoRaWAN devices to be roaming globally. But we will need it when bands are more harmonized (e.g. EU 915 MHz or LoRaWAN over 2.4 GHz) and for deployments that are in between Packet Broker Europe and Asia Pacific regions (like Russia and India). --- _[View the full topic](https://www.thethingsnetwork.org/forum/t/application-and-gateway-region-selection/14654)._