Secure and Seamless Video Streaming using Randomized Dispersive Routes over Wireless Networks

Secure and Seamless Video Streaming using Randomized Dispersive Routes over Wireless Networks

P. Yuvarani

PG Scholar,

Department of Computer Science and Engineering, Institute of Road and Transport Technology, Erode, India.

Dr. S. Kalaivani

Assistant Professor,

Department of Computer Science and Engineering, Institute of Road and Transport Technology, Erode, India.

Abstract – This paper presents a multipath over different wireless networks using Multipath Multimedia Transport Protocol (MPMTP). The aim is to provide a flawless high quality video streaming service by using multipath wireless networks simultaneously. In MPMTP, by using Raptor code algorithm the video quality degradation will be reduced which is caused by wireless channel errors such as attenuation loss, signal-to-noise ratio, and traffic load. Raptor code algorithm used to avoid a head-of-line blocking problem in multipath environments and take care of video packet transmission over multipath wireless networks by using encoding and decoding complexity and receiver buffer occupancy. MPMTP performs packet scheduling algorithm, by considering wireless condition for smooth video playback. TCP-Friendly Rate Control (TFRC) is designed for best performance with applications such as streaming media where a relatively smooth sending rate is of importance in response to congestion. TFRC ensures acceptable video quality for multipath transmission over noisy wireless channels by using selective retransmission scheme.

Keywords MPMTP, Wireless Networks, Raptor Codes, Packet Scheduling, TFRC.

1. INTRODUCTION

   For the past 15 years, Video streaming service over wireless networks has been rapidly increasing. This video streaming service over wireless networks is available at anytime and anywhere. In this video streaming service, resources are very limited in wireless networks compared to wired networks. To reduce the amount of data being transferred, it is vital to employ effective video compression algorithms. Video streaming is very vulnerable to transmission errors and losses because of its extremely high compression ratio. This makes the problem of supporting flawless high-quality video streaming services over wireless networks more challenging. To solve this problem, Internet engineering task force (IETF) has proposed Multipath Transmission Control Protocol (MPTCP) to improve network throughput and enhance Quality of Service (QoS). However, the performance of MPTCP is somewhat lower than expected in the presence of diverse network conditions [1]. Moreover, Transmission Control Protocol (TCP) is not appropriate for real-time video streaming services because retransmission of lost packets incurs a large delay. User Datagram Protocol (UDP) is light weight and fast, but it does not provide reliable

   communication. When using UDP for video streaming, the video quality may be degraded since it is very vulnerable to packet losses due to its high degree of compression. Forward error correction (FEC) codes are one solution to provide reliable communication.

   TFRC is designed for unicast applications, such as multimedia streaming in the best-effort Internet environment. However, high bandwidth networks with large delays present an environment where TFRC may have a problem in utilizing the full bandwidth. TFRC inherits the slow-start mechanism of TCP Reno, but this is a time-consuming process that may require many Round-Trip times (RTTs), until an appropriate sending rate is reached. Another disadvantage inherited from TCP Reno is the RTT-unfairness problem, which severely affects the performance of long-RTT flows.

