mesh iot networks explained

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

Upload: globallogic-ukraine

Post on 22-Jan-2018

144 views

Category:

Technology


1 download

TRANSCRIPT

1

Mesh IoT Networks Explained

Oleksii Savochkin

Team Lead, Engineering

23 Nov 2017

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

33

IoT History ... already?

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

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

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

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

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 prototypefor signaling and control purposes in 1980’s

9

First Wireless Data Network

1971 ALOHA System

Pure Slotted

Time Time

1010

IoT Dimensions

11

IoT Growth

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

Dig

itizatio

n

Functions

Security

DESIGN

Architecture

En

d U

se

r a

nd

Ma

na

ge

me

ntS

enso

rsWorkflowHistorical

Data

Exte

rnal

Fed

era

ted

Data

Deep

Insights

Connected Devices

and Systems

Actuators

Fast Decision Making

Dev.

Ops.

Content

M2M Devices

Intelligent

Gateways

Notific

atio

ns

Device

Management

Platform

Complex

Actions

CEP PaaS

Pro

vis

ionin

g

Clie

nts

Applications

IoT Complexity

13

IoT Fragmentation - Radios Standards

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 someset of Controllers

• Can be smart enough to implement custom IFTTT or other logic

System components

Controller

SensorActuator

M2MGateway

IoT Fragmentation - Protocols

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

IoT Fragmentation - TechnologiesFull Web stack technologies:

AllJoynCommunication framework

OpenFireReal time collaboration server

HTTP RESTMQTTClient-server communication protocol

Lightweight messaging protocol

ActiveMQMessage broker

Data Types:

SQL/NoSQLDatabase management systems

ProtobufData serialization framework

SSLSQLiteCryptography 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

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

IoT Fragmentation - Developers hardware diversity

19

IoT Fragmentation Layers

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

Re

so

urc

es

M2

M T

ier

(Io

T M

esh

Ne

two

rk)

Co

nstr

ain

ed

Ne

two

rk

Root Node Layer(Controller)

Cloud

2121

What is Mesh Network and will it solve the problems?

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

“Decentralized” vs “Distributed”

Centralized

Telecom

Decentralized

Internet

Distributed

Latency vs Throughput...

24

“Decentralized” vs “Distributed”

Centralized

Telecom

Decentralized

Internet

Distributed

What People ThinkReal Mesh Networks Should Look Like

25

“Decentralized” vs “Distributed”

Centralized

Telecom

Decentralized

Internet

Distributed

What Real Mesh NetworksActually Looks Like

What People ThinkReal Mesh Networks Should Look Like

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

“Mesh-like” Network

Internet Connectivity Enabler: Root Node - Gateway - Middleware

Controller - Router - Routing Slave Node

End-point Device -Slave Node

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

“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

6Source 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

“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 NodeKnows 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

Node reference Data Model

● Schema: [ { name:type } ]

Capabilities

● Description

● Certificate

● GUID

● VID

● PID

● Protocol Version

Device Info

32

IoT Node connection steps

I. Authentication

II. Authorization

III. Announce

IV. Communication

Valid

Not valid

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

3434

Challenges of High integrated mesh

35

IoT - Area of Highly integrated Solutions

High-Level example of integrated system

36

IoT Integration Issues

SecurityMany new nodes being added to networks, internet will provide malicious actors with innumerable attackvectors, especially since a considerable number of them suffer from security holes.ConnectivityIoT 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 LongevityVarieties of M2M protocols. Diversities in firmware and operation systems among IoT devices.Data and Process IntegrationComplexity in terms of scaling and IoT management processes.Data sources can rapidly get out of sync.Intelligent Analysis & ActionsInaccurate analysis due to flaws in the data and/or model, ability to analyze unstructured data, ability tomanage real-time data, machine's actions in unpredictable situations, slow adoption of new technologies.

37

Complexity of integrated IoT Mesh development/supportThe 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

Scalable Fault tolerance End-to-end IoT solution

Middlewareprovider

End User and Clients Management

C2C

Device

HistoricalData

End-point

DevicesCloud

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 PartyCloudAPI

3rd party

Provider

3rd partyProvider

ExternalFederated

Data

39

Oleksii Savochkin

Thank you

GlobalLogic