Open-Source-Defined Multi-Access Edge Computing for 6G: Opportunities and Challenges

Multi-access edge computing (MEC) is capable of meeting the challenging requirements of next-generation networks, e.g., 6G, as a benefit of providing computing and caching capabilities in the close proximity of the users. However, the traditional MEC architecture relies on specialized hardware and its bespoke software functions are closely integrated with the hardware, hence it is too rigid for supporting the rapidly evolving scenarios in the face of the demanding requirements of 6G. As a remedy, we conceive the compelling concept of open-source-defined cellular networking and intrinsically amalgamate it with MEC, which is defined by open-source software running on general-purpose hardware platforms. Specifically, an open-source-defined MEC (OpenMEC) scheme is presented relying on a pair of core principles: the decoupling of the MEC functions and resources from each other with the aid of network function virtualization (NFV); as well as the reconfiguration of the disaggregated MEC functions and resources into customized edge instances. This philosophy allows operators to adaptively customize their users’ networks. Then, we develop improved networking functions for OpenMEC decoupling and discuss both its key components as well as the process of OpenMEC reconfiguration. The typical use cases of the proposed OpenMEC scheme are characterized with the aid of a small-scale test network. Finally, we discuss some of the potential open-source-related technical challenges when facing 6G.


I. INTRODUCTION
B Y integrating communication and information technologies, multi-access edge computing (MEC) [1]- [3] intrinsically amalgamates the computing and caching capabilities in the immediate proximity of the users, which reduces the transmission delay and improves the resource utilization at the edge. As a further benefit, the emergence of MEC alleviates both the potential data transmission congestion of the transport network (TN) as well as the data processing burden imposed on the core network (CN). Therefore, in December 2014, the European telecommunications standards institute (ETSI) has initiated MEC standardization for continuously updating and improving the MEC reference architecture and its applications [4]. Many operators and vendors provide a convenient computing and caching environment at the edge by relying on ETSI's MEC architecture [5]- [7].
With the continual growth of the mobile Internet traffic, next-generation networks are expected to operate at rates up to Tbps and delays lower than 1ms [8]- [10]. MEC is considered as a potential enabling technology of the sixth generation (6G), capable of satisfying enhanced service requirements [11]. For example, MEC can guarantee ultra-low transmission delay and satisfy flawless 4k/8k video broadcast by processing computation-intensive data or caching ultra-high-definition (UHD) videos at the edge [12], [13]. However, the exiting MEC reference architecture is built upon specialized hardware and its software functions are closely integrated with the hardware, which is inconvenient in the face of rapidly evolving scenarios, when aiming for satisfying the demanding requirements of 6G. As a remedy, the above challenges may be met by introducing the opensource-defined (OSD) cellular network concept into MEC for allowing operators to adaptively customize their users' networks.
Open-source software [14] has a very long history, which can be traced back to the organizations of SHARE and DECUS in 1950s. In the following years, ARPANET, UNIX, Linux and Android were developed for altruistic public sharing. By contrast, OSD cellular networks are still in their infancy, despite the associated benefits. Explicitly, in the OSD cellular network, an open infrastructure would enable flexible network reconfiguration based on the specific requirements of diverse scenarios, and open source software would enable users to develop the future network in a collaborative openaccess manner. Such an OSD cellular network has to rely on the integration of 6G candidate technologies, such as network function virtualization (NFV) [15], software-defined networking (SDN) [16], network slicing [17] and MEC [18], etc. Among them, SDN/NFV serve as the core drivers, which should additionally be integrated with MEC for cell-edge performance enhancement in support of customized radio access networks (RANs).
Substantial efforts have been invested in promoting the progress of OSD networks [19]. The Open-Air-Interface (OAI) community founded in Europe exploited a fullyfledged fourth generation (4G) protocol stack based on commercial off-the-shelf (COTS) hardware. As a further advance, the Open5G community founded in China developed the concepts, technologies and platforms of open source fifth generation (5G). The O-RAN alliance [20] founded by the global industry supported by academics has endeavoured to evolve RANs around the world. Additionally, the Linux Foundation (LF) launched the open network automation platform (ONAP) for orchestration. As for virtualization, the open platform of NFV (OPNFV) was conceived. Recently, there have also been a few open source efforts on MEC [21]. For example, the Akraino project built by LF offers a pair of blueprints, namely the 5G MEC/slice and the micro-MEC system, but unfortunately it remains focused on the virtualization layer of the MEC reference architecture. Based on all these efforts, we present a new paradigm for developing an all-encompassing open-source-defined MEC (OpenMEC) scheme.
The contributions of this paper are summarized as follows.
1) Using ETSI's MEC architecture as a springboard, this paper introduces an OpenMEC framework to facilitate customized services for any potential scenario in 6G network, which is built on a pair of key principles, namely on network decoupling and reconfiguration. 2) With reference to the service-based architecture (SBA) of the 5G core network (5GC) [22], a service-based MEC layer is developed for the OpenMEC scheme for decomposing the tightly coupled service functions into multiple independent network functions (NFs), thereby achieving MEC decoupling. 3) In order to integrate these decoupled NFs as required and to reconfigure a MEC system, the concept of templates and instances is implemented as part of the NF's management and orchestration (MANO) scheme, eventually generating a customized entity for supporting complete services. 4) Several typical use cases are demonstrated based on our test network for validating its flexibility and customization. Our novel contributions are also contrasted at a glance boldly and explicitly to the state-of-the-art in Table 1.
The rest of this paper is organized as follows. We first introduce the basic concepts and key technologies of OSD cellular networks in Section II. In Section III, we present our OpenMEC framework, its service-based MEC layer, interface, and the NF's MANO. In Section IV, our smallscale test network, our use cases and our demonstrations are presented. In Section V, we elaborate on some potential technical challenges. Finally, we conclude in Section VI.

