ZONE-Based Multi-Access Edge Computing Scheme for User Device Mobility Management

: Recently, new mobile applications and services have appeared thanks to the rapid development of mobile devices and mobile network technology. Cloud computing has played an important role over the past decades, providing powerful computing capabilities and high-capacity storage space to efﬁciently deliver these mobile services to mobile users. Nevertheless, existing cloud computing delegates computing to a cloud server located at a relatively long distance, resulting in signiﬁcant delays due to additional time to return processing results from a cloud server. These unnecessary delays are inconvenient for mobile users because they are not suitable for applications that require a real-time service environment. To cope with these problems, a new computing concept called Multi-Access Edge Computing (MEC) has emerged. Instead of sending all requests to the central cloud to handle mobile users’ requests, the MEC brings computing power and storage resources to the edge of the mobile network. It enables the mobile user device to run the real-time applications that are sensitive to latency to meet the strict requirements. However, there is a lack of research on the efﬁcient utilization of computing resources and mobility support when mobile users move in the MEC environment. In this paper, we propose the MEC-based mobility management scheme that arranges MEC server (MECS) as the concept of Zone so that mobile users can continue to receive content and use server resources efﬁciently even when they move. The results show that the proposed scheme reduce the average service delay compared to the existing MEC scheme. In addition, the proposed scheme outperforms the existing MEC scheme because mobile users can continuously receive services, even when they move frequently.


Introduction
With the advent of various mobile and Internet of Things (IoT) devices, new types of services and mobile applications are emerging that utilize Machine Learning (ML) and Augmented Reality (AR) technology, which require high computing power and low latency due to recent advances in mobile network technology [1][2][3][4][5]. For example, the AR services, which provide users with an experience of interacting with the real world by adding computer-generated perceptual information to objects that exist in the real world, require high computing power because they should quickly process data collected from camera and sensor to mobile devices [6,7]. In addition, services and applications that utilize ML to provide insights into users with large amounts of data require large amounts of storage space and fast processing speed [8,9].
However, due to constraints such as processing power and battery lifetime of mobile devices, mobile users cannot efficiently receive services that require high computing power and low-latency. To meet these service requirements, a 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) [10,11]. With the computing paradigm of cloud computing and the development of many kinds of research, cloud computing could provide a well-established distribution model and application platform [12,13]. Thanks to such computing paradigm, there are growing interests in powerful computing operations such as real-time online games and ultra-high definition (UHD) streaming that require very low latency and high access speeds [14,15]. The existing cloud computing has performed computation-intensive tasks well with their powerful computing capabilities and scalability of cloud service infrastructure. The limitations are that cloud server is relatively remote for mobile users, making it unsuitable for services that require ultra-low latency and impossible to respond effectively in the event of the frequent mobile user movements. In addition, the massive volume of data exchanged between mobile users and remote cloud servers cause data tsunamis, leaving the backhaul network saturated.
To solve these problems, various kinds of network architecture and methods are emerging [16][17][18]. Especially, a new network architecture, which places a small cloud with various computing functions close to the mobile user devices, is under active research named as Fog Computing and Multi-Access Edge Computing [19][20][21][22]. Figure 1 shows the existing cloud computing architecture and MEC architecture. The concept of the initial Fog Computing was proposed by Cisco, which is a service infrastructure that provides data computation, storage, and application services similar to the cloud, but it does not perform the role of a central server and it does not feel like a central server [23,24]. That is, fog computing extends cloud computing into the edge for secure control and management of domain-specific hardware, storage and network functions within the domain and enables secure robust data processing applications across the domain. Similarly, the concept of MEC was proposed by the European Telecommunications Standard Institute (ETSI) and provides powerful cloud computing capabilities within a radio access network (RAN) [25]. In other words, MEC is considered as a paradigm close to mobile user devices in 5G network and provides powerful both computing capability and delay-sensitive services to mobile users quickly and effectively. Although many kinds of research for MEC are actively conducted, there are few studies on schemes related to mobility management for mobile users.
To solve these problems, this paper proposes the MEC-based mobility management scheme that enables the mobility of mobile users efficiently by managing MECS as the concept of Zones. The proposed scheme arranges MECS in the concept of Zone so that mobile users can continue to receive content and use of server resources efficiently even when they move. In other words, through the exchange of information between orchestras managing access MECS in the concept of Zone, it is possible to support continuous content delivery and efficient use of server resources even when the mobile users move. The rest of the paper is organized as follows. Section 2 presents the related works. Section 3 presents the proposed Zone-based MEC scheme for user device mobility management and then, we present the performance evaluation results in Section 4. Finally, we conclude the paper in Section 5.

