Week 5 Lecture 1

EL
PT
N
0 mins
Mobile Edge Computing (MEC)

EL
PT
N
Dr. Rajiv Misra, Professor
Dept. of Computer Science & Engineering
Indian Institute of Technology Patna
[email protected]
Contents
• Introduction to Mobile Edge Computing
• MEC Architecture
• Task offloading in MEC

EL
• Resource Allocation in MEC
• Mobility Management and Resource Migration in MEC

PT
N
Mobile Edge Computing (MEC)
• Mobile-edge Computing provides IT and cloud-computing capabilities within the Radio Access Network (RAN) in close proximity to
mobile subscribers.
• Provides high bandwidth and very low latency services.
• Operators can open their Radio Access Network edge to the authorized third parties

EL
• MEC can be implemented in cellular base stations
• The MEC server provides computing resources, storage capacity, connectivity, and access to user traffic and radio and network
information.

PT
N
Characteristics of Mobile Edge Computing (MEC)
• Typically, Mobile-edge Computing is characterized by:
• On-Premises
• Proximity

EL
• Lower latency
• Location awareness
• Network context

PT
N
Mobile Edge Computing (MEC)

Models closely related to MEC:

• MCC – mobile cloud computing

EL
• Fog Computing
• Cloudlet

PT
N
Mobile (Multi-Access) Edge Computing (MEC)
• From the mobile users’ point of view, the most notable drawback of previously
mentioned edge computing paradigms is that QoS (Quality of Service) and QoE
(Quality of Experience) for users can be hardly guaranteed, since the
computing is not integrated into an architecture of the mobile network.

EL
• In 2014, the Industry Specification Group (ISG) within European
Telecommunications Standards Institute (ETSI) outlined the concept of Mobile
Edge Computing (MEC) which integrates edge computing into the mobile

PT
network architecture.

N
MEC Architecture
• Several MEC concepts are built upon with the purpose to smoothly
integrate cloud capabilities into the mobile network architecture.
• We shall discuss some of the architectures of MEC such as:

EL
• Small Cell Cloud (SCC)
• Mobile Micro Cloud (MMC)

PT
• Fast Moving Personal Cloud
• Follow Me Cloud (FMC)
• CONCERT
• ETSI MEC
N
Small Cell Cloud (SCC)

EL
PT
N
MME - Mobility Management Entity SCM - Small Cell Manager RAN – Radio Access Network
HSS - Home Subscriber Server L-SCM – Local SCM CN – Core Network
S-GW - Serving Gateway VL-SCM – Virtual Local SCM SCeNB – Small Cell eNodeB
P-GW - Packet Gateway R-SCM – Remote SCM UE – User Equipment
Mobile Micro Clouds (MMC) MME - Mobility Management Entity
HSS - Home Subscriber Server
S-GW - Serving Gateway
P-GW - Packet Gateway
RAN – Radio Access Network
CN – Core Network
SCeNB – Small Cell eNodeB
UE – User Equipment

EL
PT
N
Fast Moving Personal Cloud (MobiScud) MME - Mobility Management Entity
HSS - Home Subscriber Server
S-GW - Serving Gateway
P-GW - Packet Gateway

RAN – Radio Access Network

CN – Core Network
SCeNB – Small Cell eNodeB
UE – User Equipment

EL
PT
N
Follow Me Cloud (FMC) MME - Mobility Management Entity
HSS - Home Subscriber Server
S-GW - Serving Gateway
P-GW - Packet Gateway
DC/GW – DataCenter Gateway

EL
PT
N
CONCERT MME - Mobility Management Entity
HSS - Home Subscriber Server
S-GW - Serving Gateway
P-GW - Packet Gateway

EL
PT
N
ETSI MEC

EL
PT
N
MEC Architecture: Comparison

EL
PT
N
MEC Deployment Options
• MEC server directly at the base station
• MEC servers at cell aggregation sites or at multi-RAT aggregation
• MEC server farther from the UEs and at the edge of CN

