The traditional approach of both "Big fat webserver device" and "Virtual cloud device" has some inherent challenges not easily solved. These are privacy, autonomy, latency, establishing multiple and adaptable dataflows after deployment.

1. Using peer-to-peer and distributed
technologies to solve the IoT challenges
Presentation at ”Living bits and things 2013”
www.nabto.com
Carsten Rhod Gregersen, Founder

2. CONTEXT: WHY DEVICE INTERNET?
PRODUCT
Installation
Quality assurance
Customers
Support
?
Accounting

3. ESSENTIAL NEEDS
Translates into two major requirements:
Graphical GUI - interact directly with the device
Data acquisition - monitor and analyze data
GUI
HTML5/
APP
Device
Firmware
Data
Acquisition
IOT Device
End users
Analysis &
Monitoring

4. THREE TYPES OF IOT
Fat Webserver
Device
Virtual cloud
device
Client reachable
P2P/VoIP device
(Skype)
Client
Client
Virtual
Device
Graphics, Javascript,
Templates, Stylesheets
Cloud
Remote
Connect API
Firewall
GUI LOGIC
DB
FS
HTTPD
TCP/IP
(RT)OS
Firewall

Data acquisition
and push logic
Connect API
(RT)OS
(RT)OS

5. CLOUD DEVICE IOT APPROACH
At firmware creation time:
What, When, Where to push data?
Data
Analysis
End users
Data storage layer
HTTP
Web
frontend
Data
Acquisition
Backend
Data push
protocol
Device
Logic
Data push
logic

6. SOME OBSERVATIONS
• No internet -> No GUI
– Low autonomy
• Data requirements changes over time
– Firmware has to be upgraded continuously
• Firmware decides data push
– Firmware has limited resources and knowledge, so normally
simplistic algorithms for push are chosen
• Scales : O(<DEVICES> x <TIME> x <DATAFOOTPRINT>)
• Postulate: 95% of all data is ”normal” and not relevant
– Two standard deviations
– You don’t need full population knowledge to do statistics

7. P2P/VOIP IOT APPROACH - SCHEMATIC
Connect request
GUI or
Data
Collector
Client
Connect
API
Basestation
VoIP : SIP server
Skype : Supernode
P2P connection for
Data acquisition or GUI
Identification & Awareness
Device
Connect
API
Device
Logic
• Basestation act as an internet “PABX” for devices
• Basestation knows current internet “status” of devices and
can mediate connections from clients to devices
• Technology is similar to VoIP/Skype etc

8. NABTO PLATFORM
Every device is given and identified by a unique identification <serial>.<vendordomain>.net
Total device footprint typically about 10 kB of flash and 2 kB of RAM
Direct interaction with device through peer-to-peer connection (with local (offline) support)
Strong security, integrity and authentication
Full privacy - No device data stored in cloud solution (data-acquisition and storage is optional)
Provides full, interactive web experience – even on very limited devices with no HTTP/TCP stack
• Platform abstraction layer is
12 functions
• 36 different platforms
supported via FreeRTOS
partnership

9. P2P CLIENT REACHABLE DEVICE APPROACH
• P2P connection is a generic data connection
• Possible CoAP and DTLS support
• Authenticated clients can access device data
• No decisions upon firmware creation!
• Usage both HTML5-GUI and/or Data acquisition
IOT Device
PC, Tablet,
Smartphone, etc.
HTML5
GUI
P2P
Back office
Connect
API
Data
Acquisition
Firmware
P2P

10. DISTRIBUTED HTML5 COMPUTATION
PC/Mobile/Tablet
Device
Direct P2P connection
Low bandwidth raw data
Browser
Protocol
Plugin
Firmware
Plugin Data cache
HTML
Device
Driver
HTML
Device
Driver
(English)
Plugin technology enables distributed
GUI computation – high autonomy
(German)
HTML
Device
Driver
HTML
Device
Driver
(OEM A)
(OEM B)
•
Downloaded automatically on first device connect
•
Alternatively distributed on DVD/USB etc.
Full autonomy, scaling, flexibility and
GUI differentiation based on client
version/model/language etc.

11. EXAMPLE APPLICATION: DANFOSS SOLAR

12. OBSERVATION: ADAPTIVE DATA-ACQUISITION
Since the cloud initiates the P2P connect, it can easily be configured to do
adaptive Data acquisition
Nabto
Data API
Embedded
Logic
IOT Device
P2P
Data
Acquisition
Acquisition
Timer
External
Trigger
Example:
Weather forecast

13. OBSERVATION: MULTIPLE DAQ FLOWS
Multiple P2P connections for multi-flow data acquisition
DAQ system 1
P2P
P2P Data
Acquisition
DAQ system 2
P2P
Data API
P2P
Embedded
Logic
IOT Device
P2P Data
Acquisition
DAQ system 3
P2P
P2P Data
Acquisition

14. DIFFERENT DATA-FLOW AND PRIVACY NEEDS
Reason and requirements:
OEM buy the XYZ product/component. It’s used in a larger
complex composite product. The data from XYZ
component is used in a larger system of control and dataanalysis. OEM want full data control – cannot share data
Connect
API
DAQ
A
Production
Connect
API
Reason and requirements:
We have observed that systems in which temperatures in
the “ABC” part rises over long terms will at some point
fault. We generally only coarsely monitor, but devices
reaching a certain temperature threshold we switch to
monitoring and storing very fine grained and of course
inform our customers about potential issues.
R&D / QA
DAQ
B
OEM Customer
Connect
API
Reason and requirements:
We need to very fine-grained monitor and store data of
devices in batch 482 and 593, because we are investigating
a possible production error. Also serial 482934, 84992,
84932 we need to observe closely, they have been flashed
with a new firmware going into production soon.
DAQ
OEM

15. IOT CHALLENGES
Generic:
• Identification and addressability
• Authentication and privacy
• Adaptable data flow
• Autonomy, robustness and stability
Operational
• Future proof solution
• Ease-of-use, easy adoption
• Scalability
• Time-to-market
• Cost

16. CLOUD VIRTUAL VS. P2P/VOIP - DEVICE
Challenge
Identification and addressability
Authentication and privacy
Adaptable data flow
Autonomy, robustness and
stability
Flexible to changing needs
Ease-of-use, easy adoption
Scalability
Time-to-market
Cost
Latency
Virtual device
P2P/VoIP
Depends
Through central services



Autonomy – no
Single point of service

Only if data collection
need doesn’t change

Pure internet
environments - yes

DATA x TIME x DEVICES
DEVICES ()
Data-needs to be known
at firmware creation

See scalability


Transmission only
Moderate

17. EXAMPLE PRODUCTS
Danfoss Solar Inverters: Monitoring / Control solution
Cosesy: Residential Alarm system
WindowMaster (Velux): Skylights and Window Controller

18. EXAMPLE APPLICATION: ”INDUSTRIAL CONTROL”

19. OTHER CURRENT USES OF PLATFORM
STREAMING APPLICATIONS
- Serial link gateway (RS232/RS485)
- Video streaming (DVRs, cameras)
- Audio streaming (hearing aids)
- Firmware updates
- Remote desktop (VNC tunnelling)
VPN APPLICATIONS
- Honeywell EBI BACnet building automation
- Ritzau News Agency
DATA ACQUISITION
- Water heaters
- Wind turbine production data
- Indoor climate statistics

20. www.nabto.com
Founder, Carsten Rhod Gregersen – crg@nabto.com