Upgrade to Pro — share decks privately, control downloads, hide ads and more …

The Things Network 2016 Update

The Things Network 2016 Update

Wienke Giezeman

January 08, 2016

More Decks by Wienke Giezeman

Other Decks in Technology


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

    Improve our community platform • Kickstarter Product • The Things Network Cookbook
  2. 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)
  3. 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
  4. 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
  5. 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
  6. 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
  7. 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
  8. 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
  9. 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
  10. Progress Matthias Benkort a.k.a KtorZ Full-Stack Engineer at The Smiths

    December 2015 ? The Things Network Specification Implementation Integration Testing Documentation
  11. 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
  12. 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
  13. 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
  14. 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%
  15. 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’
  16. 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
  17. Hylke Visser MSc Student at … “Cloud Computing and Services”

    “Distributed Systems and Services” “Cloud Infrastructures”
  18. 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)
  19. 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
  20. 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: [email protected]