1 Introduction

The recent advances in computer science and communication technologies have enabled the development of systems that focus on improving productivity and the quality of life in society. Within this context, the information collected from the environment and delivered to users can provide additional value for the development of advanced applications. This trend is encouraging the development of new concepts in many areas of industry and consumer electronics, such as the Internet of Things (IoTs), Cyber–Physical Systems (CPS), and Mobile Computing.

On the other hand, the Cloud Computing paradigm has opened the doors to a dramatic increase in performance for many applications. The US National Institute of Standards and Technology (NIST) provides an accepted conception of this paradigm [1]. Briefly, it is described as a computing technology that takes advantage of cloud resources to enable ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources that can be rapidly provisioned and released with minimal management effort or service provider interaction [2].

The convergence of the IoT and cloud computing paradigms improves their synergy and provides a better user experience [3, 4]. Many new sensors and embedded systems have high computing capabilities that allow them to execute sophisticated applications (e.g., video and image processing, augmented reality, artificial intelligence algorithms), thus offering mobility with computing power. Nevertheless, the new features of mobile applications require greater performance, and the requirements are steadily increasing. Consequently, devices are becoming obsolete in a short time. In this way, the utility of the devices can be increased by offloading computation-intensive applications to a high-performance computing infrastructure hosted outside the mobile devices, normally to the cloud. The paradigm Mobile Cloud Computing (MCC) provides many more possibilities for computing complex applications in standard IoT devices such as mobile phones, wearables, or other embedded systems [2, 5]. Offloading the application workload running in the ‘things’ could save power consumption and bring greater computing resources. Recent technological developments are evolving towards this ‘outsourcing’ concept by deploying computing platforms in different layers of the network, not only at remote servers over the Internet. Moreover, there are a growing number of ‘things’ with processing capabilities in the surrounding environment of a mobile device or embedded system that can also be used to share the processing [6, 7].

Mobile and embedded systems are progressively incorporating connectivity and providing ready-to-use processing capabilities. Other computing resources are being installed at different network levels that work as key market drivers to improve the development of high-tech applications for advanced environments such as smart cities, autonomous vehicles, and advanced industrial systems. In this way, nearby clouds can be deployed in corporate facilities [8, 9] and/or on the mobile network [10, 11].

The fast development of wireless network technology has led to the emergence of fifth-generation (5G) networks, which offer faster data transfer speeds, lower latency, and higher capacity [12, 13]. These networks are becoming increasingly available due to the growth of IoT applications that require real-time processing of large amounts of data. One of the key advantages of 5G networks is their ability to handle a larger number of connected devices, which is critical for the development of IoT ecosystems. To further optimize the use of these networks, MCC has emerged as a promising paradigm that enables a more efficient and effective utilization of IoT devices [14]. By offloading computation tasks to the cloud, MCC paradigm can improve the performance of IoT devices and enhance the overall quality of service (QoS) provided by 5G networks. This paradigm is a promising approach to address critical challenges encountered by IoTs systems. These challenges are primarily related to privacy and security concerns, as well as to optimizing energy consumption. The adoption of this paradigm allows for efficient management of resources and data, enabling IoT systems to achieve higher levels of functionality and sustainability [15, 16].

However, to our knowledge, there is no comprehensive study or review of the MCC paradigm working in a full scenario with several available computing platforms along the network layers in a combined way. Consequently, the motivation of this work is to review how the MCC paradigm could be generalized to the current available computing platforms and to research the advantages and possibilities of architectures with multiple offloading options, as opposed to the traditional MCC scheme. Therefore, the main objective of this work is to investigate the advantages and possibilities of architectures with multiple offloading options as opposed to traditional MCC schemes and to understand how they can provide greater performance to compute advanced IoT applications.

The key contributions of this work can be summarized as follows:

  • A study of the available architectures and computing platforms to outsource processing load and a review of this process using a combination of the computing layers of the available infrastructure.

  • A demonstration of the benefits of offloading using all computing layers of the network by designing a proof-of-concept prototype that functions as an illustrative case study in which numerous tasks are involved with different characteristics and several scenarios.

The novelty of this proposal is the focus on generalizing the MCC paradigm to the available network computing platforms to increase the performance in computing advanced IoT applications. Other important aspects, such as privacy issues, are outside of the core of this research. However, these topics can be improved under the proposed framework because it is easier to manage security at nearby sites rather than remote clouds.

The paper is structured as follows: Sect. 2 provides an overview of the MCC paradigm, where the main operational concerns and platforms are described; next, in Sect. 3, the idea to extend the MCC concept is introduced. An example is used to explain how the network-assisted processing takes place; Sect. 4 discusses the benefits it provides; and finally, Sect. 5 draws the main conclusions and future research lines.

