A test method, test system and electronic device of a satellite communication system

Abstract

The application discloses a kind of satellite communication system test method, test system and electronic equipment.The application is successfully solved the conflict problem of multiple virtual users sharing single radio channel by virtualizing multiple independent running terminal instances on single physical terminal hardware and with the aid of preset unified back channel resource and time slot conflict arbitration mechanism, to realize the multiple user concurrent test of satellite communication system using real hardware.The method not only covers the complete signal link from the primary station modem radio frequency front end to the high layer protocol processing node, ensures the high confidence and authenticity of test results, but also can be compatible with the introduction of real channel impairment environment, while greatly reducing the cost and complexity of a large number of hardware equipment required by traditional multi-user test, to realize efficient, high-fidelity end-to-end system verification.

Description

Technical Field

[0001] This invention relates to the field of satellite communication technology, and more specifically to a testing method, testing system, and electronic equipment for a satellite communication system. Background Technology

[0002] MF-TDMA (Multi-Frequency Time Division Multiple Access) is a multi-user access technology in the field of satellite communication. By combining frequency division multiplexing and time division multiplexing, it supports a large number of users to access the network concurrently on different frequencies and time slots. It features flexible resource scheduling and high spectrum utilization and has been applied to broadband satellite communication systems.

[0003] In related technologies, for multi-user full-link testing of MF-TDMA satellite communication systems, there is a technical problem that the use of pure software simulation cannot cover the physical radio frequency link and key equipment, resulting in low confidence of the test results. Summary of the Invention

[0004] The technical problem this invention aims to solve is that, in related technologies, multi-user full-link testing of MF-TDMA satellite communication systems suffers from low confidence levels due to the inability to cover the physical radio frequency link and key equipment caused by using pure software simulation. The purpose is to provide a testing method, testing system, and electronic equipment for satellite communication systems, thereby resolving the problem of low confidence levels in test results.

[0005] This invention is achieved through the following technical solution:

[0006] In a first aspect, the present invention provides a testing method for a satellite communication system, the satellite communication system comprising a terminal equipment side and a master station equipment side; the method comprising:

[0007] On the terminal device side, multiple virtual terminal instances are created and maintained; each virtual terminal instance has an independent user identifier and protocol state machine, and the multiple virtual terminal instances compete to share the same physical radio frequency transmission channel; the multiple virtual terminal instances are preset to use the same return channel resources;

[0008] Generate multiple time slots to be sent for the multiple virtual terminal instances;

[0009] Time overlap detection is performed on the multiple time slots, and a time slot is selected from the overlapping time slots according to a preset conflict arbitration strategy and sent to the master station equipment via the physical radio frequency transmission channel, while other overlapping time slots are discarded; wherein, by sending the selected time slot, multi-user concurrent access and service behavior are simulated for testing the satellite communication system.

[0010] Furthermore, the step of creating and maintaining multiple virtual terminal instances on the terminal device side includes:

[0011] Load a preset configuration file; wherein, the configuration file defines independent user identification information, authentication information and business test parameter information for multiple virtual terminal instances;

[0012] The configuration file is parsed to create and initialize an independent virtual terminal instance for each defined user on a single hardware platform of the terminal device. Each virtual terminal instance maintains its own protocol state machine and service context and maps them to a shared physical radio frequency transmission channel.

[0013] Furthermore, the step of generating multiple time slots to be sent for the multiple virtual terminal instances includes...

[0014] In response to the state transition of the protocol state machine of each virtual terminal instance, a time slot to be transmitted corresponding to the current state is generated; wherein the parameters of the time slot to be transmitted are matched with the same return channel resources, and the type includes at least one of ALOHA login time slot, control time slot or service time slot.

[0015] Further, the step of performing time overlap detection on the multiple time slots and selecting one time slot from the overlapping time slots according to a preset conflict arbitration strategy, transmitting it to the master station equipment via the physical radio frequency transmission channel, and discarding other overlapping time slots includes:

[0016] For multiple time slots to be transmitted, calculate the start and end times of each time slot to determine the time interval corresponding to each time slot;

[0017] By determining whether the time intervals of any two time slots intersect, it is determined whether the two time slots overlap in time sequence;

[0018] If overlapping time slots are determined to exist, a preset arbitration rule is executed; wherein, the preset arbitration rule includes: if the overlapping time slots include a control time slot, then the control time slot is determined as the target transmission time slot; if the overlapping time slots are all ALOHA login time slots, then the ALOHA login time slot with the earliest start time is determined as the target transmission time slot.

[0019] The target transmission time slot is transmitted to the master station equipment via the physical radio frequency transmission channel, while all other time slots that overlap with the target transmission time slot are discarded.

[0020] Furthermore, the protocol state machine of the virtual terminal instance includes at least a standby state, an ALOHA login state, and an online state; wherein, when in the ALOHA login state, an ALOHA login time slot is generated; when in the online state, a control time slot or a service time slot is generated; when in the standby state, no time slot to be sent is generated; wherein, if the protocol state machine exits from the ALOHA login state due to failure, it re-enters the ALOHA login state and does not return to the standby state.

[0021] Furthermore, the step of simulating multi-user concurrent access and service behavior by sending selected time slots for testing the satellite communication system includes:

[0022] After the virtual terminal instance successfully accesses the network based on its user identification information and authentication information, it initiates a capacity request to the main station device and sends a test data packet carrying a serial number based on the business test parameter information defined in the configuration file and the allocated time slot, and / or receives a forward test data packet from the main station device; wherein, the serial number is filled in for the sent test data packet, and the serial number and data content of the received test data packet are verified.

[0023] Based on the verification results of the serial number and data content, the data transmission quality is evaluated to complete the performance verification of the satellite communication system; wherein, the performance verification is an end-to-end performance verification; wherein, the end-to-end performance verification includes at least the performance verification of the radio frequency modem and the higher-layer protocol processing node in the master station equipment.

[0024] Furthermore, the service test parameter information includes back-end service test parameters and forward-end service test parameters; wherein, both the back-end service test parameters and the forward-end service test parameters include at least an enable flag, a test rate, a test duration, and test data content.

[0025] Furthermore, the multiple virtual terminal instances are preset to use the same return channel resources, specifically including:

[0026] On the main station device side, user accounts of all virtual terminal instances belonging to the same terminal device side are configured with the same return channel parameters; wherein, the return channel parameters include center frequency, symbol rate and roll-off factor;

[0027] In this context, after the multiple virtual terminal instances access the network, all their data transmissions are constrained to the same back-return channel resource defined by the same back-return channel parameters.

[0028] Secondly, the present invention provides a test system for satellite communication, comprising:

[0029] On the terminal device side, it includes at least one terminal device configured to create and maintain multiple virtual terminal instances; each virtual terminal instance has an independent user identifier and protocol state machine, and the multiple virtual terminal instances compete to share the same physical radio frequency transmission channel; the multiple virtual terminal instances are preset to use the same return channel resources; multiple time slots to be transmitted are generated for the multiple virtual terminal instances; time overlap detection is performed on the multiple time slots, and a time slot is selected from the overlapping time slots according to a preset conflict arbitration strategy and transmitted to the master station device side via the physical radio frequency transmission channel, while other overlapping time slots are discarded; wherein, by transmitting the selected time slot, multi-user concurrent access and service behavior are simulated for testing the satellite communication system;

[0030] On the master station equipment side, the master station equipment side establishes a communication connection with the terminal equipment side and is configured to respond to and process the multi-user concurrent access and service behavior initiated by the terminal equipment side in order to complete the test of the satellite communication system.

[0031] Thirdly, the present invention provides an electronic device, comprising: a memory, and one or more processors communicatively connected to the memory; the memory stores instructions executable by the one or more processors, the instructions being executed by the one or more processors to enable the one or more processors to implement the above-described test method for a satellite communication system.

[0032] Compared with the prior art, the present invention has the following advantages and beneficial effects:

[0033] This invention virtualizes multiple independently running terminal instances on a single physical terminal hardware and successfully resolves the conflict problem of multiple virtual users sharing a single radio frequency channel by leveraging a pre-defined unified return channel resource and time slot conflict arbitration mechanism. This enables multi-user concurrent testing of satellite communication systems using real hardware. This method not only covers the complete signal link from the master station modem radio frequency front-end to the higher-layer protocol processing node, ensuring high confidence and authenticity of the test results, but also accommodates the introduction of real channel impairment environments. Furthermore, it significantly reduces the cost and complexity of the large amount of hardware required for traditional multi-user testing, achieving high-efficiency, high-fidelity end-to-end system verification. Attached Figure Description

[0034] To more clearly illustrate the technical solutions of the exemplary embodiments of the present invention, the accompanying drawings used in the embodiments will be briefly described below. It should be understood that the following drawings only show some embodiments of the present invention and should not be considered as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort. In the drawings:

[0035] Figure 1 A flowchart illustrating a test method for a satellite communication system provided in the embodiments of this specification;

[0036] Figure 2 This is an architecture diagram of a test system for satellite communication provided in the embodiments of this specification;

[0037] Figure 3 A flowchart illustrating multi-user access provided in the embodiments of this specification;

[0038] Figure 4 This is a schematic diagram illustrating the aggregation and transmission process of time slots for different users in a terminal device, as provided in the embodiments of this specification. Detailed Implementation

[0039] To make the objectives, technical solutions, and advantages of the present invention clearer, the present invention will be further described in detail below with reference to the embodiments and accompanying drawings. The illustrative embodiments and descriptions of the present invention are only used to explain the present invention and are not intended to limit the present invention.

