11

IoT Device Platform- ARTIK & IoT Protocols -

2017. 11. 8

최 욱

S/W 센터 (반도체연구소)

삼성전자

2

Outline

1. The Era of IoT

2. IoT Value

3. IoT Architecture

4. Samsung ARTIK

5. IoT Platform

6. IoT Protocols

3

4차 산업혁명…

확산 & 전환

4

Amazon …..

5

Amazon …..

■ Amazon Go

6

Tesla …

■ Electric Car manufacturer .. That is all?

Gigafactory in Nevada, US

Solar roof tile from Solarcity

7

■ Unveiling a new solar panel

Tesla …

8

IoT Hype Cycle

Gartner Hyper Cycle

9

The Era of IoT - Why Now?

■ Internet Connectivity Evolution From Human-centric to Device-centric

10

The Era of IoT – IIoT & CIoT

[Ref] Talk on Industrial Internet of Things @ Intelligent systems tech forum 2014

11

IoT Value – Moore’s Law

■ Gordon Moore predicted that transistor density is doubled every 2 years

■ Moore’s law has been driving IoT evolution from technical perspective…

Moore’s Law - A logarithmic scale on the Y-axis

Performance

Cost

processor evolution is following Moore’s law

Mobile devices and machine-to-machine (M2M) communication modules are following similar performance and cost curves!!!

Hardware miniaturization, decreasing sensor costs, and ambient device connectivity

12

IoT Value – Metcalfe’s Law

■ Targeting a value-driven business to meet its growth expectations

■ The network value grows by “the square of the number of network nodes” while costs follow a more or less linear function (by Bob Metcalfe, 3Com co-founder)

MetCalfe’s Law

Metcalfe’s law is really about network growth, value creation, and customer acquisition rather than about technological innovation

N: # of servicesM: # of devices

13

IoT Conceptual Architecture

Data AnalyticsServices

Internet

Gateway/Hub

Things(Sensors, Intelligence Appliances…)

■ Layered architecture consisting of Application, Network, Edge, and Perception layers

Perception Layer

Network Layer

Application Layer

Edge Layer

Clouds

High-valuedevices

Constraineddevices

14

IoT Use Case Scenario - What a Diverse!

■ Various device architectures, service scenarios and use cases!

– Various functions, standards, protocols, APIs

■ One platform dominates all, possible or not possible?

– Flexible platform architecture for heterogeneity

15

IoT Platforms – Eco-system

People

데이터

■ IoT is a biz area that creates value out of data collected from “everything connected” must provide various connectivity & data collection technology and eco-system

Internet of Everything !!

How can we get everything connected and get some meaningful value out of it?

Things Connection with various things, env.

Eco-system

16

Types of IoT Platforms

of

People &Things

Gateway

Data Gathering

Device Management

AI Analytics

Storage / Database

Messaging

Data Collection

Edge Intelligence

BSP

Connectivity

Co

mm

un

icat

ion

s

Device & Controllers

Cloud Services

Ecosystem

Security

Communications

Edge Computing

Cloud Platform

Edge Platform

Device Platform

Secu

rity

17

Platform Definition

■ Platform Technology (from Wikipedia)

– “제품” 개발을 가능하게 하는 기술이나, 현재 또는 미래의 개발을 지원하는 프로세스

17/8

18

Open Platform

■ 필요기능의 통합 플랫폼 개발의 끝이 아니다!

– “계속적으로 유용”하고 사용자 친화적인 경험 제공

■ 어떠한 플랫폼도 똑같이 만들어지지 않는다!

– 훨씬 더 강력하고 유용하며 “인기 있는 플랫폼”이 있기 마련

■ 고객을 알아야 강력한 Platform을 만든다!

– 플랫폼 오픈화를 통한 “소통 채널” 극대화! Do you know What your customers want?

Platform = “Technology + Ecosystem”

Ecosystem = “Community + Environment”