II. THE OPEN-SOURCE-DEFINED NETWORK
In this section, our vision of an OSD cellular network relies on four key elements: the cloud domain including CN; the edge domain including distributed MEC servers; the heterogeneous terminal domain; and the network domain connecting the cloud-edge-terminal domain, which includes a RAN linking the edge and terminal domains, and a transport network linking the cloud and edge domains, as shown in Fig. 1.
In the cloud domain, the OSD CN architecture has been well documented. For example, SBA has been identified as a basic element of the 5GC architecture in the 3rd Generation Partnership Project's (3GPP) standards, which exhibits a high grade of flexibility and scalability. In SBA, the originally coupled network functions are partitioned into multiple independent functional blocks, where each of them provides one or more services that can be used by any of the other functional blocks. Therefore, all functional blocks can communicate with each other in order to support the users with customized applications, as if they were connected to a service bus. In the edge domain, the OpenMEC concept will be discussed in the next section. However, in the network domain, the OSD RAN architecture has not as yet been defined, because it is hampered by its increased real-time complexity requirement. To achieve this, some promising solutions, such as RAN decoupling and reconfiguration, have been put forward. Firstly, the tightly coupled RAN elements, functions and resources of conventional networks have to be completely split. Then, they could be reassembled dynamically according to a user's requirements, thus providing customized virtual RANs. In a nutshell, the OSD concept facilitates a convenient LEGOblock based construction of 6G RANs. Open5G [25] O-RAN [20], [26] ONAP [27] OPNFV [28] ETSI's MEC [4] Akraino [21] SDEC [29] NDN-ECC [30] Proposed

