# Protecting Download Traffic from Upload Traffic over Asymmetric Wireless Links

Authors: Hwangnam Kim; Woonghee Lee; Hyunsoon Kim; Hwantae Kim; Jaehyeuk Michael Yang
Journal: Wireless Communications and Mobile Computing
 (2018)

---

## Abstract

Many varied mobile device networks have been developed with the advancement of communication and network technologies. Cellular data networks are currently the most widely used, and the number of cellular network subscriptions has increased steadily. Most recent wireless access technologies employ asymmetric uplinks and downlinks because mobile subscribers usually download contents from the Internet. Therefore, most cellular network service providers allocate more bandwidth to downlinks than uplinks for mobile subscribers. However, this asymmetry can have unexpected influence on network performance, particularly TCP performance. When the uplink interface is congested, TCP ACK packets are delayed by TCP data packets on the uplink, causing considerable TCP retransmissions on the downlink channel. Thus, downlink bandwidth cannot be fully utilized, which results in significantly degraded downlink throughput. To resolve this problem, this paper proposes a feedback scheme, network traffic chunk regulator (NCR). We analyzed the aforementioned problem through the empirical study, and we designed and implemented NCR based on the analysis. NCR adaptively controls TCP according to the degree of link usage asymmetry. We evaluate NCR performance through simulations and experiments with real devices. We verify that the proposed scheme allows the downlink traffic to not interfere with the aggressive uplink traffic. Thus, NCR increases total link utilization and aggregated throughput significantly, without imposing additional overhead on base or mobile stations.


---

## Body

## 1. Introduction

Emerging mobile services and systems allow one or more computing elements, such as applications or control programs, to control one or more physical entities, such as sensors or actuators, and generally assume a networked control system between them. Recent system development trends are tending towards scalable architectures that can be adapted to any application or system rather than systems dedicated to specific purposes. Thus, the systems can be applied to many fields, such as smart grids [1], health care [2], surveillance [3], hazard detection [4], criminal tracking [5], and any system based on networked control, such as cyber-physical systems (CPSs) [6]. The wide application range of mobile services or systems raises concerns that the network infrastructure needs to be suitable for each mobile service or system type. For example, mobile surveillance systems using drones require wireless interface on physical entities (drones) and access points that carry data from drones to control system [3]. Also, traditional surveillance systems, usually based on closed-circuit televisions (CCTVs), are moving toward wireless internet interfaces [7]. In contrast, mobile systems for smart grids require physical entities to periodically record power usage of each location. However, the physical entities are not required to move around, making wired network easily fit into the system [8]. Reasons to employ wireless networks for the network infrastructure to construct such systems, rather than wired or ad hoc sensor networks, are twofold. One is that many mobile services require proper mobility of physical entities to reduce installation complexity. The other is that most systems require reliable and qualified communication [9], which is not easily handled by low power ad hoc sensor networks.On the other hand, emerging networking technologies pose new transmission control protocol (TCP) challenges in terms of performance, requiring analysis, and solutions. TCP enables network management and reliable communication between computing and physical systems. Worldwide interoperability for microwave access (WiMAX) and long term evolution (LTE) are widely used cellular packet data networks [10–13]. They have network asymmetry with respect to network performance to satisfy demanding mobile subscribers by allocating them more downlink than uplink bandwidth. This is because mobile subscribers generally download content from the internet.However, poor downlink throughput has been reported on mobile handsets when downlink and uplink TCP data transfers are simultaneously activated. In such mixed TCP case, TCP ACK packets are delayed by TCP data packets on the uplink, causing considerable downlink TCP retransmissions, as detailed in Section2. We attempted various TCP configurations, such as TCP window size, delay ACK, selective ACK, buffer size, and TCP autotuning to address this problem, but no setting choices were successful. Some studies have addressed TCP upload or download throughput degradation in asymmetric links, including ADSL, cable, and satellite [14–19]. However, the proposed solutions generally impose additional overhead of maintaining separate packet queues [15–24], modifying TCP protocols or parameters [25, 26], or tracking per-flow traffic statistics [18] on access points (i.e., base stations) or mobile stations. Thus, these solutions are either inappropriate or not sufficiently satisfactory to be applied to emerging wireless technologies.To address these asymmetric characteristics and their negative effect on TCP throughput, we propose an adaptive TCP regulator called network traffic chunk regulator (NCR). The contributions of this paper can be summarized as follows.(i)
We show that asymmetry link capacity can have unexpected influence on network performance, particularly TCP performance, and empirically confirm downlink TCP traffic interference from uplink traffic with unexpected throughput degradation.(ii)
We design and implement NCR to adaptively control TCP according to the degree of asymmetry in link usage and discuss the design for the feedback value based on the traffic volumes for each flow, class, and device.(iii)
We evaluate NCR through simulations and empirical experiments using real devices, verifying that NCR successfully regulates uplink and downlink traffic to protect downlink performance, significantly increasing aggregated throughput.(iv)
We show that NCR only requires mobile node management without extra load on managing packet queues in network systems.Current WLANs commonly use contention based resource management, which is inappropriate to provide real-time stable communication between control elements and physical entities. Thus, WLAN is not considered as a target network for the solution, and we only consider quality manageable access networks, such as LTE and WiMAX. However, since we cannot access cellular network and driver internal architectures, we emulate the systems with WLAN devices enabled with interface cards.The remainder of this paper is organized as follows. We present the problem statement based on specific empirical results in Section2, and then we devise the feedback scheme in Section 3. We explain an extensive set of simulation studies and empirical experimentation in Section 4. Then, we summarize the related work in Section 5. We conclude the paper with Section 6.


## 2. Problem Statement

TCP is adaptive to the available network bandwidth in a wide variety of networking environments. However, emerging networking technologies pose new challenges for TCP in terms of performance, requiring analysis and solutions. CDMA evolution data only (1xEV-DO), 3GPP high speed packet data access (HSPA), WiMAX, and LTE are widely used cellular packet data networks [10–13]. They have network asymmetry with respect to network performance [27, 28]. To satisfy demanding mobile subscribers, networks allocate more downlink bandwidth than uplink bandwidth because mobile subscribers generally download content from the internet.However, poor downlink throughput has been reported on mobile handsets for simultaneous downlink and uplink activations. This is because TCP ACK packets are delayed by TCP data packets on the uplink, causing significant TCP retransmissions on the downlink. Poor downlink throughput can also cause control message losses from computing (cyber) elements, breaking real-time physical entity control.To visualize this problem, we constructed a testbed to emulate an asymmetric access network, configuring two laptops as mobile and base stations, respectively. To emulate cellular networks, we used two IEEE 802.11 wireless interface cards for each station. We configured the routing table to employ one interface card as the downlink channel and the other as the uplink channel. We enabled the ad hoc interface mode for the base station laptop. The specific details were as follows:(i)
Base station: Fujitsu Lifebook A6010.(ii)
Mobile station: Fujitsu Lifebook A6010.(iii)
Uplink interface: Intel 3945 ABG with ipw3945 driver.(iv)
Downlink interface: 3Com Wireless 11 a/b/g PC card with madwifi driver.(v)
Operating system: Ubuntu 8.04 LTS with Linux kernel 2.4.24.6.As for routing table modifications, ipw3945(eth1) was set as the higher uplink routing table entry on the mobile station. On the contrary, madwifi(ath0) was set as the higher downlink routing table entry on the base station. We modified the routing tables to separate uplink and downlink traffic between the mobile and base stations. However, this meant address resolution protocol (ARP) messages were not sent and received correctly. Therefore, we also modified the ARP table by inserting internet protocol (IP) address and medium access control (MAC) address tuples into the ARP table statically. To ensure network asymmetry, we also set network bandwidth to 54 and 1 Mb/s for the downlink and uplink interfaces, respectively.We emulated the cellular system using WLAN because we had limited access to manipulate cellular devices and software. We employed IEEE 802.11 as the testbed access network. Thus, the channel access mechanism and bandwidth allocation scheme of the testbed may differ from actual cellular networks. Generally, cellular networks guarantee contention-free channel access and bandwidth allocation for each station. On the contrary, IEEE 802.11 networks provide contention based channel access and bandwidth allocation. However, since the testbed included only a single base and mobile station, the configuration ensured contention-free channel access and bandwidth allocation using IEEE 802.11. Therefore, there was negligible difference between the testbed and cellular networks in terms of network bandwidth, and the testbed was able to successfully emulate network asymmetry.We measured TCP throughput using the FileZilla [29] FTP application and theIperf tool.Iperf is the widely used network testing tool [30]. In principle, FTP andIperf conduct TCP data communication without limiting the data rate. Downlink and uplink data rates were approximately 14 and 1 Mb/s, respectively, for the experiment.


### 2.1. Single Downlink Throughput

Figure1 shows the throughput of downlink TCP traffic generated with FileZilla andIperf. Average downlink throughput was approximately 14 Mb/s for both FileZilla andIperf, but FTP throughput was slightly less and more stable thanIperf. FTP works in user mode and uses the read system call to access its data from the kernel application buffer, which slows it slightly, resulting in more stable read speed.Figure 1
One-way TCP downlink throughput.
(a)
FTP throughput (b)
Iperf throughput


### 2.2. Mixed Downlink and Uplink Throughput

