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, i.e. Arduino Uno (R3) with 32 kb of the 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, i.e. ESP8266 and ESP32 chips, battery powered, consuming some dozen or hundred of mW while operating.
• Devices that do can offer various, advanced network services, capable of implementing protocol stack with ease yet not servers, routers or gateways, i.e. 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, routers, usually with embedded, hardware-based implementations of the switching logic, utilising some 10-50W of power.
• Universal IoT computers (i.e. Intel IoT), using PC-grade processors (x86, but sometime 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 ones need to connect, so their topology is a priori prepared as NAT (Network Adress Translation) solution ^[1] 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, there are security concerns, which make the IoT devices to be put in some separate sub-network and guarded by the firewall.

All of it brings the three, main communication models, explained below.

Device to device communication model, sometimes referenced as M2M (Machine to Machine communication model) used to be implemented between the homogeneous class of the 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+ ^[2], sometimes do 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 producer/consumer but is also expected to act as message forwarder/router.

Device to device model is highly utilized in the 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 sequence 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 a device to device networks very frequently mimics popular P2P (peer to peer) networks, where one device can virtually contact any other to ask for information or deliver one. Comparing to the classical, tree-like topology, a device to device communication constitutes a graph of relations rather than a hierarchized tree. The Figure 1 presents comparison between pre-I4.0 (Industry 3.0) and I4.0 data flow. Along with physical (real) devices participating in the manufacturing process, there usually goes their virtual representation (“virtual 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 communication assumes, participating devices are smart enough to talk one another, without the need of the translation nor advanced data processing, even if their nature is different (e.g. your intelligent door can inform your smart, IoT kettle to start boiling water once they get informed about poor weather condition by the Internet weather monitoring service, when you're back home after long day of work). Devices constituting mesh or scatter network communicate virtually one another similar way people do. The Figure 2 briefly presents the data flow idea

Device to gateway communication occurs when there is a need to provide the translate information between different networks, i.e. some Zigbee ^[3] 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 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 have knowledge about constrained devices constituting IoT network and it usually supplies some missing information instead of them, i.e. 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, i.e. simple MQTT texting can be converted to the XML, heavy messages or exposed as XHTML. Those solutions are mostly software-based, i.e. Node-RED ^[4]. The Figure 3 briefly presents the data flow. Please note the protocol change: arrows of the different colours reflect it.

As IoT devices are usually unable to constitute an efficient computation structure (as 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 the visualisation, data analytics (statistics, data mining, knowledge discovery, big data processing). Those tasks are resource consuming, require huge processing capabilities; thus, utilising cloud solution is usually a good choice. Note, claiming “cloud” we consider not only public clouds like Amazon, Google or Microsoft but also 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 i.e. REST ^[5], SoAP ^[6], HTTP GET/POST methods ^[7], etc. It requires the IoT devices interfacing cloud to implement full communication stacks for the protocols needed. Some of the IoT devices can interface cloud services directly, but some of them are unable to do so due to the constraints, so it is necessary to use gateways as mentioned in the previous chapter.