Video Streaming Over Multi-hop Wireless Networks

Transcription

1 Video Streaming Over Multi-hop Wireless Networks Hao Wang Dept. of Computer Information System, Cameron University Andras Farago, Subbarayan Venkatesan Dept. of Computer Science, The University of Texas at Dallas P.O. Box 83688, Richardson, TX Abstract In this paper, we considered the problem of transporting layered video over erroneous multi-hop wireless networks and proposed a Distributed System. Our proposed Distributed Scheme is comprised of Distributed Control (DC), Distributed Buffer (DB) and Distributed Error Control schemes. The DC scheme improves the efficiency of the network bandwidth usage and reduces the end-to-end delay of the streaming application. End-to-end delay jitter can be reduced by proper use of the DB nodes buffer. Replacing the traditional FEC and ARQ with our distributed FEC and ARQ scheme reduces the errorprotection overhead and ARQ delay and improves the wireless channel throughput. A Layered Video module is developed in GlomoSim 2.3 for video streaming application. We simulated our Distributed Scheme employing the Layered Video module in GlomoSim 2.3. Our simulation results confirm that QoS of Streaming Video over erroneous multi-hop wireless network can be improved using our proposed Distributed Scheme. I. Introduction Most of the nomadic applications today are built using a single wireless hop to a wired network. In parallel with the single hop model, another type of model, based on radio to radio multi-hopping, has been evolving to serve a growing number of applications, which rely on a rapidly deployable, multi-hop, wireless infrastructure [5]. In this paper, we are addressing the video streaming application over multi-hop wireless networks. In this paper, we considered the problem of transporting layered video over erroneous multi-hop wireless networks and proposed a Distributed Scheme. In our proposed distributed control scheme, a subset of nodes along the streaming path is chosen dynamically as distributed control (DC) nodes. These DC nodes drop the video packets whose timestamps indicate that there is no benefit in further transmission. The early drop scheme saves wireless bandwidth and hence video packets transmitted subsequently experience small end-to-end delays. The DC nodes improve the efficiency of the network bandwidth usage and reduce the end-to-end delay of the streaming application. In the proposed distributed buffer scheme, we pre-select some intermediate nodes as distributed buffer (DB) nodes, which are used to pre-buffer video packets before the video streaming starts. End-toend delay jitter can be reduced by proper use of the DB nodes buffer, and our simulation results confirm this. Video playback quality is very sensitive to wireless channel errors. Traditionally, to deal with the transmission errors in the wireless channel, forward error correction (FEC) is employed at the sender by adding redundancy information to packets before they are transmitted. The receiver manages to decode the erroneous packets relying on redundant FEC codes. If a packet is beyond the FEC error correction capability, ARQ (automatic repeat) is used to handle the retransmission of the corrupted packet all the way from the sender to the receiver [1][2][3]. In our proposed scheme, besides the sender, FEC is also employed at all DB nodes. Each DB node is capable of correcting some error bits by using previously added FEC code and adding new FEC code to the original video packet for further transmission. Employing FEC scheme at each DB node requires the addition of small FEC code to the video packet (to combat wireless channel errors). Therefore the FEC error-protection overhead and overall video bit rate can be reduced. For those video packets which are beyond the error correction capability at a certain DB node, instead of retransmission from the sender, only retransmission from previous DB node is needed. Replacing the traditional FEC and ARQ with our distributed FEC and ARQ scheme reduces the errorprotection overhead and ARQ delay and improves the wireless channel throughput. II. The Distributed System 1. Layered Video Background In the video compression standards, generally, an I frame leads a GOP. All P and B frames of the same GOP basically depend on that I frame. GOP length can be constant or variable. In this chapter, we assume that a new GOP starts when the scene changes.