A. RAN DECOUPLING
The tightly coupled 4G cellular networks rely on a rigid closed operating system. Hence at least four different RAN decoupling methods have been conceived for orchestrating a beneficial degree of openness in 6G, namely hardware/software decoupling (HSDe) [31], control plane and user plane splitting (CUPS) [32], central unit and distributed unit splitting (CDUS) [33], as well as downlink and uplink decoupling (DUDe) [34]. Since they have different pros and cons, there is no wide agreement concerning the best OSD RAN architecture. It is worth noting that HSDe and CUPS constitute the basis of OSD cellular networks, while CDUS and DUDe further exploit the flexibility and openness of cellular networks. HSDe decouples the resources and functions from the physical facilities. Given the mature family of NFV technologies, the network resources can be abstracted and shared among different users, and diverse services can be supported by the same infrastructure, thus separating the functionalities from the underlying infrastructure.
The idea of CUPS stems from SDN, which decouples the control signaling from the data transmission. Then, it further expands to cellular networks by deploying control base stations (CBSs) in the most friendly lower frequency band and data base stations (DBSs) in higher frequency bands to form the control plane (CP) and user plane (UP), respectively. CDUS represents one of the key technologies for the next-generation cloud RAN, which focuses on separating the traditional evolved node base station (eNB) into the radio transceiver (distributed unit) and the logical center (central unit) from the perspective of the OSD protocol stack.
The tightly coupled downlink (DL) and uplink (UL) transmission limits the flexibility of a user's connections. Upon adopting DUDe via dual-connectivity, where a user connects to a macro base station (MBS) and a small base station (SBS) for its DL and UL delivery respectively, flexible user association and high energy efficiency can be achieved.

B. RAN RECONFIGURATION
Upon using RAN decoupling technologies, conventional RANs have been softwarized and split into independent virtual NFs. Then, to support diverse application (APPs), only the necessary decoupled NFs will be chosen and assembled to construct RANs on a demand basis. For reconfiguring 6G RAN efficiently, there have been at least two possible solutions, namely RAN slicing and MANO.
RAN slicing [17] allows the virtual NFs and radio resources in RAN to be dynamically allocated to various services. Explicitly, when a specific service request arrives, RAN slicing selects the necessary NFs using the resources allocated, and then encapsulates them to form a customized virtual network.
MANO is also an effective technique of achieving RAN configuration, and it can be applied more flexibly to different network scopes than RAN slicing. Among them, the management part is responsible for the overall monitoring of RANs, including life cycle management, fault detection, accounting and security monitoring [35]. The orchestration part [36] supports the NFs and uses the underlying resources for VOLUME 4, 2016 reassembling the RAN, which mainly includes two sub-parts: choosing the appropriate NFs and appropriately scheduling them for a certain service.

C. RAN CAPABILITY ENHANCEMENT
MEC supports local computing and storage resources, which can be integrated with the open RAN both for providing the users with low-latency services and for reducing the transport network's burden [37]. Although the OSD RAN architecture has not as yet been defined, an OpenMEC scheme will be established and detailed in our paper, which relies on the above decoupling and reconfiguration technologies.
Furthermore, 6G will have an ever increasing complexity in support of its compelling applications, heterogeneous networking architecture, and diverse resources. Hence the conventional network management methods (i.e., deployment, resource allocation and operation) associated with humancontrolled philosophies will become inadequate, calling for sophisticated artificial intelligence (AI) techniques [9] in the RAN, for achieving self-organizing, automated operation and CapEx/OpEx savings.

III. THE OPEN-SOURCE-DEFINED MEC
In this section, we incorporate the fundamental concepts of OSD networks into MEC by relying on decoupling and reconfiguration, and propose the OpenMEC concept for improving the openness and flexibility of the emerging MEC systems. Explicitly, by developing a service-based MEC layer, we decompose the tightly coupled service functions into multiple independent NFs and support them flexibly using a simple service-based interface (SBI). Next, by introducing the convenient template and instance concept, NF's MANO is proposed for reconfiguring MEC, in which the OpenMEC's templates are predefined and then instantiated when needed.

