No content

No content

No content

No content

No content

Sustainability of The Things Network Beyond the hype

Generating value on top of The Things Network

No content

Guiding the IoT community in building use cases

No content

Q1 2014 • Build 2.0 of The Things Network • Improve our community platform • Kickstarter Product • The Things Network Cookbook

Technical Update Johan Stokking Tech Lead, The Things Network January2016

Agenda • Timeline • Design Principles • Security • Core Components • Platform Integration • Milestones • Progress (Matthias Benkort) • Channel Plan (Thomas Telkamp) • Fair Access Policy (Thomas Telkamp) • Internship Research and Development (Hylke Visser)

Timeline • July 2015 Validatebasic connectivity and routing by building a demonstration prototype • August 2015 Demonstrated prototype during The Things Network Conference • September 2015 Gather input from experienced community members • October 2015 Present RFC of network architecture and validatedesign with experts • November - December 2015 Implement and test components • January 2015 Network infrastructure, fair access policy, introduce new back-end and start research projects

Design Principles • Standards compliant • Distributed decentralized architecture • Picocell network layout • No geographical borders • Support for geographical segmentation to keep the data close • Efficient routing: reduce bandwidth, computations and packet drop rate • Trust-based model for both the gateway owners and application developers • End-to-end encryption: application keys remain secret to the application Node Any LoRaWAN 1.x compliant device

Security • LoRaWAN provides builtin AES encryption using 128 bit keys on both the network and the application level • Application keys remain secret to the application to enable end-to-end encryption • The Things Network back-end components provide mitigation of various man-in-the-middle attacks, for example by checking the message integrity and frame counters

Core Components R Router Routes raw packets from gateways to brokers NC Network Controller Node state, data rate and frequency management H Handler Decryption, deduping, works on behalf of apps A Application Application or IoT cloud platform Gateway Send data to and receive data from nodes B Broker Decoupling from router to handler

R H S1, S2 S2, S1, S3 S2, S1, S3 S3, S2 B Core Components B 041FBA43 R NR P A A H A NC NC uplink downlink

Application and Cloud Platform Integrations H A B Integrate handler functionality in application H A B Connect Application with Node RED H NR B A Connect Application with AwS IoT, IBM Bluemix, FIWARE, etc H P B A Connect Application with the open source The Things Handler The Broker and the Handler are offered hosted services by the Foundation, but both services can be installed on-premise as well MQTT MQTT HTTP HTTP HTTP HTTP

Milestones 1. Have a fake gateway able to mock the behavior of a physical gateway. This will be used mainly for testing and ensuring the correctness of other components. 2. Handle an uplink process that can forward a packet sent by a personalized node and received by a gateway to a simple end-server (fake handler) 3. Support application registration for personalization. Applications provide a list of personalized device addresses along with the network session keys 4. Allow transmission of downlink messages from an application. Messages will be shipped as response after an uplink transmission from a node 5. Handle OTAA and downlink accept message 6. Handle complex commands and their corresponding acknowledgement, including full implementation of LoRaWAN 1.x MAC commands

Introduction Progress Matthias Benkort, back-end developer The Things Network

Progress Matthias Benkort a.k.a KtorZ Full-Stack Engineer at The Smiths December 2015 ? The Things Network Specification Implementation Integration Testing Documentation

1 2 3 4 5 6 80% 50% 75% 0% 0% 0% Mock gateway Fake traffic simulator Semtech protocol library Uplink transmission Router -> Broker -> Handler Personalized registration Progress Downlink transmission Detailed Stats OTAA Complex MAC commands Network monitoring Network optimization

Introduction Channel Plan Fair Access Policy Thomas Telkamp, network architect The Things Network

Channel Plan 867.1 867.3 867.5 867.7 867.9 868.1 868.3 868.5 #3 #4 #5 #6 #7 #0 #1 #8 #2 867.8 #9 869.0 869.525 870.0 g1 g1.1 g1.2 g1.3 g1.4 SX1257 A: 867.5 Mhz SX1257 B: 868.5 Mhz

Fair Access Policy: Why? • All TTN users need to be able to reliably use the network • Nodes sending at the same time on the same frequency and SF will cause collisions, and therefore cause packet loss • We need to keep the number of collisions acceptable • Many nodes transmitting at the maximum duty cycle does not scale! • Note: 20.000 or 60.000 nodes per gateway numbers (as advertised) assume nodes not sending more than 1 message per hour

Fair Access Policy: Basis • TTN wants to support at least 1.000 nodes per gateway • Duty cycle of the gateway (receiving) needs to remain << 10% • Assuming the 8 channels to be used at all SF • Achieved by limiting air time per node to 30 seconds per day • This limits the duty cycle to less than 5%

Fair Access Policy: Practice • Golden rule: 30 seconds air-time per device per day • For 10 bytes of payload, this translates in (approx.): • 20 messages per day at SF12 • 500 messages per day at SF7 • more for SF7BW250 and FSK (local-area) • If your application requires more bandwidth, think of another solution • This allows for >1000 nodes per gateway • Downlink bandwidth is even more restricted • you can’t send all messages as ‘confirmed uplink’

Don’t waste your time! • Simple: • { “Count”: 1234, "Temperature": 20.635 } • 40 bytes: 292 messages per day (SF7) • Remove counter (is already included in header), spaces, and compress names: • {“t”:20.63} • 11 bytes: 486 messages per day • No JSON: • 20.63 • 5 bytes: 582 messages per day • Signed 16 bit integer • 0x080F • 2 bytes: 648 messages per day

Introduction Research and Development Hylke Visser, intern The Things Network

Hello! Hylke Visser Intern @ The Things Network

Hylke Visser MSc Student at … “Cloud Computing and Services” “Distributed Systems and Services” “Cloud Infrastructures”

Hylke Visser Going to work on TTN Cloud Infrastructure • Redundant (kill a datacenter and it should still work) • Globally Distributed (our friends in Brazil also want low latency) • Scalable (750 Kickstarter backers all plug in their gateways)

Teams

Teams and Internship Positions 1. Architecture team draws on whiteboards • Overview of different components • Design for openness and decentralization • LoRaWAN compliance 2. Network access team develops in C/C++ • Nodes • Gateway firmwares 3. Core team develops in Golang • Router, Broker, Network Server and Handler 4. Integration team makes things work together • Node RED setup and examples • AwS IoT, IBM Bluemix, FIWARE, IFTTT, Parse.com, thethings.io, etc • Bundling and containerizing • Code examples and libraries • Develop workshop materials

How to join a team or apply for an internship Do you want to participate in the Architecture, Network Access, Core and/or Integration team as a community developer or intern? 1. Register on the forum: http://forum.thethingsnetwork.org 2. Join Slack: http://slack.thethingsnetwork.org 3. Sign up for the newsletter: http://thethingsnetwork.org (go to Join Team) 4. Read background information: http://thethingsnetwork.org/wiki 5. Check out GitHub: http://github.com/TheThingsNetwork 6. Send an e-mail: johan@thethingsnetwork.org

No content