key open standards for inter-operable iot systems
TRANSCRIPT
Key requirements for Interoperable IoT systems
Pratul Sharma Technical Marketing Manager,
ARM Inc.
May/08/2014
Agenda
• Why Interoperability?
• Open standards for interoperability
– Data Communication Standards
– Web Objects
– Device Management
– Web Services
• ARM IoT Solution
2
Why Interoperability?
IoT market Growth Projections
Source: Piper Jaffray
IoT IoT 39%
Two Scenarios of IoT Market Growth
Open Data
and Objects
The future R
each
Smart
Everything
SaaS
M2M
Applications
Internet / broadband
Mobile Telephony
Sensors & Actuators
Networks
Fixed Telephony Networks
Mobile internet
Scale Needs Standards Sharing Needs Trust Trust Needs Security
Today
Risk
Time
Key Elements to Drive IoT Market Growth
New Applications
Innovation
Trust
Security
Interoperability
Standards
Growth in the Billions Doesn't come without Standards and Industry Alliances
A simple Model of an IoT system
Sensor, Actuator and uController
(nodes)
User Interface/Application
Device Management
Data
Communication Infrastructure
2) Device Management 1) Data Communication 3) Web Objects 4) Web Services
For Interoperable IoT system we need standards for
Data Communication Standards
Communication interfaces in an IoT system
10
Comm. Infra.– App. Interface IoT Device – Comm. Infra. Interface
Sensor, Actuator and uController
(nodes)
User Interface/Application
Device Management
Data
Communication Infrastructure
Communication infrastructure and Web app. Interface
TLS
TLS
TLS
TLS
TLS
TLS
12
Communication infrastructure and Constrained Device interface
It’s a Standard IP interface as constrained devices are not involved
Standard IP protocol stack is suitable for communication
DTLS
DTLS
DTLS
DTLS
DTLS
DTLS
How does CoAP features optimize IoT data communication?
• Resource discovery – New devices (nodes) are discovered automatically. No human intervention needed. – Easy to add new devices. Easy to replace the devices.
• Subscription – Push of Information from IoT devices to application.
• Content Negotiation – Data type to be used between the client and the server is settled before the actual data communication. It make it
easy to integrate CoAP enabled device in an IoT system. – Explicitly indicate the content type of the payload in the header
• Simple Caching – Optimize performance
• REST oriented – REST based web services are based on architecture of the web and more compatible with existing web tools and
techniques. – It has less overhead, less parsing complexity, statelessness, and tighter integration with HTTP
CoAP and optimized security handshakes: 10x reduction in bandwidth
14
Constrained Devices
Little Data
Band
wid
th
HTTP
CoAP
10x reduction in BW
Internet
6LoWPAN : High level overview
15
IOT nodes
Standard Internet
Packet size ~ 1280 bytes Packet size ~127 bytes
6LoWPAN specification • 6LoWPAN is adaptation layer for IPV6
• Function • IPV6 header compression
• Packet fragmentation and re-assembly
• Optimized Neighborhood discovery
Why 6LoWPAN?
• No need for translation gateways or proxies.
• IP networks allow the use of existing network infrastructure.
• Very well known and have been proven to work and scale.
• Open and free standard. Processes and documents available to anyone.
• Encourages innovation and is better understood by a wider audience.
• Tools for managing, commissioning and diagnosing IP-based networks already exist.
• Allows Interoperability on device side.
Web Objects
Web objects
DTLS / UDP
Proprietary
CoAP
6LoWPAN
IoT
De
vic
e
DTLS / UDP
Proprietry
CoAP
6LoWPAN
IoT
De
vic
e
Service 1 Service 2
DTLS / UDP
Web Object
CoAP
6LoWPAN
IoT
Devic
e
Service 1 Service 2
DTLS / UDP
Web Object
CoAP
6LoWPAN
IoT
Devic
e
In addition to data communication we need
standard web objects for Interoperability
Non-interoperable devices & Services
DTLS / UDP
Web Object
CoAP
6LoWPAN
IoT
Devic
e
Service 1 Service 2 Service 3
Interoperable Services
Interoperable Devices & Services
IPSO Web Objects
• The IPSO Alliance promotes the Internet Protocol for smart objects.
• We need semantics to build a Web of Things
• Web Objects exposes the state and behavior of a device.
• IPSO defines Web Object guidelines (join us!)
• 65+ members
IPSO Object example: Temperature Sensor
Example
Temperature sensor: This IPSO object should be used over a temperature sensor to report a remote temperature measurement. It
also provides resources for minimum/maximum measured values and the minimum/maximum range that can be measured by the
temperature sensor. The unit used here is Celsius degree.
Object info
Resource Info
Object Object ID Object URN Multiple Instances?
IPSO Temperature 303 urn:oma:lwm2m:ext:303 Yes
Resource Name Resource ID Access Type Multiple Instances? Type Units Descriptions
Sensor Value 5700 R No Decimal Cel This resource type returns the Temperature Value in °C
Min Measured Value 5601 R No Decimal Cel The minimum value measured by the sensor since it is ON
Max Measured Value 5602 R No Decimal Cel The maximum value measured by the sensor since it is ON
Accessing the Resources
• Temperature Value /303/0/5700
• Min Measured Value /303/0/5601
• Max Measured Value /303/0/5602
LWM2M Client
/303/0
5700
5601
5602
Temperature Value
Min Measured Value
Max Measured Value
Object
Device Management
Device Management
22
Mobile Device
Management Device
Management
Provisioning
Device Configuration
Software Upgrade
Fault Management
Enabling, disabling
features
Changes to settings
Changes to parameters of the
device
Update application and system software
Bug fixes
Report Errors from devices
Query about status of devices
OMA Lightweight M2M
©Sensinode 2013
• Efficient Device-Server interface based on open
IETF standards
• Banking class security based on DTLS
• Standard Device management already defined by
OMA
• Applicable to Cellular, 6LoWPAN, WiFi, Zigbee IP
and other IP based on constrained networks
• Can be combined with other DM offerings.
* OMA also define Objects for Device Management
Web Services
REST Style Web Services
• We need web applications in an IoT system to configure, control and monitor the sensors and actuators.
• Web services are required to integrate web applications over the internet protocol backbone.
• REST is web service architecture style for designing networked applications.
• REST is not a "standard". Its a set of guidelines/constraints.
• REST uses simple HTTP/CoAP to make calls between machines rather than using complex mechanisms such as Remote Procedure Call (RPC) or (Simple Object Access Protocol) SOAP.
• The World Wide Web can be viewed as a REST-based architecture.
Open Standard based ARM IoT Solution
27
ARM IoT Products: from Device to Cloud
ARM Sensinode NanoService
Web Application SDK Java SDK and Reference Applications (source code) for rapid
development of customer application that controls/monitors
IoT nodes
NanoService Platform IoT security, communication and data flow platform with OMA
Lightweight M2M Server support
NanoService Client
Enables secure, efficient communication between devices
and the NanoService Platform with OMA Lightweight M2M
Client support
ARM Sensinode NanoMesh
• NanoRouter
6LoWPAN to IPv6 border router for both embedded
platforms and Linux.
• NanoStack 6LoWPAN protocol stack for both routing and host devices.
• Stack Products
– ZigBee IP – Home Area Network Mesh
– BT Smart IP – 6LoWPAN for BT Smart devices
– ZigBee NAN – Neighborhood Area Network Mesh
– G3 PLC – For wired smart metering applications
802.15.4
2.4 GHz
ZigBee IP ZigBee NAN
BT Smart IP
BT 4.0 (LE)
2.4 GHz
802.15.4g
Sub-GHz
6LoWPAN
IPv6
Free Online IDE
Get started today! mbed.org
1,200,000+
mbed.org unique visitors in 2013
100,000+ mbed-enabled development
boards shipped
100+ Major OEMs from
diverse industries
are using mbed
45,000+ Mbed developers
The Internet of Things is the next evolution of Web
Summary
ARM Mbed and Sensinode SW enables the design of future proof and scalable IoT systems.
32
Market growth driven by Standards, Security and Innovation. Interoperability will be the key.
CoAP, 6LoWPAN, IPSO objects, OMALWM2M