A Mobility Management Using Follow-Me Cloud-Cloudlet in Fog-Computing-Based RANs for Smart Cities

Abstract

Mobility management for supporting the location tracking and location-based service (LBS) is an important issue of smart city by providing the means for the smooth transportation of people and goods. The mobility is useful to contribute the innovation in both public and private transportation infrastructures for smart cities. With the assistance of edge/fog computing, this paper presents a fully new mobility management using the proposed follow-me cloud-cloudlet (FMCL) approach in fog-computing-based radio access networks (Fog-RANs) for smart cities. The proposed follow-me cloud-cloudlet approach is an integration strategy of follow-me cloud (FMC) and follow-me edge (FME) (or called cloudlet). A user equipment (UE) receives the data, transmitted from original cloud, into the original edge cloud before the handover operation. After the handover operation, an UE searches for a new cloud, called as a migrated cloud, and a new edge cloud, called as a migrated edge cloud near to UE, where the remaining data is migrated from the original cloud to the migrated cloud and all the remaining data are received in the new edge cloud. Existing FMC results do not have the property of the VM migration between cloudlets for the purpose of reducing the transmission latency, and existing FME results do not keep the property of the service migration between data centers for reducing the transmission latency. Our proposed FMCL approach can simultaneously keep the VM migration between cloudlets and service migration between data centers to significantly reduce the transmission latency. The new proposed mobility management using FMCL approach aims to reduce the total transmission time if some data packets are pre-scheduled and pre-stored into the cache of cloudlet if UE is switching from the previous Fog-RAN to the serving Fog-RAN. To illustrate the performance achievement, the mathematical analysis and simulation results are examined in terms of the total transmission time, the throughput, the probability of packet loss, and the number of control messages.

1. Introduction

Cloud computing driving centralization is shown to be useful to lower the marginal costs of system administration and operations, and edge computing is a new technique for an alternative to cloud computing by moving the computing resources and analysis works from the cloud to the edge, referred to as cloudlet or fog nodes. The fog nodes are placed in close proximity to mobile devices to deliver highly response cloud services [1]. It is highly challenge to integrate the edge/fog computing techniques into smart IoT infrastructure for the smart city. A fog-computing-based radio access network, namely F-RAN, had proposed in [2] to take the advantage of local radio signal processing, cooperative radio resource management, and distributed storing capabilities in edge devices to significantly overcome the disadvantage of cloud-RAN [2] of the heavy burden on front-haul communications and the large amount of radio signal processing operations in the centralized baseband unit pool of cloud-RAN [2]. In an F-RAN, edge node is endowed with caching capabilities and is controllable from a central cloud processor as in a C-RAN [3] to reduce the delivery latency. Mobility management allows UEs or goods to move access multiple points while keeping their data sessions. Distributed mobility management (DMM) is proposed in [4] to distribute the mobility anchors in the data plane in flattening the mobility network such that the mobility anchors are positioned closer to UE [4]. Distributed mobility management for future 5G networks is emerging as a valid framework taking into account the requirements for large traffic in the core and the rise of extremely dense wireless access networks [5]. This work aims to develop a new DMM with low delivery latency using proposed Follow-Me Cloud-Cloudlet (FMCL) concept in F-RANs for the smart city. There is a novel and similar result in [6] to present a Fog-supported smart city network architecture called Fog Computing Architecture Network (FOCAN). To decrease latency and improve energy provisioning and the efficiency of services among things with different capabilities, the applications running on things jointly compute, route, and communicate with one another through the smart city environment.

Before describing the proposed follow-me cloud-cloudlet approach, the Follow-Me Cloud (FMC) and Follow-Me Edge concepts are initially described. Follow-Me Cloud (FMC) concept is proposed in [7] to migrate user service by virtual machines (VMs) between data centers (DCs) to support the service migration and continuity due to UE mobility or load balancing. Many mobile applications are heavily based on data and processing capabilities from the cloud [8]. Fog computing paradigm arises to overcome high delay encountered when real time applications need the low latency to access data or things of smart cities. Cloudlets allow the low latency access to data and processing capabilities, which can be accomplished by dynamically building a local virtual machine (VM) near to UEs or goods. A fog computing-based architecture in [8] supports the handoff by the local VM migration. In addition, Mobile Edge Computing (MEC) research is proposed by realizing the Follow-Me Edge (FME) concept [9] to ensure that the service constantly follows the user and that the user is always serviced from the closest edge [9].

It is observed that Follow-Me Cloud (FMC) results do not have the property of the VM migration between cloudlets for the purpose of reducing the transmission latency. In contrast, Follow-Me Edge (FME) results do not keep the advantage of the service migration between data centers (DCs) for reducing the transmission latency. Efforts will be made to propose a follow-me cloud-cloudlet (FMCL) approach to keep the VM migration between cloudlets and service migration between data centers (DCs) to significantly reduce the transmission latency. With the assistance of edge/fog computing, this paper presents a mobility management using a proposed follow-me cloud-cloudlet (FMCL) approach in fog-computing-based radio access networks (Fog-RANs) for smart cites. The proposed follow-me cloud-cloudlet approach is an integration strategy of follow-me cloud and follow-me edge. The new proposed mobility management aims to reduce the total transmission time if some data packets are pre-scheduled and pre-stored into the cache of cloudlet if UE is switching from the previous Fog-RAN to the serving Fog-RAN. The main contributions of the proposed handover scheme with FMCL approach are summarized as follows.

• We had proposed follow-me cloud-cloudlet (FMCL) approach, which is a integration strategy of follow-me cloud and follow-me edge to inherit the properties of FMC and FME and explore the cooperation between clouds and cloudlets.

• We had proposed a new mobility management with using FMCL approach to reduce the total transmission time, upgrade the throughput, and reduce the probability of the packet loss. This is because that the transmission cooperation between the cloud and the cloudlet, while some packets can be pre-scheduled in the cache of cloudlets to reduce the total transmission time and upgrade the throughput. This is because that some pre-scheduled packets can be directly accessed from local cloudlet, and these pre-scheduled packets are avoided the long network transmission to further improve the probability of the packet loss.

The rest of the paper is organized as follows. Section 2 describes the related work and motivation. Section 3 describes the system model, problem formulation and basic idea of our proposed scheme. Section 4 describes our proposed handover protocol with FMCL. Section 5 provides the performance analysis, and the conclusion is finally given in Section 6.

2. Related Works

This section first describes related work in Section 2.1 and then provides the research motivation in Section 2.2.

2.1. Related Works

The work mainly discusses the mobility management in the fog-computing-based RANs for smart city. There are some results for fog-computing-based RANs and some related handover works in [1,2,3,10,11,12,13]. Satyanarayanan et al. [1] had explained the background, effect, and application of the edge computing. Edge computing is a new paradigm in which substantial computing and storage resources—variously referred to as cloudlets, micro datacenters, or fog nodes—are placed at the Internet’s edge in close proximity to mobile devices or sensors [1]. Peng et al. [2] proposed some issues and challenges about fog-computing-based radio access networks. Peng et al. [2] declared that the fog-RAN-based architecture is a model for the 5-G mobile networks. The main idea includes local radio signal processing, cooperative radio resource management and distributed storing capabilities in edge devices. Tandon et al. [3] considered a hybrid architecture, referred to as fog RAN (F-RAN), and presented an information-theoretic framework. The information-theoretic framework characterized the main trade-offs between performance of an F-RAN, in terms of the worst case of the delivery latency and resources of caching and fronthaul capacities. Liang et al. [10] developed the offloading services from the cloud to the edge of networks in fog-computing-based platform for offering the real-time data services to the nearby data terminal. Tandon et al. [11] defined the fog radio access network (Fog-RAN) architecture in [11]. Fog-RAN is an emerging wireless network architecture. This architecture utilizes the caching capabilities at the edge nodes to provide a low data access latency. Jalali et al. [12] studied about the energy consumption problem of nano data centers (nDCs) for the edge computing data center. Shin et al. [13] introduced the Fog-Radio Access Network (F-RAN) architecture to bring the efficient computing capability of the cloud to the network edge. By distributing computing-intensive tasks to multiple F-RAN nodes, F-RAN has the potential to meet the requirements of those ultra low-latency applications.

