1. System Design of Multiprotocol IOT
Dev Bhattacharya
dev_bhattacharya@ieee.org
2. Outline
• What is Internet of Things?
• Capabilities and functions of IoT
• Simplified IoT System Architecture
• Multiple Protocols of IoT
• Application layer Protocols
• Lower layer Protocols
• “Things” Requirements
• “Things” Challenges
• Conclusion
3. What is Internet of Things(IoT)?
• The word “internet” signifies internet connectivity
• The “Things” may provide
– Identification and information storage (e.g. RFID tags)
– Information collection (e.g. sensor networks)
– Information processing (e.g. embedded edge
processors), communication, control and actuation.
• The “Things” may consists of following parts:
– Transducers (sensors and/or actuators) and/or
– MCU (processing capabilities)
4. Capabilities and functions of IoT
• Full capability
– With MCU & Network
– The IOT application runs on the device. example: Smart Thermostat
• Constrained capability
– Various combinations of MCU & Networking
• With MCU (various processing capabilities)
• Without MCU (goes through a smart hub that provides MCU processing)
• With networking
• Without networking (goes through a hub that provides networking)
– The IOT application runs as a web application on the cloud or, the
cloud connected dedicated server
• Functions (I/O, input or, output)
– Sensors and Actuators
– Sensors
– Actuators
5. Simplified IoT System Architecture
Data
Analytics
smartphone
Internet cloud Cloud
server
Full
Capability
IoT
IoT Network
Constrained
Capability
IoT
Constrained
Capability
IoT
User
remote
server
Internet
gateway
Can connect to internet
directly or, through an
internet gateway
hub
6. Multiple Protocols of IoT
• Higher layer protocols
– Application
– Transport
– Network
• Lower layer protocols
– Link layer
HTTP/REST, MQTT, COAP, etc.
TCP, UDP
IPV6 , IPV6 w 6LOWPAN, etc.
Wireless (802.15.4, WiFi, BTLE, etc.)
Security
Security
7. Application layer Protocols
• HTTP/REST
– Universal availability of HTTP stacks for various platforms
– Backend processing ability of servers.
– Message latencies of several seconds
– RESTful HTTP over TCP is used mainly for connecting consumer premise devices (example: home
energy management)
• MQTT (Message Queue Telemetry Transport)
– Client/server model, where every sensor is a client and connects to a server, known as a broker, over
TCP. Telemetry or, remote monitoring of large number of constrained devices.
– MQTT is message oriented. Every message is a discrete chunk of data, opaque to the broker.
– The publisher subscriber model allows MQTT clients to communicate one-to-one, one-to-many and
many-to-one..
– Publish/subscribe messaging protocol designed for lightweight M2M (constrained) communications.
• COAP (Constrained Application Protocol)
– CoAP over UDP is used for resource constrained, short message for low-power devices.
– Like HTTP, CoAP is a document transfer protocol. Unlike HTTP, CoAP is designed for the needs of
constrained devices.
– CoAP packets are much smaller than HTTP TCP flows and can be parsed in small device memory.
– CoAP runs over UDP, not TCP. Clients and servers communicate through connectionless datagrams.
Retries and reordering are implemented in the application stack. Removing the need for TCP may
allow full IP networking in small microcontrollers. CoAP allows UDP broadcast and multicast to be
used for addressing.
8. Lower layer Protocols
• WiFi
– Wide availability of WiFi solutions for various hardware
– IoT device can directly connect to internet (additional infrastructure not needed)
– Internet gateways with WiFi access points are readily available
– Integrates Security (WPA2 uses an encryption device which encrypts the network
with a 256 bit key)
– Range 100 m
– Higher cost & power (~100mW) than 802.15.4 or, BT (not good for sensor & sensor
network)
– Data transfer rate 54 Mb/s
• 802.15.4
– 802.15.4 good for sensor related and low-data-rate monitor and control applications
and extended-life low-power-consumption uses (~1mW)
– Range 10 to 100m
– Security 128 bit AES
– Data transfer rate 250 Kb/s
• Bluetooth LE
– BTLE has very long battery life with sleep mode and used for medical sensors (0.1 to
0.5mW)
– Range 50m
– Security 128 bit AES
– Data transfer rate lower than 100 kb/s
9. “Things” Requirements
• Functional modes
– Sensor, Actuator, Both sensor & actuator
– What is being sensed - pressure, temperature etc., sensor resolution?
– Measurement frequency (How often it needs to be read?)
– How the measurement is triggered by timer, detected event in the monitored
value or, other event or, is it polled?
– What kind of processing needs to be done on sensed data
• Space available
– How big of a sensor or, actuator can be accommodated?
• Powering mechanism & Power consumption
– Battery primary or, secondary with energy harvesting
• Security requirement
– Encryption on the data, message (medical data), Security on all layers
• Connection to internet
– Direct , Through internet gateway (data rate, distance, latency)
• Cost
– Lowering overall system cost to meet system performance & power
10. “Things” Challenges
• Power Consumption
– System usage duty cycle determines where power needs to be
minimized
• For high bandwidth, minimize radio power For mostly inactive, minimize
standby power
– Radio transceiver is one of the most power-consuming
components
• Make use of a low-power listening MAC protocol that uses an efficient
wake-up mechanism to attain a high power efficiency.
– Memory and MCU cost power consumption
• Use MQTT or, COAP small packet size to minimize memory and MCU
– Frequent interrupts cost power consumption
• Use FIFO or, have a hub manage multiple sensors to reduce power
– Minimize power consumption for higher power circuits
• Reference voltage, oscillator & choice of buses
• Highly modular platform
– Design system based on preexisting power optimized chips
11. Conclusion
• Provided an overview of IoT
• Full capability and Constrained capability IoT
• Multiple protocols of IoT is covered
• Application layer and lower layer protocols are
compared
• Requirements of Things are highlighted
• Challenges of Things with possible solutions are
discussed
• Designing of an IoT calls for system design to
match constrained capabilities of “Things”
