Differences

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

--- en:iot-open:networking2:model [2023/11/23 13:47] – pczekalski
+++ en:iot-open:networking2:model [2023/11/23 18:11] (current) – pczekalski
@@ Line 1: / Line 1: @@
+====== 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 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 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.
+Some IoT networks are also constrained by the number of IP addresses available regarding the number of IoT devices one needs to connect, so their topology is //a priori// prepared as NAT (Network Adress Translation) solution ((RFC 1631: http://www.faqs.org/rfcs/rfc1631.html)) thus it requires automatically use of routers.
+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 put the IoT devices in some separate sub-network and guarded by a firewall.
+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 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. 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 | Industry 3.0 vs Industry 4.0 communication topology}}
+<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. 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 | Device to device communication model}}
+<caption>Device to device communication model</caption>
+</figure>
+=== Device to Gateway ===
+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/)). 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 | Device to gateway communication model}}
+<caption>Device to gateway communication model</caption>
+</figure>
+=== Device to Cloud ===
+As IoT devices usually cannot constitute an efficient computation structure (as a single IoT node or even their federation), most data is forwarded to the server, often a cloud-based solution, where it is stored and processed. This data processing in the cloud varies, depending on the type of information, their goal, etc. In any case, we usually face the problem of visualisation and data analytics (statistics, AI, data mining, knowledge discovery, big data processing).
+Those tasks are resource-consuming and require substantial processing capabilities; thus, cloud solutions are usually a good choice.\\
+In this context, "cloud" means public clouds like Amazon, Google or Microsoft and dedicated solutions hidden somewhere in the separated manufacturing networks. Eventually, there is a need to send back some actuation requests to the devices from the cloud. Cloud services are usually PC-based solutions; thus, they extensively use rich protocols, providing their APIs via REST ((http://www.restapitutorial.com/lessons/whatisrest.html)), SoAP ((https://www.w3.org/TR/soap/)), HTTP GET/POST methods ((https://www.w3schools.com/tags/ref_httpmethods.asp)), etc. It requires IoT devices interfacing with the cloud to implement full communication stacks. Some IoT devices can interface with cloud services directly. Still, some of them cannot do so due to the constraints, so it is necessary to use gateways, as mentioned in the previous chapter.
+<figure device-to-cloud>
+{{ :en:iot-open:communications_and_communicating_sut:dev-cloud.png?150 | Device to cloud communication model}}
+<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>