사용자 + Contributors + Partners

Platform 사용자

PartnersContributors

Evangelize

Feedbacks

Evangelize Contribute

Evangelize

Collaborate

Promote

Feedback

19

■ Current status of SW development resources

- Android developers > Web developers >> Embedded developers

Prospective IoT SW Developers

20

Samsung IoT ARTIK Family

■ Support E2E IoT use case scenario from sensor device to cloud

Clouds

Rich devices

Constraineddevices

ARTIK 05x (WiFi)

ARTIK 020 (BLE)ARTIK 030 (ZigBee)

ARTIK 5X0

[Ref.] https://www.artik.io

ARTIK 710

Cortex-M4/32KB/256KB

Cortex-M4/32KB/256KB

Cortex-R4/1.4MB/8MB

4xCortex-A9/GPU512MB|1GB/4GB

8xCortex-A53/GPU1GB/4GB

21

ARTIK Key Differentiations

22

ARTIK Security

■ Providing differentiated end-to-end security solution

■ Proven security technologies combining HW and SW security

[Ref.] https://www.tizen.org/sites/default/files/event/a1_tdc15_artik_-_the_ultimate_platform_solution_for_iot.pdf

23

ARTIK Cloud

■ Connect devices to be analyzed and visualized anytime, anywhere!

[Ref.] https://www.tizen.org/sites/default/files/event/a1_tdc15_artik_-_the_ultimate_platform_solution_for_iot.pdf

24

Device

ARK API

ML BP

API call

• Fragmented API

- Inconsistent Dev Exp. because of various API concepts

& styles

Decreasing usability, productivity, accessibility

• Coarse-grained Build Configurability

- Impossible image build with features tailored only for

device spec. or user-specific use cases

Over featuring and unnecessary memory usage

AS-IS

• Consistent API

- Providing consistent & developer friendly API

Excellent Dev. Exp. to increase usability, productivity,

accessibility

• Fine-grained Build Configurability

- Providing build-time feature configurability for OS,

network stack, connectivity, Services

Optimal memory footprint

TO-BE

Security

Platform

Device ML BP Security

ARK Platform

Release

Easy to develop services using one set of consistent APIs !!!

Already read the sensor data. How do I upload it to the Cloud?

Platform Requirements

25

ARTIK device use-case requirement specific image build

Build-time optimal memory footprint by selecting necessary features for OS, Network

Stack, Connectivity, Service Framework, etc.

- Consisting of component modules:

OS, Network Stack , Service

Framework, Protocols, Lib.[Low-End]

No Thread OSBLECoAPGPIO

….

OS

Wi-FiBLE

IoTivityML Lib

IP

MQTT

HTTPCoAP

LWM2M

AppFrw

SensorFrw

CloudFrw

[High-End] Multi Thread OSWiFiCoAPTCP/UDPGPIO….

[Mid-End] Multi Thread OSWiFiCoAPUDPGPIOPWM ….

Image

Image

020

053

Footprint: ~수십KB

Footprint: ~수백KB

Footprint: ~수천KB

Platform

Build-time Configuration

Device-specific Memory Footprint

Image

Platform Requirements

26

Characteristics of TizenRT

■ RTOS-based lightweight platform

■ Fit into constrained devices with Cortex-M/R MPU and less than

2 MB RAM and 16 MB Flash.

■ Cannot load additional modules at runtime

■ POSIX API, BSD Socket API, Shell, and Kconfig build

configuration

■ Adopt lightweight JavaScript environment that consists of

JerryScript and IoT.js

■ Public open: May 10, 2017 https://github.com/Samsung/TizenRT

27

Platform API Classification

■ Proprietary vs. POSIX

- Proprietary (Custom API): not compatible with other OSs

- POSIX (Open API): IEEE Standard OS Interface (Linux/Windows/iOS/TizenRT)

Ex Advantages Disadvantages Examples

ProprietaryAPI-based