[0040] In a potential MF-TDMA (Multi-Frequency Time Division Multiple Access) satellite communication system, the system mainly comprises a ground-based master station and terminal equipment distributed across various locations. The master station may include modulators and demodulators for radio frequency signal modulation and demodulation, network control equipment for resource scheduling and access management, gateways and servers for processing service data and signaling, and other equipment. The terminal equipment may include a large number of satellite communication terminals, each acting as a single user accessing the satellite network and interacting with the master station via a radio frequency link to complete access, synchronization, and service data transmission.

[0041] To evaluate the performance and stability of satellite communication systems, especially in multi-user concurrent scenarios, thorough testing is necessary. One possible testing method is pure software simulation. Specifically, this approach often involves using a test software simulator at the master station to simulate the behavior of a large number of end users. This simulator can generate higher-level signaling and service data packets according to protocol specifications and interact directly with the master station's server or gateway via network interfaces such as Ethernet, thereby verifying the system's capabilities in higher-level protocol processing, session management, and data routing.

[0042] However, this purely software-simulated testing method has fundamental limitations, leading to insufficient confidence in the test results. First, this method completely bypasses the critical RF hardware on the master station side, namely the modulator and demodulator. Therefore, it cannot evaluate key physical layer performance aspects such as the transmission quality of the RF signal, receiver sensitivity, and the ability to suppress nonlinear distortion and adjacent channel interference. Second, since the test data stream does not pass through a real RF channel, it cannot simulate and verify the system's adaptability and robustness under real satellite channel impairments such as Doppler shift, transmission delay, and signal attenuation. Finally, software simulators cannot fully and accurately reproduce all the behaviors of a real terminal at the physical and link layers (e.g., precise time-frequency offset synchronization and tracking processes, real-time response to power control commands, etc.), resulting in a discrepancy between the test scenario and the actual behavior of the terminal, thus reducing the fidelity of the test.

[0043] In summary, among the relevant technologies, the multi-user full-link testing of MF-TDMA satellite communication systems suffers from a technical problem: the use of pure software simulation cannot cover the physical radio frequency link and key equipment, resulting in low confidence of the test results.

[0044] The concept of this invention is to create multiple independent virtual terminal instances based on real terminal hardware on a multi-user virtualized terminal device and resolve the time slot conflict caused by multiple instances sharing a single radio frequency channel, thereby enabling end-to-end full-link testing of satellite communication systems, including radio frequency modems, to solve the problem of insufficient test confidence mentioned above.

[0045] like Figure 1 As shown, this embodiment provides a testing method for a satellite communication system, the satellite communication system including a terminal equipment side and a master station equipment side; the method includes:

[0046] Step S12: On the terminal device side, create and maintain multiple virtual terminal instances; wherein each virtual terminal instance has an independent user identifier and protocol state machine, and the multiple virtual terminal instances compete to share the same physical radio frequency transmission channel; wherein the multiple virtual terminal instances are preset to use the same return channel resources.

[0047] In this embodiment, the virtual terminal instance can be represented as an independent virtual communication entity built on a single physical satellite terminal hardware on the terminal device side based on software virtualization technology, and having the same communication function logic as the physical satellite terminal.

[0048] In this embodiment, the independent user identifier is used to uniquely identify the instance's identity within the network. Specifically, it can be a hardware ID, International Mobile Subscriber Identity (IMSI), or other system-defined identifiers. This user identifier is used for registration with the master station during the access phase. The independent protocol state machine can be represented as a state transition logic module built into the virtual terminal instance and conforming to the MF-TDMA satellite communication system communication protocol. It can switch working states and trigger corresponding communication behaviors according to the communication process. In one possible and specific implementation, the protocol state machine can be based on a finite state machine model or an event-driven architecture, where state transitions are triggered by external events (receiving broadcast signals) or internal timers. Specific states of the state machine can include standby (inactive), ALOHA login (Additive Links On-line Hawaii Area, random access protocol), time-frequency offset synchronization (correcting frequency deviation), online (maintaining connection), and service testing (sending or receiving data). Each state can maintain independent context data (such as synchronization parameters and session keys).

[0049] In this embodiment, the contention and sharing can be represented as multiple virtual terminal instances needing to use the same physical radio frequency transmission channel when sending radio frequency signals. Each virtual terminal instance has a resource competition relationship for the use of this channel, and the right to use the channel needs to be determined through subsequent time slot arbitration rules.

[0050] In this embodiment, the backhaul channel resource can be the wireless channel used by the terminal to send data to the master station in satellite communication, and can be specifically defined by parameters such as center frequency, symbol rate, and roll-off factor. In a possible and specific implementation, in the network management system on the master station equipment side, the same backhaul link physical layer parameters can be pre-configured for user accounts of all virtual terminal instances belonging to the same physical terminal.

[0051] In one possible and specific implementation, the terminal device can use software virtualization technology to create virtual terminal instances on its single physical satellite terminal hardware. Any number of virtual terminal instances can be created based on the actual needs of multi-user testing of the MF-TDMA satellite communication system. Each virtual terminal instance is an independent virtual communication entity, and their communication behaviors do not interfere with each other. All instances possess the same communication functional logic as the physical satellite terminal. During the creation of each virtual terminal instance, a unique user identifier can be configured. This identifier can be a numeric string, a string, or a combination of numeric and character strings, enabling the master station equipment to accurately identify each virtual terminal instance. Simultaneously, each virtual terminal instance has a built-in protocol state machine. The state types of this protocol state machine can include standby state, ALOHA login state, and online state, etc.

[0052] In one possible and specific implementation, all created virtual terminal instances can be configured to compete for and share the same physical radio frequency (RF) transmission channel on the terminal equipment side. This means each virtual terminal instance has the authority to use that physical RF transmission channel to send RF signals, without a dedicated physical RF transmission channel, thus completely simulating the actual scenario of multiple physical user terminals sharing a communication channel in an MF-TDMA satellite communication system. Furthermore, during the creation of virtual terminal instances, the same return channel resources can be preset for all virtual terminal instances. That is, the return channel parameters of all virtual terminal instances are uniformly configured to be consistent. These return channel parameters may include the center frequency, symbol rate, roll-off factor, etc., ensuring that all virtual terminal instances use the same return channel when sending signals to the master station equipment side, conforming to the multi-user channel configuration rules of the MF-TDMA satellite communication system.

[0053] Step S14: Generate multiple time slots to be sent for the multiple virtual terminal instances.

[0054] In this embodiment, the time slot can be represented as a communication time unit with a fixed time length, which is divided based on the time division multiplexing rule in the MF-TDMA satellite communication system. It is the basic time unit for the terminal equipment to send radio frequency signals to the master station equipment. Each time slot is distributed continuously and without overlap on the time axis.

[0055] In one possible and specific implementation, the terminal device independently triggers the generation of time slots to be sent for each created and normally operating virtual terminal instance, based on the current working state of its protocol state machine. The time slot generation processes of each virtual terminal instance do not interfere with each other. Each virtual terminal instance generates corresponding time slots to be sent according to its own communication needs, and the time slots generated by multiple virtual terminal instances together constitute the set of time slots to be sent. The type of the time slots to be sent generated adapts to the current working state when the protocol state machine of a virtual terminal instance is in different working states. Specifically, for example, when the protocol state machine is in the ALOHA login state, an ALOHA login time slot is generated to initiate an access request to the master station device. When the protocol state machine is in the online state, a control time slot can be generated to maintain the communication connection with the master station device, or a service time slot can be generated to transmit service test data to the master station device. When the protocol state machine is in the standby state, no time slots to be sent may be generated.

[0056] In one possible and specific implementation, all the configuration parameters of the time slots to be transmitted generated by the virtual terminal instances are matched with the preset same return channel resources. That is, the frequency parameters, rate parameters, roll-off coefficient parameters, etc. of the time slots are consistent with the return channel parameters of the virtual terminal instances, ensuring that the radio frequency signals carried by the time slots to be transmitted can be transmitted normally in the preset return channel, which conforms to the channel transmission rules of the MF-TDMA satellite communication system.

[0057] Step S16: Perform time overlap detection on the multiple time slots, and select one time slot from the overlapping time slots according to the preset conflict arbitration strategy, and send it to the master station equipment side through the physical radio frequency transmission channel, while discarding other overlapping time slots; wherein, by sending the selected time slot, multi-user concurrent access and service behavior are simulated for testing the satellite communication system.

[0058] In this embodiment, the time overlap detection can be represented as the terminal device detecting the time interval of the time slots to be sent generated by all virtual terminal instances, thereby determining whether there is an intersection in the distribution of different time slots to be sent on the time axis. Specifically, for example, if the start time of time slot 1 is t1 and the end time is t2, and the start time of time slot 2 is t3 and the end time is t4, if the intervals [t1, t2] and [t3, t4] have an intersection, then an overlap is determined.

[0059] The conflict arbitration strategy can be represented as a set of rules pre-defined on the terminal device side, used to determine a unique transmittable time slot among overlapping time slots. Specifically, if the overlapping time slots include a control time slot (used for connection maintenance), the control time slot is selected first, and the ALOHA login time slot or other service time slots are discarded. This is because the loss of the control time slot may lead to connection interruption, affecting the continuity of the test. If the overlapping time slots are all of the same type (e.g., multiple ALOHA login time slots), the time slot with the earliest start time (i.e., the first triggered instance) is selected, and subsequent overlapping time slots are discarded, which is used to simulate the first-come, first-served behavior in a real network.