2 We use layered video coding to encode I, P and B frames into a hierarchy of X, Y and Z layers respectively, shown in Figure 1. We denote the layers of I, P and B frames as {I(BL), I(EL 1 ) I(EL X-1 )}, {P(BL), P(EL 1 ) P(EL Y-1 )} and {B(BL), B(EL 1 ) B(EL Z-1 )}. Values X, Y and Z can be chosen such that each layer of I, P or B frames is of the same size. Since I frame is statically larger (in size) than P frame and P frame is larger than B frame, X Y Z. Each layer of video frame is transmitted in one packet. In ideal scenario (no transmission errors), I, P and B frames can be transmitted in X, Y and Z packets respectively. To reduce the amount of the computation performed at the sender when transmitting, we order packets of each GOP. The sequencing is based on the decoding dependency of all packets. For example, enhancement layer of I frame can only be decoded based on the base layer of the I frame. Base layer of a P frame can not be decoded until the base layer of the related I frame is decoded. Given the video sequence IBBP, the decoding dependency of packets of IB 1 B 2 P 1 can be drawn as a directed graph shown in Figure 2. Assume that X, Y and Z equals to 3, 3 and 2. In the directed graph, each node represents a layer of a certain frame. For example, I(BL) represents base layer of I frame. Directed link from node X i (Y j ) to node X p (Y q ) means that layer Y j of frame X i depends on layer Y q of frame X p. To determine all the dependent packets for a certain packet, find all the paths from node I(BL) to the corresponding node in the graph and every node along each path is a dependent packet. To sequence all the packets of a GOP, we start from node I(BL) on the top. Then order all directly connected nodes in temporal order. We keep doing this until all packets are ordered. Then we have sequenced packets at the sender. The ordered packets for video sequence IB 1 B 2 P 1 are listed below: delay, the DC node early-drops that packet. Otherwise, the DC node forwards it to the next hop. Without these DC nodes, the outdated video packets are still forwarded to the next hop even though they may be no longer useful for the receiver. Precious wireless bandwidth is wasted. The early drop scheme saves the wireless bandwidth so that the video playback quality at the receiver side can be improved. Frame type B frame Z P frame I frame Y X Fig. 1 Layered video of I, P and B frame I(EL1) I(BL) P1(BL) Num of layers I(BL), I(EL 1 ), P 1 (BL), I(EL 2 ), P 1 (EL 1 ), B 1 (BL), B 2 (BL), P 1 (EL 2 ), B 1 (EL), B 2 (EL) 2. Distributed Control Scheme A subset of the nodes along the streaming path from the server to the client is chosen dynamically as the set of distributed control nodes. The DC nodes provide control functions. The DC nodes are used to control network bandwidth usage and QoS of the streaming application and are set up by a self-learning scheme. Each intermediate node periodically checks its wireless link condition. When a node detects severe fading, the node becomes the DC node. The node will keep serving as the control node until the wireless link condition goes back to normal. Each DC node makes decision on whether to drop the recently received video packet or continue to transmit the packet to the destination. When the packet s current delay plus DC node delay threshold exceeds a preset end-to-end I(EL2) P1(EL1) P1(EL2) B1(BL) B2(BL) B1(EL1) B2(EL1) Fig. 2 Dependency graph of frame sequence IB 1 B 2 P 1