Related Works
To solve the aforementioned problems of mobile user's movement in the MEC environment, there are studies related to mobility management scheme in MEC environment. Kondo et al. developed a MEC platform with a migration support system for edge servers [26]. Their proposed platform uses IP mobility support gateway that applies the extended virtualized Mobility Support Gateway (vMSG) to achieve mobility management requirement. They focused on requirements for continuous and transparent communication as well as reduced latency between the edge server and the mobile user. This platform provides a low-latency response when the mobile user moves, but there is lack of consideration for the movement of the mobile user requiring task migration. Ojima et al. predicted user mobility with Kalman filter for estimation of the connectivity [27]. They used mobility prediction to enable mobile users to select stable MECS during task requests and task collection and the success rate of collecting results was improved. However, if the mobile user moves frequently, they should select stable MECS at the new location each time. Al Ridhawi et al. proposed the solution to decompose the data in the cloud into a set of files and services [28]. They performed caching on the user mobile device to provide frequently requested files and services quickly. Their proposed solution is able to rapidly provide cloud composite services to end users while maintaining Quality of Service (QoS) requirements, but there is a lack of consideration for task migration situations that occur when users move frequently. Aloqaily et al. proposed the solution to provide fast service in situations where users demand data or services at the same time in a high density environment such as the stadium or the subway station [29]. They used service-specific overlays to provide mobile devices with faster data access by using data replication methods from the cloud to the edge in the congested environment. Although the methods provide efficient solutions for managing data and services in congested situations, they do not provide efficient solutions to the use of MECS resources in situations where mobile users are frequently moving and generating tasks. Balasubramanian et al.
proposed the mobile device cloud system architecture to solve the buffering problem of mobile devices in the dense and congested environment [30]. To this end, they utilized MPTCP (MultiPath-TCP) in their proposed system architecture. They also proposed an OS-side architecture that can manage the traffic coming from different flows. They have demonstrated the reduction in buffer occupancy using balking techniques that enable better queue management. They also modeled agents that meedt Kleinrock's laws and demonstrated their effectiveness through experiments. The OS-side architecture and MPTCP-based methods allow efficient use of cloud resources, but lacks consideration of the MEC environment.

Proposed Zone-Based MEC Architecture for User Device Mobility Management
To provide efficient service to the mobile user, we propose a mobility management scheme that manages MECS as Zones. To this end, the proposed architecture has an Edge Management Orchestra (EMO) that manages access MECS by creating a specific Zone, and a Zone Management Orchestra (ZMO) that manages Zones. In other words, the proposed structure is able to provide efficient service even in the presence of moving mobile users by hierarchically managing access MECS as the concept of Zone. It is assumed that all access MECS transmit their own information to a pre-established EMO by an operator such as a carrier in the initial connection establishment process. The proposed scheme has four stages. The detailed procedure is as follows.