A. OPENMEC FRAMEWORK
The OpenMEC framework conceived is shown in Fig. 2. The entire framework includes the application plane and MANO plane, where the former is mainly responsible for data processing and transmission, involving the infrastructure layer, virtualization layer, service-based MEC layer, and application layer from bottom to top. By contrast, the latter is composed of the virtualized infrastructure manager (VIM) and MANO, which completes the coordination and resource management of the OpenMEC system. The pair of adjacent layers communicate with each other through standard interfaces and cooperate for completing the MEC services requested by users.
As seen in Fig. 2, the infrastructure layer is at the lowest level, covering all computing, caching and communication resources of the system. Specifically, the central processing unit (CPU) provides high-performance computing power for the service-based MEC layer right below the application layer at the top of The communications resources of this layer include the bandwidth as well as the eNB, next-generation node base station (gNB) and access point (AP), as shown in the bottom layer of Fig. 2.
At the virtualization layer of Fig. 2, based on the NFV concept, the underlying three-dimensional resources may be decoupled from the dedicated hardware and abstracted into a resource pool that could be shared by various NFs at the service-based MEC layer of Fig. 2. Then, OpenMEC creates multiple Docker containers or virtual machines (VMs), which are run on the underlying resource pool and could simultaneously support different NFs for providing customized services [38], as seen at the virtualization layer of Fig. 2.
The service-based MEC layer of Fig. 2 constitutes the core part of OpenMEC, which includes a unified SBI and diverse NFs, where the SBI can connect these NFs together based on the unified stateless hypertext transfer protocol (HTTP) for ensuring that they can communicate directly with each other when needed. Furthermore, we decouple the originally centralized service functions into independent NFs. Specifically, the user plane function (UPF) of the service-based MEC layer in Fig. 2 is borrowed from 5GC for OpenMEC, in order to lend the 5G new radio (NR) capabilities to OpenMEC. Subsequently, to enhance OpenMEC, we download several other NFs at the control plane of 5GC and develop several new NFs. These NFs are transparent to each other and can also be combined at will, so that they could be activated and released by all users instantly in support of their customized services.
Actually, the user does not have to rely on the specific details of OpenMEC. Instead, they will use various APPs at the application layer to gain access to customized services. For simplicity, only two APPs are considered in this paper for processing caching and computing requests, respectively, i.e., the high throughput and the intensive computation scenarios of the application layer seen at the top of Fig. 2.
Additionally, the MANO plane at the right of Fig. 2  Since there is rich literature on the design and implementation of both the virtualization layer and on the infrastructure layer [4], [21], [24], [25], [28]- [30], we mainly consider the service-based MEC layer and the MANO plane of Open-MEC.

B. MEC DECOUPLING
In order to decouple the MEC functions, we conceive the service-based MEC layer of the OpenMEC framework, which evolved from the traditional MEC layer, mainly composed of the SBI and the service-oriented NFs. We extract the service-based MEC layer from Fig. 2, and portray its detailed structure in Fig. 3.
The SBI connects all the NFs together for facilitating their interface programming and implementation. The northbound interface (NBI) is an application program interface (API) provided for the application layer to interact with the service-based MEC Layer in order to obtain services. The east-bound interface (EBI) is an API for NF's MANO to interact with the service-based MEC Layer, which is mainly used to manage and orchestrate both the resource allocation and life cycle of NFs. On the basis of using the same HTTP, we design a unified Representational State Transferful (RESTful) [23] API for the SBI, NBI and EBI, which is lightweight and can be read both by people and machines easily. Thus, the service-based MEC layer provides direct communications between the NFs, the MANO and the NFs, as well as the NFs and APPs, thereby reducing the interfacecomplexity and the protocol-inconsistency in the traditional MEC architecture [18].
In this paper, all service-oriented NFs are independently deployed in the Docker containers mentioned in Fig. 2 in order to become virtualized. There are six basic NFs in our proposed OpenMEC of Fig. 3. Specifically, the MEC NFs learned from 5GC include the unified data management (UDM), the NF repository function (NRF) and UPF seen in Fig. 3. Furthermore, the communication protocol conversion function (CPCF), the service registry function (SRF) and the application selection function (ASF) of Fig. 3 are newly developed after considering the context of OpenMEC. Below we briefly describe the functional differences of UDM and NRF applied both in OpenMEC as well as 5GC, followed by the portrayal of our proposed CPCF, SRF and ASF of Fig. 3.
• UDM is used for unified data storage and management.
In contrast to the 5GC UDM, the OpenMEC UDM does not have to deal with the issue of data structure compatibility because of its semi-homogeneous data. It mainly manages the data through the MySQL database management system [39], and implements data insertion, search, update and deletion in the data tables of specific services. OpenMEC UDM can also provide standardized interfaces for SRF and ASF to ensure flexible access and real-time data update. • NRF is a repository provided for centralized storing of NFs. OpenMEC further decouples the 5GC NRF, thus the OpenMEC NRF is only responsible for the storage of NFs and APPs, while the service registration is repackaged as SRF, and the service discovery is integrated into MANO. Due to the limited edge resources, general NFs (including SRF, CPCF, UDM and NRF) use local storage, while dedicated NFs, e.g., ASF and APPs are stored in the remote image repository. As for the latter, the OpenMEC server will rely on specific NF and APP images to provide services only when needed. • CPCF can complete the communication protocol conversion. In the OpenMEC system, the stateless HTTP is mainly used for data exchange between NFs. However, the protocols of users requesting edge services are heterogeneous, so CPCF has to analyze and re-encapsulate them into a unified HTTP protocol for supporting compatibility of the system.  APPs and for communication between APPs and the other basic NFs.
The NF's MANO of Fig. 3 can flexibly schedule the NFs according to the specific service types, since the unified HTTP is used as EBI between the service-based MEC layer and NF's MANO, and is also used as SBI in the servicebased MEC layer. With all the NFs deployed in the Docker containers in our solution, Kubernetes [40], the open-source implementation of the container cluster management, is advocated for centrally managing all the Docker containers playing the role of MANO. Its specific architecture will be introduced in the next subsection.
Based on the above NFs, we are ready for characterizing the basic functionalities of OpenMEC. Hence anyone could develop his/her own NFs for supporting new applications.