Figure2 shows throughput for simultaneous downlink and uplink TCP flows. Downlink TCP traffic was activated through the whole experiment, and then uplink traffic was started. There is sudden downlink TCP throughput degradation when uplink TCP traffic commences, reducing from 14 Mb/s to 80 Kb/s, whereas uplink TCP throughput was 1 Mb/s. TCP downlink traffic can fully use the allocated link bandwidth provided TCP ACK packet flow to the sender is timely. However, when TCP uplink traffic commenced, the smaller uplink bandwidth (compared to the downlink) was quickly used up. This caused uplink congestion, and the TCP downlink was unable to receive TCP ACK packets timely enough. Consequently, it could exploit the whole downlink bandwidth, and downlink throughput was degraded. There is some fluctuation inIperf throughput after TCP uplink traffic terminates. This is because theIperf TCP congestion window is not large enough to saturate the downlink once it reduces due to interference with uplink TCP data traffic.Figure 2
Combined TCP downlink and uplink throughput.
(a)
FTP downlink and uplink throughput (b)
Iperf downlink and uplink throughputThus, we verified that uplink and downlink flow interfere with each other such that TCP flow cannot fully use the available downlink bandwidth. Therefore, to resolve the problem, we need to protect downlink TCP flow from uplink TCP flow (or other flows). The problem will become more severe as physical cyber systems generate more uplink traffic from physical entities.


## 2.1. Single Downlink Throughput

Figure1 shows the throughput of downlink TCP traffic generated with FileZilla andIperf. Average downlink throughput was approximately 14 Mb/s for both FileZilla andIperf, but FTP throughput was slightly less and more stable thanIperf. FTP works in user mode and uses the read system call to access its data from the kernel application buffer, which slows it slightly, resulting in more stable read speed.Figure 1
One-way TCP downlink throughput.
(a)
FTP throughput (b)
Iperf throughput


## 2.2. Mixed Downlink and Uplink Throughput

Figure2 shows throughput for simultaneous downlink and uplink TCP flows. Downlink TCP traffic was activated through the whole experiment, and then uplink traffic was started. There is sudden downlink TCP throughput degradation when uplink TCP traffic commences, reducing from 14 Mb/s to 80 Kb/s, whereas uplink TCP throughput was 1 Mb/s. TCP downlink traffic can fully use the allocated link bandwidth provided TCP ACK packet flow to the sender is timely. However, when TCP uplink traffic commenced, the smaller uplink bandwidth (compared to the downlink) was quickly used up. This caused uplink congestion, and the TCP downlink was unable to receive TCP ACK packets timely enough. Consequently, it could exploit the whole downlink bandwidth, and downlink throughput was degraded. There is some fluctuation inIperf throughput after TCP uplink traffic terminates. This is because theIperf TCP congestion window is not large enough to saturate the downlink once it reduces due to interference with uplink TCP data traffic.Figure 2
Combined TCP downlink and uplink throughput.
(a)
FTP downlink and uplink throughput (b)
Iperf downlink and uplink throughputThus, we verified that uplink and downlink flow interfere with each other such that TCP flow cannot fully use the available downlink bandwidth. Therefore, to resolve the problem, we need to protect downlink TCP flow from uplink TCP flow (or other flows). The problem will become more severe as physical cyber systems generate more uplink traffic from physical entities.


## 3. Network Traffic Chunk Regulator

This section introduces the proposed network traffic chunk regulator (NCR) to regulate downlink and uplink traffic at the uplink interface of a mobile device. We first present a brief feedback control scheme and explain how to design the feedback value based on traffic volume for each flow, class (uplink or downlink), and device.


### 3.1. Feedback Control Scheme for Regulation

The NCR uses a feedback value to quantify uplink and downlink traffic volumes. We propose a feedback control scheme that delivers the feedback value to TCP senders in the local stations (uplink traffic) or remote stations (downlink traffic), which allows TCP senders to adjust their sending rates according to the feedback value. Figure3 shows the overall block diagram of NCR. For every interval, NCR calculates the per-flow, class wide, and device wide feedback values specified in Section 3.2. When a packet arrives at the NCR module, it is identified as downlink or uplink traffic. Then, NCR produces a random number with value uniformly distributed over the feasible range of feedback values, normalized to [0,1], and compares the random value with the feedback value. If the number is less than the feedback value, NCR sets the explicit congestion notification (ECN) bit in the IP header and delivers the packet to the intended sender. Thus, the probability of setting the ECN bit increases as the feedback value increases. TCP senders reduce their congestion window size upon receiving a packet with the ECN bit set or increase the window size if the ECN bit is unset.Figure 3
The overall block diagram of NCR.Figure4 shows a conceptual feedback architecture for the proposed NCR. NCR is located between the IP and device drivers. NCR calculates the feedback value using the algorithm from Section 3.2 and then sends the feedback value to each TCP receiver.Figure 4
The feedback architecture of NCR.


### 3.2. Feedback Value for Regulation

The NCR monitors device wide, class (uplink or downlink) wide, and per-flow traffic and calculates the feedback value for each network or device time interval,Tnet or Tdev, respectively. Since the feedback value is monitored and calculated at given intervals, the computation is also executed at the corresponding intervals. The feedback value, ρi, for flow i consists of three components:(1)ρit=ρfit+ρct+ρdt,where (i)
ρfi is the difference between the desired and measured per-flow traffic;(ii)
ρc is the class (downlink or uplink) wide difference between desired and measured class wide traffic;(iii)
ρd is the device wide difference between target and measured aggregate traffic load at the uplink interface in the mobile station.The first two terms in (1) are updated at intervals of Tdev, while the last one is updated at intervals of Tnet.


#### 3.2.1. Per-Flow Feedback Value

To estimate per-flow feedback value, we first assign a weight,φi, to each flow, i, which is used to determine traffic for the flow. After determining each flow usage, if there is spare bandwidth in output link, the bandwidth is redistributed to each flow according to φi. In the fair condition, all φi are equal. Let Ri(t), i=1,…,n, be the flow i and Riin(t), i=1,…,n, be the cumulative (cumulative means we regulate flows by overall traffic volume rather than instantaneous traffic rate) input volume for flow i entering the NCR until the t-th interval of Tdev. Similarly, let Riout(t), i=1,…,n, be the cumulative output volume for flow i exiting the NCR. In this situation, if φi≥φj, then data transmission in time interval [s+1,t] is(2)Rioutt-Rioutsφi≥Rjoutt-Rjoutsφj.Therefore,(3)φjRioutt-Riouts≥φiRjoutt-Rjouts,and summing up for all j, yields(4)∑j=1nφjRioutt-Riouts≥φi∑j=1nRjoutt-Rjouts.Since(5)∑j=1nRjoutt-Rjouts=ct-sTdev,where c is the link capacity and C(t)=∑i=1tc(i)Tdev is the cumulative capacity in the interval [1,t],(6)Rioutt-Riouts≥φi∑j=1nφjct-sTdev.Lets+1 be the beginning time slot for the last busy period (busy period means the duration that the uplink interface is continuously used) for flow i up to time t. Then,(7)Rioutt≥Riins+φi∑j=1nφjct-sTdev,≥min0≤s≤t⁡Riins+φi∑j=1nφjct-sTdev,where Riout(s)=Riin(s) since all input traffic is transmitted to the output before a new busy period commences. Therefore, each flow i should have at least(8)fis,t=φi∑j=1nφjct-sTdev,during the interval [s,t].Thus, we can defineρfi(s,t) as(9)ρfis,t=κfRiouts,t-fis,tRiouts,t,where κf is a smoothing factor and Riout[t] represents the measured traffic of flow i. Equation (9) can be simplified to provide the output volume for flow i for a single time interval,(10)ρfit=ρfit-1,t=κfrioutt-fitrioutt,where fi(t)=fi(t-1,t)=φi/∑j=1nφjc(t-(t-1))Tdev and riout=Riout(t)-Riout(t-1).


#### 3.2.2. Class Wide Feedback Value

Since each flowi is assigned weight φi, the weight for the aggregate uplink traffic is(11)φul=∑i∈Mulφi,where Mul is the set of all uplink flows. Similarly,(12)φdl=∑i∈Mdlφi,where Mdl is the set of downlink flows.To prioritize downlink traffic, we apply the constraintφdl>φul, which imposes the additional constraint on each φi(∈Mdl). Let Rdlin(t) and Rulin(t) be the cumulative input volume for aggregate downlink and uplink traffic, respectively, until the t-th interval of Tdev. Similarly, let Rdlout(t) and Rulout(t) be the cumulative output volume for aggregate downlink and uplink traffic, respectively. Using the equal procedure of deriving ρfi,(13)Rdloutt-Rdlouts≥φdlφdl+φulct-sTdev.Lets+1 be the beginning slot of the last busy period of the aggregate downlink input up to time t. Then, since Rdlout(s)=Rdlin(s),(14)Rdloutt≥Rdlins+φdlφdl+φulct-sTdev,≥min0≤s≤t⁡Rdlins+φdlφdl+φulct-sTdev.Therefore, the aggregate downlink traffic should have at least volume(15)fdls,t=φdlφdl+φulct-sTdev,during interval [s,t]. Thus, ρc(s,t) for aggregate downlink traffic is(16)ρcs,t=κcRdlouts,t-fdls,tRdlouts,t,where κc is a smoothing factor and Rdlout[t] is the measured volume for aggregate downlink traffic. Hence, the feedback value for a single time interval is(17)ρcit=ρcit-1,t=κcrdloutt-fdltrdloutt,where fdl(t)=φdl/φdl+φulcTdev and rdlout=Rdlout(t)-Rdlout(t-1).Similarly,ρc(s,t) and ρc(t) for aggregate uplink traffic are(18)ρcs,t=κcRulouts,t-fuls,tRulouts,t,ρcit=κcruloutt-fultruloutt,where Rulout(t) is the measured aggregate uplink traffic,(19)fult=φulφul+φdlcTdev,and(20)rulout=Ruloutt-Ruloutt-1.


#### 3.2.3. Device Wide Feedback Value