EL
• Selection of the MEC server deployment depends on many factors, such as,
scalability, physical deployment constraints and/or performance criteria (e.g.,
delay).

PT
N
Deploying Mobile Edge Computing (MEC)
• Edge computing in outdoor scenarios
• Improve mobile users’ Quality of Experience (QoE)
• Improve infrastructure’s efficiency

EL
• Tight integration with radio equipment

• Edge computing in indoor scenarios

PT
• Machine-to-Machine scenarios
• Retail Solutions
N
• Stadiums, Airports, Stations, Theatres
• Big data and Analytics
 Computation Offloading in MEC
• A critical use case regarding the MEC is a computation
offloading as this can save energy and/or speed up the
process of computation.
• A crucial part regarding computation offloading is to

EL
decide whether to offload or not. In the former case,
also a question is how much and what should be
offloaded.

PT
A decision on computation offloading may result in:

Local execution - The whole computation is done locally at the UE. The offloading to the
MEC is not performed.
N
Full offloading - The whole computation is offloaded and processed by the MEC.

Partial offloading - A part of the computation is processed locally while the rest is
offloaded to the MEC.
Task Offloading in MEC
• The computation offloading (partial offloading in particular) is a very
complex process affected by different factors, such as:
• Users preferences,

EL
• Radio and backhaul connection quality,
• UE capabilities and/or cloud capabilities
• Resource availability

PT
• An important aspect in the computation offloading is also an application
model/type since it determines whether full or partial offloading is
N
applicable and what could be offloaded.
Task Offloading Objectives
● Objectives formally and mathematically define the goals and guide the offloading solution.
Objectives of the task offloading problem can be categorized as follows:

● Energy - total consumed energy by offloading is the consumed energy to send the task from
device to the server, the consumed energy to execute the task in the edge server, and the
consumed energy to return the results to the device.

EL
● Latency - the total time of transferring the task to the edge servers, the taken execution time in
the servers, and the time to return the results to the device.

PT
● Response Time – the interval time between offloading the tasks from local devices to the remote
servers and receiving the suitable answer in the devices.

● N
Cost - cost of edge and cloud resource usages and sometimes the penalty cost due to SLA
violations. There are mainly two kinds of resources, private resources and public resources, used
for finishing offloaded tasks, for the service provider.

● QoE/QoS – measures user satisfaction, a combination of various factors such as latency,

response-time, power saving, bandwidth, resource requirements.
Factors Affecting Task Offloading
● Several factors influence the decision-making process in task offloading in edge computing. The
selection of appropriate offloading strategies depends factors such as:

● Latency: local processing for low-latency demands.

EL
● Computational Resources: availability of resources.

● Power Constraints: energy consumption and efficiency

PT
● Data Variety: Large datasets v/s Small datasets, private and sensitive data

●
N
Task Variety: compute intensive v/s data intensive

Application Requirements: strict real-time requirements, desired quality of service (QoS)

● Device Mobility: devices move within coverage units or in and out of the network coverage.
Task Offloading in MEC
Computation Offloading or Task offloading is a complex process and can be affected by a number of
different factors. In particular, this process involves task partitioning, offloading decision making and
distributed execution.

TT

EL
Offload to Edge/Cloud

PT
User
Application ?

End-Devices
N Task
Partitioning
Decision making
TT

Local Computation
Task Offloading in MEC

EL
PT
The computation offloading decision itself is done at the UE by means
of a computation offloading policy module. This module decides,
N
during each time slot, whether the application waiting in a buffer should
be processed locally or at the MEC while minimizing the execution
delay.

CSI – Channel State Information

Task Offloading Decision Making
How to utilize and manage offloading process in practice?
The User Equipment (UE) needs to be composed of a following components:

● The code profiler is responsible for determining what could be offloaded (depending on

EL
application type and code/data partitioned).

● The system profiler is in charge of monitoring various parameters, such as available