• Small Memory Size• Fast Execution• Quick Interrupt Response

• No code compatibility and reusability (Esp. Linux-based codereuse)- Customer app. redevelopment- Retraining for new platform

• FreeRTOS• RIOT• Zephyr

POSIXAPI-based

• Code compatibility and reuse- existing Linux code reuse- Almost zero porting effort

• Existing Linux customer/developer-oriented

• Real-time OptionsUnpredictable interrupt latency & jitter

• Slow Booting Time• Large Memory Size

• ThreadX• QNX• VxWorks• Integrity• LynxOS• TizenRT

28

TizenRT Architecture

■ NuttX-based RTOS, called TinyAra

■ Consisting of OS, Core components, framework, and application layers

■ IPv4/IPv6 network stack, file system, lightweight database, device monitor,

and IoT protocols (IoTivity, MQTT, CoAP, and LWM2M)

https://source.tizen.org/documentation/tizen-rt

29

MQTT (Message Queue Telemetry Transport)

Official web site : http://mqtt.orgM2Mqtt project : http://www.m2mqtt.netMosquitto : http://mosquitto.orgHiveMQ : http://www.hivemq.comMQTT An implementer’s perspective : http://bit.ly/1koMZLFMQTT Another implementer’s perspective : http://bit.ly/1rHDnAN

30

Characteristics

■ Easy Messaging Protocol

■ Minimal Overhead

■ Data agnostic

■ Publish / Subscribe

■ Push instead Pull

■ Reliable even when used with unreliable networks

■ Constrained Devices

■ Low bandwidth, high latency

31

MQTT Architecture

■ Broker-based communications

Publisher(Source)

BrokerSubscriber

(Sink)

Publish (topic, info)

Publish (topic, info)

Subscribe (topic)

32

MQTT Brokering Basic Terms

■ Broker: The broker accepts messages from clients and then delivers them to any interested clients. – Key component of MQTT

■ Client: A “device” that either publishes a message to a topic, subscribes to a topic, or both

■ Topic: A namespace (or place) for messages on the broker. Clients subscribe and publish to a topic

■ Publish: A client sending a message to the broker, using a topic name

■ Subscribe: A client tells the broker which topics interest it. Once subscribed, the broker sends messages published to that topic. A client can subscribe to multiple topics

■ Unsubscribe: Tell the broker you are bored with this topic. In other words, the broker will stop sending messages on this topic.

33

MQTT Advantages in IoT

MQTT packet can be as small as 2 bytes compared to HTTP. MQTT uses binary messages to exchange information with a low overhead

Compared to HTTP which requires multiple POST actions to distribute a message to more than one client, MQTT distributes a message, or, only to a client interested

MQTT is inherently 1 to many communication

Publish-subscriber paradigm in contrast to HTTP based on request/response paradigm

Asynchronous protocol, that means that it does not block the client while it waits for the message no need to be connected at the same time (server & Client). HTTP protocol, that is mainly a synchronous protocol

Highly scalable

34

MQTT QoS

■ MQTT client sets QoS and broker honors the QoS level on each client end

■ Three levels of QoS

QoS Level 0: At most once delivery (non-persistent)

No retry semantics are defined in the protocol

QoS Level 1: At least once delivery (persistent, duplicates possible)

Server acknowledges with a PUBACK

Message is resent with DUP bit set if PUBACK is not received

35

MQTT QoS

■ Three levels of QoS

QoS Level 2: Exactly once delivery (persistent)

Two stage processes to ensure there is no duplicate message delivery

Server acknowledges with a PUBREC

Client releases message with a PUBREL

Server acknowledges completion with a PUBCOMP

https://www.slideshare.net/Hamdamboy/message-queuing-telemetry-transport-mqtt

36

CoAP (Constrained Application Protocol)