LetR(t) be device wide cumulative traffic until the t-th interval of Tnet, Rin(t) be the cumulative input volume for aggregate device traffic and Rout(t) be the cumulative output volume for aggregate device traffic. Then,(21)Routt-Routs≥ct-sTnet.where c is the link capacity. Thus,(22)Routt≥Rins+ct-sTnet,≥min0≤s≤tRins+ct-sTnet,since Rout(s)=Rin(s). Therefore, we can define the device wide feedback value as(23)ρds,t=Rs,t-ct-sTnet.Hence, the feedback value for a single time interval is (24)ρdt=Rt-cTnet.Consider the effect of a buffer, which can accommodate burst traffic, and feedback value error in calculatingρd(t). Since the network interface device usually employs the buffer to accommodate burst traffic, (24) can be extended to(25)ρdt=Rt-cTnet+γqt-qroom,where q(t) is the queue length at the t-th interval of Tnet, qroom is the desired queue length, and γ(>0) is a control gain. However, the feedback value may include error relative to the correct value, which will accumulate over time. Thus, (25) can be expressed as(26)ρdt=Rt-cTnet+γqt-qroom+β∑k=0t-1Rk-cTnet+γqk-qroom,where the last term is the result of summing errors incurred by (25) over all intervals up to t, and β(>0) is a control gain.Finally, the feedback value with control gainα(>0) can be expressed as(27)ρdt=αRi-cTnet+γqt-qroom+β∑k=0t-1Rk-cTnet+γqk-qroom.This final feedback value can be used to let traffic senders adjust their transmission rate together withρf and ρc. The term R(k)-cTnet in (27) can be approximated as(28)Rk-cTnet=qk-qk-1.With (28), the feedback value from (27) can be more easily estimated using the queue length,(29)ρdt=αγ+β+1qt-qt-1-γqroom+βγ∑k=0t-1qt-qroom.


## 3.1. Feedback Control Scheme for Regulation

The NCR uses a feedback value to quantify uplink and downlink traffic volumes. We propose a feedback control scheme that delivers the feedback value to TCP senders in the local stations (uplink traffic) or remote stations (downlink traffic), which allows TCP senders to adjust their sending rates according to the feedback value. Figure3 shows the overall block diagram of NCR. For every interval, NCR calculates the per-flow, class wide, and device wide feedback values specified in Section 3.2. When a packet arrives at the NCR module, it is identified as downlink or uplink traffic. Then, NCR produces a random number with value uniformly distributed over the feasible range of feedback values, normalized to [0,1], and compares the random value with the feedback value. If the number is less than the feedback value, NCR sets the explicit congestion notification (ECN) bit in the IP header and delivers the packet to the intended sender. Thus, the probability of setting the ECN bit increases as the feedback value increases. TCP senders reduce their congestion window size upon receiving a packet with the ECN bit set or increase the window size if the ECN bit is unset.Figure 3
The overall block diagram of NCR.Figure4 shows a conceptual feedback architecture for the proposed NCR. NCR is located between the IP and device drivers. NCR calculates the feedback value using the algorithm from Section 3.2 and then sends the feedback value to each TCP receiver.Figure 4
The feedback architecture of NCR.


## 3.2. Feedback Value for Regulation

The NCR monitors device wide, class (uplink or downlink) wide, and per-flow traffic and calculates the feedback value for each network or device time interval,Tnet or Tdev, respectively. Since the feedback value is monitored and calculated at given intervals, the computation is also executed at the corresponding intervals. The feedback value, ρi, for flow i consists of three components:(1)ρit=ρfit+ρct+ρdt,where (i)
ρfi is the difference between the desired and measured per-flow traffic;(ii)
ρc is the class (downlink or uplink) wide difference between desired and measured class wide traffic;(iii)
ρd is the device wide difference between target and measured aggregate traffic load at the uplink interface in the mobile station.The first two terms in (1) are updated at intervals of Tdev, while the last one is updated at intervals of Tnet.


### 3.2.1. Per-Flow Feedback Value

To estimate per-flow feedback value, we first assign a weight,φi, to each flow, i, which is used to determine traffic for the flow. After determining each flow usage, if there is spare bandwidth in output link, the bandwidth is redistributed to each flow according to φi. In the fair condition, all φi are equal. Let Ri(t), i=1,…,n, be the flow i and Riin(t), i=1,…,n, be the cumulative (cumulative means we regulate flows by overall traffic volume rather than instantaneous traffic rate) input volume for flow i entering the NCR until the t-th interval of Tdev. Similarly, let Riout(t), i=1,…,n, be the cumulative output volume for flow i exiting the NCR. In this situation, if φi≥φj, then data transmission in time interval [s+1,t] is(2)Rioutt-Rioutsφi≥Rjoutt-Rjoutsφj.Therefore,(3)φjRioutt-Riouts≥φiRjoutt-Rjouts,and summing up for all j, yields(4)∑j=1nφjRioutt-Riouts≥φi∑j=1nRjoutt-Rjouts.Since(5)∑j=1nRjoutt-Rjouts=ct-sTdev,where c is the link capacity and C(t)=∑i=1tc(i)Tdev is the cumulative capacity in the interval [1,t],(6)Rioutt-Riouts≥φi∑j=1nφjct-sTdev.Lets+1 be the beginning time slot for the last busy period (busy period means the duration that the uplink interface is continuously used) for flow i up to time t. Then,(7)Rioutt≥Riins+φi∑j=1nφjct-sTdev,≥min0≤s≤t⁡Riins+φi∑j=1nφjct-sTdev,where Riout(s)=Riin(s) since all input traffic is transmitted to the output before a new busy period commences. Therefore, each flow i should have at least(8)fis,t=φi∑j=1nφjct-sTdev,during the interval [s,t].Thus, we can defineρfi(s,t) as(9)ρfis,t=κfRiouts,t-fis,tRiouts,t,where κf is a smoothing factor and Riout[t] represents the measured traffic of flow i. Equation (9) can be simplified to provide the output volume for flow i for a single time interval,(10)ρfit=ρfit-1,t=κfrioutt-fitrioutt,where fi(t)=fi(t-1,t)=φi/∑j=1nφjc(t-(t-1))Tdev and riout=Riout(t)-Riout(t-1).


### 3.2.2. Class Wide Feedback Value

Since each flowi is assigned weight φi, the weight for the aggregate uplink traffic is(11)φul=∑i∈Mulφi,where Mul is the set of all uplink flows. Similarly,(12)φdl=∑i∈Mdlφi,where Mdl is the set of downlink flows.To prioritize downlink traffic, we apply the constraintφdl>φul, which imposes the additional constraint on each φi(∈Mdl). Let Rdlin(t) and Rulin(t) be the cumulative input volume for aggregate downlink and uplink traffic, respectively, until the t-th interval of Tdev. Similarly, let Rdlout(t) and Rulout(t) be the cumulative output volume for aggregate downlink and uplink traffic, respectively. Using the equal procedure of deriving ρfi,(13)Rdloutt-Rdlouts≥φdlφdl+φulct-sTdev.Lets+1 be the beginning slot of the last busy period of the aggregate downlink input up to time t. Then, since Rdlout(s)=Rdlin(s),(14)Rdloutt≥Rdlins+φdlφdl+φulct-sTdev,≥min0≤s≤t⁡Rdlins+φdlφdl+φulct-sTdev.Therefore, the aggregate downlink traffic should have at least volume(15)fdls,t=φdlφdl+φulct-sTdev,during interval [s,t]. Thus, ρc(s,t) for aggregate downlink traffic is(16)ρcs,t=κcRdlouts,t-fdls,tRdlouts,t,where κc is a smoothing factor and Rdlout[t] is the measured volume for aggregate downlink traffic. Hence, the feedback value for a single time interval is(17)ρcit=ρcit-1,t=κcrdloutt-fdltrdloutt,where fdl(t)=φdl/φdl+φulcTdev and rdlout=Rdlout(t)-Rdlout(t-1).Similarly,ρc(s,t) and ρc(t) for aggregate uplink traffic are(18)ρcs,t=κcRulouts,t-fuls,tRulouts,t,ρcit=κcruloutt-fultruloutt,where Rulout(t) is the measured aggregate uplink traffic,(19)fult=φulφul+φdlcTdev,and(20)rulout=Ruloutt-Ruloutt-1.


### 3.2.3. Device Wide Feedback Value

LetR(t) be device wide cumulative traffic until the t-th interval of Tnet, Rin(t) be the cumulative input volume for aggregate device traffic and Rout(t) be the cumulative output volume for aggregate device traffic. Then,(21)Routt-Routs≥ct-sTnet.where c is the link capacity. Thus,(22)Routt≥Rins+ct-sTnet,≥min0≤s≤tRins+ct-sTnet,since Rout(s)=Rin(s). Therefore, we can define the device wide feedback value as(23)ρds,t=Rs,t-ct-sTnet.Hence, the feedback value for a single time interval is (24)ρdt=Rt-cTnet.Consider the effect of a buffer, which can accommodate burst traffic, and feedback value error in calculatingρd(t). Since the network interface device usually employs the buffer to accommodate burst traffic, (24) can be extended to(25)ρdt=Rt-cTnet+γqt-qroom,where q(t) is the queue length at the t-th interval of Tnet, qroom is the desired queue length, and γ(>0) is a control gain. However, the feedback value may include error relative to the correct value, which will accumulate over time. Thus, (25) can be expressed as(26)ρdt=Rt-cTnet+γqt-qroom+β∑k=0t-1Rk-cTnet+γqk-qroom,where the last term is the result of summing errors incurred by (25) over all intervals up to t, and β(>0) is a control gain.Finally, the feedback value with control gainα(>0) can be expressed as(27)ρdt=αRi-cTnet+γqt-qroom+β∑k=0t-1Rk-cTnet+γqk-qroom.This final feedback value can be used to let traffic senders adjust their transmission rate together withρf and ρc. The term R(k)-cTnet in (27) can be approximated as(28)Rk-cTnet=qk-qk-1.With (28), the feedback value from (27) can be more easily estimated using the queue length,(29)ρdt=αγ+β+1qt-qt-1-γqroom+βγ∑k=0t-1qt-qroom.


