The presentation describes a variety of solutions in the IoT area and provides hints on creating distributed systems. It focuses on modern standards in the field of IoT, their disadvantages and prospects. This presentation by Oleksii Savochkin (Engineering Team Lead, Consultant, GlobalLogic Lviv) was delivered at GlobalLogic Lviv Embedded Tech Talk on November 23, 2017.

1. 1
Mesh IoT Networks Explained
Oleksii Savochkin
Team Lead, Engineering
23 Nov 2017

2. 2
Agenda
1. IoT History ... already?
2. IoT dimensions overview
3. What is Mesh Network and will it solve the problems?
4. Challenges of High integrated mesh

3. 33
IoT History ... already?

4. 4
First it was like...
1982 Coke Machine
Who: Carnegie Mellon University students.
They installed micro-switches in the Coke
machine to sense how many bottles were
present in each of its six columns of bottles.
Message Example:
EMPTY EMPTY 1h 3m
COLD COLD 1h 4m
Finger requests are part of standard ARPANET
(now Internet) protocols, people could check the
Coke machine from any computer anywhere on
the internet by saying "finger coke@cmua".

5. 5
First it was like...
1990 Toaster
Who: Simon Hackett, John Romkey.
Connected a Sunbeam Deluxe Automatic
Radiant Control Toaster to the Internet.
Connected to with TCP/IP networking,
controlled with a Simple Networking
Management Protocol Management Information
Base (SNMP MIB).
Had one control, to turn the power on, and the
darkness of the toast was controlled by how
long the power was kept on.
A human being still had to insert the bread.

6. 6
First it was like...
1993 Webcam
Who: Cambridge - Dr. Stafford-Fraser
"They would often turn up to get some coffee
from the pot, only to find it had all been drunk"
Installed camera grabs images three times a
minute, and they wrote software that would
allow researchers in the department to run the
images from the camera on their internal
computer network.
"The first version was probably only 12 lines of
code, probably less, and it simply copied the
most recent image to the requester whenever it
was asked for."

7. 7
And then...
1994 Internet/Radio player
1994 Smartphone
1995 VOIP software
1999 “Internet of Things”
MQTT CoAP
2000-th
3G Z-Wave Zigbee Bluetooth
2010-th
4G/LTE BLE
AllJoyn Threads MQTT 3.1

8. 8
First Wireless Data Network
1971 ALOHA System
First version of the protocol ("Pure ALOHA")
Who: University of Hawaii
Rules:
● If you have data to send, send the data
● If, while you are transmitting data, you
receive any data from another station,
there has been a message collision.
All transmitting stations will need to try
resending "later".
Its became a 1G mobile prototype
for signaling and control purposes in 1980’s

9. 9
First Wireless Data Network
1971 ALOHA System
Pure Slotted
Time Time

10. 1010
IoT Dimensions

11. 11
IoT Growth

12. 12
Confidential
The range of IoT technologies is vast — even the largest technology companies
are challenged to deploy the full range of expertise required to transform their
business with IoT
Streaming and
Batch Analytics
Platform
Mobile
Embedded
Big Data
Cloud
DigitizationFunctions
Security
DESIGN
Architecture
EndUserand
Management
Sensors
Workflow
Historical
Data
External
FederatedData
Deep
Insights
Connected Devices
and Systems
Actuators
Fast Decision Making
Dev.
Ops.
Content
M2M
Devices
Intelligent
Gateways
Notifications
Device
Management
Platform
Complex
Actions
CEP
PaaS
Provisioning
Clients
Applications
IoT Complexity

13. 13
IoT Fragmentation - Radios Standards

14. 14
• MQTT / TLS
• Alljoyn
• Kafka
• Amazon IoT
• Google IoT
• LvM2M
○ JSON
○ TLV
○ Opaque
○ Text
• XMPP
• HTTP
Protocols
Sensor/Actuator
• Pressure sensors, camera, stepper motor,
etc.
Controller
• Collects, processes and stores data;
implements some custom IFTTT etc.
• Sensors or Actuators can connect to it
• Can talk to other Controllers or M2M
Gateway
M2M Gateway
• Provides Internet access to one or some
set of Controllers
• Can be smart enough to implement
custom IFTTT or other logic
System components
Controller
Sensor
Actuator
M2M
Gateway
IoT Fragmentation - Protocols

15. 15
• Amazon with Alexa
• Google Brillo
• Apple HomeKit
• IBM Watson
• ARM mbed
• At&T Digital life
And thousands of smaller ones ...
Top platforms
IoT Fragmentation - Platforms