2 Mobile Cloud Computing overview

This section describes the potentials and limitations of the MCC paradigm, and after that, the possibilities for outsourcing the application workload are discussed, as well as the most relevant existing architectural design possibilities for this area. Finally, some conclusions are drawn that justify the main contributions of this research.

2.1 MCC operational concerns

The MCC paradigm of computation extends the capabilities of devices in the execution of applications. In this way, it can be defined as an ‘augmented device’ system. The most common uses of this paradigm are mainly focused on extending the battery life of mobile platforms [17,18,19,20,21] without considering the versatility that remote computers can provide to extend the computing power of devices. However, recent work considers the increase in performance to be one of the most important contributions of MCC to mobile computing [22, 23].

This approach brings great potential to the development of the IoT paradigm, since it can provide computing power when and where necessary for connected things and turn them into smart things. In this way, it can be considered as a disruptive paradigm enabler of advanced applications. The two main disruptive changes can be summarized as (a) homogenization of device computing capabilities because they can execute applications regardless of their native hardware and (b) overcoming the limitations of mobile devices in the execution of advanced applications.

The concept of offloading computation is used to address the inherent problems of mobile computing in using other computing resources than the device itself to host the execution of mobile applications [22]. Of these challenges, the following are highlighted [2, 24,25,26,27]:

  1. (1)

    Using heterogeneous cloud resources managing cloud resource utilization for many components and devices around the world is not a trivial undertaking. The tasks involved, such as partitioning resource-intensive components, virtual machine (VM) creation and migration, and monitoring the overall outsourced processes, can produce overhead for the cloud management system.

  2. (2)

    Elasticity of infrastructure providers there may also be situations where there are more demands from MCC clients than available resources. This can cause cloud resource unavailability, service interruption, and performance degradation.

  3. (3)

    Unpredictable and long latency response times and delays in server responses are difficult to predict. In offloading tasks from MCC devices, situations can occur where server response delays can increase. When network latency increases, the quality of user experience is decreased. However, better network protocols and new telecommunication technologies (such as, for example, promising 5G) could reduce this drawback.

  4. (4)

    Security and Privacy this is a challenging issue in MCC because different devices use heterogeneous computing resources through a communication network. This is the main reason why private clouds (or other private deployed resources) are still a good choice for organizations, since they are deployed and managed inside them.

2.2 MCC platforms: solving challenges and related work

At the moment, new platforms with computing capabilities have been deployed at several layers of the network with different objectives: increasing security, keeping privacy, providing specialized resources, etc. [28]. The network has been labeled at two ends, called the ‘edge’ and ‘core’ ends [29,30,31,32]. The edge end is close to the data sources and users; the core end consists of the cloud servers. In general, edge computing aims to bring cloud resources and services to the edge of the network [31]. This concept aims to provide resources and services to the end user with minimal delay. Figure 1 shows a scheme of these different current offloading options along the communications network between the devices and the cloud servers.

Fig. 1
figure 1

Offloading platforms along the communication network

Full size image

The traditional conception of the MCC paradigm considers the cloud as the target platform for offloaded computation [2, 5, 22]. The Cloud is referred to as the computing infrastructure hosted on remote servers that can be accessed through the Internet. Challenges (1) and (2) are common in the management of cloud server resources [33]. With the MCC paradigm, this problem increases significantly because the volume of ‘things’ deployed is growing rapidly due to the expansion of the IoT [34]. Internet access through wide area networks (WANs) is the main culprit [Challenge (3)]. The network can behave unpredictably at any time due to different aspects. For this reason, it is difficult to provide a smooth scheduling of response times. Regarding security issues [Challenge (4)], offloading work to external servers is a critical task. Even in the case of private infrastructures, access to a WAN can be a source of security issues. Recent proposals have attempted to overcome the previous drawbacks by approaching cloud computing resources to mobile devices that will consume them [4, 35, 36].

Regarding the mobile edge computing (MEC) paradigm, the main efforts are directed towards reducing network latency by moving the computation and storage capacity from the core WAN to the edge network [37]. This goal can be achieved due to the evolution of communication base stations towards platforms capable of providing secure computing and IT services [38]. Thus, these resources can be used by connected mobile devices near stations to offload application tasks and execute part of the computing load. In turn, edge platforms can shift computation to traditional cloud servers to compute intensive calculations or centralized database access tasks [35].