## 3.2.1. Per-Flow Feedback Value

To estimate per-flow feedback value, we first assign a weight,φi, to each flow, i, which is used to determine traffic for the flow. After determining each flow usage, if there is spare bandwidth in output link, the bandwidth is redistributed to each flow according to φi. In the fair condition, all φi are equal. Let Ri(t), i=1,…,n, be the flow i and Riin(t), i=1,…,n, be the cumulative (cumulative means we regulate flows by overall traffic volume rather than instantaneous traffic rate) input volume for flow i entering the NCR until the t-th interval of Tdev. Similarly, let Riout(t), i=1,…,n, be the cumulative output volume for flow i exiting the NCR. In this situation, if φi≥φj, then data transmission in time interval [s+1,t] is(2)Rioutt-Rioutsφi≥Rjoutt-Rjoutsφj.Therefore,(3)φjRioutt-Riouts≥φiRjoutt-Rjouts,and summing up for all j, yields(4)∑j=1nφjRioutt-Riouts≥φi∑j=1nRjoutt-Rjouts.Since(5)∑j=1nRjoutt-Rjouts=ct-sTdev,where c is the link capacity and C(t)=∑i=1tc(i)Tdev is the cumulative capacity in the interval [1,t],(6)Rioutt-Riouts≥φi∑j=1nφjct-sTdev.Lets+1 be the beginning time slot for the last busy period (busy period means the duration that the uplink interface is continuously used) for flow i up to time t. Then,(7)Rioutt≥Riins+φi∑j=1nφjct-sTdev,≥min0≤s≤t⁡Riins+φi∑j=1nφjct-sTdev,where Riout(s)=Riin(s) since all input traffic is transmitted to the output before a new busy period commences. Therefore, each flow i should have at least(8)fis,t=φi∑j=1nφjct-sTdev,during the interval [s,t].Thus, we can defineρfi(s,t) as(9)ρfis,t=κfRiouts,t-fis,tRiouts,t,where κf is a smoothing factor and Riout[t] represents the measured traffic of flow i. Equation (9) can be simplified to provide the output volume for flow i for a single time interval,(10)ρfit=ρfit-1,t=κfrioutt-fitrioutt,where fi(t)=fi(t-1,t)=φi/∑j=1nφjc(t-(t-1))Tdev and riout=Riout(t)-Riout(t-1).


## 3.2.2. Class Wide Feedback Value

Since each flowi is assigned weight φi, the weight for the aggregate uplink traffic is(11)φul=∑i∈Mulφi,where Mul is the set of all uplink flows. Similarly,(12)φdl=∑i∈Mdlφi,where Mdl is the set of downlink flows.To prioritize downlink traffic, we apply the constraintφdl>φul, which imposes the additional constraint on each φi(∈Mdl). Let Rdlin(t) and Rulin(t) be the cumulative input volume for aggregate downlink and uplink traffic, respectively, until the t-th interval of Tdev. Similarly, let Rdlout(t) and Rulout(t) be the cumulative output volume for aggregate downlink and uplink traffic, respectively. Using the equal procedure of deriving ρfi,(13)Rdloutt-Rdlouts≥φdlφdl+φulct-sTdev.Lets+1 be the beginning slot of the last busy period of the aggregate downlink input up to time t. Then, since Rdlout(s)=Rdlin(s),(14)Rdloutt≥Rdlins+φdlφdl+φulct-sTdev,≥min0≤s≤t⁡Rdlins+φdlφdl+φulct-sTdev.Therefore, the aggregate downlink traffic should have at least volume(15)fdls,t=φdlφdl+φulct-sTdev,during interval [s,t]. Thus, ρc(s,t) for aggregate downlink traffic is(16)ρcs,t=κcRdlouts,t-fdls,tRdlouts,t,where κc is a smoothing factor and Rdlout[t] is the measured volume for aggregate downlink traffic. Hence, the feedback value for a single time interval is(17)ρcit=ρcit-1,t=κcrdloutt-fdltrdloutt,where fdl(t)=φdl/φdl+φulcTdev and rdlout=Rdlout(t)-Rdlout(t-1).Similarly,ρc(s,t) and ρc(t) for aggregate uplink traffic are(18)ρcs,t=κcRulouts,t-fuls,tRulouts,t,ρcit=κcruloutt-fultruloutt,where Rulout(t) is the measured aggregate uplink traffic,(19)fult=φulφul+φdlcTdev,and(20)rulout=Ruloutt-Ruloutt-1.


## 3.2.3. Device Wide Feedback Value

LetR(t) be device wide cumulative traffic until the t-th interval of Tnet, Rin(t) be the cumulative input volume for aggregate device traffic and Rout(t) be the cumulative output volume for aggregate device traffic. Then,(21)Routt-Routs≥ct-sTnet.where c is the link capacity. Thus,(22)Routt≥Rins+ct-sTnet,≥min0≤s≤tRins+ct-sTnet,since Rout(s)=Rin(s). Therefore, we can define the device wide feedback value as(23)ρds,t=Rs,t-ct-sTnet.Hence, the feedback value for a single time interval is (24)ρdt=Rt-cTnet.Consider the effect of a buffer, which can accommodate burst traffic, and feedback value error in calculatingρd(t). Since the network interface device usually employs the buffer to accommodate burst traffic, (24) can be extended to(25)ρdt=Rt-cTnet+γqt-qroom,where q(t) is the queue length at the t-th interval of Tnet, qroom is the desired queue length, and γ(>0) is a control gain. However, the feedback value may include error relative to the correct value, which will accumulate over time. Thus, (25) can be expressed as(26)ρdt=Rt-cTnet+γqt-qroom+β∑k=0t-1Rk-cTnet+γqk-qroom,where the last term is the result of summing errors incurred by (25) over all intervals up to t, and β(>0) is a control gain.Finally, the feedback value with control gainα(>0) can be expressed as(27)ρdt=αRi-cTnet+γqt-qroom+β∑k=0t-1Rk-cTnet+γqk-qroom.This final feedback value can be used to let traffic senders adjust their transmission rate together withρf and ρc. The term R(k)-cTnet in (27) can be approximated as(28)Rk-cTnet=qk-qk-1.With (28), the feedback value from (27) can be more easily estimated using the queue length,(29)ρdt=αγ+β+1qt-qt-1-γqroom+βγ∑k=0t-1qt-qroom.


## 4. Performance Evaluation

This section details the NCR performance evaluation using simulations and experiment studies. We implemented the proposed NCR as a light interface layer between the IP and MAC layers at the uplink interface.


### 4.1. Simulation Studies

For the simulation, we employedns-2,ns-3, andOPNET simulators since each simulates a different cellular network type. We employedns-2 to emulate general access networks with separated uplink and downlink, enabling multiple interfaces for a station and using each interface as an uplink or downlink. We also simulated cellular access networks withOPNET andns-3.OPNET has an elaborate WiMAX module, whereasns-3 has a precise LTE module.Figure5 shows the network topology we used for the simulation and empirical studies. One downlink and one uplink channel were activated at the mobile station communicating with its peer downlink and uplink server. The downlink channel receives TCP data packets via the downlink interface from the downlink interface of the base station, i.e., its connection peer. In contrast, the downlink channel sends TCP ACK packets via the uplink interface to the uplink interface of the base station, i.e., its connection peer. The uplink channel sends TCP data packets through the uplink interface and receives TCP ACK packets from the downlink interface.Figure 5
Network topology for simulation and experiment studies.The control parameters of the NCR scheme,α, β, γ, κf, and κc, were set to 0.03, 0.03, 0.05, 1.0, and 1.0, respectively. Update intervals, Tnet and Tdev, were set to 10 and 10 ms, respectively. Recall that Tdev is the update interval to calculate per-flow and class wide feedback value and Tnet is the update interval to computer device wide feedback value. These parameters were determined from a preevaluation simulation series, a common method for parameter tuning in many research fields. The target for the uplink interface queue was set to 50 packets.


#### 4.1.1. Simulation Study with IEEE 802.11

