This paper has been accepted for publication in the IEEE Communication Magazine Will TCP work in mmWave 5G Cellular Networks? Menglei Zhangy, Michele Polese∗, Marco Mezzavillay, Jing Zhu, Sundeep Rangany, Shivendra Panwary, Michele Zorzi∗ yNYU Wireless, New York University, NY, USA - e-mail: fmenglei, mezzavilla, srangan, [email protected] ∗Department of Information Engineering, University of Padova, Italy - e-mail: fpolesemi, [email protected] Intel Corporation - e-mail: [email protected] Abstract—The vast available spectrum in the millimeter wave goodput and a very low utilization of the resources at mmWave (mmWave) bands offers the possibility of multi-Gbps data rates frequencies, or, in the presence of link-layer retransmissions, for fifth generation (5G) cellular networks. However, mmWave high goodput at the price of high latency. Moreover, in [4] it capacity can be highly intermittent due to the vulnerability of mmWave signals to blockages and delays in directional searching. is shown that the bufferbloat phenomenon (i.e., the increase Such highly variable links present unique challenges for adaptive in latency that is caused by excessive buffering) emerges as a control mechanisms in transport layer protocols and end-to-end consequence of the presence of large buffers in the network. applications. This paper considers the fundamental question of Our goal is to answer the question: Will TCP work in whether TCP – the most widely used transport protocol – will work in mmWave cellular systems. The paper provides a com- mmWave 5G cellular networks? To this aim, we compare the prehensive simulation study of TCP considering various factors performance of different TCP congestion control algorithms such as the congestion control algorithm, including the recently over simulated 5G end-to-end mmWave networks consider- proposed TCP BBR, edge vs. remote servers, handover and multi- ing (1) a high speed train and (2) an urban macro 3GPP connectivity, TCP packet size and 3GPP-stack parameters. We deployment, as further described in Sec. II. Our detailed sim- show that the performance of TCP on mmWave links is highly dependent on different combinations of these parameters, and ulation study demonstrates that the performance of TCP over identify the open challenges in this area. mmWave depends critically on several aspects of the network: Index Terms—TCP, Congestion Control, BBR, mmWave, 5G, Edge vs. Remote Server: Cellular, Blockage, ns-3 1) By comparing the end-to-end performance at varying server’s location, we show that for a shorter control loop, i.e., when the server is placed I. INTRODUCTION at the cellular network edge, TCP can react faster to link impairments. End-to-end connectivity over the internet largely relies on 2) Handover and Multi-Connectivity: Due to unreliability transport protocols that operate above the network layer. of individual mmWave links, dense deployments of small The most widely used transport protocol is the Transmission cells with fast handover protocols are critical in maintain- Control Protocol (TCP), designed in the 1980s [1] to offer ing stable connections and avoiding TCP timeouts. reliable packet delivery and sending rate control to prevent 3) CC Algorithms: With remote servers, we observe higher congestion in the network. Reliability is accomplished with performance variations across different congestion con- receiver’s acknowledgments (ACKs) fed back to the sender, trol algorithms, while the difference is almost negligible which retransmits packets if needed, while rate control is with edge servers. Overall, BBR outperforms loss-based achieved by dynamically adjusting the congestion window, TCP in terms of both rate and latency. i.e., the maximum amount of data that the sender can transmit 4) TCP Packet Size: We quantitatively compare the benefits without receiving ACKs. Several Congestion Control (CC) al- of transmitting larger TCP packets in Long-Term Evo- gorithms have been proposed in order to improve the goodput lution (LTE) versus mmWave networks, and show that, (defined as the application layer throughput) and latency of given the fluctuating Gbps data rates offered at mmWave TCP over different types of networks [2]. arXiv:1806.05783v2 [cs.NI] 6 Oct 2018 frequencies, a larger packet size provides a faster growth However, the next generation of cellular networks will of the congestion window and higher achievable rate. present new challenges for TCP1, specifically related to 5) Radio Link Control (RLC) Buffer Size: We analyze mmWave links in the radio access network, which exhibit TCP performance over small and large buffers. While an erratic propagation behavior. This technology is seen as the TCP goodput degradation caused by buffer overflow a promising enabler for the 5G targets of multi-gigabit/s data in undersized buffers is difficult to mitigate, the problem rates and ultra-low latency [3], but the end-to-end performance of bufferbloating, i.e., large buffer occupancy leading to perceived by the user will eventually depend on the interaction delays, can be approached by appropriately designing with transport protocols such as TCP. Some recent studies [4], cross-layer algorithms [6]. [5] have highlighted that the extreme variability of the signal quality over mmWave links yields either a degraded TCP The rest of the article is organized as follows. We first describe the scenarios of interest in Sec. II. Then, we list the 1In this work, we focus on TCP since it is the dominant transport protocol main features of the CC algorithms considered in this study in use today. One possible avenue for future work is to consider the UDP protocol, that, however, shifts the burden of retransmissions and flow control in Sec. III. We report the main results and observations in to a higher layer, introducing similar problems as those related to TCP. Sec. IV, and draw our conclusions in Sec. V. LTE Edge Server Remote Server LTE HIGH SPEED URBAN Indoor DEPLOYMENT DEPLOYMENT PGW NLOS mmWave mmWave LOS 35 m mmWave V = 30 m/s mmWave 5 m 6 m 5 m 580 m 580 m 572 m Cell 3 40 Cell 1 Cell 2 Cell 4 mmWave 20 SINR [dB] 0 25 m 0 5 10 15 20 25 30 35 40 45 50 55 60 Time [s] Figure 7: SINR of high speed deploymentFigure 1: High speed and urban deployment scenarios II. 5G DEPLOYMENT SCENARIOS SINR, four are in Non-Line of Sight (NLOS) and the last two are inside a building, so that the received power is additionally In order to assess how TCP will perform in mmWave attenuated by the building penetration loss. cellular networks, we consider two of the most challenging For both scenarios we consider two deployments of the TCP scenarios among those specified by the 3GPP in [7], i.e., a server which acts as the endpoint of the connection. The first high speed train and a dense urban scenario, represented in is a traditional setup in which the server is hosted in a remote Fig. 1. They were studied using the ns–3-based mmWave end- data center, with a minimum Round Trip Time (RTT) in the to-end simulation framework described in [8], which models order of 40 ms, accounting for the latencies of both the core radio access, the core network, and the 3GPP channel for the network and the public internet. The second is a Mobile Edge mmWave band with spatial correlation in mobility scenarios. Cloud (MEC) scenario [10], in which the server is located Moreover, the protocol stack simulated by [8] also features close to the gNBs with smaller latency (of the order of 4 ms). retransmissions at both the MAC layer, with Hybrid Auto- matic Repeat reQuest (HARQ), and the RLC layer, using the III. TCP CONGESTION CONTROL PROTOCOLS acknowledged mode option. In this section, we will describe the congestion control High speed scenario: In this scenario, shown on the left protocols and the TCP performance enhancement techniques side of Fig. 1, we test the performance of TCP over a channel considered in this paper. that varies frequently in time and under realistic mobility conditions. Multiple Next Generation Node Bases (gNBs) A. TCP Congestion Control Algorithms provide coverage to the railway, which is mostly Line of Sight We study four most commonly used CC algorithms. (LOS): even if the current gNB is blocked by obstacles placed TCP NewReno has been the default algorithm for the between gNBs 2 and 3, the User Equipment (UE) can quickly majority of communication systems. In the congestion avoid- perform a handover to another LOS gNB. The gNBs are at a ance phase, the congestion window cwnd is updated after the height of 35 meters, with an intersite distance of 580 meters. reception of every ACK. The update is based on the Additive The train moves at a speed of 108 km/h, and, as a result, the Increase Multiplicative Decrease (AIMD) design: cwnd is channel experienced by the UE varies very quickly because increased by summing a term α=cwnd for each received ACK, of severe fading and the Doppler effect, and, on a longer time and divided by a factor β for each packet loss. For NewReno scale, due to obstacles, as shown in the Signal to Interference these parameters are fixed to α = 1 and β = 2. plus Noise Ratio (SINR) plot of Fig. 1. We use the channel HighSpeed TCP is designed for high Bandwidth-Delay tracking and mobility scheme described in [9], which features Product (BDP) networks, in which NewReno may exhibit fast and locally coordinated handovers for devices that are a very slow growth of the congestion window. HighSpeed dual-connected to a mmWave gNB and a sub-6 GHz gNB behaves the same as NewReno when the congestion window (e.g., an LTE base station). is small, but when it exceeds a predefined threshold the Dense urban scenario: In this deployment, shown on the parameters α, β become functions of the congestion window, right side of Fig.