bandwidth, data size to be offloaded or energy spent by execution of the applications

PT
locally.

● The decision engine determines whether to offload or not; and in case of offloading,
N
determines the location to offload.
Task Offloading Application Model
● what and how much could be offloaded? - depends
Remote Server
on the application running on UE

● Offloadability of application - The application

enabling code or data partitioning and parallelization

EL
can be categorized into two types,
9 10 11 12

1. Fully offloadbale - Each offloadable part may

differ in the amount of data and required

PT
computation.
Local
2. Partially offloadbale - Applications which are

N
always composed of some offloadable parts
and some non-offloadable parts.
Execution

1 2 3
Non-Offloadable

4 5 6 7 8 9
Offloaded

10 11 12

User Application
Task Offloading Application Model
● Knowledge on the amount of data to be processed – The applications can be classified according
to the knowledge on the amount of data to be processed.

1. Fixed Input - the amount of data to be processed is known beforehand (e.g., by face
detection, virus scan, etc.,)

EL
2. Interative Input - continuous-execution application and there is no way to predict how long
they will be running (such as, online interactive games)

PT
N
Task Offloading Application Model
● Dependency of the offloadable parts – offloading depends
on the mutual dependency of individual parts to be
processed.

● The parts of the application can be either independent on

each other or mutually dependent.

EL
● Independent - all parts can be offloaded simultaneously and
processed in parallel.

PT
● Dependent - the application is composed of parts
(components) that need input from some others and
parallel offloading may not be applicable.

● N
The dependency relationship among individual components
can be expressed by component dependency graph (CDG)
Example: whole application is divided into M non-
offloadable parts (1, 4, 6) and N offloadable parts (2, 3,
or call graph (CG) 5). In this case, 2 and 3 can be offloaded only after
execution of the 1 while the 5 can be offloaded after
execution of 3 and 4.
Task Offloading in collaborative cloud-edge computing
• The design for collaborative cloud-
edge computing architecture consists
of hierarchical tiers, for e.g., end
devices, network edge nodes, central

EL
offices, and a remote data center.

• The end devices can locally process a

PT
fraction of the input workloads,
horizontally offload to neighboring
devices, and vertically offload to edge
N
nodes for remaining workloads.
Task Offloading Horizontal and Vertical Offloading
● Vertical offloading refers to transferring
tasks from higher-level processing units
to lower-level ones, for example, from
edge server to a cloud service.
● Pros – more computing power

EL
● Cons – increased latency due to data
transmission delays

● Horizontal offloading refers to the

PT
distribution of tasks across multiple
processing units, for example,
distributing a single server's workload

●
N
across multiple servers in the edge to
increase processing capacity.
Pros – distributed task execution for
efficient utilization of resources
● Cons – low compute capacity and
resource constrained
Combined offloading in edge computing can
significantly reduce total system costs
Task Offloading
• In summary, task-offloading process starts at the end device (i.e., mobile/IoT devices) and leverages
the benefits of the added computational resources at the edge of the network, before ending up to
the Cloud.

• The benefits of task offloading are numerous, allowing to increase the QoS and QoE of the

EL
application, while extending the battery lifetime of the end devices.

• Offloading parts of an application from an end device to a remote Edge or Cloud site, arises a

PT
number of challenges mostly related to the dynamic network behavior and the resource allocation
problem to be solved.

•
following type:
To minimize an execution delay
N
The main objective of the works focused on the full/partial offloading decision making can be of the

• To minimize energy consumption at the UE while predefined delay constraint is satisfied

• To find a proper trade-off between both the energy consumption and the execution delay
Task Offloading Minimization of Execution Delay
One of the advantages introduced by the task offloading is a possibility to Remote Server
reduce the execution delay (D).
In case the UE performs all computation by itself (i.e., no
offloading is performed), the execution delay (𝑫𝑫𝑰𝑰 ) represents
solely the time spent by the local execution. In case

