1

Matthias Kovatsch

kovatsch@inf.ethz.ch

Scalable Web Technology

for the Internet of Things

Tuesday, 9 Dec 2014Doctoral Defense

Zurich, Switzerland

2

Connecting the Virtual and the Physical World

Environmental Monitoring

Building Automation

Logistics

3

Inexpensive Wireless Technology

Resource-constrained

computing devices

4

The Internet of Things (IoT)

Environmental Monitoring

Smart EnergyAmbient Assisted Living

Structural Health

Building Automation

LogisticsReal-time City

Information

Hundreds of billions

of connected devices

5

Challenges for the Internet of Things

Resource-

constrained

Devices

IoT Cloud

Services

Humans

in the Loop

Application-layer

Interoperability

Improved

Usability

6

Contributions of this Work

Resource-

constrained

Devices

IoT Cloud

Services

Humans

in the Loop

Protocol Design and EvaluationConcepts

and Tools

System

Architectures

and Guidelines

System

Architectures

and Guidelines

System

Architectures

and Guidelines

Constrained Application Protocol (CoAP)

7

Web Technology

Well-known Patterns

Global Interoperability

Digital

Services

8

Web Mashups

Script

Reviews Maps

Payment

Hotel booking

9

IoT Mashups

/set/valve 42

/raw/ADC2

/sensors/humidity

/PIR

Ob

se

rve

Ob

se

rve

Ob

se

rve

GE

T

if ( occupied ) {heatRoom( COMFORT_TEMP );

}

10

Research Questions

Resource-

constrained

Devices

IoT Cloud

Services

Humans

in the Loop

How can we scale

Web technology

down to constrained

environments?

How can we scale

Web technology

up to hundreds of

billions of devices?

How does

Web technology

improve usability

for developers

and users?

11

Scalable Web Technology for the IoT: Part 1

Resource-

constrained

Devices

IoT Cloud

Services

Humans

in the Loop

12

Lightweight IP and Low-power Networks

Border Router

43

2

1

6LoWPAN

Class 1 Devices

~100 KiB Flash

~10 KiB RAM

Short Frames HTTP over TCP

not a good fit

13

RESTful protocol designed from scratch

Transparent mapping to HTTP

Additional features for IoT scenarios

Push notifications (CoAP Observe)

Group communication (IP multicast)

Alternative transports (e.g., SMS)

The Constrained Application Protocol (CoAP)

Internet Engineering Task Force

14

How does this new Web protocol look like?

The Constrained Application Protocol (CoAP)

Message Sub-layer

Reliability

UDP DTLS …

Request-Response Sub-layer

RESTful interaction

GET, POST, PUT, DELETE,

URIs, and Internet Media Types

Deduplication

Optional retransmissions

Co

AP

15

Guidelines for CoAP

Fulfill the requirements of

resource-constrained devices

Focus on usability

Intuitive API similar to

normal Web frameworks

16

The Thin Server Architecture

/set/valve

/set/target

/sensors/temp

/sensors/user

/sensors/battery

/config/mode

/config/datetime

“Thin server” like in “thin client”

Web server that provides

elementary device functionality

Application-agnostic

device infrastructure

Separate application logic

from device firmware

17

0

1

2

3

4

5

6

7

8

9

10

ROM

RAM

Erbium (Er) Memory Footprint

Every Option

Mem

ory

footp

rint

[KiB

]

Re-use of

Buffers

> 90% of ROM

Still Available

18

Radio always on

Normal Operation

Evaluation of CoAP in Low-power Operation

Border

Router

CoAP Servers

in 6LoWPAN Network

CoAP

Client

Radio Duty Cycling (RDC)

Radio off

Channel

check

> 99%

19

Evaluation of CoAP

Number of hops

Energ

y p

er

req

uest

[mJ]

No duty cycling

RDC (ContikiMAC)

1 2 3 4

0

100

200

300

400

Number of hops

Late

ncy [

s]

1 2 3 4

0

0.2

0.4

0.6

0.8

1.08 Hz Channel Check Rate

RDC < 0.6%

20

CoAP fits the requirements

Resource-constrained systems can be developer-friendly

Application layers can be made energy-efficient

through an independent radio duty cycling layer

Part 1: Conclusions

Matthias Kovatsch, Simon Duquennoy, Adam Dunkels

A Low-Power CoAP for Contiki