Coap Technology : http://coap.technologyOfficial draft : https://datatracker.ietf.org/doc/rfc7252/CoRE Link format : http://tools.ietf.org/html/rfc6690#section-3.1CoAPSharp : http://www.coapsharp.comCopper : https://github.com/mkovatsc/Copper

37

Characteristics

■ IETF lightweight messaging Standard for constrained devices and networks

■ Client/server protocol

■ One-to-one “request/response” interaction model

■ Interoperate with HTTP and RESTful protocol (GET, POST, PUT, DEPETE)

■ Ideal for Specialized for M2M applications

■ Compact 4-byte header

■ UDP, SMS, (TCP) Support

■ Strong DTLS security

■ Asynchronous communication

■ Build-in discovery

http://www.electronicdesign.com/iot/mqtt-and-coap-underlying-protocols-iot

38

CoAP Architecture

■ Based on REST Architecture

■ Unlike HTTP based protocols, CoAP operates over UDP

■ To compensate for the unreliability of UDP, CoAP redefines a

retransmission mechanism

39

Messaging Model

■ Supports 4 message types: CON (Confirmable), NON (Non-confirmable), ACK (Acknowledgement), RST (Reset)

■ Reliable message transport: ACK with the same message ID

If fail to process message, responses by replacing ACK with RST

■ Unreliable message transport: using NON message type with message ID

If fail to process message, server replies RST

40

Request/Response Model

■ Piggy-backed: ACK contain response message (identified by token)

■ Separate response

Server not ready to response: empty ACK

Server ready to response: a new CON, then client replies with ACK

41

Request/Response Model

■ Non Confirmable Request and response

Client sends NON type message indicating no need to confirm

Sever resend a NON type message with response

42

CoAP Security

■ DTLS for CoAP security

Considers all of integrity, authentication, and confidentiality

DTLS in application layer protects end-to-end communication

■ To protect CoAP transmission, DTLS provides three types of security

Authentication

Secure channel

Key management

43

IoTivity Open Connectivity Foundation

IoTivity Open Source Community: https://openconnectivity.orgOpen Connectivity Foundation: https://openconnectivity.org/

44

OCF and IoTivity Relationship

Specifications & Open Source ready simultaneously

OCF Specifications: https://openconnectivity.org/developer/specificationsIoTivity Open source: https://www.iotivity.org/downloads/iotivity-1.3.0

45

OCF (Open Connectivity Foundation)

■ Why OCF?

– Dilemma of current IoT world

Fragmentation, Fragmentation, Fragmentation !! (No universal language for IoT)

»Device makerLimiting market, increasing costs

»End usersAlways check compatibility & interoperability

■ OIC (Open Interconnect Consortium)

– Samsung & Intel proposed

■ OCF (Open Connectivity Foundation)

– Board members (Qualcomm, MS,..) of AllJoyn joined OIC in 2016 ➛ OIC was renamed as OCF

– Provides connectivity to any “things” regardless of their OS, connectivity technology

46

OCF Goals

■ Make it easy for developers to deal with the complexity of IoT

communications

■ Provide a common data model that developers can use to interface

with all IoT devices and their underlying data

■ Establish an architectural foundation that can achieve the necessary

scalability

■ Focus the architecture around interoperability

■ Supports the needs of multiple vertical markets (since many use

cases span multiple vertical markets)

■ Provide a path towards future consolidation of standards

47

Definition of Various Things

• By defining resources of things and its properties

• By defining functions/operations of things

48

Support of Multiple Verticals

• Legacy vertical services usually designed as silos No common way to communicate among them

• A common platform provides a foundation for vertical services to collaborate and interwork by providing common services and data models

49

IoTivity Overview

An open source software framework implementing OCF Standards

Seamless device-to-device connectivity to address emerging needs of IoT

Licensed under Apache License Version 2.0

Available on TIZEN, Android, Arduino, Linux(Ubuntu) Platforms

P2P Direct

OCF Client OCF Server

OCF Intermediary

XMPP/STUN/TURN/I

CE

