Fuzzy-Logic Workload Orchestration Framework for Smart Campuses in Edge-Cloud System Architecture

Abstract

Transforming a conventional university campus into a smart campus by leveraging modern technologies aims to deliver university services efficiently, effectively, and at low cost. Modern technologies enhance campus life by providing services, such as smart classrooms and campus security, on demand. Seamless service delivery requires reliable and efficient access to the services that take into consideration the dynamic contextual attributes related to, e.g., end-device mobility, latency sensitivity, and resource constraints. University staff, students, and visitors frequently submit different types of service requests on the move, which requires a robust orchestration framework capable of managing these requests across edge-cloud environments. The orchestration framework needs to intelligently distribute the workload, taking into consideration the latency sensitivity requirements and contextual conditions, including resource constraints. Therefore, a fuzzy-logic orchestration framework for smart-campus environments in edge-cloud architecture is proposed. The framework incorporates key factors, including user speed, resource utilization, and request delay sensitivity, in the decision-making process to satisfy both service consumers and service providers. It prioritizes latency-sensitive requests while simultaneously enhancing resource utilization efficiency. Simulation-based experimental results demonstrate the effectiveness of the proposed framework compared with benchmark approaches in orchestrating incoming workloads under several user and contextual conditions. Additionally, the results show that the proposed framework improves the execution rate by 30% compared to benchmark models and achieves more than double resource utilization efficiency.

1. Introduction

Edge Computing (EC), also known as a cloudlet or micro-datacenter, is a computing architecture that consists of geo-distributed, interconnected, and resource-constrained nodes located at the proximity of the network [1,2,3,4]. By pushing computational cloud resources to the network edge, low-latency services can be provisioned closer to the data source, mobility support for the mobile users is enhanced, and intelligence in the Internet of Things (IoT) environment is empowered. Furthermore, it has been seen as enabling architecture for several domains, primarily IoT-based environments, and is thus rapidly adopted in, e.g., smart cities, smart factories, robotics, smart homes and buildings, and driverless vehicles [5,6,7]. Moreover, the massive proliferation of IoT devices raises the need for EC, as the number of IoT devices is expected to reach over 32.1 billion by 2030. Hence, EC is a research opportunity hotspot for academia and has potential economic impact due to its potential role in enhancing service performance and responsiveness, especially for emergent technologies.

In a smart-campus environment, which is a subset of smart city applications, the EC paradigm is considered a promising and enabling architecture for transforming traditional university campuses into smart ecosystems [8,9,10,11]. By leveraging its resources, university services can be provided effectively, efficiently, and autonomously. These services are made available on demand for researchers, staff, students, and visitors. Services may include, but are not limited to, smart classrooms (SC), housing, irrigation systems, smart grids, pollution monitoring, and campus security applications. For instance, EC resources can be used to provide SC services [12]. It is utilized to facilitate and automate the evaluation of submitted assignments using intelligent video management systems. This functionality can be further extended to monitor the students’ learning curve by personalizing learning experience. The latency requirement for these scenarios requires efficient task allocation mechanism to fulfill such requirement.

Campus visitors can also utilize edge services, such as Augmented Reality (AR) applications, while moving around the campus. AR provides interactive information related to the campus’ attractive locations or historical buildings aiming to enhance visitors’ experience. Such service requires mobility awareness and continuous connectivity to avoid service disruption. In fact, the characteristics of smart-campus services vary significantly in terms of workload, execution time, and data size, whereas their Quality-of-Service (QoS) metrics are also service-dependent. Additionally, user mobility around the campus may have a significant impact on service failure, as users can move at different speeds based on the mobility mode, such as walking, e-scooters, bikes, or cars. The fulfillment of QoS metrics, especially for latency-sensitive applications, that also takes users’ mobility into consideration can be achieved by an efficient task allocation approach through edge-cloud architecture.

This research employs a fuzzy-logic-based approach to optimize task allocation as an online problem in edge-cloud environments with consideration of prioritizing latency-sensitive applications, users’ mobility awareness, and efficient edge resource utilization. It has been seen as a promising approach that can handle the growth, complexity, and uncertainty that are inherited from the smart-campus environments, as well as its high complexity and computational requirements [7,13,14,15]. It is an if–then rule-based approach that can consider multiple conflicting parameters, such as user speed, service priority, network bandwidth, and resource availability. Several research efforts have been conducted to tackle uncertainty problems using several techniques, including the fuzzy-logic approach [13,14,16,17,18].

Although extensive research, such as [13,15,16], has been conducted with consideration of mobility and application latency sensitivity, the use of fuzzy logic for real-time task allocation in smart-campus environments remains limited and requires further investigation and evaluation. Moreover, this research aims to optimize resource utilization and prioritize latency-sensitive applications, as well as aiming to be mobility-aware, which is represented by end-device speed in the orchestration decisions. Yet, most of existing solutions employed fuzzy logic in general domains, such as [19,20,21], where mixed applications are considered. Moreover, limited research effort targets smart campuses, such as [11,22], where neither address the task allocation problem. In [19], a two-tier fuzzy-based workload orchestration is proposed for collaborative edge-cloud without targeting a specific domain.

Therefore, this paper proposes a context-aware fuzzy-based task allocation framework for smart-campus environments that is able to allocate end-device tasks to most suitable EC resources. The proposed approach also incorporates centralized cloud-computing resources based on predefined fuzzy rules, which means that the cloud can be selected as a candidate resource when some fuzzy rules are applicable. For instance, in case of an IoT device having low speed and its requested service being classified as a latency-tolerant application, it can be offloaded to the cloud. However, the offloading process to the cloud is not always the case, where the consideration of the edge node resource availability must be evaluated. The contribution of this paper can be summarized as follows.

• A context-aware two-tier fuzzy-based task orchestration framework, referred to as the Mobility Fuzzy-based Model (MFBM), is proposed for smart-campus environments. The proposed model incorporates multiple factors, which are task characteristics, user mobility status via mobility speed, and resource availability, in the task orchestration process in order to satisfy three main objectives, which are task priority, resource utilization efficiency, and execution rate. It targets collaborative edge-cloud resources by dynamically offloading the workload to the most suitable resources in accordance with predefined rules. A lightweight decision-making algorithm is developed to prioritize latency-sensitive applications, maximize edge resource utilization, and maximize the execution rate taking into consideration user mobility awareness in the smart campus domain.
• A thorough simulation-based performance evaluation is conducted under diverse and dynamic scenarios, including smart campus daytime and nighttime conditions and applications, to examine the effectiveness of the proposed fuzzy-based solution. Both day and night scenario investigations contribute to understanding the smart campus workload requirements over day and night periods. Additionally, a benchmark, i.e., Sonmez, is considered to assess the ability to generalize the proposed model for off-campus applications.
• An extensive experimental evaluation of the proposed fuzzy-based model is performed against two representative benchmarks, aiming to highlight the superiority and effectiveness of the proposed approach under varying workloads and scenarios.

The remainder of this paper is organized as follows. Section 2 reviews the related work focusing on studies that target task orchestration over both edge and cloud layers. This is followed by Section 3, which presents the system model. Section 4 introduces the mobility fuzzy-logic system architecture, including parameters and membership functions, as well as the decision levels considered in the approach. Section 5 describes experimental design, covering the evaluation scenarios, simulation-related parameters, and evaluation metrics. The results of experiments conducted are presented and discussed in Section 6. Finally, Section 7 concludes the paper and presents the future work plan.

2. Related Work

The task orchestration process determines the responsible resources for executing the submitted tasks by mobile devices. In the context of EC, it has been an active research topic since the emergence of the EC paradigm, driven by continuous development as well as the massive shift of IoT applications towards the network edge. Task allocation across EC nodes is not a trivial task, whereby the edge environment consists of distributed and resource-limited resources, i.e., network, computational, and energy resources. This is more challenging when cloud resources are considered, where the service prioritization mechanism becomes essential. Task allocation has been widely addressed in the literature by using several approaches, such as deep learning, fuzzy logic, and Mixed Integer Linear Programming. The selection of the candidate approach is factor-dependent and is related to, but not limited to, application type, scenario, domain, historical data availability, system architecture, and optimization objectives.

Fuzzy logic has been widely adopted in task orchestration problems, demonstrating its ability to deal with task orchestration as an online problem, particularly, in environments with uncertainty [14]. Fuzzy logic is adopted in this paper due to three main reasons: (1) its promising results in handling uncertainty in the EC as demonstrated by several research studies, such as [7,15,16,19,20,23]; (2) the consideration of event-driven task allocation for mobile devices, which is classified as an online and real-time orchestration problem; and (3) the lack of fuzzy-based model evaluation in smart-campus environments.

Several studies have proposed fuzzy-based models for IoT applications, which can be classified into single-tier fuzzy logic systems and multi-tier fuzzy logic systems. A recent study [16] proposes a single-tier fuzzy-based model for the Internet of Vehicles, targeting vehicle-to-vehicle scenarios. It aims to optimize several parameters related to the execution rate, resource utilization efficiency, and overall system delay, with primary focus on latency-sensitive applications. It evaluates the candidate edge nodes by scoring their ability to handle the tasks based on task priority and using four input variables, which are the physical proximity of the edge node, the urgency of the task, vehicle speed, and the computational power of the node. Simulation-based experiments are conducted using integrated environments, namely the Simulation of Urban Mobility and the Adaptive Neuro-Fuzzy Inference System. The experiments lack fuzzy-based benchmarks, which instead consider, e.g., the Generalized Heuristic Greedy offloading approach, the next fit algorithm, and the random policy algorithm.

A novel fuzzy logic method is proposed to manage the campus parking areas by identifying available parking bays and providing parking recommendations [22]. Although parking management optimization in smart campuses is the aim, task allocation in edge-cloud is not considered. Similarly, fuzzy logic is employed in enhancing the indoor atmosphere in heating, ventilation, and air-conditioning systems for SCs, instead of the task allocation problem [11].

Fuzzy logic also demonstrated its strength in the smart city domain, as illustrated in [17], which proposes a single-tier fuzzy-based service placement strategy. It adopts microservice applications where an application consists of microservices that can be either placed on the same node or distributed across different nodes. Placement decisions are made based on the fuzzy logic model, which determines the performance level of the candidate nodes where the cloud can be utilized once the placement on the edge is impossible. Several input variables are considered, which are the node’s Central Processing Unit (CPU) load, memory usage, the available node bandwidth, the load required for running the service’s blocks, and the service’s required bandwidth. The evaluation is conducted using EdgeCloudSim, taking two benchmarks into consideration. Unlike the earlier presented studies, the performance evaluation does not present sufficient details regarding the simulated applications nor evaluation metrics that highlight its effectiveness in terms of cost objectives. In contrast, our study targets a specific domain, which is the smart city domain, and provides experimental validation to the considered objectives. Similarly, a service placement strategy, which is molded as a set of microservices, using fuzzy logic is proposed to enable fast and low-cost deployment in edge infrastructure [17]. EdgeCloudSim is also used to evaluate the proposed strategy.

A fuzzy inference mechanism for data-driven applications is proposed to make offloading decisions based on data overlapping, task delay sensitivity, and Virtual Machine (VM) utilization [24]. Three offloading options can be made, which are the local node, i.e., the nearest edge node, the neighbor edge node, or the cloud. EdgeCloudSim is used in evaluating the proposed mechanism against cloud-based and EC-based mechanisms, which utilize only the edge layer. Compared to our work, classical benchmarks are considered, whereas it is essential to use fuzzy-logic approaches to demonstrate its effectiveness.

A novel generic fuzzy-based logic offloading algorithm for edge-cloud architecture is introduced in [7] for latency-sensitive applications, with overall service time optimization as the primary objective. It uses four input variables, which are VM utilization, task length, network demand, and task delay sensitivity, with belief in its significance in supporting the targeted objective. Several experiments are conducted using EdgeCloudSim with three benchmarks. Although the experiments show remarkable results over various evaluation metrics, the results lack sufficient details to show the effectiveness of the proposed algorithm in terms of latency-sensitive applications. In [16], a fuzzy-based offloading scheme is proposed. It utilizes EC, which is a mobile vehicle, to process resource-intensive vehicular tasks to optimize the execution rate and system delay. Tasks are offloaded to another vehicle by prioritizing tasks based on their urgency using the fuzzy model. Two offloading layers are considered, which are the local mobile vehicle and another vehicle.

Several fuzzy-based models are designed using multi-tier architecture. For instance, a two-step multi-objective fuzzy-based strategy is introduced in [20]. It aims to enhance resource utilization, reduce the task failure rate, and reduce the service time by prioritizing the tasks to be executed in collaborative edge-cloud environments. This study adopts the same offloading decisions that are adopted by [7], which can be the local edge, the neighbor edge, or the cloud. Further, the same input variables are considered, except the network demand is replaced by Wide Area Network (WAN) bandwidth to account for the network bandwidth once the cloud resource is selected. The first step considers edge node resources, i.e., the local node or the neighbor node, while the second step considers edge and cloud resources. Four different applications and benchmarks are used to evaluate the proposed strategy using EdgeCloudSim. Although the proposed model efficiently offloads the workload to the most suitable layer, which outperforms other benchmarks, a clear limitation is the evaluation of the proposed model to deal with latency-sensitive applications. This is due to the absence of application details and the presented results that aggregate results across all applications regardless of the specifications of individual applications.

In [23], a collaborative fuzzy-logic task-offloading scheme for mobile EC-enabled densely deployed small-cell networks is proposed. It evaluates the edge node load to determine the candidate nodes, which can be the local, neighbor Small Base Station Multi-access Edge Computing (SBS-MEC) server or the cloud, which is not considered as part of the fuzzy system decision. The cloud layer is selected only when there is no collaboration between the edge nodes. It uses five input variables, which are the task size, the delay sensitivity of the task, the local SBS-MEC VM utilization, network delay, and the neighbor SBS-MEC VM utilization. The evaluation is conducted using EdgeCloudSim, which considers the AR application and non-fuzzy logic models as benchmarks.

A two-tier fuzzy logic workload orchestration model for EC is proposed in [19]. The adoption of two stages is to reduce the handling node complexity. The first stage selects the best candidate node at the edge layer, whereas the second stage compares the edge with the cloud. Computational, network, and task requirements are considered to make the offloading decision that can be the local edge node, the alternative edge node, or the cloud. A comprehensive evaluation is conducted using EdgeCloudSim and taking into consideration the multi-application scenario and both the fuzzy-based and the non-fuzzy models as benchmarks. A major limitation is that optimization objectives are not explicitly defined.

A two-stage belief rule-based orchestration model built based on fuzzy logic is proposed in [21]. The first stage makes offloading decisions across the edge layer using CPU utilization of both the local and the least loaded edge and the Metropolitan Area Network (MAN) delay, while the second stage compares the candidate edge with the cloud using the CPU utilization of the candidate edge node, WAN bandwidth, delay sensitivity, and the CPU utilization of cloud. Indeed, making utilization-based decisions for the cloud represents a key limitation as it, by nature, has unlimited capacity.

In [25], fuzzy logic and EC are employed to optimize the distributed generation placement and extend electric vehicle lifespan in the smart grid. EC is used to monitor the energy, execute the fuzzy inference algorithm, and reduce the central grid overload by neighboring coordination. The proposed framework can optimize battery life, reduce latency, and improve reliability. The study, however, does not focus on task orchestration through the edge-cloud environment, where it employs the edge to run the fuzzy logic system. In [13], a two-stage fuzzy-based scheduling technique is proposed for the vehicle ad hoc network, aiming to minimize latency and energy consumption while enhancing response time. The simulation experiments are conducted using iFogSim to model the vehicle ad hoc scenario.

Fuzzy logic can be designed with a three-stage system as proposed in [15], which introduces task prioritization and a three-level fuzzy logic manager. The manager decides the processing resource which can utilize the mobile device, the local edge node, the alternative edge node, or the cloud. The first step determines whether the task should be processed on a mobile device or the local edge node. The second stage decides between the local edge and the candidate edge. The third stage decides between the best edge node and the cloud. It uses EdgeCloudSim to evaluate the proposed model, taking four different applications with different requirements into consideration. The key strength of this paper is the detailed performance evaluation to show the effectiveness of the proposed model for each considered application under various benchmarks.

There are other approaches that are used to orchestrate the IoT tasks, such as prediction models and reinforcement learning. In [26], an offloading approach is proposed to optimize the latency of both the network and the execution time. A prediction algorithm is also proposed to predict the specifications of mobile applications, which helps in decision-making. Reinforcement learning is another method that shows its ability to orchestrate edge tasks, which employs deep learning in [27]. A reinforcement-based framework for dynamic service placement in the EC environment is introduced. It aims to minimize the delay under the constraints of physical resources and operational costs. As part of the solution, a service migration mechanism is proposed to avoid invalid status in the decision.

Table 1. Related work comparison.

Paper	Layers		Mobility	Domain	Optimization Objectives
	Edge	Cloud
[19]	Yes	Yes	No	Unspecified (generic)	Not specified
[7]	Yes	Yes	No	Latency-sensitive applications	Service time
[11]	N/A	N/A	No	Smart classroom atmosphere	N/A
[22]	N/A	N/A	Yes	Smart parking at university campus	N/A
[20]	Yes	Yes	No	Unspecified (generic)	Resource utilization Task failure rate Service time
[15]	Yes	Yes	Yes	Latency-sensitive applications Heavy task applications	Resource utilization Latency QoS (not specified)
[23]	Yes	Yes	No	Mobile EC enabled densely deployed small-cell networks	Response time Execution latency
[16]	Yes	No	Yes	Latency-sensitive applications in vehicle to vehicle	Task execution rate Overall system delays Resource utilization
[21]	Yes	Yes	No	Unspecified (generic)	Not specified
[24]	Yes	Yes	No	Data driven	Resource utilization
[17]	Yes	Yes	Yes	Unspecified (generic)	Cost–Latency
[25]	Yes	No	No	Smart grid Electric vehicle	Distributed generation allocation Enhance electric vehicle longevity
[13]	Yes	Yes	Yes	Intelligent transportation system	Energy consumption Response time
This study	Yes	Yes	Yes	Smart campus	Resource utilization Task prioritization Task execution rate

below compares the most relevant studies under five criteria to position and highlight the significance of this study compared to the literature. The literature analysis reveals a clear research gap in the exploration of the fuzzy-based approach in the workload orchestration process in smart-campus environments. Furthermore, most of existing studies either focus on general edge-cloud environments or consider a subset of critical factors, such as latency and resource utilization, whereas a domain-specific approach and the impact of multiple factor combinations in a unified decision-making framework can significantly enhance the overall system performance. So, this gap is related to the research domain, i.e., a smart campus, taking mobility awareness, resource utilization efficiency, and latency-sensitive application prioritization into consideration.

Therefore, this paper proposes a context-aware fuzzy-logic-based workload orchestration technique that prioritizes latency-sensitive applications to be executed closer to the end device, hence reducing the overall system latency. Unlike existing approaches, it incorporates multiple factors, including user mobility speed as a mobility indicator, tasks’ delay sensitivity, and resource availability, in the decision-making process, aiming to efficiently utilize edge nodes by maximizing the edge execution rate and resulting in higher resource utilization, while maintaining low latency for latency-sensitive applications by processing them closer to the end devices and enabling cloud utilization in accordance with predefined fuzzy rules. Such a technique can enable the balance between the considered objectives. Indeed, both service time for latency-sensitive applications and efficient resource utilization are significant factors in EC. On one hand, EC emerged to reduce the latency caused by utilizing cloud resources that are located away from the data source. On the other hand, edge nodes are resource-limited by nature.

3. System Modeling

In edge-cloud environments, services demanded by the end-devices, e.g., IoT devices, can be executed on either edge or cloud resources. Hence, a multi-tier approach is the most suitable system architecture that can be used to model the paper’s environment. It is modeled using three layers, which are the end-devices layer, the edge layer, and the cloud layer, where each layer has distinct functions.

Let assume that $D=\{d_1, {d }_2, \dots , d_n\}$ denotes the set of end-devices, such as IoT devices, smart watches, and smartphones, that are located on the end-devices layer. These devices are connected to the upper layer, which is the edge layer, via either the Wireless Local Area Network or telecom-based networks. Further, they instantiate service requests $R=\{r_1, {r }_2, \dots , r_x \}$ to access a wide range of applications $A=\{a_1, {a }_2, \dots , a_i\}$ that are deployed on both edge and cloud layers. Each $r_x ϵ R$ has specific requirements that are modeled as $r_x=(a_i,{UD}_x, {DD}_x, {TL}_x, {RC}_x, {UE}_x, {UC}_x, {DS}_x)$; these notations are defined in

Table 2. System symbols and notations.

Symbol	Notation
$D$	Set of end devices located at the end-device layer, where $d_n\in D$
$R$	Set of requests generated by $D,$ where $r_x\in R$
$A$	Set of applications or services consumed by $D,$ where $a_i\in A$
$UD$	Size of uploaded data for each ${UD(r}_x)$ and ${\overline{UD}}_i$
$DD$	Size of downloaded data for each ${DD(r}_x)$ and ${\overline{DD}}_i$
$TL$	Task length for each ${TL(r}_x)$ and ${\overline{TL}}_i$
$RC$	Required number of cores ${RC(r}_x)$ and ${RC}_i$
$UE$	Utilization percentage on edge for each ${UE(r}_x)$ and ${UE}_i$
$UC$	Utilization percentage on cloud for each ${UC(r}_x)$ and ${UC}_i$
$DS$	Dilay sensitivity for each ${DS(r}_x)$ and ${DS}_i$
$UP$	Usage percentage of each $a_i\in A$
$MC$	Set of mini-cloud (i.e., edge nodes) resides in edge layer

. Once a $r_x$ is processed by the candidate layer, i.e., the edge or the cloud, the response is sent back to the end device $d_n ϵ D$. These applications and services, notated as $a_i ϵ A$, are related to the smart campus domain, such as smart emergency (SE) and smart parking (SP). Each application has its own requirements, which are $a_i=({UD}_i, {DD}_i, {TL}_i, {RC}_i, {UE}_i, {UC}_i, {DS}_i, {UP}_i)$, as defined in Table 2. Further details regarding the requirements of the adopted applications are presented in Section 5.2.

The edge layer, which is the intermediate layer located at the network proximity, consists of a set of geo-distributed and resource-restricted nodes represented as $MC=\{{mc}_1,{mc}_2,\dots ,{mc}_j\}$, which are responsible for processing the requested services $r_xϵR$, and the edge orchestrator, whereby it is responsible for making offloading decisions. Offloading decisions can be local processing on the local edge node ${mc}_jϵMC$, the most suitable neighbor edge node ${mc}_jϵMC$, or the cloud, which is based on fuzzy logic rules as illustrated in Section 4. The edge node can be seen as a micro-datacenter that is a virtualized environment with the ability to run various applications on demand.

The top layer is the cloud layer, where the huge and unlimited datacenter resides. This layer can be utilized once the defined fuzzy logic rules are met. These cases include processing the latency-tolerant requests in case of edge nodes being fully utilized.

4. Fuzzy Logic System Architecture

In highly dynamic environments like edge-cloud environments, uncertainty is a fundamental issue that represents a significant challenge towards the efficient task orchestration process, aiming to optimize resource utilization enhancement, latency minimization, and execution rate maximization with mobility awareness. Hence, a multi-tier fuzzy-logic-based approach is employed to perform efficient task orchestration across edge-cloud environments, considering these objectives. A fuzzy-based model is capable of orchestrating the received requests by the IoT devices to decide the most suitable offloading resource, whereby there are three candidates which are local edge node, most suitable neighbor edge node, or cloud. The offloading decision is taken based on a two-tier fuzzy logic system model, as illustrated in Figure 1 and Algorithm 1.

Algorithm 1. Two-tiers offloading decision for the proposed MFBM

i: ii: iii: iv: v: vi: vii: viii: ix: x: 1: 2: 3: 4: 5: 6: 7: 8: 9:

Input: Values of the input variables      $r_x$: request generated by an end device      $\nu$: Device speed     $\mathcal{l}\rho$: Local edge utilization     $\mathcal{r}\rho$: Remote edge utilization     $\tau$: Task delay sensitivity     $\delta$: MAN delay     $\mathcal{l}$: Task length     $\beta$: WAN bandwidth Output: offloading_decision (local edge, remote edge, cloud) Begin $\mathbf{For} \mathrm{each} r_x$ do      $\mathbf{Call} \mathrm{first} \mathrm{tier} \mathrm{MFBM} (\nu ,\mathcal{l}\rho ,\mathcal{r}\rho ,\tau ,\delta$)            Target_node ← candidate edge node (local or neighbored node)      $\mathbf{Call} \sec \mathrm{ond} \mathrm{tier} \mathrm{MFBM} (\nu ,\mathcal{r}\rho ,\tau ,\mathcal{l},\beta$)            Target_node ← (candidate edge node or cloud)      offloading_decision ← Target_node End for End

To present the details of the proposed fuzzy system, the fuzzy generic architecture is used, which consists of three main parts, which are fuzzification, inference engine, and defuzzification, as depicted in Figure 1. The details of these parts in relation to the proposed two-tier MFBM are presented below.

4.1. First-Tier Fuzzy Logic System Architecture

The first tier in the proposed fuzzy-logic system architecture uses the input variables to decide the processing location of the received task, which can either be the local edge, i.e., the edge node that received the task, or it can be offloaded to the nearest suitable edge node.

4.1.1. Fuzzification

Fuzzification is the process of converting input variables into fuzzy sets using defined membership functions. As depicted in Figure 1, five input variables are selected at this tier, which are device speed, local edge utilization, remote edge utilization, task delay sensitivity, and MAN delay, which are represented as $F_{\nu }$, $F_{\mathcal{l}\rho }$, $F_{\mathcal{r}\rho }$, $F_{\tau }$, and $F_{\delta }$, respectively. The selection of these input variables is critical, as they directly contribute to system objective fulfillment. The device speed variable is adopted as high-level indicator for user mobility behavior in a campus, which is a critical variable in offloading the decision-making process. For instance, when user speed is classified as fast and a latency-sensitive application is requested, it is important to classify this user as high-priority in execution on the local or the nearest edge node, as the connection is most likely to be lost. Hence, this variable enables mobility-aware orchestration by adapting offloading decisions based on user movement. Three linguistic terms are used for the speed variable, which are slow, medium, and fast, representing the device’s mobility speed. Three membership functions are employed, namely left shoulder $\mathrm{L}$, trapezoidal, and right shoulder $\mathrm{\Gamma }$, to quantify the linguistic terms, as described in Equations (1)–(3).