C. MEC RECONFIGURATION
As the MEC management is not directly related to the reconfiguration of OpenMEC, the joint management of MEC and NFV proposed by ETSI can still be used in OpenMEC, albeit the conception of service-based MEC layers is bound to impose challenges on the orchestration scheme. Therefore, by means of Kubernetes, we present OpenMEC's templates and instances of NF's MANO, which supports the flexible scheduling of NFs, and any further MEC reconfiguration. More explicitly, some templates are pre-defined for the corresponding applications, as exemplified by a computationintensive template. However, when no user asks for this application, we do not allocate the related resources to the template, hence, the template is empty. By contrast, as shown in Fig. 4, if a user requests this application, we shall activate the template by assigning computing, caching and communication resources as an instantiation.

1) NF's MANO
A detailed view of the NF's MANO extracted from Fig. 2 is shown in the middle (blue) part of Fig. 4, where the right side represents the predefinition and selection of templates, while the left side represents the templates' instantiation based upon Kubernetes [40], which is a container-based cluster management platform. The VIM seen at the bottom right of Fig. 4 is used for scheduling the underlying resource pool to arrange for the immediate resource deployment for instantiation, so as to avoid the assignment of excessive resources. Fig. 4 that there is always a main node and either one or several secondary nodes in Kubernetes, where the former is in charge of managing Kubernetes, while the latter is in charge of the orchestration of NFs. In a slave node, there are two basic components dedicated to instantiation in NF's MANO, namely Pod and Kubelet as seen in Fig. 4. As defined in [40], Pod is the smallest unit of deploying and monitoring NFs in Kubernetes, which can run several Docker containers simultaneously. Kubelet [40] of Fig. 4 maintains the life cycle of Pods and the communication between the master and the slave nodes. In the master node, there are three basic components, namely the scheduler, controller and API server. The API server provides the only entry for slave nodes to the application layer, i.e., Pods communicate with the given templates selected by the user through the API server for implementing MEC reconfiguration. The Scheduler and Controller of Fig. 4 manage and monitor all slave nodes, e.g., for fault detection. Moreover, there is a Kubernetes' data center represented by Etcd of Fig. 4 for storing the states of the above components.

