Mobile Personal Multi-Access Edge Computing Architecture Composed of Individual User Devices

Abstract

The Multi-Access Edge Computing (MEC) paradigm provides a promising solution to solve the resource-insufficiency problem in user mobile devices by offloading computation-intensive and delay-sensitive computing services to nearby edge nodes. However, there is a lack of research on the efficient task offloading and mobility support when mobile users frequently move in the MEC environment. In this paper, we propose the mobile personal MEC architecture that utilizes a user’s mobile device as an MEC server (MECS) so that mobile users can receive fast response and continuous service delivery. The results show that the proposed scheme reduces the average service delay and provides efficient task offloading compared to the existing MEC scheme. In addition, the proposed scheme outperforms the existing MEC scheme because the existing mobile user devices are used as MECS, enabling low-latency service and continuous service delivery, even as the mobile user requests and task sizes increase.

1. Introduction

The proliferation of high-performance user mobile devices and advances in network technology have led to the explosion of computational-intensive, delay-sensitive mobile application services such as real-time online games, virtual reality (VR) and augmented reality (AR) [1,2,3,4,5,6]. For example, AR services provide mobile users with an experience of interacting with the real world by adding computer-generated perceptual information to objects that exist in the real world. Since these services should quickly process data collected from cameras and sensors on user mobile devices, AR services require high computing power. Due to these changes in service and application requirements, mobile terminal technology at the edge of the network is also changing rapidly [7,8,9]. However, due to the limited battery capacity and computational processing power of the mobile user devices, mobile users cannot be provided with these services efficiently [10,11,12].

To meet these service and application requirements, the computing paradigm is widely used to deliver these services to mobile users using cloud computing such as Google Cloud Platform (GCP) and Amazon Elastic Compute Cloud (EC2) [13,14,15]. Cloud computing, which provides infrastructure as a service (IaaS), platform as a service (PaaS) and software as a service (SaaS) by clustering multiple data centers can deliver high-performance services that require large amounts of computation. In addition, due to the various research and technology developments of the cloud computing, cloud computing can provide well-established deployment models and application platforms. However, the existing cloud computing architecture has long delays due to the propagation distance from the mobile user device to cloud data center. Also, the enormous amount of data exchanged between the mobile device and central cloud data center causes the data tsunami that saturates the backhaul network. These problems make it difficult to provide mobile users with the fifth-generation cellular network (5G) services that require high reliability and low latency such as ultra-reliable and low-latency communication (URLLC). Various kinds of network architectures and efficient schemes are emerging to solve these problems [16,17,18,19]. In particular, the small cloud computing containing the various computing functions close to the mobile user is the subject of active research [20,21,22,23,24].

The concept of fog computing, the service infrastructure that provides services similar to the cloud computing, is proposed by Cisco but does not act as a central server and acts like the cloud [25,26,27]. In other words, fog computing extends cloud computing to the edge to securely control and manage domain-specific hardware, storage, and network capabilities within the domain and secures powerful data-processing applications across the domain. Similarly, the concept of MEC proposed by European Telecommunications Standard Institute (ETSI) provides the powerful cloud computing functionalities in the radio access network (RAN) [28]. In other words, edge computing can provide services with relatively low latency, but the edge server has limited computing resources, which makes it difficult to perform tasks requiring high throughput. Although MEC-related studies are being actively carried out, there is a lack of research on edge cluster structures for efficient working offload [29,30,31,32,33,34]. However, when the edge server becomes congested due to frequent task offloading requests from mobile users, the advantages of edge computing that provide ultra-low latency response by performing computing tasks in close proximity to the mobile user disappear. Accordingly, there is a need for an efficient tasking offloading scheme in edge computing environments. To solve these problems, this paper aims to study how to support efficient task offloading by using user mobile device as edge computing host in the MEC environment.

The rest of the paper is organized as follows. Section 2 describes the proposed scheme’s components and detailed operation process for using a user mobile device as an edge computing host. Section 3 presents the performance evaluation results of the proposed scheme. Section 4 concludes the result of the efficient and fast task offloading using mobile user devices as MECS.

2. Proposed Mobile Personal Multi-Access Edge Computing Architecture

