Differences

This shows you the differences between two versions of the page.

--- en:iot-open:networking2:model [2023/11/21 21:36] – pczekalski
+++ en:iot-open:networking2:model [2023/11/23 16:11] (current) – pczekalski
@@ Line 1: / Line 1: @@
-====== Communication Models ======
+====== Communication Models ======
+{{:en:iot-open:czapka_m.png?50| General audience classification icon }}{{:en:iot-open:czapka_e.png?50| General audience classification icon }}\\
 IoT Devices can be classified regarding their ability to implement full protocol stacks of the typical Internet protocols like IPv4, IPv6, HTTP, etc.
   * Devices unable to implement full protocol stack without external support, like, e.g. Arduino Uno (R3) with 32 kb of flash memory, 16 MHz single core processor and 2 kB of static ram, battery-powered, consuming some couple of mW while operating.
-  * Devices able to implement full protocol stack yet still limited by their resources, e.g. ESP8266 and ESP32 chips, battery-powered, consuming some dozen or hundred of mW while operating.
+  * Devices that can implement full protocol stack yet are still limited by their resources, e.g. ESP8266 and ESP32 chips, battery-powered, consuming some dozen or hundred of mW while operating.
-  * Devices that can offer various advanced network services, capable of implementing protocol stack with ease yet not servers, routers or gateways, e.g. Raspberry Pi and its clones. Usually, DC powered with power consumption far above 1–2 W, usually up to 10–15 W.
+  * Devices that can offer various advanced network services, capable of efficiently implementing protocol stack yet not servers, routers or gateways, e.g. Raspberry Pi and its clones. Usually, DC powered with power consumption far above 1–2 W, usually up to 10–15 W.
   * Dedicated solutions for gateways and routers, usually with embedded, hardware-based implementations of the switching logic, utilising some 10-50W of power.
   * Universal IoT computers (e.g. Intel IoT), using PC-grade processors (x86, but sometimes ARM), using some about up to 100 W of power.
@@ Line 12: / Line 13: @@
 IoT devices are usually expected to deliver their data to some cloud for storage and processing while the cloud can send back commands to the actuators/outputs.
-Finally, security concerns usually make the IoT devices be put in some separate sub-network and guarded by a firewall.
+Finally, security concerns usually put the IoT devices in some separate sub-network and guarded by a firewall.
-The aforementioned limitations bring 3 communication models available regarding specific IoT ecosystem requirements.
+The abovementioned limitations bring 3 communication models available regarding specific IoT ecosystem requirements.
 === Device to Device and Industry 4.0 Revolution ===
