Fuzzy Based Collaborative Task Offloading Scheme in the Densely Deployed Small-Cell Networks with Multi-Access Edge Computing

Abstract

Accelerating the development of the 5G network and Internet of Things (IoT) application, multi-access edge computing (MEC) in a small-cell network (SCN) is designed to provide computation-intensive and latency-sensitive applications through task offloading. However, without collaboration, the resources of a single MEC server are wasted or sometimes overloaded for different service requests and applications; therefore, it increases the user’s task failure rate and task duration. Meanwhile, the distinct MEC server has faced some challenges to determine where the offloaded task will be processed because the system can hardly predict the demand of end-users in advance. As a result, the quality-of-service (QoS) will be deteriorated because of service interruptions, long execution, and waiting time. To improve the QoS, we propose a novel Fuzzy logic-based collaborative task offloading (FCTO) scheme in MEC-enabled densely deployed small-cell networks. In FCTO, the delay sensitivity of the QoS is considered as the Fuzzy input parameter to make a decision where to offload the task is beneficial. The key is to share computation resources with each other and among MEC servers by using fuzzy-logic approach to select a target MEC server for task offloading. As a result, it can accommodate more computation workload in the MEC system and reduce reliance on the remote cloud. The simulation result of the proposed scheme show that our proposed system provides the best performances in all scenarios with different criteria compared with other baseline algorithms in terms of the average task failure rate, task completion time, and server utilization.

1. Introduction

Nowadays, user equipment terminals, such as smart mobile phones, smart sensors, smart bands, virtual reality (VR) glass, wearable devices, smart watches, and smart cameras are growing in popularity [1,2,3,4]. The high-demanding applications and services, such as mobile augmented reality, gesture and face recognition, intelligent transportation, smart healthcare, interactive gaming, human heart-rate monitoring, voice recognition, natural language processing, and wearable virtual reality streaming are undergoing tremendous developments [5,6,7,8,9]. With the enormous enhancement of smart user devices and the emergence of recent innovative applications and high-demanding services, data traffic is rising exponentially [10,11]. Therefore, storing, processing big data, and supporting real-time as well as computation-intensive tasks and applications is a big challenge. Additionally, owing to the confined processing capability and battery-life time, the execution of latency-sensitive and computation-intensive applications in user devices will undoubtedly affect the QoS and performance. To overcome these limitations, the applications are offloaded to the conventional remote cloud for execution. Although conventional remote cloud has unlimited storage and computing capacity, it has some difficulties in executing latency-sensitive and real-time applications because of the distance between the end users and the central cloud as well as unpredictable network latency [11]. To deal with these challenges, diverse approaches such as mobile cloud computing (MCC) [12], cloudlet [13], fog Computing [14], and multi-access edge computing (MEC) [15], can be used as complementary solutions to cloud computing by employing services adjacent to the edge network. The comparison among the MCC, fog computing, and the MEC based on the technical aspect is shown in

Table 1. Comparison of different mobile computing architectures [11,16,17].

Technical Aspect	MCC	Fog Computing	MEC
Proposed by	Not specific	Cisco	ISG, ETSI
Deployment	Centralized	Distributed	Dense and distributed
Computing capabilities	Higher	Lower	Lower
Latency	High	Low	Low
Storage capacity	Ample	Limited	Limited
Location	Large data center	Between user devices and data center	Radio access network
Hierarchy	2 tiers	3 or more tiers	3 tiers
Context awareness	No	Yes	Yes

.

MEC has emerged as a promising approach to cope with growing computing demands in 5G networks, where the traditional base stations are upgraded to MEC-enabled small base stations (SBS-MEC) [18]. The SBS-MEC provides higher bandwidth, low latency, location awareness, dramatic reduction of energy consumption, and real-time radio network information [17]. One of the major limitations of the SBS-MEC server is that it does not allow continuous offloading service for all tasks which are offloaded from the end user because of its confined computation resources. However, if the number of mobile user’s increases, the QoS will be depreciated for service interruptions, larger execution, and waiting time. Therefore, it is necessary to deal with the resources of SBS-MEC effectively for better system performance. Moreover, without providing proper information on the task-arrival time and sizes, MEC faces some challenges in a dynamic and rapidly changing environment to determine where the offloaded task will be processed. Due to the incomplete information, it is difficult to predict the demand of end users in advance. As a result, the quality of experience (QoE) will conspicuously degrade and negate the advantages of MEC. With this need in mind, several authors are trying to solve this problem using optimization techniques, but when the number of constraints is larger, multi-constraint optimization becomes a difficult task. In the MEC system, multiple constraints are engaged and these come from its infrastructure, end user device, and different application characteristics. Meanwhile, due to lack of proper advance information about task offloading requests, traditional offline optimization is not suitable for the collaborative task offloading problem.

To solve the above-mentioned issues, we have introduced a novel collaborative task offloading scheme among multiple SBS–MEC servers to boost the computation offloading service. By using the proposed system, we can easily reduce the load of local SBS-MEC servers and the execution time as the tasks are distributed among neighboring SBS-MEC servers. Meanwhile, with the accelerated growth of 5G technologies and the current development of emerging applications, it can be thought that the densely deployed small-cell networks (DDSCNs) will be the mode of future 5G communication networks which will have the capacity to deal with the requirements of excessive data traffic [19]. Generally, in sparse edge deployment, a user can only connect to the local SBS-MEC server, and it is not always the best decision to connect this server; however, in densely deployment environment [20,21], there will be multiple SBS-MEC servers in the nearest places such as user residences, airports, and workplaces. The user may, therefore, have multiple options to connect to neighboring SBS-MEC servers for the services. In DDSCNs, the access nodes are deployed close to the end users and the access nodes are densified per unit area with immense probability of line-of-sight transmission [22].

