IPTV Multicast over Wireless LAN Using Merged ...

7 downloads 523 Views 977KB Size Report
(RTCP) packets for a media track are also inserted into a corresponding source buffer data structure (e.g., linked list). Sequence numbers in the RTCP packets ...
IPTV Multicast over Wireless LAN Using Merged Hybrid ARQ with Staggered Adaptive FEC Mingquan Wu1, Shivesh Makharia2, Hang Liu1, Dekai Li1, Saurabh Mathur 1 1

Corporate Research Lab, Thomson Inc. 2 Independence Way, Princeton, NJ 08540 2 WINLAB, Rutgers University 671 Route 1 South, North Brunswick, NJ 08902 mingquan.wu, hang.liu, dekai.li, [email protected], [email protected]

Abstract — Internet Protocol TV (IPTV), an emerging internet application, provides more flexibility and interactivity for users because of its embedded return channel. Wireless 802.11 networks, used as the last hop of IPTV networks, would add another dimension of mobility, which is of great value for hot spot deployment and is increasingly required for in-home content distribution. However, a wireless channel may suffer from multipath fading and interference, which may cause random and burst packet loss and impact users’ quality of experience of an IPTV program. We report the design, implementation and evaluation of Merged Hybrid Adaptive FEC and ARQ (MHARQ) system for IPTV multicast over wireless LANs. In MHARQ, an IPTV cache server is introduced to improve the reliability for the last hop wireless distribution. MHARQ combines the advantages of receiver-driven staggered FEC and hybrid ARQ schemes to compensate the large dynamic range of WLAN channels and to achieve high reliability, scalability and wireless bandwidth efficiency for IPTV multicast. We also address backward compatible FEC encoding and decoding, audio and video synchronization issues in practical system implementation. Using the ORBIT radio grid test bed, we have investigated the performance of the proposed MHARQ system with various numbers of users per AP and different numbers of APs per IPTV cache server. It is demonstrated via real system implementation on ORBIT that MHARQ improves wireless bandwidth efficiency and scalability for reliable IPTV multicast, compared with existing reliable multicast schemes.

experience of an IPTV program. To improve reliability, error correction schemes such as forward error correction (FEC) and/or automatic repeat request (ARQ) can be used. In FEC, parity packets are sent with the source media packets. However, as each mobile device may experience different channel conditions, it is difficult to decide how much FEC to send. Lower FEC may cause poor protection and lost packets may not be able to be recovered. Higher FEC may cause more overhead and waste network bandwidth. Using ARQ for error correction, a mobile device’s packet recovery may suffer a long round trip time delay. In multicast applications, ARQ may also result in feedback explosion problem. However, when the round trip delay is short, and appropriate feedback suppression algorithm is used, ARQ is still a viable error correction scheme for real time IPTV content streaming.

Index terms — IPTV, FEC, ARQ, Wireless and Multicast. I. INTRODUCTION As digital TV gradually replaces analogue TV, there is an increasing interest to distribute digital TV programs on an IP network [1-4]. IPTV has an advantage over satellite, terrestrial or cable TV system because it has an embedded return channel. This enables a service provider to add more interactivity. Another advantage is that a service provider can now combine TV (video), phone (audio) and internet access (data) into one network, which would decrease deployment cost significantly, and, at the same time, give users the convenience to pay all the services in one bill. Wireless local area networks (WLANs) have been extensively used in homes, hotels, on campus and other hot spots such as airports and train stations because of their flexibility and low cost. While in most cases, users connect to a WLAN to browse websites or check e-mails, it is a natural extension to use WLANs as the last hop for IPTV distribution. However, a wireless channel may suffer from multi-path fading and interference, which may cause random and burst packet loss and impact the users’ quality of

Figure 1 MHARQ for IPTV Architecture Figure 1 shows our MHARQ architecture for IPTV distribution. An IPTV server, often located at video head end office (VHO) or video serving office (VSO), would package real-time or pre-recorded TV contents into IP packets and distribute the packets through the IP network. It should be noted that packet loss often occurs at the last hop DSL or wireless connection. To improve the reliability for the last hop distribution, an IPTV cache server is added at VSO or