EL
offloading is performed, the execution delay (𝑫𝑫𝒐𝒐 )
incorporates three following parts:
1. transmission duration of the offloaded task (𝑫𝑫𝒐𝒐𝒐𝒐 )

PT
2. computation/processing time at the server (𝑫𝑫𝒐𝒐𝒐𝒐 )
3. reception duration of the processed data (𝑫𝑫𝒐𝒐𝒐𝒐 )
𝑫𝑫𝒐𝒐 = 𝑫𝑫𝒐𝒐𝒐𝒐 + 𝑫𝑫𝒐𝒐𝒐𝒐 + 𝑫𝑫𝒐𝒐𝒐𝒐

N
In this case, it will be favorable for the UE to offload its task to
remote server whenever the local execution delay is more
UE2 UE1

Example: UE1 performs all computation locally since

than remote execution delay i.e., 𝑫𝑫𝒊𝒊 > 𝑫𝑫𝒐𝒐 the local execution delay is significantly lower than
expected execution delay (i.e., 𝑫𝑫𝒊𝒊 < 𝑫𝑫𝒐𝒐 ). Contrary, a
better alternative for the UE2 is to offload to the
remote server as the local execution would result in
notable higher execution delay (i.e., 𝑫𝑫𝒊𝒊 > 𝑫𝑫𝒐𝒐 ).
Task Offloading Minimization of Execution Delay
We shall assume a basic system model where a computation task is defined as
𝑇𝑇 = { 𝜆𝜆, 𝜌𝜌, 𝛿𝛿 } Remote Server
where 𝜆𝜆 is the size of input data in bits, 𝜌𝜌 is the processing density in CPU cycles per
The image part with relationship ID rId4 was not found in the file.

𝛿𝛿 𝜌𝜌
input bit and 𝛿𝛿 is the size of processed or output data in bits.
Let 𝒇𝒇𝒎𝒎𝒎𝒎 and 𝒇𝒇𝒖𝒖𝒖𝒖 denote the processing capacity (in Hz) at MEC and UE respectively.
Let the bandwidth (in bits-per-second) between UE and MEC be denoted by 𝑏𝑏 . 𝜆𝜆
𝑫𝑫𝒐𝒐𝒐𝒐

EL
Delay in Local Execution 𝑫𝑫𝒐𝒐𝒐𝒐
𝜆𝜆𝜌𝜌 𝑫𝑫𝒐𝒐𝒐𝒐

PT
𝑫𝑫𝒊𝒊 =
𝒇𝒇𝒖𝒖𝒖𝒖
𝜆𝜆
Delay in Remote Execution

N
𝑫𝑫𝒐𝒐 = 𝑫𝑫𝒐𝒐𝒐𝒐 + 𝑫𝑫𝒐𝒐𝒐𝒐 + 𝑫𝑫𝒐𝒐𝒐𝒐

𝑫𝑫𝒐𝒐 =
𝜆𝜆
+
𝜆𝜆𝜌𝜌 𝛿𝛿
+
𝒃𝒃 𝒇𝒇𝒎𝒎𝒎𝒎 𝒃𝒃
UE

The offloading decision in this model is defined by the inequality 𝑫𝑫𝒐𝒐 < 𝑫𝑫𝒊𝒊
Task Offloading Minimization of Energy Consumption while
satisfying Execution Delay Constraint
Remote Server
The main objective is to minimize the energy consumption at
the UE while the execution delay constraint of the application
is satisfied. In case UE executes tasks locally, the energy
consumption (𝑬𝑬𝒊𝒊 ) is contributed by the processing unit. On

EL
one hand, the computation offloaded to the remote servers
saves battery power of the UE since the computation does not
have to be done locally. On the other hand, the UE spends

