# Matching-Based Resource Allocation for Satellite-Ground Network
## 6 Performance Results and Analysis  
In this part, we choose to compare with two-sided matching method, greedy matching solution, and random matching solution, and evaluate the performance of the proposed algorithm through MATLAB simulation. The algorithms used in the simulation are as follows:  
1. Proposed method: a three-sided cycle matching method;
2. Two-sided matching method: it decouples three types of entities into two types for matching;
3. Greedy matching method: it finds the local optimal solution by using the best option in the current situation;
4. Random matching method: random matching of three kinds of entities  
The main simulation parameters are listed in Table 1[15; 36]. Within a geographical area of 10 km \(\times\) 10 km, the users are dispersed at random. There are six LEO satellites, six GEO satellites, and \(N\in[20,\,140]\) users in total. Specifically, the orbit height of the LEO satellite is 780 km, the orbit period is 6028 s, and the LEO satellite's capacity \(N_{L}\) is 20, and the GEO satellite's capacity \(N_{G}\) is 6. In the delay model, the transmission delay experienced by users connected to LEO satellites may be calculated by dividing the task data size \(\alpha_{i}^{t}\) by the associated transmission data rate \(R_{i,j,t}^{u\to s}\). As can be seen in Figure 2, with the increase in users, the average delay of users is also increasing. Our proposed algorithm can always produce a stable match so it has the lowest user delay. The delay of the two-sided matching and greedy algorithm is higher than the proposed three-sided cyclic matching algorithm, and the random allocation is the worst. In Figure 3, the number of users served by the four algorithms is depicted as the user base grows. We increase the number of users from 20 to 140 in 20 steps. According to the figure, we can see that the proposed algorithm, two-sided matching algorithm, and greedy method serve all users until the user number reaches 100. When there are about 120 users, the two-sided matching algorithm tends to be flat. Since then, when the number of users continues to rise, the proposed algorithm tends to be stable when serving about 120 users, because the available LEO satellite capacity is limited. It can be seen that our algorithm is superior to other algorithms in the number of service users. \begin{table}
\begin{tabular}{c c c c} \hline \hline
**Parameter** & **Value** & **Parameter** & **Value** \\ \hline \(B_{ij}^{t}\) & 54 MHz & \(f\) & 2.4 GHz \\ \(G_{i}^{tr}G_{j}^{cre}\) & 15 dB & \(P_{i}^{tr}\) & 0.5 W \\ \(a_{i}^{t}\) & [10, 100] Mbits & \(c\) & \(3\times 10^{8}\) m/s \\ \(k_{B}\) & \(1.38\times 10^{-23}\) J/K & \(T_{s}\) & 1000 J \\ \(N_{L}\) & 6 & \(N_{G}\) & 20 \\ \(M\) & 6 & \(K\) & 2 \\ \(N\) & [20, 140] & & \\ \hline \hline \end{tabular}
\end{table} 
Table 1: Simulation parameters. Figure 3: Number of output matching vs. users. Figure 2: Average delay vs. users. Figures 4 and 5 compare the change in satellite revenue with users and the change in satellite revenue at each slot. We increase the number of users from 20 to 140 in 20 steps. As shown in Figure 4, under all four scenarios, as more users join the network, the user's income increases. This is because the more users of the service, the more revenue. We can see that when the number of users reaches 120, the revenue is still increasing, because new users may have higher priority. On the other hand, Figure 5 shows that the revenue of satellites increases as time slots increase. The more users successfully matched, the more revenue the satellite obtains, so it shows an increasing trend. We can also observe from Figures 4 and 5 that our proposed algorithm is superior to two-sided matching, greedy, and random allocation methods. We further study the impact of time slot changes on the number of served users. For clarity, we considered the case where the user set is 120. In addition, we need to assume that the user's requirements for delay do not change in each time slot, so that we can make a fair comparison.