Some results of distributed mobility managements are reported in the literature. For instance, Balfaqih et al. [14] presented a network-based DMM solution. This work also developed an analytical model to evaluate the handover latency and the packet loss. To improve the performance during the handover, this work specifies a buffer technique at the new Mobile Anchor Access Router (nMAAR) for the packet buffering. Murtadha et al. [15] also designed a network-based fully distributed mobility management in flattened network architecture. In addition, some SDN-based mobility managements are recently reported in [16,17,18,19,20,21,22,23]. One interest result is a SDN-based handover result reported in [16,17]. Modares et al. [16] provides a useful survey on proxy mobile IPv6 hsndover. Raza et al. [17] proposed an inter-domain IP mobility solution with route optimization using the SDN-based proxy mobile IPv6. Wang et al. [18] focused on extending SDN paradigm to mobility handling in the Internet, and to propose the design, implementation and deployment of a software-defined IP mobility architecture. Yao et al. [19] proposed a dynamic switch migration scheme by dynamically adapting the the data flow to realize the load balance among multiple SDN controller. Garzon et al. [20] proposed an X2-based handover procedure in an SDN-based LTE architecture. Elgendi et al. [22] proposed a distributed mobility management (DMM) and a user rate-perceived (URP) algorithm over a 3-Tier SDN-based architecture. Carpio et al. [23] proposed a new load balancing solution in SDN-based data center networks.

Mobility management results using the concept of follow-me cloud (FMC) are recently studied in [7,24,25,26,27]. Aissioui et al. [24] proposed proxy MIPv6-based FMC in [24] by a inter-domain distributed mobility management. Nadembega et al. [25] proposed a mobility-based services migration prediction (MSMP) scheme by addressing the trade-off between the overhead and Quality of Experience (QoE). Ksentini et al. [26] further considered the trade-off by modeling the service migration issue by using a Markov Decision Process (MDP).

Mobility management results using the concept of follow-me edge (FME) is studided in [9]. Taleb et al. [9] realized the FME concept by enforcing an autonomic creation of Mobile Edge Computing (MEC) service to allow the data access with the optimum QoE and the reduced latency. To realize the FME, the Edge Orchestrator (EO) of the mobile network operators (MNOs) needs to update the resource information and the user location information.

Some novel results of cloud and fog services to vehicular networks had developed [28,29]. Shojafar et al. [28] proposed an energy-efficient adaptive resource management for real-time vehicular cloud services. Naranjo et al. [29] proposed an energy-efficient adaptive scheduler for Vehicular Fog Computing (VFC) that operates at the edge of a vehicular network. Some results of 5G mobile networks with caching are provided [30,31,32,33]. Zakrzewska et al. [30] investigated the key challenges and current trends of 5G mobile networks.

Park et al. [31] developed a joint optimization of cloud and edge processing for fog radio access networks. Peng et al. [32] developed a backhaul-aware caching placement for wireless networks. Ugur et al. [33] developed a cloud radio access networks with coded caching.

2.2. Motivation

As mentioned in Section 2.1, two kinds of mobility managements are reported; one is the mobility managements using the concept of follow-me cloud (FMC) [7,24,25,26,27] and another one is the mobility management using the concept of follow-me edge/cloudlet (FME) [9]. The main motivation of this work is attempted to propose a new mobility management with the integration of the concepts of follow-me cloud (FMC) [7,24,25,26,27] and the follow-me edge/cloudlet (FME) [9], which is called as follow-me cloud-cloudlet (FMCL) approach in this paper. Existing FMC results do not own the novel property of the VM migration between cloudlets for the purpose of reducing the transmission latency. All existing (FME) results do not keep the advantage of the service migration between data centers (DCs) for reducing the transmission latency. Efforts will be made to propose a follow-me cloud-cloudlet (FMCL) approach to keep the VM migration between cloudlets and service migration between data centers (DCs) to significantly reduce the transmission latency. Thus, this work is to propose a new mobility management using the FMCL approach for the smart cities. One interested capability of fog-computing-based RAN architecture is that F-AP (fog-computing-based access point) of F-RAN contains the local cache functionality. Consequently, the new mobility management with the FMCL approach can inherit the advantage of the service migration from follow-me cloud (FMC) [7,24,25,26,27] and can explore and additionally keep the data locality property from the local cache functionality from the follow-me edge (FME) [9].

Consequently, one of the benefits is that the optimal shortest route can be re-calculated and re-constructed from the new service migrated data center to significantly reduce the network transmission latency. Another one is that all received packets can be pre-scheduled to the cache of edge/cloudlet to keep this data locality property of cache to improve the throughput and reduce the packet loss rate.

3. Preliminaries

This section describes the system model, the problem formulation, and basic idea in Section 3.1, Section 3.2 and Section 3.3.

3.1. System Architecture

The fog-computing-based RAN system architecture evolution from cloud-radio access network (C-RAN) [1,2,3] is shown in Figure 1. To overcome the disadvantages of C-RANs with the fronthaul constraints, the user and control planes are decoupled in such networks and the high power nodes (HPNs) are mainly used to provide seamless coverage and execute the functions of the control plane, while remote radio heads (RRHs) are deployed to provide high-speed data rate for packet traffic transmission in the user plane. The fronthaul portion of a C-RAN telecommunications architecture comprising the intermediate links between the centralized radio controllers and remote radio heads (RRHs) at the edge of a cellular network [1]. One main difference between C-RANs and F-RANs is that the centralized control function is shifted from the BBU pool in C-RANs to the HPN in F-RANs [2]. To incorporate fog computing in edge devices, the traditional RRH is evolved to the fog-computing-based access point (F-AP) by being equipped with a certain caching, CRSP, and CRRM capabilities [2]. The main difference between C-RANs and F-RANs is that the centralized control function is shifted from the BBU pool in C-RANs to the HPN in F-RANs [2].

Figure 1.

System architecture.

As shown in Figure 2a, the system architecture for our proposed follow-me cloud-cloudlet is modified from the system architecture of mobility using follow-me cloud approach from Aissioui et al.’s work in [24], and its simplified architecture is given in Figure 2b. Consequently, our system architecture also contains the follow-me cloud controller (FMCC), decision making application module (DMAM), mapping information gateway (MIGW), inter domain mobility database (IDMD), and local mobility anchor (LMA) [24]. The service migration of follow-me cloud approach [24] is also provided and reviewed as follows. When an UE switches to a different region, FMCC then decides to initiate a service migration from the current serving data center to the new serving data center, and also initiate a handover procedure and re-calculate the shortest route from the new serving data center gateway (DCG) to the next LMA of the new serving F-AP. In our follow-me cloud-cloudlet approach, FMCC also pre-sends some packets to the cache of the new serving F-AP to reduce the total data transmission time.

Figure 2.