Observe in
The template seen close to the right of Fig. 4 is provided for extracting the common characteristics of a class of problems. Given this idea, a static OpenMEC template is predefined, e.g., for selecting appropriate NFs and for predefining the related parameters according to the specific type of APPs. Again, we consider two APPs, namely high throughput and intensive computation, as seen at the right of Fig. 4. These are examples of describing the OpenMEC templates, where the former is provided for high-throughput multimedia video services, while the latter is mainly for computing intensive services. Naturally, there are some differences between the two templates in terms of the NFs selection and data table definition in UDM, as detailed in Fig. 5.
Explicitly, observe in Fig. 5 that the OpenMEC template is composed of three tiers, including Managed NFs, Attributes and Actions. In this context, all NFs have to communicate directly with the Managed NFs at the top layer, which are responsible for monitoring the templates' status and orchestrating NFs. The middle-layer of Fig. 5 representing the Attributes acts as the database of templates, where the associated parameters are stored in the UDM's data tables. Finally, the underlying Actions seen at the bottom of Fig. 5 are provided for completing a range of customized functions by selecting appropriate NFs as well as APPs and for updating the predefined UDM parameters in real time.
We partition the computation-intensive and the highthroughput templates into the shared parts (overlap of the templates in Fig. 5) and the dedicated non-overlapping parts of each. The shared part is irrelevant for the APPs, it essentially ensures the normal operation of the system, while the dedicated template is the key for supporting OpenMEC in providing specific services for the corresponding APP. For example, both the computation-intensive and the highthroughput templates have to complete service registration provided by SRF, protocol conversion completed by CPCF and data updates by UDM. However, the dedicated ASF and APP of the computation-intensive template are responsible for completing the computations based on the source-data, as seen at the bottom left of Fig. 5 and for setting up a charging function. By contrast, the dedicated ASF and APP of the high-throughput template process video caching and analyze the video popularity, as observed at the bottom right of Fig. 5.

3) OpenMEC Instance
The OpenMEC template of Fig. 5 cannot directly provide services and we do not allocate the related resources for the template. As a result, users can only gain access to the edge services through instances. The instantiation determines whether the OpenMEC system can run stably, which is the key for reconfiguring MEC.
The instantiation process mainly includes the following three steps. Firstly, when a user requests edge services, such as intensive computation and high throughput, the MANO of Fig. 4   the API Server of Fig. 4 locates the idle Pod and updates the relevant information to Etcd of Fig. 4, which provides basic environmental support for instantiation. Secondly, the MANO of Fig. 4 schedules VIM for allocating the specified virtual computing, caching and communication resources to users. Finally, under the specifically configured operating environment and the resources allocated, MANO actually runs the predefined NFs and APPs of the template, i.e., Kubelet runs the Pod that specifically deploys NFs and APPs. Therefore, the dedicated MEC instance has been created. In Fig. 6, we summarize the workflow of OpenMEC, commencing from the instant when a user sends a service request until the edge service is instantiated. Specifically, 1) when a user sends a service request to the OpenMEC, such as the intensive computation service request, CPCF firstly actions the protocol identification. 2) Upon receiving a HTTP request, CPCF does not need to perform the protocol conversion; otherwise, it reencapsulates the service request using HTTP. following three steps: the environmental configuration, resource allocation, and NF activation and APP activation. 5) Finally, OpenMEC provides a computation-intensive edge service to the user in the form of APP by the service interface. At this point, we have succeeded in creating the OpenMEC scheme by completing the MEC decoupling and reconfiguration.