$${\mu }_{slow} \left(x\right) =\left\{\begin{array}{c}1; x\le 20\\ \left(21-x\right); 20<x<21\\ 0; x\ge 21\end{array}\right.$$

(1)

$${\mu }_{medium}\left(x\right) =\left\{\begin{array}{c}0; x\le 20\\ \left(x-20\right); 20<x<21\\ 1; 21\le x\le 60\\ \left(61-x\right); 60<x<61\\ 0; x\ge 61\end{array}\right.$$

(2)

$${\mu }_{fast} \left(x\right) =\left\{\begin{array}{c}0; x\le 60\\ \left(x-60\right); 60<x<61\\ 1; x\ge 61\end{array}\right.$$

(3)

The local edge utilization variable is a key indicator of the current load of the node connected to the end-device. The awareness of local edge utilization helps in deciding whether to process the request on the local node, which helps reduce MAN resource consumption, overall latency, and task execution rate improvement, or to offload it to the nearest node to avoid high latency and task failure, especially in hotspot areas. The linguistic terms that are used for the local edge variable are low, medium, and high. The membership functions for these terms are left shoulder $\mathrm{L}$, triangular, and right shoulder $\mathrm{\Gamma }$, as described in Equations (4)–(6).

$${\mu }_{low} \left(x\right) =\left\{\begin{array}{c}1; x\le 20\\ \left({\displaystyle \frac{40-x}{20}}\right); 20<x<40\\ 0; x\ge 40\end{array}\right.$$

(4)

$${\mu }_{medium }\left(x\right)=\left\{\begin{array}{c}0 ; x\le 30\\ \left({\displaystyle \frac{x-30}{20}}\right); 30<x\le 50\\ \left({\displaystyle \frac{70-x}{20}}\right); 50<x<70\\ 0 ; x\ge 70 \end{array}\right.$$

(5)

$${\mu }_{high} \left(x\right) =\left\{\begin{array}{c}0 ; x\le 60\\ \left({\displaystyle \frac{x-60}{20}}\right); 60<x<80\\ 1 ; x\ge 80\end{array}\right.$$

(6)

The remote edge utilization variable is the utilization of an edge node that has the lowest load. The evaluation of this node is important to help keep the latency-sensitive applications close to the data source by processing them on the edge layer. Furthermore, it also helps utilize edge nodes effectively, hence achieving a better execution rate on the edge. Likewise, remote edge utilization adopts the same linguistic terms and membership functions that are adopted in local edge utilization.

The task delay sensitivity variable is used as an indicator to determine the task delay sensitivity, as it represents the tolerance of the task in terms of execution time, hence supporting QoS fulfillment. Low, medium, and high are linguistic terms are used for the task delay variable classes and left shoulder $\mathrm{L}$, triangular, and right shoulder $\mathrm{\Gamma }$ are membership functions for these terms, as described in Equations (7)–(9).

$${\mu }_{low}\left(x\right) =\left\{\begin{array}{c}1; x\le 0.2\\ \left({\displaystyle \frac{0.4-x}{0.2}}\right); 0.2<x<0.4\\ 0; x\ge 0.4\end{array}\right.$$

(7)

$${\mu }_{medium }\left(x\right)=\left\{\begin{array}{c}0 ; x\le 0.3\\ \left({\displaystyle \frac{x-0.3}{0.2}}\right); 0.3<x\le 0.5\\ \left({\displaystyle \frac{0.7-x}{0.2}}\right); 0.5<x<0.7\\ 0 ; x\ge 0.7 \end{array}\right.$$

(8)

$${\mu }_{high} \left(x\right) =\left\{\begin{array}{c}0 ; x\le 0.6\\ \left({\displaystyle \frac{x-0.6}{0.2}}\right); 0.6<x<0.8\\ 1 ; x\ge 0.8\end{array}\right.$$

(9)

Lastly, the MAN delay variable is a critical factor when making offloading decisions to a remote edge node, as offloading might be impossible once the MAN is congested. The selected linguistic terms are low, medium, and high, which correspond to left shoulder $\mathrm{L}$, triangular, and right shoulder $\mathrm{\Gamma }$, respectively, as described in Equations (10)–(12).

$${\mu }_{low} \left(x\right) =\left\{\begin{array}{c}1; x\le 0.001\\ \left({\displaystyle \frac{0.004-x}{0.003}}\right); 0.001<x<0.004\\ 0; x\ge 0.004\end{array}\right.$$

(10)

$${\mu }_{medium }\left(x\right)=\left\{\begin{array}{c}0 ; x\le 0.002\\ \left({\displaystyle \frac{x-0.002}{0.005}}\right); 0.002<x\le 0.007\\ \left({\displaystyle \frac{0.012-x}{0.005}}\right); 0.007<x<0.012\\ 0 ; x\ge 0.012 \end{array}\right.$$

(11)

$${\mu }_{high} \left(x\right) =\left\{\begin{array}{c}0 ; x\le 0.010\\ \left({\displaystyle \frac{x-0.01}{0.003}}\right); 0.010<x<0.013\\ 1 ; x\ge 0.013\end{array}\right.$$

(12)

The selection of these variables, i.e., $F_{\mathcal{l}\rho }$, $F_{\mathcal{r}\rho }$, $F_{\tau }$, and $F_{\delta }$, and their membership functions are inspired by [19], as they have a significant contribution in QoS fulfillment. This work, however, extends and enhances the model by considering more variables to provide fine-grained offloading decisions. Their integration and configuration in this paper specifically aim to address workload orchestration in a domain-specific environment, i.e., a smart campus, which is not considered in [19]. Additionally, the integration of user mobility awareness and the framework objectives, which are task priority, resource utilization efficiency, and execution rate enhancement are novel aspects of the designed framework. A summary of the input variables is shown in

Table 3. First tier input variables.

Input Variable	Notation	Fuzzy Set	Membership Function
Device speed	$F_{\nu }$	Slow, Medium, Fast	$\mathrm{L}$ shoulder, Trapezoidal, $\mathrm{\Gamma }$ shoulder
Local edge utilization	$F_{\mathcal{l}\rho }$	Low, Medium, High	$\mathrm{L}$ shoulder, Triangular, $\mathrm{\Gamma }$ shoulder
Remote edge utilization	$F_{\mathcal{r}\rho }$	Low, Medium, High	$\mathrm{L}$ shoulder, Triangular, $\mathrm{\Gamma }$ shoulder
Task delay sensitivity	$F_{\tau }$	Low, Medium, High	$\mathrm{L}$ shoulder, Triangular, $\mathrm{\Gamma }$ shoulder
MAN delay	$F_{\delta }$	Low, Medium, High	$\mathrm{L}$ shoulder, Triangular, $\mathrm{\Gamma }$ shoulder

.

4.1.2. Inference Engine

This step aims to specify the fuzzy output, which will be used in the defuzzification stage, based on the input variables and by using a series of linguistic rules. In fuzzy systems, these rules are if–then-based and make the final decision. For instance, IF $\nu$ is Fast AND $\mathcal{l}\rho$ is Low AND $\mathcal{r}\rho$ is Low AND $\tau$ is Low AND $\delta$ is High THEN offloading decision is Local edge. The design of these rules is a critical process, as the overall system performance, including the targeted objectives, will be significantly influenced by them. Therefore, the rules and their corresponding decisions are carefully designed by a knowledgeable domain expert and supported by insights gained from the literature. Further, these rules capture the intuitive relationships between the selected system parameters. In the proposed fuzzy model, 234 fuzzy rules are specified, as there are five input variables with three linguistic terms, which represent the possible combinations. These rule decisions are carefully reviewed to cover all possible combinations and ensure logical consistency to avoid conflicting decisions. A sample of the defined fuzzy rules is listed in

Table 4. First-tier sample rules.

Input Variable	R1	R2	R3	R4	R5	R6
Device speed	Fast	Slow	Medium	Fast	Slow	Fast
Local edge utilization	Low	High	High	High	Low	Low
Remote edge utilization	Low	Low	Low	Low	High	High
Task delay sensitivity	Low	Low	Low	Low	High	High
MAN delay	High	Low	Low	Low	High	Low
Offloading decision	Local	Remote	Remote	Remote	Local	Local

.

4.1.3. Defuzzification

The last step maps the inference engine outputs into a single crisp value that is in human-friendly format. The centroid defuzzifier is adopted following [19]. Figure 2 shows the membership functions that specify the offloading decision classes, namely the local edge node and the remote edge node.

4.2. Second-Tier Fuzzy Logic System Architecture

The second tier in the proposed MFBM architecture uses five different input variables, as shown in Figure 1, to decide the processing resources that are responsible for handling the received task. The decisions of this tier can either be an edge node or the cloud layer, where more and unlimited resources are available. The utilization of the cloud layer is influenced by some factors where task delay sensitivity and user mobility speed are the cornerstone variables.

4.2.1. Fuzzification

Five variables are selected, which are device speed, remote edge utilization, task delay sensitivity, task length, and WAN bandwidth, and notated as $F_{\nu }$, $F_{\mathcal{r}\rho }$, $F_{\tau }$, $F_{\mathcal{l}}$, and $F_{\beta }$, respectively. The device speed variable represents the user mobility speed, which is used to make offloading decisions. Its membership functions are similar to those used in the first tier, which are left shoulder $\mathrm{L}$, trapezoidal, and right shoulder $\mathrm{\Gamma }$, for slow, medium, and high linguistic terms, respectively. The remote edge utilization is the candidate edge node that is selected in the first tier. The consideration of this variable is to examine the effectiveness of utilizing this node compared to the cloud in accordance with other variables. This is critical, as the candidate node might be overloaded, which leads to higher execution time, and a higher task failure rate is expected. The task-delay-sensitivity variable is used as an indicator to determine task priority in processing, as it represents the tolerance of the task in terms of execution time; hence, this variable contributes to QoS fulfillment.

The task length, which is calculated as the number of instructions per second, is important due to the limited capacity of edge nodes which may be unable to accommodate requests with a huge number of instructions. It can be used as an indicator of the amount of the execution time required. Alongside other variables, it contributes to efficient edge utilization and QoS fulfillment, where some request can have better performance once they are offloaded to the cloud, especially those with computationally intensive workloads. Three linguistic terms are used, which are low, medium, and high, and $\mathrm{L}$ left shoulder, triangular, and $\mathrm{\Gamma }$ right shoulder as membership functions are adopted for these terms, respectively, as described in Equations (13)–(15).

$${\mu }_{low}\left(x\right) =\left\{\begin{array}{c}1; x\le 4000\\ \left({\displaystyle \frac{8000-x}{4000}}\right); 4000<x<8000\\ 0; x\ge 8000\end{array}\right.$$

(13)

$${\mu }_{medium }\left(x\right)=\left\{\begin{array}{c}0 ; x\le 6000\\ \left({\displaystyle \frac{x-6000}{6000}}\right); 6000<x\le \mathrm{12,000}\\ \left({\displaystyle \frac{\mathrm{18,000}-x}{6000}}\right); \mathrm{12,000}<x<\mathrm{18,000}\\ 0 ; x\ge \mathrm{18,000} \end{array}\right.$$

(14)

$${\mu }_{high} \left(x\right) =\left\{\begin{array}{c}0 ; x\le \mathrm{16,000}\\ \left({\displaystyle \frac{x-\mathrm{16,000}}{4000}}\right); \mathrm{16,000}<x<\mathrm{20,000}\\ 1 ; x\ge \mathrm{20,000}\end{array}\right.$$

(15)

The WAN bandwidth variable must be considered when deciding to offload to the cloud layer. Although the cloud layer consideration is beneficial, offloading some workload might be ineffective. For instance, an intelligent parking application is requested, which is a latency-tolerant application, and can be executed on the cloud. However, the execution of this application on the cloud might not always be visible, as the network might be congested, hence resulting in high delay that might exceed the acceptable QoS requirements. Like the previous variable, low, medium, and high are adopted as linguistic terms, and $\mathrm{L}$ left shoulder, triangular, and $\mathrm{\Gamma }$ right shoulder as membership functions, as represented in Equations (16)–(18).

$${\mu }_{low} \left(x\right) =\left\{\begin{array}{c}1; x\le 2\\ \left({\displaystyle \frac{4-x}{4}}\right); 2<x<4\\ 0; x\ge 4\end{array}\right.$$

(16)

$${\mu }_{medium }\left(x\right)=\left\{\begin{array}{c}0 ; x\le 3\\ \left({\displaystyle \frac{x-3}{2}}\right); 3<x\le 5\\ \left({\displaystyle \frac{7-x}{2}}\right); 5<x<7\\ 0 ; x\ge 7 \end{array}\right.$$

(17)

$${\mu }_{high} \left(x\right) =\left\{\begin{array}{c}0 ; x\le 6\\ \left({\displaystyle \frac{x-6}{2}}\right); 6<x<8\\ 1 ; x\ge 8\end{array}\right.$$

(18)

Both input variables, i.e., the task length and the WAN bandwidth, are inspired by [19] and carefully reviewed and integrated into this paper by a knowledgeable domain expert. A summary of the presented variables is listed in

Table 5. Second-tier input variables.

Input Variable	Notation	Fuzzy Set	Membership Function
Device speed	$F_{\nu }$	Slow, Medium, Fast	$\mathrm{L}$ shoulder, Trapezoidal, $\mathrm{\Gamma }$ shoulder
Remote edge utilization	$F_{\mathcal{r}\rho }$	Low, Medium, High	$\mathrm{L}$ shoulder, Triangular, $\mathrm{\Gamma }$ shoulder
Task delay sensitivity	$F_{\tau }$	Low, Medium, High	$\mathrm{L}$ shoulder, Triangular, $\mathrm{\Gamma }$ shoulder
Task length	$F_{\mathcal{l}}$	Low, Medium, High	$\mathrm{L}$ shoulder, Triangular, $\mathrm{\Gamma }$ shoulder
WAN bandwidth	$F_{\beta }$	Low, Medium, High	$\mathrm{L}$ shoulder, Triangular, $\mathrm{\Gamma }$ shoulder

.

4.2.2. Inference Engine

This step specifies the fuzzy output based on the input variables using fuzzy rules. As stated in the first tier, a knowledgeable domain expert defines these rules based on the most suitable offloading location in accordance with the input variables and their relationships. A sample of the fuzzy rules is listed in

Table 6. Second-tier sample rules.

Input Variable	R1	R2	R3	R4	R5	R6
Device speed	Slow	Medium	Fast	Fast	Slow	Slow
Remote edge utilization	Low	Low	High	High	High	Medium
Task delay sensitivity	Low	High	Low	Low	Low	Low
Task length	High	Low	High	Medium	Low	High
WAN bandwidth	Low	Low	Low	Medium	Low	Medium
Offloading decision	Cloud	Edge	Cloud	Cloud	Cloud	Cloud

.

4.2.3. Defuzzification

At this step, the crips value will be derived from the inference engine output. The offloading decision classes, which are the remote edge node and the cloud, are shown in Figure 3, and are adopted based on [19].

4.3. Offloading Decision Algorithm

In Algorithm 1, when given a set of requests $r_x\in R$ submitted by the end devices, the objective is to make offloading decisions to the most suitable resources, which can either be the local edge node, the neighbor node, or the cloud. The decision is made while taking several input variables into consideration, which are $\nu$ device speed, $\mathcal{l}\rho$ local edge utilization, $\mathcal{r}\rho$ remote edge utilization, $\tau$ task delay sensitivity, $\delta$ MAN delay, $\mathcal{l}$ task length, and $\beta$ WAN bandwidth.

For each incoming request $r_x$ submitted by an end device (line 2) that requires being offloaded to the most suitable resources, the first tier of the MEBM uses $\nu , \mathcal{l}\rho , \mathcal{r}\rho , \tau , \mathrm{a}\mathrm{n}\mathrm{d} \delta$ as the input variables for deciding where to offload the request within the edge layer (lines 3 and 4). The second tier then uses $\nu , \mathcal{r}\rho , \tau , \mathcal{l}, \mathrm{a}\mathrm{n}\mathrm{d} \beta$ as the input variablesto compare the candidate edge node with the cloud (lines 5 and 6). The final offloading decision is made by selecting the targeted node (line 7).

The computational complexity of the proposed algorithm is $O\left(n\right)$, where n is the number of requests submitted by the end devices, as a linear amount of time is required to execute the algorithm.

5. Experiment Design

This section presents the experimental design adopted in this paper to evaluate the performance of the proposed MFBM. It illustrates the evaluation scenario, smart campus applications, the simulation setup, the considered benchmarks, and evaluation metrics.

5.1. Evaluation Scenario

A thorough evaluation is essential to examine the performance of the proposed MFBM in the context of a smart-campus environment. This evaluation has to consider the specified performance objectives which are the execution rate, resource utilization efficiency, and latency-sensitive application prioritization. It is assumed that university students, employees, and staff are moving around the campus and within buildings. Their mobility patterns can be by, e.g., walking, e-scooters, bikes, and cars, where different mobility speeds can be recognized.

To simulate user mobility, the nomadic mobility model, which is built in the adopted simulator, i.e., EdgeCloudSim, is adopted. This model enables the simulation of users moving between different locations on the campus, where the user remains waiting in a specific area for a random amount of time before moving to another area. It is assumed that the simulation environment consists of different areas, where each belongs to one of three categories, namely area 1, area 2, and area 3. Each category has a specific waiting time, as listed in

Table 7. Simulation parameters.

Parameters (Unit)	Day and Night Scenarios	Sonmez Scenario
Simulation time (minute)	31 (1 warm-up)	31 (1 warm-up)
# of iterations	10	10
Mobility model	Nomadic	Nomadic
Waiting time (Second)	Area 1 = 480, Area 2 = 240, and Area 3 = 120.	Area 1 = 480, Area 2 = 240, and Area 3 = 120.
Minimum # of devices	200	200
Maximum # of devices	2000	2000
Domain	Smart campus	Unspecified
Applications	SE, SC, AR, SP	AR, HA, HCP, IA
Usage percentage (KB)	Day: SE = 5, SC = 30, AR = 25, SP = 40	AR = 30, HA = 20, HCP = 20, IA = 30
	Night: SE = 40, SC = 10, AR = 25, SP = 25
Uploaded data size (KB)	SE = 8060, SC = 1226, AR = 5120, SP = 3	AR = 1500, HA = 20, HCA = 2500, IA = 25
Downloaded data size (KB)	SE = 5, SC = 1, AR = 5, SP = 3	AR = 25, HA = 1250, HCA = 200, IA = 1000
Edge utilization (%)	SE = 20, SC = 10, AR = 10, SP = 5	AR = 6, HA = 2, HCA = 30, IA = 10
Cloud utilization (%)	SE = 2, SC = 1, AR = 1, SP = 0.5	AR = 0.6, HA = 0.2, HCA = 3, IA = 10
Task length (MIPS)	SE = 4000, SC = 2000, AR = 500, SP = 500	AR = 9000, HA = 3000, HCA = 45,000, IA = 15,000

Kilobyte (KB), smart emergency (SE), smart classroom (SC), augmented reality (AR), smart parking (SP), health application (HA), heavy computation application (HCP), information application (IA), million instructions per second (MIPS).

. This model can reflect real and normal campus scenarios, user behavior, and various mobility speeds. For instance, a student can either be located in the library, a classroom, or moving between buildings by, e.g., walking or running. The student can stay in the library for a certain amount of time, then move from the library building to the classroom building to attend a lecture. In both the classroom and the library, the student spends more time, where the connection is stable, compared to moving from one building to another, where the connection is not stable and most likely to be degraded or lost; hence, task failure occurs.

Furthermore, users can access a wide range of services and applications, such as SE and SP. The complete list of applications is presented in Section 5.2. In real-world scenarios, task demand fluctuates, and application type is varied over day and night. Therefore, the evaluation process considers the models’ performance during both day and night. These scenarios are annotated as the day scenario and the night scenario. This can be simulated by specifying the usage percentage for each application, as presented in Table 7.

Additionally, it is vital to assess the possibility of extending the proposed MFBM to cover generic domain applications. Thus, the Sonmez et al. [19] scenario, referred to in this paper as the Sonmez scenario, is considered, which brings different scenarios, a set of application types—where each application has different simulation settings—and simulation configurations. The consideration of this study is critical to evaluate the effectiveness of the designed framework and the adopted models in different environmental settings, as well as to explore its limitations under different scales and conditions. A summary of these scenarios is listed in

Table 8. Experiment scenarios.

Scenario	Description
Day	Evaluate the proposed MFBM during daytime.
Night	Evaluate the proposed MFBM during nighttime.
Sonmez [19]	Evaluate the proposed MFBM under a generic domain with different applications.

.

All scenarios are simulated for 30 min, which is sufficient to capture and observe the system dynamicity and behavior, and 1 min as a warm-up period, which is long enough to get the simulation components up and ready. The simulation experiments are conducted using various numbers of users, following an incremental approach starting from 200 end-devices up to 2000 end-devices. The incremental approach enables for highlighting the performance trends, fairness, and reliable evaluation of the proposed framework under various workloads. The key simulation parameters are listed in Table 7.

5.2. Smart Campus Applications

The smart campus domain relies on several applications that support the efficient operation of smart-campus environments. These applications can be classified as student service applications, safety and security applications, staff service applications, environmental applications, educational applications, and research and development applications. Each class covers a wide range of applications. As the scope of this research is the smart campus domain, it is essential to use some of its applications to evaluate the proposed approach. Below, four different applications are presented, which are SE, SC, AR for maintenance, and SP.

5.2.1. Smart Emergency (SE)

It is an important smart campus application, which is known as the SE call point [28,29]. Its primary aim is to ensure the security and safety of students, staff, and visitors around the campus 24/7 by enabling people to request emergency services using an alert system in any emergency case, including health emergencies and criminal activities [28]. In this paper, we assumed that people could utilize this application by pressing the emergency button located at the emergency call point in order to establish a live session with a security agent by using the speakers and supported by a CCTV camera that is pointed at the alert point. They can also use their university application to access this service. Based on this scenario, it can be assumed that SE is a latency-sensitive application due to the real-time communication requirements and situation criticality. Further, it can generate different video files with different sizes that can be approximately ~8000 Kilobyte (KB)/minute as the uploading data size, following the estimation presented in [30,31]. Such application requires 4000 million instruction per second (MIPS) and 0.8, which simulate application sensitivity in the simulation environment in terms of average task length and delay sensitivity, respectively. The complete simulation settings are listed in Table 7.

5.2.2. Smart Classroom (SC)

SC is a fundamental application for the smart campus, which is developed to support and facilitate the learning and teaching processes [12,32]. Such an application includes several services, such as student attendance, exam correction, and students’ behavior and learning path analysis. In this research, it is assumed that the SC application will be used in recording the students’ attendance by recognizing their faces using either an onsite attendance system or students’ smartphones. In accordance with this assumption, it is considered as a medium-latency application, which can be represented as 0.4. Furthermore, the average generated data size can be approximately 1200 KB, as it can be performed using students’ pictures [33]. More application settings can be found in Table 7.

5.2.3. Augmented Reality (AR)

The AR application is scenario-dependent, such as information and guidance and smart maintenance. On one hand, it can be most useful for new students, visitors, and tourists by adding information on the users’ smartphones or smart glasses. For instance, students can be able to see more information about the university staff, such as their email address, bio, and office location, once a staff picture is recognized by their cameras as presented in [12]. This application can also guide new students to take a tour around the university to explore the campus and the key services provided [30]. On the other hand, it can be used to facilitate the maintenance process by enabling the administrators and workers to add information into the AR space. For instance, an administrator can set a request for adding, e.g., network nodes around the campus by adding notes within the AR space. Workers can be able to see the administrator requests pointed out on the AR space. Alongside this functionality, workers can add notes on, e.g., installed network nodes, that can be related to the node performance or inspection requirements. This scenario can be performed using both administrator and worker smartphones, which can generate about ~5120 KB for a 10 s recorded video [34]. This application is considered a latency-tolerant application and represented as 0.2 in terms of latency sensitivity in the simulation setting.

5.2.4. Smart Parking (SP)

This application is important for both university staff and students, which enables them to explore available parking bays, especially during rush hour [35]. They can search for a parking space in real time or request a parking reservation upon arrival by using their smartphone.

5.3. Simulation Environment and Setup

Edge architecture primarily emerged to support the requirements of end devices, such as mobility and low latency, by bringing cloud resources closer to the end devices. It resides between the end devices and the cloud layer. It is capable of orchestrating tasks across edge-cloud layers based on several factors, such as task priority and resource availability. The consideration of the edge-cloud environment is extremely challenging to be implemented in a real-world smart-campus environment. Thus, a Java-based simulator known as EdgeCloudSim is adopted in this paper to simulate the smart campus edge-cloud environment [36]. It is a well-known and widely adopted simulator that models a three-layer architecture, which includes the end-devices layer, the edge layer, and the cloud layer. It is also capable of orchestrating tasks across all considered layers using two approaches, which are the single-layer approach, whereby it enables requests to be processed on the nearest edge node, and the two-tier approach with an Edge Orchestrator (EO), which has the ability to offload the request to any other edge node.

In this research, EdgeCloudSim version 3, which is well-evaluated and widely adopted in the literature, was installed on an HP Envy x360 laptop that has a Windows 11 operating system. The device has a 13th-generation intel i7 processor, 1 TB of storage, and 16 GB RAM. The simulator enables users to easily define scenarios and configure their parameters for their experiments. The key simulation parameters are presented in Table 7.

5.4. Benchmark

Benchmark evaluation is a vital process that must be considered to provide a comprehensive evaluation of the proposed solution. The existing literature, however, is limited to comparable approaches that address neither smart-campus environments nor the targeted objectives of this work, including latency-sensitive application prioritization, execution rate maximization, and resource utilization efficiently, while considering mobility awareness in the orchestration process. Thus, the proposed MFBM is evaluated experimentally against two fuzzy-based benchmarks, which are presented in [19,37] and described below:

• The first benchmark is proposed by [19], which is a two-tier fuzzy-based orchestration solution that is developed with the primary aim of optimizing the task orchestration process without specifying a particular optimization objective and domain. Several input parameters are considered, e.g., MAN delay, local edge utilization, and WAN bandwidth. Although there are some differences compared to our study, the consideration of this study is important, as it is the most closely related study available in the literature. The consideration of this approach is critical, as it is the closest benchmark to the proposed MFBM and can be seen as a well-known and widely used benchmark in the literature for fuzzy-based models. Additionally, full implementation can be conducted, as its author used the same simulator.
• The second benchmark is presented in [37], and is included as a baseline solution in [19]. It develops a mobile code-offloading fuzzy-logic solution to make offloading decisions based on four variables, which are bandwidth, transferred data, CPU instance, and video execution, for mobile-cloud environments. The targeted offloading resources are local devices, i.e., mobile devices or the cloud layer, where the EC layer is not considered. Although this study can be seen as an out-of-date approach, it is important to take it into consideration, as it is included and evaluated against a well-known model proposed by [19], as well as being able to provide a thorough analysis and highlight the strengths and limitations due to the consideration of mobility. Hence, the same assumptions that are made in [19] are considered in our study.

Both benchmarks are accessible and closely related to the proposed model. These benchmarks are selected to provide a representative and fair comparison against the proposed framework, as all fuzzy-based approaches operate under comparable system models and real-time decision-making constraints. To ensure the fairness of the comparison, all models are evaluated under the same scenarios and simulation configurations as explained in Section 5.1 and listed in Table 7.

5.5. Evaluation Metrics

In this paper, five metrics are used, which are the number of executed tasks, the average processing time, the average service time, the average resource utilization, and the percentage of failed tasks, as described below.

5.5.1. Number of Executed Tasks

It represents the total number of tasks executed on each layer. It is important to show the effectiveness of the MFBM as compared to the benchmarks in terms of execution rate maximization and efficient node utilization.

5.5.2. Average Processing Time

It is a common performance metric which is used to illustrate the average time taken by tasks when executed on the selected resources. It is calculated using Equation (19) as follows.

$$\mathit{AvgPT}={\displaystyle \frac{{\sum }_{j=1}^N{P}_j}{Total number of tasks}}$$

(19)

5.5.3. Average Service Time

It is used to calculate the average time required, including the network, processing, and queuing delays. It is calculated using Equation (20), which is the sum of both processing time, denoted as $P$, and the network delay, denoted as $N$, for each task $j$, divided by the number of tasks.

$$\mathit{AvgST}={\displaystyle \frac{{\sum }_{j=1}^N(P_j+N_j)}{Total number of tasks}}$$

(20)

5.5.4. Average Resource Utilization

It represents the average CPU utilization of the VMs located on the edge nodes, which are important for demonstrating the effectiveness of the MFBM in terms of utilizing the edge nodes’ resources. It is computed using Equation (21), where $U$ represents the CPU utilization for each VM and $C$ represents the capacity of each VM.

$$\mathit{AvgU}={\displaystyle \frac{Total CPU used}{Total CPU capasity }}\times \mathsf{100}=\left({\displaystyle \frac{\sum _{j=1}^N{U}_j}{\sum _{j=1}^N{C}_j}}\right)\times 100$$

(21)

5.5.5. Percentage of Failed Tasks

It is a well-known performance metric that shows the percentage of failed tasks to the total number of tasks. This metric can be further broken down to determine the reasons behind task failure, which can be, e.g., device mobility, where the user moved from one area to another and the connection was lost, and network issues. It is calculated using Equation (22).

$$\mathrm{PerF}={\displaystyle \frac{Total number of failed tasks}{Total number of tasks}}$$

(22)

6. Results and Discussion

This section presents the experimental results of the selected performance measures. Moreover, it illustrates the performance of the proposed MFBM as compared to the selected benchmarks and scenarios.

6.1. Number of Executed Tasks

Across all models, there is an increasing trend as the number of devices increases. This is, however, limited in the Sonmez scenario for the FC model, where the growth slows down once the number of devices reaches 1400. The proposed MFBM and FC models provide the highest number of processed tasks on the edge compared to the FB in most cases across all scenarios, due to their ability to accommodate the received task on the edge layer, as can be seen in Figure 4a–c. MFBM outperforms FB where the difference ranges between approximately ~2300 tasks, when the number of devices is 200, and up to about ~8000 tasks, when the number of devices is 1600. When MFBM is compared with FC in terms of the day scenario, both have almost the same performance in most cases, although FC provides a better execution rate that ranges between eight tasks, when the number of devices is 1000, and up to 5100 tasks, when the number of devices is 1800. This behavior can also be seen in both the night and the Sonmez scenarios, as shown in Figure 4b,c. Figure 4c shows that MFBM provides the best performance, which is particularly evident in high workload cases, i.e., 1200–2000 devices. When the number of devices reaches 2000, MFBM provides almost a 30% improvement as compared to FB.

The analysis of individual applications is also critical to illustrate the effectiveness of the proposed model in prioritizing latency-sensitive applications and the efficient utilization of edge resources. All models in both day and night scenarios execute almost the same number of tasks on the edge layer for AR, SC, and SE applications in most cases. Both MFBM and FC provide a great execution rate in the case of the SP application as compared to FB, which offloads all SP applications to the cloud layer, as shown in Figure 5a,b. In the Sonmez scenario, both MFBM and FC significantly improve the number of tasks executed on the edge as compared to FB in the case of HCA and IA applications, as depicted in Figure 5c,d. These models also begin offloading some workload to the cloud when the number of devices is 1200, as the execution rate on the edge slows once the workload exceeds the capacity of edge resources, while the cloud workload starts growing.

The MFBM achieves the optimization objective, which is the number of executed tasks on the EC layer, by prioritizing the latency-sensitive applications to be executed on the edge, which are SE in both day and night scenarios and AR in the Sonmez scenario. This can be seen clearly in Figure 6a–c, where MFBM provides either the highest performance or the nearest to the best performance. Notably, it not only outperforms other selected models in latency-sensitive applications, but it can execute some latency-tolerant applications on the edge to achieve better utilization and execution rates. This can be seen in Figure 5a,c for both SP and IA applications, which are classified as latency-tolerant applications.

6.2. Average Processing Time

Both the MFBM and FB models exhibit a decreasing trend as the number of devices increases until they reach 1000 devices. The processing time is then stable for the remaining number of devices, where MFBM decreases faster than FB, as shown in Figure 7a. For small workloads, MFBM experiences high processing time as it tries to accommodate all latency-sensitive applications on the edge alongside latency-tolerant applications in order to achieve its objectives, which are execution rate maximization, resource utilization efficiency, and latency-sensitive application prioritization. For instance, in the case of 200 devices, MFBM has the highest processing time, which is almost double the value of the FB. This difference decreases as the number of devices increases due to the ability of the model to deal with high workloads and prioritize latency-sensitive applications to be processed on the edge. For FC, a slow increasing trend is observed as the workload increases.

In day and night scenarios, a similar trend is also seen in SC and AR applications, which are classified as medium-latency, i.e., 0.4 and 0.6 latency sensitivity. In the Sonmez scenario, FB has the shortest processing time compared to other models, where the MFBM starts out having the longest processing time once the number of devices reaches 1200, as can be seen in Figure 7b. The maximum difference between the MFBM and FB models is ~0.8 s at 1400 devices.

When considering latency-sensitive applications, which are SE for day and night scenarios and AR for the Sonmez scenario, in the day scenario, all models show a fluctuating pattern across different numbers of devices, which range between 0.8 and 1.5 s as the workload increases. In the night scenario, which is depicted in Figure 8a, MFBM and FB provide almost the same processing time as the workload increases, while FC exhibits the worst processing time. The Sonmez scenario, presented in Figure 8b, shows that all models provide almost the same result until they reach 800 devices, where MFBM begins to increase the results faster than the other models as workload increases. This higher processing time can be justified by the nature of the MFBM that prioritizes the execution of latency-sensitive applications, i.e., AR in this scenario, on the edge. This process causes higher resource utilization compared to other models, which have more offloading process freedom, and hence a higher processing time.

6.3. Average Service Time

The average service time for both day and night scenarios follows the same trending pattern, where the night scenario provides longer service time due to the utilization of heavy-load and latency-sensitive applications. Furthermore, this pattern is also strongly affected by the processing time, which is included as part of the service time calculation alongside network delay. Figure 9a–c show the average service time across all applications.

It is clear that MFBM has the highest service time in most cases, especially when the workload is light, as compared to other models in Figure 9a,b. The difference, however, can be neglected in most cases, especially for high workloads. In these figures, MFBM provides better performance when the workload is high compared to low workload, as it aims to accommodate more requests on the edge layer, which leads to higher service time. In the Sonmez scenario, shown in Figure 9c, all algorithms experience an increasing service time pattern as the workload increases, where MFBM increases the results faster when the workload reaches 1000 devices. Likewise, FB increases faster than others when the workload reaches 1600 devices. It, however, still provides the shortest service time over all numbers of devices.

When the latency-sensitive application results are analyzed, MFBM provides better service time compared to other models in both day and night scenarios, as shown in Figure 10a,b, while in the Sonmez scenario, it provides the best service time until the number of devices reaches 600. In fact, the higher service time observed for MFBM is due to the higher execution rate on the edge layer, as presented in Section 6.1, which results from network congestion and server utilization. Further, its service time in its worst case is still acceptable and close to the best service time in most cases.

6.4. Average Resource Utilization

As can be seen in Figure 11a–c, the average VM utilization of edge nodes increases as the number of mobile devices increases for all scenarios, where MFBM achieves the highest VM utilization. In both day and night scenarios, it achieves almost double the utilization of FC model, where FC increases faster than the other models in the day scenario. This higher utilization of the MFBM is caused by two main reasons, which are the higher task execution rate achieved by the model and the prioritization of latency-sensitive applications, i.e., SE 0.8 and SC 0.4, which have higher edge node utilization as compared to other applications. The resource utilization improvement, however, can have a negative impact on the overall percentage of failed tasks. MFBM prioritizes latency-sensitive applications to be executed on the edge and seeks for a high execution rate, which may cause higher network congestion and higher queuing time, hence resulting in a higher overall task failure rate due to the network and mobility issues. These aspects will be explained in the following section.

6.5. Percentage of Failed Tasks

The results show that the percentage of failed tasks increases as the workload increases for all models. Figure 12a,b show the overall percentage of failed tasks on both edge and cloud layers over day and night scenarios. They reveal that MFBM has the highest percentage of failed tasks compared to the other models, while FB has the lowest percentage of failed tasks across varying workloads. In the Sonmez scenario, shown in Figure 12c, the performance of MFBM improved as compared to the FC model, while FB still provides the best performance.

When the performance of each model is analyzed with respect to latency-sensitive applications, which are prioritized by the MFBM, as depicted in Figure 13a–c, it can be seen that MFBM provides a lower percentage of failed tasks compared to FC and provides almost the same performance as FB, where the difference can be neglected in most workload conditions. This demonstrates the ability of MFBM to prioritize latency-sensitive applications, which are SE in both day and night scenarios and AR in the Sonmez scenario.

The same results are found when analyzing the percentage of failed tasks on the edge layer only, as depicted in Figure 14a–c, except in the day scenario. In the day scenario, MFBM provides the worst performance once the number of mobile devices reaches 800. Its performance, however, can be neglected when compared with the FC model in most cases. This is due to the prioritization of the SE application, which is latency-sensitive, and the heavy load application to be executed on the edge nodes, which can be the local node or the remote node. This approach causes two main issues, which are the high failure rate due to network congestion at the edge and high failure rate due to user mobility, which may be the result of long queuing time. Indeed, such results are reasonable, as MFBM considers multiple objectives.

The best performance is achieved by the FB model, which shows almost less than 1% failure until the number of mobile devices reaches 1400, where the percentage of failed tasks increases faster than others. Despite this fast increase, it still provides a lower percentage of failed tasks.

When the reasons behind task failure are analyzed, the results show that most of the tasks are failed due to network congestion for all models, while mobility comes as the second reason. Figure 15a–c present the number of failed tasks due to the MAN, which has the highest impact on task failure compared to WAN, for the day, night, and Sonmez scenarios, respectively. It can be seen that MFBM is significantly affected by the MAN, contributing to the high percentage of failed tasks compared to other selected models. This is due to its approach that is strict in accommodating latency-sensitive applications on the edge layer. This does not contradict its great performance in achieving a higher task execution rate and latency-sensitive application prioritization on the edge layer.

7. Conclusions and Future Work

This research introduces a context-aware fuzzy-based system architecture for a smart-campus environment in collaborative edge-cloud architecture. Through extensive evaluation in smart-campus scenarios, the proposed system architecture effectively prioritizes latency-sensitive applications to be executed closer to end devices. Furthermore, it improves the execution rate by accommodating about 30% more tasks compared to the selected benchmarks. This can reach about 70% improvement compared to other selected benchmarks for latency-sensitive applications, showing its strength in execution rate enhancement and latency-sensitive application prioritization. This improvement in the execution rate enhances the utilization of edge nodes twice compared to the selected baseline approaches. Indeed, the proposed MFBM can be applied across other sectors with similar objectives, as demonstrated through the experiments using the Sonmez benchmark.

Although the targeted objectives are achieved, there are several possible directions that can be followed to ensure the robustness of the proposed framework and explore possible performance improvements. For instance, the sensitivity of the designed fuzzy rules can be further analyzed and investigated to evaluate framework robustness. This can include the evaluation of the proposed framework on larger-scale campuses with different scenario conditions, such as network conditions and mobility behavior. Additionally, a direct experiment can be conducted to measure the overhead on the CPU and memory when running the proposed MFBM on real edge hardware, which is important to evaluate its effectiveness. Moreover, advanced and sophisticated benchmarks, e.g., machine learning and deep learning approaches, can be considered to have a wider overview on the performance of the proposed MFBM framework. Another important direction is the elimination of the reasons behind task failure, e.g., MAN and mobility, by considering some optimization approaches. Mobility, which is modeled at a high-level, is another main direction that can be further investigated as a standalone challenge. Several mobility aspects can be explored by modeling different mobility patterns, handoff costs, service migrations, and intermittent connectivity. Lastly, scalability and heterogeneity are key aspects in EC environments, where the performance of the proposed MFBM can be systematically and thoroughly evaluated under large-scale and heterogeneous edge environments.