PT
certain amount of energy (𝑬𝑬𝒐𝒐 ) in order to:
1) transmit offloaded data for computation (𝑬𝑬𝒐𝒐𝒐𝒐 )
2) receive results of the computation (𝑬𝑬𝒐𝒐𝒐𝒐 )
UE2 UE1
N
Example: UE1 decides to perform the computation locally since the energy spent by the local
execution (𝑬𝑬𝒊𝒊 ) is significantly lower than the energy required for transmission/reception of
the offloaded data (𝑬𝑬𝒐𝒐). Contrary, the UE2 offloads its task as the energy required by the
𝑬𝑬𝒐𝒐 = 𝑬𝑬𝒐𝒐𝒐𝒐 + 𝑬𝑬𝒐𝒐𝒐𝒐
In this case, it will be favorable for the
computation offloading is significantly lower than the energy spent by the local computation. UE to offload its task to remote server
Although the overall execution delay would be lower if the UE1 offloads computation to the
remote server and also if the UE2 performs the local execution, the delay is still below
whenever 𝑬𝑬𝒊𝒊 > 𝑬𝑬𝒐𝒐
maximum allowed execution delay constraint (i.e., 𝑫𝑫𝒊𝒊 < 𝑫𝑫𝒎𝒎𝒎𝒎𝒎𝒎 ).
Task Offloading Minimization of Energy Consumption while
satisfying Execution Delay Constraint
Remote Server

Assuming the same formulation for delay as in the previous example, we need to define 𝛿𝛿 𝜌𝜌
energy consumption (𝑬𝑬𝒊𝒊 ) and (𝑬𝑬𝒐𝒐 ) in joules. Let 𝑾𝑾𝒏𝒏 denote the power (in watts) of UE’s
network adaptor and 𝑾𝑾𝒄𝒄 denote the power of UE’s processing unit.
𝜆𝜆

EL
Energy Consumption in Local Execution
𝜆𝜆𝜌𝜌
𝑬𝑬𝒊𝒊 = × 𝑾𝑾𝒄𝒄 𝑬𝑬𝒐𝒐𝒐𝒐
𝒇𝒇𝒖𝒖𝒖𝒖 𝑬𝑬𝒐𝒐𝒐𝒐

PT
Energy Consumption in Remote Execution 𝜆𝜆
𝑬𝑬𝒐𝒐 = 𝑬𝑬𝒐𝒐𝒐𝒐 + 𝑬𝑬𝒐𝒐𝒐𝒐

N
𝑬𝑬𝒐𝒐 =
𝜆𝜆+𝛿𝛿
𝒃𝒃
× 𝑾𝑾𝒏𝒏
𝑬𝑬𝒊𝒊 UE

The offloading decision in this model is defined by the inequality 𝑬𝑬𝒐𝒐 < 𝑬𝑬𝒊𝒊
Resource Allocation in MEC
• Resource allocation in Mobile Edge Computing (MEC) refers to the process of
distributing computing resources (such as CPU, memory, storage, and network
bandwidth) among different applications or services that are running on the edge
servers.

EL
• MEC enables mobile devices to offload their compute-intensive tasks to edge servers
located closer to the network edge, which can improve the performance of
applications and reduce network latency. To achieve this, the MEC system needs to
manage the available resources efficiently and allocate them to the applications in a

PT
way that maximizes the overall system performance.
• Resource allocation in MEC can be dynamic and adaptive, taking into account factors
such as:

N
• the current workload of the edge server,
• the quality of service requirements of the applications,
• the available network bandwidth.
• The goal is to ensure that the resources are utilized optimally, while meeting the
delay constrains of the applications and minimizing the overall energy consumption
of the system.
Resource Allocation in MEC
• A decision on the full or partial offloading of an
application to the MEC is accompanied by a proper
allocation of the computation resources on the Edge
Nodes; and if required on the Cloud as well.

EL
• The selection of computation placement is influenced
by the ability of the offloaded application to be
parallelized/partitioned.

PT
• If the parallelization/partitioning of the application is
not possible, only one physical node may be allocated
for the computing since the application cannot be split
into several parts.