Proc. of the 8th IEEE International Conference on Mobile Ad-hoc and Sensor Systems (MASS 2011). Valencia, Spain, 2011

Matthias Kovatsch, Simon Mayer, Benedikt Ostermaier

Moving Application Logic from the Firmware to the Cloud:

Towards the Thin Server Architecture for the Internet of Things

Proc. of the 6th International Conference on Innovative Mobile and Internet Services in Ubiquitous Computing (IMIS 2012).

Palermo, Italy, 2012

21

Scalable Web Technology for the IoT: Part 2

Resource-

constrained

Devices

IoT Cloud

Services

Humans

in the Loop

22

Scalable Web Technology for the IoT: Part 2

23

Hundreds of Billions of IoT Devices

24

State of the Art: High-performance HTTP Servers

Netgear GS108 Gigabit Switch

3 × i7-4770 CPU @ 3.40 GHz

Virtual IoT Devices HTTP-based Service

i7-4770 CPU @ 3.40 GHz

25

Throughput with HTTP Keep-Alive

0 k

50 k

100 k

150 k

200 k

250 k

300 k

350 k

400 k

10 100 1,000 10,000

Re

qu

est

s p

er

seco

nd

Number of concurrent clientsJetty Vert.x Grizzly Tomcat Node.js Apache + PHP

New traffic

patterns

Very high

concurrency factors

for IoT services

26

Throughput without HTTP Keep-Alive

0 k

50 k

100 k

150 k

200 k

250 k

300 k

350 k

400 k

10 100 1,000 10,000

Re

qu

est

s p

er

seco

nd

Number of concurrent clients

Jetty Vert.x Grizzly Tomcat Node.js Apache + PHP

27

CoAP-based architecture

inspired by HTTP servers

Staged Event-Driven Architecture[Welsh et al. 2001]

PIPELINED[Choi et al. 2005]

A Scalable Architecture for IoT Cloud Services

28

The Californium Architecture

Sta

ge

1

Network

Sta

ge

2

Processing PipelineBook-

keeping

Protocol

Sta

ge

3Business Logic

Client Role(Response Handlers)

Server Role(Resource Handlers)

29

Evaluation of CoAP in the Service Backend

Netgear GS108 Gigabit Switch

3 × i7-4770 CPU @ 3.40 GHz

Virtual IoT Devices CoAP-based Service

i7-4770 CPU @ 3.40 GHz

30

Throughput with CoAP-based Services

0 k

50 k

100 k

150 k

200 k

250 k

300 k

350 k

400 k

10 100 1,000 10,000

Re

qu

est

s p

er

seco

nd

Number of concurrent clients

Californium Initial Cf Sensinode txThings OpenWSN nCoAP

31

Comparison to the State of the Art

100

1,000

10,000

100,000

1,000,000

10 100 1,000 10,000

Re

qu

est

s p

er

seco

nd

(lo

g.)

Number of concurrent clientsCalifornium Initial Cf Sensinode txThings OpenWSN nCoAPJetty Vert.x Grizzly Tomcat Node.js Apache + PHP

32

CoAP also has benefits in less constrained environments

Connectionless

Low parsing complexity

Our architecture is highly scalable

64 times better than high-performance HTTP servers

First published architecture for CoAP backend services

Part 2: Conclusions

Matthias Kovatsch, Martin Lanter, Zach Shelby

Californium: Scalable Cloud Services for the Internet of Things with CoAP

Proceedings of the 4th International Conference on the Internet of Things (IoT 2014).

Cambridge, MA, USA, October 2014

33

Scalable Web Technology for the IoT: Part 3

Resource-

constrained

Devices

IoT Cloud

Services

Humans

in the Loop

34

IoT Mashups

/set/valve 42

/raw/ADC2

/sensors/humidity

/PIR

Ob

se

rve

Ob

se

rve

Ob

se

rve

GE

T

if ( occupied ) {heatRoom( COMFORT_TEMP );

}

35

Runtime system for

server-side JavaScript

CoapRequest Object API

for direct device interaction

Running applications

modeled as Web resources

RESTful lifecycle management

A RESTful Runtime Container for the IoT

36

Web Browser Support for CoAP

coap://sky025.h108/sensors/light

37

User Study with 48 Participants

Copper (Cu)

41%

libcoap

client

17%

Sensinode

NanoService

Java Client

5%

Californium (Cf)

GUI client

5%

Californium (Cf)

console client

10%

other

22%

Web browser

