Transmission Control for Space–Air–Ground Integrated Multi-Hop Networks in Millimeter-Wave and Terahertz Communications

Abstract

Millimeter-wave (mmWave) and terahertz (THz) communications are susceptible to frequent link disruptions and severe performance degradation due to high directionality, significant path loss, and sensitivity to blockages. These challenges are particularly acute in highly dynamic and densely populated user environments. The issues present significant obstacles to ensuring reliability and quality of service (QoS) in future space–air–ground integrated networks. To address these challenges, this paper proposes an adaptive transmission control scheme designed for space–air–ground integrated multi-hop networks operating in the mmWave/THz bands. By analyzing the intermittent connectivity inherent in such networks, the proposed scheme incorporates an incremental factor and a backlog indicator into its congestion control mechanism. This allows for the accurate differentiation between packet losses resulting from network congestion and those caused by channel blockages, such as human body occlusion or beam misalignment. Furthermore, the scheme optimizes the initial congestion window during the slow-start phase and dynamically adapts its transmission strategy during the congestion avoidance phase according to the identified cause of packet loss. Simulation results demonstrate that the proposed method effectively mitigates throughput degradation from link blockages, improves data transmission rates in highly dynamic environments, and sustains more stable end-to-end connectivity. Our proposed scheme achieves a 35% higher throughput than TCP Hybla, 40% lower latency than TCP Veno, and maintains 99.2% link utilization under high mobility.

1. Introduction

The emergence of 6G communications has positioned millimeter-wave (mmWave) and terahertz (THz) frequency bands as key technologies for satisfying the ultra-high data rate demands of future applications. With their potential for Gbit/s-level bandwidth, they are crucial for immersive extended reality (XR), holographic communications, and wireless backhaul. To deliver advanced user experiences in densely populated areas such as indoor hotspots, stadiums, and transportation hubs, mmWave/THz network architectures rely on densely deployed base stations and highly directional beamforming to ensure effective signal coverage.

However, the physical properties of mmWave/THz signals present formidable challenges. Transmissions in these bands are highly susceptible to obstructions—such as the human body, walls, or adverse weather—which can cause sudden link disruptions. Furthermore, high terminal mobility can exacerbate beam misalignment, significantly degrading link reliability and stability. Traditional transport control protocols, such as TCP, are ill suited for these environments because they cannot distinguish between packet loss from physical-layer blockages and that from network-layer congestion. Consequently, they often misinterpret blockage-induced losses as congestion, erroneously invoking control mechanisms that drastically reduce the sending rate. This leads to significant bandwidth underutilization, even after the channel has recovered [1]. Sustaining robust transmission performance in highly dynamic mmWave/THz networks therefore remains a significant challenge.

While considerable research has focused on mmWave/THz network architectures and performance optimization, the design of adaptive transport protocols for these unique high-frequency channels remains suboptimal [2,3,4]. Thus, developing efficient transmission control mechanisms that can fully exploit the bandwidth potential of mmWave/THz networks has become a critical research imperative.

To address this need, this paper investigates the transmission performance within space–air–ground integrated networks, analyzing how architectural features affect the performance of such a hybrid system. We propose a theoretical framework for transmission control optimization that focuses on preventing erroneous congestion judgments and enabling rapid transmission recovery. Through problem decomposition and the design of a cross-layer network control strategy, this work offers a framework for enhancing transmission performance in dynamic and blockage-prone mmWave/THz environments.

2. Related Work

2.1. Millimeter-Wave/Terahertz Network Architectures

Researchers have conducted extensive studies on the architecture of millimeter-wave (mmWave) and terahertz (THz) communication networks. To address the challenge of limited coverage, Integrated Access and Backhaul (IAB) architectures have been proposed, enabling flexible coverage expansion via wireless multi-hop backhaul links [5]. To mitigate the susceptibility of mmWave/THz links to blockage, multi-connectivity techniques have attracted significant attention. These allow user terminals to simultaneously connect to base stations operating at mmWave/THz and Sub-6GHz frequencies, thereby improving connection robustness [6,7].

A considerable amount of research has also focused on transport protocol optimization. Zong [8] proposed a cross-layer transmission scheme tailored to the directional and interruption-prone characteristics of mmWave links. This scheme leverages physical layer channel state information to guide the adjustment of the congestion window. Nguyen [9] developed a TCP performance analysis model that accounts for beamforming and alignment errors, quantitatively revealing the impact of physical layer imperfections on upper-layer throughput. Zong [10] further proposed an end-to-end transport control scheme for mobile scenarios, which freezes the TCP state during link outages and rapidly resumes transmission upon link recovery, thus adapting well to highly dynamic network conditions.