We implemented NCR in thens-2 simulation and subsequently improved the simulation by enabling multiple interfaces in IEEE 802.11-based WLANs and employing each interface as separate uplink and downlink channels. To ensure network bandwidth asymmetry, we set the downlink interface at 11 Mb/s and uplink interface at 1 Mb/s for both the mobile station and its associated AP. Downlink and uplink data rates were approximately 3.5 and 1 Mb/s, respectively.The first simulation study withns-2 used the following simulation scenario: (i) downlink traffic was active in the entire simulation period [0, 60] s; (ii) uplink traffic was started at 20 s and stopped at 40 s precisely. Figure 6 shows that throughput dynamics between downlink and uplink flow are strongly consistent with the testbed evaluation (Figures 1 and 2). Downlink flow is severely reduced in the presence of uplink flow, with uplink and downlink flows 765 and 870 Kb/s during the period [20, 40] s, whereas downlink flow for periods [0, 20] s and [40, 60] s (before and after uplink flow was activated, respectively) reached 3.29 and 3.35 Mb/s, respectively. When we enabled NCR, downlink flow was protected, reaching 3.29, 3.08, and 3.35 Mb/s for periods [0, 20] s (downlink only), [20, 40] s (uplink flow 164 Kb/s), and [40, 60] s (downlink only), respectively.Figure 6
TCP throughput comparison between downlink and uplink flow.
(a)
Normal WLAN throughput (b)
NCR enabled WLAN throughputAs the second simulation study, we evaluated the NCR effectiveness for various uplink and downlink flows, aggregate downlink and uplink throughputs, and average end-to-end delay using the following simulation scenarios: (i) the total simulation time was 60 s; (ii) uplink and downlink flow were active throughout the entire simulation; (iii) the number of downlink flows was varying from 1 to 3, and the number of uplink flows was changing from 1 to 5; (iv) 10 simulation runs were conducted for each simulation configuration. Table1 compares indicative IEEE 802.11-based WLAN (normal WLAN) and NCR enabled WLAN cases. Downlink and uplink throughput values in the table are aggregate throughput over all the relevant flows, averaged over the 10 simulation runs. The outcomes are consistent with the previous simulation study: uplink flow severely degrades downlink flow, regardless of the number of uplink or downlink flows for normal WLAN conditions, but NCR effectively protects downlink flow.Table 1
Average uplink (UL) and downlink (DL) throughput for differently configured networks.
# of flows IEEE 802.11 WLAN NCR enabled WLAN DL UL DL (Mb/s) UL (Mb/s) DL (Mb/s) UL (Mb/s) 1 1 0.754 0.771 3.078 0.164 1 2 0.432 0.843 2.988 0.292 1 3 0.391 0.848 2.892 0.386 1 4 0.385 0.810 2.773 0.461 1 5 0.366 0.840 2.594 0.521 2 1 1.347 0.707 5.665 0.105 2 2 1.046 0.771 5.357 0.204 2 3 0.963 0.786 4.884 0.284 2 4 1.199 0.740 4.567 0.333 2 5 0.999 0.778 4.330 0.376 3 1 3.366 0.479 5.799 0.068 3 2 2.929 0.554 5.769 0.137 3 3 2.617 0.598 5.685 0.186 3 4 2.558 0.601 5.439 0.240 3 5 2.148 0.710 5.417 0.266Figure7 shows that NCR also positively influences overall network throughput and end-to-end delay. As shown in the figure, the aggregate network throughput for NCR was 2.58 times that for the normal WLAN case (Figure 7(a)). Also, average end-to-end delay for NCR was 6.85 times less than that for the normal WLAN case (Figure 7(b)).Figure 7
Aggregate throughput and end-to-end delay for differently configured networks.
(a)
Aggregate throughput (b)
End-to-end delay


#### 4.1.2. Simulation Study with WiMAX

We implemented NCR in the WiMAX module of theOPNET simulator. To verify that the proposed NCR can efficiently manage the network for a long period of time, we conducted a simulation with much longer traffic period. The specific simulation settings were as follows: (i) the downlink station received data from the server during the period [10, 600] s; (ii) the uplink station started sending data to the server at 200 s and stopped at 400 s precisely. We allocated 25% capacity to uplink and the remaining 75% to downlink to ensure network asymmetry and data rate similar to reality. We used the WiMAX characteristics of Vividwireless [31, 32]. Downlink and uplink data rates were approximately 4.5 and 1.5 Mb/s, respectively.Figure8 shows throughput results. Similar throughput was achieved for the normal and NCR enabled WiMAX networks during the period [10, 200] s (no uplink traffic), 4.28 and 4.33 Mb/s, respectively. However, during [200, 400] s (active uplink traffic), normal WiMAX network performance was degraded to 1.52 Mb/s, whereas the NCR enabled network achieved 3.17 Mb/s.Figure 8
Comparison of WiMAX network throughputs.
(a)
Normal WiMAX network throughput (b)
NCR enabled WiMAX network throughputFigure9 shows TCP round trip times (RTT). As shown in the figure, the RTT of downlink traffic was reduced approximately 47% in NCR enabled WiMAX network. A notable point of the results is that RTT of the uplink traffic was also reduced (28%) when we enabled NCR. Since NCR usually dropped uplink packets and hence could shorten the uplink interface queue, downlink and uplink RTTs were both reduced.Figure 9
Comparison of round trip times (RTT) between normal and NCR enabled WiMAX networks.
(a)
Downlink traffic RTT (b)
Uplink traffic RTTFigure10 shows aggregate throughput for normal and NCR enabled WiMAX networks. NCR allowed more efficient use of the limited wireless network capacity, with aggregated throughput increasing approximately 28% compared to the normal WiMAX network.Figure 10
Aggregated throughput of normal and NCR enabled WiMAX networks.


#### 4.1.3. Simulation Study with LTE

We performed the simulation study on LTE network which is the most advanced network withns-3. We employedns-3 LTE module of LENA project [33]. We used the same scenario as Section 4.1.2 except that downlink traffic was active [1, 50] s and uplink traffic was active [13, 39] s. We assigned 25 resource blocks to the uplink and 50 blocks to the downlink to ensure network asymmetry and data rate similar to reality. We used Verizon wireless network characteristics from [34]. Downlink and uplink data rates were approximately 30 and 15 Mb/s, respectively.Figure11 compares normal and NCR enabled network throughputs. NCR successfully regulated uplink and downlink traffic to protect mobile device downlink performance. Average downlink throughputs were 16.99 and 30.02 Mb/s during the period [13, 39] s for normal and NCR enabled LTE networks, respectively.Figure 11
Comparison of normal and NCR enabled LTE network throughputs.
(a)
Normal LTE network throughput (b)
NCR enabled LTE network throughputFigure12 compares aggregated throughputs of normal and NCR enabled LTE network. Similar to the previous simulation results, NCR achieved significantly more efficient link usage. Average aggregated throughputs were 31.36 and 36.19 Mb/s during the period [13, 39] s for normal and NCR enabled LTE networks, respectively. The normal LTE aggregated throughput does not show the sink behavior evident for the previously considered wireless networks. This is because LTE cells provide considerably more uplink bandwidth since many mobile phone applications require duplex communication, e.g., Skype and p2p torrent services. However, NCR still shows performance enhancement because the asymmetric bandwidth problem remains not fully resolved.Figure 12
Aggregated throughput of normal and NCR enabled LTE networks.Thus, the simulations confirm that the proposed NCR can successfully protect downlink traffic in WiMAX, LTE, and general asymmetric network architectures.


### 4.2. Empirical Study

For the empirical study, we employed the testbed from Section2 and implemented NCR in the mobile station. Figure 13 shows the overall NCR software architecture and data flows at the Linux kernel function level. As discussed before, NCR can be implemented as a light interface layer between the IP and MAC layer. Therefore, to implement the layer, we created a virtual device driver and made hooking in dev_hard_start_xmit() function to perform packet queueing from IP layer to MAC layer (device driver). Then, we implemented NCR in the virtual device driver.Figure 13
Linux kernel architecture and function level flows.Figure14 shows empirical results from experiments using FileZilla andIperf as traffic generators. Downlink and uplink data rates were approximately 14 and 1 Mb/s, respectively. We employed the same evaluation scenarios described in Section 2. Cellular networks cannot protect downlink traffic from uplink traffic interference as discussed in Section 2. However, NCR secured downlink flow from uplink interference, with average 10.7 and 11.6 Mb/s for FileZilla andIperf through [60, 120] s (uplink and downlink traffic simultaneously enabled). Also, during the period [60, 120] s, average aggregated throughputs were 1.24 and 11.0 Mb/s for normal and NCR enabled devices with FileZilla traffic, respectively. Similarly, during that period, average aggregated throughputs were 1.28 and 11.7 Mb/s for normal and NCR enabled devices withIperf traffic, respectively. Substantially similar results were obtained when we used different combinations of uplink and downlink traffic and thus are omitted for brevity.Figure 14
Throughput comparison of downlink and uplink for the real testbed.
(a)
FTP traffic throughput for NCR enabled device (b)
Iperf traffic throughput for NCR enabled device


## 4.1. Simulation Studies

For the simulation, we employedns-2,ns-3, andOPNET simulators since each simulates a different cellular network type. We employedns-2 to emulate general access networks with separated uplink and downlink, enabling multiple interfaces for a station and using each interface as an uplink or downlink. We also simulated cellular access networks withOPNET andns-3.OPNET has an elaborate WiMAX module, whereasns-3 has a precise LTE module.Figure5 shows the network topology we used for the simulation and empirical studies. One downlink and one uplink channel were activated at the mobile station communicating with its peer downlink and uplink server. The downlink channel receives TCP data packets via the downlink interface from the downlink interface of the base station, i.e., its connection peer. In contrast, the downlink channel sends TCP ACK packets via the uplink interface to the uplink interface of the base station, i.e., its connection peer. The uplink channel sends TCP data packets through the uplink interface and receives TCP ACK packets from the downlink interface.Figure 5
Network topology for simulation and experiment studies.The control parameters of the NCR scheme,α, β, γ, κf, and κc, were set to 0.03, 0.03, 0.05, 1.0, and 1.0, respectively. Update intervals, Tnet and Tdev, were set to 10 and 10 ms, respectively. Recall that Tdev is the update interval to calculate per-flow and class wide feedback value and Tnet is the update interval to computer device wide feedback value. These parameters were determined from a preevaluation simulation series, a common method for parameter tuning in many research fields. The target for the uplink interface queue was set to 50 packets.


### 4.1.1. Simulation Study with IEEE 802.11