3 The early-dropping decision is based on the following criteria: 1) If a packet contains I-frame base layer, the DC node schedules that packet at the head of the forwarding queue and forward it immediately. 2) For all other packets, if the current delay plus DC node delay threshold exceeds the end-to-end delay bound, that packet becomes outdated and is early-dropped. 3) Each DC node keeps a look-up table that stores the correctly received video information of each GOP. The table indicates which layer of which frame is received correctly and what has been ruined. The DC node can drop some layers of P or B frames when the corresponding layers of the dependent I or P frames are not received correctly. To make accurate early-dropping decision, a DC node needs to update its delay threshold frequently, which is critical to packet early-dropping. Inaccurate delay threshold can either unnecessarily drop packets or push some outdated packets into the forwarding queue, resulting in a situation where the receiver either fails to receive video packets or receives outdated video packets. In either case, video playback quality is lowered at the receiver side. Therefore, more accurate the delay threshold of DC node is, better is the video playback quality that can be achieved. The delay threshold of each DC node can be updated by packet timestamps. Before video streaming starts, all intermediate nodes along the path need to be synchronized. Each DC node time-stamps the packet which is located at the head of its forwarding queue. In every t second interval, from the most-recently received video packet, the receiver retrieves all the timestamps marked by intermediate DC nodes. It compares them against its current clock to calculate the delay thresholds for each DC node. The receiver constructs an Update message, which contains the newly-computed delay thresholds for all DC nodes, and sends the Update message along the video streaming path all the way back to the video server. When the Update message is transmitted, each DC node reads the corresponding delay threshold information and updates the delay threshold to be used for later packet early-dropping decision. The variance of the streaming throughput is caused by the variance of wireless link conditions. In order that DC nodes employ accurate delay threshold for packet early drop, the interval t for collecting timestamps at the receiver can be tuned down when larger variance of wireless link throughput exists. The receiver will send Update messages more frequently and each DC node will be able to employ more accurate delay threshold for early-dropping. On the other hand, when a smaller variance appears, the interval t can be tuned up to avoid unnecessary signaling traffic. The variance of the video streaming throughput can be measured by the timestamps of video packets. In our study, propagation delay is assumed to be relatively small and is neglected. Also we assume that all the video packets are of the same size S and all video packets experience similar queuing delays (layer 2 forwarding queuing delay). The variance of delay D reflects the variance of the throughput B. The receiver keeps track of the timestamps of all the received video packets in the current interval and the variance of delay D can be calculated from the timestamp record. The distributed control system early-drops the updated video packets and saves the bandwidth for next significant video packets. However, delay jitter can lower video playback quality even when end-to-end delay can be tolerated by the receiver. To overcome the difficulty of large delay jitter, distributed buffer nodes are introduced next. 3. Distributed Buffer System Large delay jitter is generated when the wireless links experience good-bad state transitions. Traditionally, the video streaming delay jitter can be reduced by prebuffering a large number of video frames at the receiver side. However, in mobile wireless networks, there is no guarantee that a mobile device has enough buffering capacity. In this case, overflow occurs at the receiver buffer and video packets are dropped. In our proposed scheme, we pre-select some intermediate nodes along the video streaming route which have relatively larger buffering and computing capacity as the distributed buffer nodes (DB nodes). At the beginning of video streaming, each DB node fills up its buffer to some extents (say, 5% of the full capacity). Since each DB node has pre-buffered video data, delay jitter can be reduced at each distributed buffer node. From the receiver point of view, the end-to-end jitter is reduced step-by-step by the collaborative work of all the DB nodes. The DB nodes need to signal the streaming server before the streaming application starts. The signal includes the corresponding DB node s buffer capacity and node location. The streaming server then decides how much video data can be pre-stored at each DB node. Upon prebuffering a small amount of video data at pre-selected DB nodes, the video streaming starts. 4. Distributed Error Control In multi-hop wireless networks, video data is transmitted over multiple erroneous wireless links. Traditionally, FEC error correction and ARQ are performed only by the receiver. The receiver tries to use the redundant FEC code to correct the transmission errors in the received video packet. If errors are beyond the error correction capability, ARQ retransmission from the video streaming server to the client is required, even though

