# Comparative Analysis of 5G Mobile Communication Network Architectures
## 2 Previous Works
The M-CORD is a network architecture that utilizes the service orchestration platform called XOS to link the distributed and virtualized base stations to the core network, while allocating centrally located computing resources to each individual edge cloud. Through utilization of this architecture, sharing of computing resource between individual edge clouds is possible, and the edge cloud overload problem can be addressed. [PERSON] et al. [20] defined the MEC architecture as a multiple layer system consisting of terminal edge cloud, and core layers. They proposed a methodology for optimizing computing resources and minimizing delay time through best allocation of computing resources and traffic to nodes in each layer. [PERSON] and [PERSON] [21] divided an MEC architecture into three different layers and implemented an auction-based optimization algorithm to obtain minimum cost for the network. Recently, new methodologies have been proposed for optimizing offloading tasks between clouds. Table 1 lists the recent works in this area. [PERSON] et al. [22] proposed a model for horizontal offloading between autonomous vehicles and road infrastructure, and optimized for latency using a heuristic algorithm. [PERSON] et al. [8] assumed a vertical offloading model for edge and cloud, and optimized for latency using convex optimization. [PERSON] et al. [23] proposed a cooperation model between edge and cloud for video analytics based on Internet of Things (IoT). They defined the optimization as a mixed integer problem and applied the heuristic algorithm to optimize the cost required for cloud operation. [PERSON] et al. [24] employed a vehicle network comprising edge and cloud, and tried to optimize cloud utilization using convex \begin{table}
\begin{tabular}{l c c c c c} \hline \hline
**Previous Research** & **Multi-Tiered** & **Offloading** & **Optimization Objectives** & **Optimization Methodology** & **Queuing Status Sharing** \\ \hline [PERSON] et al. [22] & No & Horizontal & Latency & Heuristic & No \\ [PERSON] et al. [8] & Yes & Vertical & Latency & Convex & No \\ [PERSON] et al. [23] & Yes & Vertical & Cost & Heuristic & No \\ [PERSON] et al. [24] & Yes & Vertical & Utilization & Convex & No \\ [PERSON] et al. [25] & Yes & Vertical & Profit & Convex & No \\ [PERSON] et al. [26] & Yes & Vertical & Profit & Convex & No \\ [PERSON] et al. [27] & Yes & Vertical & Latency & Heuristic & No \\ [PERSON] et al. [28] & Yes & Vertical and Horizontal & Cost & Approximation & No \\ \hline \hline \end{tabular}
\end{table} 
Table 1: Published works on offloading optimization between clouds. optimization. [PERSON] et al. [25; 26] used whole-sale and buy-back models between edge and cloud to share computing resources, and optimized the profit from the edge's perspective. [PERSON] et al. [27] assumed an energy management infrastructure as a cloud model comprising three tiers, and optimized for latency using joint optimization between Stackelberg and Lyapunov-based pricing and energy demand. [PERSON] et al. [28] proposed vertical and horizontal offloading models between edge to cloud and edge to edge, and used an approximation algorithm to minimize the cost. Surveying previous works revealed several research gaps that can be addressed. Several papers proposed new frameworks for offloading between user terminals and the cloud and they established foundations for future MEC architecture related research. However, the limitation of their works is that their main direction was focused on the design of the system's functional elements, and they did not propose ways to optimize offloading under various operating conditions. Moreover, the single layer offloading methodology is another research area on which the majority of research has been published. However, the single layer offloading methodology exhibits limitations in addressing the MEC architecture's issues of computing resource shortage, work overload and quality degradation resulting from local traffic spike.