Gateway

OCF Servers

OCF Client

Remote Access

Cloud

Gateway

OCF ServersCloud based intelligent Services

OCF Client

OCF Topologies Supported

CoAP over TCP

50

High Level Architecture

Base Layer

Sensing/ControlApplication

Base Layer

MessagingDiscovery

Service Layer

Device Management

Data Management

Security Discovery

Messaging

APIs(C/C++/Java/JS)

….

Security

Resource Encapsulation

Low-Power Management

Resource Container

Rich Device

Lite Device

Consumer

Enterprise

Industrial

Automotive

Health Key Goals

Common Solution

Established Protocols

Security & Identity

Standardized Profiles

Interoperability

Innovation Opportunities

Necessary connectivity

IoTivity Profiles

IoTivity Framework

IoTivity Connectivities*

51

Discovery Subsystem

Multicast announcement over Wi-Fi / Ethernet

OCF Server

OCF Client

announce resource“OCF/server”

multicastlisten

[ port 5683 ]

Multicast/Unicast over WiFi / Ethernet

OCF Server

OCF Client

multicastlisten

findresource

[ port 5683 ]

unicast response “OCF/server”

Advertise/Scan over BLE/BT

OCF Server

OCF Client

advertiseOCF service

scanOCF service

response “OCF/server”

find resource

IANA: Internet Assigned Numbers Authority

Server

Server

ClientC

CGateway

C

COAP

CCOAP

HTTP

C

COAP

Internet

Constrained Environment

Connectivity Discovery Mechanism Description

WiFi &Ethernet(over IP)

IP Multicast CoAP Multicast Port: 5683 (Assigned by IANA)CoAP Secure Port: 5684

IP Unicast over UDP Precondition:OIC Server Address & Port are known

Bluetooth(EDR &BLE)

Using Scan & Advertise OCF Specific Service UUID

Discovery within local network

52

Discovery – Finding a Resource

Application

C++ API (SDK)

C API (SDK)JSON/CBOR

Encode/Decoder

OCStack

CoAP

Connectivity Abstraction

2

1

IoTivityDevice

IoTivityDevice

IoTivityDevice

3

Multicast

4

5

6 OCPlatform::findResource(host, “/light/1”

, connectivityType, resourceHandlerCb);

OCDoResource(resourceHandle, OC_REST_GET, “/

light/1”, 0, payLoad, connectivityType, qos,

&cbData, headerOptions, numOptions);

CASendRequest(endPoint, reques

tInfo);

Send a multicast query

//Devices that matches the query answers as indicated below

OCF Client

Light192.168.1.11

Light192.168.1.12

Fan192.168.1.21

GET /oc/core?rt=light

(IP multicast)GET /oc/core?rt=light

(multicast)

GET /oc/core?rt=light

(multicast)

ACK,CONTENT

ACK, CONTENT

Function Call Flow Sequence Diagram

53

Messaging - Connectivity Abstraction

CA API

CA Control

NetworkConfig.

CoAPProtocol

InterfaceController

Transport Adapter

BLEAdapter

BTAdapter

Platform Adapter

Ubuntu Android Tizen Arduino

AndroidInterface

UbuntuInterface

TizenInterface

ArduinoInterface

TCPAdapter

IPAdapter

NFCAdapter

BlockwiseTransfer

Resource ModelCA Control Component

- Target network selection, interface control & monitoring

- CoAP message serialization & parsing

- Block-wise messaging flow control

Transport Adapter Component

- Data transmission over UDP, TCP, BLE(GATT), BT(SPP) & NFC

- Secure data exchanging using DTLS

Platform Adapter Component

- Wi-Fi, Ethernet and BLE

- Android Wi-Fi, BLE and BT

- Tizen Wi-Fi, BLE and BT

- Arduino Wi-Fi, Ethernet and BLELegend

CA Component CA Module External

Ubuntu Android Tizen Arduino

54