A Scheme to Support User Mobility Management within the Zone
Step 1. Registration of access MECS to configure internal Zone: In the MEC environment, the proposed scheme to support continuous service even when user devices move frequently manages access MECSs with the concept of Zone. The proposed scheme uses EMO to configure Zone with access MECS and manage the access MECS located in Zone. To construct an internal Zone in the proposed scheme, it is assumed that each access MECS has EMO information preset by the carrier operator. First, the access MECS transmits the access MECS registry (AMR) message containing its own information to the EMO that is preset by the carrier operator before starting the service in order to configure the Zone. Figure 2 shows the format and example of the AMR message. The Zone Identifier field of the AMR message is set using information from the EMO preset by the carrier operator, which contains the information to identify the Zone. Access MECS Identifier refers to the unique information of access MECS such as the universally unique identifier (UUID). In addition, the access MECS address field indicates the address of the access MECS itself that is identifiable in EMO. Finally, the Signature field is the secure hash algorithm (SHA) value generated by using the information of the Zone identifier and the access MECS identifier. It is used to check the validity after registering the access MECS in the Zone. Step 2. Creation of EMO management list for access MEC management: The EMO, which receives AMR messages from access MECS, generates Edge Management List (EML) to efficiently perform mobility management of access MECS and mobile user located in its internal Zone. The EML is generated using the information of the message sent from the access MES and additional information (i.e., location, accessibility, etc.) from access MECS preset by the carrier operator. Figure 3 shows an example of the EML list generated by the EMO. The identifier and address fields of access MECS represent the unique identifier and address of access MECS, respectively. The Signature field represents a signature field in the AMR Message sent from the access MECS and is used to check the validity of the access MECS. Finally, the group tracking area field is a field of information for managing mobility generated by EMO based on AMR messages from access MECS located on its Zone to provide an efficient mobility experience for mobile users. EMO generates group tracking information by referring to AMR messages sent from access MECS and the EML information created by itself for continuous service provision even when mobile users are on the move. Group tracking information, which consists of information from adjacent access MECS, is transmitted to the access MECS by the EMO to manage the mobility of the mobile user so that it is possible to efficiently respond even when the mobile user frequently moves. In other words, EMO generates EML by combining information transmitted from access MECS and various information preset by carrier operator and generates group tracking information for mobility management by using generated EML and transmits it to access MECS. Thus, it is possible to provide continuous service even when mobile users move frequently. Step 3. Movement Indication: To recognize that the mobile user has moved in the proposed scheme, access MECS periodically broadcasts the access MECS status (AMS) message containing its own information. Since the AMS message includes information on the Zone, access MECS and neighboring access MECS, the mobile users receiving the AMS message can determine whether they have moved. Figure 4 shows the format and example of the AMS message. The Zone identifier field is identification information of the Zone created by the EMO, and it is possible to detect whether or not the mobile user has moved to other Zones. Mobile users moving to other Zones are described in detail in the next section. The access MECS Identifier field is identification information for the access MECS currently located in the mobile user, and this information can be used by the mobile users to detect whether they have moved. The inner group tracking area field represents information grouped into several adjacent access MECSs. This allows mobile users to quickly infer adjacent access MECS, so that it is possible to provide a continuous service even when the mobile user moves. The mobile user who receives the AMS message periodically checks the Zone identifier and the access MECS identifier field to detect his/her movement event. The mobile user who detects the movement sends a Zone Update (ZU) message to the access MECS to continuously perform the same task being performed by the previous MECS in the new location. Upon receiving the ZU message, access MECS performs a migration of existing tasks from the access MECS where the mobile user was previously located.
Step 4. Path Creation for Task Migration: Mobile users aware of their movements by receiving AMS messages periodically sent by access MECS send ZU messages to access MECS to register with the newly moved Zone. Figure 5 shows the format and example of the ZU message. The task migration field is used to determine whether or not a mobile user is performing the task at the access MECS where it is previously located. The access MECS identifier field indicates the identifier of the access MECS to which the mobile user was previously located. The Zone info field is used to identify whether a mobile user has moved from an internal Zone or an external Zone using the Zone identifier field in the AMS message received from the access MECS. Access MECS that received the ZU message first checks the task migration field of the ZU message to check whether the mobile user needs task migration from the previously located access MECS. When a task migration is required, access MECS performs a task of checking the access MECS identifier of the ZU message to check whether the mobile user has moved in the area it is tracking. If the mobile user moves from the area currently recorded in the access MECS tracked list, the access MECS can identify the previously located access MECS of the mobile user. In other words, access MECS, which checks the access MECS identity field recorded in the ZU message and identifies the access MECS that the mobile user was previously located, transmits a task migration request message to the access MECS where the mobile user was previously located. Access MECS that receives task migration request transmits task in progress to the access MECS where mobile user is currently located. The access MECS, which received task from the access MECS where mobile users were previously located, continues to perform task and provides continuous service to mobile users. That is, the proposed scheme performs the task migration from the access MECS that the mobile user was previously located based on the inner group tracking area information so that it is possible to provide a continuous service even when the mobile user moves. On the other hand, if the access MECS identifier does not exist in the inner group tracking area information of the access MECS, it means that the mobile user moves in the area where the access MECS is not tracking. Therefore, the ZU message is redirected to the EMO managing the access MECS. The EMO receiving the ZU message refers to its EML and transmits a task migration request to the access MECS where the mobile user was previously located. The access MECS that received the task migration request sends the currently performed task to the EMO, and the EMO that received the task transmits to the access MECS where the mobile user is currently located. As a result, the proposed scheme manages access MECS as a Zone concept, generates inner group tracking area information and transmits it to access MECS to mobile users' movements, so that efficient migration and continuous service can be provided even if mobile users frequently move.

