**Table 1.**

*Simulation parameters.*

In Scheme 3, the service migration is triggered once the latency exceeds the threshold (e.g., 10 ms in **Figure 4**). Scheme 3 is considered as a tradeoff between Scheme 1 and Scheme 2. When *B* is low, Scheme 3 performs similar to Scheme 2, that is, frequent migrations are performed in both schemes (see **Figure 5**). As B increases, there are fewer and fewer migrations triggered in Scheme 3. Thus, the E2E latency is less and less affected by downtime. Therefore, Scheme 3 has similar performance with Scheme 1 when *B* is high and performs better than Scheme 2

*Low-Latency Strategies for Service Migration in Fog Computing Enabled Cellular Networks*

*DOI: http://dx.doi.org/10.5772/intechopen.91439*

During the service migration procedure, sufficient computation resource is needed to host the migrated services. Also, provisioning resource for the migrated real-time services needs to be completed as soon as possible to minimize the service interruption. Otherwise, the services have to stay at the source fog node, which may increase the access delay. On the other hand, one single fog node only has limited amount of computation resource, and its load is highly burst due to the mobility of vehicles. The service migration strategy discussed in the previous section assumes sufficient resources for the migrated services, which may not always hold in practice. Thus, it is important to employ efficient resource management scheme,

To guarantee sufficient computation resource for the migrated vehicular services and thus reducing the service migration blocking caused by the lack of computing resources, a distributed fog computing resource management scheme is proposed [9]. Two distributed fog computing resource management schemes, namely, fog resource reservation (FRR) and fog resource reallocation (FRL), have been considered. In FRR scheme, a certain amount of computation resources for vehicular services in each fog node are reserved based on the predicted vehicular traffic load. The performance of this scheme depends on the traffic flow prediction methods. Overestimating leads to low resource utilization, while underestimating significantly decreases one-hop access probability for high-priority (HP) vehicular services (e.g., remote driving, pre-crash sensing warning). For FRL, the key idea is to release part of fog resources used for low-priority (LP) services (e.g., online game, navigation, sign notification) by suspending those services and reallocate them to HP services. However, in such a scheme, the one-hop access probability for

when downtime is large (e.g., 0.3 s), as shown in **Figure 5**.

*The average number of migrations for a vehicle as a function of transmission capacity.*

**Figure 5.**

**31**

**3. Distributed fog computing resource management**

especially in the scenarios with fast mobility and high load.

**Figure 4.** *Transmission capacity (*B*) in the backhaul versus average end-to-end latency.*

*Low-Latency Strategies for Service Migration in Fog Computing Enabled Cellular Networks DOI: http://dx.doi.org/10.5772/intechopen.91439*

**Figure 5.** *The average number of migrations for a vehicle as a function of transmission capacity.*

performance with Scheme 1 when *B* is high and performs better than Scheme 2 when downtime is large (e.g., 0.3 s), as shown in **Figure 5**.

### **3. Distributed fog computing resource management**

During the service migration procedure, sufficient computation resource is needed to host the migrated services. Also, provisioning resource for the migrated real-time services needs to be completed as soon as possible to minimize the service interruption. Otherwise, the services have to stay at the source fog node, which may increase the access delay. On the other hand, one single fog node only has limited amount of computation resource, and its load is highly burst due to the mobility of vehicles. The service migration strategy discussed in the previous section assumes sufficient resources for the migrated services, which may not always hold in practice. Thus, it is important to employ efficient resource management scheme, especially in the scenarios with fast mobility and high load.

To guarantee sufficient computation resource for the migrated vehicular services and thus reducing the service migration blocking caused by the lack of computing resources, a distributed fog computing resource management scheme is proposed [9]. Two distributed fog computing resource management schemes, namely, fog resource reservation (FRR) and fog resource reallocation (FRL), have been considered. In FRR scheme, a certain amount of computation resources for vehicular services in each fog node are reserved based on the predicted vehicular traffic load. The performance of this scheme depends on the traffic flow prediction methods. Overestimating leads to low resource utilization, while underestimating significantly decreases one-hop access probability for high-priority (HP) vehicular services (e.g., remote driving, pre-crash sensing warning). For FRL, the key idea is to release part of fog resources used for low-priority (LP) services (e.g., online game, navigation, sign notification) by suspending those services and reallocate them to HP services. However, in such a scheme, the one-hop access probability for