(a) Fog-RAN architecture using follow me cloud-cloudlet and (b) its simplified architecture.

In the paper, we propose a new mobility management using the follow-me cloud-cloudlet (FMCL) approach for the smart city. This main purpose of FMCL approach is to reduce the total transmission time and the packet loss rate, under a $UE$ handover to a different area.

The network architecture of the fog-computing-based RANs (or called as F-RANs) contains that there is a cloud set $C=\left\{c_1,c_2,\cdots ,c_s,\cdots ,c_d,\cdots ,c_n\right\}$, where $c_s$ is the s-th serving data center or the s-th serving cloud, and cloudlet set $L=\left\{l_1,l_2,\cdots ,l_s,\cdots ,l_d,\cdots ,l_n\right\}$, where $l_s$ is the s-th serving cloudlet, then a cloud-cloudlet ($CL$) set is defined as $CL=\left\{c_1\to l_1,c_2\to l_2,\cdots ,c_s\to l_d,\cdots ,c_d\to l_s,\cdots ,c_n\to l_n,\right\}$. In general, we assumed that an $UE$ in the area with $l_s$ moves to a different area with $l_d$. Let $c_s\to l_d$ represent as the packet transmission from cloud $c_s$ to cloudlet $l_d$ during our mobility management using the cooperation transmission of cloud-cloudlet.

When the $UE$ moves from a previous area with $l_s$ to a different area with $l_d$, the current serving $c_s$ is performed the service migration operation to the new serving $c_d$. The MAG of $l_d$ sends out a proxy binding update (PBU), $PBU\_message(UE\_id,prefi{x}_d,LM{A}_d,TIM)$, to the inter domain mobility database (IDMD), where TIM (Traffic Information Message) is utilized to keep the receiving packet status of all packet transmissions during the handover procedure. The IDMD then creates an entry in its Binding Cache Entry (BCE) table. The new record of the BCE table is $BCE\_table(UE\_id,prefi{x}_d,LM{A}_d)$. After the IDMD receiving $PBU\_message$, the IDMD sends a migration-request message to the FMCC. The migration-request message contains the ID of UE, the allocated prefix, the new allocated LMA, and the cache data in $l_d$. After the FMCC obtaining the message, the FMCC concurrently finds the optimal transmission path between the new Data Center Gateway (DCG) of $c_d$ and new allocated LMA of $l_d$. When the FMCC determines the optimal path from $c_d$ to $l_d$, the FMCC sends out $REQ\_message(UE\_id,prefi{x}_s,prefi{x}_d,TIM)$ to the new $c_d$ to switch to the new path.

3.2. Problem Formulation

In the work, we attempted to develop a follow-me cloud-cloudlet approach for the mobility management. The main purpose is to reduce the transmission time during the handover by increasing the cache hit rate. As defined previously, The proposed follow-me cloud-cloudlet architecture contains a cloud-cloudlet ($CL$) set as $CL=\left\{c_1\to l_1,c_2\to l_2,\cdots ,c_s\to l_d,\cdots ,c_d\to l_s,\cdots ,c_n\to l_n\right\}$, where $l_s$, $l_d$, $c_s$, and $c_d$ are determined by FMCC during the handover operation. When FMCC decides the $l_d$, we try to pre-cache of the $l_d$ of the required data packets. Let $\alpha$ be denoted as the packet quantity existed in cache of the fog-computing-based RAN architecture. A data file F considered in this work is divided into n packets, $F=\left\{p_1,p_2,\cdots ,p_s,\cdots ,p_s,\cdots ,p_d\right\}$, where n is the total packet number of F. In our mobility protocol design, the total data transmission time when switching to different access point is $T_{FM}(p_s)$ + $T_{FML}$ + $T_{FMC}$ + $T_{FMCL}(p_d)$, where $T_{FM}(p_s)$ is the time cost of the follow me ($FM$) phase, $T_{FML}$ is the time cost of the follow me cloudlet ($FML$) phase $T_{FMC}(p_d)$ is the time cost of the follow me cloud ($FMC$) phase, and $T_{FMCL}(p_s)$ is the time cost of the follow me cloud-cloudlet ($FMCL$) phase (as described below). The problem is formulated to minimize the total data transmission time as:

$$\begin{array}{c}\hfill \mathrm{minimize}\{\min \sum _{1\le s\le k}{T}_{FM}(p_s)+T_{FML}+T_{FMC}+\min \sum _{k\le d\le n}{T}_{FMCL}(p_d)\}\\ \hfill \mathrm{subject}\mathrm{to}\left\{\begin{array}{c}{T}_{FM}(p_s)=\left\{\begin{array}{c}\begin{array}{c}{T}_c,\mathrm{if}{p}_s\in l_s\hfill \\ T_d,\mathrm{otherwise}.\hfill \end{array}\end{array}\right.\hfill \\ \begin{array}{c}{T}_{FMCL}(p_d)=\left\{\begin{array}{c}\begin{array}{c}{T}_c^{\prime },\mathrm{if}{p}_d\in l_d\hfill \\ T_d^{\prime },\mathrm{otherwise},\hfill \end{array}\end{array}\right.\hfill \end{array}\hfill \end{array}\right.\end{array}$$ (1)

where $T_c<<T_d$, $T_c^{\prime }<<T_d^{\prime }$. Time $T_c$ and $T_c^{\prime }$ denoted that the data transmission time of packet $p_s$ and $p_d$ is directly accessed from cache of clodlets $l_s$ and $l_d$, $T_d$ and $T_d^{\prime }$ denoted that the data transmission time of packet $p_s$ and $p_d$ must be transmitted from data center of clouds $c_s$ and $c_d$, respectively.

In addition, Wang et al. [34] generally discussed two kinds of caching techniques; web caching and redundancy elimination (RE). There are three types of RE technique; chunk-level RE, TCP-level RE and the packet-level RE. In the paper, we adopted the packet-level RE as our caching technique [34].

3.3. Basic Idea

This basic idea of the mobility management is to propose a cooperation strategy of cloud and cloudlet to reduce the transmission time and the packet loss rate.

Based on the proxy MIPv6-based FMC result of [24], all data packets are tunneled between MAG (Mobile Access Gateway) and LMA (Local Mobility Anchor) to keep the high connectivity property. As mentioned before, a cloud-cloudlet ($CL$) set is $CL=\left\{c_1\to l_1,c_2\to l_2,\cdots ,c_s\to l_d,\cdots ,c_d\to l_s,\cdots ,c_n\to l_n\right\}$. When $UE$ attached to a different MAG, four kinds of cooperation of cloud-cloudlet ($C{L}_{s\to s}$), cloud-cloudlet ($C{L}_{s\to d}$), cloud-cloudlet ($C{L}_{d\to s}$), and cloud-cloudlet ($C{L}_{d\to d}$) are defined below. The comparison of of proxy MIPv6-based FMC proposed by Aissioui et al. [24] and our the handover protocol using follow me cloud-cloudlet is illustrated in Figure 3.

Figure 3.

Comparison of (a) PMIPv6-based follow me cloud and (b) our proposed scheme using follow me cloud-cloudlet.

Cooperation of cloud-cloudlet $C{L}_{s\to s}$: Before the handover event of UE, assumed that $c_s$ and $l_s$ are the current serving cloud and cloudlet of the current serving F-RAN. Packets $p_s$ from the CN in data center of $c_s$ are transmitted to UE through F-AP${}_s$. For instance as shown in Figure 4a, the cooperation of cloud-cloudlet $C{L}_{s\to s}$ is provided.

Figure 4.

Basic operations of (a) cooperation of cloud-cloudlet $C{L}_{s\to s}$ and (b) cooperation of cloud-cloudlet $C{L}_{s\to d}$.

Cooperation of cloud-cloudlet $C{L}_{s\to d}$: When UE moves to a different region, and initiate the handover procedure, some packets are still transmitted from the current serving data center of $c_s$ to the new serving cloudlet $l_d$ if the data migration procedure is still not initiated. For instance as shown in Figure 4b, the cooperation of cloud-cloudlet $C{L}_{s\to d}$ is provided.

Cooperation of cloud-cloudlet $C{L}_{d\to s}$: After UE is moving to a different region, a data migration operation is executed from $c_s$ to $c_d$, it also means that CN is migrated from $c_s$ to $c_d$. Packets are then transmitted from the new serving data center of $c_d$ to the previous cloudlet $l_s$, and then be re-forward to the new cloudlet $l_d$ to UE, before the new route path from $c_d$ to $l_d$ is not re-calculated in FMCC. For instance as shown in Figure 5a, the cooperation of cloud-cloudlet $C{L}_{d\to s}$ is provided.

Figure 5.

Basic operations of (a) cooperation of cloud-cloudlet $C{L}_{d\to s}$ and (b) cooperation of cloud-cloudlet $C{L}_{d\to d}$.

Cooperation of cloud-cloudlet $C{L}_{d\to d}$: After the new route path is re-routed from the new serving data center of $c_d$ to the new cloudlet $l_d$ which is determined by FMCC, packets $p_d$ are transmitted from $c_d$ to UE through F-AP${}_d$ of $l_d$ by using the new re-calculated route path. As shown in Figure 5b, an example of the cooperation of cloud-cloudlet $C{L}_{d\to d}$ is given.

4. Mobility Management Using Follow-Me Cloud-Cloudlet Approach

In the section, mobility management using proposed follow-me cloud-cloudlet approach in F-RAN for smart cities is given. As mentioned in Section 3.3, four kinds of cooperation of cloud-cloudlet are defined, our mobility management is divided into four phases to implement these four cooperation of cloud-cloudlet, respectively.

1. Follow me phase: This phase is to implement the cooperation of cloud-cloudlet $C{L}_{s\to s}$. Before the handover event of UE, assumed that $c_s$ and $l_s$ are the current serving cloud and cloudlet of the current serving F-RAN. Packets $p_s$ from the CN in data center of $c_s$ are transmitted to UE through F-AP${}_s$.

2. Follow me cloudlet phase: This phase is to implement the cooperation of cloud-cloudlet $C{L}_{s\to d}$. When UE moves to a different region, and initiate the handover procedure, some packets are still transmitted from the current serving data center of $c_s$ to the new serving cloudlet $l_d$ if the data migration procedure is still not initiated.

3. Follow me cloud phase: This phase is to implement the cooperation of cloud-cloudlet $C{L}_{d\to d}$. After UE is moving to a different region, a data migration operation is executed from $c_s$ to $c_d$, it also means that CN is migrated from $c_s$ to $c_d$. Packets are then transmitted from the new serving data center of $c_d$ to the previous cloudlet $l_s$, and then be re-forward to the new cloudlet $l_d$ to UE, before the new route path from $c_d$ to $l_d$ is not re-calculated in FMCC.

4. Follow me cloud-cloudlet phase: The phase is to implement the cooperation of cloud-cloudlet $C{L}_{d\to d}$. After the new route path is re-routed from the new serving data center of $c_d$ to the new cloudlet $l_d$ which is determined by FMCC, packets $p_d$ are transmitted from $c_d$ to UE through F-AP${}_d$ of $l_d$ by using the new re-calculated route path.

The detailed operations of the mobility management using proposed follow-me cloud-cloudlet approach in F-RAN are described as follows. Message flow diagrams of PMIPv6-based FMC approach and our proposed mobility management using FMCL approach, are illustrated in Figure 6.

Figure 6.

Message flow diagrams of (a) PMIPv6-based FMC approach and (b) our proposed mobility management using FMCL approach.

4.1. Follow-Me Phase

This phase mainly implements the cooperation of cloud-cloudlet $C{L}_{s\to s}$. Let $REQ\_message$ $(UE\_id,prefi{x}_s,prefi{x}_d,TIM)$ or simplified as $REQ\_message$ is denoted as a data transmission request message, where $UE\_id$ is UE’s ID, $prefi{x}_s$ and $prefi{x}_d$ are UE’s the prefix of the network address, and $TIM$ is the traffic indication map to indicate the packet receiving status.

Assumed that a data file is divided into n packets, $F=\left\{p_1,p_2,\cdots ,p_n\right\}$. $TIM$ of $REQ\_message$ is n-bit map, $TIM=\left\{b_1,b_2,\cdots ,b_k,\cdots ,b_n\right\}$, if $b_k$ is equal to 1 then k-th packet is received by UE, and if $b_k$ is equal to 0, then k-th packet is not received by UE, where $1\le k\le n$. Before the handover event of UE, assume that $c_s$ and $l_s$ are the current serving cloud and cloudlet of the current serving F-RAN. Packets $p_s$ from the CN in data center of $c_s$ are transmitted or not, which is dependent on the $TIM$ which is extracted from received $REQ\_message(UE\_id,prefi{x}_s,TIM)$, to UE through F-AP${}_s$.

The $REQ\_message(UE\_id,prefi{x}_s,TIM)$ message is initiated from UE and forward the $REQ\_message$ through the serving LMA to the inter domain mobility database (IDMD). After IDMD receiving $REQ\_message$, a registration operation is executed in IDMD to create an entry in IDMD table as $UE\_information(UE\_id,prefi{x}_s,LM{A}_s)$. The $REQ\_message(UE\_id,prefi{x}_s,TIM)$ is forward to follow me cloud controller (FMCC). if FMCC receives the message, $REQ\_message(UE\_id,prefi{x}_s,TIM)$ is also forward to to the serving data center (DC) of cloud $c_s$. DC of $c_s$ extracts $TIM=\left\{b_1,b_2,\cdots ,b_k,\cdots ,b_n\right\}$ from received $REQ\_message$. DC examines $TIM=\left\{b_1,b_2,\cdots ,b_k,\cdots ,b_n\right\}$, if the value of $b_k$ of $TIM\_message$ is 0, then DC transmits k-packet toward $UE$ through $l_s$. UE also keeps a same $TIM\_UE=\left\{b_1,b_2,\cdots ,b_k,\cdots ,b_n\right\}$. $UE$ changes the value of $b_k$ from 0 to 1 if $UE$ receives k-th packet from the serving DC. Then, $TIM=(\underset{m}{\underbrace{1,1,\cdots ,1}}\underset{n-m}{\underbrace{0,0,\cdots ,0}})$. The detailed procedure is given below.

• S1. 
  $UE$ initiates $REQ\_message(UE\_id,prefi{x}_s,TIM)$, to F-AP, where $TIM=\left\{b_1,b_2,\cdots ,b_k,\cdots ,b_n\right\}$, and $b_k$ =0, $1\le k\le n$,

  $$\begin{array}{c}\hfill TIM=\underset{n}{\underbrace{\left(0,0,\cdots ,0\right)}}\end{array}$$ (2)
• S2. The $REQ\_message(UE\_id,prefi{x}_s,TIM)$ reaches to F-AP${}_s$ of $l_s$. The F-AP${}_s$ checks if k-th packets is already existed in cache of F-AP${}_s$, then update $b_k$ of $TIM$ accordingly, where $1\le k\le n$. The updated $TIM$ is re-inserted into the $REQ\_message(UE\_id,prefi{x}_s,$ updated $TIM)$, and then forward the new $REQ\_message$ to IDMD and FMCC.
• S3. DC of $c_s$ extracts $TIM=\left\{b_1,b_2,\cdots ,b_k,\cdots ,b_n\right\}$ from received $REQ\_message$. Before the handover event, DC repeatedly examines $TIM=\left\{b_1,b_2,\cdots ,b_k,\cdots ,b_n\right\}$, if the value of $b_k$, for $1\le k\le n$, of $TIM\_message$ is 0, then serving DC transmits k-packet toward $UE$ through $l_s$. UE also keeps $TIM\_UE=\left\{b_1,b_2,\cdots ,b_k,\cdots ,b_n\right\}$, and $UE$ concurrently updates the value of $b_k$ from 0 to 1 if $UE$ successfully receives k-th packet.
• S4. If the handover decision of UE is made by switching from F_AP${}_s$ to F_AP${}_d$, then go to the follow-me cloudlet phase. Then, $TIM=(\underset{m}{\underbrace{1,1,\cdots ,1}}\underset{n-m}{\underbrace{0,0,\cdots ,0}})$.

As shown in Figure 7, $UE$ sends out $REQ\_message(UE\_id,prefi{x}_1,TIM)$ with $TIM=(0,0,1,0,0,0,0,0,0,0)$ updated by F${}_1$ through IDMD to FMCC, because that 3-th packet existed is in cache of $l_1$. Finally, packets 1, 2, 3, and 4 are successfully received by UE, but packets 1, 2, 4, and 5 are transmitted from $c_1$. Therefore, $TIM\_UE$ = (1, 1, 1, 1, 0, 0, 0, 0, 0, 0).

Figure 7.

An example of follow me phase.

4.2. Follow-Me Cloudlet Phase

This phase implements the cooperation of cloud-cloudlet $C{L}_{s\to d}$. After performing follow-me phase, assume that we have $TIM=(\underset{m}{\underbrace{1,1,\cdots ,1}}\underset{n-m}{\underbrace{0,0,\cdots ,0}})$. When UE moves to a different region, and initiate the handover procedure, un-transmitted packets are still transmitted from the current serving data center of $c_s$ to the new serving cloudlet $l_d$, note that the data migration procedure is still not initiated, such that we may have $TIM=(\underset{m^{\prime }}{\underbrace{1,1,\cdots ,1}}\underset{n-m^{\prime }}{\underbrace{0,0,\cdots ,0}})$, where $m\le m^{\prime }$. That is, there are $m^{\prime }-m$ pre-transmitted packets. Some of these $n-m^{\prime }$ bits of TIM can be set to be 1 if these corresponding packets are already exited in cache of $l_d$.

The detailed procedure is given.

• S1. When $UE$ is moving to the new region with F-AP${}_d$ of $l_d$, the $UE$ initiates a request message, namely $REQ\_message(UE\_id,prefi{x}_s,prefi{x}_d,TIM)$, if the TIM message indicates that m packets are already successfully received by UE after executing the follow-me phase. The $REQ\_message$ also informs FMCC to carry the handover information with the report of the remaining un-received packets. The F-AP${}_d$ also checks if k-th packets is already existed in cache of F-AP_s, then let $b_k=1$ of $TIM$ , where $m+1\le k\le n$. The updated $TIM$ is re-inserted into the $REQ\_message(UE\_id,prefi{x}_s,$ updated $TIM)$ and forward to IDMD and FMCC.
• S2. MAG in $l_d$ receives the $REQ\_message(UE\_id,prefi{x}_s,$$TIM)$ from F-AP${}_d$, MAG initiates a proxy binding update (PBU), $PBU\_message(UE\_id,prefi{x}_s,prefi{x}_d,TIM)$ or $PBU\_message$ to LMA and forward it to IDMD. After IDMD receiving $PBU\_message$, IDMD updates the binding cache entry (BCE) table, $BCE\_table[UE\_id,prefi{x}_s,prefi{x}_d,LM{A}_s,LM{A}_d]$, $BCE\_table$. The IDMD generates the proxy binding acknowledgement (PBA), $PBA\_message$ to two LMA of the $l_s$ and $l_d$.
• S3. FMCC receives the session-migration-request message, $SMR\_message(MN\_id,prefi{x}_s,prefi{x}_d)$ from IDMD if IDMD receives $REQ\_message(UE\_id,prefi{x}_s,$ updated $TIM)$. FMCC sends $SMR\_message(MN\_id,prefi{x}_s,prefi{x}_d)$ to decision making application module (DMAM). DMAM is activated by the request from FMCC. DMAM is responsible of making the decision of the data migration to search for an optimal cloud $c_d$.
• S4. DMAM analyzes the user information, $UE\_information(prefi{x}_s,prefi{x}_d,etc.)$ in addition to the mapping information of $c_d$ and $l_d$ by generating get-mapping-information message, $GMI\_message$, to mapping information gateway (MIGW). MIGW then initiates a post-mapping-information message, $PMI\_message$, to DMAM.
• S5. After DC of cloud $c_s$ verifying the received TIM message, the DC of cloud $c_s$ randomly pre-transmits some $k^{\prime }$-th un-transmitted packets, where $b_k^{\prime }=0$ and $m+1\le k^{\prime }\le n$. The corresponding bits are set 1, for $b_k^{\prime }=1$, in the TIM message if the packet are successfully pre-transmitted toward to cloudlet $l_d$ and kept the pre-transmitted packets in cache of $l_d$. This pre-transmission operation is done until the new route path is determined in follow-me cloud-cloudlet phase. Finally, some of these $n-m^{\prime }$ bits of TIM can be set to be 1 if these corresponding packets are already exited in cache of $l_d$.
• S6. Finally, FMCC notifies $c_s$ and $c_d$ about the current user’s information containing current $TIM$ message, the location information through the analysis of DMAM and MIGW.

As shown in Figure 8, $UE$ moves from $l_1$ to $l_2$ and transmits a new $REQ\_message(UE\_id,prefi{x}_1,prefi{x}_2,TIM)$ to $l_2$, where TIM is (1, 1, 1, 1, 0, 0, 0, 0, 0, 0). This phase allows 5-th packet can be re-forward from $l_1$ to $l_2$, and allows 6-th packet can be pre-transmitted from $c_1$ to $l_2$, so $TIM$ becomes (1, 1, 1, 1, 1, 0, 0, 0, 0, 0), but 6-th packet is pre-transmitted, but, finally $TIM$ = (1, 1, 1, 1, 1, 0, 0, 1, 0, 0), since we assumed 7-th packet is already existed in cache of $l_2$.

Figure 8.

An example of follow me cloudlet phase.

4.3. Follow-Me Cloud Phase

This phase mainly implements the cooperation of cloud-cloudlet $C{L}_{d\to d}$. After UE is moving to a different region, a data migration operation is executed from $c_s$ to $c_d$, it also means that CN is migrated from $c_s$ to $c_d$. After performing follow-me cloudlet phase, assume that we have $TIM=(\underset{m^{\prime }}{\underbrace{1,1,\cdots ,1}}\underset{n-m^{\prime }}{\underbrace{0,0,\cdots ,0}})$. Thus, $m^{″}-m^{\prime }$ packets are then transmitted from the new serving data center of $c_d$ to the previous cloudlet $l_s$, and then be re-forward to the new cloudlet $l_d$ to UE, before the new route path from $c_d$ to $l_d$ is not re-calculated in FMCC. Then, we have $TIM=(\underset{m^{″}}{\underbrace{1,1,\cdots ,1}}\underset{n-m^{″}}{\underbrace{0,0,\cdots ,0}})$, where $m^{\prime }\le m^{″}$. That is, there are $m^{″}-m^{\prime }$ packets are transmitted in this phase. The detailed procedure is given.

• S1. The FMCC, DMAM and MIGW decide to execute the data migration procedure
• S2. DMAM sends a session-migration-approved message, $SMA\_message$, to FMCC. DMAM instructs FMCC to generate the essential traffic of the control plane by ensuring the seamless service migration procedure below. After FMCC receiving $SMA\_message$ from DMAM, it enables OpenFlow rules of the FMCC. FMCC sends out session-migration-request message, $SMR\_message$ to notify $c_s$ and $c_d$ to execute the data migration. Based on information of TIM message, all un-transmitted packets, for all $b_k=0$ and $m+1\le k\le n$, including TIM message are migrated from DC of $c_s$ to DC of $c_d$.
• S3. After DC of cloud $c_d$ verifying the received TIM message, the DC of cloud $c_d$ randomly pre-transmits some $k^{\prime }$-th un-transmitted packets, where $b_k^{\prime }=0$ and $m+1\le k^{\prime }\le n$. The corresponding bits are set 1, for $b_k^{\prime }=1$, in the TIM message if the packet are successfully pre-transmit toward to cloudlet $l_s$ and keep the pre-transmitted packets in cache of $l_s$. This pre-transmission operation is done until the new route path is determined in follow-me cloud-cloudlet phase.

As shown in Figure 9, 8-th packet is transmitted if TIM = (1, 1, 1, 1, 1, 1, 0, 1, 0, 0), and $b_7=0$, from the last phase. Finally, TIM = (1, 1, 1, 1, 1, 1, 1, 1, 0, 0), and the above operation is done before the new route path from $c_d$ to $l_d$.

Figure 9.

An example of follow me cloud phase.

4.4. Follow-Me Cloud-Cloudlet Phase

The phase mainly implements the cooperation of cloud-cloudlet $C{L}_{d\to d}$. We now have Then, we have $TIM=(\underset{m^{″}}{\underbrace{1,1,\cdots ,1}}\underset{n-m^{″}}{\underbrace{0,0,\cdots ,0}})$, where $m\le m^{″}$. After the new route path is re-routed from the new serving data center of $c_d$ to the new cloudlet $l_d$ which is determined by FMCC, $n-m^{″}$ un-transmitted packets are transmitted from $c_d$ to UE through F-AP${}_d$ of $l_d$ by using the new re-calculated route path. The detailed procedure is given.

• S1. When a new route path from DC of $c_d$ to DC of $l_d$ is re-calculated in route calculation module of FMCC, FMCC generates the OpenFlow flow-mod message to DCG${}_d$ of $c_d$ to LMA${}_d$ of $l_d$, the new re-calculated route from DCG${}_d$ of $c_d$ to LMA${}_d$ of $l_d$ is then constructed.
• S2. All k-th un-transmitted packets from the final TIM message, for all if $b_k=0$ and $m+1\le k\le n$ are sequentially transmitted by using the new re-calculated route from DCG${}_d$ of $c_d$ to LMA${}_d$ of $l_d$. Finally, all packets are successfully received by UE such that $TIM=TIM\_UE=(\underset{n}{\underbrace{1,1,\cdots ,1}})$.

As shown in Figure 10, since $TIM$ = (1, 1, 1, 1, 1, 1, 1, 1, 0, 0), then 9-th and 10-th packets are transmitted from CN of $c_d$ and finally all packets are received, where $TIM\_UE$ = (1, 1, 1, 1, 1, 1, 1, 1, 1, 1).

Figure 10.

An example of follow me cloud-cloudlet phase.

5. Performance Analysis

Our paper presents a mobility management using FMCL approach F-RAN for smart cities. A mathematical analysis and simulation results are provided. Our paper presents a mobility management using FMCL approach. To evaluate our handover protocol (proposed scheme with FMCL), and Aissioui et al.’s. proxy MIPv6-based FMC (PMIPv6 with FMC) [24], all these protocols are mainly implemented using the Ryu and Mininet as illustrated in Table 1. Ryu [35] is a component-based software defined networking framework. Ryu provides software components with well defined API that make it easy for developers to create new network management and control applications. Ryu supports various protocols for managing network devices, such as OpenFlow, Netconf, OF-config, etc. About OpenFlow, Ryu supports fully 1.0, 1.2, 1.3, 1.4, 1.5 and Nicira Extensions. All of the code is freely available under the Apache 2.0 license [35]. Mininet [36] creates a realistic virtual network, running real kernel, switch and application code, on a single machine (VM, cloud or native). Mininet is a way to develop, share, and experiment with OpenFlow and Software-Defined Networking systems [36]. In our simulation, we built two two computers; one is installed a SDN controller, Ryu 4.1 (IP: 172.24.4.2); and another one is installed OpenFlow-based Software-Defined Networking systems by mininet (IP: 172.24.24.2) under the same IP domain.

Table 1.

Simulation environment and parameters.

Parameter	Value
Simulation tools	Ryu SDN frame-work Mininet
Bandwidth per link	10 Mbps
Data file size	200 M
Number of F-AP	2
Number of DC	2
Number of UEs	0 to 50
Packet size	Uniform distribution with min = 84, max = 500 bytes

Before describing the performance metrics, the mathematical analysis of the total transmission time and space cost is described.

Theorem 1.

The total transmission time of the proposed mobility management with FMCL approach is $T={\displaystyle \sum _{1\le i\le m}}[\alpha t_{F{M}_l}(p_i)+(1-\alpha )t_{F{M}_c}(p_i)]+{\displaystyle \sum _{m<i\le m^{\prime }}}{t}_{FML}(p_i)+{\displaystyle \sum _{m^{\prime }<i\le m^{″}}}{t}_{FMC}(p_i)+{\displaystyle \sum _{m^{″}<i\le n}}[\beta t_{FMC{L}_l}(p_i)+(1-\beta )t_{FMC{L}_c}(p_i)]+{\displaystyle \sum _{m^{\prime }<i\le n}}{t}_m(p_i)$, where the cache hit rates of packets in caches of $l_s$ and $l_d$ are α and β, respectively.

Proof. 

Following notations in Section 4, a data file is divided into n packets, $F=\left\{p_1,p_2,\cdots ,p_m,\cdots ,p_{m^{\prime }},\cdots ,p_{m^{″}},\cdots ,p_n\right\}$, where $1\le m<m^{\prime }<m^{″}<n$. The total transmission time is divided into four phases, $T_{FM}$, $T_{FML}$, $T_{FMC}$, and $T_{FMCL}$ as illustrated in Figure 11a–c, where $T_{FM}$ is the time cost of performing follow-me phase, $T_{FML}$ is the time cost of performing follow-me cloudlet phase, $T_{FMC}$ denotes as the time cost of performing follow-me cloud phase, and $T_{FMCL}$ is the time cost of executing follow-me cloud-cloudlet phase. $T_{FM}={\displaystyle \sum _{1\le i\le m}}[\alpha t_{F{M}_l}(p_i)+(1-\alpha )t_{F{M}_c}(p_i)]$, where the cache hit rate of packets in cache of $l_s$ is $\alpha$, and $t_{F{M}_l}(p_i)$ and $t_{F{M}_c}(p_i)$ denote as the unit transmission time of packet $p_i$ transmitted from cloudlet $l_s$ or data center $c_s$, which is depended on packet $p_i$ ∈$l_s$ or $c_s$, where $1\le i\le m$. The data migration time $T_m$ is ${\displaystyle \sum _{m^{\prime }<i\le n}}{t}_m(p_i)$, where $t_m$ as the unit time of packet $p_i$ migrated from $c_s$ to $c_d$, where $m^{\prime }<i\le n$. $T_{FML}={\displaystyle \sum _{m<i\le m^{\prime }}}{t}_{FML}(p_i)$, where $t_{FML}(p_i)$ is the unit transmission time of packet $p_i$ transmitted from data center $c_s$ to cloudlet $l_d$, where $m<i\le m^{\prime }$. $T_{FMC}={\displaystyle \sum _{m^{\prime }<i\le m^{″}}}{t}_{FMC}(p_i)$, where $t_{FMC}(p_i)$ is the unit transmission time of packet $p_i$ transmitted from data center $c_d$ to cloudlet $l_s$, where $m^{\prime }<i\le m^{″}$. $T_{FMCL}={\displaystyle \sum _{m^{″}<i\le n}}[\beta t_{FMC{L}_l}(p_i)+(1-\beta )t_{FMC{L}_c}(p_i)]$, where the cache hit rate of packets in cache of $l_d$ is $\beta$, and $t_{FMC{L}_l}(p_i)$ and $t_{FMC{L}_c}(p_i)$ denote as the unit transmission time of packet $p_i$ transmitted from cloudlet $l_d$ or data center $c_d$, which is depended on packet $p_i$ ∈ $l_d$ or $c_d$, where $m^{″}<i\le n$. Consequently, the total transmission time $T=T_{FM}+T_{FML}+T_{FMC}+T_{FMCL}+T_m={\displaystyle \sum _{1\le i\le m}}[\alpha t_{F{M}_l}(p_i)+(1-\alpha )t_{F{M}_c}(p_i)]+{\displaystyle \sum _{m<i\le m^{\prime }}}{t}_{FML}(p_i)+{\displaystyle \sum _{m^{\prime }<i\le m^{″}}}{t}_{FMC}(p_i)+{\displaystyle \sum _{m^{″}<i\le n}}[\beta t_{FMC{L}_l}(p_i)+(1-\beta )t_{FMC{L}_c}(p_i)]+{\displaystyle \sum _{m^{\prime }<i\le n}}{t}_m(p_i)$. ☐

Figure 11.

Example of the time and space costs of (a) proxy MIPv6-based FMC, and our proposal scheme with FMCL if (b) $\alpha =\beta =100\%,$ and (c) $\alpha =10\%$ and $\beta =20\%.$

Theorem 2.

The space cost of the proposed mobility management with FMCL approach is ${\displaystyle \sum _{1\le i\le m,p_i\in l_s}}S(p_i)$ + ${\displaystyle \sum _{m^{″}\le i\le n,p_i\in l_d}}S(p_d)$, where $F=\left\{p_1,p_2,\cdots ,p_m,\cdots ,p_{m^{\prime }},\cdots ,p_{m^{″}},\cdots ,p_n\right\}$, $1\le m<m^{\prime }<m^{″}<n$, and $S(p_i)$ denote as the space size of packet $p_i$.

Proof. 

If $F=\left\{p_1,p_2,\cdots ,p_m,\cdots ,p_{m^{\prime }},\cdots ,p_{m^{″}},\cdots ,p_n\right\}$, and $1\le m<m^{\prime }<m^{″}<n$, as illustrated in Figure 11c, the space size of $l_s$ is ${\displaystyle \sum _{1\le i\le m,p_i\in l_s}}S(p_i)$ before the handover and the space size of $l_d$ is ${\displaystyle \sum _{m^{″}\le i\le n,p_i\in l_d}}S(p_d)$ after the handover, the total space size is ${\displaystyle \sum _{1\le i\le m,p_i\in l_s}}S(p_i)$ + ${\displaystyle \sum _{m^{″}\le i\le n,p_i\in l_d}}S(p_d)$. ☐

Example is offered in Figure 11a–c, the time and space costs of proxy MIPv6-based FMC is given in Figure 11a. The time and space costs of our proposal scheme with FMCL are given in Figure 11b–c if $\alpha =\beta =100\%$ and if $\alpha =10\%$ and $\beta =20\%$, respectively. The performance metrics to be observed are:

• Total transmission time is the time cost of all n packets are successfully received by $UE$ and transmitted from $CN$ during the handover from F_AP${}_l$ to F_AP${}_d$, if $CN$ has a data file $F=\left\{p_1,p_2,\cdots ,p_n\right\}$.

• Throughput is the total number of data packets that can be transmitted and received between UE and CN pair per unit time.

• Probability of packet loss is the total number of successfully received packets by UE divided by the total number of packets transmitted from CN.

• Number of control messages is the total number of control messages generated by the proposed mobility management using FMCL approach.

5.1. Total Transmission Time

The simulation results of the total transmission time vs. the UE moving speed, the cache size, and CDF (cumulative distribution function) are shown in Figure 12a–c, respectively. As UE moving speed increases, the total transmission time reduces because that the handover frequency increases. The more number of handover requests is, the higher handover latency time will be. As shown in Figure 12a, the total transmission time can be reduced if the more packets can be discovered in the cache. For instance, Figure 12a shows that the total transmission time is 23 s using PMIPv6 with FMC. However, the total transmission time of our proposed scheme with FMCL are 22.6 s, 22 s, 20 s and 18 s if the cache hit rate is 0, 10%, 40%, and 70%, with the UE moving speed fixed at 5 m/s, respectively. Figure 12a shows that the total transmission time of PMIPv6 with FMC was > that of our proposed scheme with FMCL (the cache hit rate = 0%) was > that of our proposed scheme with FMCL (the cache hit rate = 10%) was > our proposed scheme with FMCL (the cache hit rate = 40%) was > our proposed scheme with FMCL (the cache hit rate = 70%) was, under the different UE moving speed. Figure 12b shows the total transmission time vs. the different size of the cache (is ranging from 100 M to 200 M). The higher the size of the cache is, the lower the total transmission time will be. This proposed scheme aims at developing a pre-transmission method to increase the number of packets in cache. For instance, Figure 12b shows that the total transmission time is 22.5 s using PMIPv6 with FMC if the cache size is 150 (M). However, the total transmission time of our proposed scheme with FMCL are 22 s, 21 s, 18.5 s and 15.6 s if the cache hit rate is 0, 10%, 40%, and 70%, if the cache size is 150 (M). Similarly, Figure 12b shows that the total transmission time of PMIPv6 with FMC was > that of our proposed scheme with FMCL (the cache hit rate = 0%) was > that of our proposed scheme with FMCL (the cache hit rate = 10%) was > our proposed scheme with FMCL (the cache hit rate = 40%) was > our proposed scheme with FMCL (the cache hit rate = 70%) was, under the different cache size. In addition, Figure 12c offers the result of CDFvs. the total transmission time.

Figure 12.

Total transmission time vs. (a) UE moving speed and (b) cache size, and (c) CDF vs. the total transmission time.

5.2. Throughput

The simulation results of the average throughput vs. the UE moving speed, the cache size, and its CDF are illustrated in Figure 13a–c, respectively. On average, as $UE$ moving speed increases, the average throughput decrease. As shown in Figure 13a, the usage probability of packets in cache will be decreased if the UE moving speed increases, it implies that the average throughput will be decreases. Figure 13a shows that the average throughput is 8.6 (M/s) using the PMIPv6 with FMC under the UE moving speed is 5 (m/s). However, the average throughput of our proposed scheme with FMCL are 8.8 (M/s), 9 (M/s), 10 (M/s), and 11 (M/s) if the cache hit rate is 0, 10%, 40%, and 70%, under the UE moving speed is 5 m/s, respectively. Figure 13a shows that the average throughput of PMIPv6 with FMC was < that of our proposed scheme with FMCL (the cache hit rate = 0%) was < that of our proposed scheme with FMCL (the cache hit rate = 10%) was < our proposed scheme with FMCL (the cache hit rate = 40%) was < our proposed scheme with FMCL (the cache hit rate = 70%) was, under the different UE moving speed. As shown in Figure 13b, the simulation result of the average throughput vs. the different cache size (is ranging from 100 M to 200 M). As the higher the size of the cache is, the higher the average throughput will be. Figure 13b shows that the average throughput is 8.9 (M/s) using the PMIPv6 with FMC under the UE moving speed is 5 (m/s). However, the average throughput of our proposed scheme with FMCL are 9.1 (M/s), 9.5 (M/s), 10.9 (M/s), and 12.8 (M/s) if the cache hit rate is 0, 10%, 40%, and 70%, under the cache size is 150 (M), respectively. Figure 13b also shows that the average throughput of PMIPv6 with FMC was < that of our proposed scheme with FMCL (the cache hit rate = 0%) was < that of our proposed scheme with FMCL (the cache hit rate = 10%) was < our proposed scheme with FMCL (the cache hit rate = 40%) was < our proposed scheme with FMCL (the cache hit rate = 70%) was, under the different cache size. In addition, the CDF vs. the average throughput is provided in Figure 13c.

Figure 13.

Throughput vs. (a) UE moving speed. and (b) cache size, and (c) CDF vs. throughput.

5.3. Probability of Packet Loss

The simulation results of the probability of packet loss v. the UE moving speed, cache size, and CDF are shown in Figure 14a–c, respectively. As the $UE$ moving speed increases, the probability of packet loss reduces. As shown in Figure 14a, the probability of packet loss can be reduced if the more number of handover events occurred. Figure 14a shows that the probability of packet loss is 22.5 (%) using the PMIPv6 with FMC under the case of the UE moving speed is 5 (m/s). However, the probability of packet loss of our proposed scheme with FMCL are 23 (%), 20.5 (%), 14.5 (%), and 8.5 (%) if the cache hit rate is 0, 10%, 40%, and 70%, under the case of the UE moving speed is 5 m/s, respectively. Figure 14a shows that the probability of packet loss of PMIPv6 with FMC was ≈ that of our proposed scheme with FMCL (the cache hit rate = 0%) was > that of our proposed scheme with FMCL (the cache hit rate = 10%) was > our proposed scheme with FMCL (the cache hit rate = 40%) was > our proposed scheme with FMCL (the cache hit rate = 70%) was, under the different UE moving speed. Figure 14b shows that the simulation result of the probability of packet loss vs. the different cache size (is ranging from 100 M to 200 M). The higher the size of the cache is, the lower probability of packet loss will be. Figure 14b shows that the probability of packet loss is 21 (%) using the PMIPv6 with FMC under the case of the cache size is 150 (M) . However, the probability of packet loss of our proposed scheme with FMCL are 20.5 (%), 15 (%), 11.5 (%), and 8.6 (%) if the cache hit rate is 0, 10%, 40%, and 70%, under the case of the cache size is 150 (M), respectively. Figure 14b also shows that the probability of packet loss of PMIPv6 with FMC was ≈ that of our proposed scheme with FMCL (the cache hit rate = 0%) was > that of our proposed scheme with FMCL (the cache hit rate = 10%) was > our proposed scheme with FMCL (the cache hit rate = 40%) was > our proposed scheme with FMCL (the cache hit rate = 70%) was, under the different cache size. Finally, Figure 14c offers the result of the CDF vs. probability of packet loss.

Figure 14.

Probability of packet loss vs. (a) UE moving speed and (b) cache size, and (c) CDF vs. probability of packet loss.

5.4. Number of Control Messages

The simulation results of the number of control message vs. the UE moving speed, cache size, and CDF are shown in Figure 15a–c, respectively. As shown in Figure 15a, the the number of control message increases if the more number of handover events occurred. Figure 15a shows that the number of control messages is 10 using the PMIPv6 with FMC under the case of the UE moving speed is 5 (m/s). However, the number of control messages of our proposed scheme with FMCL are 15, 18, 33, and 48 if the cache hit rate is 0, 10%, 40%, and 70%, under the case of the UE moving speed is 5 m/s, respectively. Figure 15a shows that the number of control messages of PMIPv6 with FMC was < that of our proposed scheme with FMCL (the cache hit rate = 0%) was < that of our proposed scheme with FMCL (the cache hit rate = 10%) was < our proposed scheme with FMCL (the cache hit rate = 40%) was < our proposed scheme with FMCL (the cache hit rate = 70%) was, under the different UE moving speed. Figure 15b shows simulation result of the number of control messages vs. the different cache size (is ranging from 100 M to 200 M). The higher cache size is, the higher the number of control message will be. This is because that as the high cache size also implies that the high cache hit rate, so more control messages to needed to communicate with UE and F_AP. Figure 15b shows that the number of control messages is 4 using the PMIPv6 with FMC under the case of the cache size is 150 (M). However, the probability of packet loss of our proposed scheme with FMCL are 7, 18, 24, and 30 if the cache hit rate is 0, 10%, 40%, and 70%, under the case of the cache size is 150 (M), respectively. Figure 15b illustrates that the the number of control messages of PMIPv6 with FMC was < that of our proposed scheme with FMCL (the cache hit rate = 0%) was < that of our proposed scheme with FMCL (the cache hit rate = 10%) was < our proposed scheme with FMCL (the cache hit rate = 40%) was < our proposed scheme with FMCL (the cache hit rate = 70%) was, under the different cache size. Finally, Figure 15c provides the simulation result of CDF vs. the number of control messages.

Figure 15.

Number of control messages vs. (a) UE moving speed and (b) cache size, and (c) CDF vs. number of control messages.

6. Conclusions

This paper is to propose a new mobility management by using a follow-me cloud-cloudlet (FMCL) approach, which is a cooperation with cloud and cloudlet in Fog-RANs. All existing FMC results do not have the property of the VM migration between cloudlets, and all existing FME results do not have property of the service migration between data centers (DCs). As we can known, it is the first result to report a hybrid scheme by combining FMC and FME schemes into a fully new FMCL approach. The main contribution of the proposed mobility management using FMCL approach is to simultaneously keep the VM migration between cloudlets and service migration between DCs to significantly reduce the transmission latency in Fog-RANs. In addition, our mathematical analysis and simulation results shows that our proposed mobility scheme with FMCL approach outperforms existing FMC result in terms of the total transmission time, the average throughput, and the probability of packet loss, but with the more number of the control messages.

Future work can be further considered the multicast problem using the new proposed FMCL approach in fog-computing-based RAN for smart cities.

Author Contributions

Yuh-Shyan Chen and Yi-Ting Tsai contributed equally to the main setup, test, measurements, write-up, and towards revising the paper.

Conflicts of Interest

The authors declare no conflict of interest.