In a novel collaborative task offloading scheme, fuzzy logic is used because it has already been significantly applied for congestion mitigation, handoff control, network, and workload-management related problems [23,24,25,26,27,28]. In this study, a fuzzy-logic based technique is proposed to deal with the collaborative task offloading problem in MEC-enabled SCNs. When the exact mathematical model is difficult to develop in a rapidly changing system that is dynamic and uncertain, fuzzy logic is the most employed method because its computation complexity is lower with respect to different decision-making algorithms [29,30,31]. In [32], we consider the collaboration approach between mobile device with the SBS-MEC server and the collaboration between SBS-MEC servers with the cloud; however, in our proposed work, the collaboration approach adopts the fuzzy rules to determine the task offloading location among the SBS-MEC servers.

In particular, the main contributions of this study are summarized as follows:

• We investigate an innovative collaborative task offloading framework for MEC-enabled DDSCNs that can easily compute various service requests based on the user’s demand.
• We develop a fuzzy-based algorithm, called fuzzy-based collaborative task offloading (FCTO), that analyzes the under-utilized and over-utilized SBS-MEC servers. Based on the fuzzy rules which select a target SBS-MEC server that can efficiently process dynamic flow of service requests, each task can be assigned among SBS-MEC servers.
• By employing our proposed fuzzy-based model, one can handle uncertainty in rapidly changing environments. Our proposed model also helps in solving the dynamic resource management problem as well as the overload problem of a single SBS-MEC server.
• To analyze the performance of our proposed collaborative task offloading scheme, we conducted some experiments. The experimental results validate that our proposed model achieves outstanding performance in terms of reducing the average task duration and task failure and also provides more server utilization when compared to other two reference schemes.

The rest of this study is organized as follows. In Section 2, we review some relevant research works. The motivational scenario, different collaborative execution models, and our proposed collaborative architecture are narrated in Section 3. Section 4 introduces fuzzy logic and the proposed FCTO algorithm. Section 5 explains the performance evaluation with necessary discussions of the proposed schemes. Finally, we conclude this study in Section 6.

2. Related Work

MEC is a leading technology in satisfying the end user’s demands for service requirements [33,34]. In MEC, the main research points are the task offloading strategy and resource allocation. In recent years, some researchers have focused on these points and considered different scenarios such as a single user or multiple users, single or multiple MEC servers in a single base station, partial or full offloading for task computation, and computation offloading for dynamic as well as static environments. Bi and Zhang [35] have optimized the computing mode for a multi-user scenario of a single cell BS. On the other hand, Deng et al. [36] have used adaptive sequential offloading game approach to avert the unpredictable queuing delay for multi-user and multi-cell MEC scenario. To enhance efficiency, some researchers have concentrated on reducing the processing time and consumption of energy by using full offloading approach [37,38]. Labidi et al. [37] have proposed a jointly optimized offloading and scheduling strategy for enhancing the QoE and efficiently reducing the energy consumption. Moreover, in wireless mesh networks [38], by using collaborative edge computing, the saturated backhaul bandwidth will be reduced. However, after analyzing the full offloading and partial offloading technique, Wang et al. [39] concluded that partial offloading is much better and it is more practical as it uses a parallelism approach. Meanwhile, Mao et al. [40] proposed Lyapunov optimization which is an online based algorithm and it is used for reducing energy consumption. Moreover, in case of resource utilization, dynamic resource allocation approach [41,42] is more efficient than static approach [43]. In [43], the game-theoretic approach has been proposed to increase computation offloading performance in a distributed manner, but the insufficiency of computation resources was not considered. Chen and Hao [41] proposed an iteration-based algorithm based on software-defined network (SDN) concept for resolving the issues of task offloading and dynamic resource allocation problem. Meanwhile, Xiao and Krunz [42] reduced the energy consumption as well as processing delay by using the cooperation of edge cloud approach.

Nevertheless, most of the previous works focus on a single MEC server and Tran and Pompili [44] considered the multi-server MEC scheme, but they did not consider the dense deployment of SBS-network environment. MEC and dense deployment of SBSs are the key technologies for 5G mobile communication networks and they provide enormous access capacities for the user because the nearby SBS-MEC servers can create a computation resource pool collaboratively [10,45]. Research has been conducted to integrate the MEC with SCN, which has attracted the researcher’s attention. For balancing the computation workload, Refs. [46,47] utilized the cooperation between servers to balance the load. Zhang et al. [48] used device-to-device (D2D) collaboration for load balancing in densely deployed small-cell network environments. Sun et al. [49] have proposed a novel mobility management approach for MEC in ultra-dense network; however, for reducing latency and energy consumption, Guo et al. [50] introduced a two-tier game-theoretic greedy approach in ultra-dense IoT Networks.