In Scheme 3, the service migration is triggered once the latency exceeds the threshold (e.g., 10 ms in **Figure 4**). Scheme 3 is considered as a tradeoff between Scheme 1 and Scheme 2. When *B* is low, Scheme 3 performs similar to Scheme 2, that is, frequent migrations are performed in both schemes (see **Figure 5**). As B increases, there are fewer and fewer migrations triggered in Scheme 3. Thus, the E2E latency is less and less affected by downtime. Therefore, Scheme 3 has similar

**Table 1.**

**Figure 4.**

**30**

*Transmission capacity (*B*) in the backhaul versus average end-to-end latency.*

*Simulation parameters.*

**Parameter Value** Coverage of the country of Luxembourg 155 km2 [7] Total number of vehicles 5500 [7] Vehicle density 35.5 per km2 Bitrate of traffic generated by the vehicles (2 Kbps, 10 Mbps) Size of the applications encapsulated in VMs (10,100) Mbits Link speed in upstream and downstream in PONs 10 Gbps Repeated times of simulations 10 Simulation time 1000 s Coverage of a single BS-Fog 1 km2 Handover interruption time 20 ms [8] Wireless delay 0.5 ms Vehicle speed (1, 45) m/s [7] Processing time at active node 0.2 ms Number of ONUs in each PON 16 Number of PONs 10 Confidence level 95%

*Moving Broadband Mobile Communications Forward - Intelligent Technologies for 5G …*

LP services may be affected, especially when traffic load is high. In fact, not all the LP services (e.g., online game) need to have one-hop latency requirement and local awareness. Therefore, such services can be placed in its neighboring fog nodes with low load.

whether to accept the request or not according to the resource management

*Low-Latency Strategies for Service Migration in Fog Computing Enabled Cellular Networks*

migrated HP services (see Scenario ① in red dotted box in **Figure 6**).

In this part, we consider two scenarios used for the resource management strategy. In the first scenario, there is sufficient available resource in the target BS-Fog, the request is approved, and the corresponding resource is assigned to the

In the second scenario, the target BS-Fog does not have enough available resource. In such a case, the target BS-Fog selects ongoing LP services and migrates them to its neighboring BS-Fogs. After that, the resources of the selected LP services

**Figure 6**, the procedure is divided into two phases. In the first phase, LP services to be migrated are selected according to service selection strategies, while in the second phase, the target BS-Fog selects one of its neighboring BS-Fogs to host the migrated LP services. For such a purpose, the target BS-Fog firstly broadcasts a Migration Request message to its neighboring BS-Fogs that have direct communication with the target BS-Fog via X2 interface. Once the neighboring BS-Fogs receive the Migration Request messages, they will check their available resource and then send Migration Request ACK to the target BS-Fog. A final decision on the selection of neighboring BS-Fog is made by the target BS-Fog immediately. When the selected LP services complete the migration and release their resources, the target BS-Fog sends a Migration Request ACK to the source BS-Fog for HP service migration. If there are no available LP services or neighboring BS-Fogs, the to-bemigrated HP service has to run at the source BS-Fog and the vehicle has to access the service with more than one hop (i.e., the hop(s) between two neighboring BS-Fogs have to be counted for access), which may obviously result in a higher access delay. The selection strategies of LP services and neighboring BS-Fogs are discussed

In the proposed scheme, the selected LP services are migrated from the target BS-Fog to the selected neighboring BS-Fog, which will be accessed via backhaul networks. In such a procedure, a certain amount of backhaul bandwidth is needed for service migration and running the selected LP services. To minimize the required bandwidth, we propose a LP service selection algorithm to minimize the communication cost. The amount of the required bandwidth resources for each LP

service is firstly counted. Then, the LP services whose available computing

resources are larger than the requested amount are selected. Among these services, the one with the lowest communication cost is finally selected. If there is no service that satisfies the requirement alone, more than one service can be selected. In order to avoid ping-pong effect in LP service migration, LP services are only allowed to be

Once the LP services to be migrated are decided, neighboring BS-Fogs that will host the migrating services need to be decided. The decision needs to consider the QoS of those services since after migration, the services will be hosted at the selected neighboring BS-Fog and accessed with two hops, which results in extra backhaul delay. As LP services are only allowed to be migrated once, the access delay for the migrated LP services consists of radio access delay and backhaul delay. According to the delay requirement of the selected LP service, the budget of backhaul delay can be calculated. The transmission delay between the target BS-Fog

are released for HP services. As shown by Scenario ② in blue dashed box in

strategy.

in the following section.

migrated once.

**33**

*3.1.1 Low-priority service selection algorithm*

*DOI: http://dx.doi.org/10.5772/intechopen.91439*

*3.1.2 Neighboring fog-BS selection algorithm*