connected to the local gateway at a hotspot. The cache server intercepts and caches IP content packets for retransmission and/or produces FEC packets used for error recovery. Different scenarios may use different error correction schemes. Hybrid ARQ is more bandwidth efficient than FEC if there is only one AP. If there are multiple APs, as shown in Figure 1, it may have scalability issue. For example, a receiver under AP1 requires a lot of retransmitted FEC packets, but the receivers under AP2 only need a small number of retransmitted FEC packets. The cache server must retransmit a lot of FEC packets in ARQ multicast group to meet the requirement of AP1. Then AP2 also relays these FEC packets over its wireless link, which results in the waste of AP2 wireless resource. This is because the retransmission in hybrid ARQ is controlled by means of a central controller, the cache server that serves multiple APs (the transmission of FEC packets in staggered adaptive FEC is controlled by individual APs). Of course, an ARQ proxy can be implemented in each AP. However this introduces complexity in the AP as the AP must be modified to support application layer retransmission functionality. Another method is that each AP has its own ARQ multicast group. However when a receiver hand offs from one AP to another AP, it needs to know the address of the new AP' s ARQ group. This requires extra signaling between the receiver and video server or other mechanisms. In addition, the required number of multicast groups and the retransmitted FEC packets increase with the number of APs served by the IPTV cache server. It would be advantageous to provide a single solution for all these application scenarios. In this paper, we propose MHARQ to combine the staggered adaptive FEC and hybrid ARQ to achieve better scalability and bandwidth efficiency. The video packets are transmitted in an IP multicast group (video multicast group) through the UDP/IP stack and ethernet interface to the APs. Non-delayed FEC parity packets are transmitted in a different multicast group without time shift to correct the random packet loss according to the desired coverage range of the AP. Certain FEC parity packets are stored in the delay buffer for different time offset. These FEC parity packets are transmitted after a specified delay in multiple multicast groups to correct burst packet loss. FEC encoding and delayed/non-delayed FEC transmission is integrated in the IPTV cache server. The cache server is also responsible for handling NACK request from clients and retransmitting the ARQ FEC parity packets and video packets according to the client request. Our system can be configured to use adaptive FEC, hybrid ARQ or both according to different deployment scenarios. We have implemented the IPTV cache server and client software. Novel software architecture is designed to integrate the FEC functionality in the clients with no requirement for changing the existing video player. Using the ORBIT [18] wireless test bed, we investigate reliability, scalability and bandwidth efficiency of the proposed MHARQ and compare its performance with the existing video multicast system to demonstrate the efficacy of MHARQ in a real system. The rest

of the paper is organized as follows. In Section II, we survey the related work. In Section III, we describe the system architecture of MHARQ scheme. In Section IV, we discuss the FEC codecs and adaptive MHARQ algorithm. In Section V we present the field test results from the ORBIT wireless testbed. Section VI concludes this paper. II. RELATED WORK Video and audio contents are compressed before they can be distributed over the internet. Traditional compression algorithms rely on temporal difference coding to achieve high compression rate, thus introduces dependence among different video frames. A lost or late arrived packet may cause a client fail to decode a video frame, which in turn may cause the loss of subsequent dependent video frames, resulting in visual artifacts. When the loss rate is low, error concealment [10] may solve part of the problem. If the loss rate passes a certain threshold, the users viewing experience would be severely impacted. Authors in [5] and [6] reviewed the efforts to model and improve quality of experience (QoE) from the users’ point of view. In general, an error recovery scheme needs to be used in an IPTV application to improve the users’ QoE. There has been a lot of research and theoretical analysis on various application layer forward error correction (FEC) and automatic repeat request (ARQ) algorithms [11-14] for error recovery. Some works are particularly targeted to improve transmission reliability in wireless networks. Majumdar et al. [7] have proposed an ACK-based hybrid ARQ algorithm for unicast video transmission and progressive video coding with FEC (MDFEC) for multicast video transmission over WLANs. In [8], a cross layer protection strategy for video unicast in WLANs was proposed by jointly adapting MAC retransmission limit, application layer FEC, packetization and scalable video coding. These studies involved a single access point. Handoffs between access points were not considered. In addition, only results obtained from simulations were given. In [9], the authors proposed a layered FEC scheme with layered scalable video for multicast over the Internet, in which layered video data for the same group of pictures are transmitted with different multicast addresses in the same time slot and multiple FEC layers are transmitted with other multicast addresses at later time slots. However they focused on theoretical analysis of algorithms to select the video and FEC layers in an Internet setting to optimize the video quality of a receiver given its available bandwidth and packet loss probability. They didn' t address implementation issues, for example, how the padding information in a packet is signaled, etc. The backward compatibility with non-FEC capable players was also not considered. In addition, the characteristics of shared wireless media also makes multicast in wireless LANs different from that in Internet. Our work focus on improve the reliability for transmit IPTV content over a wireless channel. We make the following contributions: (1) Proposing merged-group hybrid ARQ, a new

and improved adaptive system for reliable video multicast over wireless LANs. In the design, MHARQ considers wireless multicast characteristics. For example, wired backhaul has more bandwidth than wireless links so delayed FEC will always be transmitted in wired backhaul but only transmitted on-demand in wireless networks. Wireless medium is shared, if one user joins a FEC group, other users under the same AP will receives the FEC data no matter if they join the multicast group or not; (2) proposing a client software architecture to integrate the FEC functionality without changing the existing video player code; (3) Addressing backward compatibility issues; (4) Using experiments to investigate reliability, scalability and bandwidth efficiency of the proposed MHARQ and comparing its performance with the existing video multicast system. III. SYSTEM ARCHITECTURE OF MHARQ SCHEME A. Cross Packet FEC Based IP Multicast Groups The FEC packets for an IPTV stream are divided into different layers and each layer is transmitted in a different multicast group. As shown in Figure 2, there are three types of FEC groups for a source stream: • Non-delayed FEC groups: The FEC packets in these groups are not delayed from the source, i.e. these FEC packets are sent as soon as they are generated. For random loss recovery, a mobile device joins one or more non-delayed FEC groups based on its “long-term” channel conditions. •

