Satellite network terminal hierarchical access simulation method and system

Abstract

This invention discloses a hierarchical satellite network terminal access simulation method and system. Addressing the issue of the linear increase in the number of container instances, network namespaces, and virtual interfaces with the scale of terminals in large-scale satellite terminal access simulation, this invention proposes a three-level terminal instantiation mechanism based on service characteristics: Terminals are divided into lightweight terminals, state-preserving terminals, and high-isolation terminals according to their state maintenance requirements, protocol stack independence requirements, and operational environment isolation requirements. These are instantiated using data object-level, network namespace-level, and independent operational environment-level methods, respectively, and connected to satellite nodes uniformly through virtual forwarding devices. When satellite or terminal movement causes changes in connectable satellites, this change is translated into updates to the terminal-satellite connection relationship table and the forwarding rules of the virtual forwarding device. This invention significantly reduces resource overhead while maintaining simulation fidelity and supports satellite network access simulation with tens of thousands of terminals.

Description

Technical Field

[0001] This invention relates to the fields of satellite network simulation, network virtualization, software-defined networking, and large-scale terminal access simulation technology, and in particular to a satellite network access simulation method and system based on terminal hierarchical instantiation for large-scale satellite terminal access scenarios. Background Technology

[0002] Existing satellite network simulation technologies typically employ a uniform-granularity, isolated simulation approach, assigning an independent simulation instance to each communication entity. For example, some solutions utilize multi-threading and virtual network interface card (NIC) technologies to implement massive terminal simulation software, establishing login and service models for a vast number of simulated terminals; other solutions leverage Docker containers for high-fidelity simulation of satellite communication network elements. These simulation methods can reasonably achieve the simulation of various indicators when the constellation size is limited and the number of communicable nodes is small.

[0003] As the scale of low-Earth orbit (LEO) constellations continues to expand, the number of terminals that can access satellite networks is growing rapidly, reaching tens of thousands or even higher. Limited by the physical resources of a single host, the scale of thousands or even tens of thousands of terminals necessitates a dramatic increase in the number of container instances, virtual interfaces, network namespaces, and forwarding ports in the traditional "one terminal, one container" simulation architecture, making it difficult to support large-scale terminal simulation. In existing technologies, the number of terminals exhibits a linear growth relationship with the underlying network entities (containers, namespaces, virtual interfaces), and the resource expansion problem caused by large-scale terminal access has not yet been effectively solved.

[0004] Meanwhile, unlike the simulation of terrestrial access networks, satellite networks present the following unique challenges: (1) Dynamic topology characteristics: Satellite nodes have orbital motion characteristics, and the satellite coverage area and inter-satellite connection relationships change over time; (2) Dynamic connection relationships: The connectable relationship between the terminal and the satellite changes continuously due to satellite motion or changes in terminal location, and the simulation system needs to be able to dynamically update the terminal-satellite connection mapping and corresponding forwarding rules; (3) Differences in service requirements: Satellite terminal service forms differ significantly - short message services usually adopt connectionless communication mode, with lower requirements for protocol stack state maintenance; while real-time video services need to maintain end-to-end session state for a long time and have higher requirements for service continuity during the switching process. Different terminals have significantly different requirements for protocol stack state maintenance, operating environment isolation, and simulation accuracy.

[0005] The resulting problem is that in large-scale terminal access scenarios, if all terminals are simulated using independent containers or uniform isolation granularity, the number of container instances, network namespaces, virtual interfaces, and forwarding ports will rapidly expand. At the same time, when the terminal-satellite connectivity changes, if the terminal connection is still fully rebuilt or the terminal node is re-instantiated, the resource overhead and connection maintenance complexity of the simulation system will be further increased. Summary of the Invention

[0006] The purpose of this invention is to provide a satellite network terminal hierarchical access simulation method and system. According to the different requirements of the terminal to be simulated for continuous session state, independent network protocol stack and complete operating environment, different instantiation and network access methods are adopted for the terminal, so that different types of terminals can access and forward data in the same satellite network simulation environment, and support the updating of connection relationship and dynamic adjustment of access link parameters when the corresponding satellite node of the terminal changes.

[0007] To achieve the above objectives, the present invention provides a satellite network terminal hierarchical access simulation method, comprising the following steps:

[0008] S1. Obtain the service characteristic parameters of the terminal to be simulated, including state maintenance requirement parameters, protocol stack independence requirement parameters, and operating environment isolation requirement parameters;

[0009] S2. Based on the aforementioned service characteristic parameters, the terminal to be simulated is divided into three levels: When the state retention requirement parameter indicates that continuous session state maintenance is not required and the protocol stack independence requirement parameter indicates that an independent network protocol stack is not required, the terminal is classified as a first-class terminal; when the state retention requirement parameter indicates that continuous session state maintenance is required or the protocol stack independence requirement parameter indicates that an independent network protocol stack is required, and the runtime environment isolation requirement parameter indicates that a complete runtime environment is not required, the terminal is classified as a second-class terminal; when the runtime environment isolation requirement parameter indicates that a complete runtime environment is required, the terminal is classified as a third-class terminal.

[0010] S3. Create terminal emulation instances and connect each terminal emulation instance to the virtual forwarding device;

[0011] For the first type of terminal, it is instantiated in the form of a data object and managed uniformly by a proxy entity. The proxy entity accesses the virtual forwarding device through a shared forwarding channel.

[0012] For the second type of terminal, an independent network namespace is created for each terminal of this type, and the network namespaces of multiple second type terminals are connected to the virtual forwarding device through the terminal-side forwarding device.

[0013] For the third type of terminal, an independent operating environment is created for each terminal of this type, and each third type of terminal accesses the virtual forwarding device through a dedicated virtual interface;

[0014] The data object of the first type of terminal stores terminal identifier, service parameters, target access satellite identifier, and statistical information. The proxy entity maintains the object table and terminal-satellite connection relationship table of the first type of terminal and sends the service data of multiple first type terminals to the corresponding satellite node via the same shared forwarding channel. The network namespace of the second type of terminal has independent IP address, routing table, and protocol stack status, and is connected to the terminal-side forwarding device through a veth pair. The independent operating environment of the third type of terminal is a container or virtual machine, with an independent file system, process space, and network protocol stack.

[0015] S4. Create satellite node simulation instances and connect each satellite node simulation instance to the virtual forwarding device;

[0016] The steps for creating satellite node simulation instances include: creating a simulation instance in the form of a container or network namespace for each satellite node, and connecting each satellite node to the virtual forwarding device.

[0017] In steps S3 and S4, the virtual forwarding device is any one of Open vSwitch, Linux Bridge, and virtual routing device.