16. 16
IoT Fragmentation - Technologies
Full Web stack technologies:
AllJoyn
Communication
framework
OpenFire
Real time
collaboration server
HTTP RESTMQTT
Client-server
communication protocol
Lightweight
messaging protocol
ActiveMQ
Message broker
Data Types:
SQL/NoSQL
Database
management
systems
Protobuf
Data serialization
framework
SSLSQLite
Cryptography and
SSL/TLS Toolkit
Cross-platform SQL
database engine
Object-relational
mapping framework
Hibernate
Telemetry
Data from sensors
in RAW format
Data Streams
Video and raw data
streaming
Connection
protocols
Text
Connection and
onboarding protocols
for various types of
devices.
String messages
from smart devices
Secured data
Authentification
Certificate signing
secured protocols
support

17. 17
Single-board computers:
● A low-power, low-cost single-board computer development platforms.
● ARM Broadcom BCM2835 quad core based computer boards.
● Texas Instruments OMAP4430 system on a chip (SoC).
● Qualcomm 410c SoC with Linux 3.16 Core
Development hardware:
● ESP8266 - a low-cost
highly integrated Wi-Fi
SOC chip with full
TCP/IP stack.
● Arduino - open-source
electronic prototyping
platform.
● Dallas Semiconductor
sensors & actuators.
Mobile Applications:
● Sensors
● Simulator applications
● Controller applications
Production Hardware:
● ZigBee controllers/devices
● Z-Wave controllers/devices
● LifX bulbs
IoT Fragmentation - Developers hardware

18. 18
IoT Fragmentation - Developers hardware diversity

19. 19
IoT Fragmentation Layers

20. 20
IoT On-Field Infrastructure Layers
Physical Entity Layer
(Automobiles, Home Appliances, Patients, etc. )
Node Management and Interface Layer
(Sensor Devices, Actuator Devices, Tag Reader Devices,..)
CoAP/MQTT/HTTPS/Binary etc.
External
M2M
Applications
Software
Systems
Resources
M2MTier
(IoTMeshNetwork)
ConstrainedNetwork
Root Node Layer
(Controller)
Cloud

21. 2121
What is Mesh Network and will it
solve the problems?

22. 22
IoT Mesh - what is it for?
● Cross domain - combining different devices running on different standards and
protocols
● Independent - help devices to communicate between each other even without
‘Cloud’ solution
● Flexible - designed as a plugin system, all parts of software acts as separate
microservice application, which corresponds on specific set of functionality
● Lightweight - core part of IoT Mesh is and can run on different platforms from
laptops and PC's to embed SoC’s with limited resources, like home routers
● Easily portable - plugins could be implemented by a variety of languages to
support easy protocol
● Pluggable - Hot plug/connection devices support (USER INTERACTION)
● Less dev effort - data exchange protocol is understandable

23. 23
“Decentralized” vs “Distributed”
Centralized
Telecom
Decentralized
Internet
Distributed
Latency vs Throughput...

24. 24
“Decentralized” vs “Distributed”
Centralized
Telecom
Decentralized
Internet
Distributed
What People Think
Real Mesh Networks Should Look Like

25. 25
“Decentralized” vs “Distributed”
Centralized
Telecom
Decentralized
Internet
Distributed
What Real Mesh Networks
Actually Looks Like
What People Think
Real Mesh Networks Should Look Like

26. 26
“Decentralized” vs “Distributed”
Distributed
Not Possible!
Why we can’t provide distributed IoT network?
•Network Data inconsistency
•Security gap(who will know about data exchange?)
•Linking Multiple Connections - expensive H/W
• You cannot simply connect to another IoT device
whenever you want - you need a linked channel or a
series of linked channels
• Your data can’t be in two places at the same time
• Who will store Network map or routing tables?
• More questions than answers, really?

27. 27
“Mesh-like” Network
Internet Connectivity Enabler: Root Node - Gateway - Middleware
Controller - Router - Routing Slave Node
End-point Device -Slave Node

28. 28
Traditional vs Pure Plug-In architecture
Host application
plug-in plug-inplug-in plug-in
plug-in
(Node)
Core App (Root Node)
plug-in
(Node)
plug-in
(Node)
plug-in
(Node)
plug-in
(Node)
Pure Plug-in engine (Root Node):
• Finding, loading/connecting/running the plug-in(Node)
• Maintaining a registry(network map) of connected plug-ins(Nodes) and the functions they provide
• Managing the plug-in extension model(Protocol Version) and inter-plug-in dependencies

29. 29
“Mesh-like” Network - Routing Table Example
Connectivity Enabler: Root Node - Gateway - Middleware - Controller
Router - Routing Slave Node
End-point Device -Slave Node
1
2
3
4
5
6
Source
Nodes
to 1 to 2 to 3 to 4 to 5 to 6
Node 1 X 1 1 0 0 0
Node 2 1 X 1 1 1 0
Node 3 1 1 X 1 1 0
Node 4 0 1 1 X 1 0
Node 5 0 1 1 1 X 1
Node 6 0 0 0 0 1 X