We implemented NCR in thens-2 simulation and subsequently improved the simulation by enabling multiple interfaces in IEEE 802.11-based WLANs and employing each interface as separate uplink and downlink channels. To ensure network bandwidth asymmetry, we set the downlink interface at 11 Mb/s and uplink interface at 1 Mb/s for both the mobile station and its associated AP. Downlink and uplink data rates were approximately 3.5 and 1 Mb/s, respectively.The first simulation study withns-2 used the following simulation scenario: (i) downlink traffic was active in the entire simulation period [0, 60] s; (ii) uplink traffic was started at 20 s and stopped at 40 s precisely. Figure 6 shows that throughput dynamics between downlink and uplink flow are strongly consistent with the testbed evaluation (Figures 1 and 2). Downlink flow is severely reduced in the presence of uplink flow, with uplink and downlink flows 765 and 870 Kb/s during the period [20, 40] s, whereas downlink flow for periods [0, 20] s and [40, 60] s (before and after uplink flow was activated, respectively) reached 3.29 and 3.35 Mb/s, respectively. When we enabled NCR, downlink flow was protected, reaching 3.29, 3.08, and 3.35 Mb/s for periods [0, 20] s (downlink only), [20, 40] s (uplink flow 164 Kb/s), and [40, 60] s (downlink only), respectively.Figure 6
TCP throughput comparison between downlink and uplink flow.
(a)
Normal WLAN throughput (b)
NCR enabled WLAN throughputAs the second simulation study, we evaluated the NCR effectiveness for various uplink and downlink flows, aggregate downlink and uplink throughputs, and average end-to-end delay using the following simulation scenarios: (i) the total simulation time was 60 s; (ii) uplink and downlink flow were active throughout the entire simulation; (iii) the number of downlink flows was varying from 1 to 3, and the number of uplink flows was changing from 1 to 5; (iv) 10 simulation runs were conducted for each simulation configuration. Table1 compares indicative IEEE 802.11-based WLAN (normal WLAN) and NCR enabled WLAN cases. Downlink and uplink throughput values in the table are aggregate throughput over all the relevant flows, averaged over the 10 simulation runs. The outcomes are consistent with the previous simulation study: uplink flow severely degrades downlink flow, regardless of the number of uplink or downlink flows for normal WLAN conditions, but NCR effectively protects downlink flow.Table 1
Average uplink (UL) and downlink (DL) throughput for differently configured networks.
# of flows IEEE 802.11 WLAN NCR enabled WLAN DL UL DL (Mb/s) UL (Mb/s) DL (Mb/s) UL (Mb/s) 1 1 0.754 0.771 3.078 0.164 1 2 0.432 0.843 2.988 0.292 1 3 0.391 0.848 2.892 0.386 1 4 0.385 0.810 2.773 0.461 1 5 0.366 0.840 2.594 0.521 2 1 1.347 0.707 5.665 0.105 2 2 1.046 0.771 5.357 0.204 2 3 0.963 0.786 4.884 0.284 2 4 1.199 0.740 4.567 0.333 2 5 0.999 0.778 4.330 0.376 3 1 3.366 0.479 5.799 0.068 3 2 2.929 0.554 5.769 0.137 3 3 2.617 0.598 5.685 0.186 3 4 2.558 0.601 5.439 0.240 3 5 2.148 0.710 5.417 0.266Figure7 shows that NCR also positively influences overall network throughput and end-to-end delay. As shown in the figure, the aggregate network throughput for NCR was 2.58 times that for the normal WLAN case (Figure 7(a)). Also, average end-to-end delay for NCR was 6.85 times less than that for the normal WLAN case (Figure 7(b)).Figure 7
Aggregate throughput and end-to-end delay for differently configured networks.
(a)
Aggregate throughput (b)
End-to-end delay


### 4.1.2. Simulation Study with WiMAX

We implemented NCR in the WiMAX module of theOPNET simulator. To verify that the proposed NCR can efficiently manage the network for a long period of time, we conducted a simulation with much longer traffic period. The specific simulation settings were as follows: (i) the downlink station received data from the server during the period [10, 600] s; (ii) the uplink station started sending data to the server at 200 s and stopped at 400 s precisely. We allocated 25% capacity to uplink and the remaining 75% to downlink to ensure network asymmetry and data rate similar to reality. We used the WiMAX characteristics of Vividwireless [31, 32]. Downlink and uplink data rates were approximately 4.5 and 1.5 Mb/s, respectively.Figure8 shows throughput results. Similar throughput was achieved for the normal and NCR enabled WiMAX networks during the period [10, 200] s (no uplink traffic), 4.28 and 4.33 Mb/s, respectively. However, during [200, 400] s (active uplink traffic), normal WiMAX network performance was degraded to 1.52 Mb/s, whereas the NCR enabled network achieved 3.17 Mb/s.Figure 8
Comparison of WiMAX network throughputs.
(a)
Normal WiMAX network throughput (b)
NCR enabled WiMAX network throughputFigure9 shows TCP round trip times (RTT). As shown in the figure, the RTT of downlink traffic was reduced approximately 47% in NCR enabled WiMAX network. A notable point of the results is that RTT of the uplink traffic was also reduced (28%) when we enabled NCR. Since NCR usually dropped uplink packets and hence could shorten the uplink interface queue, downlink and uplink RTTs were both reduced.Figure 9
Comparison of round trip times (RTT) between normal and NCR enabled WiMAX networks.
(a)
Downlink traffic RTT (b)
Uplink traffic RTTFigure10 shows aggregate throughput for normal and NCR enabled WiMAX networks. NCR allowed more efficient use of the limited wireless network capacity, with aggregated throughput increasing approximately 28% compared to the normal WiMAX network.Figure 10
Aggregated throughput of normal and NCR enabled WiMAX networks.


### 4.1.3. Simulation Study with LTE

We performed the simulation study on LTE network which is the most advanced network withns-3. We employedns-3 LTE module of LENA project [33]. We used the same scenario as Section 4.1.2 except that downlink traffic was active [1, 50] s and uplink traffic was active [13, 39] s. We assigned 25 resource blocks to the uplink and 50 blocks to the downlink to ensure network asymmetry and data rate similar to reality. We used Verizon wireless network characteristics from [34]. Downlink and uplink data rates were approximately 30 and 15 Mb/s, respectively.Figure11 compares normal and NCR enabled network throughputs. NCR successfully regulated uplink and downlink traffic to protect mobile device downlink performance. Average downlink throughputs were 16.99 and 30.02 Mb/s during the period [13, 39] s for normal and NCR enabled LTE networks, respectively.Figure 11
Comparison of normal and NCR enabled LTE network throughputs.
(a)
Normal LTE network throughput (b)
NCR enabled LTE network throughputFigure12 compares aggregated throughputs of normal and NCR enabled LTE network. Similar to the previous simulation results, NCR achieved significantly more efficient link usage. Average aggregated throughputs were 31.36 and 36.19 Mb/s during the period [13, 39] s for normal and NCR enabled LTE networks, respectively. The normal LTE aggregated throughput does not show the sink behavior evident for the previously considered wireless networks. This is because LTE cells provide considerably more uplink bandwidth since many mobile phone applications require duplex communication, e.g., Skype and p2p torrent services. However, NCR still shows performance enhancement because the asymmetric bandwidth problem remains not fully resolved.Figure 12
Aggregated throughput of normal and NCR enabled LTE networks.Thus, the simulations confirm that the proposed NCR can successfully protect downlink traffic in WiMAX, LTE, and general asymmetric network architectures.


## 4.1.1. Simulation Study with IEEE 802.11

We implemented NCR in thens-2 simulation and subsequently improved the simulation by enabling multiple interfaces in IEEE 802.11-based WLANs and employing each interface as separate uplink and downlink channels. To ensure network bandwidth asymmetry, we set the downlink interface at 11 Mb/s and uplink interface at 1 Mb/s for both the mobile station and its associated AP. Downlink and uplink data rates were approximately 3.5 and 1 Mb/s, respectively.The first simulation study withns-2 used the following simulation scenario: (i) downlink traffic was active in the entire simulation period [0, 60] s; (ii) uplink traffic was started at 20 s and stopped at 40 s precisely. Figure 6 shows that throughput dynamics between downlink and uplink flow are strongly consistent with the testbed evaluation (Figures 1 and 2). Downlink flow is severely reduced in the presence of uplink flow, with uplink and downlink flows 765 and 870 Kb/s during the period [20, 40] s, whereas downlink flow for periods [0, 20] s and [40, 60] s (before and after uplink flow was activated, respectively) reached 3.29 and 3.35 Mb/s, respectively. When we enabled NCR, downlink flow was protected, reaching 3.29, 3.08, and 3.35 Mb/s for periods [0, 20] s (downlink only), [20, 40] s (uplink flow 164 Kb/s), and [40, 60] s (downlink only), respectively.Figure 6
TCP throughput comparison between downlink and uplink flow.
(a)
Normal WLAN throughput (b)
NCR enabled WLAN throughputAs the second simulation study, we evaluated the NCR effectiveness for various uplink and downlink flows, aggregate downlink and uplink throughputs, and average end-to-end delay using the following simulation scenarios: (i) the total simulation time was 60 s; (ii) uplink and downlink flow were active throughout the entire simulation; (iii) the number of downlink flows was varying from 1 to 3, and the number of uplink flows was changing from 1 to 5; (iv) 10 simulation runs were conducted for each simulation configuration. Table1 compares indicative IEEE 802.11-based WLAN (normal WLAN) and NCR enabled WLAN cases. Downlink and uplink throughput values in the table are aggregate throughput over all the relevant flows, averaged over the 10 simulation runs. The outcomes are consistent with the previous simulation study: uplink flow severely degrades downlink flow, regardless of the number of uplink or downlink flows for normal WLAN conditions, but NCR effectively protects downlink flow.Table 1
Average uplink (UL) and downlink (DL) throughput for differently configured networks.
# of flows IEEE 802.11 WLAN NCR enabled WLAN DL UL DL (Mb/s) UL (Mb/s) DL (Mb/s) UL (Mb/s) 1 1 0.754 0.771 3.078 0.164 1 2 0.432 0.843 2.988 0.292 1 3 0.391 0.848 2.892 0.386 1 4 0.385 0.810 2.773 0.461 1 5 0.366 0.840 2.594 0.521 2 1 1.347 0.707 5.665 0.105 2 2 1.046 0.771 5.357 0.204 2 3 0.963 0.786 4.884 0.284 2 4 1.199 0.740 4.567 0.333 2 5 0.999 0.778 4.330 0.376 3 1 3.366 0.479 5.799 0.068 3 2 2.929 0.554 5.769 0.137 3 3 2.617 0.598 5.685 0.186 3 4 2.558 0.601 5.439 0.240 3 5 2.148 0.710 5.417 0.266Figure7 shows that NCR also positively influences overall network throughput and end-to-end delay. As shown in the figure, the aggregate network throughput for NCR was 2.58 times that for the normal WLAN case (Figure 7(a)). Also, average end-to-end delay for NCR was 6.85 times less than that for the normal WLAN case (Figure 7(b)).Figure 7
Aggregate throughput and end-to-end delay for differently configured networks.
(a)
Aggregate throughput (b)
End-to-end delay