MEC reduces Challenge (2) because it can offer additional resources for outsourcing the computation load of advanced applications and then increase the elasticity of cloud computing. Furthermore, MEC platforms can be deployed in numerous locations and build a dense network where necessary, providing flexibility [37]. This offloading process is transparent to the user. Mobile devices maintain services by sharing the processing between the MEC and the cloud. Challenge (3) is also addressed. In this case, the response times of the offloaded tasks are reduced due to the higher bandwidth and proximity of the MEC platforms.

On the contrary, Challenges (1) and (4) remain. Decentralization of infrastructure adds heterogeneity to cloud resources and increases management costs. The security issue remains unsolved. In this case, a distributed security strategy is required to consider the entire system and the different edge platforms. Furthermore, a standardized environment is required to adequately address this problem and specify how the different elements of the architecture can collaborate with each other [39].

The cloudlet infrastructure is a step forward towards bringing cloud resources closer to mobile devices. The physical proximity of the cloudlet simplifies the challenge of meeting the required bandwidth and provides improved performance in response times [40,41,42]. However, the limited resources of the cloudlet infrastructure negatively affect performance with an increasing number of user devices. Hence, the cloudlet must move this additional processing to the core cloud systems to meet the requirements. As mentioned, cloudlet infrastructure is usually deployed within a local area network (LAN) and can be accessed wirelessly [7]. The bandwidth of the wireless LAN is typically two orders of magnitude higher than the bandwidth of the wireless Internet available to a mobile device [43].

The deployment of cloudlet is designed specifically to address Challenges (2) and (3) and to provide scalable resources [44]. Therefore, it can be used to improve the QoS of interactive applications in citizen-centric environments such as smart cities [45]. Cloudlets are decentralized, widely distributed, and self-managing. Hence, they are not as efficient as core cloud computing, because the resources are sparse in a wide area (for example, each city district could have its own cloudlet). Therefore, Challenge (1) is not well addressed by cloudlets. Concerning the security issue [Challenge (4)], the security and privacy vulnerabilities inherent to the communications across the network remain. However, the cloudlet nodes are closer to the users, and the platforms are owned by the companies providing the service. In this sense, it is less risky to compute the data in the cloudlet compared to a remote server.

The next step is fog computing, where the closest network devices can provide a computing aid to the applications. This infrastructure provides real-time capabilities to devices that minimize security risks and offloading distance and communication latency [8, 46]. It is inefficient to transmit all the data acquired by the sensors to the cloud for processing and analysis. Thus, this paradigm has been designed specifically to provide computing capabilities to nearby IoT infrastructures, such as sensors or embedded devices. It has been proven that the closer the cloud computing resources are to the devices, the more useful they are and the better the performance achieved. However, this novel paradigm has a lack of standards related to several aspects such as communication, data storage models, and interoperability of service discovery.

These mini-clouds deployed by fog nodes have a high impact on Challenges (2) and (3) issues because they provide the first line of computing [47]. Many of the application tasks can be solved at this level, and the others can be offloaded in turn to remote clouds. In this manner, unpredictability in response times does not disappear; however, it can be reduced significantly. The management of heterogeneous cloud resources [Challenge (1)] remains. Fog nodes can be extremely heterogeneous with no possibility of being scaled. Wireless network security [Challenge (4)] is a significant problem in fog networking because wireless communication is predominant in fog networking, even in edge computing, in general. Additionally, fog nodes are in the environment of the end user and can collect more sensitive information than a remote cloud. This aspect adds greater concern regarding the privacy issue [48, 49].

The final step in providing infrastructure for offloading applications consists of the sharing of computation tasks among neighboring connected devices. These devices become a collaborative environment called an ‘ad hoc’ cloud [50, 51]. This peer-to-peer computing allows applications to run cooperatively on devices that are in close proximity. Therefore, the end devices can be considered as edge computing platforms. For example, a mobile device can process the data from a near sensor [29]. This computational paradigm is highly scalable, depending on the available devices. However, the management of the computing platforms can be difficult and thus Challenge (1) remains unsolved or can even be increased. It is necessary to define efficient discovery services, user agreements, and other aspects such as task scheduling or resource pricing. However, this configuration provides considerably more flexibility to address computation requirements. Data can be processed over the set of computing devices in its surroundings without the requirement of Internet access or available cloud resources. Hence, it can ease Challenge (2) by providing elasticity in access to cloud resources. Direct communication between devices also provides solutions to Challenge (3). The response time and latency are highly predictable because there are no network congestion problems. However, the availability of the computing power of existing devices can limit the resulting performance. Regarding security [Challenge (4)], this computational model better protects data because it is not transmitted to cloud servers or external platforms for processing. However, in a heterogeneous and variable network topology, it is difficult to support effective security and privacy mechanisms [52]. Other additional challenges arise, such as power consumption restrictions and access permissions to the devices.