N
• In the opposite case, the offloaded application may be
processed by resources distributed over several
computing nodes.
Resource Allocation in MEC
• The main objective of Resource allocation problems in MEC is the maximization of the
amount of the applications served by the MEC while satisfying the delay
requirements of the offloaded applications and optionally, energy consumption of
the system.

EL
• The decision where the individual applications should be placed depends on the
applications priorities, application’s delay requirements and availability of the
computing resources at the MEC.

PT
N
Resource Allocation in MEC
In case of VM based resources, the resource allocation problem has to deal with minimization of the execution
delay of the offloaded application along with minimizing both communication and computing resource
overloading/overprovisioning and the VM migration cost.
The computing nodes are represented by the SCeNBs and the VM migration may be initiated due to the SCeNBs
shutdown. The whole problem can formulated as the VM allocation at the SCeNB and solved by means of a

EL
Markov Decision Process (MDP).

PT
N
Clustered Resource Allocation
• Forming clusters of SCeNBs is a common approach to optimize resource allocation in Mobile Edge Computing
(MEC) systems. Clustering involves grouping together a set of SCeNBs that are geographically close to each other,
and can be controlled and managed as a single unit. By forming clusters, the MEC system can effectively manage
the resource allocation among the SCeNBs and improve the overall performance of the system.

EL
PT
N
Clustered Resource Allocation
• Requirements to form clusters of SCeNBs for resource allocation in MEC:
1. Define the clustering criteria: Define the criteria for clustering, such as the proximity of the
SCeNBs to each other, the network load, the available resources, and the QoS requirements
of the applications.
2. Determine the cluster size: Determine the optimal cluster size based on the clustering
criteria. The cluster size can be determined based on the number of SCeNBs that can be

EL
controlled and managed effectively as a single unit. Cluster size may be determined
dynamically as well.
3. Assign/Provisioning resources: Once the clusters are formed, the MEC system can

PT
allocate resources to each cluster based on the available resources and the QoS
requirements of the applications. This can be done using various resource allocation
techniques, such as dynamic resource allocation, load balancing, and QoS-aware
resource allocation.

•
N
4. Monitor and optimize: Finally, the MEC system should continuously monitor the
performance of the clusters and optimize the resource allocation based on the changing
workload and QoS requirements of the applications.
By forming clusters of SCeNBs, the MEC system can effectively manage the resource
allocation among the SCeNBs and improve the overall performance of the system. This can
lead to reduced network latency, improved application response time, and better utilization of
the edge resources.
Selection of Compute Nodes
• The selection of computing nodes can significantly influence not only the execution delay,
but also the power consumption of these computing nodes.
• Following key observation are made in regard to impact of the cluster size (i.e., the
amount of the SCeNBs performing computing) on both execution latency of the offloaded
application and the power consumption of the SCeNBs:

EL
• Backhaul Topology:
• Backhaul Connection:

PT
• Number of Nodes:
• Proper cluster formation and the SCeNBs selection play a crucial part in system
performance.

N
• The problem to find an optimal formation of the clusters of SCeNBs for computation
taking into account both execution delay and power consumption of the computing
nodes.
Clustering Strategies in MEC
• Clustering Strategies - Three different clustering strategies can be followed:

1. In the first strategy, SCeNBs are selected in order to minimize execution delay. Since all
SCeNBs in the system model are assumed to be one hop away (i.e., full mesh topology is
considered), all SCeNBs are included in the computation offloading and resource

EL
allocation. This can significantly reduce the execution delay due to the fact that the
computation gain (increase in offloaded application processing) is far greater than the
transmission delay.

PT
2. The objective of the second clustering strategy is to minimize overall power
consumption of the cluster. In this case, only the serving SCeNB is preferred to compute,
thus, any computation at the neighboring SCeNBs is suppressed to minimize power
consumption of the SCeNBs. This, however, increases overall latency and high variations