30. 30
“Mesh-like” Network -Routing Table Example
Connectivity Enabler: Root Node - Gateway - Middleware - Controller
Router - Routing Slave Node
End-point Device -Slave Node
1
2
3
4
5
6 Neighbours Route Possible functions
Controller/
Middleware
Knows all
neighbours
Has access to
complete routing table
Can communicate with every device in
the network, if route exists
Slave Node
Knows all
neighbours
Has no information
about routing table
Can only reply to the node which it has
received the message from. Hence,
can not send unsolicited messages
Routing
Slave
Knows all
neighbours
Has partial knowledge
of routing table
Can reply to the node which he has
received the message from and can
send unsolicited messages to a
number of predefined nodes he has a
route too

31. 31
Node reference Data Model
● Schema: [ { name:type } ]
Capabilities
● Description
● Certificate
● GUID
● VID
● PID
● Protocol Version
Device Info

32. 32
IoT Node connection steps
I. Authentication
II. Authorization
III. Announce
IV. Communication
Valid
Not valid

33. 33
Authentication steps
Node with ID/Serial
Connected Node
Unknown Node Manual Registration
Authorization
Controller
− If Signed Device does not pass the authorization
Try to pass the authorization
− If Serial does not present in the DB
Try to validate device by the serial

34. 3434
Challenges of High integrated mesh

35. 35
IoT - Area of Highly integrated Solutions
High-Level example of integrated system

36. 36
IoT Integration Issues
Security
Many new nodes being added to networks, internet will provide malicious actors with innumerable attack
vectors, especially since a considerable number of them suffer from security holes.
Connectivity
IoT devices can be charged on mission-critical operations and servers take on data gathering and
analytical responsibilities. Networks grow to join billions and hundreds of billions of devices, middleware
and cloud systems will turn into a bottleneck.
Compatibility and Longevity
Varieties of M2M protocols. Diversities in firmware and operation systems among IoT devices.
Data and Process Integration
Complexity in terms of scaling and IoT management processes.
Data sources can rapidly get out of sync.
Intelligent Analysis & Actions
Inaccurate analysis due to flaws in the data and/or model, ability to analyze unstructured data, ability to
manage real-time data, machine's actions in unpredictable situations, slow adoption of new technologies.

37. 37
Complexity of integrated IoT Mesh development/support
The majority of problems are generally manifestations of distributed systems that inherits complexity
from the unpredictable, asynchronous, and highly diverse nature of the physical world they are trying to
re-present. Number of distributed services are growing, log tools and bug tracking became ineffective to
find the root causes of the issues.
Challenges:
⑅ Services Failures
⑅ Communication medium failures
⑅ Transmission delays
⑅ Distributed agreement problems
⑅ Impossibility result
⑅ Heterogeneity
⑅ System establishment
⑅ Security
⑅ Scalability
⑅ Fault handling
⑅ Concurrency
⑅ Transparency
Goals:
✓ Isolate failure points
✓ Protect system from partitioning
✓ Help to debug lost/delayed message issues
✓ Help to investigate system inconsistency
✓ Distributed execution debug
✓ Fault handling improvement
✓ Issue tracking effectiveness
✓ Automatic Security checks
✓ Automatic performance/replication checks

38. 38
Scalable Fault tolerance End-to-end IoT solution
Middleware
provider
End User and Clients Management
C2C
Device
Historical
Data
End-point
Devices
Cloud
Middleware
Sensors/Actions
provider
Meta
Provider
Cloud Middleware
● Provided by 3rd party Cloud API
● Access is managed by 3rd party user
token, stored in Cloud Middleware
● User registration
● Device connection using providers
● History features
● Device control
Automatic bridge
between Cloud Middleware and
Endpoint Devices.
No user interactions are involved.
● SmartHub management
● ZWave, ZigBee, WiFi devices
● Rule Engine
● Notification Engine
● Cloud to Cloud devices
● Home access management
User involved in: Accounts registration, Devices registration, Home Access Management, Rule Management, Notification Management,
Device Control(locally/physically, by 3rd party API, by Connected Home API, by Rules triggering)
Create/Manage Accounts
Create/Manage Devices
Create/Manage Rules
Create/Manage
3rd party accounts
Create/Manage
3rd party
devices
Create/Manage accounts
Create/Manage Devices
Get History
Core
3rd party
Cloud API
3rd Party
Cloud
API
3rd party
Provider
3rd party
Provider
External
Federated
Data

39. 39
Oleksii Savochkin
Thank you
GlobalLogic