2. Supporting Technologies in the IoT-Edge-Cloud Continuum
The overall architectural approach of an IEC system is shown in
Figure 2 (optional communication with a 5G network has been included as well). As can be observed, various IoT nodes from different operational scenarios may communicate with 5G access points (APs) via either public or private networks. The latter case can be more appealing in latency-demanding applications, such as smart manufacturing, since all network operations can be established within the premises of interest
[22][23]. It should also be noted at this point that inter-node communications can be supported as well, based on well-known communication protocols, such as Sigfox, LoRa, or narrow band (NB)-IoT
[24]. It is also assumed that MEC servers can be either collocated with APs or alternately deployed in close proximity.
Figure 2. An IoT-edge-cloud operating system.
IoT nodes, which are assumed to have sensing and transmitting capabilities, can offload a particular task to the MEC server either in cases of latency-demanding applications or in cases of extreme computational load. This offloading may also take place in the cloud domain if necessary. In all cases, optimum task offloading should take into consideration additional parameters that may have a direct effect on the system’s performance, such as the energy footprint and computational capabilities of the involved servers. Therefore, as depicted in
Figure 2, efficient ML algorithms can be used for resource optimization and efficient task offloading. In all cases, it is essential to identify trusted IoT nodes and secure task offloading/data transfer procedures. Therefore, task offloading may also include the execution of advanced security protocols that might not always be feasible in resource-constraint IoT nodes. Finally, in highly demanding latency scenarios (e.g., autonomous driving in the cases of advanced 5G infrastructure
[25]), the involved IoT devices should be in a position to operate autonomously and support network functionalities via NFV and ensure uninterrupted connectivity.
In light of the above, the most important key enabling technologies for an efficient IEC deployment include distributed/decentralized ML approaches for efficient resource optimization, serverless computing to leverage software and hardware decoupling, blockchain technology to ensure security during data transfer among the various nodes of the continuum as well as trusted nodes identification, subnetworks for the provision of uninterrupted connectivity, and device to device (D2D) communications for inter-node data transfer and content caching if necessary.
2.1. Distributed and Decentralized Machine Learning
As also mentioned in the introductory part, over the last decade, ML algorithms have emerged as a potential solution to relax the computational burden of traditional optimization approaches and provide near-optimum solutions in highly non-convex problems
[26]. In centralized ML approaches, data collected directly from different network devices (i.e., mobile terminals, access points, IoT devices, edge servers, etc.), are sent to a high-performance computing server for proper model training. Afterwards, model inference to all involved devices takes place, if necessary.
However, there are several disadvantages with this approach, especially in the modern era of IEC systems: (i) centralized data collection might lead to high computational load, especially for a large number of involved devices and associated datasets, as well as to a single point of failure; (ii) since the vision of the IEC continuum involves multiple connected heterogeneous devices over diverse infrastructures, data preprocessing prior to the actual training of the ML model is necessary, which might increase overall training time and result in system latency deterioration; (iii) frequent transmission of data from IoT devices to centralized servers might drive security and privacy concerns since not all IoT devices have the processing power to execute advanced security protocols; and (iv) computationally demanding ML training might have an impact on the energy footprint of the involved devices.
Distributed ML approaches can reduce the centralized computational burden, either by parallelizing the training procedures or by efficiently distributing training data
[27][28]. The first case, which is also known as model parallelism, enables different parts of the model to be trained on different devices (e.g., certain layers of a neural network (NN) or certain neurons per layer are trained per device). In the second case, each ML node takes into account a subset of the training data. Afterwards, model aggregation takes place. Although both aforementioned approaches can improve training times and relax the computational burden, unavoidably, training data offloading still takes place. Consequently, their deployment on privacy-critical applications might be questionable.
To overcome the aforementioned issue, the concept of FL has emerged over the last years
[29][30] as a promising approach that ensures distributed ML training on the one hand and privacy protection on the other hand. To this end, training is performed locally on the involved devices, with no need for forwarding training data to external servers. At predefined time intervals, the parameters of the trained model are sent to the central processing node, where the master model is periodically updated. Moreover, since training data remain localized, privacy is enhanced, as was previously mentioned. In addition, with FL, data can be distributed across many devices, which can enable the use of much larger datasets. Moreover, the amount of data transfers and the communication burden are reduced, especially in cases where the data are distributed across devices with limited connectivity or bandwidth. Finally, FL allows the model to be trained on a diverse range of data sources, which can improve its robustness and generalizability, as well as overall training times. For example, focusing on the previously mentioned autonomous driving 5G scenario, using this approach, a predefined set of identical cars can be parallelly trained on different landscapes. Results can then be aggregated and sent back to the autonomous cars in order to cover a wide range of driving reactions.
A schematic diagram of FL is shown in
Figure 3, in the case of NN training. In this case, each node locally trains the corresponding ML model with the available local data set. The derived parameters (i.e., weights of the NN in the specific case) are sent periodically to the master processing node for proper model aggregation. At the next stage, the new weights of the master model are sent back to the local nodes for a model update. Apart from autonomous driving, which was previously mentioned, FL can be quite beneficial in a wide range of scenarios, such as smart manufacturing and e-health applications, where data privacy protection is of utmost importance
[31]. However, since FL is based on distributed computations, several types of privacy attacks may take place, such as poisoning and backdoor attacks
[32]. Hence, privacy enhancement is a crucial step towards large-scale FL deployment.
Figure 3. Federated learning in a two-node distributed system.
2.2. Serverless Computing
Serverless computing expands on state-of-the-art cloud computing by further abstracting away software operations and parts of the hardware–software stack. To this end, and with respect to the already standardized 5G architecture, the execution of vertical applications in the management and orchestration layer initiates the E2E service creation and orchestration. In the context of serverless computing
[33][34], related functions need to be executed in the background for specific time triggers or generally short events. In this case, a container cluster manager (CCM) is required where the appropriate set of function containers is enabled per the requested application. Therefore, supported applications are fully decoupled from hardware infrastructure. This will not only make the support of latency-critical scenarios feasible on the one hand, such as autonomous driving, smart manufacturing, e-health applications, etc., but on the other hand, a more efficient infrastructure management can be supported.
The serverless computing concept benefits from containerization by removing decision-making regarding scaling thresholds, reducing costs by charging only when applications are triggered, and reducing application starting times. Therefore, appropriate business models can be applied in IEC continuum systems, based on the actual usage of applications. Serverless and edge computing are indispensable parts in the heterogeneous cloud environments of 6G networks, since major network functionalities should be able to migrate and be executed at the edge, either in cases of outage of the main core network or in order to leverage flexible network deployment for ultra-low latency applications.
2.3. Blockchain Technology
The ever-increasing number of interconnected devices on the Internet has raised many concerns regarding security and privacy preservation, as was previously mentioned. For example, in domestic or e-health IoT scenarios, multiple attacks may take place due to the diverse nature of the involved communication protocols
[35][36]. To this end, blockchain technology is a credible way to ensure security and privacy in heterogeneous infrastructures. A blockchain is a distributed ledger technology with growing lists of records (blocks) that are securely linked together via cryptographic hashes. Each block contains a cryptographic hash of the previous block, a timestamp, and transaction data. These blocks are interconnected to form a chain. Therefore, for a particular block (i.e.,
nth block), its hash value is calculated by hashing the whole part of the
n 1 block, which in turn includes the hash of the
n 2 block, etc.
[37][38].
A key novelty of blockchain technology is that it does not require a central authority for node identification and verification, but transactions are made on a peer-to-peer (P2P) basis. In general, blockchain is a decentralized security mechanism, where multiple copies of blocks are held in different nodes. Therefore, a tampering attempt would have to alter all blocks in all participating nodes. Moreover, since timestamps are inserted in all related blocks, it is not possible to alter the encrypted content after it has been published to the ledger, making it more trustworthy and secure as a result. In addition, timestamps are also helpful for the tracking of the generated blocks and for statistical analysis.
The integration of blockchain technology in IoT networks faces many technical challenges since the encryption and decryption process of the blocks requires computational resources that cannot always be supported by lightweight IoT devices. Recent advances in the development of ‘‘light clients’’ for blockchain platforms have enabled nodes to issue transactions in the blockchain network without downloading the entire blockchain
[39]. Therefore, by combining blockchain with FL, IoT sensing devices can offload a portion of their data to an edge server for local model training. However, there are still open issues to be addressed, such as a common blockchain framework that can be adopted by all involved entities, which is a key concept towards scalability in large-scale networks. Blockchain is usually combined with smart contracts, stored on a blockchain, and run only when predetermined conditions are met
[40][41]. Therefore, human intervention is minimized. Smart contracts do not contain legal language, terms, or agreements—only code that executes actions. Hence, the need for trusted intermediators is reduced, while at the same time, malicious and accidental exceptions are minimized.
2.4. Subnetworks
The increased number of wireless applications deployed at the network edge involving a limited number of network components, such as a sensor network in a manufacturing environment or vehicle-to-vehicle (V2V) communications, requires minimum latency with short-range transmission. To this end, the concept of subnetworks has been introduced, where a network component in the edge acts as a serving AP
[42][43]. However, the concept of subnetworks extends the provision of zero latency to the connected devices, as in cases where the connection with the core network is lost. In this case, as also mentioned in the autonomous driving application, the subnetwork should be in a position to operate autonomously for the provision of uninterrupted E2E connectivity. Sub-networks will be a key driving factor towards the 6G architectural concept due to their local topology in conjunction with the specialized performance attributes required, such as extreme latency or reliability. Moreover, the concept of subnetworks is crucial for the design of energy-efficient networks, where topology reconfiguration might take place in time-varying IoT sensor networks
[44].
In 6G terminology, subnetworks are also referred to as ‘in-X’ subnetworks, with the ‘X’ standing for the entity where the subnetwork is deployed, such as a production module in a smart manufacturing environment, a robot, a vehicle, a house, or even the human body in cases of wearable devices that can monitor various parameters
[45]. A schematic diagram of such a network is shown in
Figure 4, where data flows are categorized according to their latency requirements: low, such as in the cases of monitoring non-latency-critical key performance indicators (KPIs); medium, such as task offloading in edge servers; and high. The latter case includes, for example, control signals from the involved IoT devices in a smart manufacturing environment that necessitate immediate production termination in cases of malfunction. Therefore, the highly critical data flows are kept within the in-X subnetwork, as the tight latency requirement does not allow for external processing. For this reason, a local edge server can be in close proximity to the AP under consideration (in this case, an unmanned aerial vehicle—UAV).
Figure 4. X subnetwork deployment within wide area networks.
2.5. Device to Device Communications
In an IoT environment, a specific type of content might be requested from several user terminals or other IoT devices in close geographical proximity. In this case, user-experienced latency can be improved if the content is requested from adjacent IoT devices that share the same content, instead of centralized APs. In this case, a particular node requests content by broadcasting a short-range signal in order to set up a link connection with the node having the content. Therefore, D2D connectivity should be supported in this case
[46][47]. However, apart from content caching, D2D connectivity can also support subnetwork organization, as well as dynamic IoT node deployment and reconfiguration if necessary.
In general, D2D communication offers autonomous intelligent services or mechanisms without centralized supervision. Hence, the provision of ultra-low latency services in the IEC continuum can be achieved, as D2D communication offers more reliable connectivity between devices. In addition, the concept of green network deployment can be supported as well, due to the shorter propagation paths and consequently reduced transmission power.
In the same context, device interconnection can be established via mesh networking
[48][49]. A mesh network comprises a type of local area network (LAN) topology, where multiple devices or nodes are connected in a non-hierarchical manner so that they can cooperate and provide significant network coverage to a wider area compared to the area coverage achieved by a single router. As mesh networks consist of multiple nodes, which are responsible for signal sending and information relaying, every node of the network needs to be connected to another via a dedicated link. Since mesh networks leverage a multi-hop wireless backbone formed by stationary routers, they can serve both mobile and stationary users. Mesh networks have significant advantages such as fast and easy network extension, self-configuration, self-healing, and reliability, as a single node failure does not result in total network failure.