Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

Mesh IoT Networks Explained

725 Aufrufe

Veröffentlicht am

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.

Veröffentlicht in: Technologie
  • Als Erste(r) kommentieren

Mesh IoT Networks Explained

  1. 1. 1 Mesh IoT Networks Explained Oleksii Savochkin Team Lead, Engineering 23 Nov 2017
  2. 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. 3. 33 IoT History ... already?
  4. 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. 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. 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. 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. 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. 9 First Wireless Data Network 1971 ALOHA System Pure Slotted Time Time
  10. 10. 1010 IoT Dimensions
  11. 11. 11 IoT Growth
  12. 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. 13 IoT Fragmentation - Radios Standards
  14. 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. 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. 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. 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. 18 IoT Fragmentation - Developers hardware diversity
  19. 19. 19 IoT Fragmentation Layers
  20. 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. 21. 2121 What is Mesh Network and will it solve the problems?
  22. 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. 23 “Decentralized” vs “Distributed” Centralized Telecom Decentralized Internet Distributed Latency vs Throughput...
  24. 24. 24 “Decentralized” vs “Distributed” Centralized Telecom Decentralized Internet Distributed What People Think Real Mesh Networks Should Look Like
  25. 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. 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. 27 “Mesh-like” Network Internet Connectivity Enabler: Root Node - Gateway - Middleware Controller - Router - Routing Slave Node End-point Device -Slave Node
  28. 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. 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. 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. 31 Node reference Data Model ● Schema: [ { name:type } ] Capabilities ● Description ● Certificate ● GUID ● VID ● PID ● Protocol Version Device Info
  32. 32. 32 IoT Node connection steps I. Authentication II. Authorization III. Announce IV. Communication Valid Not valid
  33. 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. 34. 3434 Challenges of High integrated mesh
  35. 35. 35 IoT - Area of Highly integrated Solutions High-Level example of integrated system
  36. 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. 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. 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. 39 Oleksii Savochkin Thank you GlobalLogic

×