The proposed scheme utilizes user mobile devices such as smart phones and laptops as MECS in addition to the existing MEC architecture. In addition to the existing architecture consisting of the MECS and cloud computing layers, it consists of the mobile MECS layer that utilizes mobile devices as MECS as shown in Figure 1. The proposed scheme utilizes user mobile devices as MECS, so that the user mobile devices enables the MECS and Cloud layer to distribute processing of computing loads. Therefore, this reduces the compute load at the MECS and cloud layers and the amount of data sent to higher layers to reduce bottlenecks. In addition, the scheme proposed in this manuscript utilizes the user mobile devices that exist closest to the mobile user as MECS, enabling rapid response and continuous service delivery, even when there are many users.

2.1. Components to Utilize Mobile Device as MECS

As shown in Figure 2, the components of the proposed scheme are the service requestor that requests the computing task, access MECS, which serves to generate task segmentation information by analyzing the requested task, and mobile devices, which act as a worker to perform tasks by receiving task segmentation information. In the proposed scheme, the mobile device used as the MECS is named mobile MECS (mMECS). The basic components and roles of the proposed scheme are shown in

Table 1. Description of the elements of the proposed scheme.

Component	Description
Access MECS	Creates the segment information of the task requested from the service requestor.
mMECS	Performs task offloading based on the segment information.
Service Requester	Serve task offloading requests to the access MECS.

.

The procedure for using MECS as the mobile device to provide fast response and continuous service is as follows. First, the service requester sends metadata of the task for requesting the task offloading to access MECS. The access MECS, which received the metadata, analyzes the requested task from the service requestor and generates segment information of the appropriate size. The generated segment information is transmitted to the mMECS, which has registered to be used as an MECS resource. Upon receiving of the segment information, mMECS receives the task segment from the service requestor and performs task offloading. The mMECS, which completed the task offloading of the task segment received from the service requestor, transmits the completed task to the access MECS. Access MECS, which has received the completed task segment from mMECS, reassembles the received task segment based on the segment information created by itself, and transmits the completed task to the service requester.

In other words, the proposed scheme uses the mobile device as an MECS in addition to the existing MEC architecture, so that it is possible to provide continuous and rapid service delivery even when the number of users increases. In addition, if the requested content is frequently used and highly shareable, the content is stored in the storage of the cloud layer and provided to the mobile user. Then the mobile user can receive the service from the cloud quickly even if the mobile user frequently requests the content. The detailed operational process of dispersion and reassembly of the task requested for computing offloading is described in Section 2.2. Also, the detailed operational procedures of the proposed scheme are described in Section 2.3.

2.2. Working Distribution and Merging Process

To maximize the distributed computing task processing speed, all the resources of mMECS, which plays the role of worker from the beginning to the end of the entire task execution process, should be utilized to ensure continuous operation. However, the proposed scheme utilizes mobile devices with diverse and limited computing power as MECS, so the existing computing method that distributes computing task considering all situations properly is not suitable. Since the proposed scheme utilizes the mobile node as MECS so there are a number of considerations for rearranging computing task when mMECS is moved. For this, the proposed scheme uses the method which sets the length of the segment to the smaller size so that mMECS, which is relatively poor in computing power, can be processed quickly. Figure 3 shows the task processing time of the distributed model based on task segment size.

In the case of a task segment-based model, when a large segment size is set, bottlenecks and additional processing time may be caused since each of the mMECS with different computing capacities has different task processing speeds. On the other hand, the distributed model used in the proposed scheme maximizes the task processing speed by allocating only a small number of task segments to mMECS at a time and assigning additional task segments right after the task processing is complete.

In other words, the proposed distributed model has a shorter segment length, so that the task distribution for the mMECS can be more balanced, and it is possible to use the worker’s resources to the maximum.

2.3. Detailed Operation Process of the Proposed Scheme

The detailed operation process of the proposed scheme consists of three steps: mobile MECS registration step to utilize mobile node as MECS, service requester’s request step for task offloading, and task offloading step of mMECS. A detailed description of the steps follows.

[Step01] Mobile MECS Registration: In order to provide the task offloading service to the service requester by using the mobile node existing in the access MECS as the MECS, the mobile node performs a procedure of registering its own information in the access MECS. To this end, the proposed scheme uses the mobile Node Registration (mNR) message to register the mobile node with the access MECS. The mNR message is a message format defined to register with access MECS that the mobile node will utilize its computing resources to play a role as the MECS. Figure 4 shows the format and example of the mNR message.