A Scheme to Support User Mobility Management between the Zones
Step 1. Creation of Zone management list for Zone management: When mobile users move to the external Zone, it is necessary to register the information of the Zone composed of access MECS in the ZMO that manages the Zones in order to support mobility management and task migration of mobile users. To this end, the EMO, which manages the information of the access MECS, transmits its EML to the ZMO preset by the carrier operator. ZMO that receives EML from EMO that manages Zones generates Zone management list (ZML) to efficiently perform mobility management and task migration of mobile users moving between Zones. That is, the ZMO which generates the ZML having the information of the Zone by receiving the EML knows the information of multiple Zones, so that it is possible to provide a continuous service delivery even when the mobile user moves to an external Zone which does not exist in the tracking area information. Figure 6 shows an example of the ZML generated by the ZMO. The Zone identifier field is a unique identifier for the Zone created by the EMO. The EMO identifier field is a unique identifier of the EMO. Finally, the Zone tracking area field is composed of information on neighboring Zones generated by the ZMO based on the EML received from the EMO to provide continuous service delivery and mobility management to the mobile users moving to the external Zone. In other words, ZMO generates ZML using information from EMO and uses it to generate Zone tracking area information and transmits it for mobile user mobility management between Zones to EMO. Therefore, it is possible to provide continuous service delivery even when mobile users frequently move to other Zones.
Step 2. Movement Indication: The access MECS periodically broadcasts the AMS message containing information related to the Zone and access MECS, as well as detecting the movement of the mobile user within the Zone in Section 3.1. The mobile user receiving the AMS message can recognize whether the mobile user has moved using the field information in the AMS message. That is, mobile users recognize that they have moved to another Zone by checking the Zone identifier field in the AMS message, which records identification for the Zone managed by EMO. The mobile users who detect their movement transmits the ZU message to the access MECS in order to continuously perform the existing task at the new location. The access MECS that received the ZU message checks the Zone Info field of the ZU message to recognize that it is a movement between Zone and delegates the processing of Zone update to the EMO. The EMO, delegated to handle Zone update, sends ZU message to ZMO in order to support the movement of the mobile user between the external Zones. The ZMO can identify the access MECS where the mobile user was previously located by using the ZML in which the information of the Zones managed by each EMO is recorded. The ZMO, which identifies the access MECS where the mobile user is previously located, performs task migration to the access MECS, where the mobile user is currently located.
Step 3. Path Creation for Task Migration: When the mobile users receive the AMS message periodically transmitted by the access MECS and then recognize the movement to other Zones, they send the ZU message to the access MECS. The access MECS receiving the ZU Message checks the task migration field of the ZU message and determines whether the mobile user is working from the access MECS that was previously located. The access MECS, which recognizes that mobile users have moved to an external Zone by checking the Zone info field in the ZU message, delegates the processing of the Zone update to the EMO. The EMO, delegated to handle Zone update, supports the movement of the mobile user between the external Zones and transmits the ZU message to the ZMO in order to provide the continuous service delivery. The ZMO can identify the access MECS that the mobile user was previously located by using the ZML which records the information of the access MECS managed by each EMO. Therefore, the ZMO requests the access MECS, where the mobile user was previously located, to perform task migration. The ZMO, which received the tasks that was previously performed by the mobile user from the access MECS that was previously located, performs task migration with the access MECS, where the mobile users are currently located. In other words, the proposed scheme manages the access MECS by using the EMO that manages the access MECS as a Zone and the ZMO that manages the EMOs. Therefore, even if mobile users frequently move, efficient task migration and continuous service delivery can be provided to mobile users. Figure 7 shows the flowchart of the proposed zone-based MEC architecture for user device mobility management.