Table 1 summarizes the main features of each platform level related to the offloading process and the purposes of this work. The data have been extracted from the references cited in this section.

Table 1 Offloading features of each network platform
Full size table

2.3 Findings and novelty of the proposal

After reviewing the design possibilities and development of architectures for offloading mobile computation, some findings can be drawn that justify and summarize our contributions to previous MCC architecture designs:

  • The trend to improve the overall performance of complex applications deployed in distributed environments (such as IoT and mobile applications) is to identify methods of using the networks and the Internet to provide additional computing power to mobile devices and ‘things’. The proposals are intended to add computing resources at several layers of the network and to move increasing computing capabilities closer to data sources and users.

  • Several approaches have been proposed to offload application tasks that take advantage of technological progress in communication, embedded systems, cloud computing, and application development.

  • In the new paradigms and applications that deploy connected ‘things’ and embedded systems, mobile ad hoc clouds can be an effective option to share processing tasks. These mechanisms can be considered to improve the possibilities of outsourcing work.

This work proposes an extended architecture for the MCC paradigm to enhance the offloading process based on network resources. This approach combines ad hoc clouds, fog nodes, cloudlets, MEC platforms, and cloud servers to improve the flexibility of computations and determine the best way to execute applications.

3 Extended MCC architecture

3.1 General framework

In this section, the architecture for performing network-assisted processing is introduced. This architecture aims to reduce the impact of previous challenges for high-demanding applications that can be executed along the network. In order to verify its functioning, a prototype and study case of the multi-layer architecture is described in this section. The prototype is validated by running a complex application in a realistic operating environment. The purpose of the experiments performed is to illustrate the flexibility provided by the different offloading options and their implications for addressing the challenges. The results demonstrate that only the availability of several offload layers can overcome the operating conditions imposed by the application scenarios.

The application used consists of computing the ‘Autonomous Vehicle Driving’ (AVD-App) executed on board a car. The operating environment is an urban area of a Smart City where several autonomous vehicles are circulating at the same time on the streets. This will be common in the near future, where vehicles will be required to make decisions in real time and provide information to the city to facilitate traffic management in a similar time frame. This application requires a huge amount of computational power because there are numerous driving aspects involved and obstacle trajectories must be calculated and verified at every moment. To address this problem, one design option could be to provide the embedded car system with sufficient computing resources to complete all computations. However, in this scenario, new application updates and capabilities could exceed the system’s resources in the future. Another option is to offload part of the processing cost to the cloud. This option requires Internet connectivity and a powerful cloud system to provide service to the entire vehicle fleet. Between these extremes, the proposed approach consists of combining the computing resources of the network architecture to perform all computations. This approach provides flexibility and robustness by increasing the computation options at several computing layers. In this work, a simplified version of the AVD-App is described; therefore, the non-relevant details for this work are not mentioned.

The operation of the framework for network-assisted processing is defined by three key factors: (i) application, (ii) infrastructure, and (iii) criteria.

3.1.1 Specification of the application

Firtly, the applications suitable to be processed by this architecture must be ready for the proposed workload. This means that the application workload can be partitioned and distributed along the network to be processed by different layers.

In this way, let \(\Gamma _{Appl}\) be the set of tasks of the application and {\(t_{1},t_{2},\ldots ,t_{n}\)} the application tasks to be computed, as shown in Eq. 1:

$$ \Gamma _{Appl}=\{t_{1}, t_{2}, \ldots , t_{n}\}. $$
(1)

The AVD-App can be decomposed into common tasks according to the findings of recent research works [53,54,55,56] in a possible Smart City context. The simplified set of tasks for the AVD-App used in this study is shown in Fig. 2. The set of tasks is defined by the set \(\Gamma _{Appl}=\{t_{1}, t_{2}, \ldots , t_{7}\}\). The application tasks are running continuously while the vehicle is operating.

Fig. 2
figure 2

Autonomous vehicle driving application decomposition

Full size image

A brief description of the tasks is as follows:

\(t_{1}\):

Readings from sensors this task manages the raw data acquired by the sensors and prepares them for processing. Sensors can be autonomous devices or part of embedded systems. In some cases, preprocessing (digitalizing, filtering, enhancing, and sampling) might be required to obtain the correct data. The volume of information generated by this stage depends on the number of sensors and their nature. Data are derived from several sensors including video cameras, LIDAR (Laser Imaging Detection and Ranging) scanners, radar, and GPS (Global Positioning System). The range of vehicle sensors determines the maximum speed of the vehicle. Thus, the greater the sensor range, the better the knowledge of the environment and the greater the speed the car can achieve. Sensors are considered to have an effective perception of the environment of ten meters around the vehicle.