integration of CoAP

77%

standalone

23%

For user interaction

CoAP Client Market Share User Preference

38

Agreement on the Likert Scale

Internet protocolsease the

development

Web patterns easethe development

CoAP in addition toHTTP is a necessity

Strongly agree

Agree

Neutral

Disagree

Strongly disagree

(Error Bars ±1 std. dev.)

39

Web-like mashups among IoT devices are feasible

The Web browser is a valuable tool for the IoT

Users agree with our hypotheses on

improved usability through Web technology

Part 3: Conclusions

Matthias Kovatsch, Martin Lanter, Simon Duquennoy

Actinium: A RESTful Runtime Container for Scriptable Internet of Things Applications

Proceedings of the 3rd International Conference on the Internet of Things (IoT 2012). Wuxi, China, 2012

Matthias Kovatsch

CoAP for the Web of Things: From Tiny Resource-constrained Devices to the Web Browser

Proceedings of the 4th International Workshop on the Web of Things (WoT 2013). Zurich, Switzerland, 2013

40

Summary

Resource-

constrained

Devices

IoT Cloud

Services

Humans

in the Loop

41

Open source projects

http://www.contiki-os.org/

http://www.eclipse.org/californium/

https://addons.mozilla.org/en-US/firefox/addon/copper-270430/

Standardization of CoAP within the IETF

http://tools.ietf.org/html/rfc7252

http://tools.ietf.org/wg/core/

Contributions

Questions?

Matthias Kovatsch https://github.com/mkovatsc/

kovatsch@inf.ethz.ch http://people.inf.ethz.ch/mkovatsc/

43

Observing Resources

Server

Client

Resource state at origin server

Replicated state at client

Notification

lost

Max-A

ge

44

Observing Resources – CON Notifications

Server

Client

Resource state at origin server

Replicated state at client

45

Group Communication

PUT /control/color#00FF00

Enabled by IP multicast

46

ContikiMAC

A

D

A

D A

ACK frame

Data frame

Radio on

Sender

Receiver

Transmission detected

DD DD

Channel check

47

Link-layer Bursts

A

AD

Sender

Receiver

Transmission detected

DD DD

Channel check

A

AD

D A

AD

D A

AD

D

D

A ACK frame

Data frame

Radio on

48

Transmitting Larger Payloads

0

5

10

15

20

25

30

35

40

45

50

55

60

65

70

75

80

85

90

95

100

0 128 256 384 512

En

erg

y [

mJ]

CoAP payload [B]

4 Hops

2 Hops

1 Hop

0.0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1.0

1.1

1.2

1.3

1.4

1.5

1.6

1.7

1.8

1.9

2.0

0 128 256 384 512

Late

ncy [

s]

CoAP payload [B]

49

Transmitting Larger Payloads (Weekend)

0

5

10

15

20

25

30

35

40

45

50

55

60

65

70

75

80

85

90

95

100

0 128 256 384 512

En

erg

y [

mJ]

CoAP payload [B]

4 Hops

2 Hops

1 Hop

0.0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1.0

1.1

1.2

1.3

1.4

1.5

1.6

1.7

1.8

1.9

2.0

0 128 256 384 512

Late

ncy [

s]

CoAP payload [B]

50

The Impact of Link-layer Bursts

0.0

0.2

0.4

0.6

0.8

1.0

1.2

1.4

1.6

1.8

2.0

0 128 256 384 512

La

ten

cy [

s]

CoAP payload [B]

2 Hops

1 Hop

0.0

0.2

0.4

0.6

0.8

1.0

1.2

1.4

1.6

1.8

2.0

0 128 256 384 512

La

ten

cy [

s]

CoAP payload [B]

51

Californium

Architecture

3 stages

Central state

management

Independent

concurrency

models

B2

B1

A2

A

Root

Sta

ge

3:

Clie

nt

Client for Y

Client for X

Async. ClientB

A1

Sta

ge

1S

tag

e 2

: P

roto

co

l (C

oA

P)

Sta

ge

3: B

usin

ess L

og

.

Network Transport (socket I/O)

Exch

an

ge

Sto

re

Blockwise Layer

Observe Layer

Token Layer

Reliability Layer

Matching & Deduplication

Message Serialization

ma

in

52

Laptop

Intel Core i7-3720M

CPU @ 2.6 GHz

(Hyperthreading and

Turboboost disabled)

24 GiB RAM

