understanding the hread interface of …...thread requirements #2 wi-fi is notoriously power hungry...

Copyright 2007-2016, The PTR Group, Inc.

UNDERSTANDING THE THREAD INTERFACE OF GOOGLE’S NEST DEVICES

Mike Anderson Chief Scientist

The PTR Group, Inc.

http://ThePTRGroup.com

[email protected]

http://theptrgroup.com/


Who is The PTR Group? The PTR Group was founded in 2000 We are involved in multiple areas of work: Robotics (NASA Space arm) Flight software (over 35 satellites on orbit) Offensive and defensive cyber operations

• I’ll leave this to your imagination

Embedded software ports to RTOS/Linux/bare metal

IoT systems architecture and deployment

OIOT-SD-0416-2


Who am I? Over 39 years in the embedded space Developed part of VxWorks™ Instructor for Linux/Android internals Mentor for FRC #116 FIRST Robotics Team Frequent speaker at: Embedded Linux Conference Embedded Systems Conference CIA Emerging Technology Conference And more…

OIOT-SD-0416-3


What We’ll Talk About… Thread Group history to this point

Why we need another wireless standard

Interoperability with other standards

The underlying communications approach

Existing implementations

OIOI-SD-0416-4


The Thread Group The Thread Group was formed in 2014 as a 501(c) (6) non-profit corporation Independent, vendor neutral with over 213 member companies Open to all (who can afford to join )

• Memberships levels: − Affiliate ($2.5k/yr) − Contributor ($15K/yr) − Sponsor ($100K/yr)

The Thread Group manages the delivery of enabling solutions Specifications, certification programs, website, trademarks, copyrights, logos/seals

Essentially, they are an industry trade group to promote and protect Thread’s IP All member’s meeting March 22-24, 2016 – Redwood City, CA

Thread Group Open House May 10, 2016 -- Shanghai, China

OIOI-SD-0416-5


A Sample of Thread Group Members

OIOI-SD-0416-6

Sponsor-BoD Contributors

Source: threadgroup.org


We Need Another Wireless Standard? Apparently, yes However, it’s really a combination of existing standards

Existing IoT radios are either Wi-Fi, Zigbee or proprietary The Thread Group is working from a clear set of requirements: - Low Power - Secure and user-friendly - Resilient (mesh) - Fast time to market - IP Based - Existing radio silicon - Open protocol - No need for FCC licensing

OIOI-SD-0416-7


Thread Requirements #2 Wi-Fi is notoriously power hungry and not very resilient A single point of failure at the AP

Zigbee is relatively power efficient but is not an open standard Based on IEEE 802.15.4 with proprietary

L3+ stack However, Zigbee has several incompatible

versions and is confusing to the consumer Zigbee IP is a different story and actually close to Thread’s standard

• Zigbee Alliance is now collaborating with the Thread Group to enable the Zigbee Cluster Library to run on top of Thread

Needed to be able to operate in all countries without a license This pretty much means the 2.4 GHz ISM band Fortunately, there are a lot of existing radios for this frequency band

OIOI-SD-0416-8

Source:zigbee.org


What do they mean by Resilient? No single point of failure Mesh-oriented with automatic failover

Reliable enough for critical infrastructure Self-extending User can add new nodes with a minimum of hassle

Interference tolerant Can live in the Wi-Fi/Microwave oven bands

Able to penetrate normal drywall/stud construction Self-healing OIOI-SD-0416-9


Connected Home Requirements Simplified forming and joining of network Limit the need to understand concepts like coordinator, router and end

device

Latency on the order of 100ms for most transactions Scalable to 250-300 devices in a home Compatible with multiple vendors

Direct addressability to all devices Both device-to-device and device-to-cloud

Support multiple border routers with transparent fail over Years of expected life on small batteries E.g., door locks, smoke detectors, security devices

Seamless connectivity to user interaction device E.g., smartphone, tablet, dedicated display

OIOI-SD-0416-10


The Thread Standard Built on existing IEEE 802.15.4 standard Uses 6LoWPAN for L3+ [RFC6282]

• UDP traffic over modified IPv6 • Easily to gateway to the cloud or smartphones

Supports 250+ products per network

Just a firmware upgrade to existing 802.15.4 radios Works in the 2.4 GHz ISM band world-wide

Security using Datagram Transport Layer Security (DTLS) [RFC6347] Provides integrity, authentication and confidentiality

OIOI-SD-0416-11


IEEE 802.15.4 IEEE 802.15.4 actually describes only the physical and media access control layers of the network The upper layers are left to other groups/ organizations Supports tree, star and mesh topologies

Source: freescale.com

Source:colorado.edu

OIOI-SD-0416-12


