Writing
kittu_unadu
WLN.docx
I. INTRODUCTION
Having a reliable end-to-end connection is one of the primary concerns in telecommunication. This aim can be attained by using the transport layer mostly deployed protocol, TCP (Transmission Control Protocol) [1], in a way that it strives to guarantee the delivery of each packet by using ACKs (Acknowledgements). During the last decades, various TCPs have been proposed to cope with different networks based on the network’s type and its unique characteristics [2], and each one had its own advantages and disadvantages.
With the emergence of 5G mmWave (millimeter-wave), new principles and paradigms have been included in cellular networks. The new generation can provide different use cases by relying on the vast available spectrum in high frequen- cies [3], [4]. However, due to the intermittent characteristic of mmWave, TCP cannot perform well and experiences per- formance degradation [5], [6]. The cause of this behavior is
role in TCP’s final performance. From the ITU-R (Inter- national Telecommunication Union- Radiocommunication) point of view, there are five different scenarios, including indoor hotspot-eMBB (Enhanced Mobile Broadband), dense urban-eMBB, rural-eMBB, urban macro-mMTC (massive Machine Type Communication), and urban macro-URLLC (Ultra-Reliable Low-Latency Communication) [8]. These five scenarios are considered as test environments in order to evaluate the performance of IMT-2020 (International Mobile Telecommunications), i.e., 5G networks [9]. Deploy- ing eMBB provides high data rates for a variety of services, URLLC is for latency-sensitive connections, and mMTC is for supporting a large number of devices. A thorough expla- nation of these five scenarios can be found in [8].
From the 3GPP point of view, there are twelve different deployment scenarios [10], and each scenario can be used based on the needs and equipment availability. The twelve scenarios include indoor hotspot, dense urban, rural, urban macro, high-speed, extreme long-distance coverage in low- density areas, urban coverage for massive connections, high- way scenario, the urban grid for connected cars, commercial air to ground, light aircraft scenario, and satellite extension to terrestrial.
A thorough investigation of TCP and 5G networks, their procedures, and parameters have been presented in [6]. The paper incorporates analysis of 5G networks, the functionality of TCP and how it performs over the new cellular networks, the existing advantages and disadvantages of 5G mmWave networks, the state-of-the-art of 5G networks, and how to deal with the problems in order to improve performance of TCP in 5G networks.
A detailed analysis of the high-speed scenario has been done in [5]. The authors analyzed TCP’s behavior over 5G mmWave networks in a high-speed train and investigated the impacts of different parameters on the most important KPIs (Key Performance Indicators) of TCP, i.e., throughput and latency. Moreover, they also had a brief examination of TCP over 5G mmWave in the urban deployment. They tried to test TCP over 5G mmWave networks in an urban deployment and see how applicable it is. However, the analysis does not cover all possible situations that a UE can have inside a city.
Some other aspects of TCP, including RLC buffer size and RTO (Retransmission Time-Out), have been studied in [11]. The authors tried to show the effects of increasing RLC buffer size to 7 MB and decreasing the RTO to 200 ms. The simu- lations’ outcome indicated that the aforementioned numbers could enhance TCP’s functionality over 5G mmWave net- works. Moreover, they strived to measure the compatibility of TCP and 5GmmWave networks in a city. However, they did not indicate the detailed behavior, and some circumstances that a UE can have inside a city are missing.
There are some other investigations of TCP over 5G mmWave networks, including the analysis of TCP perfor- mance in disastrous situations in [7], analyzing of TCP per- formance over 5G mmWave networks in an indoor scenario, i.e., a train station in [12], which its focus is only on the
performance of TCP when deployed in a train station, and link-layer retransmission impacts on the functionality of TCP over 5G networks in [13]. Moreover, designing a new pro- tocol called TCP Ohrid to improve the functionality of the network in [14], studying the effects of having a TCP with a single flow versus multiple flows in [15], and practical measurement of the network in a real 5G network in [16] have been accomplished. However, none of the studies analyzed TCP’s detailed behavior in one of the most popular 3GPP’s scenarios, i.e., urban deployment. 5G networks are going to serve as the prominent telecommunication infrastructure in the coming future, and it is going to cover 65 percent of the world population in 2025 [17]. Most of this population is settled in cities; thus, filling the gap of having a thorough analysis of TCP performance over 5G mmWave networks is inevitable.
In this paper, we focus on the urban deployment to cover the performance of 5G mmWave and the transport layer when deployed inside a city. This analysis can give a thor- ough insight into the behavior of the new cellular networks when exploited inside a city. The primary goal of this elabo- rated analysis is to understand ‘‘how sufficient TCP is when deployed in 5G mmWave networks over an urban scenario’’. To achieve our purpose, we simulated different conditions that a user can have in a city, such as short or long NLoS states, being static or dynamic, moving at a low or high speed, and being close or far from a gNB.
The paper’s main contribution is filling the gap in having a thorough analysis of TCP and 5G mmWave inside a city, which is the most used scenario in cellular networks. More- over, it aims to cover the behavior of the new mobile gener- ation and state-of-the-art TCPs. The comprehensive analysis of the transport layer, how cutting edge TCPs such as CUBIC and BBR (Bottleneck Bandwidth and Round-trip time) react to different circumstances when deployed in 5G networks over a city, and analysis of the modified and newly proposed parameters, i.e., deployment of an edge server vs. the remote one, RLC (Radio Link Control) buffer size effect, deploying different congestion control algorithms, and MSS (Maximum Segment Size) impact, are the novelty of the paper. Further- more, the presented work is the extension of [18] by providing a detailed investigation of the 5G mmWave network over the urban deployment scenario and analyzing its behavior in different circumstances.
The rest of the paper is organized as follows: the funda- mentals of TCP have been introduced in section two, section three incorporates methodology and the simulation details, section four and its subsections include different RLC buffer size impacts on the functionality of TCP, the investigation of the MSS effect, remote server deployment impacts, and finally, section five concludes the paper.
II. FUNDAMENTALS OF TCP AND TCP VARIANTS
The transport layer of the protocol stack exploits TCP for having a reliable end-to-end connection. TCP tries to deliver all of the packets along with preventing the network from
having congestion. There are various TCP variants [2] for different situations. Each TCP can be deployed in different networks based on the needs and necessities.
Four TCPs, including NewReno, CUBIC, HighSpeed, and BBR, have been chosen to be analyzed in this paper based on their popularity and deployment. NewReno is one of the first appeared TCPs and was the base protocol in designing most of the coming ones, CUBIC is the default protocol since Linux 2.6.26, HighSpeed is one of the primary candi- dates of being exploited in high-speed networks, and BBR is a recently cutting edge protocol proposed by Google and deployed in some of its services.
A. TCP NEWRENO
NewReno [19], which is an extension of Reno [20], employs an AIMD (Additive Increase Multiplicative Decrease) in its congestion avoidance mechanism. The main goal of propos- ing NewReno was overcoming the confusion of Reno in dealing with several packet losses in one congestion window. NewReno has served as one of the default congestion control mechanisms in most communication structures [5]. When functioning in the congestion avoidance phase, NewReno increases its cwnd (Congestion Window) by 1/cwnd for each received ACK and halves the cwnd by detecting a packet loss through three duplicate ACKs.
B. TCP CUBIC
TCP CUBIC [21] is the default transport protocol in Linux since Kernel 2.6.26, Android, and iOS operating sys- tems [11], [22]. This protocol tries to adjust the sending rate based on the elapsed time since the last packet loss by using a cubic function. CUBIC’s goal is to detect the time before the last drop and achieve that sending rate in a shorter time. One of the main aims of designing this protocol was reaching the high sending rates by keeping the fairness between different flows.
C. TCP HIGHSPEED
By the emergence of high BDP (Bandwidth-Delay Product) networks, the former TCPs such as NewReno showed defi- cient functionality, and designing a new protocol for these kinds of networks with an aggressive approach in increasing and decreasing the congestion window was an essence. As a result, HighSpeed [23] TCP appeared to overcome the previ- ous protocols’ slow reaction in high-speed networks. When the sending rate is low, i.e., cwnd is small, HighSpeed func- tions similarly to NewReno. However, by exceeding a prede- fined threshold for cwnd, the congestion avoidance approach of HighSpeed changes in order to have proper reactions to different conditions.
D. TCP BBR
TCP BBR was proposed by Google in July 2017 [24]. This protocol tries to measure the available bandwidth in the net- work’s bottleneck to keep the sending rate as much as high by accommodating the cwnd size and the available sending
rate at the bottleneck. Moreover, it strives to obtain the lowest possible latency and keep working close to the minimum available RTT.
III. METHODOLOGY AND THE SIMULATION SCENARIO The study presented in this paper has been evaluated by means of simulation. There exist several known sim- ulators. In this subsection, we motivate the use of the selected one.
LENA [25] is one of the simulating tools for LTE-EPC based networks. It has the capability of evaluating downlink and uplink channels, Radio Resource Management Algo- rithms, Inter-cell Interference Coordination solutions, Load Balancing, Mobility Management, and more. This simulator is an open-source module, and like most well-known network simulators, it is based on ns-3 (Network Simulator) [26], [27].
For simulating the mmWave spectrum, we should use a more sophisticated module called ns3-mmWave [28]. This module includes channel model implementation [29] and supports dual connectivity and handover [30], [31]. By enabling simulation tools for evaluating different aspects of ns3-mmWave networks, such as different channel models and layers, this module is a powerful tool that can be exploited to simulate 5G mmWave networks. Moreover, it has been the default simulation tool in various researches, including [5], [7], [11], [13], [15], [18], which proves its practical function- ality. Based on the mentioned advantages, we have decided to use this module as the simulation tool to analyze TCP’s and 5G behaviors in the urban deployment.
Besides ns3-mmWave, there are two other tools, including a library supported by MATLAB [32], and another one pro- posed by Seoul National University called K-SimNet [33], which is an extension of ns-3 with the capability of supporting 5G NR, 5G core, and multi-RAT protocols. These tools can also evaluate an end-to-end connection in a 5G mmWave network based on the needs and necessities.
In conclusion, for simulating 5G mmWave networks, ns3-mmWave is one of the primary candidates to be exploited, as the majority of the 3GPP features are incorpo- rated in it.
A. SIMULATION SCENARIO
This section aims at explaining how the results and conclu- sions have been drawn and the deployed scenario throughout the simulations.
There have been some analyses of 5G mmWave, and TCP in some scenarios such as high-speed [5], urban deploy- ment [5], [11], but different aspects of the urban deployment were not covered, disastrous situations [7], and an indoor train station [12]. However, none of the researches studied TCP’s applicability over 5G mmWave inside a city. By having a comprehensive analysis of TCP and its parameters, TCP can be tuned for different applications. These applications mainly fall into three categories, including eMBB, mMTC, and URLLC. Applications such as autonomous driving or traffic controllers, which are sensitive to delays, can benefit
from edge server deployment, as the simulations revealed that RTT could be reduced by deploying this feature. In this case, techniques such as edge computing and cloud com- puting can be enablers for low RTT, which leads to lower latencies. Moreover, deploying small buffers can be another choice in order to foster the functionality of latency-sensitive applications as they do not need to transmit large amounts of data.
On the other hand, some applications require sending large amounts of data without the necessity of low latencies, such as UHD (Ultra-High-Definition) videos. In this case, the proposed techniques in the paper, including using large RLC buffers or increasing the MSS can be exploited. Enlarging MSS will challenge the conventional value for MTU (Max- imum Transmission Unit), which is 1500 bytes. As a result, this procedure might be demanding.
For applications such as IoTs (Internet of Things) or devel- oping a smart city, which fall into mMTC, the deployment of the remote servers can be a choice as they do need to transmit small amounts of data without the prerequisite to low latency and large data rates.
To sum up, this paper will open a new horizon and can be a guide in order to tune up TCP’s parameters in order to use the 5G mmWave network to its full potential, especially in the urban deployment. As a result, we proposed a model that includes most of the conditions that a user can have inside a city, explained in detail in the following.
After designing a proper topology, we have conducted extensive simulations and collected the results. We should analyze the behavior of different TCP variants in various situations to figure out the protocols’ exact behavior. As a consequence, numerous simulations have been run in order to draw the results. The final step is having thorough com- parisons between different TCPs in order to shape the TCP’s paradigm in the urban deployment.
For comparing the functionality of different TCP variants, three important KPIs, including throughput, RTT, and cwnd, were chosen to be analyzed. The value for these parameters can reflect how sufficient a protocol is when deployed inside a city. Throughput is an indicator of delivered packets to the node from the server. As a result, it can reveal that to what extent a protocol can utilize the available bandwidth in the network by preventing overusing the available resources and congestion collapse. This KPI can be extremely paramount in use cases such as eMBB. RTT, which is the time from sending a packet to receiving its corresponding acknowl- edgment, is directly correlated to latency. As the value of RTT decreases, we can have low latency in the network. This parameter is highly important for URLLC applications as they are time-sensitive. Congestion window adjustment importance is in sensibly utilizing the resources and pre- venting buffer exhaustion in the network. If it is increased in a blind and drastic way, it will lead to buffer overflows. On the other hand, if it is increased conservatively, it leads to underutilization of the available resources. As a result, a well-designed protocol should adjust the cwnd value by
considering the current conditions in the network. The codes for individual scenarios are available online.1
The studied scenario includes a UE, a gNB, and some obstacles for preventing a proper connection establishment and creating NLoS states. This scenario tries to emulate LoS and NLoS states that a UE can have in the 3GPP’s urban deployment [10]. The UE connects to a gNB work- ing at 28 GHz, 1 GHz bandwidth, which is at the height of 15 meters, connected to a server working in a 1 Gb/s sending rate.
The initial distance between the UE and the gNB is 52 meters. In the beginning phase of the simulation, the user remains static for a second to mime the LoS static state. After- ward, it starts moving at a speed of 1.5 m/s. After 1.5 seconds of walking, it arrives at five trees as obstacles, which are going to impair the connection between the UE and the gNB. These trees have been put to emulate small obstacles. While passing the second tree, the UE stops for about four seconds; thus, both static and dynamic forms of small obstacles could be simulated when all trees are passed. After passing the trees and entering the LoS state, the user turns to the left and continues its walking toward a building where NLoS states created by a big obstacle is going to be emulated. The user also stops behind this building for four seconds in order to have static and dynamic NLoS created by a big obstacle.
When the building is passed, the user continues walking in the LoS mode for seconds, and then it gets in a car to simulate having a user at the driving speed. The car’s speed is 108 km/h, and it gets far from the gNB to evaluate the effect of the distance between a UE and a gNB.
Eventually, the user stops at a distance of 716 meters from the gNB after driving for fifteen seconds. These con- ditions can help to emulate static and dynamic LoS, static and dynamic NLoS behind a small or a big obstacle, moving at the speed of walking or driving, and the impact of the distance between a UE and a gNB. It is worth saying that the obstacles were created by putting some boxes and setting their boundaries in a way that can mime small and big hurdles. Moreover, Buildings Obstacle Propagation Loss Model has been used as the path loss model. Figure 1 shows the deployed scenario in the simulations.
In order to see the effects of the congestion, bottlenecks, and environmental impacts, the scenario has been simulated under four different PERs (Packet Error Rates), including
no error rate, 10−7, 10−8, and 10−9. These numbers mime
empty, heavy, moderate, and light packet drop possibilities in
networks, resulting from various conditions such as existing noise or environmental effects. The aforementioned PERs have been distributed through the simulations and can happen in LoS or NLoS states. Table 1 shows the default exploited parameters in the simulations.
The reason for choosing 20 MB RCL buffer size in the default scenario is to mime unlimited buffer in order to ana- lyze the behavior of 5G mmWave in the different conditions.
FIGURE 1. The deployed scenario in the simulations.
TABLE 1. Deployed parameters in the simulations.
We suggest that a large buffer size can give a clearer insight into the 5G network functionality and prevent overflows in NLoS states. On the other hand, a quick buffer overflow in NLoS states can occur for small buffer sizes and makes it difficult to see 5G networks’ detailed behavior. In the first step, we analyzed the effect of the RCL buffer size on the principal KPIs, i.e., throughput, RTT, cwnd adjustment. In this case, unlimited, large, and small sizes have been tested. Consequently, firstly, we analyze the presented scenario with the unlimited RCL buffer size for different PERs in order to see the behavior of 5G mmWave networks. Then, to see the impacts of the RCL, we will analyze two distinct sizes, including BDP and 10% BDP. This helps to see how vari- ous TCPs respond to different RLC buffer sizes. Afterward, the effect of the MSS and datagram size is investigated, and both 1400 bytes and 14000 bytes MSS with their corre- sponding datagrams are tested in order to figure out TCP’s performance under different MSS sizes. The reason is to see that how increasing the datagram size can assist TCP in ramping up quickly and utilizing 5G potential. Finally,
we study the effects of placing an edger server and how TCP can benefit from the shorter control loop. This can aid in comparing TCP’s functionality in edge, and remote server deployments and will reveal to what extent it is inescapable to deploy techniques such as edge computing. These steps can assist us in having a clear insight from TCP performance in the urban deployment and aid in tuning its parameters.
IV. RESULTS
Based on the ns-3 mmWave module [28] advantages pre- sented in Section three, it was chosen as the simulating tool. In this section, the parameters are the default ones without any changes.
Figure 2 shows the average throughput that individual TCPs can reach. This figure indicates that without packet losses and in the presence of pure channels, loss-based TCPs have similar functionalities by reaching the same values. The reason is the high value for the slow-start threshold, enabling the window scale option, and the large value for the RCL buffer size. During large PER, the BBR impairment is because of a drastic rise in the number of packet drops, which forces the protocol to assume a bandwidth decline in the bottleneck.
FIGURE 2. Average throughput for different TCPs.
Between these loss-based TCPs, only HighSpeed can retain its high functionality when having packet drops. How- ever, under large PER, this protocol also loses its function- ality. On the other hand, BBR can keep its high throughput throughout various PERs because it is not a loss-based TCP and strives to work by obtaining the bottleneck bandwidth value and adjusting the sending rate based on it. The UDP saturated value shown by a red dashed line in the figure equals 824.825 Mb/s and is the maximum achievable throughput at the transport level that we take as a reference level.
From the RTT point of view, by increasing the packet drops in the network, loss-based TCPs put less traffic on the RCL buffer, so the value of RTT decreases.
However, BBR can keep sending more packets to the net- work with a high value for RTT, as shown in Figure 3.
FIGURE 3. Average RTT for different TCPs.
FIGURE 4. Throughput comparison of HighSpeed and BBR, PER=0.
This figure reveals that the best performance between these four TCPs is for BBR by having acceptable throughput and averaged RTT. However, this protocol cannot exploit the network’s full potential from a throughput point of view. We should notice that by having low PERs, HighSpeed is the suitable protocol to be deployed. For example, when the PER is moderate, HighSpeed and BBR have a slight difference in their throughput. However, a low value for RTT can be achieved when HighSpeed is deployed.
For having a detailed analysis of the results, we can look at the values of instantaneous throughput and RTT in-depth. We have chosen HighSpeed as the best candidate for the loss-based TCPs to be compared with BBR. The gray areas in all of the figures in this paper show the static small obstacle situation, and the cyan one is for the big obstacle.
As it was said, all hurdles in the deployment scenario can attenuate the power of the signal and reduce the avail- able bandwidth. For more clarity, we can look at the SINR (Signal-to-Interference-Plus-Noise Ratio) values in different
FIGURE 5. SINR fluctuation throughout the simulations.
situations to see why both TCPs experienced throughput degradation in NLoS states.
Figure 5 indicates that obstacles on the path of communi- cation could impair the connection between a UE and a gNB. The degraded SINRs in NLoS states are the primary issue of having unstable communication in 5G mmWave networks and can be misleading for TCP. As a result, by increasing the number of obstacles, TCP’s functionality will be impaired drastically.
It is true that there is not a thorough analysis of TCP over 5G mmWave networks in the urban deployment, however, we can compare other aspects of our simulations to the avail- able researches.
As a result, we can compare the values of SINR in Figure 5 and in [7], which reveals some similarities. In the former one, the building and trees act as blockers, and in the latter one, which analyzed TCP’s behavior in a disastrous situation, collapsed buildings and trees acted as hurdles in the way of communication. As a result, our conclusion in determining NLoS states when the user is behind an obstacle is correct.
By looking at Figure 6, which shows the throughputs, it can be seen that by appearing packet losses along with the NLoS states in the network, the behavior of HighSpeed and BBR changes. HighSpeed can have quick reactions to different conditions and has a better overall performance. However, BBR assumes that the bottleneck bandwidth is low, and it cannot increase the estimated bandwidth, so it enters the drain phase to empty the queues.
This phase can be seen in the figure when the throughput degrades drastically.
After that, the sharp increments for BBR is because of the probe-bandwidth phase, where BBR strives to recover by sending at the bottleneck bandwidth. This immune mech- anism to losses helps BBR to have better functionality as the number of packet drops increases. Figure 7 indicates the throughput comparison for HighSpeed and BBR when having a moderate PER.
FIGURE 6. Throughput comparison of HighSpeed and BBR, PER=10−9.
FIGURE 7. Throughput comparison of HighSpeed and BBR, PER=10−8.
As shown in the figure, BBR can recover faster and reach the highest possible sending rate without considering the con- secutive drops by knowing the bottleneck bandwidth. How- ever, HighSpeed can suffer from several drops and encounters drastic throughput reductions.
These different functionalities can be more evident when the number of drops is very high. Figure 8 shows the through- put comparison for the two protocols when the value of PER is high. HighSpeed, like other loss-based TCPs, suffers from both NLoS adverse effects and packet losses in this scenario, however, BBR functions way better.
The only problem for BBR is the misleading impacts of NLoS states in estimating the correct bottleneck bandwidth. From the RTT point of view, the two protocols have close functionalities. However, when the UE is moving fast and the distance between the user and the gNB increase, BBR shows some deficiencies. Moreover, when the value of PER is large,
BBR sends way more packets compared to HighSpeed, which can increase the value of RTT.
For emphasizing the results, we can compare the obtained values for throughput with the results in [11], [12]. In [11],
FIGURE 8. Throughput comparison of HighSpeed and BBRs, PER=10−7.
which is indicating throughput for CUBIC and some other variants, the same behavior for TCP can be seen as in our simulations. Both HighSpeed in our simulations and CUBIC in [11] show that obstacles can block communication channels and impair the functionality of TCP. Moreover, the obtained results in [12] accommodate our conclusion, i.e., as the number of obstacles increases, TCP confusion gets more intense, and adjusting the cwnd can be difficult.
Furthermore, practical measurements in [16] prove the conclusion in TCP’s throughput degradation over 5G net- works, as it raises the question of the sufficiency of the transport layer over 5G mmWave networks.
Figure 9 shows the RTT values when there are no packet losses in the network. The figure reveals that if we omit the part that the UE is in the car, BBR can function in lower RTTs, especially in NLoS states, by knowing the bottleneck bandwidth and preventing sending extra packets. However, in LoS states, the protocols can reach similar values.
By having a small number of packet drops in the network, except for some minor reductions after the drops, the RTT
FIGURE 9. RTT comparison of HighSpeed and BBR, PER=0.
values do not experience considerable changes, as seen in Figure 10.
FIGURE 10. RTT comparison of HighSpeed and BBR, PER=10−9.
This reduction can be more intense when a loss-based protocol detects a loss in NLoS state and decreases its sending rate. The reason is that buffers are filled at high paces in NLoS states, and reducing the sending rate can drain them and lower the enqueued packets.
Figure 11 shows that more packet losses force drastic sending rate reductions to HighSpeed; thus, it decreases the enqueued packets, which leads to RTT reduction. The immense difference is in the NLoS states, where BBR can function at high sending rates and quickly fill the buffer.
FIGURE 11. RTT comparison of HighSpeed and BBR, PER=10−8.
By increasing the PER to a large number, the difference becomes even higher. Figure 12 shows that HighSpeed can lower RTT values, which is at the cost of throughput. Gener- ally, cwnd size reduction, which leads to lower throughputs, can reduce the value of RTT.
As a result, a trade-off should be kept between the values of throughput and RTT.
FIGURE 12. RTT comparison of HighSpeed and BBR, PER=10−7.
The detailed presented analysis can ease the way of justify- ing TCP behavior in the coming sections as they are going to show the impacts of different parameters on the performance of TCP.
A. IMPACT OF THE RLC BUFFER SIZE
For analyzing the impact of RCL buffer size on TCP’s behav- ior, we have decided to deploy two values, BDP and 10% of BDP. By exploiting these values, the effects of the large and small buffer can be investigated on TCP’s behavior over 5G mmWave networks. This can be beneficial to find out which RLC buffer size is suitable for various use cases. Because having an appropriate trade-off between the throughput and latency is highly depends on the value of RCL buffer size.
Having a server functioning at 1 Gb/s through 1 GHz bandwidth and minimum latency of 20 ms leads to a 2.5 MB RLC buffer size. As a result, 10% BDP will equal 0.25 MB.
1) DEPLOYING 100% BDP
This section sees various TCPs’ reactions when the RCL buffer size is 2.5 MB, i.e., 100% BDP. Generally, When the RLC buffer size is reduced to 100% BDP from the unlimited value, all TCPs experience RTT improvements at the cost of throughput degradation. However, based on the congestion control mechanism, these reactions can be different.
Between the four tested TCPs, BBR experienced consider- able improvements in its latency value at the cost of minor degradations in its throughput. Moreover, because BBR is almost immune to packet drops, as the number of packet losses increases in the network, it does not lose its function- ality in terms of throughput, and it is the only TCP that could function close to the minimum RTT in all conditions.
Between the three loss-based TCPs, CUBIC benefits from 100% BDP when there are no packet losses in the network as it can achieve the highest throughput with a small difference to HighSpeed. Moreover, both TCPs experienced a minor reduction in their throughputs compared to the unlimited RLC buffer size scenario.
However, CUBIC loses its superiority to HighSpeed when packet losses appear in the network. In contrast to CUBIC, HighSpeed can retain its functionality when the PER value is small. Nevertheless, all three loss-based TCP lose their functionalities when the value of PER rises. Figure 13 indi- cates the average throughput values for different TCPs. The red dashed line is the value of saturated UDP, which equals
810.55 Mb/s.
FIGURE 13. Average throughput for different TCPs, 100% BDP.
As shown in Figure 14, BBR can retain its low RTT value in different packet loss probabilities. It means that by increasing PER value in the network, BBR functionality is not impaired in terms of latency. On the other hand, when the PER is low, loss-based TCPs are not able to prevent buffer overflow and lead to higher latencies. The reason is that they are not able to detect the correct situations in the networks and distinguish each one from the other. However, as PER increases, the latency is reduced at the cost of throughput. This conclusion shows that attaining optimal throughput and latency in loss-based TCPs is challenging in 5G mmWave networks.
( = )In NLoS states, sending numerous packets can fill the buffers and create overflow occurrences. As an example, we can look at HighSpeed throughput to see how this loss-based protocol functions in this situation. Figure 15 shows the throughput of HighSpeed when PER 0.
It can be seen in the figure that NLoS states can impair the functionality of HighSpeed, especially when there are prolonged ones. These failures can be severe when the UE stops behind an obstacle, such as the figure’s cyan area, because the RTO can be triggered, and TCP initializes its sending rate.
This initializing process can be more evident if we look at the congestion window adjustment of a TCP.
Figure 16 shows the cwnd adjustment for HighSpeed. For more clarity and to see how HighSpeed controls the sending rate in detail, we can look at the figure after the first RTO initializing, as seen in Figure 17.
FIGURE 14. Average RTT for different TCPs, 100% BDP.
FIGURE 15. Throughput of HighSpeed, PER=0.
FIGURE 16. HighSpeed cwnd adjustment mechanism.
Figure 17 indicates that buffer overflow and RTO trigger- ing possibility increase when the user is behind the trees or the building. Buffer overflows can lead to packet drops and
FIGURE 17. HighSpeed reaction after the first initialization.
FIGURE 18. RTT comparison for HighSpeed and BBR, PER=0.
force TCP to initialize its sending rate, which takes some time to ramp up to the full potential of the mmWave high bandwidth. The main cause for this behavior is due to the intermittent characteristic of mmWave frequency ranges as emphasized in [15], which its results indicate that when 5G and LTE co-exist, multipath TCP selects the LTE channels to transmit its data. The reason is that it finds LTE channels more stable and assumes 5G links as congested ones due to their discontinuous nature.
Besides throughput, NLoS States can degrade the value of RTT. Figure 18 indicates RTT values for HighSpeed as a loss- based TCP and BBR as a model-based TCP.
Both protocols suffer from NLoS states, especially when the UE stays static. However, BBR, because of its congestion control mechanism that tries to work close to the minimum RTT, can attain better values.
To sum up, as the PER decreases, CUBIC can attain higher throughput. On the other hand, for small and moderate PERs, HighSpeed is better in terms of throughput. In contrast to
FIGURE 19. Average throughput for different TCPs, 10% BDP.
loss-based TCPs, BBR can attain a stable functionality in all situations. Moreover, it works close to the minimum latency, no matter what the loss probability is. However, this protocol cannot reach the saturated value of UDP. If latency is not important such as in the eMBB use case, HighSpeed can be a suitable protocol to be deployed. However, if latency is essential along with moderate throughput, BBR is the ideal protocol to be deployed.
2) DEPLOYING 10% BDP
In order to analyze how different congestion control mech- anisms react to small RLC buffer size, this section aims to analyze their behavior when the value of the RLC buffer size is 10% of BDP, i.e., 0.25 MB.
As seen in Figure 19, reducing RLC buffer size impairs the loss-based TCPs dramatically. The main reason for this reduction is the increased number of packet drops because of the buffer’s small size, which forces overflows, especially during NLoS states. Between the three loss-based TCPs, HighSpeed can have the largest throughput, mostly around 200 Mb/s. However, this value is far from the saturated UDP value, which is 807.5 Mb/s, and is shown by a red dashed line in the figure. HighSpeed TCP strives to keep a high sending rate in the network, but this aggressiveness creates more packet losses. Generally, if a TCP has an aggressive congestion control mechanism, it leads to a high number of RTO triggering under a large number of packet drops, especially when the buffer size is small; thus, the congestion window control fluctuation will rise.
These fluctuations are apparent in Figure 20, which shows the cwnd evolution for HighSpeed TCP.
This flaw can be reflected in the attained throughput by the protocol, as seen in Figure 21. In contrast to the time that TCP could cope with the reduced bandwidth in NLoS states because of large buffer deployment, Figure 21 indicates that having obstacles when the buffer size is small can drastically impair the protocol’s functionality. Unlike loss-based TCPs,
FIGURE 20. Congestion control evolution for HighSpeed, PER=0.
FIGURE 21. Throughput of HighSpeed, PER=0.
BBR can reach high throughputs like the previous scenarios. The estimation of the available bottleneck bandwidth in BBR helps the protocol to recover faster after failures.
Figure 22 reveals that in all PERs, BBR has the low- est latency. It means that BBR can cope with the intermit- tent characteristic of mmWave channels and achieve high throughputs throughout low latencies.
Although all loss-based TCPs’ RTTs are indeed close to the minimum value, the throughputs are reasonably far from the saturated UDP, and the low RTT values for loss-based TCPs are not worthy enough as they cannot reach high throughputs for applications that demand high throughput.
To sum up, loss-based TCPs suffer from a small RLC buffer size as it is filled quickly in NLoS states and causes packet losses and RTO triggering. This drawback can be intense in protocols that are not designed to work in high-speed networks such as NewReno. The only protocol that could perform close to the minimum RTT with a reasonable value for the throughput in all situations is BBR.
FIGURE 22. Average RTT for different TCPs, 10% BDP.
Moreover, from the use case point of view, the results showed that deploying large buffers can be beneficial for eMBB. When a 100% BDP is used, all TCPs can attain larger throughputs, which is the principal aim of eMBB. On the other hand, for time-sensitive applications, i.e., URLLC, which try to have a low latency along with low throughputs such as IoT devices, exploiting smaller buffers can be advan- tageous. The results revealed that when a 10% BDP is used, all TCPs can enhance their latencies at the throughput cost, relevant for URLLC use cases.
In real-world exploitation, the RCL buffer size is tunable and can be adjusted based on the needs and necessities. As a result, the size can be chosen by considering the use case and the defined targets.
B. INCREASING THE MAXIMUM SEGMENT SIZE
By moving to 5G networks and deploying the wide avail- able bandwidth provided in mmWave frequencies, MSS and MTU (Maximum Transmission Unit) sizes are relevant to improve the performance. MSS is the largest packet that a TCP receiver is allowed to get, and MTU is the same but for the network layer. As the mmWave offers a large sending data rate, it is worth testing to send larger packets in the network. As a result, we propose to increase the MSS size from 1400 bytes to 14000 bytes and MTU from 1500 bytes to 15000 bytes to analyze how TCPs react to these changes. The RLC buffer size was set to 2.5 MB to fulfill the need for BDP buffer size in a network.
Figure 23 shows that loss-based TCPs can get a consid- erable benefit from a larger MSS size, and in some cases, the value of throughput is larger than the unlimited scenario. The reason is that when they detect a loss in a network and reduces their sending rate, it takes some time to ramp up to the possible sending rate, and this can even be worse when consecutive packet drops occur during a congested situation. However, by increasing the MSS size, these protocols can overcome this flaw. All three protocols operate a little far
FIGURE 23. Average throughput for different TCPs, MSS =14000 bytes.
from the saturate UDP value, which equals 839.38 Mb/s. Between the loss-based TCPs, CUBIC can get the highest throughput when the packet loss probability is zero. However, HighSpeed can work in high performance throughout all PERs.
In contrast, NewReno can get adverse effects when the PER increases, and its throughput is impaired dramatically. Like the previous scenarios, BBR can have stable function- ality throughout all scenarios. However, most of the time, its performance is weaker than loss-based ones and experiences a degradation compared to the 100% BDP scenario. The reason is the repetitive overflows that BBR can experience in these situations, which force the protocol to assume that the bottleneck bandwidth is low. The important aspect of BBR is its stable functionality throughout all circumstances.
From the RTT point of view, TCP experiences an increment compared to the 1400 byte scenario. However, the achieved high throughputs for loss-based TCPs in all conditions can compensate for this increment, which is shown in Figure 24. Figure 23 and Figure 24 reveal that loss-based TCPs can attain high throughput throughout acceptable RTT when MSS is increased to 14000 bytes. In contrast, BBR cannot benefit from a larger MSS size, and it is not able to perform close to the minimum available latency like the previous scenarios.
On the other side, loss-based TCPs could decrease their latency close to BBR and even lower than BBR in some cases, and considering the higher throughput they could achieve,
they have better performances compared to BBR. For exam- ple, when the PER equals 10−8, which indicates moderate packet drops in the network, the achieved throughput for
HighSpeed is roughly 35% more than BBR among with a lower RTT.
To sum up, all studied loss-based TCPs can benefit from deploying larger MSS sizes. This conclusion is perfectly in line with the results obtained in [5], which investigated the behavior of TCP in the high-speed scenario. Both conclusions indicate that loss-based TCPs performances are improved when MSS is increased.
FIGURE 24. Average RTT for different TCPs, MSS=14000 bytes.
The observed advantage of deploying larger MSS con- cludes that applications and protocol stacks that use TCP over 5G networks must adapt the MSS and MTU sizes. The simulation results showed that by increasing MSS, High- Speed TCP is an appropriate candidate to be deployed in 5G mmWave networks, especially in the eMBB use case, where the emphasis is on attaining high throughput. This protocol can perform properly in all situations.
In real-world exploitation, increasing MSS and MTU size can be a challenging task as their default values have been deployed for a long time, and for adopting new values, some devices such as intermediate routers should exploit new rules and regulations. However, based on the attained enhanced results, this step seems to be taken in the future.
C. REMOTE SERVER DEPLOYMENT IMPACT
This section investigates the impact of a remote server deployment on 5G urban scenarios where TCP is used as the transport protocol. To emulate a remote server, we increased the latency between the gNB and the server from 10 ms to 40 ms, which helps us to analyze different TCP variants’ performance. By increasing the latency, the minimum RTT reached 80 ms; thus, for having 100% BDP, we increased the RLC buffer size to 8 MB.
Figure 25 shows that all TCPs are impaired in the case of throughput except BBR when PER equals zero. However, when PER increases, even BBR’s performance is degraded because of the longer response times. BBR estimates the available bottleneck bandwidth by calculating the number of delivered packets to a receiver in particular periods. This procedure can be impaired when the response time increases due to the remote server deployment. Loss-based TCPs rely on acknowledgments to adjust the sending rate, and when a remote server deployment increases the latency, it can harm their throughput because it takes longer to acknowl- edge a packet. With PER equals to zero, loss-based TCPs could achieve the same throughput. However, as the PER increases, HighSpeed can get higher throughput. It becomes
FIGURE 25. Average throughput for different TCPs during a remote server deployment.
FIGURE 26. Average RTT for different TCPs during a remote server deployment.
more interesting when we know that HighSpeed attains this throughput by lower RTTs than other loss-based TCPs, as shown in Figure 26. This value can even be lower than BBR in some cases.
TCP can benefit from the edge server deployment in terms of throughput and latency. As a result, in 5G networks, special attention should be paid to exploiting techniques such as cloud servers and CDN (Content Delivery Networks).
In real-world exploitation, emerging and developing novel services and techniques such as edge computing, cloud servers, and CDN ease the way of having edge servers and alleviate the adverse impacts of remote server deployments. As the response time will decrease by using these techniques, TCP can benefit from the shorter control loop.
To sum up, when the network is exploiting large buffers, HighSpeed can attain high throughputs at the cost of RTT. This superiority can be impaired as the size of the buffer is reduced, such as in the 10% BDP scenario. However, RTT can benefit from smaller buffer sizes, which are suitable for time-sensitive applications. Among the tested TCPs, BBR
can retain its functionality during various buffer sizes, and it can achieve low RTTs but cannot operate close to the UDP saturated value. Moreover, increasing the MSS size can satisfy loss-based TCPs in a way that assists them to come by high throughputs at the cost of RTT. This feature also affects BBR but in an adverse way. Finally, all TCPs can benefit from edge server deployment as it reduces the acknowledging time.
V. CONCLUSION
5G cellular communication is a promising telecommunica- tion technology that aims to fulfill the coming demands in high data rates and low latencies. Deploying the mmWave frequency band is an inseparable part of 5G networks due to its high potential in providing massive data rates. However, frequency channels crated by mmWave suffer from intermit- tent nature that can impair the functionality of the transport layer. In this paper, we had a comprehensive analysis of TCP over 5G mmWave networks in one of the 3GPP’s popular scenarios called urban deployment. Moreover, the impacts of different parameters on the value of throughput and latency were analyzed throughout extensive simulations, and the principal results are brought in the following:
· All studied TCPs can benefit from a larger RLC buffer size in terms of throughput at the cost of latency. Taking into account uses cases, eMBB can benefit from deploy- ing a larger RLC buffer, but URLLC can benefit from deploying a smaller RLC buffer.
· BBR can have stable performance throughout most of the circumstances.
· BBR can usually function close to the minimum latency so that it can be the right choice for the URLLC use case.
· BBR can benefit from using smaller buffers in contrast to loss-based TCPs.
· Studied Loss-based TCPs benefit from increasing MSS size, and they experience superiorities to BBR. In con- trast to loss-based TCPs, BBR cannot get benefit from increased MSS.
· All studied TCPs suffer from a remote server deploy- ment.
· In order to fulfill all needs to some level, deploying HighSpeed TCP by increased MSS along with an edge server deployment can be an appropriate choice as it can perform adequately in all conditions.
The conclusions show that to utilize 5G mmWave poten- tial fully, some techniques such as edge servers need more attention and a trade-off between extensive use of gNBs to expand the LoS coverage, and the cost should be maintained. Moreover, some aspects of traditional networks such as MSS and MTU should be modified in order to adapt to the new cellular networks.