Delayed FEC groups: The transmission of FEC packets in these groups are delayed from the media packets by a configurable time. Using Internet Group Management Protocol (IGMP), a mobile device dynamically (per FEC block) joins the delayed FEC groups if non-delayed FEC packets are not enough to recover the content. If the join time is less than the time shift between content and delayed FEC, the corresponding parity packets will be received to recover the lost packets by the mobile device. To save wireless bandwidth, delayed FEC data for a multicast group would not be transmitted by the AP/router in wireless network if no clients/mobile devices associated with the AP/router join this particular group.



ARQ FEC Groups: The FEC packets in the ARQ FEC groups are sent according to the NACK from the clients/mobile devices. A mobile device sends the NACK to the IPTV cache server and joins the corresponding ARQ FEC groups via IGMP if delayed FEC packets are not enough to recover the lost packets/data.



ARQ Source/Content Groups: If the number of lost packets exceeds a threshold, the IPTV cache server may retransmit the original block of media packets in a multicast group. When there are a lot of lost/damaged media packets/data, the receiver is at least able to receive some of the retransmitted media packets.

Source Non-Delayed FEC

Source FEC1 FEC2

FEC3

Delayed FEC ARQ FEC ARQ Source

FEC4 FEC5 FEC6 ARQ Source

Figure 2 Source and FEC in Multiple Multlicast Groups For flexibility, the number of non-delayed and delayed FEC groups, the time shift between content stream and delayed FEC streams, as well as the quantity of FEC in non-delayed, delayed FEC groups and ARQ FEC groups can be configured. It should also be noted that during the FEC encoding at the server side, media packets are not modified. All the information about FEC encoding parameters are included in the FEC packets. This implementation is backward compatible because even if a mobile device does not support FEC, it still can join the media multicast group, receive the media packets and playback the received content. B. IPTV Cache Server Architecture Figure 3 shows the IPTV cache server implementation for our IPTV multicast system using the merged group hybrid ARQ. FEC module allocates media content packets to a FEC block and FEC/parity packets are generated and added to the FEC block such that there are k media packets and n − k FEC/parity packets in a FEC block. The FEC/parity packets are separated into layers representing increasing FEC/parity that can be requested and used by a mobile device in the event that the FEC block (including the media and non-delayed FEC packets) was insufficient to recover the content. The mobile device requests additional FEC by joining the multicast groups that provide the additional FEC. The additional FEC is stored in a delay buffer. All data (media, non-delayed FEC, and delayed FEC) are forwarded to a mobile device via UDP/IP protocol stack. The most recent media packets and part of the FEC packets created by the FEC module are cached for use by the ARQ module. When a mobile terminal sends a NACK requesting for retransmission of FEC packets or media packets, it joins an ARQ retransmission multicast group in order to receive the retransmission of FEC packets or media packets. There are several types of NACK/ARQ requests. In one type of NACK/ARQ request, a mobile device asks for the number of FEC packets that it needs; in another type of NACK/ARQ request, a mobile device requests the cache server to retransmit specific media packets. In this case, the NACK/ARQ request includes the sequence number of the content packets that the mobile device needs. A third type of NACK/ARQ request is the combination of the above two NACK/ARQ requests. In the third case, a mobile device requests a certain number of FEC packets and media packets.

Session Description Protocol (SDP) [17] is used to indicate the video multicast group and the FEC multicast group information, including the multicast addresses, video coding format, FEC coding scheme as well as the association between the video stream and the parity stream. The SDP file can be downloaded by the client through the HTTP protocol at the session start or announced by the IPTV content or cache server via the SAP protocol [19].

Media and FEC cache

FEC Module

Hybrid ARQ process

Delay buffer

Ethernet Interface

TV content

Staggered Non FEC Staggered FEC

groups, recovers lost video packets and sends the recovered video packets to the player through an internal socket. An initial buffer is used at the client proxy to compensate the time shift between the video stream and the parity stream for lost video packet recovery. The recovered video stream can also be saved in a disk file and play back in a later time. D. Client Side Data Structure For backward compatibility, we did not modify media content packets in our FEC encoding; also in order to solve audio/video synchronization problem, the FEC block size and the number of media packets in one FEC block is not fixed. These cause challenges at client side FEC decoding. We designed a special data structure at client side to so that a client can perform FEC decoding in various loss patterns. The main data structure at the mobile device side is shown in Figure 5. The mobile device maintains a source buffer (media buffer) and a FEC block buffer for each track of the media stream in a session. The mobile device also maintains an event queue data structure.

NACK retransmission

Figure 3 IPTV Cache Server Architecture

C. Client Side Architecture Available commercial and freeware video players, e.g. Quicktime[21] and VLC players[22], do not support FEC. The source code is generally not available for commercial players. It is difficult to integrate FEC into every freeware player as well as maintain and update it even if the source code of freeware is available. To overcome these limitations, we design a novel client proxy architecture as shown in Figure 4. It can work with any commercial and freeware video players without requirement to change the player code. The proxy receives video and FEC packets from different multicast

Figure 4 Client Architecture