MEC-enabled DDSCNs are facing some challenges. In a densely deployed environment, there are many SBS-MEC servers that have limited computing resources. Meanwhile, existing research mostly focuses on end-user-to-local SBS-MEC offloading while the computing capability of local SBS-MEC server is ignored. Therefore, efficiently handling the resources of the distributed SBS-MEC server is a challenging issue. Furthermore, the end user does not have the information about the network traffic, capacity of the SBS-MEC server, etc., when they offload their task to the network. To overcome the above-mentioned challenges, we developed an FCTO scheme for MEC-enabled DDSCN environment. For many years, fuzzy logic has been the best solution that has been widely used in rapidly changing unpredictable environments. Hosseini et al. [51] have used fuzzy logic for offloading mobile data because of its simplicity, which produces more efficient results compared to its competitors. For measuring the sender’s vehicle trust level, Soleymani et al. [52] used fuzzy -logic in vehicular ad hoc networks environment which was based on experience and plausibility. To ensure the authenticity of the received information from the authorized vehicles, this model performed a series of security checks. Furthermore, in case of a security service selection, a soft hesitant fuzzy rough set (SHFRS) approach was used to choose the appropriate decision from multi-criteria decision-making problem [53]. Moreover, Sonmez et al. [54] proposed a workload orchestration based decision engine for task offloading by using fuzzy logic to determine the offloading location for executing the tasks which will be either edge or remote cloud, whereas we used fuzzy logic for collaborative task offloading scheme, which will decide where to offload the incoming task among SBS-MEC servers. Our proposed fuzzy-logic based system is employed to determine the location of the offloaded task which will either be the local or neighboring SBS-MEC servers. The novelty of our work is to utilize the neighboring SBS-MEC server which has spare computing resources to reduce the number of task failures and application response time. To the best of our knowledge, an FCTO scheme for DDSCNs has not yet been studied for this domain.

3. Motivational Scenario and System Model

3.1. Problem Statement

The system under consideration consists of a three-tier hierarchy: end users, small-cell base stations, and a remote cloud. SBSs are typically deployed in very densely populated urban areas where many people use mobile devices, i.e., shopping centers, sports venues, airports, and train stations. Moreover, mobile devices are operated with various applications and data packet information such as pictures, email, web browsing, video, gaming, and live streaming. When the mobile device user’s density is high, a single SBS-MEC server will face many challenges in handling a large number of service requests because of its confined computing resources. As a result, a single SBS-MEC server is overloaded which degrades the QoE.

To explore the neighboring small-cell base stations, we observed the following:

• It is possible to utilize a nearby SBS-MEC server which has spare computing resources or is lightly loaded to overcome the overloaded problem of a single SBS-MEC server.
• There is a function that is a trade-off of the resource capacities of all the SBS-MEC servers. We should then decide whether it should be offloaded to the remote cloud.
• By sharing the resource capacity among the SBS-MEC server, the total processing time can be reduced.

Figure 1 shows the limited capacity and the overload problem that exists in the SCNs. User $\#1$ has two tasks: one task, $T_1^1$, can be processed locally; the remaining task, $T_2^1$, needs to be offloaded for processing in another place. Generally, user $\#1$ will offload this task for performing its computation to the SBS-MEC server $\#1$, SBS-MEC-1. However, in that time, SBS-MEC-1 cannot handle this server as it is already overloaded. Consequently, task $T_2^1$ will fail. Meanwhile, user $\#2$ has three tasks which need to offload because of the confined capacity and weak performance, namely, $T_1^2$, $T_2^2$, and $T_3^2$. Basically, all the tasks will be offloaded to SBS-MEC server $\#4$. Nevertheless, SBS-MEC server $\#4$ can handle two tasks, i.e., $T_1^2$ and $T_2^2$. Therefore, task $T_3^2$ will fail.

3.2. Collaborative Execution Model

To solve the limited capacity and the overload problems, a mobile device user can offload their tasks to the target server for processing. We assume that mobile device users always offload their computation tasks to their corresponding local SBS-MEC server, but if a set of SBS-MEC servers works collaboratively, user devices can experience better edge services. Otherwise, the computation task will be further offloaded to the remote cloud. According to the connections between mobile device user, SBS-MEC server, and remote cloud, there are three types of collaboration models: mobile device user to SBS-MEC server, SBS-MEC server to remote cloud, and SBS-MEC server to SBS-MEC server. The notations used throughout this paper are summarized in

Table 2. Notations and their meanings.

Symbol	Meaning
M	Number of mobile device users
N	Number of SBS-MEC servers
T	Number of tasks
${\psi }^{sbs}$	SBS-MEC server’s computational capacity
${\omega }_i$	Amount of received mobile workload from mobile user i
${\upsilon }_i^t$	Computation task is generated from each mobile device user i
${\Im }_i\left(t\right)$	Local-executed computation task
d	Size of the input data for computation
$\lambda$	Number of CPU cycles needed to process the task
${\zeta }_i^{max}$	Highest allowable latency for accomplishing the task
${\psi }_i^{max}$	Maximum task arrival rate that can be handled by the SBS-MEC server i
${\mathrm{Y}}^t$	Total computation tasks arriving in SBS-MEC server at time slot t
$\alpha$	Task size
$\beta$	Delay sensitivity of task
$\gamma$	Local SBS-MEC VM utilization
$\delta$	Network delay
$\theta$	Neighboring SBS-MEC VM utilization
${\chi }^{*}$	X-coordinate of the center of gravity

.

Let ${\psi }_1^{sbs},{\psi }_2^{sbs},\dots ,{\psi }_n^{sbs}$ represent the SBS-MEC server’s computational capacity of small-cell base station $1,2,\dots ,n$, respectively. Let ${\omega }_1,{\omega }_2,\dots ,{\omega }_m$ be the amount of received mobile workload from various mobile device users $1,2,\dots ,m$, respectively. Note that the collaboration model occurs if and only if a mobile device user cannot execute the task(s) locally. For user $\#1$, we consider the workload ${\omega }_1$ which cannot be processed locally by itself. By comparing ${\psi }_1^{sbs}$ and ${\omega }_1$, there are three possible ways to process as follows:

• Case 1: ${\omega }_1$ is less than ${\psi }_1^{sbs}$. This computation task will be executed in SBS-MEC 1, as shown in Figure 2a, where some of the tasks will be computed locally by themselves and the remaining tasks will be offloaded to the SBS-MEC 1 server for execution.
• Case 2: Figure 2b shows ${\omega }_1$ is greater than ${\psi }_1^{sbs}$ and there are no collaborations between neighboring SBS-MEC servers or the total processing time is minimized if there are collaborations between neighboring SBS-MEC servers. In this case, this offloaded task ${\omega }_1$ will be divided according to ${\psi }_1^{sbs}$ into two parts: one is processed in the SBS-MEC server 1; the remaining task, ${\tau }_1={\omega }_1-{\psi }_1^{sbs}$, will be sent to the remote cloud for processing.
• Case 3: ${\omega }_1$ is greater than ${\psi }_1^{sbs}$ and there are collaborations between neighboring SBS-MEC servers. The minimized total processing time will elapse if this task is processed in neighboring SBS-MEC servers, as shown in Figure 3. Similar to case 2, this offloaded task ${\omega }_1$ will be divided according to ${\psi }_1^{sbs}$ into two parts: one is processed in SBS-MEC server 1; the remaining task, ${\tau }_1={\omega }_1-{\psi }_1^{sbs}$ needs to be helped. ${\tau }_1$ will be offloaded to the target neighboring SBS-MEC server to minimize the total processing time.

3.3. System Model

The key is to collect information from all SBS-MEC servers, and, according to the fuzzy rules, it decides the task handling location. Therefore, we design the architecture of the fuzzy based collaborative task offloading scheme for MEC-enabled SCN. Figure 4 shows our designed architecture: mobile device users, SBS with MEC server and remote cloud. The first layer consists of different end users who want to compute their tasks either locally or offload to the local SBS. The second layer is made up of a number of SBSs in which a single MEC server is deployed to each BS. Virtualization technology, such as virtual machine (VM), is used by the MEC server to create execution environments. The distributed SBS-MEC server is connected to the fuzzy-based edge orchestrator. The fuzzy edge orchestrator module acts as a coordination point of the system to collect information from all SBS-MEC servers and, according to the fuzzy rules, it decides the task handling location. Finally, the core network is attached to the remote cloud for providing centralized cloud computing services.

According to above consideration, we define $N=\{1,2,3,\dots ,N\}$, which represents the number of SBS-MEC servers deployed to the small-cell network. Let $M=\{1,2,3,\dots ,M\}$ be the number of mobile device users, who are covered by N SBS. We assume that the computation task, ${\upsilon }_i^t$, is generated from each mobile device user $i,i\in M$ at each time slot t following the Poisson processing. The total arrival computation tasks in one SBS in time slot t, ${\upsilon }^t$, is given as:

$${\upsilon }^t={\left\{{\upsilon }_m^t\right\}}_{m\in M}$$

(1)

Moreover, each mobile device user can execute a task at time t. The local-executed computation task is defined as:

$${\Im }_i\left(t\right)=\{d_i,{\lambda }_i,{\zeta }_i^{max}\}$$

(2)

where $d_i$ denotes the size of the input data for computation, ${\lambda }_i$ represents the number of CPU cycles that need to process the task ${\Im }_i\left(t\right)$, and ${\zeta }_i^{max}$ describes the highest allowable latency for accomplishing the computation task.

Considering each SBS, let $M_i$ be the number of mobile device users in the SBS-MEC server i. The total arrival computation task, ${\mathrm{Y}}_i^t$, will be offloaded to the SBS-MEC server, i, and it can be computed as follows:

$${\mathrm{Y}}_i^t={\displaystyle \sum _{m\in M_i}({\upsilon }_m^t-{\Im }_m\left(t\right))}$$

(3)

The number of computation tasks cannot be executed in SBS-MEC server i and is given as shown below:

$${\delta }_i={\psi }_i^{max}-{\mathrm{Y}}_i^t$$

(4)

where ${\psi }_i^{max}$ is the maximum task arrival rate that can be handled by the SBS-MEC server, i. If ${\delta }_i<0$, the SCN needs collaboration to execute all remaining computation tasks for minimization of the total processing time. Otherwise, the system can run according to the baseline scheme.

The total computation tasks arriving at all SBS-MEC servers in the SCN at time slot t, ${\mathrm{Y}}^t$ is computed as:

$${\mathrm{Y}}^t={\left\{{\mathrm{Y}}_i^t\right\}}_{i\in N}$$

(5)

The problem under consideration is: how to design decisions for all tasks ${\mathrm{Y}}^t$ which are executed at local SBS-MEC servers or offloaded to neighboring SBS-MEC servers. Thanks to the fuzzy-based edge orchestrator, each task will be decided based on fuzzy-logic approach, which will be described in the next section.

4. Fuzzy Logic Based Collaborative Task Offloading

In this study, we propose a Fuzzy-based collaboration scheme among SBS-MEC servers to improve the efficiency of resources utilization and reduce the task execution latency. Without this collaboration, if there are the small number of service requests from the user devices to connected SBS-MEC servers, these servers are not utilized properly and the resources are wasted. In contrast, the server will be overloaded when handling a large number of service requests and applications. According to Figure 4, the fuzzy edge orchestrator module has complete information resource capacities of the SBS-MEC server including task size, delay sensitivity of task, neighboring SBS-MEC, and local SBS-MEC virtual machine utilization as well as network delay. We assume that each mobile device is represented by a single virtual machine which has the computing capacity of 2 giga instructions per second (GIPS), while each MEC server consists of eight virtual machines with the capacity of 10 GIPS. The three main components of the proposed fuzzy-logic system (FLS) are fuzzification, fuzzy inference engine, and defuzzification.

4.1. Fuzzification

In our system, the fuzzy edge orchestrator module keeps track of the SBS-MEC servers in SCNs. Based on information observation, we leverage and transform the crisp values into fuzzy value, as shown in

Table 3. Fuzzification of input variables.

Fuzzification	Variables	Fuzzy Set	Membership Function	Ranges
Task Size (GI)	$\alpha$	Small	L-R open shoulder	0–8
		Medium	Triangular	6–18
		Large	L-R open shoulder	16–50
Delay Sensitivity of Task (%)	$\beta$	Low	L-R open shoulder	0–0.4
		Medium	Triangular	0.3–0.7
		High	L-R open shoulder	0.6–1.0
Local SBS-MEC VM Utilization (%)	$\gamma$	Light	L-R open shoulder	0–40
		Normal	Triangular	30–70
		Heavy	L-R open shoulder	60–100
Network Delay (ms)	$\delta$	Short	L-R open shoulder	0–4
		Medium	Triangular	2–12
		Large	L-R open shoulder	10–100
Neighboring SBS-MEC VM Utilization(%)	$\theta$	Light	L-R open shoulder	0–40
		Normal	Triangular	30–70
		Heavy	L-R open shoulder	60–100

. According to fuzzy rules, the offloading decision is made, which is then transformed into crisp values and will be considered as an output. The final decision will be the local SBS-MEC or neighboring SBS-MEC execution. The fuzzification process is described in Table 3 and

Table 4. Fuzzification of output.

Offloading Decision	Membership Function	Ranges
Local Edge	Triangular	0–60
Neighboring Edge	Triangular	40–100

[24,25,54,55].

Membership Functions

For effective collaboration among SBS-MEC servers, we must choose the significant input variables. In this study, we defined five variables: task size, delay sensitivity of task, local SBS-MEC VM utilization, network delay, and neighboring SBS-MEC VM utilization, as given below:

$$\mathsf{\Omega }=[\alpha ,\beta ,\gamma ,\delta ,\theta ],\mathsf{\Omega }\in {\mathrm{Y}}^t$$

(6)

where $\alpha$ is the volume of input task size, which directly effects the task execution time; $\beta$ represents the related task’s delay sensitivity, which decides whether the offloaded task is either a latency-sensitive or a delay-tolerant task. $\gamma$ indicates the local SBS-MEC server VM utilization and provides the information about the resource computing capacity of the local SBS-MEC server. If the SBS-MEC server is least loaded, then it is beneficial to offload the task to the local SBS-MEC server. $\delta$ represents the network delay, and it is a significant bottleneck of the system. When the network delay is high or congested due to the excessive number of user requests, it is convenient to offload the task to local SBS-MEC server rather than the neighboring SBS-MEC server. In this study, network delay is observed through a single SBS-MEC server queue with the Markov Modulated process in Poisson fashion (MMPP) [56]. $\theta$ is the neighboring SBS-MEC server utilization. In densely deployed SBS-MEC server environments, it is not a good decision to always offload the task to the local SBS-MEC server. If network delay is not congested and local SBS-MEC server is heavily loaded, offloading the task to the neighboring SBS-MEC server is advantageous.

In Table 3, according to membership and its ranges, we can model them into membership functions. Membership function (MF) can be mathematically characterized by using Equation (7), where each element of $\chi$ is within the range of 0 and 1. A is the fuzzy set which is described using Equation (8):

$${\xi }_A\left(\chi \right):\chi \to [0,1],\forall \chi \in X$$

(7)

$$A=\{(\chi ,{\xi }_A\left(\chi \right)):\chi \in X\}$$

(8)

Moreover, membership functions allow us to depict a fuzzy set graphically. Membership function, ${\xi }_A\left(\chi \right)$, is presented by a different function, such as triangular, Gaussian, left-right open shoulder, piece-wise linear, or singleton [57]. According to the information in Table 3, our model can use the triangular and left-right open shoulder membership function. These functions are given as:

$${\xi }_A^{triangular}\left(\chi \right)=\left\{\begin{array}{cc}0;\hfill & if\chi ⩽p\hfill \\ \frac{\chi -p}{m-p};\hfill & ifp<\chi ⩽m\hfill \\ \frac{q-\chi }{q-m};\hfill & ifm<\chi ⩽q\hfill \\ 0;\hfill & if\chi \ge q\hfill \end{array}\right.$$

(9)

$${\xi }_A^{left}\left(\chi \right)=\left\{\begin{array}{cc}1;\hfill & if\chi ⩽p\hfill \\ \frac{q-\chi }{q-p};\hfill & ifp<\chi ⩽q\hfill \\ 0;\hfill & if\chi \ge q\hfill \end{array}\right.$$

(10)

$${\xi }_A^{right}\left(\chi \right)=\left\{\begin{array}{cc}0;\hfill & if\chi ⩽p\hfill \\ \frac{\chi -p}{q-p};\hfill & ifp<\chi ⩽q\hfill \\ 1;\hfill & if\chi \ge q\hfill \end{array}\right.$$

(11)

To clearly understand these functions, their shapes are shown in Figure 5.

According to $\mathsf{\Omega }$ (Equation (6)), we will build five MF sets and three linguistic variables will be included in each set by combining the triangular and left-right (L-R) open shoulder MFs. The x-axis describes the quantized sensed values of the inputs and the y-axis indicates the degree of the membership (d.o.m.). It is difficult to choose the values of the MFs owing to the notable effect of FLS performance. In this study, the d.o.m. values for each fuzzy variable are decided empirically, similar to other existing systems using fuzzy decision mechanisms in different applications [24,55]. Furthermore, we used the values of MFs from [54], as this has a great contribution for task offloading in edge computing environment using fuzzy logic. For describing the fuzzification process, we considered one example where the values of the five input variables are: 9 GI of a task size, 0.3% of delay sensitivity, 55% of the local SBS-MEC VM utilization, 7 ms of network delay, and 20% of the neighboring SBS-MEC VM utilization. From Figure 6a, we can observe that, when the task size is 9 GI, then it lies in the medium fuzzy set and the d.o.m. will be 0.5. From Figure 6b, we can see that, when the delay sensitivity is 0.3%, then it lies in the low fuzzy set and the d.o.m. will be 0.3. Similarly, we can obtain the d.o.m. for other input variables from Figure 6c–e.

4.2. Fuzzy Inference Engine

To determine the fuzzy output based on the above-mentioned fuzzy input variables, fuzzy rules are used. One important indicator used in our model is a fuzzy set or the linguistic variables: small, medium, and large (Table 3). Different linguistic variables are used to represent the input and output variables of FLS. A linguistic variable is defined using three parameters or triplets ($V,X,{\mathsf{\Omega }}_V$), where V is a variable such as task size, delay sensitivity of task, network delay, etc.; X is the range of values of the variable, and ${\mathsf{\Omega }}_V$ is a finite or infinite set of fuzzy sets [55]. According to Figure 6a, the linguistic variable for task size can be defined as follows:

$$Linguisticvariablefortasksize=\left\{\begin{array}{c}\alpha =TaskSize\hfill \\ X={\Re }^{+}\hfill \\ {\mathsf{\Omega }}_{\alpha }=(Small,Medium,Large)\hfill \end{array}\right.$$

(12)

The mathematical description of the above-mentioned input variable, $\mathsf{\Omega }$, and their respective linguistic variables are given below:

$${\mathsf{\Omega }}_{\alpha }\left(\chi \right)=[{\xi }_{\alpha }^{Sml}\left(\chi \right),{\xi }_{\alpha }^{Md}\left(\chi \right),{\xi }_{\alpha }^{Lrg}\left(\chi \right)]$$

(13)

$${\mathsf{\Omega }}_{\beta }\left(\chi \right)=[{\xi }_{\beta }^{Low}\left(\chi \right),{\xi }_{\beta }^{Md}\left(\chi \right),{\xi }_{\beta }^{High}\left(\chi \right)]$$

(14)

$${\mathsf{\Omega }}_{\gamma }\left(\chi \right)=[{\xi }_{\gamma }^{Lt}\left(\chi \right),{\xi }_{\gamma }^{Nor}\left(\chi \right),{\xi }_{\gamma }^{Hvy}\left(\chi \right)]$$

(15)

$${\mathsf{\Omega }}_{\delta }\left(\chi \right)=[{\xi }_{\delta }^{Srt}\left(\chi \right),{\xi }_{\delta }^{Md}\left(\chi \right),{\xi }_{\delta }^{Lrg}\left(\chi \right)]$$

(16)

$${\mathsf{\Omega }}_{\theta }\left(\chi \right)=[{\xi }_{\theta }^{Lt}\left(\chi \right),{\xi }_{\theta }^{Nor}\left(\chi \right),{\xi }_{\theta }^{Hvy}\left(\chi \right)]$$

(17)

For combining and evaluating the fuzzy rules, fuzzy inference is used. A fuzzy variable is the output of the inference system which is used for the process of defuzzification step. Fuzzy rule consists of a series of simple IF-THEN rules along with a condition and conclusion. For example, IF the task size is medium AND the delay sensitivity is low AND local SBS-MEC VM utilization is normal AND network delay is medium AND neighboring SBS-MEC VM utilization is heavy, THEN offload to the local edge server. In this simulation, the total number of fuzzy rules used is 243 because there are five input variables which include 3 linguistic terms.The example of fuzzy rules is depicted in

Table 5. Example of fuzzy inference system rules.

Rule Index	Task Size	Delay Sensitivity	Local SBS-MEC VM Utilization	Network Delay	Neighboring SBS-MEC VM Utilization	Offloading Decision
R1	Small	Medium	Light	Large	Light	Local Edge
R2	Medium	Low	Normal	Medium	Heavy	Local Edge
R3	Medium	Low	Heavy	Short	Light	Neighboring Edge
R4	Large	High	Normal	Large	Heavy	Local Edge
R5	Large	Low	Heavy	Short	Light	Neighboring Edge
R6	Small	Medium	Normal	Medium	Normal	Local Edge
R7	Medium	Low	Heavy	Short	Light	Neighboring Edge

.

4.3. Defuzzification

Defuzzification maps the output variable derived from the inference engine of the fuzzy logic system to a crisp value, which should be easily understandable by the human user. For defuzzification, different methods are used, such as height and modified height, maximum, mean of maximum, and centroid method. Among them, the centroid defuzzifier method is the most widely used, which returns the center of gravity (COG) of the aggregated fuzzy set [55]. In this study, we used COG method for the defuzzification step. For calculating the COG, the formula given below is used to calculate the centroid, where ${\chi }^{*}$ is the x-coordinate of the center of gravity, $\xi$ depicts the bound formed by the output degree of membership, and $\chi$ is the edge node suitability. Finding the ${\chi }^{*}$ point is the basic principle of the COG method and it uses the vertical line which will slice the aggregate into two equal masses:

$$COG\left(Execution\right),{\chi }^{*}=\frac{\int \chi \xi \left(\chi \right)d\chi }{\int \xi \left(\chi \right)d\chi }$$

(18)

Algorithm 1 shows the FCTO algorithm, which basically decides the target computational node among SBS-MEC servers. At this target node, the users will offload their incoming task requests by considering various factors such as the task characteristics, delay sensitivity, local and neighboring SBS-MEC server utilization, and network delay. The algorithm returns the offloading decision for selecting the local or neighboring SBS-MEC. We assumed that tasks are already offloaded to the local SBS-MEC server from the user device. The algorithm runs on edge orchestration. The edge orchestrator receives three parameters, namely, the task size, delay sensitivity, and local SBS-MEC VM utilization from the local SBS-MEC server. The COG value is initialized in line 1. The values for the other two parameters, network delay and neighboring SBS-MEC VM utilization, were obtained in lines 2 to 4, where $NeighboringEdg{e}_{nodes}$ indicate neighboring edge node. In line 5, all the input parameters are mapped onto fuzzy sets based on their membership functions which are described in Section 4, and the inference rules from Table 5 are applied. The output of the COG evolves into a crisp value which will be within 0 and 100 after implementing the centroid defuzzifier. If the value of the COG is below 50, the task will offload to the local SBS-MEC server; otherwise, it will offload to the neighboring SBS-MEC server. For example, if the d.o.m. of ${\xi }_{localedge}$ and ${\xi }_{neighboringedge}$ are 0.2 and 0.5, respectively, then the crisp value will be 58, which is shown in Figure 7b. Therefore, according to the crisp value, the incoming task will be offloaded to the neighboring SBS-MEC server.

Algorithm 1 Fuzzy Logic Based Collaborative Task Offloading (FCTO) Algorithm

Definitions: Size of task: $\alpha$ Delay sensitivity: $\beta$ Local SBS-MEC VM utilization: $\gamma$ Network delay: $\delta$ Neighboring SBS-MEC VM utilization: $\theta$. Input: $\alpha$, $\beta$, $\gamma$ = $LocalEdg{e}_{nodes}$.$\alpha$, $\beta$, $\gamma$ Output: Target the SBS-MEC server selection to offload the incoming task. 1: $COG\leftarrow 0$ 2: for$i=1$to$|NeighboringEdg{e}_{nodes}|$do 3:  if there are neighboring resource capacity then 4:   $\delta$, $\theta$ = $NeighboringEdg{e}_{nodes}$ [i]. $\delta$, $\theta$ 5:   COG=Fuzzy Logic ($\alpha$, $\beta$, $\gamma$, $\delta$, $\theta$) 6:   if $COG<50$ then 7:    Offload decision ← Local SBS-MEC server 8:   else 9:    Offload decision ← Neighboring SBS-MEC server 10:   end if 11:  else 12:   Offload to remote cloud 13:  end if 14: end for 15: return Offload decision

5. Performance Evaluation

To evaluate the efficiency of our proposed FCTO mechanism for MEC-enabled DDSCNs, we used EdgeCloudSim simulator [58] for simulating different scenarios. This simulator extends the CloudSim toolkit [59] by including additional features that allow for modeling the virtualized resources, mobility model, network modeling, and edge orchestrator module to enable accurate simulations of the physical edge infrastructure environment. We used this environment to evaluate how different offloading techniques affect the task failure rate, average service time, and server utilization for different numbers of devices and task sizes. For simulation, we used an augmented reality (AR) application which represents the realistic real-life scenarios. Here, the offloaded tasks of mobile devices are considered as a set of AR applications. For example, a user can offload some pictures to the server by wearing smart glasses for face recognition service. The characteristics of the AR application and its respective values, which are used during simulation, are represented in

Table 6. Simulation parameters.

Parameter	Value
Number of mobile devices	100∼1000
Number of Small Base Stations (SBS)	16
VMs per Mobile/MEC server/Cloud	1/4∼8/4
VM processor speed (GIPS) per
Mobile/MEC server/Cloud	2/10/100
Active/Idle period (sec)	40/20
Average Upload/Download data size (KB)	1500/25
Average size of the task (GI)	2∼20
Delay Sensitivity (%)	0.1∼0.9
Inter-arrival time of tasks (s)	2
Propagation delay (ms)	3
Application type	Augmented Reality

. In this simulation, we considered the number of mobile devices to be within 100 and 1000 and the number of SBSs to be 16. During task generation, the system is considered to be in active mode during which the mobile device generates the task. Thereafter, it will be in idle mode for some period. We set 40 s for the active mode and 20 s for the idle mode. For sending the data to the server or receiving the data from the server, we selected the data size 1500 KB for uploading and 25 KB for downloading. The uploaded data size is large compared with the downloaded data because the AR application needs to upload the image in the server and the server responds with a text metadata which requires a smaller data size during downloading. The offloaded task can be either real time or not and it can be determined using delay sensitivity. Moreover, to determine the frequency for sending the task to the edge, the inter-arrival time of the task is used in our simulation.

To verify the effectiveness of the FCTO performance, we compared the average task completion time and the average server utilization corresponding to the average task sizes based on three task offloading schemes: local SBS-MEC offloading, workload orchestration based task offloading (WOTO) between the SBS-MEC server with cloud, and our proposed FCTO among SBS-MEC servers. Figure 8a,b represents the results of comparing the performance, where the x-axes indicate the scalability of task sizes varying from 2 to 20 GI (Giga Instructions), and the y-axes denote the average task completion time and average server utilization, respectively. From Figure 8a, it can be seen that, when the average task size is small, i.e., 2 GI, then the average task completion time is almost similar for local SBS-MEC offloading and the proposed FCTO scenario. Meanwhile, when the task size is between 2 and 14 GI, the proposed FCTO scheme will require a lower completion time compared with WOTO and local SBS-MEC offloading schemes. This is because, for small and medium task sizes, it is easy to handle the task among SBS-MEC servers, but when the task size becomes large, such as at 16 GI, the WOTO scheme will require lower completion time compared with the other schemes. This is because this scheme forwards the task to the cloud for processing, which has unlimited computing capacity. In this simulation, we considered the number of mobile devices to be 100.

From the analysis in Figure 8b, it is observed that, when the average task size is between 2 and 10 GI, the local SBS-MEC offloading and the proposed FCTO scheme provide almost similar results, while the WOTO scheme provides lower server utilization compared with the other schemes. Meanwhile, if the task size is 16 GI, then the average server utilization for local SBS-MEC offloading, WOTO, and the proposed FCTO schemes are 8.43%, 1.23%, and 10.52%, respectively. Thus, the proposed FCTO scheme accomplishes a server utilization that is 2.09% more than that of local SBS-MEC offloading and 9.29% more than that of the WOTO scheme. Therefore, from the review, it can be concluded that our introduced offloading scheme will provide more server utilization than others. This is because our proposed system can make a dynamic decision as it analyzes the CPU usage of all VMs on the SBS-MEC servers and the VM with the least CPU usage is selected to compute the task. On the contrary, the WOTO scheme requires offloading some tasks to the remote cloud for processing.

Moreover, to validate the significance of the proposed FCTO scheme, we conducted another experiment considering the average task failure rate and task completion time with respect to the number of mobile devices is shown in Figure 9a and Figure 9b respectively, where both the x-axes indicate the scalability of the mobile device and the y-axes represent the average task failure rate and task completion time, respectively. In these experiments, we have assigned eight VMs in each MEC server. In case of a lightly loaded system, for example, if the number of mobile devices is up to 200, the performance of the above-mentioned three approaches will provide a similar result and the average task failure rate will be approximately 0, which is represented in Figure 9a.The average task failure rate tends to increase in all three scenarios, with an augmentation of the number of mobile devices; however, when the number of mobile devices is more than 200, the proposed FCTO scheme will provide less task failure compared with the other two schemes, as these tasks are distributed and offloaded easily to the neighboring SBS-MEC server. Meanwhile, the local SBS-MEC offloading scheme cannot handle more tasks when the number of mobile devices is more, and, due to the congestion of VMs in the local SBS-MEC server, the WOTO scheme sends the incoming task to the remote cloud. Because of the WAN bandwidth, the average task failure will be increased in the WOTO scheme. From Figure 9b, it can be observed that, when the system is heavily loaded due to the growing number of mobile devices, the completion time of the tasks, as well as network delay, will be increased in all scenarios because of the congestion. For example, when the number of mobile users is 600, then the average task completion time for local SBS-MEC offloading, WOTO, and the proposed FCTO schemes are 1.54, 2.72, and 0.68 s, respectively. Thus, the proposed FCTO scheme reduces the task completion time by 0.86 s when compared with the local SBS-MEC offloading and by 2.04 s when compared with WOTO scheme. Therefore, by comparing with the other two approaches, we can confirm that our introduced scheme will provide a lower task completion time. This is because our proposed collaborative approach can distribute the arrival user requests among SBS-MEC servers, and it can improve the system performance to handle a large number of mobile devices.

Finally, the last simulation result shows the impact of the VM number on the SBS-MEC server. In this simulation, we assigned eight VMs to the extremely powerful MEC server, four VMs to the least powerful one, and six VMs to the other. From Figure 10a,b, it can be observed that the average task completion time tends to reduce as the number of VM increases. Compared to the WOTO scheme, the proposed FCTO scheme outperforms among all the scenarios. For example, when the number of the mobile devices is 700 and the number of VMs is four per SBS-MEC server, the average task completion time is 3.07 s in the WOTO scheme. In the same scenario, the average task completion time is 1.17s in our proposed FCTO scheme. Thus, the proposed FCTO scheme reduces the task completion time by 1.9 s when compared with the WOTO scheme. Throughout the analysis, as observed from Figure 10a,b, the proposed FCTO scheme with four VMs can alleviate the average task duration at almost 60.52% more than the WOTO scheme.

Furthermore, in Figure 10c,d, we performed another experiments to investigate the effect of SBS-MEC server capacity for the task failure rate and server utilization by varying the number of mobile devices. From Figure 10c, it can be observed that the average task failure rate tends to increases as the number of mobile device increases. The SBS-MEC server while considering four VMs, increases the task failure rate after 200 mobile devices, whereas, with six VMs, it increases the task failure rate after 500 mobile devices, and the SBS-MEC server with eight VMs can handle more than 700 mobile devices without task failure. From Figure 10d, it can be seen that the server utilization tends to increase if the number of mobile devices is also increased; however, if the number of VMs is increased, the server utilization will be decreased. When the number of mobile device is between 100 and 500, the SBS-MEC server with four VMs utilizes more servers than others. However, when the number of mobile device is more than 500, server utilization is a little lower than the six VMs because of increasing task failure rate. Therefore, it can be summarized that, when the number of VMs is higher, the average task completion time is reduced, and it can handle more mobile devices. This result is expected and the main motivation of this simulation is to explain the necessity of the collaborative task offloading scheme.

6. Conclusions

This paper proposes a fuzzy based collaborative task offloading for MEC-enabled SCN. In our scheme, the proposed FCTO algorithm analyzed the under-utilized and over-utilized SBS-MEC servers and determined the target computational node among SBS-MEC servers that were lightly loaded to share computation resources with each other. It alleviated the load on the local SBS-MEC server and could easily compute the different service requests according to user demands. Moreover, a fuzzy edge orchestrator module acted as a coordination point of the system to collect information from all SBS-MEC servers and, based on the fuzzy rules, it decided the task handling location which was either the local SBS-MEC server or the neighboring SBS-MEC server. Extensive simulations were performed to evaluate the performance of our proposed task offloading scheme. Our proposal outperformed two reference schemes, namely, local SBS-MEC and workload orchestration based task offloading (WOTO) schemes in terms of reducing task failure rate and execution latency. Moreover, it also provided more server utilization. For future studies, we intend to use a machine learning approach for collaboration among SBS-MEC servers. Moreover, for more efficient reduction of task failure and time consumption, we expand the FCTO algorithm with user’s mobility in small-cell networks.