The mobile node name and address fields of the mNR message each represent the name and address of the mobile node, and the type field is the field used by accessing MECS to identify a message. The resource field is a field that contains metadata that records computing power such as CPU performance and memory capacity of the mobile node. The mobile node that decide to provide the MECS service sends the mNR message to the access MEC. In the proposed scheme, the mobile node that provides MECS service by sending mNR message to access MECS is named mMECS. Upon receipt of the mNR message, the access MECS records the information for mMECS management in the mMECS Management Table (mMT) based on field information from the mNR message. Figure 5 shows the example of the mMT.

Since the proposed scheme utilizes mobile devices as MECS, it can provide low-latency service delivery than the traditional MEC architectures. However, since the mobile device is used as mMECS, it needs various considerations for continuous service delivery. Because the proposed scheme uses mobile devices as MECS, the access MECS needs to check whether or not mMECS has moved periodically. For this, the proposed scheme transmits segment information to mMECS and if it does not receive a response within a random time, it determines that mMECS has moved and retransmits segment information to another mMCES. In addition, in order to achieve optimal task offloading performance considering the different task processing speeds of mMECS, the proposed scheme utilizes the method for variable segment allocation. The variable segment allocation method works by allocating more segments to mMECS which can perform task offloading quickly.

For example, due to the slow computing task offloading processing speed of mMECS, when access MECS receives the processed task segment lately, access MECS adjusts the number of segments to provide fast task offloading to the service requester. In other words, the mobile device that has completed the registration in the access MECS by performing the above procedure can play a role as the MECS, so that it is possible to provide the faster service delivery to the requesting service than the existing MEC architecture.

[Step02] Service Requester Request for Task Offloading: In order for the service requester to request task offloading from mMECS, the proposed scheme initializes by sending metadata containing task offloading information to access MECS. For this purpose, the proposed scheme uses the task offloading request (TOR) message. The TOR message is used to request task offloading from access MECS by the service requester. Figure 6 shows the format and example of the TOR message.

The name and address field represent the mobile device name and address information of the service requester requesting the task offloading service. The type field is used by access MECS to identify the TOR message. The task meta field is a field that contains metadata information that is required for the task to be requested. Finally, the signature field is a field used for access control when the mMECS in the access MECS accesses the task. Based on the information in the meta field of the TOR message, the access MECS, which receives the TOR message, performs the task of determining the appropriate segment size using the variable segment allocation method as mentioned in Section 2.2. After determining the appropriate task segment size, the access MECS sends information on the service requestor and the segment information to the mMECSs suitable for performing task offloading by referring to the mMT.

[Step03] Perform Task Offloading of Mobile MECS: The access MECS, which determines the appropriate size of the task segment by referring to the mMT, uses the mobile service request (mSR) message to provide the mMECS with task offloading information to be performed. The mSR message consists of the service requestor’s information and the task’s information to be performed, which allows the mMECS to directly receive segmented data for task offloading from the service requester. Figure 7 shows the format and an example of the mSR message.

The service request address field indicates the address of the service requestor to receive the segment required for the task offloading and the type field is the field used by mMEC to identify the mSR messages. The task meta field is a field that contains the task and segment information to be performed. The mMECS receiving the mSR message requests segment data assigned to it from the service requester, referring to the fields in the mSR message to perform task offloading. The service requester that receives the request of the segment data from mMECS sends the segment data and then that mMECS performs the task offloading. In order to merge the segment data that has completed task offloading and send it to the service requester, the proposed method needs to transmit the segment data completed by mMECS to the access MECS. To this end, the proposed scheme uses the mSR acknowledgement (mSRA) message. The mSRA message is used to send the segment that has completed task offloading to the access MECS. The mSRA message format and example are shown in Figure 8.

The mobile service request message field indicates the mSR message transmitted by the access MECS to the mMECS, and the type field is a field used by the access MECS to identify the mSRA message. Finally, data filed is a field that contains segment data that has completed task offloading. The access MECS receiving the mSRA message reassembles the received segment data and transmits the assembled data to the service requester. In addition, to efficiently use mMECS computing resources, the access MECS performs periodic status checking of mMECS referring to its mMT and transmits segment information to other mMECS when the task offloading result is late or there is no response. Figure 9 shows the flow chart of the proposed Mobile Personal Multi-Access Edge Computing Architecture.

3. Performance Evaluation