3.
of the computation load.
N
The last clustering strategy aims to minimize the power consumption of each SCeNB in
the cluster, since the power consumptions of the individual SCeNBs is highly imbalanced
in the second strategy.
Cluster Allocation in MEC
• Cluster allocation refers to the process of assigning cluster of SCeNBs to UEs.
• In multi UEs scenarios, whenever the UE is about to offload data for the computation, the
computing cluster is assigned to it.
• Consequently, each UE has assigned different cluster size depending on the application

EL
and the UE’s requirements.
• The main objective in this case is to minimize the power consumption of the clusters
while guaranteeing required execution delay for each UE.

PT
• Some Cluster Allocation strategies include:
• Successive cluster optimization: The main objective of successive cluster optimization is
to improve the performance of the MEC system by dynamically adjusting the cluster size

applications.
N
and resource allocation based on the changing workload and QoS requirements of the

• In the successive cluster optimization process, the MEC system can split a cluster into
smaller clusters if the cluster is becoming overloaded, or merge smaller clusters into a
larger cluster if the clusters are underutilized. This adjustment of the cluster size allows
the MEC system to allocate resources more efficiently among the clusters.
Cluster Allocation in MEC
• Joint cluster optimization : The core idea is to jointly compute clusters for all active
users’ requests simultaneously to being able efficiently distribute computation and
communication resources among the UEs and to achieve higher QoE.
• The main objective in this case is to minimize the power consumption of the clusters
while guaranteeing required execution delay for each UE.

EL
• Static clustering : In static clustering approach, once the clusters are formed, the
allocation of resources among the clusters remains static and does not change based on

PT
the changing workload and QoS requirements of the applications.
• Usually, the resources are divided equally among all SCeNBs.

N
• Static clustering has the advantage of simplicity and ease of implementation. However, it
may not be suitable for MEC systems with highly dynamic workloads and QoS
requirements, as the static allocation of resources may result in underutilization or
overutilization of resources.
 EL
Thank You!

PT
N
References
1. Saeik, F., Avgeris, M., Spatharakis, D., Santi, N., Dechouniotis, D., Violos, J. & Papavassiliou, S. (2021). Task
offloading in Edge and Cloud Computing: A survey on mathematical, artificial intelligence and control theory
solutions. Computer Networks, 195, 108177.
2. Wang, B., Wang, C., Huang, W., Song, Y., & Qin, X. (2020). A survey and taxonomy on task offloading for edge-
cloud computing. IEEE Access, 8, 186080-186101.
3. S. Li, Y. Tao, X. Qin, L. Liu, Z. Zhang and P. Zhang, "Energy-Aware Mobile Edge Computation Offloading for IoT Over
Heterogeneous Networks," in IEEE Access, vol. 7, pp. 13092-13105, 2019, doi: 10.1109/ACCESS.2019.2893118.

EL
4. https://ieeexplore.ieee.org/document/9253665
Tang, M., & Wong, V. W. (2020). Deep reinforcement learning for task offloading in mobile edge computing
systems. IEEE Transactions on Mobile Computing, 21(6), 1985-1997.
5. https://www.mdpi.com/1999-5903/14/2/30

PT
Tu, Y.; Chen, H.; Yan, L.; Zhou, X. Task Offloading Based on LSTM Prediction and Deep Reinforcement Learning for
Efficient Edge Computing in IoT. Future Internet 2022, 14, 30. https://doi.org/10.3390/fi14020030
6. Luo, Q., Hu, S., Li, C., Li, G., & Shi, W. (2021). Resource scheduling in edge computing: A survey. IEEE
Communications Surveys & Tutorials, 23(4), 2131-2165.
7.
8. N
Yang S, Lee G, Huang L. Deep Learning-Based Dynamic Computation Task Offloading for Mobile Edge Computing
Networks. Sensors. 2022; 22(11):4088. https://doi.org/10.3390/s22114088
Fog and Edge Computing - Principles and Paradigms, Rajkumar Buyya and Satish Narayana Srirama, Wiley Series
On Parallel and Distributed Computing