## 4.1.2. Simulation Study with WiMAX

We implemented NCR in the WiMAX module of theOPNET simulator. To verify that the proposed NCR can efficiently manage the network for a long period of time, we conducted a simulation with much longer traffic period. The specific simulation settings were as follows: (i) the downlink station received data from the server during the period [10, 600] s; (ii) the uplink station started sending data to the server at 200 s and stopped at 400 s precisely. We allocated 25% capacity to uplink and the remaining 75% to downlink to ensure network asymmetry and data rate similar to reality. We used the WiMAX characteristics of Vividwireless [31, 32]. Downlink and uplink data rates were approximately 4.5 and 1.5 Mb/s, respectively.Figure8 shows throughput results. Similar throughput was achieved for the normal and NCR enabled WiMAX networks during the period [10, 200] s (no uplink traffic), 4.28 and 4.33 Mb/s, respectively. However, during [200, 400] s (active uplink traffic), normal WiMAX network performance was degraded to 1.52 Mb/s, whereas the NCR enabled network achieved 3.17 Mb/s.Figure 8
Comparison of WiMAX network throughputs.
(a)
Normal WiMAX network throughput (b)
NCR enabled WiMAX network throughputFigure9 shows TCP round trip times (RTT). As shown in the figure, the RTT of downlink traffic was reduced approximately 47% in NCR enabled WiMAX network. A notable point of the results is that RTT of the uplink traffic was also reduced (28%) when we enabled NCR. Since NCR usually dropped uplink packets and hence could shorten the uplink interface queue, downlink and uplink RTTs were both reduced.Figure 9
Comparison of round trip times (RTT) between normal and NCR enabled WiMAX networks.
(a)
Downlink traffic RTT (b)
Uplink traffic RTTFigure10 shows aggregate throughput for normal and NCR enabled WiMAX networks. NCR allowed more efficient use of the limited wireless network capacity, with aggregated throughput increasing approximately 28% compared to the normal WiMAX network.Figure 10
Aggregated throughput of normal and NCR enabled WiMAX networks.


## 4.1.3. Simulation Study with LTE

We performed the simulation study on LTE network which is the most advanced network withns-3. We employedns-3 LTE module of LENA project [33]. We used the same scenario as Section 4.1.2 except that downlink traffic was active [1, 50] s and uplink traffic was active [13, 39] s. We assigned 25 resource blocks to the uplink and 50 blocks to the downlink to ensure network asymmetry and data rate similar to reality. We used Verizon wireless network characteristics from [34]. Downlink and uplink data rates were approximately 30 and 15 Mb/s, respectively.Figure11 compares normal and NCR enabled network throughputs. NCR successfully regulated uplink and downlink traffic to protect mobile device downlink performance. Average downlink throughputs were 16.99 and 30.02 Mb/s during the period [13, 39] s for normal and NCR enabled LTE networks, respectively.Figure 11
Comparison of normal and NCR enabled LTE network throughputs.
(a)
Normal LTE network throughput (b)
NCR enabled LTE network throughputFigure12 compares aggregated throughputs of normal and NCR enabled LTE network. Similar to the previous simulation results, NCR achieved significantly more efficient link usage. Average aggregated throughputs were 31.36 and 36.19 Mb/s during the period [13, 39] s for normal and NCR enabled LTE networks, respectively. The normal LTE aggregated throughput does not show the sink behavior evident for the previously considered wireless networks. This is because LTE cells provide considerably more uplink bandwidth since many mobile phone applications require duplex communication, e.g., Skype and p2p torrent services. However, NCR still shows performance enhancement because the asymmetric bandwidth problem remains not fully resolved.Figure 12
Aggregated throughput of normal and NCR enabled LTE networks.Thus, the simulations confirm that the proposed NCR can successfully protect downlink traffic in WiMAX, LTE, and general asymmetric network architectures.


## 4.2. Empirical Study

For the empirical study, we employed the testbed from Section2 and implemented NCR in the mobile station. Figure 13 shows the overall NCR software architecture and data flows at the Linux kernel function level. As discussed before, NCR can be implemented as a light interface layer between the IP and MAC layer. Therefore, to implement the layer, we created a virtual device driver and made hooking in dev_hard_start_xmit() function to perform packet queueing from IP layer to MAC layer (device driver). Then, we implemented NCR in the virtual device driver.Figure 13
Linux kernel architecture and function level flows.Figure14 shows empirical results from experiments using FileZilla andIperf as traffic generators. Downlink and uplink data rates were approximately 14 and 1 Mb/s, respectively. We employed the same evaluation scenarios described in Section 2. Cellular networks cannot protect downlink traffic from uplink traffic interference as discussed in Section 2. However, NCR secured downlink flow from uplink interference, with average 10.7 and 11.6 Mb/s for FileZilla andIperf through [60, 120] s (uplink and downlink traffic simultaneously enabled). Also, during the period [60, 120] s, average aggregated throughputs were 1.24 and 11.0 Mb/s for normal and NCR enabled devices with FileZilla traffic, respectively. Similarly, during that period, average aggregated throughputs were 1.28 and 11.7 Mb/s for normal and NCR enabled devices withIperf traffic, respectively. Substantially similar results were obtained when we used different combinations of uplink and downlink traffic and thus are omitted for brevity.Figure 14
Throughput comparison of downlink and uplink for the real testbed.
(a)
FTP traffic throughput for NCR enabled device (b)
Iperf traffic throughput for NCR enabled device


## 5. Related Work

Several previous studies have considered TCP performance degradation in asymmetric networks, but they have usually focused on wired or satellite networks. These solutions cannot be directly applied to cellular or Wi-Fi networks since mobile devices have limited computing power compared to wired stations. Hence, the solutions cannot be fully implemented within mobile devices. This section summarizes existing solutions for digital subscriber networks and relevant solutions to enforce fairness between the uplink and the downlink stations in WLANs.


### 5.1. Networked Control System Solutions

Recent trends in networked control and/or filtering systems emphasize network delay effects on the whole system. Rajesh et al. presented simple performance issues of TCP/IP data streams when cyber control was interconnected with physical entities over the network [35]. Zhang et al. surveyed sampling rate, network delay, packet dropping, and communication error effects on networked control [36].We have not attempted to compare the proposed NCR and these studies. The reasons are threefold: (i) they did not consider asymmetric uplink and downlink capacity assignments in cellular wireless network infrastructures from the mobile station view point; (ii) they simply focused on analytical modeling results under network operation assumptions; and (iii) NCR has already shown it can protect downlink traffic from uplink traffic interference, and hence no further enhancement in downlink usage is expected. The proposed NCR scheme can work with any current or future quality of service (QoS) schemes for mobile services or systems because NCR provides isolated uplink and downlink capacities for them. Thus, schemes using NCR can focus on service fairness or differentiation on top of guaranteed network performance.


### 5.2. Direct Solutions in Computer Networks

Some previous studies considered uplink or downlink TCP throughput degradation for asymmetric links, such as ADSL, cable, and satellite links. Solutions have mainly proposed maintaining separate TCP data and ACK packet queues [18, 19, 37]. TCP parameters have also been employed for the solution in [38], and queuing delay analysis has been exploited in [18]. Ho et al. proposed a TCP segment delay based solution to solve specific asymmetric link problems [38]. Xu et al. proposed preemptive ACK queueing to completely decouple queues and ensure ACKs no longer experience queueing delay by prioritizing ACK above TCP data [37]. Park et al. proposed ACKs-first variable-size queuing (AFVQ) to reduce excessive queuing delay for TCP ACK packets where TCP performance was degraded due to the asymmetric link [18]. They implemented the proposed AFVQ on a residential ADSL based testbed and showed that the proposed system achieved balanced TCP throughput improvements in both directions. Podlesny and Williamson proposed an asymmetric queuing mechanism to maximize the use of the bottleneck link in residential networks [19]. They showed that the proposed solution was easily deployed and configured in residential networks.Szilagyi and Vulkan proposed an evolved Node B (eNB) based solution called TcpAsym, by packing an additional entity [20]. TcpAsym controls each user equipment (UE) that might contain multiple TCP flows. The entity monitors downlink traffic flow to detect abnormal behavior due to excessive uplink data flow. When asymmetric behavior is identified, it either decreases the uplink traffic congestion window size or delays uplink ACK transmission or uplink data reception. Priya and Murugan proposed a dual queue approach similar to multiqueue approaches in previous studies but applied optimization schemes for queue size and packet scheduling on each queue [21].


### 5.3. Indirect Solutions Based on Computer Network Fairness