2. BACKGROUND AND RELATED WORK

   Raptor code is used to increase the overall throughput and improve the video quality. This code determines the number of source symbols and the symbol size which parameters have a great influence on goodput, minimum symbol overhead, and error robustness. Raptor code applied on the video packets for error resiliency which permits packets to be sent or resent on any available path and combines the video packets inorder to increase the packet diversity in the network. The total goodput of Raptor codes is dramatically changing according to the number of source symbols and the symbol size. Based on the number of source symbols and the symbol size of the video packet, the total goodput of the raptor code will be change. At the time of increased transmission delay and increased complexity for Raptor encoding and decoding as the number of source symbols increases, then the minimum symbol overhead becomes smaller, if the symbol size is same. The error robustness against packet losses can be enhanced at the cost of increased transmission delay and increased complexity for Raptor encoding and decoding as the symbol size increases when the number of source symbols is fixed.

   When the symbol size is equal to a packet size, then the error robustness will achieve best performance.TFRC is used to avoid the potential threat of the internet and to increase the quality of video streaming service. TFRC uses TCP Reno

   which adjusts the transmission rate of the application and this transmission rate computes packet loss event rate, round trip time (RTT) and packet size. TCP Reno avoids blunt variations in transmission rate, especially for video streaming applications. TFRC uses slow start mechanism to balance the speed of network connection and determines an appropriate transmission rate which regulates bandwidth to prevent the sender from having to continuously retransmit data. Slow start mechanism gradually increase the amount of data transmitted until it finds the networks maximum carrying capacity.TFRC inherits the slow-start mechanism of TCP Reno, but this is a time-consuming process that may require many round-trip- times (RTTs), until an appropriate sending rate is reached. A long time will be taken by the sender to fully utilize the bandwidth on a path, if RTT is large. This will result in low quality video for a few seconds, which degrades the quality of user experience. Also gradual increase in transmission rate will result in multiple packet drops for one RTT, especially in high bandwidth networks.

   A. Related Work

   A multipath transport protocol aims to improve the performance of a multi-path ow and proposed to efficiently deliver data over networks. i.e. to be atleast as good as a single-path ow on the best route, without consuming on any path more capacity than a single-path ow. Stream Control Transmission Protocol (SCTP) supports simultaneous use of several paths and allows the video streaming to control the access interface selections on a datagram stream basis. To improve network throughput and to enhance QOS, IETF standardized the design and implementation of MPTCP providing the ability to simultaneously use multiple paths between peers. However, when some of these multiple paths exhibit a bad network status (i.e., long delay, high packet loss, or low bandwidth), MPTCP suffers from a degradation in throughput [3]. This is because packets can arrive out-of-order due to diverse network conditions, so this phenomenon can incur a head-of-line blocking problem. To overcome this problem, a Congestion Window Adaptation MPTCP (CWA- MPTCP) has been proposed. CWA-MPTCP dynamically adjusts the congestion window for each TCP subflow, thus mitigating the variation of end-to-end delay. CWA-MPTCP can alleviate a head-of-line blocking problem by minimizing the path delay difference. Heterogeneous Multipath Transport Protocol (HMTP), using fountain codes to improve the throughput performance and path utilization of heterogeneous multihoming networks [1]. HMTP keeps encoding and sending packets until the receiver completes the decoding process and sends a stop message.

   Two novel streaming approaches for UDP and TCP connections were proposed to handle the reordering problem in end-to-end multipath schemes [3]. TCP provides error recovery by requesting retransmission of missing data whereas UDP request a retransmission to ensure that it get all of the packets and can assemble them in the correct order. The number of newly appeared multimedia applications is growing intensively in the Internet protocol (IP) based networks. With the rise of multimedia and network technologies .These

   applications are not only used in reliable wired networks but also in wireless environment where the obstacles of the expansion are the higher bit error ratio of the radio link and the limited bandwidth of the links. Providing higher bandwidth levels with the ability to transmit video streams in acceptable quality. Do not retransmit any corrupted packets while SCTP will do it until all the packets arrive correctly to the client. These protocols basically do not adapt themselves to the actual conditions nevertheless it would lead to the increase of effectiveness. TFRC provides smoother change in the transmission rate that helps packets to meet the real-time constraints required by streaming media.

3. EXISTING MULTIMEDIA TRANSPORT PROTOCOL It is still challenging to achieve flawless high-quality video

   streaming services over wireless networks. To support flawless high-quality multimedia services through only a wireless network, since the data throughput can be supposedly degraded according to the surrounding environment such as traffic load, fading, attenuation loss, and signal-to-noise ratio. If any packet loss or low bandwidth occurs during transmission, then the multiple path exhibit a bad network status. Multiple Protocols like MPUDP and FMTCP are used to achieve a video quality. Since MPUDP, does not provide any error correction, it exhibits the worst video quality whereas FMTCP provides error correction but the video quality is degraded somewhat for the bad wireless channel.

   Users receive low quality video for a few seconds, which degrades the quality of user. And also increase of transmission rate may cause multiple packet drops. A single dropped packet causes a spike in latency. If packet loss occurs over multipath wireless networks, this results in a lot of latency, a lot of redundant data, and a low-bandwidth connection. Providing network congestion feedback information to end systems can prevent from starting flows with a high rate, which would worsen an already existing network congestion situation. An end system cannot know how much a change in its own rate will affect the path, and also, the path might become congested in less than one RTT Compound TCP and TCP Illinois relive the RTT-unfairness by adjusting transmission rate based on the queuing delay. Even though it does not completely eliminate the throughput dependency from the RTT.

