...
What is The Things Enterprise Stack (TTES)?
The Things Enterprise Stack, also referred to as TTES or V3, is The Things Industries' evolutionary LoRaWAN implementation for production networks. It was built from scratch to accommodate customer requirements around deployment scenarios, manageability, scalability and robustness. Also, TTES is a feature-complete stack that incorporates the complete LoRaWAN protocol, backend interfaces, regional parameters and FUOTA specification, and that follows the LoRaWAN Network Server reference model.What deployment scenarios do you offer with TTES?
We offer 4 different enterprise scenarios:
1. Cloud Hosted - shared infrastructure hosted and managed by us
2. Dedicated Cloud Hosted - physically isolated vm infrastructure hosted and managed by us
3. Self-hosted - the containerized stack offered as a binary, deployed and hosted by customer
4. Cloud Marketplace Launchers - orchestration templates deployed and hosted in customer’s cloud account in AWS.
Please check the Pricing/Deployment models page for more information on these scenarios.Where can I find the documentation for getting started with TTES?
The Things Enterprise Stack Documentation contains most of the resources to get started with TTES.Where can I find the pricing details of the TTES stack?
Check the Pricing page for licensing details.Is TTES offered via the AWS marketplace?
Yes. You can find details on the marketplace listing. The Amazon Machine Image (AMI) lets you orchestrate the deployment through our CloudFormation template, which means that you stay in control of your infrastructure. The service is billed per hour through your AWS account.How do you offer private networks per customer?
In our cloud offering, each customer has its own virtually isolated environment in our shared infrastructure (called tenants). Each tenant has a unique namespace, own branding and API end points. Gateways capacity can be shared across tenants optionally through peering.Can I have a hierarchy of tenants that I can then offer to my customers?
This is not possible on the TTI Cloud Hosted platform. However, If you are a systems integrator or reseller offering our service to multiple customers and you participate in our partner program, we will setup a multi-tenant cluster for you in a dedicated, physically isolated environment.I noticed ‘eu1
eu1.cloud’cloudin my network’s URL. Is it possible to have our environment set up in another region besides ‘eu1’eu1?
Yes. The services and databases are replicated across regions, so the service is multi-region by default. We are adding regions for redundancy and low latencies. We have currently deployedeu1,nam1clusters in Europe and North America. When new clusters are created, they will be updated in the Cloud Hosted Documentation page.
...
When setting the Frequency Plan, what is the difference between ‘Europe
Europe 863-870MHz' and 'Europe 863-870 (TTN)’?
The only difference is that863-870(TTN)uses SF9 for RX2, whereas863-870uses default SF12 for RX2. You can check this in the frequency plans repository.I don't have a JoinEUI for my device. How do I register my device?
For LoRaWAN 1.0.x devices, the JoinEUI in TTES is the same as the AppEUI in TTI V2. Devices usually come with JoinEUI (AppEUI). It is either issued from an IEEE block that you own, or you can set to70B3D57ED0000000if you are using the Global Join Server. You need to ensure that the (JoinEUI, DevEUI) pair is unique.What does the ‘External
External JoinServer’Serveroption do when I register a device?
Using an ‘External Join Server’ like the Global Join Server provided by The Things Industries allows you to claim a device which has been pre provisioned by providing only a Join EUI and Device EUI. The Things Enterprise Stack also contains a built in Join Server, which is used if ‘External Join Server’ is NOT selected. To use the built in Join Server, you must also provide an App Key (and a Network Key for 1.1 devices).How do I move the devices between applications?
Here is a sample bash script to re-organize a few selected OTAA devices between applications.Code Block #!/bin/bash old_app_id="sample-application-1" new_app_id="sample-application-2" dev_ids=("dev1", "dev2") for dev_id in ${dev_ids[@]} do dev=$(ttn-lw-cli end-devices get $old_app_id $dev_id --name --description --frequency-plan-id --network-server-address --application-server-address --join-server-address --root-keys --lorawan-version --lorawan-phy-version --supports-join) ttn-lw-cli end-devices delete $old_app_id $dev_id ttn-lw-cli end-devices create $new_app_id $dev_id <<< "$dev" doneYou can also use our device claiming service. More information about this is available at the Device Claiming Documentation page.
...
When can I expect scheduling downlink messages from the console on TTES?
This feature is in our pipeline and will be available soonpart of the 3.8.1 version, released in May 2020. You can track the progress of this and a few other features at Console feature gaps v2/v3 issue on Github.
However, you
You can schedule downlinks using CLI, MQTT or HTTP webhooks.
Please refer to Downlink Queue Operations Guide for downlink queue operations using CLI.
For further information on how to do this using MQTT or HTTP webhooks, refer to Integrations Documentation.
...
How does migration from V2 to TTES V3 work?
You are able to migrate applications and devices from V2 to V3 yourself. Devices cannot be present in both. This means that you have to integrate both V2 and V3 APIs concurrently to your application to avoid downtime. Device sessions will be preserved, however as V3 has more MAC settings, manual configuration may be required in the Network Server.
Gateways need to be updated to a newserver address. We recommend to configure the Basic Station packet forwarder to enhance manageability and security. We may provide migration time for gateways and route traffic from the V2 bridge to the V3 environment so that they can serve both for a while (although this is without guarantees as you can get conflicting downlink scheduling and duty cycle violations). Until the gateways are updated, data is routed from V2 to V3 via the Packet Broker.
Our suggested migration process:First: Update applications to support the The Things Stack data format which is different from the V2 data format. If you are using payload formatters, make sure to set them correctly from the Application settings page.
Second: Migrate a single end device (and gateway, if needed) to TTES. Continue by gradually migrating your end devices in small batches. Avoid migrating production workloads before you are certain that they will work as expected. We will publish a detailed tutorial shortly.
Finally: Once you are confident that your end devices are working properly, migrate the rest of your devices and gateways to TTES.
Do you provide scripts to help me migrate from V2 to V3?
Yes, we will provide DIY scripts to bulk migrate applications, devices and session data. Contact support@thethingsindustries.com to obtain these scripts.Can I migrate devices back to V2?
No.How do I migrate my gateway to V3?
We will offer a temporary bridging solution so that gateways work on both your existing V2 environment and the new TTES V3 environment. After that, we will update our DNS so that they will point to the new environment exclusively. However, it is highly recommended to upgrade to the Gateway Agent with V3 gateway ID and API key or update the address when using UDP.How can I migrate the MAC (LoRaWAN Version) and PHY (Regional Parameters) settings from V2 to V3?
The Things Stack requires the LoRaWAN version and Regional Parameters (LoRaWAN PHY version) to be set per end device. These default to LoRaWAN version1.0.2and LoRaWAN Regional Parameters version1.0.2 Rev Bfor end devices imported from The Things Network Stack V2, because this configuration is the most consistent with the V2.Can I migrate from a different network provider to TTES V3?
Yes. As this is a specific activity, please contact us at support@thethingsindustries.com. We need some information about the devices and gateways to understand the scope of such migration.
...