Ouyang [11] investigated a software-defined networking (SDN)-based multipath transport control protocol. By intelligently selecting paths, this protocol prioritizes high-quality mmWave links while maintaining backup paths to support low-latency service demands. Wang [12] introduced a machine learning-based beam prediction scheme to enhance connection stability and thereby improve transport protocol performance. Nguyen [13] analyzed the TCP performance of hybrid mmWave/RF links under various weather conditions (e.g., rain fade).

2.2. Transmission Control for Millimeter-Wave/Terahertz Communications

Efforts to improve TCP performance over mmWave/THz networks have also been substantial. Xia [14] analyzed the performance of various TCP variants in mmWave scenarios and discussed the key technologies for cross-layer design. Lubna [15] proposed a low-latency, high-throughput scheduler that makes real-time scheduling decisions based on beam quality and path loss, improving both throughput and delay performance. Hu [16] designed flexible network architecture in which transport protocols dynamically adapt their behavior based on link conditions, addressing the “all-or-nothing” nature of mmWave links.

Gupta [17] studied transmission strategy optimization in UAV-assisted mmWave heterogeneous networks to enhance spectrum efficiency and reduce transmission delay. Lafta [18] proposed a co-designed routing and transport protocol to reduce packet loss caused by link switching or blockage, thereby improving overall quality of service (QoS). Gures [19] reviewed mobility management challenges and solutions for highly dynamic mmWave communications in 5G and beyond networks. Jude [20,21] proposed leveraging network-assisted information to enhance TCP performance in wireless environments. By feeding back real-time link states from base stations, the sender can distinguish between congestion-induced and wireless-induced packet losses. León [22] proposed a distributed, machine learning-based congestion control protocol that learns and predicts link availability to make more intelligent transmission decisions.

While the above studies have achieved significant progress by optimizing specific aspects of mmWave/THz communications, comprehensive transport control protocols that fully adapt to their highly dynamic and blockage-prone characteristics remain insufficiently explored. In particular, traditional TCP protocols perform poorly under scenarios involving high user mobility, frequent beam switching, and link blockage.

Motivated by this, this paper adopts a cross-layer design approach, combining real-time link status sensing with intelligent congestion window control at the transport layer. We propose a novel transmission mechanism aimed at significantly improving data rate and connection stability in high-mobility mmWave/THz networks. This work provides a valuable reference for the design of future protocols in such environments.

The remainder of this paper is organized as follows: Section 3 analyzes existing TCP mechanisms and applicable network models; Section 4 presents a novel transport control mechanism for multi-hop heterogeneous networks combining satellite and wireless sensor networks; Section 5 evaluates the proposed protocol through simulations and compares it with baseline approaches to demonstrate its effectiveness in improving data transmission rates; Section 6 concludes the paper with a summary and discussion of key findings.

3. Applicable Scenarios and Existing Research Solutions

3.1. Channel Characteristics of Millimeter-Wave and Terahertz Communications

Millimeter-wave (mmWave) and terahertz (THz) communication systems consist of base stations (gNBs), relay nodes, and user equipment (UE), and are capable of forming extremely narrow directional beams using ultra-large-scale antenna arrays to compensate for severe path loss. This highly directional communication mode exhibits quasi-optical propagation characteristics, but also makes the system extremely sensitive to link blockages.

The mmWave/THz links typically rely on line-of-sight (LoS) transmission. When a direct path exists between the base station and the terminal, the system can achieve very high signal-to-noise ratio (SNR) and data rates. However, once the LoS path is obstructed by obstacles such as pedestrians, vehicles, or buildings, the signal can suffer from abrupt attenuation of several tens of decibels, leading to instantaneous link disruption. This “all-or-nothing” behavior is one of the most critical challenges in mmWave/THz communications.

To address this issue, network architectures commonly adopt multipath transmission and fast beam switching techniques. For instance, the system may utilize non-line-of-sight (NLoS) paths—such as reflections off walls—to maintain connectivity, or rapidly switch to another available base station or relay node when the primary serving base station is blocked. This architectural complexity imposes greater demands on upper-layer transport protocols, requiring them to adapt quickly to dynamic link conditions and ensure robust end-to-end performance.

3.2. Network Architecture

Millimeter-wave (mmWave) and terahertz (THz) communication networks are expected to provide core support for a wide range of future application scenarios, particularly in environments that demand ultra-high bandwidth and ultra-low latency, such as dense urban areas, indoor hotspots, and vehicle-to-everything (V2X) systems. As shown in Figure 1, a typical mmWave/THz network model for dense urban deployment is constructed as follows:

In this model, the top layer consists of a space–air network, which provides all-weather network access services for the underlying millimeter-wave (mmWave) and terahertz (THz) communication networks. The bottom layer is densely deployed with mmWave/THz sensor nodes, responsible for delivering high-speed data access in hotspot areas.

User terminals—such as smartphones, vehicles, and AR/VR devices—move through densely populated urban environments filled with high-rise buildings and heavy pedestrian and vehicular traffic. As these terminals move between the beam coverage areas of different small cells, or when their links to base stations are momentarily blocked by obstacles like people or vehicles, frequent link disruptions and handovers occur. Such highly dynamic and blockage-prone environments impose stringent requirements on the robustness and efficiency of transport protocols.

Based on the above transmission paths, this space–air–ground integrated multi-hop network architecture tailored for mmWave/THz communications enables diverse and flexible network access services for users, significantly enhancing data delivery capabilities across complex and dynamic network conditions.

3.3. Limitations of Traditional TCP Protocols in Millimeter-Wave and Terahertz Networks

As the core reliable transport protocol of the Internet, TCP’s congestion control mechanism plays a critical role in ensuring stable network operation. However, traditional TCP protocols were originally designed for wired networks, where the fundamental assumption is that “packet loss implies congestion.” This assumption does not hold in the context of millimeter-wave (mmWave) and terahertz (THz) wireless environments.

TCP Reno [23] is a classic congestion control algorithm that consists of three main phases: slow start, congestion avoidance, and fast recovery. When Reno detects packet loss (typically via three duplicate acknowledgments or timeout), it immediately halves the congestion window (cwnd) and reduces the data transmission rate, assuming that the network is congested. In mmWave/THz networks, however, temporary link blockages can lead to sudden and significant packet loss, even in the absence of actual congestion. Reno misinterprets such losses as a sign of severe congestion and drastically reduces its sending rate. Even after the blockage disappears and the high-bandwidth link is restored, Reno must gradually increase the rate through the slow start phase, resulting in severe underutilization of the available channel capacity and wasted bandwidth resources.

TCP Vegas [24] is a delay-based congestion control algorithm. It attempts to proactively predict congestion by comparing the expected throughput with the actual measured throughput and reduces the sending rate before packet loss occurs. However, mmWave/THz links typically exhibit low and relatively stable round-trip times (RTTs), and link interruptions manifest as sudden bursts of packet loss rather than gradual increases in RTT. Consequently, Vegas’s congestion prediction mechanism often fails in such environments.

When a blockage occurs, Vegas also enters congestion control mode due to retransmission timeouts, resulting in performance degradation similar to Reno. These limitations indicate that both Reno and Vegas are ill-suited to the intermittent and high-variability nature of mmWave/THz channels, highlighting the need for new transport control mechanisms tailored to these unique wireless conditions.

4. Optimal Transmission Control for Heterogeneous Network

4.1. Protocol Mechanisms of Tcp Veno and Tcp Hybla

Tcp Veno is a modification of the Reno algorithm. The main idea is different from the Reno idea; the innovation is that in Reno, the congestion window increases based on the stage of the connection being taken into account. When the number of squeezed messages in the queue A is greater than the threshold value of B, the congestion algorithm will be changed from the previous current congestion window (Cwnd) in each RTT to increase by 1 every RTT. The Cwnd mentioned here is the size of the congestion window. RTT is the last measured round-trip delay, which consists of three components: the propagation time of the link, processing time of the end system, and the queuing and processing time in the router’s buffer.

Carlo Caini et al. proposed a new TCP algorithm TCP Hybla [25]. It is a protocol to enhance TCP performance to address TCP performance degradation in large round-trip latencies. The RTT-referenced TCP connection transfer rate is used as the standard for the design, and a distinction is made between data loss due to network congestion and random loss. Although a larger congestion window can be achieved, this results in frequent packet losses within a window, which can have a significant impact on the transmission rate.

4.2. Optimized Transport Mechanism

The proposed scheme measures two important values at the sender’s end during data transmission: the actual rate at which the data is sent (Actual) and the expected rate at which the data is transmitted (Expected).

$$\mathrm{E}\mathrm{x}\mathrm{p}\mathrm{e}\mathrm{c}\mathrm{t}\mathrm{e}\mathrm{d}={\displaystyle \frac{\mathrm{C}\mathrm{w}\mathrm{n}\mathrm{d}}{\mathrm{M}\mathrm{R}\mathrm{T}\mathrm{T}}}$$

(1)