4. PROPOSED MULTIMEDIA TRANSPORT PROTOCOL

   The existing protocols like SCTP, MPTCP, FMTCP, and MPUDP do not consider multimedia services and the computational complexity of the FEC scheme. To Overcome MPMTP is used which recovers the lost packets successfully and supports flawless high quality video streaming without degradation over multipath wireless networks. In MPMTP, Raptor codes use an FEC scheme which resends the video packet in another path if any head-of-line blocking problem in multipath environments. Transmission control protocol friendly rate control (TFRC) for high quality video streaming over a high bandwidth delay product environment. The available bandwidth faster than the slow-start scheme of

   TFRC is Wide bandwidth range, intelligent streaming, and multiple bit rate encoding, high scalability.

   1. Architecture of MPMTP

      Compressed video stream is divided into video data packets at the application layer, and these are moved to the MPMTP shim layer. At the shim layer, the video data packets are transferred concurrently to the packet scheduler and Raptor encoder buffer. When the amount of video data at the Raptor encoder buffer is sufficient, Raptor encoding is performed with the encoding parameters determined by the parameter control unit. The generated redundant data are then packetized and delivered to the packet scheduler. At the receiver side, MPMTP reorders received packets via multiple paths. If any video data packet is lost during transmission, Raptor decoding is performed to recover the lost packet. The MPMTP on the receiver side periodically feeds network information, including the delay and packet loss rate, back to the sender side. For fairness with other TCP sessions, a TCP-friendly rate control is adopted to regulate the transmission rate of UDP sub-flows. However, TFRC may restrict a transmission rate unnecessarily when packet losses occur over a wireless channel.

      Fig.1 Protocol Architecture of MPMTP

      TFRC is proposed for a smoother change in the transmission rate than that in the TCP, while maintaining TCP-compatibility. TFRC goes through a slow-start phase directly after starting. Encoding parameters such as code rate, symbol size, and the number of source symbols are determined by considering the wireless channel state.

   2. Problem Description

      To provide flawless video streaming services, a sufficient number of video data packets should be delivered within playback deadline to avoid scene freezing. And the loss rate of Raptor encoding symbols should be kept in tolerable range to mitigate severe video spatial quality degradation. Thus, the proposed MPMTP is implemented to maximize the amount of only video data except Raptor encoding redundant data with buffer occupancy and Raptor decoding failure rate constraints.To transmit high quality video over a high bandwidth delay product network environment. Users receive

      low quality video for a few seconds, which degrades the quality of user. And also increase of transmission rate may cause multiple packet drops A single dropped packet causes a spike in latency. If there is significant packet loss, this results in a lot of latency, a lot of re-sent data, and ultimately a low- bandwidth connection.

      1. Packet Scheduling Algorithm:

         The packet scheduler assigns video data to multiple paths to minimize the transmission delay of the whole encoding block while supporting best effort service for in-order packet delivery. Actually, packets may arrive out-of-order, as they are transmitted through multiple paths. In this case, it may incur additional processing delay for packet reordering at the receiver buffer, which may be an obstacle to a seamless video streaming service. When the throughput of a path decreases abruptly due to wireless channel conditions and Internet congestions, packets are stacked at the sender buffer, which may increase queuing delay.

      2. Secured Delivery of Packets:

         Routing Mechanism maintains how many packets are transmitted over each path which is useful to identify any path can handle number of packets. We can stop transmission some amount of time period over that path, So the hacker cannot identify in which path the video packet is transmitted. Therefore, sender can easily transmit the video packet securely. Raptor encoding and decoding is performed to exactly estimate the transmission time in order to reduce unnecessary retransmissions due to background processes and time-varying wireless networks. Provides highly dispersive random routes at low energy cost without generating extra copies of secrete shares. If the routing mechanism known to the hacker, the hacker still cannot pinpoint the routes traversed by each packet.

   3. Data Flow Diagram of TFRC

      The performance of enhanced TFRC is compared to the original TFRC. To show the performance in the high bandwidth delay product environment. We set the network bandwidth to 1. The slow-start mechanism of TFRC just doubles the transmission rate when an ACK is received. Moreover, the slow-start mechanism at high bandwidth overshoots large data. This results in burst packet losses, shows the measured packet loss rate during 5 s after starting a TFRC flow, and a TFRC flow with enhanced TFRC. The resulting packet loss rate of the enhanced TFRC mechanism is lower than the original TFRC. The proposed fast startup mechanism starts concave growth of the transmission rate until a concave reference point is reached, and then slowly increases the transmission rate. The proposed RTT-fair bandwidth estimation scheme shares a fairer bandwidth than the other rate control schemes.

      The enhanced TFRC quickly increases transmission rate and overshoots less transmission rate than original TFRC. Also, the transmission rate of the TCP flows is similar with

      the case that the TCP flows compete with original TFRC. This results shows that the enhanced TFRC does not disturb the data transmission of TCP. The enhanced TFRC achieves higher transmission rate than original TFRC because enhanced TFRC quickly increases the transmission rate than slow-start mechanism of TCP. Enhanced TFRC includes a fast startup mechanism, and RTT-fair bandwidth estimation. Our fast startup mechanism quickly increases transmission rate to find an available bandwidth, and mitigates overshooting of the transmission rate, by using a concave increase function until the transmission rate reaches the concave threshold, and a convex increase function after the transmission rate is larger than the concave threshold [2].

      Fig.2 Data Flow Diagram of TFRC

      Enhanced TFRC also provides RTT-fairness, by only considering the delay caused by congestion, in estimating the transmission rate. Simulations show that the proposed schemes can reduce the packet losses of slow-start, and provide RTT fairness.

   4. Video Performance using TFRC

      1. Playback Failures:

         Due to transmission error a video fail to play, if so, it is also important to track the underlying errors themselves. HTML5 video has four predefined error codes, for example. Other parts of the playback chain (like a DRM library or a MPEG-DASH playback technology) can throw errors as well.

      2. Startup time:

         It measures how long a video takes to start playing. The longer a video takes to load, the more likely a viewer is to leave. Startup time can be measured in several ways: the time it takes for the first frame of video to appear after a user hits "play", the time taken to load a video player as well as to load an entire page. While playing video, various metrics related to advertising and social media fall into this category like the wait time between an advertisement and video content.

      3. Rebuffering:

         It is stalling in the middle of playback due to a buffer underrun. In other words, the video stream is loading slower than the video wants to play, so playback has to stall to buffer more video. Rebuffering can be measured in several ways:

         • Rebuffering count is the number of times that playback stalled.

         • Rebuffering duration is the total time that playback was stalled.

         • Rebuffering frequency is like Rebuffering count / minutes of watching time how often Rebuffering events occur.

         • Rebuffering percentage is the percentage of the viewer's time spent watching that playback was stalled (Rebuffering duration / watching time).

         • Rebuffering ratio is the ratio between the Rebuffering duration and the playback duration of video that played.

         Fig.3 Difference of Video Quality

      4. Video Quality:

         In order to transmit high quality video at the beginning of transmission, a fast startup scheme is required that starts data transfer with a high initial sending rate. To probe the available bandwidth at the beginning of transmission, TFRC goes through a slow start phase as TCP

         Reno[2]. The transmission rate is doubled for each RTT, until a packet loss occurs. This makes the data transport speed of TFRC rather sluggish in a high bandwidth delay product environment, and creates large bursts of packet losses when the transmission rate eventually overshoots the bottleneck queue. In order to continue a fast increase of transmission rate while avoiding burst packet losses and rapid increase of queuing delay to achieve flawless high quality video.

   5. Performance Comparison with Existing Protocols over two Wireless LAN Captions

      MPTCP and HMTP support loss-free video quality, so their results are not included. It is clearly observed that the video quality of MPUDP is seriously degraded frequently. Since MPUDP does not provide any error correction method, it exhibits the worst video quality. Although FMTCP provides error correction using fountain codes, the video quality is degraded somewhat for the bad wireless channel. MPMTP recovers most of the lost packets successfully and supports the video streaming service without noticeable degradation.

      Fig. 4 Subjective video quality comparison of the 2711st frame: (a) MPUDP,

      (b) FMTCP, and (c) MPMTP.

      It is well known that the amount of overhead is an important performance measure for network protocols. MPTCP and MPUDP do not use FEC codes there is no data packet overhead. FMTCP shows a large amount of control packet overhead because of the acknowledgment control packets [1]. Although MPMTP experiences a small number of packet losses, it provides a seamless video streaming service with good video quality and relatively low overhead. MPMTP shows better performance regardless of the number of paths over heterogeneous wireless networks.

   6. Performance Comparison with Existing Protocols over two Wireless LAN Captions and 3G Network

   Two WLAN paths do not support sufficient throughput for seamless video streaming services due to wireless channel degradation and Internet congestion, a 3G network is

   exploited simultaneously. The performances of all the protocols are improved because the 3G network provides a very stable path.

   Fig. 5 Cumulative curves of received video data and consumed video data:

   1. MPTCP, (b) MPUDP, (c) HMTP, (d) FMTCP, and (e) MPMTP (The black arrows indicate buffer underflow.)