Figure 5 Client Data Structure An FEC block includes one or more media packets (up to k media packets). Thus a media packet is said to belong to a FEC block. The FEC block also includes one or more FEC/parity packets (up to n − k FEC/parity packets). Thus, FEC/parity packets are said to belong to an FEC block. Here n is the FEC block size, and k is the number of media packets in a FEC block. A media packet is marked if the FEC block to which it belongs has been allocated. The source buffer buffers T seconds of media packets. The source buffer may be implemented using a linked list data structure. When a mobile device receives a media packet, the received media packet is inserted into the source buffer data structure (e.g., linked list) according to the sequence number. If the FEC block data structure to which the received media packet belongs has not been allocated yet, the mobile device has no information about the FEC block to which this media packet belongs. A media packet does not include any information about the FEC block. Also our implementation does not use fixed n and k in FEC encoding (as explained in the FEC codec section), the FEC block index information cannot be derived from the sequence number. If there is no

information about the FEC block to which a media packet belongs, the media packet is not marked. It should be noted that real-time transport control protocol (RTCP) packets for a media track are also inserted into a corresponding source buffer data structure (e.g., linked list). Sequence numbers in the RTCP packets are not assigned according to the RTP [16] packets. Rather RTCP packets are inserted into the source buffer according to the time that the RTCP packets were received. If a media or RTCP packet remains in the buffer for greater than a predetermined or configurable time T , then the mobile device sends the packet to the media player. The FEC block buffer data structure may also be implemented as a linked list, each element in the linked list is a FEC block data structure which includes all the information about a FEC block, such as the base sequence number, n and k , etc. When a mobile device receives a parity (FEC) packet, the mobile device gets all the information about the FEC block to which this parity packet belongs from the FEC block header. The mobile device first checks if a block data structure has been allocated to the FEC block. If a block data structure has not yet been allocated, then a block data structure is allocated. A FEC block data is inserted into the data structure (e.g., linked list) according to its base sequence number. The base sequence number of a FEC block is the smallest sequence number of the media packets that belong to this FEC block. After a FEC block has been allocated, the mobile device looks into the source buffer and marks the media packets that belong to this FEC block, and updates the information (such as how many packets are lost, which packets are lost, etc.) corresponding to this block. The information is used in the adaptive FEC of the present invention. The information is also used in the FEC decoding. Subsequently, if a media packet or a FEC packet is received for this FEC block, the information of this block is updated correspondingly. If a media packet is received after the FEC block to which this packet belongs has been allocated, the mobile device is able to locate this FEC block structure from the linked list based on the sequence number of the media packet, the base sequence number, n and k of the FEC block. The mobile device marks this media packet and updates the FEC block information. The FEC block data structure includes an array of pointers that point to all the media packets that belong to this block. It also includes a decode buffer that is used to store FEC packets for this block. A memory buffer, that is required to perform FEC decoding, is also allocated in the decode buffer. If the FEC block is decodable, FEC decoding is performed and the recovered media packets are inserted into the source buffer. Media or FEC packets received after a FEC block has been decoded are dropped. When all the media packets for a FEC block are sent out to the display, the FEC block structure is cleared and memory is freed.

It is also possible that the parity packets for a certain FEC block are totally lost, for example, in a hand off. The mobile device may not be able to obtain any FEC information about these media packets. A mobile device also keeps a pointer to the first unmarked media packet in the source buffer, If the difference between the last unmarked media packet and the first unmarked media packet exceeds a certain threshold (for example, the 3/2 the estimated value of k ), the mobile device concludes that all FEC packets for these media packets are lost/damaged (FEC block is not decodable). The client/mobile device will then activate the adaptive FEC algorithm or ARQ request processing without any FEC information about these media packets. Because in our implementation, k is not fixed, a client/mobile device keeps an estimation of the average value of k . Each event is inserted into the event queue according to their expiration time. An event may be an ARQ processing event, which includes all the information for a mobile device to send an ARQ request or process ARQ suppression. An event may also be a check event. For an example, after a mobile device sends an ARQ request, the mobile device may insert a check event into the event queue for the mobile device to check at a later time to determine if it has received the retransmission parity packets and was able to decode a FEC block. If the mobile device has not received and decoded the retransmission packet, the mobile device may send another ARQ request. IV. FEC CODECS AND MHARQ ADAPTIVE ALGORITHM A. FEC Encode and Decode Our software implementation is based on Vandermonde generator matrix for efficient erasure correction [15]. A RS (n, k ) codeword consists of k source symbols and n − k parity symbols. During the encoding, the k × n Vandermonde generator matrix is transformed into its systematic version, where first k columns form an identity matrix, and then the RS codeword is computed by multiplying a vector of k symbols with the systematic generator matrix. Since the code is systematic, the first k coded symbols are exactly the same as the original source symbols. During the decoding, a k × k submatrix is formed from the first k columns of systematic Vandermonde matrix according to the positions of the received k symbols in the codeword. The submatrix is inverted and the original k source symbols are recovered by multiplying the vector of k received symbols with the inverted submatrix. For backward compatibility, we extended Pro-MPEG CoP#3 RTP packet header [16]. In Pro-MPEG specification, we have only 3 bits of index, which means we can most have 8 FEC packets, this is not sufficient to give appropriate protection for transmit video over wireless channels. We borrow another 5 bits index_ext from the mask bits from the RTP header, these bit are not used when the type of the FEC code is specified as RS ocde. Figure 6 shows the parity RTP

packet format. Using this scheme, our FEC block size can reach 255. This mechanism can be used in a multicast scenario with mixed FEC capable and non-FEC capable receivers because the original RTP source packets are unchanged. The non-FEC capable legacy players can just receive video multicast group. This achieves backward compatibility. Our testing with several H.264 compliant players shows that our scheme works well with commercial players like VLC by Video LAN project, Quicktime by Apple Inc. and Thomson player.