-The device-to-device communication model, sometimes referenced as M2M (machine-to-machine communication model), used to be implemented between the homogeneous class of IoT devices. Nowadays, there is a need to enable heterogeneous systems to collaborate and talk one-to-another. In a device to a device model, communication is usually held simple, sometimes with niche, proprietary protocols, i.e. ANT/ANT+ ((https://en.wikipedia.org/wiki/ANT%2B)), sometimes employs heavy protocols like XML, so there is a need to provide common communication ontologies and semantics. Devices participating in such networks usually act as multimode, constituting self-organising networks, capable of exchanging the data through routing and forwarding as it appears in 6LowPAN networks where nodes may not only act as data producers/consumers but are also expected to act as message forwarders/routers.
+The device-to-device communication model, sometimes referenced as M2M (machine-to-machine communication model), used to be implemented between the homogeneous class of IoT devices. Nowadays, there is a need to enable heterogeneous systems to collaborate and talk one-to-another. In a device to a device model, communication is usually held simple, sometimes with niche, proprietary protocols, i.e. ANT/ANT+ ((https://en.wikipedia.org/wiki/ANT%2B)), sometimes employs heavy protocols like XML, so there is a need to provide standard communication ontologies and semantics. Devices participating in such networks usually act as multimode, constituting self-organising networks, capable of exchanging the data through routing and forwarding as it appears in 6LowPAN networks where nodes may not only act as data producers/consumers but are also expected to act as message forwarders/routers.
-The device-to-device model is highly utilised in Industrial Automation Control systems and recently very popular in developing Industry 4.0 (I4.0) solutions, where manufacturing devices, i.e. robots and other Cyber-Physical systems (CPS), communicate to set operation sequences for optimal manufacturing process (so-called Industry 4.0) thus providing elastic working zones along with manufacturing flexibility and self-adaptation of the processes. It happens because of the presence of various IoT devices (here, sometimes referenced as Industrial IoT) and advanced data processing, including Big and Small data. Such device-to-device networks frequently mimic popular P2P (peer-to-peer) networks, where one device can virtually contact any other to ask for information or deliver one. Compared to the classical, tree-like topology, device-to-device communication constitutes a graph of relations rather than a hierarchised tree. The Figure {{ref>device-to-deviceIO40}} presents comparison between pre-I4.0 (Industry 3.0) and I4.0 flow. Along with physical (real) devices participating in the manufacturing process, there usually goes their virtual representation ("digital twin") to enable cognitive manufacturing based on data science. The detailed description of the data analysis and its use in I4.0 is out of the scope of this book, however.
+The device-to-device model is highly utilised in Industrial Automation Control systems and recently very popular in developing Industry 4.0 (I4.0) solutions, where manufacturing devices, i.e. robots and other Cyber-Physical systems (CPS), communicate to set operation sequences for optimal manufacturing process (so-called Industry 4.0) thus providing elastic working zones along with manufacturing flexibility and self-adaptation of the processes. It happens because of the presence of various IoT devices (here, sometimes referenced as Industrial IoT) and advanced data processing, including Big and Small data. Such device-to-device networks frequently mimic popular P2P (peer-to-peer) networks, where one device can virtually contact any other to ask for information or deliver one. Compared to the classical, tree-like topology, device-to-device communication constitutes a graph of relations rather than a hierarchised tree. Figure {{ref>device-to-deviceIO40}} presents comparison between pre-I4.0 (Industry 3.0) and I4.0 flow. Along with physical (real) devices participating in the manufacturing process, there usually goes their virtual representation ("digital twin") to enable cognitive manufacturing based on data science. The detailed description of the data analysis and its use in I4.0 is out of the scope of this book, however.
 <figure device-to-deviceIO40>
-{{ :en:iot-open:communications_and_communicating_sut:i30vsi40.png?400 |}}
+{{ :en:iot-open:communications_and_communicating_sut:i30vsi40.png?400 | Industry 3.0 vs Industry 4.0 communication topology}}
-<caption>Industry 3.0 vs Industry 4.0 communication topology.</caption>
+<caption>Industry 3.0 vs Industry 4.0 communication topology</caption>
 </figure>
-The device-to-device communication assumes participating devices are smart enough to talk to one another without the need for translation or advanced data processing, even if their nature is different (e.g. your intelligent door can inform your smart IoT kettle to start boiling water for warm tea, once they get informed about poor weather condition by the Internet weather monitoring service when you're back home after a long day of work). Devices constituting mesh or scatter networks communicate virtually with one another in a similar way people do. The Figure {{ref>device-to-device}} briefly presents the data flow idea
+The device-to-device communication assumes participating devices are smart enough to talk to one another without the need for translation or advanced data processing, even if their nature is different (e.g. your intelligent door can inform your smart IoT kettle to start boiling water for warm tea, once they get informed about poor weather condition by the Internet weather monitoring service when you're back home after a long day of work). Devices constituting mesh or scatter networks communicate virtually with one another in a similar way people do. Figure {{ref>device-to-device}} briefly presents the data flow idea
 <figure device-to-device>
-{{ :en:iot-open:communications_and_communicating_sut:dev-dev.png?150 |}}
+{{ :en:iot-open:communications_and_communicating_sut:dev-dev.png?150 | Device to device communication model}}
-<caption>Device to device communication model.</caption>
+<caption>Device to device communication model</caption>
 </figure>
 === Device to Gateway ===
-Device-to-gateway communication occurs when there is a need to provide the translate information between different networks, e.g. some Zigbee ((http://www.zigbee.org/)) network devices need to send data to the Internet to let the smart home be remotely monitored and managed. This model also appears when there is a need to transfer messages between the IoT network implemented with constrained devices, so using some simplified protocol (e.g. LoRA, 6LowPAN) and the Internet network, using the full implementation of the protocols (e.g. IP6). In this case, the gateway device (sometimes named here as Edge Router) needs to know constrained devices constituting the IoT network, and it usually supplies some missing information instead of them, e.g. enriching message headers or addresses when passing packets from IoT-constrained network to the Internet, but also translating Internet packets (e.g. by removing full address), when acting opposite, e.g. forwarding actuator requests to the IoT devices.
+Device-to-gateway communication occurs when there is a need to provide the translated information between different networks, e.g., some Zigbee ((http://www.zigbee.org/)) network devices need to send data to the Internet to monitor the smart home remotely and manage. This model also appears when there is a need to transfer messages between the IoT network implemented with constrained devices, so using some simplified protocol (e.g. LoRA, 6LowPAN) and the Internet network, using the full implementation of the protocols (e.g. IP6). In this case, the gateway device (sometimes named here as Edge Router) needs to know constrained devices constituting the IoT network, and it usually supplies some missing information instead of them, e.g. enriching message headers or addresses when passing packets from IoT-constrained network to the Internet, but also translating Internet packets (e.g. by removing full address), when acting opposite, e.g. forwarding actuator requests to the IoT devices.
-Gatewaying and protocol translation can also occur on the 6th and 7th level of the ISO/OSI model when the implementation of high-level protocols overwhelms even more advanced IoT devices, e.g. simple MQTT texting can be converted to the XML, heavy messages or exposed as XHTML. Those solutions are mostly software-based, e.g. Node-RED ((https://nodered.org/)). The Figure {{ref>device-to-gateway}} briefly presents the data flow. Please note the protocol change: arrows of the different colours reflect it.
+Gatewaying and protocol translation can also occur on the 6th and 7th level of the ISO/OSI model when the implementation of high-level protocols overwhelms even more advanced IoT devices, e.g. simple MQTT texting can be converted to the XML, heavy messages or exposed as XHTML. Those solutions are mostly software-based, e.g. Node-RED ((https://nodered.org/)). Figure {{ref>device-to-gateway}} briefly presents the data flow. Please note the protocol change: arrows of the different colours reflect it.
 <figure device-to-gateway>
-{{ :en:iot-open:communications_and_communicating_sut:dev-gwy.png?150 |}}
+{{ :en:iot-open:communications_and_communicating_sut:dev-gwy.png?150 | Device to gateway communication model}}
 <caption>Device to gateway communication model</caption>
 </figure>
@@ Line 48: / Line 49: @@
 <figure device-to-cloud>
-{{ :en:iot-open:communications_and_communicating_sut:dev-cloud.png?150 |}}
+{{ :en:iot-open:communications_and_communicating_sut:dev-cloud.png?150 | Device to cloud communication model}}
-<caption>Device to cloud communication model.</caption>
+<caption>Device to cloud communication model</caption>
 </figure>
 <note>Recent advances in hardware development and energy-efficient design allowed even the edge-class constrained devices to implement some simple AI models. Still, AI model training, updating and using reinforced learning models typically involves a cloud-based solution.</note>

en/iot-open/networking2/model.1700602610.txt.gz · Last modified: 2023/11/21 21:36 by pczekalski