\(t_{2}\):

Processing data from the results of the previous task, in this stage, the data are processed to recognize objects and elements of the environment (pedestrians, traffic signals, and other vehicles).

\(t_{3}\):

Build digital map in this stage, the objects identified in the previous task are combined to build a digital map of the environment. That is, locate pedestrians, obstacles, and other vehicles. Additionally, a road map is created to identify the limits of the road. In this way, as the vehicle travels on the road, a digital map is created to transform the continuum of the environment into a digital representation of the environment, which is the essential space for planning.

\(t_{4}\):

Interaction with pedestrians this task aims to determine the interaction between the autonomous vehicle and pedestrians. It predicts the intention of the participants in human traffic, calculated separately for each pedestrian. It is assumed that intentions do not change over time.

\(t_{5}\):

Interaction with vehicles this task analyzes the interactions between vehicles and aims to predict the movement of other vehicles. It is also calculated separately for each vehicle detected.

\(t_{6}\):

Digital representation of the road from the previous information, in this task, the driving corridors are constructed according to the predicted motion of the dynamic obstacles (pedestrians and other vehicles) and the presence of static objects.

\(t_{7}\):

Determine best manoeuvre determining the best maneuver to perform the movement is based on calculating the relative positions of the other participants in the environment at the time of making a decision, estimating the risk of possible situations, and making a decision about the best geometric path for the vehicle to follow.

Each previous task has a specific computational cost which can vary depending on the complexity of the environment and the participants involved (obstacles, pedestrians, and other vehicles). Tasks 3 and 6 are intensive in multimedia processing; Tasks 2, 4, and 5 are intensive in signal processing. Task 7 is intensive in both types of specific processing. To reduce computational cost, several simplifications and assumptions can be made. For example, the system can consider a simple representation of vehicles as rectangles and obstacles as circles. However, in this case, close proximity motions cannot be performed due to the lack of accuracy in the approximation [54]. The proposed architecture can avoid these simplifications to improve reliability and allow the system to operate in more complex situations.

The cost of computing the entire application is also an important determinant of the speed of the vehicle. In this case, the sensor range and frequency of decision determine the maximum speed at which the vehicle can move. In this prototype example, it is considered valid to make a maneuver decision every ten meters traveled (except for sudden movements).

3.1.2 Infrastructure

Several computing layers and platforms can be used to process the application tasks. In Eq. 2 let L represent the collection of computing layers that can be accessed through the network design, and let \(L_{0}\) and \(L_{cc}\) represent the network’s ends, where \(L_{0}\) represents the edge device (the closest one to the IoT device) and \(L_{cc}\) represents the last available architecture layer, with a remote cloud-computing data server:

$$ L = \{L_{0}, \ldots , L_{cc}\}. $$
(2)

In general, the available computing layers are variable according to numerous aspects, such as the execution environment, the available infrastructure, and the configuration options. In rich contexts, there may be several computing platforms to process the workload. In other cases, the offloading options are limited. In between, there are several computing layers available to perform the processing at different levels. For example, in an autonomous vehicle application context, \(L_{1}\) can be the network composed of several nearby vehicles, \(L_{2}\) can be the layer formed by the city traffic infrastructure or cloudlets deployed, and \(L_{3}\) can be the mobile edge computing infrastructure behind the communication network. Other infrastructure configurations can be set up for this application.

Each layer (\(L_{j}\)) has a set of computing platforms which can be heterogeneous with different processing capabilities and abilities according to their characteristics. Thus, layer \(L_{j}\) has \(m_{j}\) computing platforms (see Eq. 3), where \(j \in \{0, \ldots , cc\}\) and \(m_{j} > 0\). The set \(\{0,\ldots , cc\}\) represents the available computing platforms that span from mobile devices to cloud servers, thus providing a comprehensive range of resources for distributed computation.

$$ L_{j}= \{p_{j1}, p_{j2},\ldots ,p_{jk}\}, $$
(3)

where \(p_{jk}\) is the platform \(k\in \{1,\ldots ,m_{j}\}\) of the layer j.

The different layers of the network can be deployed in sequence or in a parallel configuration, where each computing platform of a layer can execute the services of the upper layers and provide services to several elements of the lower layers.

The infrastructure of the case study is as follows (Fig. 3).

Fig. 3
figure 3

Prototype of the network architecture for autonomous vehicle driving application

Full size image

