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
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
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
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
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
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
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
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%
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’
"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
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)
• 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
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