5. CONCLUSIONS

   In this paper, we have proposed MPMTP using systematic Raptor codes to provide a seamless high-quality video streaming service over heterogeneous wireless networks. The Raptor encoding parameters such as symbol size and the number of source symbols are treated as control variables to overcome time-varying wireless network conditions and avoid receiver buffer underflows. MPMTP performs packet scheduling algorithm in wireless network conditions to ensure smooth video playback.

6. FUTURE ENHANCEMENT

The system can further be enhanced with the implementation of services using the protocol sets. Effect of the proposed probability model on the receiver buffer size is good for future work.

ACKNOWLEDGMENT

This research was supported by Basic Science Research Program through the National Research Foundation. of Korea (NRF) funded by the Ministry of Education (NRF- 2013R1A1A2006732) and the MSIP (Ministry of Science, ICT & Future Planning), Korea, in the ICT R&D Program.

REFERENCES

1. Oh Chan Kwon, Yunmin Go, Yongseok park and Hwangjun Song, Multipath Multimedia Transport Protocol Using Systematic Raptor Codes over Wireless Networks IEEE Transaction on mobile computing, Vol 14, No 9, Sep 2015.

2. Sunghee Lee, Hyunsuk Roh, Hyunwoo Lee and Kwangsue Chung, Enhanced TFRC for High Quality Video Streaming over High Bandwidth Delay Product Networks Journal of Communications and networks, vol 16, No.3, June 2014