In the described environment, there can be five computing layers for computing the application:

\(L_{0}\):

vehicle it is the computing system built into the vehicle. This layer consists of each isolated vehicle.

\(L_{1}\):

set of nearby vehicles this layer consists of the VANETs existing at a given time. A VANET provides wireless communication between a set of moving vehicles [56]. The VANET vehicles can exchange information and share computing resources to offload processing tasks to each other. This layer is an ad hoc cloud.

\(L_{2}\):

district cloudlet in the planned configuration, each city district has a cloudlet. Therefore, this layer has the set of cloudlets of the city. Each cloudlet establishes a LAN where vehicle systems and VANETs can interact. That is, the cloudlet is a private cloud that provides additional processing capabilities to the vehicles. Furthermore, in the described application context, these resources can be used for managing other Smart City infrastructures such as smart traffic signals, parking meters, or urban furniture.

\(L_{3}\):

mobile edge computing this layer has the computing resources available from the communications network. This layer can be optional and accessible through mobile communication technologies such as LTE. If it exists, it can provide additional computing resources to the systems. The urban area covered by each base station is approximately 1.5 km in radius. The deployment of dense networks can provide more base stations to provide processing power to the city [57].

\(L_{4}\):

cloud computing this last layer provides the cloud computing resources of the architecture. It can be a public cloud hosted outside the city and can be accessed through Internet protocols.

The available computing layers depend on the communication facilities of the vehicles. For local area networking, the available layers will be \({L} = \{L_{0}, L_{1}, L_{2}, L_{4}\}\) and for LTE connections: \({L} = \{L_{0},L_{3}, L_{4}\}\). Additionally, there are devices that support both types of communication. In these cases, all layers will be available to them.

The size of each level is variable because it is based on traffic conditions. The number of computing platforms depends on the zone, the existing vehicles, and the circumstances of the city. In addition, computer platforms can be heterogeneous at each level. Thus, vehicles can have different features, cloudlets can have processor capabilities according to their average workload (i.e., the most powerful for city center and highest population districts), and the MEC and cloud computing infrastructures can be adapted to the computing requirements of the city (i.e., most powerful for rush hours and less at night or on weekends). All of these are examples of the computing flexibility of the architecture. In this example, a generic approach with all available layers has been described. Other configurations are possible with a reduced number of layers. There can be different cases where driving conditions evolve; for example, zones without traffic (no layer 1), districts without cloudlet (no layer 2), and areas outside of the communication coverage (no layers 3 and 4).

The list of described platforms represents the specific network architecture of the device and indicates the possible offloading of work at a given time. This list can vary over time, depending on the context of the application. For example, if the mobile device is moving, the available infrastructure can change.

3.1.3 Criteria

The third key factor is related to why application tasks are offloaded to different computing platforms. The criteria determine what the determinant execution costs are involved in the computation of the application.

The execution cost can be any of the different performance aspects that are involved in the execution of a task on a platform. Thus, let \(\Omega \) be the set of performance aspects to consider (see Eq. 4). This covers a range of variables such as computing cost, power consumption, and monetary expense, among others.

$$ \Omega = \{ \text {computing cost, power consumption, money,} \ldots \}. $$
(4)

The selection of criteria is based on multiple configurations, depending on the type of application, execution restrictions, or operating conditions. A single aspect or a combination of several aspects of \(\Omega \) can be considered depending on the specific requirements of the application.

The underlying idea is that each of the available platforms could have a value for each of them. This information is used to feed the scheduling algorithm along the network and to decide where tasks are computed. In this way, the application could search for the best option to meet the requirements.

Regarding the management of the offloading process and the scheduling method, there are many recent contributions to outsourcing the workload in multi-tier network architectures [58, 59]. There is a multitude of works that propose a method for distributing workload, for example, our recent research on IoT applications [60]. A middleware layer might be necessary to allow communication of heterogeneous computing platforms, to include manager modules, as well as other interesting services such as filtering, discovery, and availability services for receiving and executing tasks [61]. This layer can be installed within the devices or deployed around some edge computing platform.

To avoid scheduling overhead in complex environments with multiple offload options, a prediction method based on performance estimations can be used. These data are based on historical performance measurements and are continuously updated. However, this solution cannot be extended to all applications and situations; it is valid when the possibilities can be clearly defined, as indicated in this case. In addition, there may be platforms with specific capabilities that provide services to many applications and allow acceleration of the processing of specific types of tasks. For example, GPUs can be installed on cloudlet servers to accelerate multimedia algorithms. In this manner, the granularity of this calculation is the cost of computing each task.