4 some of wireless links on the steaming path may be good. In the multi-hop scenario, the traditional FEC error correction needs large FEC codes in order to cope with the worst possible link and ARQ delay is the end-to-end delay from the video streaming server to the client. In our proposed error control scheme, each DB node functions as the traditional receiver regarding how to control transmission errors. First, each DB node tries to correct bit errors in the received video packets. If the packet is error-free or the error bits can be corrected by the previously added FEC code, then the DB node corrects error bits by exploiting the old FEC code and adds new FEC codes (of possibly different length) to the original video packet and forwards the error-protected packet to the downstream node. Therefore, wireless channel errors occurring between two consecutive DB nodes could be corrected by the error detection/correction capability of the downstream DB node. For a heavily corrupted packet beyond the recovering capability of the DB node, ARQ request is initiated by the downstream DB node and the corrupted packet is retransmitted by the upstream DB node. Since each DB node only deals with the channel errors between two consecutive DB nodes, the FEC code is of shorter length than the one used in the traditional FEC in order to achieve the same error correction capability. On the other hand, in respond to the heavily corrupted packet, traditional ARQ scheme retransmits the packet from the video streaming server to the client even through many of the wireless links in the streaming path are very good. Instead of retransmitting over these good wireless links, our distributed FEC/ARQ scheme localizes the retransmission within two consecutive DB nodes. Unnecessary retransmission over good wireless channels is avoided. 5. Cross-Layer Design The proposed distributed scheme can be implemented by careful cross-layer design of the Protocol Stack including layer, Network Layer, Transport Layer and Application layer, shown in Figure 3. Traditionally, upon receiving each frame, an intermediate node of a video streaming traffic removes the header, retrieves source and destination addresses from the header. Based on the destination address, it looks for next hop in its routing table to route the packets to the next hop. The transmission of packets from video streaming source to the destination is accomplished hop by hop. In our proposed distributed control scheme, the flow of video streaming traffic from the video server to the client through intermediate nodes is represented by the Figure3. Instead of processing video streaming traffic only by Physical Layer, Layer and Network Layer at each intermediate node in traditional way, video streaming traffic flows through Physical Layer to Application Layer at each intermediate node in our scheme. At the video server, video data is divided into a sequence of segments. Each segment is encapsulated by application header. The application header contains server ID, starting transmission time, and sequence number. Each encapsulated segment is further encapsulated by header, header, header and transmitted over physical radio link to the intermediate node. Upon receiving data at the physical layer, each intermediate node removes, and headers and retrieves transmission time and sequence number from the application header. The current delay can be computed by the difference between current time and starting transmission time. The current delay is kept at the intermediate node and is refreshed every time a new video segment is received. The intermediate node makes earlydrop decision for received video segments based on their current delay. If the current delay exceeds the delay bound set up by the control protocol, the video segment is earlydropped at the intermediate node. Otherwise, the video segment is encapsulated by,, headers and routed to the next intermediate node. Each video segment needs to pass the early-drop decision at all intermediate nodes before it arrives to the video client. Video client decodes received video data and playback in real-time. The control protocol is used to help intermediate nodes to refresh the delay bound and make early-drop decision. The video client initiates the control protocol by constructing control messages and sending them all the way back to the video server periodically. The control message is routed along the reverse route of video streaming traffic. The video client retrieves transmission time from newly received video segment and computes the end-to-end delay. The end-to-end delay information is used to construct a control message. When the control message is routed to an intermediate node, the end-to-end delay in the control message is retrieved and the delay bound is nothing but a linear function of the difference of end-to-end delay bound and the current delay kept at that intermediate node.

5 APP APP APP APP the starting transmission time included in the video packet header. At the end of simulation, video server reports traditional QoS parameters like packets drop ratio, average end-to-end delay and delay jitter. 3. GlomoSim Simulation Setting Video Server Intermediate Node Figure 3. Cross-Layer Design III. Simulation 1. Video Packet Generation A Layered Video module is developed in GlomoSim 2.3 for video streaming application. We simulated our distributed control and distributed buffer schemes employing the Layered Video module in GlomoSim 2.3. Our Layered Video module is implemented in the application layer of network stack of GlomoSim. The input to the Layered Video module is video profile, which stores packet ID, layer ID, frame ID and timestamp of each video packet. Packet ID is a unique identification for each video packet. Layer ID refers different layer of a certain frame. It only has some fixed integers like, 1, 2 and 3. Layer ID means base layer and Layer ID 1 means enhancement layer 1 and so on. The video profile can be generated prior to simulation given video coding pattern and layering coding scheme. For example, if we choose video coding pattern IBBPBBPBBPBB for GOP and encode I, P and B frame into 4, 2, 1 layer respectively. Then each GOP has 18 ( ) video packets (each packet contains only one layer of a certain frame) and each packet has the same timestamp as that of the frame it belongs to. 2. Video Packet Transmission Intermediate Node Video Client The video packets corresponding to a certain video profile is first ordered before the video streaming starts. The ordering is implemented at video server side based on the traversal algorithm running on the dependency graph. The server passes the ordered packet down along the ///Physical network stack for transmission. Each intermediate node routes the received packets to the next hop. The distributed control nodes reconstruct original video packets from the corresponding packets and it makes early-drop decisions based on the current delay. Current delay can be computed from current local time and The wireless network in the simulation is WLAN. There are 12 nodes in the network in a meter region, shown in Figure 4. There is no movement of nodes in our simulation. We use protocol in layer. The channel has bandwidth 2 Mb/s. The path loss model used in the simulation is two-ray propagation model. The heights of transmitter and receiver antennas are h t and h r, which are preset to 1.5m in our simulation. During the simulation, radio transmission power, radio receiver threshold, antenna gain of transmitter and receiver are unchanged. The transmission power and radio receiver threshold are 15 dbm. Antenna gain of transmitter and receiver are all set to. If the sender is within the radio range of the receiver and the sender successfully access the channel during the transmission period, the packet is regarded as correctly received. The maximum number of link layer retransmission is seven, after which the packet is dropped. protocol is used in the transport layer. meters Wireless Network Topology VBR Traffic CBR Traf f ic meters Figure 4. Wireless Network Topology in Simulation 4. Simulation Result We have multiple VBR and CBR application in the simulation. Multi-hop VBR application carries video streaming application while CBR application is regarded as the background traffic. Background traffic shares the network resource with VBR application. By adjusting the background traffic, the performance of the proposed

