ENHANCED RMCAT PROTOCOL FOR VIDEO STREAMING
OVER WLAN
Mohanapriya C1, Govindarajan J
2*
1,2Dept. of Computer Science and Engineering, Amrita School of Engineering, Coimbatore,
Amrita Vishwa Vidyapeetham, India
e-mail: [email protected], [email protected]*
ABSTRACT:The video streaming is one of the important application which consumes more bandwidth
compared to non-real-time trafficlike FTP traffic. Real-Time Media Congestion Avoidance Technique (RMCAT)
is one of the recently proposed frameworks to provide congestion control for real-time applications. In our
study we have identified some of the problems of RMCAT likethe variation in sending rate due to RTT variation
(i.e., variation in propagation delay), unnecessarily reduction in sending rate, blocking of flows. In this paper,
the enhanced RMCAT protocol has been proposed to address the problems of RMCAT and to add the media
friendliness to the RMCAT. The performance of enhanced RMCAT has been verified using a set of simulation
experiments.
Keywords: Video streaming, RMCAT, WLAN, TFRC, congestion
1. INTRODUCTION
Nowadays, Media friendliness is considered to be an important factor along with TCP-
friendliness for the design of video transmission over wired or wireless LAN.A flow is called as TCP-
friendly if it fairly shares the bandwidth with TCP flows. In contrast media friendliness considers the
characteristics of streaming media and provides the streaming media with uninterrupted transport
services.Some of the media characteristics that are also to be considered for the evolution of the
transmission rate are the peak signal-to-noise ratio (PSNR), burstiness, client buffer fill level, etc [1].
Hence, the sending rate of the video transmission should be controlled based on the level of
congestion and media quality. Also, the available bandwidth should be shared with TCP flows fairly.
Most of the real-time applications are using RTP (Real-time Transport Protocol) to provide
the end-to-end delivery of audio and video transmission [2]. This protocol will work based on the
UDP protocol for the multiplexing and the checksum services. Some of the common real-time
applications arevideo conferencing, video streaming, etc. While streaming the video over wired
network or wireless network, the packets of video frames may get lost before reaching the receiver
due to congestion inside the network. To avoid the packets losses due to congestion, many congestion
control algorithmshave been proposed. TFRC (TCP Friendly Rate Control) [3]is one of the main
protocol which provides TCP-friendliness and smooth sending behavior. Recently RMCAT [4] has
been proposed to provide congestion control to the real-time applications. In comparison to TFRC, it
considers the delay in addition to the loss ratio to calculate the sending rate. UTFRC [5]is an extended
version of TFRC to provide the media-friendliness over the TFRC flows.
Most of the TCP based internet applications were designed for a wired network. Later
performance degradation has been observed for these applications when they were migrated to
WLAN. The unfairness, reordering,and error are the main causes of this performance degradation [6]
[7].Streaming of the video is one of the importantapplications over WLAN after the introduction of
IEEE 802.11ac. In [8], the authors have compared 802.11ac and 802.11n standards. As per their
results, they have shown that IEEE 802.11ac provides higher throughput using channel bandwidth of
International Journal of Pure and Applied MathematicsVolume 119 No. 17 2018, 1919-1927ISSN: 1314-3395 (on-line version)url: http://www.acadpubl.eu/hub/Special Issue http://www.acadpubl.eu/hub/
1919
80MHz or 40MHz with four spatial streams while compared to the IEEE 802.11n. In [9], the authors
have shown that the performance of IEEE 802.11ac will decline when channel conditions are changed
or distance between the sender and receiver increases.
The main aim of this paper is to propose the enhanced RMCAT protocol and to add media-
friendliness using the functions defined by UTFRC over WLAN. Rest of the paper is organized as
follows: The summary of existing protocols for real-time applications is presented in Section 2.
Section 3 describes the proposed work of the enhanced RMCAT protocol. The performance analysis
of the enhanced RMCAT over WLANis presented in Section 4. Finally, Section 5 concludes the
design and performance analysis of our work and also gives the future directions.
2. EXISTING WORK
TFRC (TCP- Friendly Rate Control)protocol was designed to provide congestion control for
real-time applications. TFRC is a receiver based mechanism which detects the congestion and
calculates the loss ratioat the receiver side rather than sender side [3]. TFRC can also be used as a
sender side mechanism, which has been allowed in Datagram Congestion Control Protocol.While
comparing with TCP, TFRC has a lower variation of throughput. Hence it is more suitable for
streaming the video, with smooth sending rate.
Even though TFRC provides the congestion control, it onlyuses the packet loss ratio for the
calculation of the sending rate[3]. But the recently proposed RMCAT protocol has considered both
loss and delay for the calculation of sending rate [10].As per the design, RMCAT framework consists
of Media encoder, Sender, NADA Controller ad Receiver. The Media encoder splits thevideo frames
into data chunks according to the sending rate, which will then sent as a packet to the RTP sender.
The output rate of the encoder may get fluctuated while comparing with the target rate. The RTP
sender will receive the feedback report from the receiver which carries the congestion control
parameters (i.e., loss and delay).These parameters will be used by the NADA controller to calculate
the reference sending rate. Then, using reference rate the RTP sender updates the target rate of the
Media Encoder. Each packet from the sender carries the timestamp to calculate the RTT between the
sender and the receiver. RTP sender will also regulate the sending rate according to the reference rate.
RTP receiver will calculate the end-to-end delay, packet losses, receiving rate (r_recv) and the ECN
(Explicit Congestion Notification) marking ratio of the flow. The receiver also calculates the
aggregate congestion signal (x_curr) which reflects the loss of packets, queuing delay and ECN
marking ratio. As per the observation of packet loss ratio, the receiver will beeither in accelerated
ramp-up mode or gradual rate mode. The receiver will send the RTCP report periodically to the
sender. The RTCP report contains the r_recv, x_curr,andrmode(receiver mode) values.
UTFRC (Utility-driven TCP- Friendly Rate Control) protocolis the extended version of the
TFRC which provides media-friendliness while compared to the TFRC protocol.UTFRC has defined
the utility function to adjust the transmission rate according to the media characteristics. TFRC is
smoother in the transmission of video and hence it is not suitable forvariable encoding rate videos. In
contrast,the UTFRC changes the sending rate according to the media characteristics and hence itis
more suitable for the variable encoding rate codec than TFRC.
RMCAT has recently proposeda protocol to improve the performance of real-time
applications over a congested network and better than TFRC and UTFRC. However, the media
friendliness is not considered in the design of RMCAT. Recently, the video streaming is one main
application of 802.11ac. Hence, in our previous work we have done the detailed study on the
performance of RMCAT over recent WLAN 802.11ac and few problems of RMCAT are observed.
The study was focused on the impact of various network level parameters (like the distance between
International Journal of Pure and Applied Mathematics Special Issue
1920
the AP and the stations, packet size, maximum sending rate, number of stations and resolutions)over
the sending rate and receiving a rate of the video.
3. PROPOSED WORK
In this section, we describe the problems of RMCAT over WLAN which are observed in
previous work and the solutions to address those problems. These solutions are incorporated in the
RMCAT andalso media-friendly utility function defined by UTFRC is added to our modified
RMCAT to achieve the enhanced media-friendly congestion control protocol for video streaming.
3.1 Media-Friendliness over RMCAT
The RMCAT is designed to provide congestion control and hence the sending rate calculated
by the NADA controller will be taken the sending rate for the transmission. In contrast, UTFRC was
designed with media friendliness. In our enhanced RMCAT protocol, the media-friendly function
defined by UTFRC is integrated with RMCAT to achieve the enhanced media-friendly congestion
control for real-time applications. As per our modification, the sending rate calculated by the NADA
controller will be multiplied with media-friendly function. We considered the ratio of the current bit
rate to the average bit rate of the video as the media-friendly function. The modified equation of the
RMCAT sending rate is,
Sending rate = sending rate of NADA Controller X bitrate for current t seconds
average bitrate (1)
3.2 Avoiding performance variation due to the RTT variation
As per the design of RMCAT, the flow with the same RTT and same loss ratio will achieve
the same bandwidth. However, the flows with different RTTs due to the difference in propagation
delay will differ in achieved bandwidth. This is due to the calculation of reference rate using the
absolute value of RTT. In ramp-up mode, the reference rate is inversely proportional to RTT (refer
equations 2 and 3). Hence the flow with low RTT will reach high sending rate faster than the flow
with high RTT. To avoid this problem, in our modified RMCAT, the absolute value of RTT is
replaced bythe relative value of RTT. The modified RMCAT sender updates the minimum RTT of the
flow after receiving each feedback message. Instead of applying the absolute value of RTT, the
difference between the current sample (RTT) and minimum RTT (RTTmin) will apply in the equation.
The minimum RTT refers to the propagation delay, transmission delay,and minimum processing
delay. The difference between current RTT and minimum RTT refers to the delay due to congestion
inside the network. The modified equation of our enhanced RMCAT is shown in equation 4. When
the equation 2 of RMCAT is replaced by equation 4 of our enhanced RMCAT, gamma will be same
for both high propagation delay and low propagation delay flows, hence they will acquire same
bandwidth.
gamma = min GAMMAMAX ,QBOUND
rtt + DELTA+ DFILT (2)
r_ref = max(r_ref, 1 + gamma r_recv) (3)
gamma = min GAMMAMAX ,QBOUND
(rtt − rttmin ) + DELTA+ DFILT (4)
3.3 Avoiding unnecessary reduction in sending rate due to few packet losses
RMCAT NADA controller will work in two modes, one is accelerated ramp-up mode and
another one is gradual rate mode. Initially, the NADA controller will work in the accelerated mode.
International Journal of Pure and Applied Mathematics Special Issue
1921
Once there is a packet loss, then the gradual rate mode will be invoked. As per the implementation,
NADA will enter into the gradual rate modeeven if there is a single packet loss has been observed and
due to this, the sending rate will be reduced. In our proposed protocol, the condition is modified with
the loss threshold, i.e., the controller will enter into the gradual rate mode only when the count of
packet losses reaches the loss threshold.This modification will reduce the unnecessary reduction in
sending rate due to the few packet losses. The loss threshold will be decided based on the network
condition and the channel condition.
3.4 Reduction in sending rate due to the mobility of the nodes or reduction in sending rate due
to other blocking flows
When the flows are originated from the same node, one flow may block the transmission of
other flows. In our study, we observed that the flows which are towards the faraway nodes have
blocked the transmission of other flows. We also observed that the packets for the long distance nodes
are waiting inside the MAC level queue fora longer time to receive the reply for ARP request. These
packets are blocking the transmission of other flows. Also, the packets which are sending towards the
long distance nodes may drop frequently. Hence, in our proposed protocol, the sender will identify the
blocking flows based on the difference between two consecutive arrivals of RMCAT feedback. The
flows which are not received the feedback message for a long period of time are considered as
blocking flows. Hence, the sender will stop the transmission of these flows to avoid the blocking of
other flows and also to utilize the available bandwidth for other flows.
4. PERFORMANCE ANALYSIS OF ENHANCED RMCAT
To study the performance of enhanced RMCAT, a grid topology with varying number of
nodes and the varying distance between the nodes. The various configuration parameters of our
experiments are summarized in Table 1.The MCS (Modulation and Coding Scheme) of 802.11ac is
configured as 4 with a channel width of 20MHz. YansErrorRateModel is considered to simulate the
channel with a transmission error. In all experiments, the AP (Access Point) sends a video to the
stations.
Table 1: Configuration Parameters
Initially, the experiment is conducted with 10 nodes which are at the distance of 10m in a grid
topology. The topology and the results of our first experiment are presented in Figure 1 and Figure 2
respectively. In this experiment, we observed near-zero packet loss in transmission. The results show
that exiting RMCAT sender increases the sending rate initially and maintains the same sending rate
after reaching the maximum rate of 1500kbps. In contrast, the sending rate of enhanced RMCAT is
varying according to video rate.Since the existing RMCAT considers only the congestion, the sender
uses the sending rate calculated by the NADA controller to configure the transmission rate of
Parameter Values
MCS 4
Channel Width 20MHz
Guard Interval Short guard interval
Error Model YansErrorRatemodel
Number of Nodes 5, 10
The distance between the Nodes 10m, 30m
Packet size 1000bytes
The configured maximum rate of video
transmission
1500Kbps
Resolution of video Fixed encoding(360p)
Protocol RMCAT, Enhanced RMCAT
International Journal of Pure and Applied Mathematics Special Issue
1922
videopackets. Our enhanced RMCAT protocol usesa media-friendlyfunction defined by UTFRC;
hence, the sending rate calculated by the controller is multiplied with the media-friendly function as
shown in equation1.
Figure 1: Grid Topology of 10m distance with 10 nodes
(a) Sending rate of RMCAT (b) Sending rate of Enhanced RMCAT
Figure 2: Sending Rate of RMCAT and Enhanced RMCAT over the WLAN with 10 nodes and the
distance between the nodes is 10m
To study the performance of the protocol with mobility and distance, the distance between the
nodes is increased to 30m. The second experiment is carried out for the topology with 5 nodes
positioned at the distance of 30m (Refer Figure 3). The performance of the existing RMCAT NADA
controller and the proposed enhanced RMCAT NADAUTFRC controller are shown in Figure 4 and
Figure 5 respectively. Out of five stations (STA), the flows originating from AP to STA 0 and 3
(faraway stations) are the blocking flows i.e., the flows are blocking the transmission of other flows.
Figure 4 shows that flows to STA 1,2 and 4 were started with an initially configured minimum
bandwidth of 200kbps and the same rate last for first 140 seconds. Then, they were reached maximum
rate only after 170 seconds. i.e., the transmissions of flows to these stations were blocked by the flows
to STA 0 and 3. In contrast, our enhanced RMCAT detects these blocking flows and stops these
blocking flows at 80 seconds. i.e., since the feedback was not received for the first 80 seconds these
flows are designated as blocking flows. Hence, the other flows (flows to STA 1, 2 and 4) were able to
reach the maximum rate after 80 seconds. Our enhanced RMCAT helps the sender to reach a
maximum transmission rate earlier than(90 seconds) RMCAT. Also, the calculated sending rate is
adjusted to video rate (Refer Figure 5).Since transmission of packets to STA 0 and 3(faraway stations)
International Journal of Pure and Applied Mathematics Special Issue
1923
are temporarily stopped, the unnecessary attempts for the transmission of the packets are avoided.
Also, the bandwidth has been utilized for other flows.
Figure 3: Grid Topology of 30m distance with 5 nodes
(a) NADA controller sending rate (b) Sender Sending rate
(c) Receiver rate
Figure 4:Performance of RMCATover the WLAN with 5 nodes and the distance between the nodes is
30m
(a) NADA controller Sending rate (b) Sender Sending rate
International Journal of Pure and Applied Mathematics Special Issue
1924
(c) Receiver rate
Figure 5: Performance of Enhanced RMCAT over the WLAN with 5 nodes and the distance between
the nodes is 30m
Finally, the experiment is conducted for the topology with 5 nodes arranged at a distance of
10m. Theresults of an experiment with this topology are presented in Figure 6. In contrast to the
RMCAT, our proposed protocol has reduced the number of unnecessary reduction in the sending rate.
(a) NADA controller sending rate (b)Sender Sending rate
(c) Receiver Receiving rate
Figure 6: Enhanced RMCAT NADA-UTFRC Controller sending rate, Sender Sending rate and
Receiver Receiving rate at distance of 10m and 5 nodes
International Journal of Pure and Applied Mathematics Special Issue
1925
CONCLUSION
In this paper, an enhanced RMCAT protocol has been proposed to consider the media-
friendliness for video transmission and to avoid the performance degradation caused by RTT
variations, unnecessary reduction in sending rate due to few packet losses and the reduction in
sending rate due to the mobility of the nodes or other blocking flows. As a future work,the enhanced
RMCAT can be tested for other types of real-time flows like audio. In our proposed work, only the bit
rate ratio of the video is considered as the quality metric. Hence, other media characteristics like
PSNR, MoS also be considered for the design of media-friendly congestion control protocol.
REFERENCES
[1] Sterca, A., Hellwagner, H., Boian, F., Vancea. “A.: Media-friendly and TCP-friendly rate
control protocols for multimedia streaming”, IEEE Transactions on Circuits and Systems
for Video Technology 26(8), 1516–1531 (2016)
[2] Schulzrinne, H., Casner, S., Frederick, R., and V.Jacobson."RTP: A Transport Protocol for
Real-Time Applications",RFC 3550, July 2003.
[3] S. Floyd, M. Handley, J. Padhye, J. Widmer. “TCP friendly rate control (TFRC): protocol
specification”, in IETF RFC 5348, September 2008.
[4] X. Zhu, Z. Sarker.“Framework for Real-time Media Congestion Avoidance Techniques”,
Internet- Draft, July. 2016.
[5] A. Sterca. “UTFRC—Utility-driven TCP-friendly rate control for multimedia streams”,
inProc. 17th Euromicro International Conference, pp. 167–172, Feb. 2009.
[6] Govindarajan, J., N. Vibhurani, and G. Kousalya. "Enhanced TCP NCE: A Modified Non-
Congestion Events Detection, Differentiation and Reaction to Improve the End-to-End
Performance Over MANET", Progress in Intelligent Computing Techniques: Theory,
Practice, and Applications. Springer, Singapore, 2018. 443-454.
[7] Govindarajan J, Devi G A, and Kousalya G. “Analysis of TCP- unfairness from MAC layer
perspective in wireless Ad-hoc networks”, Indian Journal of Science and Technology, vol. 8,
2015.
[8] Adian Fatchur Rochim , Riri Fitri Sari, “Performance Comparison of IEEE 802.11n and
IEEE 802.11ac”, International Conference on Computer, Control, Informatics and its
Applications, 2016.
[9] Dianu, Mihaela-Diana, Janne Riihijärvi, and Marina Petrova. "Measurement-based study of
the performance of IEEE 802.11 ac in an indoor environment", Communications (ICC),
2014 IEEE International Conference on. IEEE, 2014.
[10] X. Zhu, R. Pan, M. Ramalho, S. Mena, P. Jones. J. Fu and S D’ Aronco, “NADA: A Unified
Congestion Control Scheme for Real-Time Media”, Internet- Draft, 2017.
International Journal of Pure and Applied Mathematics Special Issue
1926
1927
1928