Limitations of IEEE 802.15.4 Frames The maximum length of an 802.15.4 frame is 127 octets Typical frame overhead of 22 octets leaves 105 octets If you add the 21-byte encryption overhead (AES-CCM-128) then you only have 84 octets for L3+ For IP-style routing, you’ll need source and destination addresses and an 8 octet UDP header That is, 76 octets - (size of source + destination

addresses) IPv4 addresses are 4 octets and IPv6 addresses are 16

octets each

OIOI-SD-0416-13


How does Thread fit with 802.15.4? Thread defines only to L4 Applications protocol is

available for customization UDP messaging and ACK Supports multicast to the

network • Potential for mDNS

Examples include: • Zigbee Smart Energy 2.0 • CoAP and Smart Objects • ECHONET Lite • Zigbee Cluster Library


OIOI-SD-0416-14


What is 6LoWPAN? IPv6 over Low-power Wireless Personal Area Networks The 6LoWPAN IETF working group created a

standard that allows IPv6 packets to be sent over IEEE 802.15.4 networks [RFC6282]

Encapsulation and header compression that makes IPv6 packets small enough to transmit in the 127-byte 802.15.4 frames and still leave room for payload

OIOI-SD-0416-15


Why is IPv6 Involved? Simple, we’ve exhausted the IPv4 address space If we are to provide connectivity to the cloud for access via smartphones or tablets, we need to be able to route the sensor and control traffic IPv6 usage is increasing worldwide The U.S. is behind in adoption,

but we are making progress

OIOI-SD-0416-16

Source:netcore.com


IPv6 Addresses IPv6 addresses are certainly more complex 128-bit IPv6 vs. 32-bit IPv4

Special addresses include: ::1 (Loopback IPv4 127.0.0.1) :: (unspecified a.k.a. 0.0.0.0/INADDR_ANY)

IPv6 does not support broadcast Only multicast

IPv6 link-local addresses can be based on your hardware MAC address MAC- 5c:26:0a:26:76:dc IPv6- fe80::5e26:aff:fe26:76dc/64

• EUI-64 address • Notice that addresses are in groups of 4 (hextets) in hexadecimal

Auto-assigned addresses via SLAAC or DHCPv6

OIOI-SD-0416-17


IPv6 is Easier to Route IPv4 is a complex protocol for a router Many fields to look at and variable-length header

IPv6 header is a fixed length with no checksums Easier for low-resource CPUs to route

OIOI-SD-0416-18

Source

Address

Destination

Address

Source: wikimedia.org

Source Address

Destination Address


Example IPHC Compression of 6LoWPAN

OIOI-SD-0416-19

Source: ipso-alliance.org

Local PAN routing only

Multicast for ND & RD

Routing for Internet Traversal

Typical IEEE 802.15.4


Thread Network Architecture Devices join network as router-eligible or end device Routers can become leaders

Addresses assigned via DHCPv6 Home network can address devices via border router Routes maintained via RIPng Enables low-cost bridging to other networks No single point of failure


OIOI-SD-0416-20


Thread Messaging Model

Home Devices Border Router (Could be Wi-Fi access point)

Ethernet or Wi-Fi

Source: motorola.com

All devices use standard sockets API

OIOI-SD-0416-21


Security and Adding Devices User authorizes devices on the network using smartphone, computer or other GUI-rich device on the network Security session is established between the new device and the commissioning device to authenticate and provide credentials Once commissioning is complete, device attaches to the

network

Link encryption is used for all messages DTLS can be used based on application requirements

OIOI-SD-0416-22


Thread Certification All Thread devices will require certification Validation of device behavior,

interoperability, commissioning

Members will have access to free standard test harness 3rd-party testing labs Certification program launched in 1H 2015 Specification published June 1, 2015 but only available to members


OIOI-SD-0416-23


Teardown of a Nest Thermostat Runs Linux 2.6.37 kernel Busybox and lots of other

GNU-related code

TI AM3703CUS Sitara Cortex-A8

512 Mb DRAM 2Gb of NAND Flash Radios for IEEE 802.15.4 BLE Wi-Fi

OIOI-SD-0416-24

Source: iFixIT.com


Getting Started with Thread Silicon Labs announced the EFR32™ Mighty Gecko Wireless SoC Starter Kit ARM Cortex-M3 Includes mainboard, radios,

integrated debug, packet trace and starter software for three nodes

Kit price is $499

Uses Simplicity Studio software development environment (Eclipse-based) Available for Windows, OS/X and Linux

Source: silabs.com

OIOI-SD-0416-25


Summary Thread is still a work in progress

Standards-based approach yields high hopes for interoperability

They don’t appear to be coordinating with other IoT frameworks

Development units are available

Prepare for the IoT framework wars…

Source: nest.com

OIOI-SD-0416-26

understanding the hread interface of …...thread requirements #2 wi-fi is notoriously power hungry...

Documents