enhanced rmcat prot ocol for video streaming over … · enhanced rmcat prot ocol for video...

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.


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


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)


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


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


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.


1926

enhanced rmcat prot ocol for video streaming over … · enhanced rmcat prot ocol for video...

Documents