the BBU pool [39]. Fog computing solutions can be exploited not only by the mobile operators but also by the private networks. For this reason, OpenFog consortium [72] has been formed to address the various challenges within fog computing and to provide solutions for deploying private and public fog computing systems. 1.2.2.2 Cloud-Edge 5G RAN Based on O-RAN and 3GPP Similar to the architectural framework proposed in [25] and adopted for C-RAN in [3] and [26], O-RAN alliance [42] decouples the NG-RAN into O-CU, O-DU, and O-RU. O-RAN provides an AI/ML-based architecture that aims to provide flexible, agile, automated, and optimized 5G network. As depicted in Fig. 1.5, O- RAN architecture is composed of O-Cloud, service management and orchestration (SMO), non-real-time RAN intelligent controller (Non-RT RIC), near-real-time RIC (Near-RT RIC), O-CU, O-DU, and O-RU. 3GPP in [24] defines the CU or O-CU as a logical node that operates the gNB functions and controls the operations of the DU or O-DU. Meanwhile, the Near-RT RIC hosts xApps and is responsible for the low latency processing, i.e., 10 ms to 1 S, as well as it monitors and controls the O-RAN nodes. In addition, O-RAN architecture defines the SMO entity that contains the Non-RT RIC. The role of the Non-RT RIC is to perform data analytics and AI/ML training that demands processing higher than 1 S [2]. O-RAN provides O1, A1, and E2 interfaces in order to enable intelligent processing and control of the traffic routing. The 01 interface collects data from O-CUs and O-DUs for the ML models in Non-RT RIC. In addition, A1 and E2 interfaces optimize the quality of experience (QoE) based on AI models [2, 42]. The open-fronthaul M-plane interface between the O-RU and the O-DU is defined by O-RAN alliance. Meanwhile, the interface F1 between the O-DU and O-CU and the interface NG between the O-CU and the 5GC are defined by 3GPP. However, the interface between the SMO and the 5GC has not been defined and out of the scope of O-RAN. The entities of O-RAN architecture, such