Sensor-to-cloud connectivity using Sub-1 GHz and

Transcription

1 Sensor-to-cloud connectivity using Sub-1 GHz and Nick Lethaby, IoT, Ecosystem Manager, Texas Instruments

2 Agenda Key design considerations for a connected IoT sensor Overview of the Sub-1 GHz band Overview of the standard stack and internet connectivity Power consumption results Summary

3 IoT sensor network requirements Long range: It is desirable to deploy IoT sensors over a whole building or factory without the cost and complexity of intermediate routers or range-extenders Robustness: For IoT applications such as smoke alarms or predictive maintenance, sensor data must be delivered reliably to enable a response Scalability: IoT applications will have dozens to hundreds of sensors on an individual wireless network Latency: An IoT application like a home alarm must deliver data in a timely manner Security: Unauthorized access or eavesdropping must be prevented

4 IoT sensor node requirements Low power: IoT sensors must often run on small batteries for years as mains/solar power may not be available and it will be not be practical to frequently replace batteries. Low cost: IoT sensors must be low cost, which means avoiding network implementations that require complex protocol stacks residing on the node, with the associated additional processing, power, and memory cost These network and sensor node requirements drove our implementation choices

5 The Sub-1GHz ISM Band Overview Range, and Range, Penetration Range Power Low consumption Power Robustness Robstness 1000x more than Wi-Fi, ZigBee Better penetration of walls and bending around obstacles Full building coverage with a simple network architecture Choice of long range modulations 20 km on coin cell battery Up to multi-years on coin cell battery Lower power vs. other technologies for the same range Less susceptible to interference Avoid the crowded 2.4 GHz Frequency hopping FCC and ETSI-approved bands The Sub-1 GHz band is proven in smart meter and connected alarm applications Widespread adoption in IoT applications limited by lack of easy internet connectivity

6 The standard The standard address the MAC and PHY definitions for wireless networks and is designed for ultra-low power operation The standard was introduced in 2003 and has been widely deployed in the 2.4 GHz band For example, zigbee applications is also used by Thread In 2011, the Smart Utility Networks (SUN) Task Group released the g extension to that enables the protocol to be used on the Sub-1 GHz band Some 20 different PHYs are supported Note is a la carte standard and implementations do not need to include every feature

7 Overview Range & Penetration Security g supports Sub-1 GHz PHYs Scalability includes AES-CCM Robustness CSMA-CD Frequency-hopping Narrowband CSMA-CD WiSUN frequency-hopping Low Power Low Cost $$$$$ Low memory & CPU overhead No need for IP at the node Asynchronous mode means no need to maintain connection

8 The 15.4 stack implementation OSI Layer Standard Comments 2. DATA LINK 2a. Logical Link Controller Device authentication, management, service discovery Network formation, open/close 2b. MAC Security Medium access Addressing Packeting Frequency Hopping Not addressed by standard AES-CCM standard CSMA/CA standard addresses standard packeting WiSun based frequency hopping TI created a proprietary LLC layer to offer these functions 1. PHYSICAL g 2-GFSK 50kbps supported

9 security and authentication uses AES-CCM (Counter with CBC-MAC) security scheme. AES provides encryption for data confidentiality Uses pre-shared key added at build time to the image In security, we also want to make sure that the received message is valid (authentic), that has been not tampered with (integrity), or repeated as a form of attack to trick the receiver (anti-replay) An AUX header is added to the original frame when security is used. A message integrity code (MIC) is also appended to the original frame, and it is applied doing CCM to the whole frame (header+aux header+payload) The MIC serves to authenticate the frame, and in combination with the AUX header provides protection against anti-replay attacks (because the AUX header is generated using the sequence number).

10 Bridging the 15.4 stack to the Internet Linux Host Send to cloud, Local analytics,. JSON sensor data (IPSO) App Client Socket interface Join/leave network Transmit data Receive data Gateway Node Network management application App Server /dev interface Linux Kernel Logical Link Controller Network Processor Interface Server UART/USB Sub-1 GHz NWP Network Processor Interface MT Layer Serial MAC layer stack g PHY Sub-1 GHz Node User Application Link Layer Controller e MAC g PHY

11 security: AES-CCM AES-CCM = Advanced Encryption Standard-Counter with CBC-MAC Security Challenge Confidentiality Authenticity Integrity AES-CCM implementation AES-CCM includes 128/256-bit AES encryption. AES is symmetric and therefore requires a key or similar artifact to be shared in advance and remain secret. CCM proves packets are authentic. The counter prevents replay attacks as each packet must have a different number. AES-CCM in a Message Integrity Check (MIC) that enables the receiver to verify that the packet contents were not altered (countering man-in-themiddle attacks)

12 AES-CCM security limitations Lack of secure commissioning AES-CCM lacks a mechanism to authenticate devices joining the network A potential solution is to use asymmetric encryption (e.g. token, QR code, certificates) to authenticate network access EAP-TLS would be one solution for authenticating users, although its memory requirements may be too great for some Sub-1 GHz microcontrollers A key (or equivalent) needs to be burnt into a device at production time and there is no way to update the key A potential solutions ECDHE is an option for key exchange which could then also be used to update keys This key exchange may also be used to implement secure commissioning

13 Assumptions: Coin Cell battery: 230 mah Transmit Power = 10 dbm Power consumption results Voltage = 3.6 V Packet size = 20 bytes Mode Range Data Rate Application Profile: Sensor Polls every 1 min Sensor sends data every 3 min Application Profile: Sensor never polls Sensor sends data every 3 min Battery life Avg Current Battery Life Avg Current km 50 kbps 6.6 yrs 4 ua 13.9 yrs 1.9 ua & frequency hopping 1 km 50 kbps 4 yrs 6.7 ua 11.9 yrs 2.2 ua TI SimpleLink Long Range mode 4 km 5 kbps 1.2 yrs 22 ua 3 yrs 8.8 ua TI SimpleLink Long Range mode with frequency hopping 4 km 5 kbps 0.75 yrs 35 ua 2.15 yrs 12.2 ua Note: This is a simplified theoretical estimate and does not include battery decay, power required for join procedure, reception of data from the gateway if a polls indicates there is some, and handling different packet sizes. 13

14 Reliability Test Basic Test Setup/Procedure Tx power = 0 dbm, 50 kbps data rate (Run for 36 hours) 1 gateway connected to 150 sensor devices MHz Application Traffic Profile Value Sensor packet (100 bytes) interval 90 seconds Sensor poll interval 30 seconds Tracking (5 bytes Request & 1 byte Response) message exchange 90 seconds Broadcast Frame from collector 10 seconds Max Frame Retransmissions 6 Unicast Fail Rate 0.7% Broadcast Fail Rate 0.2% 14

15 Summary The Sub-1 GHz band offers ideal properties for IoT nodes Long range, low power, and low cost It is widely used in proprietary networks such as home alarm or smart meter applications Adoption in the IoT has been slowed by the reliance on proprietary protocols and lack of easy internet connectivity The g extension enables its use with the Sub-1 GHz band and provides a comprehensive MAC layer To connect g networks to the internet, a link layer controller must be implemented and an internet gateway developed

16 More Information For source code, hardware design, and documentation for Sub-1 GHz gateway implementations, visit: Linux gateway implementation: RTOS gateway implementation: The links include software, hardware, and documentation IPSO Smart Objects: Wi-SUN frequency hopping:

17 Thank You!