$$\mathrm{A}\mathrm{c}\mathrm{t}\mathrm{u}\mathrm{a}\mathrm{l}={\displaystyle \frac{\mathrm{C}\mathrm{w}\mathrm{n}\mathrm{d}}{\mathrm{R}\mathrm{T}\mathrm{T}}}$$

(2)

The minimum round-trip time (MRTT) mentioned here is the value of the smallest RTT measured. Define Diff as the difference between the actual sending rate and the expected sending rate:

$$\mathrm{D}\mathrm{i}\mathrm{f}\mathrm{f}=\mathrm{E}\mathrm{x}\mathrm{p}\mathrm{e}\mathrm{c}\mathrm{t}\mathrm{e}\mathrm{d}-\mathrm{A}\mathrm{c}\mathrm{t}\mathrm{u}\mathrm{a}\mathrm{l}$$

(3)

If the round-trip delay is greater than the minimum round-trip delay when RTT > MRTT, it means that there is a backlog of messages in the process of transmitting data; assuming that the backlog length of messages in the queue is A, then,

$$\mathrm{R}\mathrm{T}\mathrm{T}=\mathrm{M}\mathrm{R}\mathrm{T}\mathrm{T}+{\displaystyle \frac{A}{Actual}}$$

(4)

$$\mathrm{A}=(\mathrm{R}\mathrm{T}\mathrm{T}-\mathrm{M}\mathrm{R}\mathrm{T}\mathrm{T})\times \mathrm{A}\mathrm{c}\mathrm{t}\mathrm{u}\mathrm{a}\mathrm{l}$$

(5)

$$\mathrm{A}={\displaystyle \frac{cwnd}{RTT}}\times RTT-Actual\times MRTT$$

(6)

$$\mathrm{A}={\displaystyle \frac{cwnd}{MRTT}}\times MRTT-Actual\times MRTT$$

(7)

$$\mathrm{A}=(\mathrm{E}\mathrm{x}\mathrm{p}\mathrm{e}\mathrm{c}\mathrm{t}\mathrm{e}\mathrm{d}-Actual)\times MRTT=Diff\times MRTT$$

(8)

Assuming MRTT = 1/4x RTT then,

$$\mathrm{A}={\displaystyle \frac{3RTT}{4}}\times {\displaystyle \frac{Cwnd}{RTT}}={\displaystyle \frac{3}{4}}Cwnd$$

(9)

Assuming that MRTT = 1/2x RTT then,

$$\mathrm{A}={\displaystyle \frac{RTT}{2}}\times {\displaystyle \frac{Cwnd}{RTT}}={\displaystyle \frac{1}{2}}Cwnd$$

(10)

It can be seen that if the difference between RTT and MRTT is larger, then the A value is larger and the network is more congested. So, to some extent the magnitude of the A value can be used to represent the degree of network congestion. If A ≥ B then the packet is considered to be lost in congestion. If A < B then the packet is considered to be lost with this loss, and the threshold value B is generally 3.

The data is constantly updated during transmission, and the values of RTT and MRTT measured at different time points are different. It is necessary to compare and record the minimum RTT value to keep the data updated at all times.

The proposed scheme is designed to obtain the same transmission rate B(t) when a TCP connection has a large RTT by referring to the RTT transmission rate of the TCP connection as a standard.

$$\mathrm{B}\left(\mathrm{t}\right)={\displaystyle \frac{\mathrm{C}\mathrm{w}\mathrm{n}\mathrm{d}\left(\mathrm{t}\right)}{\mathrm{R}\mathrm{T}\mathrm{T}}}$$

(11)

In order to reduce the effect of propagation delay RTT in the process of transmitting data in a satellite link, p is introduced here as the normalized round-trip delay, p is the ratio of RTT and ${\mathrm{R}\mathrm{T}\mathrm{T}}_0$. ${\mathrm{R}\mathrm{T}\mathrm{T}}_0$ is the round-trip delay of the reference link defined in order to achieve the compensation effect.

$$\mathrm{p}={\displaystyle \frac{\mathrm{R}\mathrm{T}\mathrm{T}}{{\mathrm{R}\mathrm{T}\mathrm{T}}_0}}$$

(12)

In order to minimize the effect of RTT on the congestion window, let the threshold value and the time taken to reach the threshold value be as follows:

$$\mathrm{C}\mathrm{w}\mathrm{n}\mathrm{d}\left(\mathrm{t}\right)=\left\{\begin{array}{c}{2}^{{\displaystyle \frac{\mathrm{t}}{\mathrm{R}\mathrm{T}\mathrm{T}}},0<\mathrm{t}<{\mathrm{t}}_{\mathrm{s}}},\mathrm{SS}\\ {\displaystyle \frac{\mathrm{t}-{\mathrm{t}}_{\mathrm{s}}}{\mathrm{R}\mathrm{T}\mathrm{T}}}+\mathrm{s},\mathrm{t}>{\mathrm{t}}_{\mathrm{s}},\mathrm{CA}\end{array}\right.$$

(13)

Here slow start (SS) is the slow start, also called the exponential growth period, a blocking control mechanism, which means that the TCP receiving window grows every time it receives an acknowledgement. Congestion avoidance (CA) is the congestion avoidance phase—also a blocking control mechanism.

Multiplying time by the normalized round-trip delay p yields the RTT independent Cwnd (pt):

$$\mathrm{C}\mathrm{w}\mathrm{n}\mathrm{d}\left(\mathrm{p}\mathrm{t}\right)=\left\{\begin{array}{c}\mathrm{P}{2}^{{\displaystyle \frac{\mathrm{t}}{\mathrm{R}\mathrm{T}\mathrm{T}}},0<\mathrm{t}<{\mathrm{t}}_{\mathrm{s}}},\mathrm{SS}\\ \mathrm{P}[{\displaystyle \frac{\mathrm{t}-{\mathrm{t}}_{\mathrm{s}}}{\mathrm{R}\mathrm{T}\mathrm{T}}}+\mathrm{s}],\mathrm{t}>{\mathrm{t}}_{\mathrm{s}},\mathrm{CA}\end{array}\right.$$

(14)

The resulting congestion window is multiplied by p to obtain the RTT independent B(t):

$$\mathrm{C}\mathrm{w}\mathrm{n}\mathrm{d}\left(\mathrm{p}\mathrm{t}\right)\ast \mathrm{p}=\left\{\begin{array}{c}\mathrm{P}{2}^{{\displaystyle \frac{\mathrm{p}\mathrm{t}}{\mathrm{R}\mathrm{T}\mathrm{T}}},0<\mathrm{t}<{\mathrm{t}}_{\mathrm{s}}},\mathrm{SS}\\ \mathrm{P}[\mathrm{P}{\displaystyle \frac{\mathrm{t}-{\mathrm{t}}_{\mathrm{s}}}{\mathrm{R}\mathrm{T}\mathrm{T}}}+\mathrm{s}],\mathrm{t}>{\mathrm{t}}_{\mathrm{s}},\mathrm{CA}\end{array}\right.$$

(15)

Substituting and simplifying the equation $\mathrm{p}={\displaystyle \frac{\mathrm{R}\mathrm{T}\mathrm{T}}{{\mathrm{R}\mathrm{T}\mathrm{T}}_0}}$ yields the following:

$$\mathrm{C}\mathrm{w}\mathrm{n}\mathrm{d}\left(\mathrm{p}\mathrm{t}\right)\ast \mathrm{p}=\left\{\begin{array}{c}\mathrm{p}\ast 2^{{\displaystyle \frac{\mathrm{t}}{{\mathrm{R}\mathrm{T}\mathrm{T}}_0}}},0<\mathrm{t}<{\mathrm{t}}_{\mathrm{s}},\mathrm{SS}\\ \mathrm{P}[{\displaystyle \frac{\mathrm{t}-{\mathrm{t}}_{\mathrm{s}}}{{\mathrm{R}\mathrm{T}\mathrm{T}}_0}}+\mathrm{s}],\mathrm{t}>{\mathrm{t}}_{\mathrm{s}},\mathrm{CA}\end{array}\right.$$

(16)

According to the data transmission rate formula B (t) = Cwnd(t)/RTT, so the actual transmission rate is as follows:

$${\displaystyle \frac{\mathrm{C}\mathrm{w}\mathrm{n}\mathrm{d}\left(\mathrm{p}\mathrm{t}\right)\ast \mathrm{p}}{\mathrm{R}\mathrm{T}\mathrm{T}}}={\displaystyle \frac{\mathrm{C}\mathrm{w}\mathrm{n}\mathrm{d}\left(\mathrm{p}\mathrm{t}\right)}{{\mathrm{R}\mathrm{T}\mathrm{T}}_0}}=\left\{\begin{array}{c}{\displaystyle \frac{1}{{\mathrm{R}\mathrm{T}\mathrm{T}}_0}}\ast 2^{{\displaystyle \frac{\mathrm{t}}{{\mathrm{R}\mathrm{T}\mathrm{T}}_0}}},0<\mathrm{t}<{\mathrm{t}}_{\mathrm{s}},\mathrm{SS}\\ {\displaystyle \frac{1}{{\mathrm{R}\mathrm{T}\mathrm{T}}_0}}[{\displaystyle \frac{\mathrm{t}-{\mathrm{t}}_{\mathrm{s}}}{{\mathrm{R}\mathrm{T}\mathrm{T}}_0}}+\mathrm{s}],\mathrm{t}>{\mathrm{t}}_{\mathrm{s}},\mathrm{CA}\end{array}\right.$$

(17)

Both sides of the formula are multiplied by ${\mathrm{R}\mathrm{T}\mathrm{T}}_0$ at the same time:

$$\mathrm{C}\mathrm{w}\mathrm{n}\mathrm{d}\left(\mathrm{p}\mathrm{t}\right)=\left\{\begin{array}{c}{2}^{{\displaystyle \frac{\mathrm{t}}{{\mathrm{R}\mathrm{T}\mathrm{T}}_0}}},0<\mathrm{t}<{\mathrm{t}}_{\mathrm{s}},\mathrm{SS}\\ {\displaystyle \frac{\mathrm{t}-{\mathrm{t}}_{\mathrm{s}}}{{\mathrm{R}\mathrm{T}\mathrm{T}}_0}}+\mathrm{s},\mathrm{t}>{\mathrm{t}}_{\mathrm{s}},\mathrm{CA}\end{array}\right.$$

(18)

From this formula, we can know that the congestion window of data transmission is not related to RTT but related to ${\mathrm{R}\mathrm{T}\mathrm{T}}_0$.

To simplify the configuration of the congestion window and ensure compatibility with traditional transport protocols, the congestion window in the slow start (SS) phase is updated as ${\mathrm{C}\mathrm{w}\mathrm{n}\mathrm{d}}^{\mathrm{i}+1}={\mathrm{C}\mathrm{w}\mathrm{n}\mathrm{d}}^{\mathrm{i}}+2^{\mathrm{p}}-1$, while the window in the congestion avoidance (CA) phase is updated as ${\mathrm{C}\mathrm{w}\mathrm{n}\mathrm{d}}^{\mathrm{i}+1}={\mathrm{C}\mathrm{w}\mathrm{n}\mathrm{d}}^{\mathrm{i}}+{\displaystyle \frac{{\mathrm{p}}^2}{{\mathrm{C}\mathrm{w}\mathrm{n}\mathrm{d}}^{\mathrm{i}}}}$.

This algorithm maintains the ACK mechanism used in the standard TCP window, which can achieve a larger congestion window. But this will lead to more frequent packet loss in the window, especially when the RTT is large, which will have a greater impact on the transmission rate.

If data loss occurs during transmission in traditional schemes, it is considered to be caused by congestion. The proposed scheme adopts a differentiated data loss strategy through improvement, which can determine whether the data loss is caused by network congestion or random loss. This scheme fully utilizes the high-bandwidth delay product of the satellite network, but when the number of nodes increases, the random loss of data will also increase. In order to optimize the above scenario, a new algorithm is proposed to increase the data transmission and to distinguish whether the data loss is due to network congestion or due to random loss.

5. Simulation and Performance Analysis

This section presents the simulation setup and evaluates the performance of the proposed algorithm against established TCP protocols. The simulation model is illustrated in Figure 2. In this model, data is transmitted from a server, through a data gateway, to a multi-hop terminal receiver. The Bit Error Rate (BER) for the satellite downlink is varied from 1 × 10⁻⁵ to 1 × 10⁻⁹ to simulate different channel conditions. The primary performance metrics are throughput and access layer delay, measured as the number of hops in the terminal network, which increases from one to five. The experiments compare the performance of four schemes: TCP Reno, TCP Veno, TCP Hybla, and our proposed algorithm.

5.1. Transmission Rates for Long-Delay Links

The results of the experiments compare four schemes: the TCP Reno, the TCP Veno, the TCP Hybla, and the proposed. The vertical coordinate is the rate of packet propagation per second and the horizontal coordinate is the data on nodes 1–5 of the multichip terminals. The bottleneck link transmission rate of the heterogeneous network is tested in the experimental simulation, and the data in the figure can be reflected from the above-mentioned parameters. Figure 3 shows the transmission rate of the satellite link in the heterogeneous network when the BER of the satellite link is 1 × 10⁻⁵.

As seen in Figure 3, the link transmission rate of these four schemes changes with the change of node hop counts. TCP Reno maintains a transmission rate of about 5 packets/sec over the links at different hops of a multi-hop network built by a satellite network with wireless sensors. This is related to its transmission policy. When a loss of data occurs in transmission, TCP Reno directly assumes that there is congestion in the network. A slow start is initiated to alleviate further data backlog, and the window for sending data is simply halved. In addition, this scheme, which uses a linear increase in data during the slow-start phase, is also unable to cope with satellite networks with long latency bandwidths in heterogeneous networks. Therefore, this transmission scheme of TCP Reno greatly affects the transmission performance of heterogeneous networks.

TCP Veno scheme is adopted to differentiate the data loss strategy, comparing the bar chart in Figure 3, it can be found that the transmission rate of TCP Veno is maintained at around 6 packets/sec for different hop links in the wireless sensor multichip network. The multi-hop terminal link transmission rate is enhanced with respect to TCP Reno, both of which perform data transmission in a wireless environment, which greatly increases the probability of random data loss. After adopting the strategy of differentiating data loss, different transmission strategies for data loss due to congestion and random loss due to wireless links in heterogeneous networks can greatly improve the transmission efficiency of the network.

TCP Hybla maintains a transmission rate of about 11.8 packets/sec over different hop count links in a multi-hop network of satellite networks and wireless sensors, due to its strategy of increasing the amount of data transmitted. This algorithm nearly doubles the transmission rate compared to both TCP Reno and TCP Veno. From 2 hop to 5 hop of the multichip terminal, it can be seen that as the number of nodes increases, the transmission rate decreases. It is clear that as the number of nodes increases there is a possibility of packet loss during transmission and the rate decreases.

The proposed scheme increases the number of data transmission and at the same time different the data loss category. This clearly facilitates the transmission in heterogeneous networks of satellite network and multi-hop network of wireless sensors. The proposed algorithm maintains a transmission rate around 12.4 packets/sec over different hop-count links. The transmission rate of the links in the proposed scheme is also improved compared to TCP Veno, TCP Hybla, and TCP Reno as seen in the figure. However, from 2 to 5 hop of the multi-hop wireless sensor terminal, it is easy to realize that the transmission rate decreases as the number of hop increases.

Figure 4 shows the transmission rate of the satellite link in the heterogeneous network when the BER of the satellite link is 1 × 10⁻⁶. Compared with 1 × 10⁻⁵, the transmission rates of these four schemes are improved. TCP Veno scheme for the loss of data transmission although it would be considered that congestion occurs. With the reduction of the BER still has a great impact on the data transmission, as can be observed through the Figure 4. It maintains a transmission rate about 13 packets/sec. TCP Veno transmission rate is generally maintained about 14 packets/sec and decreases as the number of hops increases. TCP Hybla propagation rate is still significantly higher than the former. It does not change much as the number of hop increases, and the variation is very small. The advantage of these four schemes over the propagation rate of the newly proposed is still significant.

Figure 5 Show the transmission rate of the satellite link in the heterogeneous network with BER of 1 × 10⁻⁷. As the BER decreases, the transmission rate of all the four algorithms is improved, the transmission rate of the three TCP Reno, TCP Veno, and TCP Hybla generally maintains around 15 packets/sec, which is not a big difference. The transmission rate of the proposed algorithm is generally maintained at around 16 packets/sec. Although the proposed algorithm does not show a great advantage in the transmission rate at 1 and 2 hops of the multi-hop terminals of the wireless sensor network. It starts to show gradually in the process of 3 to 5 hops of the multi-hop terminals. As the number of hops increases, the transmission rates of all the four algorithms are decreasing.

Figure 6 Transmission rate of these four algorithms once again when BER is reduced to 1 × 10⁻⁸. TCP Veno, TCP Reno, TCP Hybla, and Proposed with the increase in the number of hops, the data transmission rate gradually decreases. The transmission rate of TCP Hybla and Proposed is the same at 1 hop. Both are around 18 packets/sec, a decreasing trend occurs at 2 hops of the wireless sensor multi-hop terminal. When at the 5 hop of the multi-hop terminal, the transmission rate of the other three, except for the proposed algorithms, decrease drastically, with TCP Veno and TCP Reno decreasing to three times their previous rates.

Such data changes also reaffirm that the proposed algorithm has good stability in the transmission of data. Although the number of hops increases, rate is still able to maintain at a stable value.

Figure 7 Show the transmission rate of the satellite link in the heterogeneous network with BER of 1 × 10⁻⁹. The difference in the transmission rates of the four algorithms is more obvious when the multi-hop terminal is 5 hop. The transmission rates of Hybla and Proposed are equal but better than TCP Veno and TCP Reno when the multi-hop terminals are 1 hop and 2 hop.

From the above five sets of simulation results, with the gradual decrease in the BER, the data transmission rates of the four algorithms are increasing. The proposed algorithm has strong stability, and for the heterogeneous network constructed by satellite network and wireless sensors, increasing the number of data transmissions is more effective than distinguishing the loss of data to improve the transmission rate of the link. The proposed scheme optimizes the transmission rate of the link among the four schemes due to the consideration of the respective characteristics of the satellite network and the multi-hop network.

5.2. Node Access Layer Latency

Figure 8 shows the sum of all the delays at the access layer in a multichip network when the BER is 1 × 10⁻⁵, including the delays of contention in the wireless channel, data processing delay, etc. From Figure 8, the delay increases gradually from 1 hop to 5 hops. Different strategies are used to deal with the sending rate in satellite networks and wireless sensor multichip networks, where a large amount of forwarded data is back logged at the gateway. Once a packet loss occurs in TCP Reno, it is considered that congestion has occurred, and the sending rate is limited to reduce the level of congestion and minimize the amount of data being transmitted. Therefore, the value of data squeezing at the access point is also minimized as 0.886 × 10⁻³ s. TCP Veno is using the strategy of lowering the congestion window and adjusting the thresholds higher in fast recovery. Therefore, the data transmission is slightly more than TCP Reno, as 0.911 × 10⁻³ s. The delay difference between the proposed algorithm and TCP Hybla scheme at the access point is not much—1.055 × 10⁻³ s and 1.060 × 10⁻³ s, respectively.

Through Figure 8 it is observed that as the number of hops increases, the delay also increases to varying degrees. The data suffers more delay when it is transmitted internally in a multi-hop network; this is mainly due to the intense competition in the media access control (MAC) channel, the instability of the routing in the multichip network, and other factors, which indirectly affect the delay of the gateway MAC. MAC protocol is characterized by its simplicity, flexibility, and robustness, which makes it very popular. Nodes compete to seize the channel usage rights and data collision occurs when more than one node sends data at the same time. When the amount of data transmitted increases, the probability of collision also increases and the throughput decreases, resulting in increased delay. The newly proposed algorithm and Hybla transmits larger amount of data compared to other two schemes, so the delay becomes larger. The delay data for the newly proposed algorithm is 1.95 × 10⁻³ s at 5 hops and for Hybla algorithm is 1.39 × 10⁻³ s at 5 hops.

Apart from this aspect which leads to an increase in delay, there are other reasons as well which also lead to an increase in delay. When a large amount of data is transmitted, in order to be able to increase the rate of propagation, it is solved by increasing the bandwidth. When the satellite bandwidth is increased, the ground station will need more time to process and forward more data. If there is congestion at this time, we have to deal with these problem;, a series of complex processes will lead to increased delay. As well as the transmission of data from the source to the host, due to the multi-hop network, 1 hop and 5 hops distance from the source is different, so this also leads to the number of hops with the increase in propagation delay continuing to increase the reason. For this architecture model, although the gateway delay increases, the propagation rate of the link is also increasing.

Figure 9 presents the delay at a lower BER of 1 × 10⁻⁷. The trend remains consistent. With a better channel quality, more data is transmitted successfully by all protocols, leading to more intense channel competition and thus higher overall delays compared to the 1 × 10⁻⁵ BER case. Again, the proposed algorithm and Hybla show the highest latency, which is attributable to their success in handling a larger amount of data. This highlights a fundamental trade-off: achieving a higher link propagation rate can increase gateway delay. Properly coordinating data transmission between the satellite and sensor network segments is crucial to balance this trade-off and optimize the performance of the entire heterogeneous network.

6. Conclusions

To realize the full potential of mmWave and THz communications, it is imperative to optimize transport control mechanisms for the challenges of highly dynamic and blockage-prone channels. This requires protocols that can intelligently distinguish between network congestion and physical link failures to maximize throughput and maintain stable connectivity in space–air–ground integrated networks. This paper investigated the characteristics of mmWave/THz systems and proposed an adaptive TCP protocol to address these challenges.

The primary findings are as follows:

• The proposed algorithm demonstrates superior data throughput compared to conventional protocols like TCP Reno, Veno, and Hybla in simulated mmWave/THz environments. By strategically increasing data transmission and accurately differentiating between congestion-based and random packet loss, it achieves higher and more stable transmission rates.
• The scheme exhibits exceptional robustness, maintaining high throughput with minimal performance fluctuation even under conditions with frequent link blockages, unlike existing protocols.
• Through theoretical analysis and simulation, this study presents a novel adaptive transport protocol and a simulation model that captures the core challenges of mmWave/THz communications, offering valuable insights for future protocol design.

The current work is based on simulation results. Future research will focus on validating these findings by implementing the proposed scheme on a real-world mmWave/THz hardware testbed. This step will be crucial for refining the algorithm and assessing its practical impact on optimizing transport control in next-generation networks.