Intel 82579 LM Gigabit

Multi-core Utilization

53

Lab machine

Intel Core i7-4770

CPU @ 3.40 GHz

(Hyperthreading and

Turboboost disabled)

16 GiB RAM

Intel Ethernet

Connection I217-V

Comparison with the State of the Art

54

Multi-core Utilization

0 k

20 k

40 k

60 k

80 k

100 k

120 k

140 k

10 100 1,000 10,000

1 core

2 cores

3 cores

4 cores

0 k

20 k

40 k

60 k

80 k

100 k

120 k

140 k

10 100 1,000 10,000

Number of concurrent clients Number of concurrent clients

Re

qu

es

tsp

er

se

co

nd

Initial-Cf Californium

55

Intel Xeon E3-1265LV2 @ 2.5 GHz

0 k

40 k

80 k

120 k

160 k

200 k

240 k

10 100 1,000 10,000

Re

qu

est

s p

er

seco

nd

Number of concurrent clients

Cf 1/2/2 Initial-Cf Sensinode nCoAP Cf 4/4/4

56

Config

A RESTful Runtime Container for the IoT

ConfigPOST

2.01 Created

Sandbox/running/my-instance REST API

/installed/my-script

PUT

2.04 Changed

Script POST

2.01 Created

/install

/instances/my-instanceDELETE

2.02 Deleted

57

Actinium (Ac) Round-Trip Time Overhead

1000 Requests Minimum Maximum Average Overhead

Ping 32ms 77ms 46ms

CoAP (Cf) 34ms 78ms 48ms +2ms

Actinium 33ms 97ms 49ms +1ms

Subnet A Subnet B

SLIP

802.15.4CH 21

Mote 1..10Border router

App server Router

LLN

58

Performance: Quicksort (Memory-intensive)

Act

iniu

m e

xecu

tio

n t

ime

[m

s]

0

200

400

600

800

1000

1200

1400

Pe

rfo

rman

ce f

acto

rs

Array size

1

6

11

16

21

Java

node.js

Actinium

0 1E+5 2E+5 3E+5 4E+5 5E+5

59

Performance: Newton (Arithmetics-intensive)P

erf

orm

ance

fa

cto

rs

1

6

11

16

21

Java

node.js

Actinium

Act

iniu

m e

xecu

tio

n t

ime

[m

s]

0

200

400

600

800

1000

1200

1400

0 1E+6 2E+6 3E+6 4E+6 5E+6

Number of computations

60

Agreement with our Hypotheses

0

1

2

3

4

Internet protocolsease the

development ofdistributed software

for tiny devices.

Web patterns easethe development ofdistributed software

for tiny devices.

CoAP in addition toHTTP is a necessity

for the Internet ofThings.

I expect native Webbrowser support forCoAP in the future.

I prefer using aHTTP-CoAP cross-proxy for accessing

devices.

Overall

Academia

Industry

Less than5 years

5 yearsand more

Responses from 48 participants on the Likert scale

(0 = strongly disagree, 4 = strongly agree, error bars: +/- 1 std. dev.)

61

Elements

Origin

Server

User

Agent

Origin

Server

Non-Web

Origin

Server

Resource

User

Agent

Browser

IoT Mashup

Engine

Forward

Proxy

Reverse

Proxy

Inter-

mediary

Gateway

Web server

Bluetooth

device

Components Data Connectors

Inter-

mediary

Inter-

mediary

(Metadata)

62

Client-Server

Stateless

Cache

Uniform Interface (HATEOAS!)

Layered System

(Code-On-Demand)

Set of Constraints

63

All RESTful Web services use the same interfaces

that are defined by

URIs to identify resources

Representations to manipulate resources

State transfer

No RPC-like service calls

Self-descriptive messages (also see Stateless)

Well-defined media types

Standard set of methods

Independent from transport protocol

HATEOAS...

Uniform Interface Constraint

define semantics

64

Application as finite-state machine (FSM) at the client

Hypermedia As The EngineOf Application State

◾ Clients start from an entry URI

or a bookmark

◾ Response to a GET request

has a hypermedia representation

◾ It contains Web links that represent

transitions in the application FSM

◾ The media type is pre-defined and

tells the client how to formulate the

requests to fire a transition

◾ URIs and possible transitions are

never hardcoded into the client,

that is, the client “learns” the

application on the fly

⇒ loose coupling to evolve independently

User Agent

Entry URI / bookmark