This work is focused on the multi-tier network architecture and exploits previous research for scheduling of the tasks. In this way, it is necessary to define the performance of the available layers of the architecture. The main aspect considered is the time delay (including computing time and communication costs). That is, \(\Omega = \{\text {computing cost}\}\). The same principle of flexibility that was followed throughout this work can be similarly applied to other performance metrics.

3.2 Simulation and discussion

In this section, a simulation of the proposed architecture is performed according to the previous application environment. The main objective of this section is to demonstrate the flexibility of the architecture and the different possibilities to outsource the workload along the network layers and to overcome difficulties as they arise. The simulation is carried out to obtain different performance results according to the environmental conditions and the working scenarios. It is designed as a five-layer architecture, as illustrated in Fig. 3 considering built-in devices, mobile network, cloudlet infrastructure, communication base station servers, and remote cloud computing. Other layers can be incorporated under the same principles described, providing extra flexibility and computing possibilities to the architecture.

3.2.1 Simulation setup

Many previous works present experiments and simulations of offloading applications between several layers of the architecture [6, 44, 51, 59, 61]. In these investigations, performance data is provided that demonstrate the benefits of the outsourcing process. The results of these works have been considered to estimate the cost of application and network in terms of time delay. To introduce heterogeneity to the computing layers, the cloudlet platform is equipped with GPU devices, which accelerates the multimedia tasks, and the base station platforms have been equipped with DSP devices, which accelerate the signal processing tasks.

Based on the experiments and simulation of the previous works, the following tables show the values of the performance of the framework. The calculation of the computing cost of each platform is given in Table 2. The data generated by each task are shown in Table 3.

Table 2 Computing cost (units in ms)
Full size table
Table 3 Generated data by each task in kB/s
Full size table

This application is executed continuously while the autonomous car is operating. When a driving maneuver is performed, new data acquired by Task 1 becomes available. Thus, the tasks produce a continuous data stream per second. For example, the data flow acquired by the sensors in Task 1 is 1 MB/s.

Finally, the communication costs are listed in Table 4. The cost of these communications usually depends on the volume of data transmitted. Short Range Communication for vehicular networking, WiFi communication with cloudlet platforms and LTE with base stations are chosen. The devices and cloudlets are in a LAN. The base stations and cloud servers are on a WAN. The costs are extracted from the experiments on communication performance analysis carried out by Kaya et al. [62] and da Mata and Guardieiro [63], as shown in Table 4. Symmetric communication is considered in all cases.

Table 4 Communication cost
Full size table

The costs of computation and communication can change with time. To simulate different situations, several scenarios have been defined: (A) normal scenario with fluid flow traffic, (B) busy street, (C) traffic congestion in the city district, (D) rush hour, and (E) congested communication network.

The normal scenario (A) corresponds to the working environment described by Tables 2,  3 and 4. The busy street (B) is the situation produced in which many elements, such as other vehicles, traffic signals, and pedestrians, are located near the autonomous car. In this context, more items imply that the computing costs of the tasks are increased. The simulated data consider a cost double (\(\times 2\)) the data depicted in Table 2 for the computing cost of this scenario, except for the cloud server (\(\times 1.4\)), due to its higher response capacity to absorb more processing. Traffic congestion in (C) for the city district corresponds to the same scenario as in (B); however, in this case, this situation affects a city district. Thus, the cloudlet deployed in this district has an additional delay in processing the tasks. An increase of (\(\times 10\)) is estimated for the computing cost of the cloudlet represented by Table 2 to simulate this scenario. The cost of the other platforms remains at (\(\times 2\)). The rush hour scenario (D) affects a larger area of the city. In this case, the communication cell of the base station has many users using services. Both the cloudlet and base station server produce an additional delay in computing the tasks. An increase of (\(\times 10\)) the computing cost of the cloudlet and base station server is estimated. Finally, the scenario of congestion of the communication network (E) implies a higher communication cost for WANs, that is, base stations and cloud servers. In this context, the communication cost with these platforms is trebled (\(\times 3\)). Table 5 displays the different scenarios of this simulation and their effects on the cost functions with respect to the cost shown in Tables 2 and 4.

Table 5 Computing and communication cost in working scenarios
Full size table

The architecture scheduling algorithm that determines where and when to offload the computation considers the costs and scenarios depicted in Tables 2, 3, 4, and 5 to build a look-up table to predict the behavior of the network platforms and coding the offloading decision in each case. Table 6 summarizes the simulation parameters.

Table 6 Simulation parameters
Full size table

3.2.2 Simulation results

