v3.20.0

Getting Started Devices Gateways Integrations Reference
Get The Things Stack

Getting Started

    Overview
  • Quick Start
  • What Is The Things Stack?
  • Console
  • Command-line Interface
  • Installing The Things Stack
  • Upgrading The Things Stack
  • Migrating to The Things Stack
    • Migrating End Devices from Community Edition to Cloud
    • Migrating End Devices from ChirpStack
    • Migrating End Devices from V2
      • Major Changes In The Things Stack
      • Packet Broker Requirements for End Device Migration
      • Migrate using the Console
      • Migrate using the Migration Tool
      • Migrate using the V2 Takeout Tool
    • Migration Tool
    • Import End Devices in The Things Stack
    • Fine-tuning MAC Settings for End Devices
    • Migrating Gateways
    • JSON File Reference
    • CSV File Reference
    • Migration FAQ
  • The Things Stack Cloud
  • The Things Stack AWS Launcher
  • The Things Network
  • Server Addresses
  • Packet Broker
  • Single Sign-On
  • Users and Organizations
  • Using the API
  • Working with Events
  • Troubleshooting Getting Started

Packet Broker Requirements for End Device Migration

Read this section if you want to make use of Packet Broker to migrate your end devices and route traffic from V2 to The Things Stack.

When migrating your devices with active sessions, it is in most cases not possible to make use of Packet Broker. Read along to learn when you can and cannot make use of Packet Broker.

Migrate from Migrate to Possibility to use Packet Broker
The Things Industries V2 The Things Stack Community Edition Only without persisting active device sessions
The Things Industries V2 The Things Stack Cloud With and without persisting active device sessions

Remember that The Things Stack Enterprise and The Things Stack Open Source can also be configured to connect to Packet Broker. If using those deployments, end devices can be migrated from V2 via Packet Broker without persisting active sessions.

Devices Address (DevAddr)

V2 DevAddr of your end device needs to be routable by Packet Broker.

OTAA devices migrated without an active session will acquire a new DevAddr from The Things Stack during the join procedure. Packet Broker will always be able to route the traffic with DevAddrs assigned by The Things Stack Community Edition or The Things Stack Cloud.

When registering ABP devices on The Things Stack, it is possible to auto-generate new DevAddr which can be routed by Packet Broker. ABP devices can be re-programmed to use this new DevAddr. This implies breaking their existing session on V2.

Migrating OTAA and ABP devices with their active sessions implies keeping their DevAddr values from V2. Packet Broker will be able to route traffic for these DevAddr values only if these devices were registered on The Things Industries V2 (SaaS) and you are migrating them to The Things Stack Cloud. If you are not using these deployments and you still want your traffic to be routed by Packet Broker, end devices can only be migrated without their active sessions. The alternative option is to migrate your gateway instead of using Packet Broker.

RX1 Delay

The RX1 delay value for your end device needs to be set to 5 seconds, which is a default for The Things Stack (V2 is using 1 second).

The RX1 delay of OTAA devices migrated without their active session will be automatically set to 5 seconds without your intervention.

However, this needs to be manually set for OTAA devices migrated with an active session by configuring their MAC settings. It is also possible to re-program ABP devices to enforce the RX1 Delay of 5 seconds (this basically implies starting a new ABP session, i.e. migrating ABP devices without their active session from V2).

If devices keep on using an RX1 Delay of 1 second, downlinks routed via the Packet Broker will probably never reach the end device in time. The alternative solution to enable downlinks is to migrate your gateway to The Things Stack too. Remember that even if you migrate your gateways to The Things Stack, you might still experience issues if you are using a high-latency backhaul in a combination with an RX1 Delay of 1 second.

If DevAddr and RX1 Delay conditions stated above are not met, it is likely that you will experience difficulties in communication between your end device and The Things Stack via Packet Broker. If you are using deployments that are not connected to Packet Broker, you will have to migrate your devices as well as your gateways in order to receive the traffic from your end device on The Things Stack.

Warning:
We strongly recommend to migrate devices without their active sessions, to make sure Packet Broker can route the traffic properly and that it reaches The Things Stack in time.
← Major Changes In The Things Stack Migrate using the Console →

On this page

  • Devices Address (DevAddr)
  • RX1 Delay

The Things Stack

Getting Started

Devices

Gateways

Integrations

Reference

Contributing

GitHub

Forum

About Us

The Things Network

The Things Industries

About this page

Last changed by Nejra Selimović on 22 Dec 2021.
doc: Update migration docs post TTN V2 shutdown (#676)

Edit on Github