[0018] Furthermore, after completing the creation and access of the terminal simulation instance and satellite node simulation instance in steps S3 and S4, the method also includes a parameter configuration step for the access link: configuring propagation delay, bandwidth limit, jitter, and packet loss rate for the access link using Linux tc qdisc flow control technology, and dynamically updating the link parameters of the access link according to changes in link quality; the access link refers to the simulation link through which the terminal simulation instance and satellite node simulation instance communicate with the virtual forwarding device.

[0019] S5. Establish a terminal-satellite connection relationship table and configure forwarding rules between the terminal and the satellite, and between satellites;

[0020] The terminal-satellite connection table records at least the terminal identifier, terminal level, current corresponding satellite node identifier, and access channel information for each terminal. Based on the terminal-satellite connection table, forwarding rules are issued to the virtual forwarding device. Messages from all three levels of terminals are forwarded to the corresponding satellite nodes via the virtual forwarding device. Furthermore, based on the satellite-to-satellite topology, corresponding satellite-to-satellite forwarding rules are issued to the virtual forwarding device.

[0021] When the satellite node corresponding to the terminal changes:

[0022] For the first type of terminal, update the terminal-satellite connection relationship table in the proxy entity and the forwarding rules corresponding to the shared forwarding channel in the virtual forwarding device;

[0023] For the second type of terminal, update the forwarding rules in the terminal-side forwarding device;

[0024] For the third type of terminal, update the forwarding path corresponding to the dedicated virtual interface.

[0025] For the multiple second-type terminals determined in step S2, the multiple second-type terminals located in the same geographical area or the same beam coverage area are further divided into terminal groups according to the geographical area or the beam coverage area to which each second-type terminal is located. The network namespace corresponding interfaces of multiple second-type terminals in the same terminal group are associated with the same port group. When the target satellite node corresponding to a terminal group changes, the forwarding rules of the port group associated with the terminal group are updated in batches so that the traffic of multiple second-type terminals in the terminal group is forwarded to the new satellite node in a unified manner.

[0026] The forwarding rules are issued through any one of the following methods: OpenFlow protocol, OVSDB interface, command line interface, and Netlink interface.

[0027] Furthermore, after completing the establishment of the terminal-satellite connection relationship table and the configuration of forwarding rules in step S5, the simulation operation phase begins. In the simulation operation phase, the simulation status acquisition step is also included: acquiring the terminal instantiation status and resource occupancy status. The terminal instantiation status includes the number of first-type terminal objects, the number of second-type terminal network namespaces, and the number of third-type terminal independent operating environments. The resource occupancy status includes the number of container instances, the number of network namespaces, the number of virtual forwarding device ports, and the number of flow table rules.

[0028] Furthermore, this invention also proposes a satellite network terminal hierarchical access simulation system, which is implemented using the aforementioned terminal simulation and access steps, and includes:

[0029] The satellite network side module includes multiple satellite node simulation instances and a satellite network side virtual forwarding device. The satellite node simulation instances are connected to the satellite network side virtual forwarding device through an access link. The satellite network side virtual forwarding device is configured with forwarding rules between satellite nodes.

[0030] The terminal-side module includes terminal simulation instances instantiated according to different levels: The first type of terminal exists as a data object and is uniformly managed by a proxy entity, which accesses the satellite network-side virtual forwarding device through a shared forwarding channel; the second type of terminal each corresponds to an independent network namespace, and the network namespaces of multiple second-type terminals are connected to the terminal-side forwarding device, which is connected to the satellite network-side virtual forwarding device through an uplink port; the third type of terminal each corresponds to an independent operating environment, and each third-type terminal accesses the satellite network-side virtual forwarding device through a dedicated virtual interface.

[0031] The control plane module is used to maintain the terminal-satellite connection relationship table and issue forwarding rules to the virtual forwarding device on the satellite network side according to the terminal-satellite connection relationship table and the topology between satellites;

[0032] The control plane module is also used to: when the satellite node corresponding to the terminal changes, update the terminal-satellite connection relationship table in the proxy entity and the corresponding forwarding rules in the satellite network-side virtual forwarding device for the first type of terminal; update the forwarding rules in the terminal-side forwarding device for the second type of terminal; and update the forwarding path corresponding to the dedicated virtual interface for the third type of terminal.

[0033] The satellite node simulation instance is any one of container, network namespace, and virtual machine; the satellite network-side virtual forwarding device is any one of Open vSwitch, Linux Bridge, and virtual routing device; the forwarding rules are implemented through any one of Open vSwitch flow table rules and Linux Bridge routing rules; the access link is implemented through any one of tunnel interface and veth pair; the proxy entity is a user-space process; and the shared forwarding channel is any one of TUN / TAP interface, veth interface, Socket channel, and tunnel interface.

[0034] Beneficial effects:

[0035] 1. Reduce instantiation resource overhead. Based on the different needs of terminals for state maintenance, independent network protocol stacks, and complete runtime environments, terminals are instantiated in a three-tiered system (first-tier terminals use data object level, second-tier terminals use network namespace level, and third-tier terminals use independent runtime environment level), avoiding the use of complete container or virtual machine runtime environments for all terminals. For first-tier terminals that do not require independent protocol stacks and runtime environments, they are managed uniformly as data objects through a proxy entity, with multiple terminals reusing the same shared forwarding channel. For second-tier terminals that require independent protocol stacks but not complete runtime environments, only network namespaces are created instead of complete containers. This approach effectively reduces the number of container instances, network namespaces, and virtual interfaces created, increasing the number of terminals a single host can support from hundreds to tens of thousands.

[0036] 2. Improve simulation scalability. By storing a large number of lightweight terminals as data objects, the number of logical terminals is no longer limited by the number of underlying network entities such as containers or namespaces. This partially decouples the number of logical terminals from the number of underlying network entities, significantly improving the scalability of the simulation system.

[0037] 3. Balancing Differentiated Fidelity and Resource Utilization. This invention retains different layers of protocol stacks and operating environments based on business needs: the first type of terminal uses object-level lightweight simulation, suitable for business scenarios that do not require maintaining session state, such as short messages and sensor data reporting; the second type of terminal retains an independent network protocol stack, suitable for business scenarios that require maintaining session state, such as voice calls and video streaming; the third type of terminal retains a complete operating environment, suitable for business scenarios requiring high isolation, such as encrypted communication and critical command and control links. This maximizes resource utilization while ensuring necessary simulation fidelity.

