## 5 Numerical Experiments
### Experiments on Large- and Super-Large-Scale Instances  
The NP-hard nature of the MILP model makes obtaining optimal solutions for larger-scale instances impractical, with even finding a feasible solution for such instances proving to be challenging. In order to further investigate the performance of the LNS on large-scale and super-large-scale instances, the results are compared with the GA proposed by [PERSON] et al. [11]. Since their study does not include forbidden arcs for IE and OE request vertices, the GA is then tailored to accommodate these constraints. As described in [PERSON] and [PERSON] [4], a sub-fleet can handle a maximum of 75 transport requests per day. Consequently, in this section, twenty large-scale instances are randomly generated, with the maximum number of requests set at 75 before the request vertex split and 135 after the split. Additionally, ten super-large-scale instances are generated, featuring transport request counts ranging from 100 to 480, with the total number of requests after vertex split ranging from 160 to 760. The results are shown in Tables 6 and 7. \begin{table}
\begin{tabular}{c c c c c c c c} \hline \hline \multirow{2}{*}{**Instance**} & \multirow{2}{*}{**No. of Requests**} & \multirow{2}{*}{**No. of Empty**} & \multicolumn{3}{c}{**Cost**} & \multicolumn{3}{c}{**Time (s)**} & \multirow{2}{*}{**Gap (\%)**} \\ \cline{5-6}  & & & **Containers** & & **GA** & & **LNS** & \\ \hline  
\hline \hline \end{tabular}
\end{table} 
Table 6: Results of LNS and GA for large-scale instances. \begin{table}
\begin{tabular}{c c c c c c c} \hline \hline \multirow{2}{*}{**Instance**} & \multirow{2}{*}{**No. of Requests**} & \multirow{2}{*}{**No. of Empty**} & \multicolumn{3}{c}{**Cost**} & \multicolumn{3}{c}{**Time (s)**} & \multirow{2}{*}{**Gap (\%)**} \\ \cline{5-6}  & & & **Containers** & & **GA** & & **LNS** & \\ \hline
41 & 100 (10, 5, 5, 10, 5, 5, 20(0), & 40(0)) & (0, 7, 6, 8, 4, 8) & 2498.5 & 2404.3 & 324.52 & 302.13 & \(-\)3.77 \\
42 & 120 (5, 5, 5, 5, 0, 0, 40(10)) & (8, 8, 8, 8, 9, 9) & 3502.1 & 3441.7 & 445.26 & 423.85 & \(-\)1.72 \\
43 & 140 From Tables 6 and 7, it can be observed that as the problem size increases, both the LNS and GA algorithms exhibit similar increase trends in terms of objective values and solution time, which proves the stability of the algorithms. Although there appears to be some fluctuation, the objective values and solution time are closely related to the number of request vertices after the split. To illustrate, while the number of requests in instances 23 and 24 is the same, instance 24 has more composite requests, which results in a greater number of request vertices, thus leading to higher costs and longer solution time compared to instance 23. Notably, the proposed LNS obviously outperforms GA in terms of both the objective values and solution time for large-scale and super-large-scale instances. When the total number of transport requests after vertex split does not exceed 135, both the LNS and GA are able to find solutions with excellent convergence within 126 s. However, on average, the LNS is 4.47 s faster than GA, and its objective values are 3.53% lower than those of GA. On the other hand, when the total number of transport requests after vertex split exceeds 160, the solving time of both LNS and GA shows a sharp increase. This phenomenon indicates that the problem size has a significant impact on the performance of the algorithms, especially in terms of solution complexity and computational resource requirements. The advantage of LNS becomes particularly evident for super-large-scale instances, where it has an average solving time of 107.78 s shorter than GA and an average objective value 3.86% lower than that of GA. Additionally, LNS has the capacity to yield solutions with relatively acceptable convergence within 3550 s for all the super-large-scale instances. All in all, the proposed LNS demonstrates a clear advantage by consistently providing significantly better solutions compared to the algorithm of [PERSON] et al.