From the specifications described in the previous sections, numerical results were obtained after simulating the autonomous vehicle operation in the different scenarios proposed. The experiments carried out allowed us to identify the best options to execute the application and the possible decisions to offload the work in each case. Minor random changes can be included to the cost data to validate the architecture in a more realistic functioning. These results can improve the knowledge of the scheduling offload method.

Figure 4 shows possible configurations for offloading tasks among network platforms. This figure gives a graphic representation of the sequence of platforms where the application is executed. Other offloading combinations can be considered on the basis of the performance aspect analyzed and the scheduling function.

Fig. 4
figure 4

Configurations for offloading the tasks among the network platforms. a Only device, b Device–mobile network, c Device–mobile network–cloudlet, d Device–cloudlet–cloud server, e Device–base station server, f Device–base station server–cloud server, and g Device–cloud server

Full size image

In the next section, we will describe the behavior of the multi-layer architecture in the different designed scenarios. The results of the simulations are presented in Table 7.

In the normal scenario, the computing cost of processing the entire application in the built-in device of the car was 1000 ms. That is, the autonomous system made a movement decision per second. This cost sets a maximum speed of 10 m/s (36 km/h). This is a normal speed for city streets. The MCC paradigm for this application improved this time, allowing faster speeds using external platforms to outsource computing. In the previous table, the configurations with improved performance are highlighted. In these cases, the speed of the autonomous car could be increased due to the reduced time required to execute each iteration of the application.

Table 7 Simulation results for the offloading configurations in the working scenarios
Full size table

4 Analysis and discussion

The results obtained in the previous section confirm two important findings for the MCC paradigm. First, the multi-layer architecture allowed higher flexibility in offloading the computations along the available network layers to meet the requirements, not only with regard to the time delay but also other performance aspects such as monetary cost and power consumption. The results in Table 7 illustrate the minimum cost configurations for each scenario. For each of them, there are some configurations that can reach the desired performance. Of course, this is just an example, but shows that the network-assisted processing concept provides clear advantages over cloud-targeted outsourcing methods. Second, the proposed multilayer architecture provided additional opportunities to improve application performance and, thus, better regulated the capabilities of mobile devices and connected ‘things’. In all defined scenarios, the achieved speed of 10 m/s was improved using the different offload options. The experiment also demonstrated a comparison with other proposals that use a specific computing platform for offloading. None of the known platforms alone was sufficient to provide an effective response to the problem in all scenarios. However, the communication cost of the network usage must also be considered in the overall performance. In many cases, performance decreased due to the delay in the outsourcing process along the network platforms.

In general, this approach contributes to improving the overall operation of the MCC paradigm. Table 8 describes the main points to address the operational concerns of the MCC described previously.

Table 8 Extended MCC architecture contributions
Full size table

5 Conclusions

In this work, a distributed architecture for outsourcing computation tasks is described. This approach uses all available platforms along the network. In this manner, the proposed model configures an extended MCC paradigm, which allowed the outsourcing of the workload to other platforms. These platforms were separately analyzed to improve processing in previous work, and the main challenges were identified. In this research, it was proposed to use the entire available infrastructure to enhance the MCC paradigm beyond mobile computing applications and to leverage the deployed resources along the network: ad hoc clouds, fog nodes, cloudlets, MEC platforms and cloud servers.

The main advantage of this proposal is the increase in flexibility in processing compute-intensive applications, which makes the system more resilient to environmental changes. The aim of the experiments carried out is to only make visible this flexibility provided by the different offloading options (Fig. 4) and their implications on the overall computing cost (Table 7). The performance data were acquired from previous research works on MCC and offloading frameworks, and from our own estimations. Other source data could produce different performance results. However, the key aspect of the simulations performed was not the specific cost obtained; instead, it was the flexibility and offload possibilities that the proposed multilayer architecture provided. The results show that only the availability of several offload layers can overcome the operating conditions imposed by the application scenarios. This experiment also shows a comparison against other proposals that use a specific computing platform for offloading, since none of the known platforms, by itself, could be sufficient to provide an effective response to the problem in all cases.

The approach presented in this work addresses the problem of providing additional computing power to mobile and embedded devices and contributes to some extent to address the operational concerns of the MCC (Table 8). The major incidence of this architecture occurs in resolving Challenges (2) and (3) due to the higher flexibility provided.

This research provides a wide variety of research lines for future work. In our opinion, these research lines can be classified into two sets: first, the research on interoperability of platforms and discovery of computing services to facilitate the distribution of processing along the network, and second, the design of efficient scheduling methods for outsourcing the work to multiple available computing platforms, especially when the device is functioning in a dynamic environment. In this set are located the QoS management and the performance prediction of the network.