# Delay-Sensitive Service Provisioning in Software-Defined Low-Earth-Orbit Satellite Networks
## 2 Related Work and Motivation
### Related Work
Therefore, satellite network routing is actually finding a suitable path for each flow on \(m\) topologies, that is, a flow's routing strategy \(P\) is a set of \(m\) paths \(p_{1}\), \(p_{2}\),..., \(p_{m}\). It is worth noting that paths \(p_{i}\) and \(p_{j}\) of flow \(f\) corresponding to two time slots \(T_{i}\) and \(T_{j}\) may be the same (\(p_{i}=p_{j}\)). In other words, a flow may choose the same routing path across multiple time slots. The method based on virtual topology was first proposed in [17]. In order to reduce the computational cost on satellites, the routing scheme for each time slot is calculated in the ground control center and the routing scheme corresponding to each time slot is uploaded when the satellite passes through the ground control center. In addition, to improve routing performance, the paper proposes a topology snapshot segmentation strategy, which comprehensively considers system performance and limited satellite buffer space. This optimization strategy sacrifices equal-length time slots and divides them into unequal-length time slots, merging too-short time slots to balance routing delay and storage overhead. Another model for dealing with dynamic changes in satellite network topology is the virtual node model. In the virtual node model, the ground coverage area is divided into a grid, and virtual nodes are created to represent each grid position. Each virtual node corresponds to a physical satellite that is directly above the corresponding grid position at a certain time and is responsible for communication with the ground. When the satellite moves away from the grid position, another satellite in the same orbit will take over its communication responsibilities. Through the virtual node model, the entire satellite network is transformed into a static topology structure, and the routing forwarding between satellite nodes can be realized by maintaining the mapping relationship between physical satellites and virtual nodes [19]. The work in [19] is the first to establish the virtual node model, establish a mapping table between virtual nodes and satellites, and propose a distributed routing algorithm (DRA). DRA determines the forwarding path of data packets on satellite nodes by finding the shortest path between virtual nodes. DRA is a distributed and independent routing strategy that does not involve data interaction between satellite nodes. However, the performance of this algorithm significantly declines when satellite nodes or links fail. To improve DRA, the research community has proposed several routing optimization problems in satellite networks, most of which aim for load balancing. To improve the DRA algorithm, the low-complexity routing algorithm (LCRA) was proposed in [20]. The LCRA algorithm allows satellite nodes to write and exchange information about their network congestion state and consider the congestion state of neighboring nodes in the routing decision process. This reduces local congestion in the routing results, thereby enhancing the algorithm's performance. In [21], the authors proposed to allocate the remaining bandwidth of lightly loaded neighbors to congested satellites to avoid link congestion. In [22], each node in the network maintains the state information of the entire network and filters out overloaded nodes when making routing decisions. To reduce information exchange, the authors in [23] limit the exchange of state information between neighboring nodes. Assuming a globally synchronized state, the authors in [24] proposed an agent-based load balancing routing scheme. In [25], the authors proposed an on-demand load balancing routing scheme, which limits the range of state synchronization. It is true that the existing routing optimization solutions have a coarse control granularity. Although they can achieve a certain degree of load balancing based on network status, these methods cannot provide fine-grained routing schemes for each flow and thus cannot guarantee the latency requirements of each latency-sensitive application.