[0060] In one possible and specific implementation, the terminal device first performs a time overlap detection operation on the time slots to be transmitted. It first acquires the time information of each time slot to be transmitted generated by all virtual terminal instances. This time information can include the start and end times of the time slot. The terminal device can determine the corresponding time interval based on the start and end times of each time slot. After determining the time interval, the terminal device compares the time intervals of any two time slots to be transmitted. If the two time intervals intersect on the time axis, it is determined that the two time slots to be transmitted overlap in time. If the two time intervals do not intersect on the time axis, it is determined that the two time slots to be transmitted do not overlap in time. The terminal device can perform the above pairwise comparison detection operation on all time slots to be transmitted to complete the time overlap detection of all time slots to be transmitted and filter out all time slot groups with time overlap. For each time slot group that has been determined to have time overlap, the terminal device can perform a time slot arbitration operation according to a preset conflict arbitration strategy, selecting a unique time slot to be transmitted from each time slot group as the target transmission time slot. Finally, after determining all target transmission time slots, the terminal equipment can transmit all target transmission time slots sequentially to the master station equipment through the same physical radio frequency transmission channel on the terminal equipment side, according to the time interval of the time slots.

[0061] This embodiment virtualizes multiple independently running terminal instances on a single physical terminal hardware and successfully resolves the conflict problem of multiple virtual users sharing a single radio frequency channel by leveraging a pre-defined unified return channel resource and time slot conflict arbitration mechanism. This enables multi-user concurrent testing of a satellite communication system using real hardware. This method not only covers the complete signal link from the master station modem radio frequency front-end to the higher-layer protocol processing node, ensuring high confidence and authenticity of the test results, but also accommodates the introduction of real channel impairment environments. Furthermore, it significantly reduces the cost and complexity of the large amount of hardware required for traditional multi-user testing, achieving high-efficiency, high-fidelity end-to-end system verification.

[0062] In some implementations, the step of creating and maintaining multiple virtual terminal instances on the terminal device side includes:

[0063] Step S122: Load the preset configuration file; wherein the configuration file defines independent user identification information, authentication information and business test parameter information for multiple virtual terminal instances.

[0064] In this embodiment, the configuration file can be a file pre-set on the terminal device side according to the multi-user testing requirements of the MF-TDMA satellite communication system, used to uniformly define the configuration parameters of all virtual terminal instances. Specifically, the configuration file can be stored in the local storage module (hard disk, flash memory) on the terminal device side, or it can be stored in an external storage device accessible on the terminal device side. The configuration file can be a JSON format file, an XML format file, a YAML format file, or a custom-formatted text / binary file.

[0065] In this embodiment, the user identification information is also the information representing the user's identifier.

[0066] In this embodiment, the authentication information can be represented as parameter information defined individually for each virtual terminal instance in the configuration file, used by the main station device to verify the legitimacy of the virtual terminal instance's identity. Specifically, it can be various authentication methods such as passwords, keys, digital certificates, or verification codes, and can correspond one-to-one with user identification information.

[0067] In this embodiment, the service test parameter information can be represented as parameters defined in the configuration file for each virtual terminal instance, used to drive the virtual terminal instance to perform subsequent service test behaviors. Specifically, it can include back-end service test parameters and forward-end service test parameters.

[0068] In one possible and specific implementation, after the terminal device initiates the satellite communication system test process, it automatically triggers a configuration file loading command and reads the preset configuration file from the storage location through a preset file reading interface.

[0069] Step S124: Parse the configuration file, and create and initialize an independent virtual terminal instance for each defined user on the single hardware platform of the terminal device; wherein, each virtual terminal instance maintains its own protocol state machine and service context, and maps them to a shared physical radio frequency transmission channel.

[0070] In this embodiment, the parsing action can be represented as the terminal device reading the specific content of the loaded configuration file through a preset parsing program, extracting the user identification information, authentication information and business test parameter information defined for each virtual terminal instance, and identifying and classifying the extracted parameter information, converting it into parameter instructions that can be recognized and executed by the terminal device.

[0071] In this embodiment, initialization can be defined as the process by which the terminal device configures basic operating parameters and starts corresponding functional modules after creating a virtual terminal instance, enabling it to operate normally and participate in multi-user concurrent access and service testing. Specifically, initialization may include: writing the parsed user identification information and authentication information corresponding to the virtual terminal instance into the configuration module of the virtual terminal instance, enabling it to have identity identification and authentication capabilities; starting the protocol state machine built into the virtual terminal instance and initializing the protocol state machine to a standby state, so that the protocol state machine can switch states normally according to subsequent communication processes; storing service test parameter information in the service module of the virtual terminal instance, providing parameter basis for triggering subsequent service test behaviors; and simultaneously initializing the operating environment of the virtual terminal instance, allocating the required system resources (memory, processor resources), so that the virtual terminal instance can run independently and stably without resource conflicts with other virtual terminal instances.

[0072] In this embodiment, the business context can be represented as a set of information maintained by each virtual terminal instance during operation, related to its own communication behavior and operating status. Specifically, it can include the virtual terminal instance's current protocol state machine state, transmitted / received timeslot records, business test progress information, communication interaction records with the main station device, and its own resource occupancy status, etc. It is understood that the business context of each virtual terminal instance is independent and maintained independently, ensuring that the communication behaviors of each virtual terminal instance do not interfere with each other.

[0073] In this embodiment, the mapping can be represented as the terminal device establishing an association between the communication needs of each virtual terminal instance and a shared physical radio frequency transmission channel, so that the time slots to be sent and various communication signals generated by the virtual terminal instance can be sent to the main station device through the physical radio frequency transmission channel.

[0074] In some implementations, generating multiple time slots to be sent for the plurality of virtual terminal instances includes:

[0075] Step S142: In response to the state transition of the protocol state machine of each virtual terminal instance, generate a time slot to be transmitted corresponding to the current state; wherein the parameters of the time slot to be transmitted are matched with the same return channel resources, and its type includes at least one of ALOHA login time slot, control time slot or service time slot.

[0076] In this embodiment, the state transition of the protocol state machine can be represented as the virtual terminal instance's protocol state machine transitioning from one state to another when a preset trigger condition (which could be a clock, an external event, or an internal timer timeout) is met. This state transition process can trigger a corresponding time slot construction task. Specifically, when the state machine transitions from the standby state to the ALOHA login state, it triggers the generation of an ALOHA login time slot. The trigger condition for this transition could be the successful reception and parsing of system broadcast information. When the state machine successfully transitions from the time-frequency offset synchronization state to the online state, it can periodically or on demand trigger the generation of control time slots to maintain connection synchronization with the master station. When the virtual terminal instance is in the online state and needs to initiate service tests according to service test parameters, it can trigger the generation of service time slots to carry test data.

[0077] In this embodiment, the ALOHA login time slot can be represented as the time slot generated by the virtual terminal instance in the ALOHA login state and used to initiate a random access request to the master station equipment. The control time slot is a dedicated time slot used for control signaling interaction with the master station equipment. It is the standard time slot type in the MF-TDMA satellite communication system for maintaining normal communication between the terminal and the master station, and is used to carry non-service control commands and status information. The service time slot is the time slot used for service data transmission with the master station equipment.

[0078] In this embodiment, the parameters of the time slot to be transmitted can be the transmission parameters of the time slot at the physical radio frequency layer, such as the center frequency, symbol rate, modulation scheme, and roll-off factor. The matching can be expressed as the physical parameters configured for the time slot to be transmitted needing to be consistent with the same backhaul channel resource parameters preset for all virtual terminal instances in the network management system.

[0079] In one possible and specific implementation, each virtual terminal instance on the terminal device side configures an independent state monitoring module for the protocol state machine within its own software runtime environment. This state monitoring module is then associated with the instance's built-in timeslot generation module. The state monitoring module can monitor the current operating state of the protocol state machine in real time at a preset time period, which can be consistent with the system's timeslot length. When the state monitoring module detects a state transition in the protocol state machine, it immediately sends a state change trigger signal to the timeslot generation module. Upon receiving this signal, the timeslot generation module immediately activates from its dormant state and begins the generation process for the timeslots to be sent. If the state monitoring module detects no state transition in the protocol state machine, the timeslot generation module remains dormant and does not perform any timeslot generation operations.

[0080] In one possible and specific implementation, after the time slot generation module is activated, it first extracts the target working state of the protocol state machine (i.e., the current working state after state transition) from the state change trigger signal, and determines the type of time slot to be generated this time according to a preset state-time slot type matching rule. The matching rule can be a fixed mapping relationship. Specifically, the state-time slot type matching rule can be: if the target working state is the ALOHA login state, then the time slot type to be generated this time is determined to be the ALOHA login time slot. If the target working state is the online state, then based on the current communication needs of the virtual terminal instance, it determines whether to generate a control time slot or a service time slot. Specifically, when the communication needs are to maintain connection synchronization with the master station device and send control commands, a control time slot is generated. When the communication needs are to initiate a service test capacity request and transmit test data packets, a service time slot is generated.

[0081] In one possible and specific implementation, after the time slot generation module determines the time slot type, it can call the back channel resource parameter set that is uniformly preset for all virtual terminal instances on the terminal device side (this parameter set can be stored in the common storage area on the terminal device side, which can be accessed by all virtual terminal instances, and can include parameters such as center frequency, symbol rate, roll-off factor, time slot frame structure, synchronization code type, modulation and coding scheme, etc.), and completely copy all the parameters in this parameter set to the configuration template for this time slot generation as the basic transmission parameters of the time slot to be sent.

[0082] In one possible and specific implementation, the time slot generation module can fill in the configuration information and service carrying information of the time slot type in the configuration template according to the determined time slot type. Specifically, when generating an ALOHA login time slot, the configuration template can be filled with the user identification information and the digest value of the authentication information of the virtual terminal instance, and parameters such as the random access identifier and transmission power of the time slot can be configured, so that the master station equipment can identify the initiator of the access request and complete the initial authentication through the time slot. When generating a control time slot, the configuration template can be filled with the corresponding control signaling type (e.g., time-frequency offset synchronization request, online keep-alive signaling, time slot resource request signaling, etc.), the online status identifier of the virtual terminal instance, and parameters such as the sequence number and retransmission identifier of the time slot can be configured. When generating a service time slot, the configuration template can be filled with service test-related information (e.g., the rate value of capacity request, the sequence number of test data packets, the digest value of test data content, etc.), and dedicated parameters such as the service type identifier and data length of the time slot can be configured, so that the master station equipment can identify the service test requirements and complete the reception and processing of test data.

[0083] In some implementations, the step of performing time overlap detection on the plurality of time slots and selecting one time slot from the overlapping time slots according to a preset conflict arbitration strategy, transmitting it to the master station equipment via the physical radio frequency transmission channel, and discarding other overlapping time slots includes:

[0084] Step S162: For the multiple time slots to be transmitted, calculate the start time and end time of each time slot to determine the time interval corresponding to each time slot.

[0085] In this embodiment, the time interval can be defined as the time range occupied by each time slot on the time axis, with the start time as the starting point and the end time as the ending point.

[0086] Step S164: Determine whether the two time slots overlap in time sequence by judging whether there is an intersection between their time intervals.

[0087] Step S166: If it is determined that there are overlapping time slots, execute the preset arbitration rules; wherein, the preset arbitration rules include: if the overlapping time slots include a control time slot, then the control time slot is determined as the target transmission time slot; if the overlapping time slots are all ALOHA login time slots, then the ALOHA login time slot with the earliest start time is determined as the target transmission time slot.

[0088] In this implementation, all overlapping time slots can be traversed. If any of the overlapping time slots are included, then regardless of the type of the other overlapping time slots (which could be other control time slots, ALOHA login time slots, or service time slots), that control time slot can be identified as the target transmission time slot. This rule prioritizes maintaining the link for online users, thereby simulating the strategy of protecting the control channel when resources are scarce for real terminals.

[0089] In this embodiment, if overlapping time slots are detected to be ALOHA login time slots (i.e., of the same type), the start times of the time slots are compared, and the ALOHA login time slot with the earliest start time (i.e., the time slot that expires first) is determined as the target transmission time slot. This is used to simulate the first-come, first-served principle of network access, which helps to improve the login success rate.

[0090] Step S168: The target transmission time slot is transmitted to the master station equipment side via the physical radio frequency transmission channel, while discarding all other time slots that overlap with the target transmission time slot.

[0091] In one possible and specific implementation, the RF transmission module on the terminal device side receives the target transmission time slot list generated in step S166, and sorts all the target transmission time slots in the list according to their start times from earliest to latest, generating an ordered transmission queue. This ensures that the target transmission time slots are transmitted sequentially according to their timing, avoiding new time slot conflicts. Then, the RF transmission module can sequentially call the buffer area of ​​the virtual terminal instance corresponding to each target transmission time slot, read the digital baseband signal data of that target transmission time slot, and simultaneously call the preset return channel parameters on the terminal device side to perform RF modulation on the digital baseband signal, converting the digital baseband signal into an RF signal that can be transmitted through the physical RF transmission channel. During modulation, the return channel parameters of the target transmission time slot can be synchronously checked against the preset parameters of the same return channel resource. If a parameter mismatch exists, the transmission preparation for that target transmission time slot is immediately terminated, and it is marked as a transmission anomaly, triggering an anomaly prompt; the time slot will no longer be transmitted. If the parameters match, the RF modulation is complete.

[0092] In one possible and specific implementation, discarding all other time slots overlapping with the target transmission time slot may include: calling the cache area of ​​the virtual terminal instance corresponding to each time slot to be discarded, deleting the digital baseband signal data and all configuration information of that time slot, and releasing the cache resources occupied by that time slot. All subsequent operations (including overlap detection, arbitration, transmission preparation, etc.) of the time slot to be discarded may be terminated, releasing the system resources such as processors and memory it occupies.

[0093] In some implementations, the protocol state machine of the virtual terminal instance includes at least a standby state, an ALOHA login state, and an online state; wherein, when in the ALOHA login state, an ALOHA login time slot is generated; when in the online state, a control time slot or a service time slot is generated; when in the standby state, no time slot to be sent is generated; wherein, if the protocol state machine exits from the ALOHA login state due to failure, it re-enters the ALOHA login state without returning to the standby state.

[0094] In this embodiment, the standby state can be represented as the initial working state of the protocol state machine, that is, the working state when the virtual terminal instance has no active communication needs. Specifically, it can be an idle state in which the virtual terminal instance does not initiate any communication behavior and does not establish any communication association with the master station device.

[0095] In this embodiment, the ALOHA login state can be represented as the working state that the protocol state machine enters when initiating a random access request to the master station device. The online state is the continuous working state that the protocol state machine enters after the virtual terminal instance completes identity authentication through ALOHA login and establishes a stable communication association with the master station device. That is, the virtual terminal instance has obtained legitimate access permissions from the master station device and can perform normal signaling interaction and data transmission with the master station. Specifically, the protocol state machine can trigger the transmission of control signaling or service data according to communication needs, and can receive downlink signaling and data from the master station device in real time, maintaining communication synchronization with the master station.

[0096] In this embodiment, the protocol state machine exiting the ALOHA login state due to failure can be an action where the protocol state machine, while in the ALOHA login state, fails to complete access authentication with the master station device due to various abnormal reasons, and is forced to exit the ALOHA login state. Specifically, this could be due to: the ALOHA login slot being discarded due to a conflict; failure to receive access response signaling from the master station device within a preset time after the login slot is sent; the master station device failing to authenticate the user identification information / authentication information; or packet loss during radio frequency signal transmission resulting in incomplete login signaling, etc.

[0097] In this implementation, when the protocol state machine exits the ALOHA login state due to failure, it does not return to the initial standby state as in the conventional process, but instead re-enters the ALOHA login state. This retry after a failed ALOHA login allows for the reuse of public information acquired and initialized before initialization and entering the ALOHA state (e.g., parsed system broadcast information, carrier frequency, etc.), avoiding the resource release and re-initialization overhead of a complete fallback to the standby state. This significantly saves system resources and improves overall efficiency and access success rate in multi-user concurrent access scenarios.

[0098] This implementation optimizes the state transition path after an ALOHA login failure. Specifically, if the protocol state machine exits the ALOHA login state due to failure (e.g., due to a time slot conflict, failure to receive a response from the master station within a preset time, or authentication failure), it re-enters the ALOHA login state instead of returning to the standby state.

[0099] Understandably, the aforementioned mechanism avoids resetting and reacquiring already obtained public context information. Specifically, before the virtual terminal instance first enters the ALOHA login state, it has already obtained public configuration data such as system frame structure, forward channel parameters, and access rules by receiving forward broadcast information. If the design of returning to standby state upon failure is adopted as in related technologies, the instance needs to re-execute the initialization process such as forward broadcast reception and parameter parsing, which not only increases access latency but also causes redundant overhead of processor resources.

[0100] The failure-based retry mechanism employed in this implementation allows virtual terminal instances to retain the acquired public context information. These parameters can then be reused in subsequent retries, requiring only a new ALOHA access request. This design offers significant performance advantages in multi-user concurrent access scenarios. Specifically, when hundreds or thousands of virtual instances on the same physical terminal initiate access simultaneously, this mechanism effectively avoids access storms caused by repeated resetting of the public context, significantly reducing overall access latency and processor overhead, and improving access success rate and system stability in large-scale concurrent scenarios.

[0101] In some implementations, the step of simulating multi-user concurrent access and service behavior by sending the selected time slots for testing the satellite communication system includes:

[0102] After the virtual terminal instance successfully accesses the network based on its user identification information and authentication information, it initiates a capacity request to the master station device and sends a test data packet carrying a serial number based on the business test parameter information defined in the configuration file and the allocated time slot, and / or receives a forward test data packet from the master station device; wherein, the serial number is filled in for the sent test data packet, and the serial number and data content of the received test data packet are verified.

[0103] In this embodiment, successful access can refer to the virtual terminal instance's protocol state machine switching from the ALOHA login state to the online state after completing identity authentication and time-frequency offset synchronization. In this state, the virtual terminal instance obtains communication and service processing permissions from the master station device and can initiate subsequent service actions such as capacity requests and data transmission. In other words, in this state, the master station device has completed the validity verification of the virtual terminal instance's user identification information and authentication information, and both parties have completed time-frequency offset synchronization, ensuring the communication link is in a state of normal interaction.

[0104] In this embodiment, the service test parameter information refers to the set of parameters independently defined for each virtual terminal instance by the preset configuration file loaded in S122, which drives its execution of service test behavior. Specifically, it can include return service test parameters and forward service test parameters. Both types of parameters can include test enable flags, test rates, test durations, and test data content. In this embodiment, the capacity request can be represented as a signaling interaction initiated by the virtual terminal instance to the master station device after successful access, requesting the data transmission bandwidth and time slot resources required for service testing. Specifically, the virtual terminal instance can send a capacity request signaling including the test rate and service type to the master station device through the allocated control time slot. After the master station device sends a resource allocation confirmation signaling, the virtual terminal instance initiates the test data packet sending process.

[0105] In this embodiment, the test data packets may include return test data packets sent from the terminal device side to the master station device side and forward test data packets sent from the master station device side to the terminal device side. Both types of data packets include preset test data content. The return test data packets are populated with sequence numbers by the virtual terminal instance, and the forward test data packets are configured with identification information by the master station device side according to the specification. The sequence number may be configured by the virtual terminal instance for each returned test data packet sent, and it is information that uniquely identifies the data packet transmission order.

[0106] Based on the verification results of the serial number and data content, the data transmission quality is evaluated to complete the performance verification of the satellite communication system; wherein, the performance verification is an end-to-end performance verification; wherein, the end-to-end performance verification includes at least the performance verification of the radio frequency modem and higher-layer protocol processing node in the master station equipment.

[0107] In this embodiment, the end-to-end performance verification can be represented as a full-link performance verification starting from the virtual terminal instance on the terminal device side, through the physical radio frequency transmission channel and satellite communication link to the master station device side, and then processed by the master station device side before being transmitted back to the terminal device side. It covers the entire process performance testing of the satellite communication system from the physical radio frequency layer to the protocol processing layer, rather than testing a single link. The specific verification scope can include key links and devices throughout the entire link, such as the physical radio frequency transmission channel on the terminal device side, the air interface radio frequency link, the radio frequency modem on the master station device side, and the higher-layer protocol processing nodes on the master station device side.

[0108] In one possible and specific implementation, when performing a backhaul service test, the instance requests capacity from the master station. After obtaining time slot resources, it generates backhaul test data packets according to the configured rate and test data content, fills each data packet with an independently incrementing sequence number, and then encapsulates the data packets into a service time slot for transmission. When performing a forward service test, the instance receives forward test data packets from the master station and immediately performs sequence number continuity verification and data content integrity comparison. The entire testing process can be controlled by the test duration parameter in the configuration file. Each instance runs independently, and its sending and receiving behaviors, sequence number filling and verification records are all stored in its own service context, providing raw data for subsequent evaluation.

[0109] In one possible and specific implementation, the step of evaluating data transmission quality based on verification results to complete end-to-end performance verification can be uniformly executed by the test quality evaluation module on the terminal device side. This module can summarize the sequence number verification and data content verification results reported by all virtual terminal instances, and quantitatively evaluate the integrity, sequence, and accuracy of the link by calculating packet loss rate, out-of-order rate, and bit error rate. Based on the quantitative indicators, this module can further implement end-to-end performance verification. If the bit error rate is abnormal but the air interface link is normal, it is determined that the demodulation performance of the master station's RF modem is defective. If the packet loss rate or out-of-order rate is abnormal but the RF link is normal, it is determined that the resource scheduling or data processing performance of the master station's higher-layer protocol processing node is insufficient. Finally, the module can generate a full-link performance verification report covering the entire link from terminal RF transmission to master station protocol processing, providing a basis for system performance evaluation.

[0110] In some implementations, the service test parameter information includes back-end service test parameters and forward-end service test parameters; wherein, both the back-end service test parameters and the forward-end service test parameters include at least an enable flag, a test rate, a test duration, and test data content.

[0111] In this embodiment, the enable flag is a switch-type parameter used to control whether the corresponding service test is started. Specifically, it can be a Boolean switch used to activate or disable the corresponding test process. When the flag is set to 1 (enabled), the service test module of the virtual terminal instance will automatically start the corresponding test behavior. When set to 0 (disabled), it will not be executed.

[0112] In this embodiment, the test rate is a quantitative parameter used to define the transmission rate of test data packets in the corresponding direction of service testing. Specifically, it can be the upper limit of the test data packet sending / receiving rate.

[0113] In this embodiment, the test duration can be the duration of a single test task.

[0114] In this embodiment, the test data content can be the raw data filling the payload of the test data packet. Specifically, it can be a predefined string, a cyclic binary sequence, or an identifier generated by a preset data generation algorithm (pseudo-random sequence). The receiver can calculate the bit error rate by comparing the actual received data content with the expected content defined here.

[0115] In some implementations, the plurality of virtual terminal instances are preset to use the same return channel resources, specifically including:

[0116] On the main station device side, user accounts of all virtual terminal instances belonging to the same terminal device side are configured with the same return channel parameters; wherein, the return channel parameters include center frequency, symbol rate and roll-off factor.

[0117] In this context, after the multiple virtual terminal instances access the network, all their data transmissions are constrained to the same back-return channel resource defined by the same back-return channel parameters.

[0118] In this embodiment, the user accounts of all virtual terminal instances on the same terminal device side can be user accounts created by the master station device side for the terminal device side, and each user account corresponds one-to-one with each virtual terminal instance on the terminal side. Specifically, it can be a set of account information including user identifier, authentication information, and channel configuration permissions, and all accounts belong to the same device identifier on the same terminal device side. The master station device side can perform unified parameter configuration on all accounts under this identifier.

[0119] In this embodiment, after the virtual terminal instance is connected, all generated time slots to be transmitted and modulated radio frequency signals strictly follow the same return channel parameters configured on the main station equipment side. All data transmission behaviors are completed in the return channel defined by these parameters, and there is no right to switch channel resources autonomously.

[0120] In this embodiment, the center frequency is the radio frequency carrier frequency of the return channel. It serves as the basis for the terminal device to modulate the digital baseband signal into a radio frequency signal, and it is also the frequency reference for the master station device to receive the radio frequency signal from the terminal. All virtual terminal instances on the terminal device side generate transmit timeslots using this center frequency as the carrier frequency when modulating into radio frequency signals. The master station device then tunes its radio frequency receiving module using this center frequency to receive the terminal signal, ensuring that the signal can be transmitted within the specified radio frequency band.

[0121] In this embodiment, the symbol rate is the symbol transmission rate of the digital baseband signal sent from the terminal device to the master station device. The parameters of all the time slots to be transmitted generated by the virtual terminal instances on the terminal device side are matched with this symbol rate, and the length and data carrying capacity of the time slots can be designed according to this rate.

[0122] In this embodiment, the roll-off factor is a roll-off element used for transmit pulse shaping (raised cosine filtering). All virtual terminal instances on the terminal device side configure their transmit filters according to this roll-off factor when modulating digital baseband signals into radio frequency signals. This limits the spectrum of the radio frequency signal to a specified frequency band, reducing out-of-band radiation interference to other channels. Simultaneously, the master station equipment side configures its receive filters with the same roll-off factor to achieve filtering and demodulation of the radio frequency signal, improving the signal-to-noise ratio of the received signal.

[0123] In one possible and specific implementation, a top-level device ownership account can be established on the master station device side for the physical terminal devices participating in the test. Then, user sub-accounts can be created in batches under this account, corresponding exactly to the number of virtual terminal instances to be simulated on the terminal side. The user identifier and authentication information of each sub-account are consistent with the definitions in the terminal-side configuration file. The same set of return channel parameters—i.e., the same center frequency, symbol rate, and roll-off factor—can be uniformly associated and written into the communication attribute configuration fields of all user sub-accounts under this device ownership account. This configuration information can be centrally stored in the master station's user database. Once effective, the return channel resources available to all virtual instances belonging to this physical terminal when accessing the network are preset and locked by the system.

[0124] like Figure 2 As shown, this embodiment provides a test system for satellite communication, including:

[0125] On the terminal device side, it includes at least one terminal device configured to create and maintain multiple virtual terminal instances; each virtual terminal instance has an independent user identifier and protocol state machine, and the multiple virtual terminal instances compete to share the same physical radio frequency transmission channel; the multiple virtual terminal instances are preset to use the same return channel resources; multiple time slots to be transmitted are generated for the multiple virtual terminal instances; time overlap detection is performed on the multiple time slots, and a time slot is selected from the overlapping time slots according to a preset conflict arbitration strategy and transmitted to the master station device side via the physical radio frequency transmission channel, while other overlapping time slots are discarded; wherein, by transmitting the selected time slot, multi-user concurrent access and service behavior are simulated for testing the satellite communication system.

[0126] On the master station equipment side, the master station equipment side establishes a communication connection with the terminal equipment side and is configured to respond to and process the multi-user concurrent access and service behavior initiated by the terminal equipment side in order to complete the test of the satellite communication system.

[0127] In one specific implementation, the terminal device can be a portable satellite terminal, a vehicle-mounted satellite terminal, or a fixed-station satellite terminal. It may have a physical radio frequency transmission channel and a baseband processing module (for encoding, decoding, and time slot generation of digital baseband signals). It may also have a processor and a storage unit (supporting the concurrent operation of multiple virtual terminal instances, protocol state machine processing, execution of time slot conflict arbitration algorithms, and storing configuration files and test logs).

[0128] In one specific implementation, the master station equipment may include: a network control layer, a service processing layer, a radio frequency modulation and demodulation layer, and an external interaction module.

[0129] Specifically, the network control layer is the central hub for managing concurrent access by multiple users on the main station device side. It is responsible for coordinating the scheduling of backhaul and forwardhaul channel resources and maintaining the access status of virtual terminal instances. The network control layer further includes: a backhaul channel resource management module, a forwardhaul channel resource management module, and a network control center. The backhaul channel resource management module can uniformly configure the same backhaul channel parameters (center frequency, symbol rate, roll-off factor) for all virtual terminal instance user accounts on the same terminal device side and maintain an account configuration information table. When a virtual terminal instance initiates an ALOHA login, it can verify the legitimacy of its user identifier and authentication information to complete identity authentication. After successful authentication, it sends backhaul channel parameters and time-frequency offset synchronization parameters to the terminal device side, providing basic configuration for virtual terminal instance network access. It can also monitor the occupancy status of backhaul channel resources in real time, providing dynamic resource scheduling basis for multi-user concurrent access testing.

[0130] The forward channel resource management module is mainly used to coordinate with the back channel resource management module to complete the matching and scheduling of back and forward resources after a virtual terminal instance successfully accesses and initiates a capacity request. It can receive forward test data packets forwarded by the gateway, generate forward service time slots according to forward service test parameters (test rate, duration, etc.), and schedule the forward modulation board to complete radio frequency transmission.

[0131] As the control node for both the backhaul channel resource management module and the forward channel resource management module, the network control center is primarily responsible for coordinating the linked configuration of backhaul and forward channel resources, synchronously maintaining the access status and service testing progress of all virtual terminal instances, and providing resource scheduling instructions and status information support to the gateway.

[0132] The service processing layer (gateway) is primarily used to connect the network control layer and the radio frequency modulation and demodulation layer. It can receive virtual terminal instance test data (ALOHA login slots, control slots, and service slots carrying signaling and data) demodulated by the back-end modulation board, parse the higher-layer protocols, and forward it to the back-end channel resource management module for resource scheduling and authentication. It can also receive forward test data packets and control signaling from the forward channel resource management module, encapsulate them into frame structures conforming to the MF-TDMA (Multi-Frequency Time Division Multiple Access) protocol, and forward them to the forward modulation board for radio frequency modulation.

[0133] The radio frequency modulation and demodulation layer mainly consists of a back-to-back modulation board and a forward modulation board. This layer is the physical interface between the master station equipment and the satellite link, and is responsible for the demodulation and modulation of radio frequency signals.

[0134] The back-modulation board mainly receives radio frequency signals transmitted via a physical radio frequency transmission channel and relayed by satellite from the terminal equipment side, and performs down-conversion, demodulation, decoding and other processing to restore the radio frequency signal into digital baseband test data.

[0135] The forward modulation board mainly receives forward test data packets and control signaling forwarded by the gateway, performs encoding, modulation, up-conversion and other processing, converts digital baseband signals into radio frequency signals that conform to forward channel parameters, and forwards them to the terminal equipment via satellite.

[0136] The external interaction module (network management) is a remote configuration and monitoring node on the main station equipment side. It primarily communicates with the network control center to preset the configuration of return channel parameters, batch create virtual terminal instance user accounts, and distribute and adjust test parameters. It can also collect real-time data on the operating status of each module on the main station equipment side, test data statistics, and performance verification results, generating visualized test monitoring reports to support remote management and troubleshooting for testers.

[0137] like Figure 3 and Figure 4 As shown, in a specific implementation scheme, a test system and test method suitable for MF-TDMA satellite communication systems are provided. Specifically, this implementation scheme is based on commercial satellite communication terminal hardware. By improving the state machine and context management mechanism of its embedded software, a large number of independent user instances are virtualized on a single physical terminal, thereby conducting end-to-end performance and stress tests on the entire satellite communication system, including the master station modulator, demodulator, server, and network management system. In related technologies, testing for multi-user scenarios generally adopts a pure software simulation technical solution. This solution constructs a test system by simulating terminal behavior through a terminal station simulation server and software modules. It can only realize high-level signaling interaction between Ethernet and the master station server, completely bypassing the physical radio frequency link and related hardware devices such as radio frequency modems and demodulators, and cannot cover the entire link test scenario from the physical layer to higher-level protocols.

[0138] While the aforementioned pure software simulation testing scheme is characterized by low cost and easy expansion, it has significant technical limitations, as follows:

[0139] 1. Pure software simulation only simulates high-level protocols and cannot reproduce the real transmission characteristics of physical radio frequency links (signal attenuation, transmission delay, channel interference, etc.). As a result, the test results cannot reflect the system performance in real communication scenarios and cannot provide a reliable basis for system optimization.

[0140] 2. The testing process bypasses key RF hardware devices such as the main station modulator and demodulator, making it impossible to effectively test and verify the actual operating performance, compatibility, and stability of such devices, and making it difficult to support the research, development, debugging, and acceptance evaluation of hardware devices.

[0141] 3. Pure software simulation cannot construct a real transmission environment that includes channel impairments (Doppler frequency offset, noise, bit error), cannot evaluate the system's performance under actual channel conditions, and cannot verify the system's anti-interference capability and robustness.

[0142] 4. The relevant solutions only simulate the high-level protocol behavior of the terminal, and cannot verify the hardware carrying capacity, resource scheduling efficiency and long-term operational stability of a single physical terminal in multi-user concurrent scenarios, making it difficult to assess the actual load capacity of the terminal device.

[0143] 5. The simulation of the relevant solution only implemented part of the protocol interaction logic (heartbeat maintenance) and did not fully reproduce the full protocol stack behavior of the real terminal. For example, key processes such as automatic disconnection and recovery after control correction loss were not implemented, resulting in a significant deviation between the simulated scenario and the actual communication scenario, and the validity of the test results is insufficient.

[0144] In this implementation plan, the testing system mainly includes:

[0145] The multi-user virtualized terminal device, which serves as the core of the terminal side of the test system, is built based on real physical satellite terminal hardware and is used to simulate multi-user concurrent access behavior.

[0146] The master station system under test, which includes units such as radio frequency modulator, radio frequency demodulator, gateway and network control center, is the central hub for the management and service processing of the satellite communication system. It is responsible for receiving access requests from multi-user virtualized terminal devices, processing test data and completing resource scheduling.

[0147] The network management system is responsible for remote configuration, status monitoring and maintenance of the entire satellite master station system, including configuration operations such as user account opening, channel resource binding and test parameter distribution for virtual terminal instances on multi-user virtualized terminal devices.

[0148] The multi-user virtualized terminal equipment establishes a physical connection with the master station system under test or the radio frequency channel simulator through the radio frequency interface. All master station configuration and user account opening operations are completed uniformly through the network management system, making the test process highly consistent with the actual operation process of the satellite communication system.

[0149] In this implementation scheme, during testing, the resource configuration logic of the multi-user virtualized terminal equipment remains consistent with the configuration during normal operation of the satellite communication system. Specifically, user accounts can be opened for all virtual terminal instances on the multi-user virtualized terminal equipment through the network management system, configuring complete account information including user identifiers, authentication information, and channel resource binding relationships, so that virtual terminal instances can be authenticated by the master station upon access. Since the MF-TDMA system adopts a time-division multiplexing mechanism, the same physical radio frequency transmission channel can only transmit one time slot at a time, and the terminal side is usually a single transmission channel. Therefore, when configuring accounts for all virtual terminal instances under the same multi-user virtualized terminal equipment, they can be bound to the same return channel resource (i.e., configured with the same center frequency, symbol rate, and roll-off factor).

[0150] Understandably, the purpose of the above configuration is to prevent cross-channel time slot overlap when the forward channel resource management module on the master station schedules time slots for all users under the same multi-user virtualized terminal device. This avoids radio frequency signal transmission conflicts and failures caused by the multi-user virtualized terminal device's inability to handle overlapping time slots across channels. If this configuration rule is not followed, the multi-user virtualized terminal device will be unable to correctly handle overlapping time slots generated by different users on different channels, leading to radio frequency signal transmission conflicts and failures.

[0151] In this implementation plan, the testing methods mainly include:

[0152] S100: Standby

[0153] This step is the initial phase of the login and online persistence test for multi-user virtualized terminal devices. Its purpose is to complete the initial configuration of the multi-user virtualized terminal devices, generate the basic runtime environment required for the multi-virtual terminal instances, and put the multi-user virtualized terminal devices into a standby state where they can initiate access requests. Specifically, it includes the following operations:

[0154] 1. Disable underlying user identifier filtering function

[0155] To ensure that all virtual terminal instances on the same physical terminal can receive forward data packets normally, multi-user virtualized terminal devices first disable the "forward data packet filtering based on user identifier" function of their underlying hardware. This operation prevents the physical layer from discarding forward data from other virtual terminal instances due to identifying a single user identifier, ensuring the integrity of forward data when multiple virtual instances share the physical radio frequency link. This is a necessary prerequisite for enabling concurrent access for multiple users.

[0156] 2. User data initialization

[0157] Multi-user virtualized terminal devices initialize user data by loading a preset configuration file. The specific process is as follows:

[0158] (1) Loading configuration files and creating virtual instances. Read the locally imported configuration file and, based on the user list defined in the file, create and maintain an independent virtual terminal instance for each user on a single physical satellite terminal hardware platform. Each virtual terminal instance has an independent protocol state machine, a unique user identifier (Hid), and a dedicated service context, and all instances compete for and share the same set of physical radio frequency and baseband processing resources.

[0159] (2) Parse the configuration fields. Specifically, the configuration file includes multiple types of configuration fields, and the functions of each field are as follows:

[0160] Hid (Hardware ID) is a hardware identity identifier used to identify the terminal device itself. In this implementation scheme, it serves as the user account for a specific virtual terminal instance on a single physical hardware device, used to initiate registration and authentication with the main site.

[0161] Password, the authentication password for the virtual terminal instance, works with Hid to complete identity authentication on the main site.

[0162] LC (Lower Capability) is a terminal's underlying capability identifier, which is a predefined binary parameter of the system. For example, bit 0 indicates support for extremely low signal-to-noise ratio mode, bit 1 indicates support for rotor mode, etc. It is used to declare the terminal's underlying hardware capabilities to the master station.

[0163] HC (Higher Capability) is a terminal higher-level capability identifier, which is a predefined binary parameter of the system. For example, bit 0 indicates support for automatic power control, and it is used to declare the terminal's higher-level protocol capabilities to the master station.

[0164] RLTest (Return Link Test) is a set of parameters for return link testing, used to configure the return link testing behavior of virtual terminal instances. It may further include:

[0165] Enable, the backhaul service test enable flag (1 for enabled, 0 for disabled), controls whether to initiate backhaul capacity requests and data transmission.

[0166] Speed, the return test rate, defines the upper limit of the transmission rate of return test data packets.

[0167] Time: Backtest duration, defines the duration of the backtest business test.

[0168] Data, the content of the return test data, is used to cyclically fill the payload of the return time slot as a benchmark for verifying the accuracy of data transmission.

[0169] FLTest (Forward Link Test) is a set of parameters for forward service testing, used to configure the forward service testing behavior of virtual terminal instances. It may further include:

[0170] Enable, the forward service test enable flag (1 for enabled, 0 for disabled), controls whether to receive and verify the forward test data packets sent by the main station.

[0171] Speed, forward test rate, defines the upper limit of the forward test data packet reception rate.

[0172] Time, the duration of the forward test, is in seconds (0 indicates continuous testing until a termination instruction is received). It defines the duration of the forward business test.

[0173] Data, the forward test data content, is used to compare and verify the forward data packet content sent by the main station to confirm the accuracy of data transmission in the forward link.

[0174] 3. Access point information configuration

[0175] After the multi-user virtualized terminal device completes user data initialization, it configures the parameters of the forward access point, including forward channel parameters such as forward frequency, symbol rate, and roll-off factor. This configuration is consistent with the forward channel parameters on the master station side, providing a basis for time-frequency offset synchronization when virtual terminal instances access the master station, enabling virtual terminal instances to receive forward signaling and data sent by the master station normally.

[0176] Step S200: Forward broadcast information reception

[0177] The multi-user virtualized terminal device receives system broadcast information from the master station, a process identical to that of a single-user physical terminal. By parsing the broadcast information, the multi-user virtualized terminal device obtains configurations such as system frame structure, forward channel parameters, and access rules, providing a foundation for subsequent concurrent multi-user access.

[0178] Step S300: Multi-user access process

[0179] Each virtual terminal instance on a multi-user virtualized terminal device independently executes the access and synchronization process, with no interference between the processes of each instance, fully simulating a real-world scenario of concurrent access by multiple physical terminals. The access process of a single virtual terminal instance includes the following sub-steps:

[0180] Sub-step S301: Initiate the ALOHA access process

[0181] The virtual terminal instance initiates an ALOHA random access request to the master station. If it receives an ALOHA response signal from the master station within the timeout period specified in the protocol, it proceeds to sub-step S302. If no response is received within the timeout period, or if the access is rejected by the master station, it directly re-enters this step (S301) to initiate a new round of ALOHA requests, instead of returning to the standby state (S100). This reuses the already acquired public configuration information, improves access efficiency, and saves system resources.

[0182] Because all virtual terminal instances under the same multi-user virtualization terminal device are bound to the same return channel resource and share a single physical radio frequency transmission channel, ALOHA time slots initiated randomly by multiple instances are highly prone to overlap in time. Furthermore, the forward channel resource management module on the master station side cannot perceive the multi-user virtualization test scenario of the multi-user virtualization terminal device and will treat all virtual terminal instances as independent normal users, potentially allocating overlapping return time slot resources to different instances under the same multi-user virtualization terminal device. Therefore, the time slot conflict problem needs to be resolved through the time slot arbitration module built into the multi-user virtualization terminal device.

[0183] Sub-step S302: Time-frequency offset synchronization of the return control channel

[0184] The virtual terminal instance completes time-frequency offset synchronization of the return control channel based on the ALOHA response signaling issued by the master station. If synchronization is successful, proceed to sub-step S303; if synchronization fails, return to sub-step S301 to re-initiate ALOHA access.

[0185] The forward channel resource management module on the master station side can ensure that the control time slots of all users under the same multi-user virtualized terminal device do not overlap. However, since the login channel and control channel can be different channels, the control time slot of a user who has completed ALOHA access may overlap with the ALOHA time slot of a user who is initiating ALOHA access. In this case, the time slot arbitration module will prioritize the transmission of the control time slot and discard the overlapping ALOHA time slot. Although this process will reduce the ALOHA access efficiency of some users, it can avoid control signaling transmission failure and make the behavior of the control channel completely consistent with the real physical terminal.

[0186] Sub-step S303: Time-frequency offset tracking and online hold

[0187] After the virtual terminal instance enters the online state, it continuously tracks the time-frequency offset of the return channel to maintain communication synchronization with the master station. If the time-frequency offset tracking loss causes the number of control correction loss exceed the threshold configured by the master station, it immediately returns to sub-step S301 to re-initiate ALOHA access, ensuring that the virtual terminal instance can quickly return to the online state.

[0188] It should be noted that the time slot arbitration module is a built-in software function module of the multi-user virtualized terminal device. Its function is to detect and resolve time slot conflicts when multiple virtual terminal instances share a single physical radio frequency transmission channel. This module calculates the start and end times of each time slot to be transmitted, detects time slot overlap, and executes a preset conflict resolution strategy (actively detects the time interval of all time slots to be transmitted; if multiple ALOHA time slots are found to overlap, only the ALOHA time slot with the earliest start time is retained, and the remaining overlapping time slots are discarded).

[0189] It should be noted that, because the forward channel resource management module on the master station side may not be aware of the multi-user virtualization scenario of the multi-user virtualized terminal device, it will treat all virtual terminal instances as independent users. Consequently, it may allocate overlapping time slots on different return channels to different instances under the same multi-user virtualized terminal device. In this case, the time slot arbitration module of the multi-user virtualized terminal device only handles time slot conflicts within the same return channel, and time slot conflicts on different channels are naturally isolated by the channel separation mechanism on the master station side.

[0190] Step S400: Back-end service test

[0191] The return service test is used to verify the system's return channel capacity application, data transmission, and verification capabilities. The test triggering and execution process is as follows:

[0192] Once a virtual terminal instance successfully connects and enters online status, the multi-user virtualized terminal device can trigger the activation of the CR (Capacity Request) parameter configuration defined in the configuration file via terminal-side command line commands.

[0193] The multi-user virtualized terminal device initiates a CR (Return Test) request. Upon successful request, it generates test data packets based on the data (return test data content) defined in the RLTest (Return Test Parameter Set) field of the configuration file. A unique, incrementing sequence number is prepended to the payload of each data packet to ensure traceable data packet transmission order. Subsequently, the multi-user virtualized terminal device continuously sends these data packets at the configured test rate.

[0194] The multi-user virtualized terminal device automatically terminates the CR application and data transmission according to the Time (return test duration) parameter configured in the RLTest field; or the test can be manually stopped via terminal-side command line commands.

[0195] After receiving the return test data packet, the main station gateway extracts and verifies the sequence number and data content of the data packet, compares it with the preset configuration in the configuration file, and finally outputs the return service test results including packet loss rate, out-of-order rate, and data integrity.

[0196] Step S500: Forward Service Testing

[0197] Forward service testing is used to verify the system's data transmission, reception, and verification capabilities in the forward channel. The test triggering and execution process is as follows:

[0198] Once the virtual terminal instance has successfully connected and entered online status, the main station can start forward service testing via command line commands.

[0199] The main gateway generates forward test data packets based on the data (forward test data content) content defined in the FLTest (forward business test parameter set) field in the configuration file, and fills a unique incrementing sequence number before the payload of each data packet. Then, it sends the data packets to the corresponding virtual terminal instance at the configured test rate.

[0200] The gateway automatically terminates the sending of forward test data packets based on the Time (forward test duration) parameter configured in the FLTest (forward business test parameter set) field. Alternatively, the test can be manually stopped via command-line commands.

[0201] After receiving the forward test data packet, the multi-user virtualization terminal extracts and verifies the sequence number and data content of the data packet, compares it with the preset configuration in the configuration file, and finally outputs the forward service test results including packet loss rate, out-of-order rate, and data integrity.

[0202] This implementation scheme, by loading improved state machine and testing functions into real physical satellite terminal hardware, allows for the simulation of large-scale multi-user access, online persistence, and service testing behavior on a single terminal without any modification to the physical layer hardware. It fully replicates the full protocol stack communication process of a real user and achieves comprehensive testing of all internal nodes of the satellite communication system, fundamentally solving the engineering challenges of multi-user testing in existing technologies. Specifically:

[0203] 1. The related technologies use pure software simulation, which can only reproduce high-level protocol interactions and cannot simulate the real behavior of the physical layer and link layer. This implementation scheme builds a multi-user virtual terminal based on real physical terminal hardware, which can completely simulate the terminal's behavior at the physical layer (time-frequency offset synchronization tracking, power control response), link layer (abnormal channel adaptive adjustment), and network layer. The test scenario is highly consistent with the real communication scenario, and the confidence level of the test results is higher than that of the pure software simulation scheme.

[0204] 2. Pure software simulation solutions of related technologies completely bypass key RF hardware such as the master station modulator and demodulator, making it impossible to verify the actual performance of such devices. The test process of this implementation plan covers the complete RF baseband link from the RF output of the master station modulator to the RF input of the master station demodulator. It can directly test the transmission performance of the master station modulator and the receiving and demodulation capabilities of the demodulator, achieving true end-to-end performance evaluation and filling the testing blind spot of related technologies.

[0205] 3. Pure software simulations of related technologies cannot reproduce the transmission impairments of real satellite channels. The MUE in this implementation scheme has a standard radio frequency interface, which can be directly connected to real satellite networks, or it can be used in conjunction with a radio frequency channel simulator to introduce channel impairments such as Doppler frequency offset, transmission delay, and signal attenuation at the real radio frequency signal level, and evaluate the system's extreme performance in complex real environments.

[0206] 4. Related technologies require the deployment of multiple physical terminals to achieve multi-user testing, resulting in extremely high equipment and environment costs. This implementation plan, through a resource configuration strategy of "unified binding of the same return channel resources" and a built-in time slot conflict arbitration mechanism, successfully achieves stable simulation of large-scale concurrent users on a single physical terminal without changing the terminal hardware architecture. This greatly reduces the equipment procurement and environment deployment costs for multi-user testing, while improving testing efficiency.

[0207] In one specific implementation scheme, to achieve the concurrent operation of a large number of virtual terminal instances on a single physical terminal, this scheme does not rely on heavy virtualization technologies such as containers or virtual machines, but instead adopts a lightweight task virtualization architecture based on instance control blocks. The core of this architecture is to design a multi-instance management engine on top of the terminal embedded operating system.

[0208] Specifically, the Multi-Instance Management Engine (MIME) is responsible for the lifecycle management of all virtual terminal instances. During system initialization, MIME pre-allocates a static instance control block pool from a contiguous memory heap according to a preset configuration file. This pool pre-allocates fixed-size memory blocks based on the maximum number of virtual instances supported by the system to store Virtual Terminal Instance Control Blocks (VTICBs). Each VTICB is allocated in the pre-allocated static memory pool, and the memory block address range occupied by each VTICB is fixed and does not overlap with each other, thereby ensuring that the storage resources of each virtual terminal instance are isolated from each other and do not interfere with each other.

[0209] Each VTICB can be an independent data structure that encapsulates all the state and resource handles required for the virtual terminal instance to run, specifically including the following functional fields:

[0210] Instance Identifier Field: Stores the unique user hardware identifier (Hid), network user identifier assigned by the master station, authentication password, network layer address, and other identity information of the instance, used to uniquely identify the virtual instance in the network.

[0211] The protocol state machine field maintains dynamic parameters such as the instance's current protocol state (standby, ALOHA login, time-frequency offset synchronization, online, etc.), retry sequence number, protocol counter, signal-to-noise ratio estimate, and control correction loss count. It's important to note that each protocol state is bound to a pointer to the instance's current state handling function. When an event is triggered, the scheduler can directly call the corresponding state handling logic through this pointer to implement a state-driven protocol flow.

[0212] Business Test Context Domain: Stores the instance's back / forward business test parameters (RLTest / FLTest), sequence numbers of sent / received data packets, packet loss / out-of-order statistics, etc., for subsequent data transmission quality assessment.

[0213] Resource Index Field: Maintains an index pointer to the business data buffer and the data length. Business data to be sent by the instance (e.g., IP packets) is not stored directly in the VTICB, but in a global shared buffer pool. The VTICB only references this data through the index pointer, thus avoiding frequent copying of large blocks of data between instances.

[0214] To achieve efficient instance scheduling, this implementation scheme designs a Virtual Instance Scheduler (VIS) on top of MIME. VIS maintains a fast index mapping table based on a hash algorithm. When a virtual terminal instance successfully logs in and is assigned a network user identifier by the master station, VIS uses this identifier as the key and generates a fast index entry pointing to the corresponding VTICB physical address through a hash algorithm. In subsequent event processing, VIS adopts an event-driven working mode. Specifically, when it is necessary to process an event of a virtual instance, it first performs a hash lookup based on its user identifier, directly indexes the target VTICB in O(1) time complexity, and then calls the processing function pointer bound to the current state in the VTICB to execute the corresponding protocol process. By using hash mapping instead of linear search or binary tree, random access to thousands of instances can be achieved on performance-constrained embedded hardware, meeting the stringent response time requirements of satellite communication systems.

[0215] In terms of resource management, this implementation plan adopts a static partitioning + dynamic indexing strategy to balance isolation and efficiency. Static partitioning means ensuring physical isolation of storage resources for each instance through a pre-allocated VTICB memory pool, preventing interference. Dynamic indexing means maintaining the set of currently active instances through a hash table in VIS. When a user goes offline, the corresponding hash table entry is deleted, but the VTICB memory block is retained in the pool for reuse by subsequent new instances, thus decoupling static resource reservation from dynamic active set management.

[0216] Furthermore, for the business data buffer, this implementation scheme is designed as a global shared buffer pool, with only index pointers to the buffer maintained in VTICB. When the scheduler sends data, it directly moves the data from the shared pool according to the index, avoiding the memory waste caused by pre-allocating independent large buffers for each instance. While ensuring that data does not interfere with each other between instances, the memory overhead is controlled at the O(N) level (N is the number of virtual instances), which is significantly better than the process-level isolation scheme.

[0217] According to an embodiment of the present invention, an electronic device is provided. The electronic device in this embodiment may include one or more of the following components: a processor, a network interface, memory, non-volatile memory, and one or more application programs, wherein the one or more application programs may be stored in the non-volatile memory and configured to be executed by one or more processors, and the one or more programs are configured to perform the methods described in the foregoing method embodiments.

[0218] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above description is only a specific embodiment of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A test method for a satellite communication system, characterized in that, The satellite communication system includes a terminal equipment side and a master station equipment side; the method includes: On the terminal device side, multiple virtual terminal instances are created and maintained; each virtual terminal instance has an independent user identifier and protocol state machine, and the multiple virtual terminal instances compete to share the same physical radio frequency transmission channel; the multiple virtual terminal instances are preset to use the same return channel resources; Generate multiple time slots to be sent for the multiple virtual terminal instances; Time overlap detection is performed on the multiple time slots, and a time slot is selected from the overlapping time slots according to a preset conflict arbitration strategy and sent to the master station equipment via the physical radio frequency transmission channel, while other overlapping time slots are discarded; wherein, by sending the selected time slot, multi-user concurrent access and service behavior are simulated for testing the satellite communication system.

2. The testing method for a satellite communication system according to claim 1, characterized in that, The step of creating and maintaining multiple virtual terminal instances on the terminal device side includes: Load a preset configuration file; wherein, the configuration file defines independent user identification information, authentication information and business test parameter information for multiple virtual terminal instances; The configuration file is parsed to create and initialize an independent virtual terminal instance for each defined user on a single hardware platform of the terminal device. Each virtual terminal instance maintains its own protocol state machine and service context and maps them to a shared physical radio frequency transmission channel.

3. The testing method for a satellite communication system according to claim 2, characterized in that, The process of generating multiple time slots to be sent for the multiple virtual terminal instances includes... In response to the state transition of the protocol state machine of each virtual terminal instance, a time slot to be transmitted corresponding to the current state is generated; wherein the parameters of the time slot to be transmitted are matched with the same return channel resources, and the type includes at least one of ALOHA login time slot, control time slot or service time slot.

4. The test method for a satellite communication system according to claim 3, characterized in that, The step of performing time overlap detection on the multiple time slots and selecting one time slot from the overlapping time slots according to a preset conflict arbitration strategy, transmitting it to the master station equipment via the physical radio frequency transmission channel, and discarding other overlapping time slots includes: For multiple time slots to be transmitted, calculate the start and end times of each time slot to determine the time interval corresponding to each time slot; By determining whether the time intervals of any two time slots intersect, it is determined whether the two time slots overlap in time sequence; If overlapping time slots are determined to exist, a preset arbitration rule is executed; wherein, the preset arbitration rule includes: if the overlapping time slots include a control time slot, then the control time slot is determined as the target transmission time slot; if the overlapping time slots are all ALOHA login time slots, then the ALOHA login time slot with the earliest start time is determined as the target transmission time slot. The target transmission time slot is transmitted to the master station equipment via the physical radio frequency transmission channel, while all other time slots that overlap with the target transmission time slot are discarded.

5. The test method for a satellite communication system according to claim 3, characterized in that, The protocol state machine of the virtual terminal instance includes at least a standby state, an ALOHA login state, and an online state; wherein, when in the ALOHA login state, an ALOHA login time slot is generated; when in the online state, a control time slot or a service time slot is generated; when in the standby state, no time slot to be sent is generated; wherein, if the protocol state machine exits from the ALOHA login state due to failure, it re-enters the ALOHA login state and does not return to the standby state.

6. The test method for a satellite communication system according to claim 3, characterized in that, The step of simulating concurrent access and service behavior of multiple users by sending selected time slots for testing the satellite communication system includes: After the virtual terminal instance successfully accesses the network based on its user identification information and authentication information, it initiates a capacity request to the main station device and sends a test data packet carrying a serial number based on the business test parameter information defined in the configuration file and the allocated time slot, and / or receives a forward test data packet from the main station device; wherein, the serial number is filled in for the sent test data packet, and the serial number and data content of the received test data packet are verified. Based on the verification results of the serial number and data content, the data transmission quality is evaluated to complete the performance verification of the satellite communication system; wherein, the performance verification is an end-to-end performance verification; wherein, the end-to-end performance verification includes at least the performance verification of the radio frequency modem and the higher-layer protocol processing node in the master station equipment.

7. The testing method for a satellite communication system according to claim 6, characterized in that, The service test parameter information includes back-end service test parameters and forward-end service test parameters; wherein, both the back-end service test parameters and the forward-end service test parameters include at least an enable flag, a test rate, a test duration, and test data content.

8. The test method for a satellite communication system according to claim 1, characterized in that, The multiple virtual terminal instances are preset to use the same return channel resources, specifically including: On the main station device side, user accounts of all virtual terminal instances belonging to the same terminal device side are configured with the same return channel parameters; wherein, the return channel parameters include center frequency, symbol rate and roll-off factor; In this context, after the multiple virtual terminal instances access the network, all their data transmissions are constrained to the same back-return channel resource defined by the same back-return channel parameters.

9. A test system for satellite communication, characterized in that, include: On the terminal device side, it includes at least one terminal device configured to create and maintain multiple virtual terminal instances; each virtual terminal instance has an independent user identifier and protocol state machine, and the multiple virtual terminal instances compete to share the same physical radio frequency transmission channel; the multiple virtual terminal instances are preset to use the same return channel resources; multiple time slots to be transmitted are generated for the multiple virtual terminal instances; time overlap detection is performed on the multiple time slots, and a time slot is selected from the overlapping time slots according to a preset conflict arbitration strategy and transmitted to the master station device side via the physical radio frequency transmission channel, while other overlapping time slots are discarded; wherein, by transmitting the selected time slot, multi-user concurrent access and service behavior are simulated for testing the satellite communication system; On the master station equipment side, the master station equipment side establishes a communication connection with the terminal equipment side and is configured to respond to and process the multi-user concurrent access and service behavior initiated by the terminal equipment side in order to complete the test of the satellite communication system.

10. An electronic device, characterized in that, include: A memory, and one or more processors communicatively connected to the memory; The memory stores instructions that can be executed by the one or more processors, which, when executed, enable the one or more processors to implement a test method for a satellite communication system as described in any one of claims 1 to 8.

Images