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
Top Related