## 6 Results and Discussion
### Simulation Results and Disscusion  
As depicted in Figure 3, as the number of UEs, i.e., \(N\) increases, the delay of all schemes increases. The delay of our scheme is always minimal. When \(N\leq 30\), the delay of JODRA-PGLMC and that of OCO are almost the same. When \(N>30\), the gap becomes apparent gradually. It can be seen that there is an intersection for OCO and OLC between \(N=50\) and \(N=60\). When \(N\leq 50\), JODRA-PGLMC and OCO are closer. When \(N\geq 60\), JODRA-PGLMC and OLC are closer. This indicates that when \(N\) is small, UEs can obtain more computing resources by computation offloading. Therefore, most UEs tend to offload tasks to the LEO satellite or the BS. When \(N\) is large, UEs can obtain few computing resources from the LEO satellite or the BS. So UEs tend to compute tasks locally. The delay of JODRA-PGLMC is lower than that of JODRA-RDLMC, and the gap increases gradually, indicating that potential game can obtain a better task offloading decision effectively. The difference between JODRA-PGLMC and JODRA-PGLMNC means the gain brought by the satellite-terrestrial cooperation. The satellite migrates tasks to the BS in an adjacent area can bring stable gain. Comparing with the difference between JODRA-PGLMC and OLC, the difference between JODRA-PGLMNC and OLC is smaller, because computing resources of the LEO satellite's MEC server are much less than those of the BS's MEC server. The gain that can be brought by offloading tasks to the LEO satellite is limited. The delay of JODRA-PGLMC is always lower than that of OLC, and they have a relatively stable difference, which demonstrates that no matter offloading tasks to the LEO satellite or the BS can bring gain for UEs, and also confirms the effectiveness of the proposed scheme. \begin{table}
\begin{tabular}{c c c c} \hline \hline
**Parameter** & **Value** & **Parameter** & **Value** \\ \hline \(N\) & 40 & \(p_{i}\) & 2 W \\ \(c_{i}\) & 1000 cycles/bit & \(a_{i}\) & [0.5, 5] Mbit \\ \(f_{i,0}\) & [1, 2] GHz & \(g_{i}\) & 43.2 dBi \\ \(B_{i,5}\) & 800 MHz & \(B_{5,5}\) & 800 MHz \\ \(f_{u}\) & 30 GHz & \(f_{4}\) & 20 GHz \\ \(N_{0,5}\) & \(-203\) dBm/Hz & \(N_{0,5}\) & \(-203\) dBm/Hz \\ \(h_{\rm s}\) & 780 km & \(p\) & 50 W \\ \(D_{\rm TA}\) & 0.5 m & \(D_{\rm RA}\) & 0.33 m \\ \(F_{\rm S}\) & 15 Gcycles/s & \(F_{\rm B}\) & 60 Gcycles/s \\ \(D_{\rm g}\) & 7.3 m & \(c\) & \(3\times 10^{8}\) m/s \\ \(R_{\rm e}\) & 6371 km & \(\mu\)max & 2000 \\ \(\theta_{\rm u}\) & [10\({}^{\circ}\), 90\({}^{\circ}\)] & \(\theta_{\rm g}\) & [10\({}^{\circ}\), 30\({}^{\circ}\)] \\ \hline \hline \end{tabular}
\end{table} 
Table 1: Simulation parameters. \begin{table}
\begin{tabular}{c c c c c c c c c} \hline \hline
**Parameter** & **Value** & **Value** & **Value** & **Value** & **Value** & **Value** & **Value** & **Value** \\ \hline \(\theta_{\rm u},\theta_{\rm g}\) & \(10^{\circ}\) & \(20^{\circ}\) & \(30^{\circ}\) & \(40^{\circ}\) & \(50^{\circ}\) & \(60^{\circ}\) & \(70^{\circ}\) & \(80^{\circ}\) & \(90^{\circ}\) \\ \(\mu_{\rm K}\) (dB) & 25.43 & 12.72 & 8.40 & 6.52 & 5.24 & 4.57 & 4.02 & 3.70 & 3.62 \\ \(\sigma_{\rm K}\) (dB) & 7.04 & 7.47 & 7.18 & 6.88 & 5.28 & 4.92 & 3.40 & 2.22 & 2.28 \\ \hline \hline \end{tabular}
\end{table} 
Table 2: Simulation parameters. As shown in Figure 4, with the increase of computation intensity, i.e., \(c_{i}\), the delay of all schemes increases. Because computing resources required by tasks increase, the corresponding task computing delay also increases. The delay of our scheme is lower than that of JDORA-RDLMC, which indicates that the potential game can obtain an appropriate task offloading decision, thus reducing the delay. Comparing with the delay of JDORA-PGLMC, the delay of JDORA-PGLMC is lower, and the difference between them increases gradually, which means that offloading tasks to the BS can bring higher gain with the increase of \(c_{i}\), and also illustrates the necessity of satellite-terrestrial cooperation. The delay of JDORA-PGLMC is lower than that of OCO, and they are the closest.