3. Sana Habib, Junaid Qadir, Anwaar Ali, Durdana Habib, Ming Li, Arjuna Sathiaseelan The Past, Present, and Future of Transport- Layer Multipath, arXiv:1601.06043v1 [cs.NI] 22 Jan 2016.

4. ITU-T ecommendation H.263 version 2, Video coding for low bit-rate communication, Feb. 1998.

5. ITU-T Recommendation H.264 version 3, Advanced video coding for generic audiovisual services, Nov. 2007.

6. R. Stewart, Stream control transmission protocol, IETF RFC 4960, Sep. 2007.

7. A. Ford, C. Raiciu, M. Handley, S. Barre, and J. Iyengar, Architectural guidelines for multipath TCP development, IETF RFC 6182, Mar. 2011.

8. D. Zhou, W. Song, and M. Shi, Good put improvement for multipath TCP by congestion window adaptation in multi-radio Devices, in Proc. IEEE Conf. Consumer Commun. Netw. Conf, pp. 508514, Jan 2013.

9. M. Li, A. Lukyanenko, and Y. Cui, Network coding based multipath TCP, in Proc. IEEE Conf. Comput. Commun. Workshops, pp. 2530, Mar 2012.

10. S. Floyd, M. Handley, J. Padhye, and J.Widmer, Equation-based congestion control for unicast applications, ACM SIGCOMM Computer Commun.Rev., vol. 30, no. 4, pp. 4356, 2000.

11. D. Sisalem and H. Schulzrinne, The loss-delay based adjustment algorithm: A TCP-friendly adaptation scheme, in Proc. NOSSDAV, pp. 215226, 1998.

12. D. Liu, M. Allman, S. Jin, and L. Wang, Congestoin control without a startup phase, in Proc. PFLDNet Workshop, 2007.

13. V. Sharma, K. Kar, K. K. Ramakrishnan, and S. Kalyanaraman, A Transport protocol to exploit multipath diversity in wireless networks, IEEE/ACM Trans. Netw., vol. 20, no. 4, pp. 10241039, Aug. 2012.

14. M. Yabandeh, S. Zarifzadeh, and N. Yazdani, Improving performance of transport protocols in multipath transferring schemes, Comput. Commun., vol. 30, no. 17, pp. 32703284, Mar. 2007.

15. N. Thomos and P. Frossard, Raptor network video coding, in Proc. Int. Workshop Mobile Video, pp. 1624, 2007.

16. M. Scharf and T. Banniza, MCTCP: A multipath transport shim layer, in Proc. IEEE Global Telecommun. Conf., Dec. 2011, pp. 15.

17. M. Becke, T. Dreibholz, H. Adhari, and E. P. Rathgeb, On the fairness of transport protocols in a multi-path environment, Proc. IEEE Int. Conf. Commun., pp. 26662672, Jun. 2012.

18. Hancui Zhang, Shuyu Chen, Qianyun Wang and Jun Liu, A Congestion Control Mechanism for Streaming Media Transmission over Wireless Environment International Journal of Multimedia and Ubiquitous Computing, Vol 11, No.8, pp. 257-270, 2016.

19. Sana Habib, Junaid Qadir, Anwaar Ali, Durdana Habib, Ming Li, Arjuna Sathiaseelan The Past, Present, and Future of Transport- Layer Multipath arXiv:1601.06043v1 [cs.NI] 22 Jan 2016.

20. S. Ahmad, R. Hamzaoui, and M. Al-Akaidi, Adaptive unicast video streaming with rateless codes and feedback, IEEE Trans. Circuits Syst. Video Technol., vol. 20, no 2. pp. 275285, Feb. 2010.