IV. DEMONSTRATION IN TEST NETWORK
In this section, we critically appraise the proposed OpenMEC scheme in the test network deployed at Xidian University and then characterize a pair of use cases, namely the intensive computation and the high throughput scenarios. Our test network is shown in Fig. 7. A 3GPP R10 based cellular network including an evolved packet core (EPC) and six eNBs was built based on open source software provided by OAI [41] and general-purpose hardware, namely an Intel Core i7-7700@3.6GHz CPU and 16 GB random access memory (RAM). A commercial wireless router was used as an AP to deploy a WiFi network, which can support multiple access. Then, we deploy all the network elements in Docker containers to arrange for them to become virtualized, yielding a virtualized EPC (vEPC) and virtual NFs (vNFs). Subsequently, the user plane of both the serving gateway (SGW) and of the packet data network gateway (PGW) is moved from vEPC into the OpenMEC server using an Intel Core i7-7567U@3.5GHz CPU and 32 GB RAM. The control plane, i.e. the home subscriber server (HSS) and the mobility management entity (MME), remains in the vEPC. Finally, based on Kubernetes, NF's MANO including its templates and instances is implemented to furnish users with customized services.
For instance, in the high throughput use case providing a video caching service, the user firstly accesses the test network of Fig. 7 by selecting an appropriate access mode, e.g., eNB. Then, the network has to confirm, whether the requested video is stored in the OpenMEC server. If so, the high throughput service may indeed be directly completed in the OpenMEC server by the specific workflow seen in Fig. 6. By contrast, if the requested video cannot be found in the OpenMEC server, then the vSGW and vPGW in the OpenMEC server will connect to the cloud server of the campus network through the switch to access the required resources.
In the intensive computation use case, we provide three services, i.e. sum and prime sum computation as well as face recognition. These three services are requested in three independent instances respectively, which are created by the same computation-intensive template though. Therefore, three containers have to be started for the above instances, respectively. By contrast, in the high throughput use case providing a video caching service, a user watches his/her video cached at the OpenMEC server, which only creates a single instance and runs a single container. Fig. 8 shows a histogram for 1000 experiments for characterizing the resultant instantiation time-duration both in the proposed Kubernetes method and in the traditional script running method used in [41], where we simultaneously support  three computation-intensive services to test the instantiation performance. For both applications, the average instantiation duration of Kubernetes is always lower than that of the traditional script, because the Kubernetes method can run multiple containers in parallel, while the traditional method only runs them separately through scripts. Moreover, the intensive computation APP takes a little longer to instantiate, because it starts three containers at the same time, while the high throughput APP only runs a single container. However, when using our Kubernetes method, their difference in time duration is small. This allows the operators to easily incorporate new NFs or services as and when needed without degrading the user experience.
To provide further insights, Fig. 9 portrays the comparison of the computing time of three computation-intensive services by a histogram for 1000 experiments. Since each picture has to be transmitted from mobile phones to the OpenMEC server and processed by the file transfer protocol (FTP), the average computing time of face recognition is higher than that of the other two services.  Since much more data have to be processed during face recognition, the CPU load of face recognition is about four times higher than that of prime sum computations. The face recognition also has to store more data than the prime sum computation, so it requires more memory in Fig. 10(b) (83.9MB). Then, whenever the network completes data processing, the CPU is freed up immediately and the computing resources are released. By contrast, the memory will not be freed up unless we handle it manually. For example, as seen in Fig. 10(a), the CPU is released immediately once the prime sum service is completed at 9:20:28. However, in Fig. 10(b), the memory remained reserved, until we released it manually at 9:20:30. Therefore, the limited edge computing and caching resources of OpenMEC are used flexibly and efficiently. Fig. 11 quantifies the transmission and computing time of the high-throughput service, in which different-length videos are cached at the edge or cloud. Upon increasing the videolength, we can see that the gap of the transmission time between the cloud and the OpenMEC scheme gradually increases, which shows that the advantage of our proposed scheme is gradually enhanced. Since the computation loads of the high-throughput service are limited, the computing time of both the cloud and of the edge is only about 0.14s on average, and their difference is small. Furthermore, the increase of video size has little effect on the computing time, which is basically in a stable state.

V. TECHNICAL CHALLENGES
As mentioned above, the rapidly evolving scenarios and requirements of the 6G network provides a compelling opportunity for introducing the OSD cellular network concept into MEC, which allows the operators to adaptively customize the users' networks at the edge based on the proposed OpenMEC philosophy. Our solutions have the potential of influencing the standardization of the MEC architecture for next-generation networks. However, there are still some open technical challenges in the research of 6G-oriented OSD cellular networks having a MEC functionality, which need further research and global discussion.

A. CLOUD-NETWORK-EDGE-TERMINAL COLLABORATIVE OSD CELLULAR NETWORK
In recent years, substantial progress has been made in the research of OSD networks. For example, due to the proposal of the 5GC SBA, the OSD CN architecture has been studied quite widely; the proposed OpenMEC scheme provides a complete overview of the edge-based OSD architecture and its implementation. Nevertheless, the OSD RAN architecture has not been clearly defined due to its complex air interfaces, heterogeneous cell structure and incompatible network protocols. Moreover, an integrated OSD cellular network paradigm involving collaborations between the cloud, the network, the edge and the terminal is inevitable in the 6G network of the near future. Whether the existing OSD network components can be integrated and work together still needs further testing.

