Queue size comparison for standard transmission control protocol variants over high-speed traffics in long term evolution advanced ( LTE-A ) network

The employment of the existing protocols such as Transmission Control Protocol (TCP) cannot achieve the requirements of high-speed networks such as long term evolution advanced (LTE-A) due to the large-bandwidth and low-latency links used in this network. LTE-A network is the continuation of 3GPPLTE (3GPP: 3rd Generation Partnership Project) and it is targeted to advanced development of the requirements of LTE in terms of throughput and coverage. Then, LTE-A is not new as a radio access technology, but it is an evolution of LTE to enhance the performance. Therefore, it is necessary to enhance the TCP variants such as improving the congestion control performance over LTE-A to make these variants fulfills the needs of the huge data which transferred over the secured links. This article offered comparative evaluation and estimation of the queue size performed by different TCP source variants over traffic model of LTE-A system using the Network Simulator 2 (NS-2).The queue size measurement proved that TCP Vegas performed better than TCP Tahoe and TCP Reno that are used in the simulation scenario.


INTRODUCTION
3GPP have prepared the official suggestion to the proposed new International Telecommunication Union (ITU) systems, represented by LTE with Release 10 and beyond to be the appraised and the candidate toward IMT-Advanced (IMT: International Mobile Telecommunications).After attaining the requirements, the main object to bring LTE to the line call of IMT-Advanced is that IMT systems must be candidates for coming spectrum bands that are still to be acknowledged (Kottkamp, 2010) (Kiiski, 2010).LTE-A is applying various bands of the spectrum which are already valid in LTE along with the future of bands of IMT-Advanced.
More developments of the spectral efficacy in downlink and uplink are embattled, specifically if users serve as an edge of the cell.In addition, LTE-A aims quicker exchanging between the resource of radio states and between additional enhancements of the latency.All at once, the bit cost must be decreased (Stencel et al., 2010).IMT-Advanced represents the next generation in systems of wireless communications, which aim to accomplish other main advances of the current thirdgeneration systems, by reaching to uplink (UL) rate of 500 Mbps and to 1 Gbps in the downlink (DL) (Nam et al., 2010).The contributions approved by this research are providing a new comparison for the performance evaluation in queue size for some standard TCP source variants.This will help the network developers to modify the current TCPs to run efficiently over large bandwidth and low latency network such as the new generation networks LTE and LTE-A.
The methodology of this research is based on using three TCP variants, Vegas, Reno, and Tahoe over a traffic model of LTE-A network and then measuring the queue size in packets when a loss packet injected in a simulation scenario using NS-2 simulator.The next section includes the architecture of LTE and LTE-A network while the other sections are including the queue estimation formula and then the results and discussion and finally the conclusion section with the recommendation to the future work.

Architecture of LTE-A network
3GPP identified in Release 8 the requirements, features, and requirements of the architecture of Evolved Packet Core (EPC) which that serving as a base for the next-generation systems.This identification specified two main work objects, called LTE and System Architecture Evolution (SAE) that leading to the description of the Evolved Packet Core (EPC), Evolved Universal Terrestrial Radio Access Network (E-UTRAN), and Evolved Universal Terrestrial Radio Access (E-UTRA).Figure 1 illustrates the architecture of LTE-A networks based on EPC and E-UTRAN.Each of these parts corresponded respectively to the network core, system air interface, and the radio access network.
EPC is responsible to provide an IP connection between an external packet data network by using E-UTRAN and the User Equipment (UE).In the environment of 4G systems, the radio access network and the air interface are actually improving, while the architecture of the core network (that is, EPC) is not suffering large modifications from the previous systematized architecture of SAE.
EPC is responsible to provide an IP connection between an external packet data network by using E-UTRAN and the User Equipment (UE).In the environment of 4G systems, the radio access network and the air interface are actually improving, while the architecture of the core network (that is, EPC) is not suffering large modifications from the previous systematized architecture of SAE.The main part in the architecture of E-UTRAN is the improved Node B (eNB or eNodeB), that providing the air interface between the termination of control plane protocol and the user plane towards the user equipment (UE).Both eNodeBs are a logical element that serving one or more E-UTRAN cells and the interface between the eNodeBs is termed the X2 interface.The interfaces of network are built on IP protocols.The eNodeBs are connected by an X2 interface and to the MME/GW (Mobility Management Entity/Gateway) object with an S1 interface.The interface S1 supported many relationships between eNodeBs and MME/GW (Khan, 2009).The two entities of the logical gateway are termed Serving Gateway (S-GW), and the other is Packet Data Network Gateway (P-GW).
X2 is the interface between the eNodeBs and also involving two interfaces; the first is X2-C, which is the control plane interface between eNodeBs, and X2-U are user plane interface between eNodeBs.It is always supposed that there is an X2 interface between eNodeBs which is to provide communicating between each other (Ghosh et al., 2010).S1-MME represents the S1 control plane interface between MME and eNodeB.Similarly, the transport network layer and user plane are based on IP transport and in case of a reliable transport to the signaling messages; the Stream Control Transmission Protocol (SCTP) is applied over IP.These protocol functions analogously to TCP confirming a reliable, in sequence transmission of all messages with congestion control.SCTP drives analogous to TCP certifying reliable and offer insequence transport of messages with congestion control (Abed et al., 2011).The application layer signaling protocols is mentioned to S1 application protocol (S1-AP) and X2 application protocol (X2-AP) for S1 and X2 interface control planes respectively.LTE, 3GPP is also defining IP-based, flat network architecture.This architecture is defined as part of the (SAE) effort.The LTE/SAE architecture and concepts have been designed for efficient support of mass-market usage of any IP based service.

Queue size estimation
The queue size at a bottleneck would affect the performance of TCP protocols, especially with the single TCP flow and large bandwidth path.There are many studies on TCP/RTT determined by evaluating packet traces, but it is not efficient if the maximum RTT is used to estimate the bottleneck queue size.In this study, the maximum values of one-way delays are immediately measured when a packet loss occurs and leads to queue overflow.To estimate the number of queued packets for each RTT interval in the slow-start phase, the following formula in Equation 1 is used (Hirabaru, 2006).
Where N is the number of queued packets, W is the window size in packets, BW is the link bandwidth capacity, Ro is the bottleneck rate, Wi is the initial window size, and Ri is the burst rate at which the TCP source generates the traffic.
To estimate the number of queued packets for each RTT interval in the slow-start phase, the following formula in Equation ( 2) is used.In Equation (2), the standard TCP increases the window size by two when an ACK is received so that Ri is limited to 2Ro.

RTT
The queue size at a network bottleneck would affect the performance of TCP protocols, particularly when executed in a single TCP flow in networks (Abed et al., 2012a).One of the important metrics to validate the performance is to know the queue sizes of network pipeline, because the dynamic behavior of TCP protocol implementations varies according to bottleneck queue size.The next section focuses on evaluating and investigates the performance of TCP source variants according to the queue length by taking all the packet traces at the sender (Abed et al., 2012b).

Simulation parameters
The proposed model is shown in Figure 2. A new scheme is proposed based on modifying the forwarding packet to add some packet loss to the simulation scenario (Sookhak et al., 2012).It involves one main server for serving data as FTP and HTTP, also to providing source connection for the TCP.The routers Gateway1 and Gateway2 are connected directly to the Server with a duplex link with bandwidth reach to 1Gbps, and propagation delay of three msec.In fact, the propagation delay for all links over the proposed model kept the same value of 3msec, where this value represents the practical latency of the links interfacing and connections on LTE-A networks.The function of Gateway routers is to control the flow rate of the streaming data from the server to the base stations eNodeB1, eNodeB2, and eNodeB3.Gateway within the wired simplex link with Bandwidth reaches to 10 Mbps.The interface between base stations (X2) is very important in a model setting due to the relation between eNodeBs will detect the handover scenario when the UEs move from one eNodeB to another.The base station nodes are responsible for buffering the data packets to the User Equipment's (UEs).
Each base station (eNodeB) is connected to the corresponding the average bandwidth size of X2 proposed to be 20 Mbps and this represent the estimated and practical range.In the proposed model, three UEs used with wireless features and each UE coupled to eNodeB, these UE nodes don't have full mobility features because avoiding the handover scenario in this model where that represents the next step.All linksare kept for one propagation delay of 3msec, and the maximum packet size used sets to 1500 Byte, with minimum window size of 128 packets.

RESULTS AND DISCUSSION
Here the performance of TCP variants that are affected by the queue length by taking all the packet traces at the sender were investigated, where it is possible to calculate the number of queued packets at the bottleneck by simulating drop-tail token buckets.The estimation of queue size over TCP running is subject to several factors and limitations; one of these limitations is at what average rate TCP expects to transmit, but there is no control of the rate within the slow-start period or discovery of the available bandwidth capacity rapidly.Therefore, TCP transmits packets as a burst per RTT intervals at a rate up to the transmitter capability.Because standard TCP's increasing window size almost jumps for each RTT interval, the final growth of window size may save overflowing a bottleneck queue till a packet loss indicates because congestion reaches the sender at most afterward RTT.
The default queue length proposed in LTE-A model is set to 12 packets and the queue monitoring focused on the link between eNodeB1-Gateway and eNodeB2-Gateway as shown in Figure 1.The motive of using 2 bottlenecks in the queue monitor instead of many bottlenecks relates to the testing of the queue management of standard TCP (Tahoe) and comparing it with the management by other TCP's due to the main goal here is not to test the model, but to evaluate the TCP versions.That is why we should expect the queue size not to exceed 12 packets, but simultaneously it should be in large level to avoid congestion in bottlenecks as far as possible.The queue size of Tahoe, Reno, and Vegas TCP are shown in the Figure 3.
Large difference in the queue management performed by the candidate TCP versions in both of steady run and during initialization phase was noted.In Figure 3, Tahoe showed a reasonable queuing control in spite of the poor size in the first 4 seconds but it keeps decent queue level until the simulation end.
Despite Reno and Tahoe are based on similar congestion control mechanism (the difference only happens with multiple packet loss) but they behaved differently.The reason behind the performance difference between Tahoe and Reno, that when Reno is used with multiple packet scenarios will not perform well while Tahoe can perform better.
All TCP variants used in this study used same slowstart mechanism and share many routines in congestion control except TCP-Vegas, where Vegas uses a different approach to avoid congestion in the pipeline network.Vegas congestion control senses the available bandwidth and compares it with the target bandwidth before increase the congestion window.Even though the throughput is steady but it will not be in high level.Figure 3 shows the excessive queue size performed by Vegas over LTE-A model where the size oscillated near the maximum size and the size of queue opened earlier than the other TCP variants.

Conclusions
This article provides experimented results to estimate the queue size given by three TCP variants, Tahoe, Reno, and Vegas over a proposed traffic model of LTE-A system.Furthermore, this article provides the basic procedures to implement the link interface for LTE-A networks by using network simulator NS-2.In addition, it offers the main features of the user plane protocol, control plane protocol, and the link interface of the protocol stack and illustrate the parameter values which make the limitation to the behavior of these protocols over LTE-A.The comparative queue size estimation proved that TCP-Vegas performed better than other TCP versions while Reno performed better than Tahoe.

FUTURE WORK
The future work of the current research will focus to estimate the packet loss of the source TCP variants over the same traffic model of LTE-A.

Figure 2 .
Figure 2. The proposed model of LTE-A.

Figure 3 .
Figure 3. Queue size behavior comparison of Tahoe, Reno and Vegas.