Loosely Coupled Actor Systems

for the Internet of Things

Raphael HiesgenInternet Technologies GroupHamburg University of Applied Sciences

Agenda

Introduction

Where We Are

Next Steps

Risks and Conclusion

2

The Internet of Things (IoT)

• Network of nodes

• Connected through Internet standards

• Perform machine-to-machine communication

• Built from often constrained embedded devices

• Sensors and actuators

• Platform for distributed applications

3

Problem Statement

• Highly distributed applications design

• Development requires specialized knowledge

• Communication, synchronization and scalability

• Usually in low-level languages (such as C)

• Error-prone & hard to debug

• Deployment is platform-specific

4

Approach

• Actors as base entities

• Run concurrently & in isolation

• Can spawn new actors

• Distributed runtime environment

• Network transparent message passing

• Distributed error-handling

• Network of actors as a design candidate for the IoT

• Programm distributed applications

5

General Relevance

• The IoT is everywhere

• Fitness trackers (FitBit, Health Kit, Google Fit, …)

• Smart watches (Pebble, Android Wear, …)

• Home automation (Home Kit, Nest, …)

• Emerging development tools (ARM mbed [3], …)

• Number of participating devices increases

6

Relevance of the Research

• Ease application development

• Reduce the development overhead

• Professionalization, generalization and standardization

• Reusability

• Robustness

• Portability

• Provide tools to test and deploy software7

Research Question

• Can we efficiently link low-level protocols to an abstract communication between actors?

• Can we meet efficiency expectations regarding hardware resources?

• Is the actor model suitable to design and develop applications for the IoT?

• Is the actor model well suited to express typical application scenarios?

8

Agenda

Introduction

Where We Are

Next Steps

Risks and Conclusion

9

The C++ Actor Framework

• Open source implementation of the actor model [1]

• Native development in C++

• Small memory footprint

• Different runtime implementations

• Memory management & scheduler

• Static type-checking

• Runtime inspection tools 10

CAF scala erlang0

500

1000

1500

2000

2500

3000

3500

Res

iden

t Set

Siz

e [M

B]

x

99th percentile1st percentile

95th percentile5th percentile

x

Median

75th percentile25th percentile

Mean

Memory Consumption Spawning 220 actors.11

Adaption to the IoT

• Communication protocols

• Lossy links are common

• Handle infrastructure failure

• Nodes may contain private data

• Secure wireless communication

• Requires suitable messaging layer

12

802.15.4 / Bluetooth LE

6LoWPAN

UDP

DTLS

CoAP

C++ Actor Framework

Ethernet / WLAN

IPv4 / IPv6

TCP

TLS

HTTP

Network Stack Built upon open Standards13

Proof-of-Concept

• Data collection at source

• Based on Ethernet, UDP and CoAP

• Compared to TCP-based impl.

• Findings

• Fewer packets send

• Lower bandwidth used

0 500 10000

20k

40k

60k

80k

100k

120k

Bit

rate

(bit/

s)

Time (ms)

CoAP + UDP TCP

0 20 40 60 80 100 120 140 160 180 200 220 240 2600

5

10

15

20

Count

Packet Size (bytes)

CoAP + UDP TCP

14

Agenda

Introduction

Where We Are

Next Steps

Risks and Conclusion

15

Transactional Layer• 6LoWPAN

• IPv6 compatibility

• Header compression

• CoAP

• Duplicate message detection

• Reliable message transfer (transactions)

• Fragmentation of large messages

• CAF

• Message header compression

• Error propagation

16

Security

• Authentication, authorization and encryption

• Challenges

• Constrained power & energy

• Nodes physically acquired

• Crypto is hard to do right

17

Runtime Environment Runtime Environment

ActorActor

Actor

Actor

Middleman Middleman

Actor

BrokerBrokerActorProxy

ActorProxy

ActorProxy

Actor

Concept (WIP) What do we need to secure?18

Support for Embedded OSs

• The friendly Operating System for the IoT [2]

• POSIX compliance

• Energy efficient

• Real-time capable

• Development in C or C++

19

Validation

• Protocol correctness

• Packet loss & message sizes

• Application performance

• Reproducibility

• Environment heavily impacts results (e.g., interference)

• Unpredictable behavior in networks

• Requires experimentally driven design and testing20

Test Environments

• From comfortable and fast to realistic and slow

• RIOT offers a native port

• Quick tests, not a realistic environment

• Few nodes in our lab

• 7 Raspberry Pis running Linux

• USB dongles enable 802.15.4

• Useful for a proof-of-concept21

Raspberry Pi Our local test-hardware.22

However …

• Pis are not our target platform

• Have lots of power and memory

• Run Linux (like desktops)

• Only a few number of nodes

• Link interference hardly a problem

• Applications may have more nodes

23

Larger Testbeds

• FU Berlin

• 60 nodes distributed in several rooms and floors

• CC1100 radio chips, 868 MHz CPU

• INRIA Technology Institute in France [4]

• Connected through RIOT and Safest

• 2700 nodes distributed through France

24

Agenda

Introduction

Where We Are

Next Steps

Risks and Conclusion

25

Risks

• We ask too much of the hardware

• Power & energy consumption

• Memory usage

• Message sizes

• Security scheme

• Community adoption (CAF & RIOT are doing well)

26

Conclusion

• Development in the IoT required on specialized knowledge

• Network communication and synchronization

• Porting software to new hardware

• The actor model abstracts over distributed systems

• Adapt CAF to the characteristics of the IoT

• A transactional layer built from open standards

• Authentication, authorization and encryption

• Support for RIOT-OS

• Requires experimentally driven testing

27

References

[1] D. Charousset, R. Hiesgen, and T. C. Schmidt, “CAF - The C++ Actor Framework for Scalable and Resource-efficient Applications,” in Proc. of the 5th ACM SIGPLAN Conf. on Systems, Programming, and Applications (SPLASH ’14), Workshop AGERE!, New York, NY, USA: ACM, Oct. 2014.

[2] RIOT-OS., “RIOT,” www.riot-os.org, November 2014.

[3] ARM Ltd., “ARM mbed IoT Device Platform,” https://mbed.org, November 2014.

[4] INRIA, “FIT/IoT-LAB,” https://www.iot-lab.info, November 2014.

28