B. EFFECTIVE INTEGRATION WITH 6G SCENARIOS
The 6G system will further improve the existing 5G networking scenarios [12], [13], with the objective of further improving ultra-reliable low latency communications (URLLC). It will also embrace new paradigm shifts, e.g. space-air-ground integrated networks [42], terahertz (THz) communication [43], etc. This requires that the future 6G OSD network must be sufficiently flexible and intelligent for seamlessly supporting new scenarios and components, or for upgrading the existing functions without causing global disruption to the architecture. However, the proposed OpenMEC had to be developed and operated on the existing general-purpose hardware and open-source software platforms. Therefore, its integration with the future 6G application scenarios and paradigms needs further research.

C. OPEN-SOURCE MARKET FRAGMENTATION
The research of OSD network platforms has attracted the attention of numerous organizations and institutions. Numerous OSD network platforms have been developed, such as O-RAN, ONAP, OPNFV and the proposed OpenMEC, etc. However, the availability of a bewildering gamut of platforms can lead to the fragmentation of the open-source market, hence resulting in interoperability problems. In order to circumvent these problems, on the one hand, a unified open-source standard should be established for supporting openness and interoperability. On the other hand, it requires closer cooperation among open-source organizations to coordinate all the OSD network platforms in the near future.

D. CYBERSECURITY AND INTELLECTUAL PROPERTY PROTECTION
The 6G-oriented OSD cellular network architecture is expected to integrate all operating networks and provide users with customized capabilities including mobile services, critical industrial infrastructure, vertical sectors and other new network services. However, these new network features and the wide application of 6G are fraught with potential security and privacy challenges. In addition, the OSD architecture means that based on general-purpose hardware, any potential user is able to study, update and release new software versions to other users in a collaborative open-access manner. This however highlights the virtualization security issues, and poses a challenge in terms of the definition and protection of intellectual property. Therefore, how to effectively protect cybersecurity and intellectual property is still a huge challenge.

E. ENGAGING TELECOM VENDORS
Although more and more researchers and practitioners rely on open-source components to build customized cellular networks supporting MEC functionality, telecom vendors are not overly motivated to follow this approach. Since this open-source mode makes the specialized hardware associated with particular operating systems or functions in the original traditional network obsolete, vendors can no longer make profits by developing different specialized hardware. Therefore, how to persuade telecom vendors to join this open-source movement from an economic perspective and to further expand the target group supporting this movement is still a challenge.

VI. CONCLUSIONS AND FUTURE RESEARCH
In this paper, we have conceived the OpenMEC scheme for 6G relying on sophisticated decoupling and reconfiguration principles. First of all, an OpenMEC framework was presented based on ETSI's MEC architecture. Then, by means of the SBA and NFV technology, the tightly coupled service functions were decomposed into independent NFs. Next, by introducing the template and instantiation based concepts into MANO, the disaggregated NFs may be re-assembled and the required resources may be allocated in order to provide customized services for users. In this context, the evolved NFs were illustrated in the service-based MEC layer. The key components and the associated implementation processes were described in the NF's MANO. Then, a pair of typical use cases have been critically appraised through demonstrations in a small-scale test network. Finally, we have discussed some potential technical challenges of 6Goriented OSD cellular networks.
In our future work, we will aim for developing the OSD RAN architecture in order to construct a complete OSD cellular network for 6G. Based on the twinned core principles of the OSD RAN architecture: RAN decoupling and RAN reconfiguration, we envisage to propose a new threedimensional RAN slicing mechanism, which realizes the decoupling and re-encapsulation of resources and NFs from the three dimensions of resource virtualization, function virtualization and network slicing, so as to provide customized virtual RANs for users. We hope to fill the gaps in the research of OSD RAN architecture and lay the foundations for the ultimate realization of cloud-network-edge-terminal collaborative OSD cellular networks.