Figure 6 Parity RTP Packet Format B. Audio/Video Synchronization Issues At the IPTV cache server, before the FEC encoding operation is performed, a certain number of media packets ( k ) are buffered. Multimedia content may include multiple tracks, e.g. video track and audio track. The FEC encoding operation is performed on each track respectively. Different media tracks have different bit rate. Usually video has a higher bit rate than audio. If we use the same FEC block size for both video and audio we will have audio/video synchronization problem at the receiver. For example, when the number of video packets in the video buffer reaches k , FEC encoding is performed on these packets, the video FEC packets are sent out and the buffer is emptied for the next block; at the same time the number of audio packets in the audio buffer may still have to wait a unspecified time before it reaches k . This is not desirable. One approach is to use different block size for video and audio. For a certain block size of video, how to select the block size for audio is a design problem. Different content may require different block size pairings between the audio and video tracks. Even for the same content, variant bit rate content may need different k for audio and video at different times. One way to solve this problem is to fix the maximum number of packets ( K ) that will be used for FEC encoding in a FEC block. When the number of video (audio) packets in the buffer reaches K , the FEC encoding based on these video (audio) packets is performed and at the same time the FEC encoding based on the audio (video) packets is also performed no matter how many packets is in the audio (video) buffer. Since both n and k are not fixed for different FEC blocks, n and k must be included in the FEC header to pass this information to the client.

For variable bit rate stream, the time to fill a fixed number of media packets in a buffer may vary. To further combat the playback jitter that may be incurred because of FEC buffering, a maximum buffer time ( τ ) for a FEC block is also suggested. If the buffering time for the first packet in the video or audio FEC buffer is equal to or greater than τ , or the number of video (or audio) packets for a track in the buffer reaches K (the maximum buffer size), the FEC encoding on the packets of both video and audio tracks of the multimedia content is performed. For real time applications, using variable n and k can solve the audio and video synchronization problem but may cause extra encoding and decoding overhead, because the generating matrix for different n and k are different, and creating generating matrices is very computationally expensive. To improve the encoding and decoding efficiency, both maximum of k and n are fixed in our work, represent by K and N respectively. The generating matrix is created based on K and N , and is initialized only once on both server and client side. All RS ( n, k ) codes, with k ≤ K and n ≤ N , can be generated using the initial generating matrix based on punctured/shortened codes, which dramatically reduces the encoding and decoding time. C. MHARQ Adaptive Algorithm Each client would run the MHARQ adaptive algorithm to decide, according to the current channel condition, if it should join or leave one or more FEC groups, send ARQ request, etc. A multicast session has one media group represented by media_group. Each media track in the multicast session also has a number of FEC groups. The number of FEC groups may be different, for example, for audio and video tracks. The adaptive FEC and ARQ algorithm are deployed for each media track separately. In the following discussion, it is assumed that a multicast session that has only one media track to describe the adaptive FEC and ARQ algorithm. For a multimedia session with multiple tracks, the method can be used for each track. Assuming that a stream has a total of

m + 1 FEC groups,

to group(0), group(1),.....group(m) , group(0) group(m − 1) are adaptive FEC groups, group (m) is used for

ARQ. The first FEC group is sent immediately after the media group (non-delayed FEC group). A client will always join the media group and the first FEC group. In the following, the group number is used to index the parameters associated with that group. For an example, the overhead of group(i ) would be overhead (i ) , and the delay of group(i ) would be delay(i ) . If the FEC code has a block size of n , the number of message packets in each block would then be:

n

k= 1+

m

overhead (i ) i =0

The number of parity packets in each group is:

(1)

num _ parity(i ) = overhead (i ) * k .

(2)

The mobile device estimates the average loss rate and its variance for the received FEC blocks as avg_loss_rate, and avg_variance respectively. When a mobile device receives the first FEC packet for a FEC block, it means that the mobile device has received the last media packet of the current FEC block. From the FEC header, the mobile device extracts all the information about this FEC block, and has the knowledge if any media packets have been lost and how many packets have been lost for this FEC block. This information is used to update the estimate of average loss and variance. At this point, if the mobile device has already received enough packets to decode the current FEC block, the mobile device does not have to join any new FEC groups or send an ARQ request. However, if the mobile device joined more FEC groups, then the mobile device may receive extra redundant parity packets. The client may need to leave (unjoin) those FEC groups. Assume that the client does not receive enough packets to decode the current FEC block. The number of lost media/message packets is:

lost _ msg = k − recv _ msg

The mobile device needs to decide the number of FEC groups to join. One solution is to join all the groups at one time. A second solution is to join one additional FEC group first. After some delay, the mobile device then checks to determine if it has received enough packets to decode the FEC block. If not, the mobile device joins the next FEC group. In the first solution, the number of packets that are needed can be estimated by:

+ α * avg_variance

(4)

In wireless networks, the packet loss variance can be very large. Thus most of the time, the mobile device may overestimate the parity packets needed. The number of groups that the mobile device needs to join would then be:

g = min( j :

j

num _ parity(i) ≥ req _ sym)

i =1

(5)

j ≤ m −1 When the mobile device joins a multicast FEC group, the mobile device needs to specify the duration that the mobile device should remain joined to this group. This is specified by the grp_expire parameter.

grp_expire(i ) = current _ time + delay(i ) + Te i ≤ m −1

( K − lost _ msg + 1) * T s . This way, the mobile device that has lost the most packets will send the ARQ request first. The ARQ request will be multicast to the ARQ request multicast group. Other clients/mobile devices, on receiving this ARQ request, will compare the number of requested parity packets in the received ARQ request to its own needs. If the number parity packets requested by another mobile device is bigger than its own request, the mobile device will suppress its own ARQ request and wait to get the multicast which will have more parity packets than it needs. In the second solution, the mobile device first joins one additional delayed FEC group and a timer is set. The timer should expire sometime before the delay time of the next delayed FEC group. If the mobile device determines that it can still not decode the FEC block, the mobile device has time to join the next FEC group. For example, if the IGMP join latency is between several to about 50ms, the timer expiration time is specified as Tx = 100ms before the next FEC group delay time:

timer_expire(i ) = current _ time + delay(i + 1) + Tx

(3)

req _ sym = lost _ msg * (1 + avg _ loss _ rate)

request is not sent immediately. An ARQ request timer is inserted into the event queue, the expiration time of the timer is set between and ( K − lost _ msg ) * T s

(6)

where Te is a configurable parameter. If the mobile device joins all the adaptive FEC groups but still cannot decode the FEC block, the mobile device will have to send an ARQ request. To cope with the feedback explosion, the ARQ

i ≤ m −1

(7)

where Tx is a configurable parameter. Again, if the FEC group has already been joined, the mobile device just needs to update the expiration time of the group, but the timer still has to be set. When the mobile device has joined the last adaptive FEC group but still cannot decode the FEC block, the mobile device will have to send an ARQ request. In some scenarios, if the number of lost media packets in a FEC block exceeds a threshold (for example, 50% of k ), it may not be efficient to send an ARQ to ask only for parity packets. In this case, the mobile device can send an ARQ to ask the retransmission of the original media packets. If the mobile device received enough packets/symbols to decode the FEC block or if the mobile device needs less parity symbols than that provided by the FEC groups it has joined, then the mobile device needs to check if it should leave (unjoin) one or more FEC multicast groups. Equation (5) gives the number of FEC groups that a mobile device should join, if the currently joined group number l is bigger than g , then the mobile device should leave group( g + 1) to group(l ) . To reduce the number of joins and leaves, another parameter is introduced. Let

h = min( j :

j

over _ head (i ) ≥ avg _ loss _ rate )

(8)

i =1

and t = max( g , h) , if l > t , then the mobile device leaves group(t + 1) to group(l ) .

V. TEST RESULTS After having designed a scalable solution for error resilient video delivery over WLANs, we were motivated to test its effectiveness in a real world scenario. The ORBIT [18] (OpenAccess Research Testbed for Next-Generation Wireless Networks) provides the necessary experimental platform to conduct experiments typical of a real world setting.

B. Comparison of Different Multicast Error Recovery Schemes

To emulate noisy environment we use noise generator to generate additive white Gaussian noise. We use a bandwidth of 20 MHz and vary the noise power to emulate the noisy and lossy environment we need to test for. A. Visual Results This experiment was carried out at Thomson Corporate Research, Princeton using a LinkSys Access point operating in 802.11a mode (channel 36). We use a Microsoft Windows XP client using QuickTime player to play back the video content. The complete system parameters are described in Table 1. Table 1. System Parameter for a Typical Visual Result Experiment

Figure 8 Comparison of Different Multicast Schemes We have compared 3 error recovery schemes for video delivery: (1) Staggered Adaptive FEC (SAFEC) (2) Hybrid ARQ (HARQ) (3) Multi Group Hybrid ARQ. We set up the experiment on ORBIT as shown in Figure 8. Here we use a stream server to send out pre-coded H.264 video in RTP packets. Assume the Media streaming server and the IPTV cache server connected through the wired network. Also assume 2 APs (AP1 and AP2) connected to the streaming server and IPTV cache server over the wired network. The 2 APs represent two different WLANs. AP1 and AP2 work on the two different channels. Client 1 is associated to AP1 and client 2 is associated to AP2. The 2 WLANs share the Video and FEC/ARQ Muticast Group. The configured overhead (in percentage) on each FEC/ARQ multicast group is given in Table 2.

Figure 7 Visual Results Obtained with MHARQ Figure 7 shows the video quality from the 2 clients. Client 1 (left-hand side) is using our MHARQ solution for video reception over the wireless channel. Client 2 (right-hand side) shows the video quality without using our client proxy. Client 2 only joins the traditional video multicast group while client 1 joins the video multicast group + the FEC/ARQ multicast groups depending upon the link losses experienced by it.

Figure 9 Overhead Comparison for AP1 We increase the interference of AP1 channel so that the raw packet loss rate of client 1 increases. It is equivalent that the client 1 is moving away from the access point. However, in WLAN2 we keep the packet loss rate of client 2 at around 5%. We use a Gilbert model to emulate such a linear increase in average link loss using packet filtering. Note that we cannot use the ORBIT noise generator due to granularity issues to emulate this type of linear increase in packet loss.

Table 2 Overhead of the Different Multicast Groups

All of three schemes are able to adapt the FEC overhead to recover the lost packets when the raw packet loss rate changes. Under AP1, the overhead incurred by hybrid ARQ and MHARQ scheme are close. The overhead of SAFEC is higher than hybrid ARQ and MHARQ scheme. This is because the granularity of the FEC in each SAFEC delayed multicast group is high. With hybrid ARQ the client 1 can request the amount of FEC packets exactly required to recover the lost packet. No additional packets are received. We see that MHARQ performs close to the HARQ solution. Figure 9 would imply that HARQ achieves the lowest overhead and hence should be favorable to use for video multicast over wireless LANs if there is only one AP per video streaming and IPTV cache server.

and networks parameters would behave under a HOTSPOT environment. In this setup (see Figure 11), we randomly choose 60 nodes on the ORBIT grid to behave as clients receiving the video. The AP is placed in the middle of the grid. Noise injection takes place from the four corners of the grid. Table 3 shows the detailed system configuration for this setup. Figure 12 (a) shows the packet loss experienced at the clients when they do not use any correction schemes. We can see that with an increasing noise level, the packet loss increases at the clients. We do not increase noise beyond -35 dB because after this level, certain clients behave very poorly (packet losses in excess of 50% per block) and in such degrading environments, no scheme can be used to recover video quality. Table 3 System Parameters for the Scalability Test on ORBIT

Figure 10 Overhead Comparison for AP2 However, the HARQ solution does not scale well assuming a number of APs each with a different link loss rate. In this scenario for WLAN2, even though the link loss rate is only 5% we see that because of an increase in link losses in WLAN1, the overhead traffic in WLAN2 using HARQ increases (since both WLAN1 and WLAN2 share the Video/FEC/ARQ multicast group). All the clients will receive the extra redundant FEC packets in WLAN2 even though they request a small number of packets. This is because there is only one multicast ARQ group. In these cases, both SAFEC and the MHARQ solution scale well since a client in WLAN2 would only join the first FEC group (10% overhead). This is evident from Figure 10 where the overhead using SAFEC and MHARQ is close to 10% but increased linearly for the case of HARQ. In summary, the MHARQ scheme can achieve better performance when there are multiple APs. C. Scalability Tests on ORBIT We now discuss the scalability issues and results obtained with our solutions. We were also motivated to find out how system

Figure 11 Setup on ORBIT for Scalability Tests

This is inherently an issue with the fine calibration of the noise antennas. Instead, to emulate a noise environment with packet losses in excess of (2~3 %) we use a Gilbert model and simulate packet filtering. We drop packets at the receiver to simulate a noisy environment (average 5% packet loss per block. Figure 12(b) shows the residual packet loss for the same clients. Note the Y-Axis scale on both the graphs for comparison. We can see that our scheme performs well on an average for around 60 clients.

Figure 13 Overhead Scalability Tests

(a)

Until now, we have considered the downlink' s scalability when using MHARQ. They discuss the data traffic from the server to the clients. It is also important to discuss some scalability results on feedback (uplink traffic). We first show how the multicast group subscription overhead behaves. As explained before, we use IGMP [20] for the multicast group subscribe/unsubscribe. To calculate the number of join/leaves we use an IGMP sniffer at the Access Point. We see that (Figure 14) with no/very low noise levels, the IGMP overheads are much less that 1 message per block. For around -35 dB, the average number of join/leaves is 3 per block (1 for video, 1 for ARQ request Group and 1 for FEC group). For around 5% packet loss this number scales to around 6-7 messages per block (1 for video, 1 for ARQ request Group, ~4 for FEC Groups and 1 for ARQ Retransmission Group).

(b) Figure 12 Comparison of Packet Loss Experienced with Different Clients The packet loss is at a maximum of around 0.09% per block which is almost close to no packets lost per block. Figure 13 shows the overhead packets requested by the clients. The actual number of packets received by the clients is lesser than this number because of losses in the FEC groups also. In the no noise case, when the packet loss is around 1%, we see that on average the clients join either 2nd or 3rd multicast groups (total overhead of 5% or 10%). For a packet loss of up to 56% (Markov model) we see that the clients at maximum join 2nd, 3rd and 4th multicast groups in some cases (total overhead of 5%, 10% or 15%). The average overall overhead is around 12%. Ideally, with a 5% packet loss we would need a minimum of 7% overhead to correct the losses. This also shows that our receiver driven adaptive algorithm is very aggressive and dynamic. Also, we can see that this solution scales very well for an increasing number of clients.

Figure 14 Multicast Join/Leave Messages These results imply that the IGMP subscription overhead scales fairly well with around 60 clients deployed. We also show some results on the ARQ NACK messages send by the clients. We discuss the ARQ NACK message overheads received by the IPTV cache server for different noise levels. For the Gilbert model (5\% packet loss per block) we can see the classical feedback implosion problem shown in Figure 15 by the blue plot. The number of ARQ retransmission messages increases drastically as the number of clients increase. However, using our suppression algorithm, we can

Figure 15 ARQ Suppression Results

Figure 16 Overall Gains Achieved Using MHARQ

see that this number is stable (around 0.5 messages per block on average). D. Overall Gains Achieved Using MHARQ In this particular experiment we show the gains achieved through our system as experienced by an end user streaming video over a wireless channel. We have a single user connected to the AP and the video server streaming video to the client associated with the AP. We have our MHARQ proxy running on the client. Figure 16 shows the average correctly received video packets % per FEC block for increasing noise levels. The blue plot has no protection and shows that the received video quality degrades as the noise levels increase from -20 dBm to -15dBm. However, using our MHARQ solution (red plot), the client can receive acceptable video quality upto -16dBm packet loss. However, our system also fails beyond -16dBm. Figure 17 shows the overhead incurred by the client to maintain an acceptable video quality for the increasing noise levels. From -20 dB to -17 dB we achieve the most gains from MHARQ with a slight increase in network bandwidth.

Figure 17 Increasing Overhead as Noise Level Increases REFERENCES [1] [2] [3] [4]

VI. CONCLUSION In this paper, we have designed, implemented and evaluated MHAQ for reliable wireless IPTV multicast. The system uses strong application layer FEC and hybrid ARQ with a simple adaptation algorithm. An efficient ARQ multicast suppression algorithm is also implemented. This system is designed to efficiently recover from random and burst packet loss, and achieve seamless handoff. We have implemented MHARQ multicast system including IPTV cache server and client side proxy. Using the ORBIT wireless network testbed, we have also investigated scalability concerns and validated our design choices. The experience and insight obtained from implementation are discussed as well.

[5] [6]

X. Hei, Y. Liu and K. W. Ross, “IPTV over P2P Streaming Networks: The Mesh-Pull Approach”, IEEE Communications Magazin, February, 2008, volume 46, p86-92. C-S Lee, “IPTV over Next Generation Networks in ITU-T,” Proc. IEEE/IFIP 2nd Int’l. Wksp. Broadband Convergence Networks, Munich, Germany, May 2007 Y. Hang et al. “When Is P2P technology beneficial to IPTV Services?,”

Proc. ACM 17th Int’l Wksp, Network and Op. Sys. Support for Digital Audio and Video, Urbana-Champaign, IL, June 2007. N. Degrande, K Laevens, and D.D.Vleeschauwer, “Increasing the User Perceived Quality for IPTV Services. IEEE Communications Magazin,

February, 2008, volume 46, p94-100.

D. Hands, “Quality Assurance for IPTV,” ITU-T Wksp. End-to-End QoE/QoS, June 2006. A. Takahashi, “Standardization activities in the ITU for a QoE assessment of IPTV,” IEEE Communications Magazin, February, 2008, volume 46,

p78-84. A. Majumdar, D. Grobe Sachs, I.V. Kozintsev, K. Ramchandran, and M. Yeung, ”Multicast and Unicast Realtime Video Streaming Over Wireless LANs,” IEEE Transactions on Circuits and Systems for Video Technology, vol. 12, no. 6, June 2002, pp. 524¬534. [8] M. van der Schaar, S. Krishnamachari, S. Choi, and X. Xu, "Adaptive Cross-Layer Protection Strategies for Robust Scalable Video Transmission Over 802.11 WLANs" IEEE Journal on Selected Areas in Communications, Vol. 21, No. 10, Dec. 2003, pp. 1752-1763. [9] W. Tan, A. Zakhor, “Video multicast using layered FEC and scalable compression,” IEEE Transactions on Circuits and Systems for Video Technology, vol.11, no.3, pp. 373-386, March 2001. [10] B. Wah,X. Su,D. Lin, “A Survey of Error Concealment Schemes for Real-Time Audio and Video Transmissions over the Internet,” Proceedings of the IEEE International Symposium on Multimedia Software Engineering, Dec. 2000 [11] J. P. Macker, “Reliable multicast transport and integrated erasure-based forward error correction”, Proceedings IEEE MILCOM, November 1997, p973-7 vol.2.

[7]

[12] S.Lin, D.J. Costello and M.J.Miller, “Automatic-repeat-request errorcontrol schemes”, IEEE communication magazine, 22(12):5-17, 1984 [13] J. Nonnenmacher, E. Biersack, and D. Towsley, “Parity-Based Loss Recovery for Reliable Multicast Transmission.” IEEE Trans. On Networking, pages 349-361, Aug. 1998. [14] Yatin Chawathe, Steven Mcanne, and Eric Brewer, “RMX: Reliable multicast for heterogenous networks.” In Proc. IEEE INFOCOM, March 2000. [15] L. Rizzo, "Effective erasure codes for reliable computer communication protocols," ACM Computer Communication Review, 27(2), Apr. 1997. [16] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications," IETF RFC 3550, July 2003. [17] "SDP: Session Description Protocol," IETF RFC 2327. [18] D. Raychaudhuri, I. Seskar, M. Ott, S. Ganu, K. Ramachandran, H. Kremo, R. Siracusa, H. Liu and M. Singh, "Overview of the ORBIT Radio Grid Testbed for Evaluation of Next-Generation Wireless Network Protocols", Proceedings of the IEEE Wireless Communications and Networking Conference (WCNC 2005). [19] "Session Announcement Protocol," IETF RFC 2974 [20] "Internet Group Management Protocol," IETF RFC 3376 [21] http://www.apple.com/quicktime/download/win.html. [22] http://www.videolan.org/vlc/