[0038] 4. Reduced maintenance overhead for dynamic topology. This invention reduces the computational overhead and latency of maintaining terminal access relationships in dynamic satellite network topologies by uniformly maintaining the terminal-satellite connection relationship table and converting connection changes caused by satellite or terminal movement into updates to the connection relationship table and virtual forwarding device forwarding rules, rather than recreating terminal instances or rebuilding network connections.

[0039] 5. Supports regional-level batch connection updates. For the second type of terminal group divided by geographical region or beam coverage area, this invention connects multiple network namespaces in the same region to the same port group. When the target satellite node changes, the forwarding rules of the port group can be updated in batches, so that the traffic of multiple terminals in the region can be uniformly switched to the new satellite node. This avoids the operation of modifying the forwarding rules of each terminal one by one, and significantly improves the rule update efficiency when a large number of terminals switch at the same time.

[0040] 6. Supports dynamic link characteristic simulation. This invention can simulate link quality changes caused by satellite motion by dynamically configuring the propagation delay, bandwidth limitation, jitter, and packet loss rate of the access link, thus supporting dynamic simulation of satellite network link characteristics.

[0041] 7. Provides a data foundation for resource optimization. By collecting terminal instantiation status and resource occupancy status, this invention can obtain resource consumption data under different terminal hierarchical configuration conditions, providing a basis for optimizing resource configuration in the simulation system. Attached Figure Description

[0042] Figure 1 This is a schematic diagram of the overall architecture of the satellite network access simulation network of the present invention.

[0043] Figure 2 This diagram illustrates the specific implementation steps of the present invention. Detailed Implementation

[0044] The technical solution of the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be noted that the following embodiments are used to illustrate the technical solution of the present invention, and not to limit the scope of protection of the present invention. Without departing from the core concept of the present invention, those skilled in the art can make equivalent substitutions for the terminal instantiation form, virtual forwarding device, virtual interface form, rule distribution method, and satellite node operating environment, etc.

[0045] Example 1:

[0046] Combination Figure 1 and Figure 2 This embodiment provides a satellite network terminal hierarchical access simulation method, which specifically includes the following steps:

[0047] S1. Obtain terminal service characteristics and determine terminal level.

[0048] First, obtain the set of terminals to be simulated in this simulation task, and then obtain the corresponding business characteristic parameters for each terminal to be simulated.

[0049] The business characteristic parameters include state maintenance requirement parameters, protocol stack independence requirement parameters, and runtime environment isolation requirement parameters.

[0050] The state retention requirement parameter characterizes whether a terminal needs to maintain a continuous session state during service operation. For example, a terminal that only sends location data, telemetry data, or status reporting data once according to a preset period, and does not need to maintain continuous communication between service interactions, has a low state retention requirement; however, for terminals engaged in voice communication, continuous data transmission, or services requiring long-term connections, maintaining the corresponding continuous session state is necessary. In one implementation, it has two parameter values: true and false.

[0051] The protocol stack independence requirement parameter characterizes whether the terminal to be simulated needs to have an independent network protocol stack. Terminals requiring an independent network protocol stack can maintain their own IP address, routing table, and corresponding network protocol stack state to support independent network configuration and communication states between different terminals. In one implementation, it has two parameter values: true and false.

[0052] The runtime environment isolation requirement parameter characterizes whether the terminal to be simulated needs to have an independent and complete runtime environment. This complete runtime environment may include one of the following: an independent file system, process space, network protocol stack, or application runtime environment. In one implementation, it has three parameter values: low, middle, and high.

[0053] In the specific implementation process, the above-mentioned business characteristic parameters can be preset through the terminal configuration file before the simulation task starts, or they can be determined according to the terminal business type, simulation accuracy requirements, or pre-established business attribute judgment rules.

[0054] For example, state retention requirement flags, protocol stack independence requirement flags, and runtime environment isolation requirement flags can be set separately in the terminal configuration file. When reading the configuration data of a terminal to be simulated, the above-mentioned business characteristic parameters corresponding to the terminal can be obtained, and these parameters can be used as the basis for subsequent terminal level classification and instantiation method selection.

[0055] This step involves acquiring and recording the service characteristic parameters of each terminal to be simulated.

[0056] S2. Determine the terminal level based on business characteristic parameters.

[0057] Based on the state maintenance requirement parameters, protocol stack independence requirement parameters, and operating environment isolation requirement parameters obtained in step S1, the terminals to be simulated are classified into three categories: Class I terminals, Class II terminals, and Class III terminals, according to the different requirements of terminals for communication state maintenance, network protocol stack independence, and complete operating environment isolation.

[0058] Terminals that do not require maintenance of a continuous session state, an independent network protocol stack, or an independent and complete operating environment are classified as Category I terminals.

[0059] The first type of terminal is mainly used to simulate the number of terminals, service generation behavior, and the access relationship between terminals and satellites, without needing to maintain a complete network operating environment for each terminal. For example, periodic location reporting terminals, short message terminals, or some IoT sensor terminals can use the instantiation method of the first type of terminal.

[0060] Terminals that do not require an independent and complete operating environment but need to maintain a relatively independent network protocol stack state are classified as Category II terminals. Category II terminals can have independent IP addresses, routing tables, and protocol stack states, thereby achieving mutual isolation of network states between different terminals without creating a complete container or virtual machine for each terminal.

[0061] For example, for data communication terminals that need to maintain IP addresses, routing status, or continuous communication status separately, the instantiation method of the second type of terminal can be adopted.

[0062] Terminals requiring an independent and complete operating environment are classified as Category 3 terminals. Category 3 terminals can utilize containers or virtual machines to provide the terminal with an independent file system, process space, and network protocol stack, and can run actual terminal business programs or protocol programs within the corresponding operating environment.

[0063] For example, terminals that need to run complete applications, perform protocol consistency verification, or require a high degree of operational environment isolation can adopt the instantiation method of the third type of terminal.

[0064] In one implementation, the service characteristics and instantiation granularity of each level of terminal can be described as shown in Table 1.

[0065] Table 1: Category 1 (Lightweight Terminal) Short-term, sudden events, no need for continuous sessions No sustained sessions, single or short-term data interactions Satellite short messages, location reporting, and IoT sensor data acquisition Lightweight simulation at the data object level Extremely low Category 2 (State-Preserving Terminals) Continuous connection, stateful Session maintenance is required to keep the protocol stack state running. Voice calls, video streaming, data relay Network resource-level isolation simulation medium Category 3 (High-Isolation Terminals) Special business, strong isolation Independent protocol stack, security domain isolation Military encrypted communications, key command and control links Standalone runtime environment level simulation higher

[0066] It should be noted that the typical services listed in Table 1 are only used to illustrate the applicable scenarios for different levels of terminals and do not constitute a limitation on the service types of each level of terminal. The specific classification is still based on the terminal's corresponding state maintenance requirements, protocol stack independence requirements, and operating environment isolation requirements.

[0067] The terminal level can be predetermined based on the service configuration file before the simulation task starts, or it can be determined by the control plane based on preset terminal service attribute judgment rules. Regardless of whether a pre-configuration or rule-based judgment method is used, as long as the instantiation level that matches the terminal requirements can be determined based on the above-mentioned service characteristic parameters, the terminal hierarchical instantiation described in this invention can be realized.

[0068] After the terminal classification is completed, a corresponding terminal attribute record can be established for each terminal. The terminal attribute record includes at least the terminal identifier, terminal level and service parameters, and serves as the basis for terminal instantiation in step S3 and for establishing the terminal-satellite connection relationship in step S5.

[0069] S3. Create terminal emulation instances and connect each terminal emulation instance to the virtual forwarding device.

[0070] S3.1 Instantiation and access of the first type of terminal:

[0071] For the first type of terminal, it is instantiated in the form of a data object and managed uniformly by the agent entity.

[0072] Specifically, instead of creating separate containers, network namespaces, and dedicated virtual network interfaces for each Type I terminal, corresponding data objects are created for each Type I terminal within the proxy entity.

[0073] Each Class I terminal data object can store terminal identifier, service parameters, target access satellite identifier, and statistical information.

[0074] For example, for terminals T1, T2, and T3 of the first type, three data objects, Obj-1, Obj-2, and Obj-3, can be created in the proxy entity respectively, and recorded in the first type terminal object table: T1—Obj-1; T2—Obj-2; T3—Obj-3.

[0075] The proxy entity simulates the business behavior of the corresponding terminal based on the business parameters stored in each data object, including generating data according to a set period, generating business messages when specific events occur, and recording corresponding send and receive statistics.

[0076] The proxy entity accesses the satellite network-side virtual forwarding device through a shared forwarding channel, and the service data of multiple Type I terminals can reuse the same shared forwarding channel to enter the satellite network.

[0077] For example, 1000 Class I terminals can exist within the proxy entity as 1000 data objects, without needing to create 1000 network namespaces and 1000 independent virtual interfaces. When sending corresponding terminal services, the proxy entity determines the target satellite node corresponding to the service data based on the terminal identifier and the terminal-satellite connection relationship, and then sends the data to the virtual forwarding device through the shared forwarding channel.

[0078] The shared forwarding channel can use a TUN / TAP interface, a veth interface, a Socket channel, or a tunnel interface.

[0079] In order to distinguish service data belonging to different first-class terminals in the shared forwarding channel, the agent entity maintains a first-class terminal object table and identifies the corresponding terminal based on at least one of the following: terminal identifier, service context, source address information, port information, or internal service index of the agent entity.

[0080] Using the above method, when the number of the first type of terminals increases, there is no need to simultaneously increase the same number of complete operating environments and dedicated virtual interfaces, thus making it suitable for simulation scenarios that require simulating a large number of lightweight satellite terminals.

[0081] S3.2 Instantiation and access of the second type of terminal:

[0082] For the second type of terminal, an independent network namespace is created for each second type of terminal.

[0083] For example, create a network namespace NS-101 for terminal T101, and configure the IP address, routing table and protocol stack status of the terminal within NS-101; create a network namespace NS-102 for terminal T102, and configure the corresponding network parameters independently.

[0084] Therefore, different Type II terminals have mutually independent network protocol stack states.

[0085] Each type II terminal's corresponding network namespace is accessed by the terminal-side forwarding device via a veth pair. One end of the veth pair is located in the corresponding network namespace, and the other end is connected to the terminal-side forwarding device.

[0086] Multiple Type II terminals are first aggregated through a terminal-side forwarding device, and then connected to a satellite network-side virtual forwarding device through one or more uplink ports of the terminal-side forwarding device.

[0087] For example, T101, T102 to T150 can each have independent network namespaces, but their corresponding virtual interfaces can be connected to a single terminal-side forwarding device, which in turn connects to the satellite network-side virtual forwarding device via an uplink port. This maintains the independence of the network protocol stacks of different terminals while avoiding the need to configure a complete container or virtual machine runtime environment for each terminal.

[0088] Furthermore, for the multiple second-type terminals determined according to step S2, they can be further grouped according to the geographical area where each second-type terminal is located or the beam coverage area to which it belongs. Multiple second-type terminals in the same geographical area or the same beam coverage area are divided into terminal groups, and the network namespace corresponding interfaces of multiple second-type terminals in the same terminal group are associated with the same port group.

[0089] For example, for terminals T101 to T120 that have been identified as Category II terminals according to step S2, if they are all currently located within the Beam-A beam region, T101 to T120 can be grouped into the same terminal group, and the corresponding interfaces of each network namespace within this terminal group can be associated with the same port group. Simultaneously, a correspondence between the port group and the current target satellite node can be established. When the target satellite node corresponding to the terminal group changes, the forwarding paths of multiple Category II terminals can be adjusted in batches by updating the forwarding rules corresponding to the port group.

[0090] The port group is not limited to a specific data structure or switching device implementation. As long as an association can be formed between multiple second-type terminal interfaces and the unified forwarding policy, the batch forwarding rule update can be achieved.

[0091] S3.3 Instantiation and Access of the Third Type of Terminal:

[0092] For the third type of terminal, an independent operating environment is created for each third type of terminal.

[0093] In one implementation, containers are used as independent runtime environments for the third type of terminal. Each container has an independent file system, process space, and network protocol stack, and can run the terminal application or protocol program to be verified within the container.

[0094] For example, create a container (Container-501) for the third type of terminal (T501), run the actual terminal service program in the container, and configure the terminal's own network parameters.

[0095] In another implementation, virtual machines can be used instead of containers to provide a more complete operating system runtime environment.

[0096] Each Category 3 terminal accesses the satellite network-side virtual forwarding device through a dedicated virtual interface.

[0097] Therefore, unlike the method of multiple first-type terminals sharing a forwarding channel and multiple second-type terminals converging through terminal-side forwarding equipment, third-type terminals maintain a relatively independent operating environment and access interface, which is suitable for terminals that need to run actual business programs or require a high degree of simulation fidelity.

[0098] Step S3 allows for the simultaneous deployment of terminal simulation instances at the data object level, network namespace level, and complete operating environment level within the same satellite network simulation system, enabling terminals of different levels to ultimately access a unified satellite network-side virtual forwarding environment.

[0099] S4. Create satellite node simulation instances and connect each satellite node simulation instance to the virtual forwarding device.

[0100] Create satellite node simulation instances based on the satellite network topology to be simulated, and connect each satellite node simulation instance to the virtual forwarding device.

[0101] In one implementation, a simulation instance in the form of a container or network namespace is created for each satellite node, and each satellite node simulation instance is connected to the virtual forwarding device on the satellite network side via a veth pair.

[0102] For example, when the satellite network to be simulated includes N satellite nodes, simulation instances Sat-1, Sat-2, ..., Sat-N corresponding to each satellite node can be created, and corresponding node identifiers and virtual interfaces can be configured for different satellite nodes.

[0103] Satellite node simulation instances are not limited to containers or network namespaces. When a more complete operating system runtime environment needs to be simulated, a virtual machine can also be used as a satellite node simulation instance.

[0104] The virtual forwarding device can be Open vSwitch, Linux Bridge, or a virtual routing device with corresponding virtual packet forwarding capabilities.

[0105] In one specific implementation, Open vSwitch is used as a virtual forwarding device on the satellite network side. The veth interface corresponding to each satellite node is connected to the Open vSwitch port, so that the virtual forwarding device can control the forwarding of packets between different satellite nodes and between the terminal and the satellite node according to the forwarding rules.

[0106] S5. Establish a terminal-satellite connection relationship table and configure forwarding rules between the terminal and the satellite, and between satellites.

[0107] After instantiating terminals of each level, the satellite node corresponding to each terminal is determined based on the current satellite coverage or pre-calculated terminal access results. The control plane establishes a terminal-satellite connection table.

[0108] The terminal-satellite connection table records at least the terminal identifier, terminal level, current corresponding satellite node identifier, and access channel information.

[0109] In one implementation, the connection table should at least resemble Table 2:

[0110] Table 2: T1 Type 1 terminal Sat-3 Shared forwarding channel A — — T101 Second type of terminal Sat-4 NS-101 corresponding interface — — T501 Third type of terminal Sat-2 Dedicated Virtual Interface 501 — —

[0111] The satellite node currently corresponding to the terminal can be provided by an external orbit calculation module, a satellite coverage analysis module, or the calculation results of an existing network topology. Alternatively, it can be determined based on information such as the terminal location, satellite location, and beam coverage relationship.

[0112] This invention primarily addresses how, after obtaining the current connection relationship between the terminal and the satellite, corresponding access channels are established based on the instantiation methods of terminals of different levels, and data forwarding is completed through a unified virtual forwarding environment.

[0113] The control plane generates corresponding forwarding rules based on the terminal-satellite connection table and sends the forwarding rules to the corresponding virtual forwarding devices, so that the messages of the three levels of terminals can be forwarded to their respective current satellite nodes.

[0114] Furthermore, the control plane sends corresponding satellite-to-satellite forwarding rules to the virtual forwarding device based on the actual satellite-to-satellite topology relationships to be simulated.

[0115] For example, if there is an inter-satellite connection between Sat-1 and Sat-2 in the topology to be simulated, the corresponding forwarding relationship between Sat-1 and Sat-2 can be configured in the virtual forwarding device so that the messages sent from Sat-1 to Sat-2 can be transmitted in accordance with the inter-satellite forwarding rules.

[0116] The satellite-to-satellite forwarding rules can be implemented using Open vSwitch flow table rules, Linux Bridge forwarding, or routing rules. All of these different implementation methods are used to establish data transmission paths corresponding to the satellite network topology to be simulated.

[0117] In implementations that use Open vSwitch as a virtual forwarding device, corresponding flow table rules can be issued to Open vSwitch via the OpenFlow protocol.

[0118] In addition to the OpenFlow protocol, corresponding forwarding rules can also be configured through the OVSDB interface, command line interface, or Netlink interface.

[0119] For the first type of terminal, the agent entity identifies the terminal to which the current service data belongs based on the first type of terminal object table, and queries the terminal-satellite connection relationship table to obtain the satellite node currently corresponding to that terminal. Subsequently, the service data enters the virtual forwarding device on the satellite network side through the shared forwarding channel, and is forwarded to the target satellite node according to the corresponding forwarding rules.

[0120] For example, if terminal T1 currently corresponds to Sat-3, after the agent entity identifies the service data generated by T1, it determines the target node as Sat-3 based on the terminal-satellite connection relationship, and then forwards the service data to Sat-3 after entering the virtual forwarding device through the shared forwarding channel.

[0121] For the second type of terminal, service data first enters the terminal-side forwarding device through the virtual interface in the corresponding network namespace. Based on the forwarding rules corresponding to the interface, address, or port group, the terminal-side forwarding device sends the service data via the uplink port to the satellite network-side virtual forwarding device, and then further forwards it to the corresponding satellite node.

[0122] For example, if T101 corresponds to the network namespace NS-101, and the terminal-satellite connection relationship table records that T101 currently corresponds to Sat-4, then the message generated by NS-101 enters the terminal-side forwarding device via the veth pair, and is further forwarded to Sat-4 according to the corresponding forwarding rules.

[0123] For the third type of terminal, the terminal service program generates service messages in its independent operating environment. The service messages enter the satellite network-side virtual forwarding device through the dedicated virtual interface corresponding to the terminal, and are then sent to the corresponding satellite node according to the forwarding rules corresponding to the dedicated virtual interface.

[0124] Therefore, although the three levels of terminals use different instantiation forms and access channels, they can still achieve unified satellite node access and service data forwarding through the terminal-satellite connection relationship table and virtual forwarding equipment.

[0125] Example 2:

[0126] This embodiment, based on Embodiment 1, adds a step of dynamically updating the access relationship when the satellite node corresponding to the terminal changes. Specifically, during the simulation, when the satellite node currently corresponding to the terminal changes due to satellite orbit movement, changes in terminal position, or changes in beam coverage, the access relationship can be dynamically updated based on the terminal-satellite connection relationship and forwarding rules established in step S5.

[0127] For example, a terminal originally corresponds to satellite node Sat-A, but after simulation time t, its target satellite node changes to Sat-B. After the control plane obtains this change, it adopts the corresponding forwarding relationship update method according to the terminal level.

[0128] For the first type of terminal, it is not necessary to recreate the terminal data object or create a new independent network environment for the terminal. The control plane or agent entity updates the target satellite node in the terminal-satellite connection relationship from Sat-A to Sat-B, and updates the forwarding rules in the virtual forwarding device on the satellite network side corresponding to the shared forwarding channel, so that the service data subsequently generated by the terminal is forwarded to Sat-B.

[0129] For the second type of terminal, the original network namespace of the terminal remains unchanged. That is, there is no need to recreate its IP address, routing table and protocol stack runtime environment. Instead, the forwarding rules corresponding to the terminal in the forwarding device on the terminal side are updated so that subsequent traffic is switched from the original path corresponding to Sat-A to the path corresponding to Sat-B.

[0130] For the third type of terminal, its independent operating environment in the form of a container or virtual machine remains running, and only the forwarding path corresponding to the dedicated virtual interface of the third type of terminal is updated, so that subsequent business data is forwarded to Sat-B.

[0131] Using the above method, when the satellite node corresponding to the terminal changes, the change in the terminal access relationship can be mainly accomplished by modifying the connection relationship and the corresponding forwarding rules.

[0132] Furthermore, for the multiple second-type terminals determined according to step S2, they can be further grouped according to the geographical area where each second-type terminal is located or the beam coverage area to which it belongs. Multiple second-type terminals in the same geographical area or the same beam coverage area are divided into terminal groups, and the network namespace corresponding interfaces of multiple second-type terminals in the same terminal group are associated with the same port group.

[0133] For example, terminals T101 to T120 of the second type are all located in the Beam-A area and are classified into the same terminal group, which currently uniformly corresponds to Sat-A. When satellite movement causes the target satellite corresponding to the terminal group to change from Sat-A to Sat-B, the forwarding rules corresponding to the associated port group of the terminal group can be directly updated, so that the traffic of T101 to T120 is uniformly forwarded to Sat-B.

[0134] This reduces the number of forwarding rules that need to be modified when a large number of Type II terminals within the same terminal group experience simultaneous changes in their access relationships.

[0135] Example 3:

[0136] Based on Example 1, after creating and accessing the terminal simulation instance and satellite node simulation instance in steps S3 and S4, this embodiment can further configure the access link parameters to simulate the actual link transmission characteristics in a satellite network. The access link refers to the simulated link through which the terminal simulation instance and satellite node simulation instance communicate with the virtual forwarding device.

[0137] In a specific implementation within a Linux network environment, propagation delay, bandwidth limitation, jitter, and packet loss rate can be configured for the corresponding access link using Linux tc qdisc flow control technology.

[0138] For example, on the satellite node side, link parameters can be configured on the access links between simulated satellite nodes such as Sat-1 and Sat-2 and virtual forwarding devices. Combined with the inter-satellite propagation distance, link capacity, and link quality in the simulated satellite network, propagation delay, bandwidth limits, jitter, and packet loss rate can be set on the access links carrying the corresponding inter-satellite communication traffic. On the terminal side, corresponding link parameters can be configured on access links such as the shared forwarding channel of the proxy entity, the veth interface corresponding to the second type of terminal or the uplink connection of the terminal-side forwarding device, and the dedicated virtual interface corresponding to the third type of terminal, according to the access methods of different terminal levels, to simulate the link transmission characteristics during the terminal's access to the satellite.

[0139] During the simulation, when the relative position of the satellite node, the terminal position, or the link parameters given by the external link status calculation module change, the tc qdisc configuration of the corresponding access link can be dynamically modified without deleting and re-establishing the terminal simulation instance, satellite node simulation instance, or the corresponding access link.

[0140] For example, when the access link used to carry communication traffic between Sat-1 and Sat-2 needs to simulate a larger propagation delay, the propagation delay of the corresponding access link can be increased according to the updated link parameters; when the quality of the access link between a terminal and its target satellite changes, the tc qdisc configuration on the corresponding access path of the terminal can also be updated according to the new bandwidth, jitter or packet loss parameters.

[0141] The above method allows for the dynamic simulation of changes in link quality over time while maintaining the virtual topology of the satellite network.

[0142] Example 4:

[0143] Based on Example 1, this embodiment adds the step of collecting simulation status and resource occupancy status. Specifically, after completing the establishment of the terminal-satellite connection relationship table and the configuration of forwarding rules in step S5, the simulation operation phase begins. In the simulation operation phase, the terminal instantiation status and resource occupancy status can be further collected.

[0144] The terminal instantiation status includes the number of first-type terminal objects, the number of second-type terminal network namespaces, and the number of third-type terminal independent operating environments.

[0145] The number of the first type of terminal objects can be obtained from the first type of terminal object table maintained by the proxy entity; the number of the second type of terminal network namespaces can be obtained from the statistics of the currently created terminal network namespaces; and the number of the third type of terminal independent running environments can be obtained from the currently created container or virtual machine instances.

[0146] The resource occupancy status includes the number of container instances, the number of network namespaces, the number of virtual forwarding device ports, and the number of flow table rules.

[0147] For example, when using Open vSwitch as a virtual forwarding device, the current switch port configuration and flow table status can be read through the management interface of Open vSwitch to obtain the number of virtual ports currently in use and the number of flow table rules.

[0148] When using Linux Bridge or other virtual forwarding devices, the number of virtual interfaces and forwarding rules with the same technical meaning can be obtained through the corresponding management interface or system network status interface.

[0149] By collecting the above states under different terminal scales and different terminal level combinations, the impact of different terminal instantiation granularities on the virtual resource usage of the simulation system can be analyzed.

[0150] For example, under the same total number of terminals, the number of container instances, network namespaces, virtual ports, and forwarding rules can be counted separately when all terminals are instantiated using a complete runtime environment and when they are instantiated using the first, second, and third types of terminals, thereby obtaining the resource usage corresponding to different instantiation schemes.

[0151] Example 5:

[0152] The working process of the satellite network terminal hierarchical access simulation system described in this invention will be illustrated below with a specific application scenario.

[0153] In this embodiment, it is assumed that the satellite network to be simulated contains 6 low-Earth orbit satellite nodes (Sat-1 to Sat-6), and the terminals to be simulated include: 2000 first-class terminals (simulating IoT sensor terminals, periodically reporting location and status data), 500 second-class terminals (simulating voice call terminals, requiring to maintain a continuous session state), and 10 third-class terminals (simulating key command and control link terminals, requiring a high degree of isolation operating environment).

[0154] System initialization phase:

[0155] First, the satellite network-side module creates six satellite node simulation instances based on the satellite network topology. In this embodiment, a Docker container is created for each satellite node, and each container is connected to the satellite network-side virtual forwarding device (implemented using Open vSwitch) via a veth pair. Based on the topological relationships between satellites, forwarding rules between satellite nodes are configured in Open vSwitch; for example, forwarding rules between Sat-1 and Sat-2, and between Sat-2 and Sat-3, are configured according to the orbital topology. Simultaneously, link parameters such as propagation delay and bandwidth limits are configured for the access link between the satellite node simulation instances and the virtual forwarding device using Linux tc qdisc.

[0156] Secondly, the terminal-side module creates terminal simulation instances according to the terminal level:

[0157] For 2000 Category 1 terminals, the terminal-side module creates a proxy entity (user-space process). Within the proxy entity, a data object is created for each Category 1 terminal. Each data object records the terminal identifier (T1 to T2000), service parameters (message generation period of 10 seconds, data packet size of 128 bytes), target access satellite identifier (initially Sat-3), and statistical information. The proxy entity accesses the satellite network-side virtual forwarding device through a TUN / TAP shared forwarding channel and can configure propagation delay, bandwidth limits, jitter, and packet loss rate on the access link corresponding to the shared forwarding channel via Linux tc qdisc.

[0158] For the 500 Category II terminals, the terminal-side module creates an independent Linux network namespace (NS-101 to NS-600) for each terminal. Each namespace is configured with an independent IP address (10.0.1.0 / 24 network segment) and routing table. Each namespace connects to the terminal-side forwarding device (implemented using Linux Bridge) via a veth pair. After the 500 terminals are identified as Category II terminals according to step S2, they are further divided into 5 terminal groups (100 terminals per group) based on their geographical location. Within the same terminal group, the interfaces corresponding to each network namespace are associated with the same port group. The terminal-side forwarding device connects to the satellite network-side virtual forwarding device through an uplink port and can configure link parameters on the veth interface corresponding to the Category II terminal or on the access link corresponding to the uplink connection.

[0159] For the 10 Category 3 terminals, the terminal-side module creates an independent Docker container for each terminal, with each container having its own file system, process space, and network protocol stack. Each Category 3 terminal directly connects to the satellite network-side virtual forwarding device through a dedicated virtual interface, and can configure link parameters such as propagation delay, bandwidth limit, jitter, and packet loss rate on the access link corresponding to the dedicated virtual interface.

[0160] Connection establishment phase:

[0161] The control plane module establishes a terminal-satellite connection table based on the satellite coverage calculation results. For example, the first type of terminals T1 to T1000 currently correspond to Sat-3, and T1001 to T2000 currently correspond to Sat-4; the second type of terminals, area group 1 (NS-101 to NS-200) corresponds to Sat-3, and area group 2 (NS-201 to NS-300) corresponds to Sat-4; the third type of terminals, C1 to C5, correspond to Sat-2, and C6 to C10 correspond to Sat-5.

[0162] The control plane module issues forwarding rules to the virtual forwarding device on the satellite network side based on the aforementioned terminal-satellite connection table and the satellite-to-satellite topology. For the first type of terminal, forwarding rules are configured between the shared forwarding channel port of the proxy entity and the Sat-3 and Sat-4 ports; for the second type of terminal, forwarding rules are configured between the uplink port of the terminal-side forwarding device and the ports of each satellite node; for the third type of terminal, forwarding rules are configured between each dedicated virtual interface and the corresponding satellite node port; simultaneously, forwarding rules are configured between satellite nodes such as Sat-1 and Sat-2, and Sat-2 and Sat-3, according to the satellite-to-satellite topology.

[0163] Simulation run phase:

[0164] The first type of terminal T1 generates uplink messages every 10 seconds. The agent entity generates messages based on the service parameters in the terminal object table, queries the terminal-satellite connection table to determine the current corresponding Sat-3 for T1, encapsulates the messages, and sends them to the virtual forwarding device on the satellite network side through the shared forwarding channel. The virtual forwarding device forwards the messages to Sat-3 according to the forwarding rules.

[0165] The voice call program running in the Type 2 terminal NS-101 generates RTP packets. The packets enter the terminal-side forwarding device from the virtual network card of NS-101. The terminal-side forwarding device sends the packets to the satellite network-side virtual forwarding device through the uplink port according to the mapping relationship between the port group and the satellite. The virtual forwarding device forwards the packets to Sat-3.

[0166] The critical command and control program running in the third-generation terminal C1 generates encrypted control messages. These messages enter the satellite network-side virtual forwarding device through C1's dedicated virtual interface, and the virtual forwarding device forwards the messages to Sat-2.

[0167] Dynamic update phase:

[0168] At t=300 seconds into the simulation, due to satellite orbital motion, the target satellite for terminal group 1 (NS-101 to NS-200) changed from Sat-3 to Sat-5. Upon detecting this change, the control plane module did not recreate any terminal instances or network namespaces. Instead, it directly modified the forwarding rules of the port group associated with terminal group 1 in the terminal-side forwarding equipment, changing the target from Sat-3 to Sat-5. After the modification, the service traffic of 100 Category 2 terminals within terminal group 1 was uniformly switched to Sat-5, achieving batch connection updates.

[0169] Meanwhile, when satellite motion increases the distance between Sat-1 and Sat-2, requiring an increase in the simulated propagation delay of the corresponding inter-satellite communication from 10ms to 25ms, the control plane module dynamically updates the access link parameters of the corresponding satellite node carrying the communication traffic via Linux tc qdisc based on the link status information provided by the external orbit calculation module. When changes in terminal location lead to changes in the quality of the terminal-side access link, the same method can be used to dynamically update the propagation delay, bandwidth limitation, jitter, or packet loss rate of the corresponding terminal access link.

[0170] As can be seen from the above system embodiments, the system of the present invention, through a three-level terminal hierarchical instantiation mechanism, enables 2000 first-type terminals to complete access with only one proxy entity and one shared forwarding channel, 500 second-type terminals to complete access with only 500 network namespaces (no need for 500 containers), and 10 third-type terminals to complete access with only 10 containers. Compared with the traditional "one terminal, one container" scheme (requiring 2510 containers), the present invention significantly reduces the number of container instances, while efficiently completing terminal switching through a regional batch update mechanism.

Claims

1. A simulation method for hierarchical access of satellite network terminals, characterized in that, Perform the following steps in sequence: S1. Obtain the service characteristic parameters of the terminal to be simulated, including state maintenance requirement parameters, protocol stack independence requirement parameters, and operating environment isolation requirement parameters; S2. Based on the service characteristic parameters, the terminal to be simulated is divided into three levels: when the state retention requirement parameter indicates that it is not necessary to maintain a continuous session state and the protocol stack independence requirement parameter indicates that it is not necessary to have an independent network protocol stack, the terminal is classified as a first-class terminal; when the state retention requirement parameter indicates that it is necessary to maintain a continuous session state or the protocol stack independence requirement parameter indicates that it is necessary to have an independent network protocol stack, and the runtime environment isolation requirement parameter indicates that it is not necessary to have a complete runtime environment, the terminal is classified as a third-class terminal; when the runtime environment isolation requirement parameter indicates that it is necessary to have a complete runtime environment, the terminal is classified as a third-class terminal. S3. Create terminal emulation instances and connect each terminal emulation instance to the virtual forwarding device; For the first type of terminal, it is instantiated in the form of a data object and managed uniformly by a proxy entity. The proxy entity accesses the virtual forwarding device through a shared forwarding channel. For the second type of terminal, an independent network namespace is created for each terminal of this type, and the network namespaces of multiple second type terminals are connected to the virtual forwarding device through the terminal-side forwarding device. For the third type of terminal, an independent operating environment is created for each terminal of this type, and each third type of terminal accesses the virtual forwarding device through a dedicated virtual interface; S4. Create satellite node simulation instances and connect each satellite node simulation instance to the virtual forwarding device; The steps for creating satellite node simulation instances include: creating a simulation instance in the form of a container or network namespace for each satellite node, and connecting each satellite node to the virtual forwarding device; Using S3 and S4, the network topology between the terminal simulation instance and the satellite node simulation instance is constructed. S5. Establish a terminal-satellite connection relationship table and configure forwarding rules between the terminal and the satellite, and between satellites; The terminal-satellite connection table records at least the terminal identifier, terminal level, current corresponding satellite node identifier, and access channel information for each terminal. Based on the terminal-satellite connection table, forwarding rules are issued to the virtual forwarding device. Messages from all three levels of terminals are forwarded to the corresponding satellite nodes via the virtual forwarding device. Furthermore, based on the satellite-to-satellite topology, corresponding satellite-to-satellite forwarding rules are issued to the virtual forwarding device.

2. The method according to claim 1, characterized in that, The data object of the first type of terminal stores terminal identifier, service parameters, target access satellite identifier, and statistical information. The proxy entity maintains the object table and terminal-satellite connection relationship table of the first type of terminal and sends the service data of multiple first type terminals to the corresponding satellite node via the same shared forwarding channel. The network namespace of the second type of terminal has independent IP address, routing table, and protocol stack status, and is connected to the terminal-side forwarding device through a veth pair. The independent operating environment of the third type of terminal is a container or virtual machine, with an independent file system, process space, and network protocol stack.

3. The method according to claim 1 or 2, characterized in that, The virtual forwarding device can be any one of Open vSwitch, Linux Bridge, and virtual routing device.

4. The method according to claim 1, characterized in that, The forwarding rules are issued through any one of the following methods: OpenFlow protocol, OVSDB interface, command line interface, and Netlink interface.

5. The method according to claim 1, characterized in that, In step S5, when the satellite node corresponding to the terminal changes: For the first type of terminal, update the terminal-satellite connection relationship table in the proxy entity and the forwarding rules corresponding to the shared forwarding channel in the virtual forwarding device; For the second type of terminal, update the forwarding rules in the terminal-side forwarding device; For the third type of terminal, update the forwarding path corresponding to the dedicated virtual interface.

6. The method according to claim 5, characterized in that, For the multiple second-type terminals determined in step S2, the multiple second-type terminals located in the same geographical area or the same beam coverage area are further divided into terminal groups according to the geographical area or the beam coverage area to which each second-type terminal is located. The network namespace corresponding interfaces of multiple second-type terminals in the same terminal group are associated with the same port group. When the target satellite node corresponding to a terminal group changes, the forwarding rules of the port group associated with the terminal group are updated in batches so that the traffic of multiple second-type terminals in the terminal group is forwarded to the new satellite node in a unified manner.

7. The method according to claim 1, characterized in that, After steps S3 and S4 complete the creation and access of the terminal simulation instance and the satellite node simulation instance, the steps also include the parameter configuration of the access link: configuring the propagation delay, bandwidth limit, jitter and packet loss rate of the access link using Linux tc qdisc flow control technology, and dynamically updating the link parameters of the access link according to changes in link quality; the access link refers to the simulation link through which the terminal simulation instance and the satellite node simulation instance communicate with the virtual forwarding device.

8. The method according to claim 1, characterized in that, After completing the establishment of the terminal-satellite connection table and configuration of forwarding rules in step S5, the simulation operation phase begins. The simulation operation phase also includes a simulation status acquisition step: acquiring the terminal instantiation status and resource occupancy status. The terminal instantiation status includes the number of first-type terminal objects, the number of second-type terminal network namespaces, and the number of third-type terminal independent operating environments. The resource occupancy status includes the number of container instances, the number of network namespaces, the number of virtual forwarding device ports, and the number of flow table rules.

9. A satellite network terminal hierarchical access simulation system, wherein the system is implemented using the method described in any one of claims 1 to 8, characterized in that, include: The satellite network side module includes multiple satellite node simulation instances and a satellite network side virtual forwarding device. The satellite node simulation instances are connected to the satellite network side virtual forwarding device through an access link. The satellite network side virtual forwarding device is configured with forwarding rules between satellite nodes. The terminal-side module includes terminal simulation instances instantiated according to different levels: the first type of terminal exists in the form of data objects and is uniformly managed by a proxy entity, which accesses the satellite network-side virtual forwarding device through a shared forwarding channel; the second type of terminal each corresponds to an independent network namespace, and the network namespaces of multiple second type terminals are accessed by the terminal-side forwarding device, which is connected to the satellite network-side virtual forwarding device through an uplink port. Each of the third-class terminals has its own independent operating environment, and each third-class terminal connects to the satellite network-side virtual forwarding device through a dedicated virtual interface. The control plane module is used to maintain the terminal-satellite connection relationship table and issue forwarding rules to the virtual forwarding device on the satellite network side according to the terminal-satellite connection relationship table and the topology between satellites; The control plane module is also used to: when the satellite node corresponding to the terminal changes, update the terminal-satellite connection relationship table in the proxy entity and the corresponding forwarding rules in the satellite network-side virtual forwarding device for the first type of terminal; update the forwarding rules in the terminal-side forwarding device for the second type of terminal; and update the forwarding path corresponding to the dedicated virtual interface for the third type of terminal. The satellite node simulation instance is any one of container, network namespace, and virtual machine; the satellite network-side virtual forwarding device is any one of Open vSwitch, Linux Bridge, and virtual routing device; the forwarding rules are implemented through any one of Open vSwitch flow table rules and Linux Bridge routing rules; the access link is implemented through any one of tunnel interface and veth pair; the proxy entity is a user-space process; and the shared forwarding channel is any one of TUN / TAP interface, veth interface, Socket channel, and tunnel interface.

Images