6 distributed schemes for VBR application can be studied under different network conditions. The performance of the distributed control scheme is studied by measuring QoS parameters of VBR application. In the first experiment, we compared case of no distributed control scheme with the case of distributed control scheme. The distributed control scheme chose 2ms as the delay bound at the first DC node and 4ms as the delay bound at the second DC node. The experiment result showed that average end-to-end delay and jitter are significantly lowered from 193ms, 13.6ms to 112.5ms and 48.6ms respectively. The cost of employing distributed control scheme is that packet drop ratio is increased from 3.7% to 5.1%, which is still acceptable. In the second experiment, we studied how delay bound of the distributed control node affect performance of VBR application. We found that when the delay bound is increased, the VBR traffic will have smaller packet drop ratio but larger end-to-end delay and delay jitter. The objective of our experiment is to minimize average end-to-end delay and delay jitter of VBR application with the constraint that unsuccessful transmission of video packets must be within a preconfigured packet drop ratio in order to meet certain video playback quality at the client side. By tuning the parameter of delay bound of distributed control node, the objective can be achieved. The simulation result is shown in Figure 5 and Figure 6. IV. Conclusion A Distributed Scheme for layered video transmission over multi-hop wireless networks has been proposed. The DC scheme early-drops outdated video packets. The DB nodes buffers some video packets at intermediate nodes and provides distributed FEC and ARQ scheme to localize error control between two consecutive DB nodes. Simulation results show that Qos of Video Streaming over erroneous multi-hop wireless network can be improved by our proposed Distributed Scheme. video compression standard. [5] C.R.Lin Multimedia transport in multihop wireless networks, IEE Proc.-Communication, vol.145, pp No.5, Oct 1998 Delay(ms) Jitter(ms) Early_Drop Threshold vs. End-to-end Delay Threshold(ms) Early_Drop Threshold vs. Jitter Threshold(ms) Figure 5. Delay and Jitter of Early-drop Scheme 1.2 Early_Drop Threshold vs. Percentage of Early_drop Pkts over Overall Drop Pkts 1 REFERENCES [1] J.Y.Pyun, J.J.Shim, S.J.Ko, S.H.Park, Packet loss resilience for video stream over the Internet IEEE Trans. Consumer Electronics Vol.48 No.3.pp Aug. 22. [2] M.Podolsky, S.McCanne, M.Vetterli soft ARQ for layered streaming video Tech.rep. UCB/CSD , University of California, Computer Science Department, Berkeley, CA, Nov [3] S. Wang, H..Zheng, J.A.Copeland, An error control design for multimedia wireless networks, IEEE Vehicular Technology Conference (VTC2- Spring).Vol, 2 pp , 2, Tokyo. [4] Joan L. Mitchell, William B.Pennebaker, MPEG Percentage Threshold(ms) Figure 6. Packet Drop Ratio of Early-drop Scheme