## 4 DRPS: Fault-Tolerant Approach for Dynamic Redundant Path Selection
### Service Migration  
As shown in Algorithm 2, the service migration algorithm first copies the task into many copies and migrates in all feasible paths simultaneously. There is no need to worry about the problem that ESs repeatedly calculates multiple identical tasks during the migration process. First of all, when searching for the migration path in Algorithm 1, all duplicate data links have been deleted (line 9), so there will not be the same data links in the migration path. Secondly, suppose two replicated tasks arrive at the same ES simultaneously (through different links, although the probability of this happening is very low). In that case, the ES will only calculate any one of the tasks and copy the calculation result, as both are sent to the next different node, respectively. Because the two tasks are the same, the calculation results are also the same, and the cost of copying the calculation results is meager, which does not affect the final result. The significance of copying tasks to all migration paths is to reduce the migration failure rate and speed up the migration. In service migration phase, the redundancy idea commonly used in fault tolerance mechanism is combined. If the BS or NR in a certain path fails, other migration paths without failure can ensure the successful migration of this task. The downside is obvious - it consumes more resources. However, the user experience can be improved by making a trade-off between the number of migration paths and the resource consumption. ```
1:Task \(r_{i}\); s feasible migration paths \(\{m_{1}^{r_{i}},m_{2}^{r_{i}},...,m_{s}^{r_{i}}\}\). 2:The task final migration time \(MT_{i}\). 3:Copy the tasks \(r_{i}\) to be migrated into \(s\) copies;
4:do in parallel
5: compute the migration time \(mt_{i}^{1}\) of task \(r_{i}\) on path \(m_{1}^{r_{i}}\). If the task is successfully migrated first on this path, it will send a termination migration signal to other paths. At this time \(MT_{i}=mt_{i}^{1}\);
6: compute the migration time \(mt_{i}^{2}\) of task \(r_{i}\) on path \(m_{2}^{r_{i}}\). If the task is successfully migrated first on this path, it will send a termination migration signal to other paths. At this time \(MT_{i}=mt_{i}^{2}\);
7:...
8: compute the migration time \(mt_{i}^{s}\) of task \(r_{i}\) on path \(m_{s}^{r_{i}}\). If the task is successfully migrated first on this path, it will send a termination migration signal to other paths. At this time \(MT_{i}=mt_{i}^{s}\);
9:return \(MT_{i}\)
```  
**Algorithm 2** Service Migration Algorithm  
During task migration, if the ESs fails, the task will be rolled back to the previous node and resend to the ES for processing. When the task on a path in \(M^{r_{i}}\) reaches the target ES successfully, a termination instruction will be sent to terminate the service migration on other paths to save costs. This is easy to implement because each task knows all migration paths. The transfer time of the termination instruction is negligible, so it can quickly terminate the migration of tasks on other paths. The service migration algorithm minimizes the task migration time based on the above resubmission and replication strategy. Algorithm 3 describes the migration process of tasks on each migration path and the calculation method of migration time. The migration time consists of computation time and transmission time. When the ES or NR fails and the migration fails, the task is rolled back to the previous node for retransmission. If the source edge server fails, it means that the task cannot be migrated at this time, that is, the migration fails. ES and NR will retain the task information (task size, execution time, failure or failure duration, etc.) of tasks that have been migrated on this device in the recent period to provide necessary information for the next round of task migration.