To evaluate the performance of the proposed scheme, we conducted experiments on various assumptions in which mobile users transmit computing tasks to access MECS and move to other access MECS. To do this, we implemented the network topology and MEC environments using CloudSim and Edge CloudSim respectively [35,36]. The mobile users moved according to a nomadic mobility model in which they move to other access MECS after a random amount of time has passed [37,38]. In our simulation model, there were three mobility types with different preference levels [39,40]. The mobile user was likely to spend more time in that access MECS in the case of low preference level.

In other words, the mobile user preference level of the location directly affected the dwelling time that the mobile user spent in the related access MECS. Million instructions per second (MIPS) was used to describe the ability to perform one million commands per second for the complexity of the computing operation. In addition, this paper handled the computation-intensive task and task offloading of mobile users using containerization technology, such as Docker, to handle tasks performed in simulation environments [41,42,43]. The percentages in the figures in this paper represent the usage of MEC resources. In

Table 2. Simulation Parameters.

Component	Description
User Mobility Model	Nomadic Mobility Model
Number of Mobile User	50–200
Number of Mobile Preference Level	3
Probability of Selecting a Mobile Preference Level	Equal (1/3)
Number of access MECS per Place	1
VM Processor Speed (MIPS) per access MECS	955
Processor Speed (MIPS) per mMECS	19
WLAN Bandwidth (Mbps)	300

, the important simulation parameters and their values are listed.

3.1. Service Delivery Time for the Number of mMECS

In Figure 10 and Figure 11, the service delivery time is shown with regard to the number of mMECS. For the performance evaluation, we set the task sizes to 3000 and 15000 MI and the results are shown in Figure 10 and Figure 11, respectively.

Figure 10 shows the service delivery time when the task size is small (3000 MI). Since the proposed scheme uses a user mobile device as MECS, so it is possible to provide a fast service delivery even if the resources of access MECS are in use. Although access MECS can be handled without the help of mMECS due to the small size of computing task processing, it shows that it is possible to provide fast service delivery when the number of mMES is increased.

On the other hand, Figure 11 shows the service delivery time when task size is large (15,000 MI). In the traditional MEC architecture, access MECS, which is delegated a large size of computing task, cannot process other computing tasks until the completion of the delegated computing task. However, the proposed scheme uses the user’s mobile device as MECS, so it is possible to provide fast service delivery, even if the size of the task is increased.

3.2. Average Service Time Due to the Movement of the Mobile User

Figure 12 and Figure 13 show the service delivery time when mobile users move frequently in relation to the number of mMECS. In order to measure the service delivery time according to the mobility of the mobile user, the mobility preference level is set to level 1 (low) and level 3 (high) and the results are as shown in Figure 12 and Figure 13, respectively. Figure 12 shows the service delivery time when the mobility preference level is low. Even if the mobile user’s movement is infrequent, if the mobile user moves, additional operations must be performed, so the service delivery time is longer than when the mobile user does not move. However, the proposed scheme utilizes the mobile user’s device as the MECS, so if the number of mMECS increases, the service can be provided faster than the existing MEC architecture.

On the other hand, Figure 13 shows the service delivery time when the mobility preference level is high. In case of frequent movement of mobile users, it is impossible to provide fast service delivery because additional operation due to frequent movement and computation result should be received from previously located access MECS. However, the proposed scheme uses a mobile device existing in access MECS as mMCES, so it can provide faster service delivery than existing architecture in a new location. In addition, as the number of mMECS increases, the computing power increases, so it is possible to provide a fast service to mobile users.

4. Conclusions

This paper makes the following points. First, it shows that the existing MEC architecture brings computing capacity to the edge of the mobile network, which enables the mobile user to run applications that require ultra-low delay service to meet strict service requirements. However, when the mobile user requests and task size increases, there are problems that the existing MEC environment does not consider, such as continuous service delivery, fast response and efficient task offloading. To solve these problems, we propose a mobile personal MEC architecture that utilizes a user’s mobile device as an MECS in this paper. The basic idea of the proposed architecture is designed to perform task offloading with the existing MECSs by using user mobile devices as MECS. In other words, the proposed scheme can efficiently support the task offloading by using the user’s mobile devices as an MECS. In addition, the proposed scheme also allows mMECS to perform task offloading of mobile users, which enables continuous service delivery and rapid service delivery, even if mobile users move frequently. Finally, simulation results show that the existing mobile user devices are used as MECS, enabling low-latency service and continuous service delivery, even as the mobile user requests and task size increases. In future works, we will improve the proposed scheme by implementing predictive models based on machine learning (ML) to enable continuous service delivery and efficient task offloading, even if mobile users move frequently.