# A DRL-Based Satellite Service Allocation Method in LEO Satellite Networks
## 1 Introduction  
In recent years, with the continuous reduction in the size of computing hardware, the enhancement of computational capabilities, and the decrease in power consumption, LEO satellites equipped with computing cards have been able to provide a certain level of edge computing capability [1]. Satellite edge computing has emerged as a novel computing paradigm, allowing the processing of tasks on LEO satellites [2; 3; 4]. This not only reduces user service latency but also conserves valuable bandwidth resources from satellites to ground-based cloud centers [5; 6; 7]. This paradigm is advantageous for LEO satellite missions such as border surveillance and unmanned area monitoring [6; 7; 8; 9; 10; 11; 12]. Due to the typically limited power availability of a few hundred watts for LEO satellites, with only a portion allocated for computing purposes, the computational resources on a single satellite are constrained [13; 14]. Additionally, these resources usually cover only a limited geographical area. Therefore, the efficient utilization of satellite computing resources in integrated satellite terrestrial networks (ISTNs) is crucial for the quality of LEO satellite services [15; 16; 17]. In an ISTN, satellite networks are positioned at the edge and connected to ground networks through ground stations [18]. However, the data link from users to satellites and then to the cloud center is too long. For delay-sensitive services, users typically access services directly at satellite nodes to meet their service requirements. This imposes higher demands on satellite resource capacity. Moreover, when multiple satellites have the ability to serve the same users simultaneously, selecting the appropriate satellites to achieve higher resource utilization becomes a research-worthy problem. Many scholars have conducted research on this topic. For single satellite coverage scenarios, [PERSON] et al. proposed the JCORA strategy [19], which considers energy consumption and latency as system costs to determine whether tasks should be offloaded to the access satellite. The work in [20] takes into account the energy and computational constraints of the satellite and presents a dynamic offloading strategy based on Lyapunov theory. [PERSON] et al. proposed a double-edge offloading mechanism in [21]. When the offloading capacity of ground edge servers is insufficient, the access satellite selects different cost-matching modes based on the size or type of the tasks to schedule edge servers in adjacent satellite nodes. For multi-satellite coverage scenario, the work by [22; 23; 24] proposes the joint optimization problem of task offloading and computing resource allocation for ground users and then decoupling it, while in [25], the collaborative computing offloading method in satellite edge computing is described, in which edge satellite nodes are used to perform tasks for the source satellite to optimize multidimensional resources. In [22], [PERSON] et al. adopted game theory methods to obtain offloading decisions in Nash equilibrium solutions. After proving the resource optimization problem is convex, they solved it by using the Lagrange multiplier method. In [23], the goal was to minimize the energy consumption of the satellite while meeting task latency requirements, and in [24], the focus is more on user service quality, with the weighted sum of user task latency and energy consumption being used as indicators. The above works have studied various schemes to provide computing offloading services to users but have not focused on the access choices of users in multi-satellite coverage scenarios. Some multi-satellite computing offloading schemes only schedule tasks and allocate resources using the access satellite's decision. Some authors have considered the association between users and satellites. In [26], a joint client selection and resource allocation strategy are proposed for the multi-task joint learning system, which selects satellite nodes based on wireless communication factors and local task data training results.