Messaging – CoAP over TCP

54

RD(**) ServerCoAP CI(*) Server

* CI

** RD

: Cloud Interface

: Resource Directory

3rd Service3rd Service

3rd Service3rd Service

TCP and TLS Transport for the CoAP

CoAP Default transport - UDP.

• Reliable delivery, simple congestion control & flow

control

• Provided by the message layer of CoAP

CoAP over TCP Benefits .

• To integrate well with existing enterprise

infrastructure,

• Ability to work with existing NAT boxes

• Advanced Congestion Control algorithms

• Integration with Web Environment

Resources should be registered to the Resource

Directory Service for discovery

CoAP over TCP for Cloud extension

55

Security Features & Architecture

Resource Server

(Provisioned)

Client(Provisioned)

ProvisioningManager

(Admin Device)

Ownership Transfer Credential(Key)/

ACL Provisioning

Resource Accessover DTLS

Ownership Transfer Credential(Key)

Provisioning

Client(Un-Provisioned)

AccessDeniedX

* Platform Hardening not part of the OCF Specs & IoTivity Implementation

DTLS modules, etc.DTLS modules, etc.

Connectivity Abstraction (CA) layer

Secure Resource Manager(SRM) layer

Resource Introspection (RI) layer

DTLS modules, etc.

Provisioning Manager (PM)

Ownership Transfer

Manager (OTM)

Secure Resource Provider (SRP)

ProvisioningDatabase Man

ager (PDM)Provisioning

Database

PM C API

Ownership Transfer & Provisioning ACL & Secure Communication

• Ownership Transfer (Unowned device Owned device)

• OCF device initial registration

(Administrator authentication, configuration of access control)

• Setting the credential for mutual authentication & access

policy into resource server

• Issued credential management

• Accept or Deny the Request according to the authority by check

the permission for GET/PUT/POST/DELETE request

• Status check of connected devices for mutual authentication

Resource Manager (RM)

Policy Engine (PE)

PersistentStorage

Interface (PSI)

Secure VirtualDatabase

Security Subsystem Architecture

56

LWM2M (Lightweight M2M)

LWM2M Open Mobile Alliance: http://openmobilealliance.org/iot/lightweight-m2m-lwm2mOMA Specifications: http://www.openmobilealliance.org/wp/

57

Common Needs for Device Management

57

Bootstrapping (Security)

- Service provisioning

- Key management

- Provisioning of access control lists

Firmware Update

- Updating application and system SW

- Applying bug fixes and new features

Remote management

- Changes to settings

- Trigger actuators

Fault management

- Reporting errors from devices

- Querying status of devices

Information reporting

- Notifying changes in sensor values

- Retrieving configuration settings and device status

58

LWM2M Overview

58

OMA (Open Mobile Alliance) Standard

Esp. targeted at constrained devices

- Low-power MCU and small amounts of flash and RAM

Device lifecycle management specification

- Handling device management and application data

- SW upgrade and device re-configuration

- Device monitoring and sensed data reporting

Client-server architecture

Modern architecture design based on REST

Defines a simple resource model for extensibility

Secure data transfer standard CoAP based

LWM2MServer

LWM2MClient

59

LWM2M Architecture

59[Ref] Implementing LWM2M in Constrained IoT Devices at https://www.researchgate.net/publication/281524900

Four logical LWM2M interfaces

- Bootstrap for managing access control and configuration

- Client Registration for device existence and capability

- Device management and service enablement

- Information Reporting for reporting resource information

Object model

- Accessed with simple URI: /objectID/object instance/resourceID

Client initiated & server initiated

Sensor Sensor#1 Value

60

Device S/W Stack

60[Ref] Implementing LWM2M in Constrained IoT Devices at https://www.researchgate.net/publication/281524900

61

LWM2M Message Flow

61[Ref] Implementing LWM2M in Constrained IoT Devices at https://www.researchgate.net/publication/281524900

62