## 2 Background and Motivation  
The edge-fog-cloud architecture is commonly envisioned as a 3-layered model [7; 8; 9]. In this model the edge layer is at the bottom and directly connected to end-user IoT devices, the middle tier is composed of fog nodes, and the cloud layer is at the top, as shown in Figure 1. There are other interpretations of how the interactions between edge, fog, and cloud may occur [10], and this paper follows the model in Figure 1. In this paper, we envision a computing architecture where the IoT devices themselves are utilised as edge resource providers. The idea of a collection of end-user IoT devices collaboratively working as a collective computing resource has been explored in the literature under various terms, such as'mobile device clouds' [11],'mobile edge-clouds' [12], 'human-driven edge computing [13], 'collaborative multi-device computing' [14],'mobile crowd computing' [6] and 'device-enhanced multi-access edge computing' [5] (device-enhanced MEC). In this paper, we use the term 'device-enhanced MEC' to refer to the bottom tier of Figure 1, which provides edge computing services to end-user IoT devices. As shown in the aforementioned research, integrating end-user IoT devices to the edge tier as resource providers can provide performance gain, energy savings, and increased resource utilisation and availability. However, when considering real-life constraints, the co-cooperation amongst device-enhanced edge, fog, and cloud layers becomes essential. We illustrate this in the motivating scenario illustrated in Figure 2.  
Figure 1: A 3-tier architecture for device-enhanced edge, fog, and cloud computing. End-user IoT devices such as smartphones, drones, and robots are integrated as edge resources, forming a local collective resource, and work collaboratively with conventional edge, fog, and cloud servers. Here, [PERSON], has a medical condition which requires her to use a wearable device for constant monitoring of health data. The application QoS requirements in this case include near-real-time response time, a particular level of accuracy, high availability, and secure handling of [PERSON]'s sensitive medical data. She is also concerned about the battery drain of her mobile device and data access fees. The wearable device sends the sensor data to her smartphone for analysis which is not powerful enough to run the AI algorithms required to process this high-velocity stream of data continuously. Hence, this application requires the support of external resources to provide accurate and timely results. [PERSON]'s smartphone has a collaborative resource-sharing middleware installed, which runs in the background of the smartphone and the resource nodes, and acts as an intermediary between applications and external resources. Applications that need external resources connect to available resources through the middleware. In Figure 2, when [PERSON] is at home, [PERSON]'s smartphone connects her to a local collective resource, made up of the collective resources of her family members' smartphones and her home edge server to carry out the sensor data processing tasks. In this situation, all of the participating resource nodes can be considered to be at the edge. Since all of the nodes are trusted, and connectivity is robust, [PERSON] does not have the need to request the support of remote servers. When [PERSON] is traveling in the car with another family member, the local collective resource is made of just two smartphones-Jane's and her family member. Since this particular resource collection does not provide sufficient computing resources to satisfy the QoS requirements of [PERSON]'s app, she further shares the app workload with a conventional edge server located at a base station, as well as with fog and cloud servers. In this situation, the entire workload is not offloaded to the servers, but shared amongst the two smartphones (which form the local collective resource in this case) as well.