Announcing staging environment of TTN Back-end 1.0

TTN Network and Services
1

Thanks to the expertise of many community members and the effort of our core development team (@KtorZ, @htdvisser, @Thomas and myself), I’m proud to announce the staging environment of TTN back-end 1.0.

Features

  • Support for over-the-air-activation (OTAA) with custom security key per device
  • Support for activation-by-personalization (ABP) with custom security key pair per device
  • Support for confirmed uplink messages
  • Support for unconfirmed downlink messages for Class A devices
  • Deduplication of uplink messages
  • Command line interface for managing users, applications, devices and testing connectivity
  • Duty cycle calculations and best gateway selection for downlink
  • MQTT authentication and authorization
  • Support for EU 863-870 MHz frequency plan
  • Designed for public community networking, private connected networking and private offline networking

See more information about the new back-end

Getting Started

Known Issues

This is a staging environment which is much like a public beta that we update continuously. Do not use this environment for production. It is advisable, however, to migrate from Croft to the staging environment.

See GitHub for the list of issues. Issues that worth mentioning here:

  • Support for EU 433 MHz, US 902-928 MHz, China 470-510 and 779-787 MHz and Australia 915-928 MHz (issue #119 and #120)
  • Support for single channel gateways (issue #140)
  • Fix technical debt (#90 and #109)

Unknown Issues

If you find any issues, please raise an issue on GitHub. That allows for easy communication with the core team, assignment of labels and milestones, reference issues and commits, and follow progress.

Future Developments

  • Web dashboard as alternative to ttnctl (in progress)
  • E-mail validation, password reset, two-factor authentication
  • Delete applications
  • Development mode for personalized (ABP) devices (issue #118)
  • Design and implement service discovery (issue #70 and #71)

(When you’re reading this in the banner on top of the forum: you can read the responses here.)

12 Likes
2

This topic is now a banner. It will appear at the top of every page until it is dismissed by the user.

4

This is very exciting indeed and I can’t wait to test it out. Congratulations to all involved!

1 Like
5

wow ! :smiley: congrats

1 Like
6

When using OTAA, what is the maximum time between transmitted packets to prevent expiration of the activation?

7

Can you elaborate @kersing; do you mean when sending multiple join requests, if and when a join request expires?

8

@johan After joining OTAA the node will be assigned a DevAddr (I assume). Will this DevAddr be recycled at some point in time if a node does not send any data? (Looking at the MultiTech network-server it has a default of 1440 minutes until a join expires)

9

Ah, it does not expire.

In fact, DevAddr may be used by different nodes at the same time. The back-end tries the NwkSKeys it has for the concerning DevAddr.

We may want to purge the activated devices after some time, but this expiration time should be long. Afaik there’s no expiration specified in LoRaWAN 1.0. There are many use cases possible where activated devices only send a couple of messages per year.

1 Like
10

So when using the API how do we distinguish one device from another with the same DevAddr?

11

See the new topic structure; <AppEUI>/devices/<DevEUI>/[up|down|activations]

Devices are unique within your application. When using ABP, the DevAddr is prepended by zeros to make the DevEUI

12

Maybe I’m overlooking, but what is the ‘new’ ip address for my MQTT client ?

13

What about a REST API ? just so that it will be easier than using ttnctl ?

14

This will be part of the web dashboard @johan mentioned:

15

@w4e staging.thethingsnetwork.org. Will clarify that, thanks!

@cambierr no more storage unfortunately. That doesn’t scale well and becomes expensive. It may be an additional, optional service. Also, we’re considering a free cache of an hour or so. It is recommended to use MQTT.

Edit: @cambierr you will get to manage everything with a dashboard too. I thought you were referring to the REST API to get data.

16

My bad: my question was unclear. Can’t wait to see the management API to integrate it in our services :smiley:

17

Thanks to all involved in getting this next phase of TTN out of the lab. Really impessive to notice what has been done and I think it might be good we say: ‘thanks all of you guys’. It looks amazing. Well done.

3 Likes
18

I’m pointed my gateway at the new backend and now trying to configure a Multitech MDOT-BOX to use this.

I’ve created a user and a new application fine. However, the following command fails:

$ ttnctl devices register DevEUI Access Key

I’m assuming that the Access Key that is associated with an application upon creation is the same as the AppKey required when registering a device, since I cannot see any other key associated with the application.

The error I get is “FATAL Invalid AppKey: Invalid input”.

I also can’t see any way to manipulate the Access Keys associated with an application.

Suspect I’m missing something obvious here…

19 
ttnctl devices register personalized 01020304 
    INFO Generating random NwkSKey and AppSKey...
20

Access Key and AppKey are not the same. The Access Key is used to connect to MQTT, the AppKey is used in your LoRaWAN devices. See also http://staging.thethings.network/wiki/LoRaWAN/Security