The Things Network 2016 Update

Transcript

1. None
2. None
3. None
4. None
5. None

6. Sustainability of The Things Network Beyond the hype

7. Generating value on top of The Things Network

8. None

9. Guiding the IoT community in building use cases

10. None

11. Q1 2014 • Build 2.0 of The Things Network •

    Improve our community platform • Kickstarter Product • The Things Network Cookbook

12. Technical Update Johan Stokking Tech Lead, The Things Network January2016

13. 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)

14. 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

15. 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

16. 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

17. 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

18. 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

19. 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

20. 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

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

22. Progress Matthias Benkort a.k.a KtorZ Full-Stack Engineer at The Smiths

    December 2015 ? The Things Network Specification Implementation Integration Testing Documentation

23. 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

24. Introduction Channel Plan Fair Access Policy Thomas Telkamp, network architect

    The Things Network

25. 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

26. 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

27. 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%

28. 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’

29. 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

30. Introduction Research and Development Hylke Visser, intern The Things Network

31. Hello! Hylke Visser Intern @ The Things Network

32. Hylke Visser MSc Student at … “Cloud Computing and Services”

    “Distributed Systems and Services” “Cloud Infrastructures”

33. 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)

34. Teams

35. 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

36. 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
37. None