Several previous studies focused on fairness between downlink and uplink flows in Wi-Fi networks. The main approaches are classified into TCP, MAC, and queue solutions.As for TCP solutions [25, 26], they allowed an AP to directly handle TCP layer information, such as TCP congestion window size. Zhang et al. constrained TCP sending rate of each uplink mobile node in order to make uplink and downlink flows share bandwidth fairly [25]. Jian et al. proposed another solution that makes an AP directly control TCP traffic whenever the AP detects unfairness between uplink and downlink TCP flows [26].Mahmoodi et al. [39] and Wang [40] exploited MAC protocol parameters to enforce the fairness among stations. Mahmoodi et al. proposed an orthogonal frequency-division multiple access (OFDMA) system solution to not only achieve optimal TCP throughput but also allocate resources fairly between downlink and uplink [39]. Wang proposed a cross layer adaptive algorithm that dynamically controls the AP minimum contention window size according to the number of users and channel conditions [40]. Nayak et al. analyzed IEEE 802.11ac operated wireless LAN behavior with downlink multiuser MIMO enabled at the access point and showed significant performance degradation [24]. They proposed a method to resolve the degradation, achieving the theoretical TCP traffic limit for the network.Various solutions have been proposed based on queue management and rate control schemes [17, 41–43]. Hayashi et al. proposed a buffer management scheme that deals with the transmission buffer of the AP to solve unfairness, where the AP removes redundant ACKs in the transmission buffer [41]. Wu et al. implemented a per-flow scheduling scheme with separate TCP data and TCP ACK queues at AP level to achieve per-flow fairness [42]. Huang et al. suggested a queue allocation boundary for the number of ACKs to limit ACK packet greedy behavior that can impair coexisting TCP flow fairness [43]. Xia et al. proposed a dual queue management scheme that maintains different queues for uplink and downlink flows to achieve both fairness and high utilization [17]. Shaik et al. proposed a system that utilizes the hybrid coordination function controlled channel access (HCCA) scheduler for 802.11e Wireless LANs [44]. In contrast to previous studies, the proposed system focused on relative fairness differentiated by required QoS for each service type.Finally, cross-layer solutions consider TCP and MAC control parameters simultaneously to address problems arising from TCP and MAC interactions [45].


### 5.4. Remark

The proposed NCR differs from all the above solutions in that (i) it does not maintain separate queues for TCP data and TCP ACK packets, (ii) it does not directly manipulate TCP parameters or MAC parameters, (iii) it does not rely on active queue management, (iv) it does not depend on any function installed onto a base station, and (v) it directly considers cellular network technologies.Additionally, the proposed NCR solution also has several advantages in that (i) it directly addresses asymmetric uplink and downlink capacity assignments and protects downlink traffic from uplink traffic interference, (ii) when multiple heterogeneous network interfaces are enabled in mobile devices or systems, NCR can isolate downlink from uplink traffic and thus enable any QoS scheme to be implemented on top of multiple networks, and (iii) NCR can differentiate multiple flows according to service quality requirements by changing the weight (φi) for each flow.


## 5.1. Networked Control System Solutions

Recent trends in networked control and/or filtering systems emphasize network delay effects on the whole system. Rajesh et al. presented simple performance issues of TCP/IP data streams when cyber control was interconnected with physical entities over the network [35]. Zhang et al. surveyed sampling rate, network delay, packet dropping, and communication error effects on networked control [36].We have not attempted to compare the proposed NCR and these studies. The reasons are threefold: (i) they did not consider asymmetric uplink and downlink capacity assignments in cellular wireless network infrastructures from the mobile station view point; (ii) they simply focused on analytical modeling results under network operation assumptions; and (iii) NCR has already shown it can protect downlink traffic from uplink traffic interference, and hence no further enhancement in downlink usage is expected. The proposed NCR scheme can work with any current or future quality of service (QoS) schemes for mobile services or systems because NCR provides isolated uplink and downlink capacities for them. Thus, schemes using NCR can focus on service fairness or differentiation on top of guaranteed network performance.


## 5.2. Direct Solutions in Computer Networks

Some previous studies considered uplink or downlink TCP throughput degradation for asymmetric links, such as ADSL, cable, and satellite links. Solutions have mainly proposed maintaining separate TCP data and ACK packet queues [18, 19, 37]. TCP parameters have also been employed for the solution in [38], and queuing delay analysis has been exploited in [18]. Ho et al. proposed a TCP segment delay based solution to solve specific asymmetric link problems [38]. Xu et al. proposed preemptive ACK queueing to completely decouple queues and ensure ACKs no longer experience queueing delay by prioritizing ACK above TCP data [37]. Park et al. proposed ACKs-first variable-size queuing (AFVQ) to reduce excessive queuing delay for TCP ACK packets where TCP performance was degraded due to the asymmetric link [18]. They implemented the proposed AFVQ on a residential ADSL based testbed and showed that the proposed system achieved balanced TCP throughput improvements in both directions. Podlesny and Williamson proposed an asymmetric queuing mechanism to maximize the use of the bottleneck link in residential networks [19]. They showed that the proposed solution was easily deployed and configured in residential networks.Szilagyi and Vulkan proposed an evolved Node B (eNB) based solution called TcpAsym, by packing an additional entity [20]. TcpAsym controls each user equipment (UE) that might contain multiple TCP flows. The entity monitors downlink traffic flow to detect abnormal behavior due to excessive uplink data flow. When asymmetric behavior is identified, it either decreases the uplink traffic congestion window size or delays uplink ACK transmission or uplink data reception. Priya and Murugan proposed a dual queue approach similar to multiqueue approaches in previous studies but applied optimization schemes for queue size and packet scheduling on each queue [21].


## 5.3. Indirect Solutions Based on Computer Network Fairness

Several previous studies focused on fairness between downlink and uplink flows in Wi-Fi networks. The main approaches are classified into TCP, MAC, and queue solutions.As for TCP solutions [25, 26], they allowed an AP to directly handle TCP layer information, such as TCP congestion window size. Zhang et al. constrained TCP sending rate of each uplink mobile node in order to make uplink and downlink flows share bandwidth fairly [25]. Jian et al. proposed another solution that makes an AP directly control TCP traffic whenever the AP detects unfairness between uplink and downlink TCP flows [26].Mahmoodi et al. [39] and Wang [40] exploited MAC protocol parameters to enforce the fairness among stations. Mahmoodi et al. proposed an orthogonal frequency-division multiple access (OFDMA) system solution to not only achieve optimal TCP throughput but also allocate resources fairly between downlink and uplink [39]. Wang proposed a cross layer adaptive algorithm that dynamically controls the AP minimum contention window size according to the number of users and channel conditions [40]. Nayak et al. analyzed IEEE 802.11ac operated wireless LAN behavior with downlink multiuser MIMO enabled at the access point and showed significant performance degradation [24]. They proposed a method to resolve the degradation, achieving the theoretical TCP traffic limit for the network.Various solutions have been proposed based on queue management and rate control schemes [17, 41–43]. Hayashi et al. proposed a buffer management scheme that deals with the transmission buffer of the AP to solve unfairness, where the AP removes redundant ACKs in the transmission buffer [41]. Wu et al. implemented a per-flow scheduling scheme with separate TCP data and TCP ACK queues at AP level to achieve per-flow fairness [42]. Huang et al. suggested a queue allocation boundary for the number of ACKs to limit ACK packet greedy behavior that can impair coexisting TCP flow fairness [43]. Xia et al. proposed a dual queue management scheme that maintains different queues for uplink and downlink flows to achieve both fairness and high utilization [17]. Shaik et al. proposed a system that utilizes the hybrid coordination function controlled channel access (HCCA) scheduler for 802.11e Wireless LANs [44]. In contrast to previous studies, the proposed system focused on relative fairness differentiated by required QoS for each service type.Finally, cross-layer solutions consider TCP and MAC control parameters simultaneously to address problems arising from TCP and MAC interactions [45].


## 5.4. Remark

The proposed NCR differs from all the above solutions in that (i) it does not maintain separate queues for TCP data and TCP ACK packets, (ii) it does not directly manipulate TCP parameters or MAC parameters, (iii) it does not rely on active queue management, (iv) it does not depend on any function installed onto a base station, and (v) it directly considers cellular network technologies.Additionally, the proposed NCR solution also has several advantages in that (i) it directly addresses asymmetric uplink and downlink capacity assignments and protects downlink traffic from uplink traffic interference, (ii) when multiple heterogeneous network interfaces are enabled in mobile devices or systems, NCR can isolate downlink from uplink traffic and thus enable any QoS scheme to be implemented on top of multiple networks, and (iii) NCR can differentiate multiple flows according to service quality requirements by changing the weight (φi) for each flow.


## 6. Conclusion

This paper showed that downlink TCP traffic suffers from performance degradation due to asymmetric links in current cellular networks. We showed experimentally that TCP ACK packets were delayed on the uplink when uplink traffic overruns the available bandwidth, causing inefficient use of the available downlink bandwidth. We proposed the network traffic chunk regulator (NCR) feedback control scheme regulating downlink and uplink traffic in preference of downlink traffic in the congested uplink interface. We implemented NCR for various simulations and also on a Linux platform equipped with two physical wireless interface cards. Simulation and experimental performance evaluations consistently verified that NCR protected downlink TCP traffic from uplink TCP traffic interference. Thus, the proposed NCR scheme can effectively secure downlink traffic against aggressive uplink traffic, significantly increasing total link utilization, and aggregated throughput. Furthermore, NCR does not impose additional overhead on base or mobile stations.This study focused on resolving significant downlink degradation due to relatively small uplink traffic volumes in asymmetric links. The proposed NCR scheme regulates downlink and uplink traffic at the mobile device’s uplink interface, which could degrade uplink traffic volume. However, downlink performance improvement is much larger than the potential uplink degradation. Hence, in principle, NCR would increase total link utilization and aggregated throughput, and this was verified by simulation and experiments. For cases where uplink traffic should be preserved, the user can ensure uplink network quality by simply decreasing the NCR feedback value. In addition to the cases, for crowded places with a lot of social activity, the uplink traffic may exceed the downlink traffic, since many people in the places often share videos of events using social networking applications. Thus, to take into account such various situations, we plan to conduct a research on dynamically adjusting control parameters of NCR in future work.



---

*Source: 1283420-2018-07-12.xml*