## 3 System Architecture
### Architecture  
The Private/Local Telecom Operator has an important role in driving local service and providing critical application services. Figure 3 shows the entire system architecture that makes the above concept feasible. In this figure, there is a Private/Local Telecom Operator, a Legacy Telecom Operator, a Cloud Owner, and an MEC/Cloud Orchestrator. Based on the application requirement (e.g., minimization of latency, minimization of CAPEX/OPEX) and the traffic requirements of the end user, the MEC/Cloud Orchestrator can automatically deploy the application for both MEC provided by the private/local  
Figure 2: Overview of concept proposal for Private/Local Telecom Operator.  
operator and cloud resources/platform provided by the Cloud Owner. With the above logic, it is possible to control the traffic generated by the end-user and obtain benefits such as traffic reduction, suppression of network congestion, and high security [62; 63]. In addition, from the end user's perspective, the application throughput in MEC is faster than during regular use on the cloud, which improves QoS/QoE. The network shared with end users must be recognized as a personal space network (individual slicing of shared resources). Here, the difference between the proposed architecture and MEC provided by the conventional telecommunications operators (Legacy Telecom Operator) is that it is a local business that holds physical resources (locations) where edge computing such as MEC can operate closer to the user while offering free utilization space for Commercial Off-The-Shelf (COTS) servers. Furthermore, the Private/Local Telecom Operator provides end user data and supports control data via the Legacy Telecom Operator. In other words, the Legacy Telecom Operator provides a stable RAN service from the perspective of coverage, and the Private/Local Telecom Operator provides the Application service for hotspots and local points. Therefore, the difference is that the network is closed to end users in terms of local secure data and assurance of latency.  
Figure 4 shows a network configuration diagram of the Private/Local Telecom Operator network in the above architecture. This figure focuses only on the Private/Local Telecom Operator network. First, installation of a Radio Unit (RU) can support higher-frequency bands (e.g., Sub6/mmWave) with a local RAN network in order to accommodate as much traffic as user plane data in a hotspot. XR/AR/VR/UAV, C-V2X, Robotics, IoT, etc., are examples of terminal devices that connect to the control/user plane. The RU is connected to the virtualized Distributed Unit (DU) pool via the fronthaul. The vDU is connected to the virtualized Centralized Unit (CU) pool via the F1 interface in the midhaul. Here, vCUs are classified into vCU-CP with a control plane and vCU-UP with a user plane, and they are deployed in the same/different place, respectively. Packets GTP encapsulated by CU-UP are GTP decapsulated in MECs that hold the UPF function. MEC analyzes the destination information in the packet and refers to the registry information and whether it is operating as MEC Apps. If there is a target MEC Apps, the traffic is passed to MEC Apps at the TCP/IP layer; if not, it is encapsulated again by GTP, and the traffic is passed to the mobile network again. Meanwhile, vCU-CP requests the X2 interface in 4G BBU to receive RU support for a wide area. Here, as an example, we request a 4G BBU to anchor via the X2 interface. As a result, terminal devices can use C-Plane and U-Plane, setup Protocol Data Unit (PDU) sessions, and receive services.  
Figure 3: Illustration of the system architecture of an MEC/Cloud Orchestrator for a Private/Local Telecom Operator and Cloud Co-operation.