Performance Evaluations
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 [31,32]. We built a virtual environment which resembles a university campus where the students walk around and request services from the access MECS located at the buildings on the specific area. We compared three different cases of mobile users' movement: (i) movement within the Zone; (ii) movement between Zones; and (iii) hybrid case moving inside and outside the Zone. 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 [33][34][35]. In our simulation model, there were three location types with different mobile user preference levels. If the mobile user preference level of the access MECS was high, the mobile user was likely to spend more time in that access MECS. That is, the mobile user preference level of the location directly affected the dwell time that the mobile user spent in the related access MECS. The mobility model is illustrated in Figure 8 where γ is the dwell time and β i j refers the probability of moving from the access MECS i to the access MECS j.
To express the complexity of the computing operation, we used million instructions per second (MIPS) to describe the ability to perform one million commands per second. In addition, we handled computation-intensive task and task migration of mobile users using containerization technology such as Docker, to handle tasks performed in simulation environments [36]. We assumed that each MECS could handle task migration requests of up to 300 mobile users. In Table 1, the important simulation parameters are listed. In Figure 9, the average service time is shown with regard to the average task size. We set the average task size as 500 million instructions (MI) and 3000 MI and the results are given in Figure 9a,b, respectively. Figure 9a shows average service time when task size is small. Since the proposed scheme manages access MECS as the concept of Zone, it is possible to provide a fast service even when the mobile user frequently moves to the inside or outside of the Zone. In addition, since the proposed scheme can migrate the tasks that are executed from the access MECS that the mobile user previously located using the information generated by the EMO and ZMO, it is possible to provide a fast service even when the number of mobile users rapidly increases. However, if the task size is small, computing capability of the existing MEC environment can sufficiently process the task. Therefore, the proposed scheme has poor results compared to the existing MEC environment due to the overhead required for mobile user mobility support, but it is possible to provide a fast service without any problems. On the other hand, Figure 9b shows the average service time when task size is large. In the existing MEC environment, access MECS encounter with a computational resource congestion on VMs as the number of mobile users increases. Therefore, the average service time is increased due to the congestion as the number of mobile users increases. The proposed scheme manages access MECS as the concept of Zone and performs task migration from a previously located access MECS so it is possible to provide a fast service even when the number of users increases and the size of a task increases. In other words, the proposed scheme generates information for supporting the movement of mobile users by using EMO and ZMO and manages access MECS according to as the concept of Zone. Therefore, even when the mobile user frequently moves or the size of the task is large, it is possible to provide fast service.
In Figure 10, the average task failure rate is shown with respect to the mobile user preference levels. That is, the simulation was performed using the mobile user preference levels that adjust the frequency of mobility based on the time the mobile user dwells in the access MECS. We set the mobile user preference level as 1 (low) and 3 (high) and the results are given in Figure 10a,b, respectively. Figure 10a shows the average task failure rate when the movement of mobile user frequency is low. Since the proposed scheme manages access MECS as the concept of Zone, it is possible to provide the low average task failure even when the mobile user moves to the inside or outside of the Zone. In other words, if the mobile user is staying in a specific access MECS for a long time, the mobile user can receive the task result with a low failure rate because there is enough time to receive the task result being performed from the access MECS that the mobile user was previously located.
On the other hand, Figure 10b shows the average task failure rate when the movement of mobile user frequency is high. If the mobile user frequently moves, the mobile user frequently requests the task migration from the previously located access MECS and moves to other access MECS. Therefore, the failure rate of the high-mobile frequency is much higher than that of the low-mobile frequency. When the mobile user frequently moves, the time for the mobile user to stay in a particular access MECS is relatively small. That is, in this case, since the mobile user frequently requests the task migration from the previously located access MECS and moves to the other access MECS, the failure rate is increased as compared with the case where the mobile frequency is low. In other words, since the proposed scheme manages access MECS as the concept of Zone, mobile user can retransmit task migration request to access MECS, which the mobile user was previously located. It is possible to provide continuous service to mobile users even if mobile user moves frequently.

Open Issues and Challenges
In this section, we highlight some issues and challenges that provide direction to researchers for further research. Mobility support for mobile users who frequently move is an open and hot challenge for decades. In addition to our proposed scheme, there are also good candidates for mobility support that can provide continuous service delivery in a rapidly moving connected-car environment [37,38]. Although there are many studies on promising approaches (eg., location prediction and probabilistic prediction method), the study and implementation of efficient and reliable mobility support techniques is still quite lacking due to the structural characteristics of MEC performing the task offloading and task migration. Another important challenge is privacy issues that can have a fatal impact on the user. Some interesting approaches to solving such issues are adopting deep learning and machine learning techniques [39,40]. Such techniques can be used to secure user data and detect intruders that violate the user's privacy. Although techniques such as machine learning can solve some privacy issues, they cause excessive latency in delay-sensitive MEC environment. Several solutions emerge in similar problem domains, but none of them consider the MEC environment in depth.

Conclusions
This paper makes the following points. First, it shows that the MEC 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 requirements. However, when mobile users move to other access MECC in MEC environment, there are problems that the existing MEC environment does not consider, such as efficient utilization of computing resources and efficient task migration. To solve this problem, we propose a mobile user mobility support scheme that manages access MECS as the concept of Zone in this paper. In other words, the proposed scheme can efficiently support the movement of mobile users by using the information generated by the EMO and ZMO that manages the access MECS. Therefore, it is possible to provide continuous service delivery and efficient task migration even when mobile users frequently moves. We also show that the proposed scheme is an improvement over the existing MEC architecture through performance evaluation in the simulation environment, resulting in faster service delivery and lower task migration failure rates. In future works, we will improve the proposed scheme by implementing artificial intelligence (AI) features to enable continuous service delivery and efficient service discovery even when mobile users are moving frequently.

Conflicts of Interest:
The authors declare no conflict of interest.

Abbreviations
The following abbreviations are used in this manuscript: