Packet Loss Recovery in Broadcast for Real-Time Applications in Dense Wireless Networks

Packet loss recovery in wireless broadcast is challenging, particularly for real-time applications which have strict and short delivery deadline. To recover the maximum number of lost packets within a short time, existing packet recovery solutions often rely on instantly decodable network coding (IDNC). Some of these solutions can recover nearly the maximum number of lost packets possible at the cost of collecting feedback from all (or a large percentage of) users. This is impractical in dense networks. In addition, their runtime grows with the number of users, which is not desirable due to the urgent delivery deadline of real-time applications. In this work, we introduce RIDNC, a random encoding approach to IDNC. We propose RACE, a light RIDNC encoder that can recover nearly as many lost packets as the optimal RIDNC encoder. We compare RACE with the CrowdWiFi encoder, a high performing packet loss recovery solution used in CrowdWiFi, a commercial system for broadcasting live video in dense networks. We show that RACE is up to two orders of magnitude faster than the CrowdWiFi encoder, and recovers more lost packets in practice, where there is not enough time to collect feedback from many users.


I. INTRODUCTION
With the increase in popularity of mobile devices, the need for greater quality and higher bandwidth in wireless networks has increased exponentially. Cisco Visual Networking Index report shows that the overall mobile traffic will rise from 11 ExaBytes per month in 2017 to more than 48 ExaBytes per month in 2021 (doubling every two years) [1]. At the same time video content is rising as well, and by 2021, it will cover 82% of all Internet traffic; 16% of this video content will be live video streams [1].
In this paper, we consider wireless broadcast of live media in a network with a single transmitter and many receivers within its transmission range. This has many applications. For example, a wireless transmitter can broadcast the bird-view of a parking lot to help vehicles find an open parking spot. In large sport stadiums, such transmitter can enable spectators watch the replay on their phones, or in concerts, it allows far away seats to get a better view of the stage on their tablets. Another example is to provide students in large theatre classes with a better view of the board on their laptops. In all these scenarios, we need to broadcast live video to hundreds or even thousands of users/receivers within the transmitter's range.
Handling packet losses. In wireless communication, packet loss is common because of various channel impairments such * arefi@ualberta.ca, † mkhabbazian@ualberta.ca, as mutli-path fading. A basic method to recover lost packets is to simply retransmit each lost packet. For example, in Wi-Fi (IEEE 802.11), the transmitter retransmits a packet if it does not receive an acknowledgment from the receiver. This is an effective way to recover lost packets when there is only a single receiver. When there are multiple receivers (i.e., in case of broadcast), however, there are more effective solutions.
As a simple example, consider a transmitter with three receivers within its transmission range. Suppose that after transmitting three packets, the transmitter realizes (through feedback/acknowledgments) that receiver one is missing packet one, receiver two is missing packet two and receiver three is missing packet three. To recover packets, the transmitter can transmit all three packets one more time. However, a more efficient solution is to XOR the three packets to construct a coded packet, and transmit the coded packet only. This way, each receiver can recover its missing packet by XORing the coded packet with the two packets it possesses.
Real-time applications. Real time applications can tolerate some packet losses, but have urgent packet delivery deadlines, which means that the transmitter has limited time to recover a lost packet. Our objective is, therefore, not to recover all lost packets as the transmitter may not have enough time for it. Instead, similar to [2] and [3], our aim is to recover as many lost packets as possible within a short time interval, that is with limited number of transmissions. Random Network Codes (RNC) and fountain codes are not suitable for this aim, as they require receivers to receive several coded packets before they can start decoding any packet. Therefore, instead of using these codes, we focus on codes that allow instantaneous decoding at the receivers.
Instantly decodable network codes (IDNC). IDNC is an attractive solution for packet loss recovery in broadcast of real-time applications [4]. However, existing IDNC encoders typically require collecting feedback from all or most of the receivers. This is a significant overhead in dense networks. To get a numeric intuition on the amount of this overhead, consider a network with 100 receivers/users. Suppose that feedback is transmitted using UDP over IP in a 802.11 network. The header size of UDP, IP and 802.11 are respectively 8 bytes, 20 bytes, and 34 bytes. This leads to at least 62 bytes of header overhead per user. Assuming that the size of a data packet is 1000 bytes, the bandwidth requirement for collecting feedback from 100 users is about that required to transmit six full data packets. In practice, the overhead of collecting feedback may be even higher as nodes have to employ large back-offs to reduce the number of collisions.
The second challenge with IDNC is that finding an optimal code is NP-hard. There are suboptimal IDNC encoders in the literature. However, the computational complexity of these encoders grows with the number of users. When the number of users grows, these solutions start to become slow and unsuitable for real time applications. Some works in the literature (e.g., [5]) tried to tackle this problem by assigning cluster heads and collecting feedback from them (instead of all users). These algorithms are relatively complicated and rely on the spacial packet loss correlation. Some existing studies show that such correlation is low [6].
Contributions. In this work, we introduce RIDNC, a random approach to IDNC encoding. We prove that, in dense networks, a single RIDNC packet can recover nearly as many lost packets as possible. Using the RIDNC approach, we propose RACE, a fast RAndom IDNC Encoder that works with limited feedback from users, yet recovers as many lost packets as the optimal RIDNC encoder. Using simulations, we compare RACE with one of the best IDNC-based packet recovery solutions, verify the superior performance of RACE in speed and in recovering lost packets, and confirm its low communication overhead in dense networks.
The rest of the paper is organized as follows. Section II covers related work in the literature. In Section III, the system model and problem definition are presented. In Section IV, we motivate the use of RIDNC in dense networks, and propose the RACE encoder. Simulation results are presented in Section V, and the paper is concluded in Section VI.

II. RELATED WORK
Ahlswede et al. first introduced network coding in [7] and showed that it can improve throughput. Since then, there has been extensive research work on designing coding-based solutions for different applications. In the case of singlehop wireless broadcast, the transmitter can use random linear network codes (RLNC) [8]- [15] and Raptor codes [16] to deliver packets with minimum number of transmissions, and with low coding complexity, respectively. These solutions are, however, not suitable for real-time applications such as live video streaming, as packets have strict delivery deadline in such applications. To meet the delivery deadline, a received coded packet needs to be decoded within a short time window; otherwise it would be useless hence discarded. Instantly Decodable Network Codes (IDNC) [17]- [19] are a family of Opportunistic Network Codes (ONC) [20]- [22] that minimize this decoding time at the cost of lower throughput than RLNCs.
IDNCs have the following distinguishing properties: 1) a coded packet is constructed by simply XORing a number of plain packet. 2) a received coded packet is either instantly decoded using the past decoded packets or discarded (i.e., it is not stored for later decoding). Because of the latter property, IDNCs have been the subject of several work studying real time multimedia broadcast [8], [9], [23].
Eryilmaz et al. [8] study the delay gain of coding in unreliable networks. They find closed-form expressions for the delay performance with or without coding, and show significant delay gains when coding is used. They further extend their results to general network topologies. Yu et al. [9] analyze the tradeoff between throughput and decoding delay, and examine the performance gap between RLNC and IDNC. They also propose a number of coding solutions with varying delaythroughput tradeoffs. Fragouli et al. [23] examine different usages of feedback in networks with coding capabilities, and illustrate benefits including adaptive parameter optimization to provide better quality of services. They also consider the possibility of using network coding to the feedback packets, and examine design of acknowledgment packets.
The most relevant work to ours among these studies is [3], [24], in which the authors show that the problem of finding a code that is instantly decodable by the maximum number of receivers is NP-hard. They also propose a polynomial time code construction method for the case where all receivers experience an identical erasure rate.
There is a large body of work on IDNCs that aim to reduce the completion time, which is the time needed to deliver packets to all the receivers. Some of these works assume that some packets are more important to be delivered than other packets [22], [25]. As argued in [3] minimizing the completion time is not the right objective for real-time applications. What is important in such applications is rather to deliver as many packets as possible within a strict delivery deadline. For this reason, similar to [3], [24], [26], [27], we focus on designing IDNCs that are instantly decodable by as many users as possible.
There are two other problem setups in the literature that resemble the problem considered in this paper. These problems are index coding [28] and data exchange [29]. The objective of both index coding and data exchange is to minimize the number of transmissions to achieve a certain goal. For example, in the index coding problem, each receiver demands a single packet from the set of packets at the transmitter. The objective is to satisfy all these demands with minimum number of transmissions. The objectives considered in index coding and data exchange are different from our objective, which is to construct a single code that is instantly decodable by the maximum number of users.
III. PROBLEM STATEMENT AND SYSTEM MODEL Similar to the work of Le et al. [3], [24], we define the problem as follows. We consider a single wireless base station (also referred to as transmitter) and N users (also referred to as receivers) U = {u 1 , u 2 , u 3 , · · · , u N }. We assume that all users are within the transmission range of the base station.
The base station has M packets P = {p 1 , p 2 , p 3 , · · · , p M } to broadcast to all N users. It first broadcasts these M packets using M transmissions. This step is called the initial transmission phase. The base station is then granted a short time to recover as many lost packet as possible by transmitting few coded packets.
In IDNC (and RIDNC), the encoder at the transmitter constructs a coded packet by XORing a subset of packets C ⊆ P. The number of packets in C (i.e., |C|) is referred to as the code degree. At the receiver side, a received coded packet is used by the decoder to recover/decode a lost packet; if not successful, the coded packet is discarded (i.e., it is not buffered for later use). The decoder is able to recover a lost packet iff the receiver has exactly one lost packet in the set C.
Objective. As in [3], [24], our objective is to recover as many lost packets as possible using a few number of coded packet transmissions. This objective is motivated by the following facts: 1) Real-time applications often have a strict and urgent packet delivery deadline. Therefore, the transmitter has limited time, hence limited number of transmission opportunities to recover lost packets. 2) Real-time applications can often tolerate some packet losses. Channel model. To analyze the performance of encoders, we model the channel between the transmitter and users by a packet erasure channel, where a packet is either correctly received or lost. The packet lost probability of user u i , 1 ≤ i ≤ N , is denoted by E i and is referred to as the packet erasure rate of u i . We assume that different users can have different packet erasure rates, and that packet receptions at different users are independent.
IV. RANDOM INSTANTLY DECODABLE NETWORK CODING Random Instantly Decodable Network Coding (RIDNC) is a random encoding approach to IDNC. In RIDNC, the encoder first decides on a code degree d. It then simply selects d packets uniformly at random, and XORs them to generate a coded packet. The simplicity of RIDNC allows design of fast encoders. Fast encoders are attractive for packet loss recovery in broadcast of real-time applications because these applications often have urgent packet delivery deadlines.

A. Asymptotic Optimality of RIDNC
The main task of a RIDNC encoder is to find a good code degree. Different code degrees result in different packet recovery performances. For example, suppose that every user is missing exactly one packet out of M packets. A small code degree, in this case, would result in a poor packet recovery, while the code degree of M would result in recovering all the lost packets (assuming that the coded packet is received by all the users).
Suppose the transmitter is granted a transmission (after the initial transmission phase) to recover as many lost packets as possible. The next theorem states that, in a dense network, if a RIDNC encoder chooses the right code degree, it can recover nearly as many lost packet as possible by any other packet recovery solution. Recall that N and M denote the number of users and the number of packets, respectively, Theorem 1. Let G R denote the expected number of recovered lost packets when the optimal code degree is used by the RIDNC encoder. Let G opt denote the maximum number of lost packets that is possible to recover by any solution. Then, for any arbitrary small positive real numbers δ and ǫ, we have

B. RACE: The Proposed RIDNC encoder
The core of RACE (and any RIDNC encoder) is the code degree calculation. When the code degree is calculated, the task of an RIDNC encoder is simple: it XORs a random subset of packets. The challenge of RIDNC encoder is to estimate the optimal code degree as accurate and as fast as possible with preferably limited feedback from users. Following, we first explain how RACE, our proposed RIDNC encoder, estimates the optimal code degree for the first coded packet (Algorithm 1). The general case of code degree estimation is then presented in Algorithm 2.
Estimating the optimal degree for the first coded packet. Let the random variable Y d be the number of lost packets recovered when the transmitted coded packet is the XOR of d packets selected uniformly at random from P. By definition, the optimal code degree d * is For the first coded packet, we have where E i is the erasure rate of user u i . Therefore, if the encoder knows the erasure rates E i , it can calculate the optimal code degree d * for the first coded packet. RACE, however, has no prior information on the erasure rates of users. To estimate the optimal code degree, it therefore collects limited feedback from a subset of users right after the initial transmission phase.
Let S be the index of users from which feedback is collected. The feedback collected from user u i , i ∈ S, is the number of packets u i has received during the initial transmission phase. After collecting all these feedback, RACE estimates the optimal code degree d * aŝ The estimation (1) is inspired by Theorem 2. In the theorem, the assumption that erasure rates come from a uniform distribution-while they likely come from non-uniform distributions in practice-is only to estimate the optimal code degree. One may justify this assumption by the fact that the transmitter has no information about erasure rates prior to collecting feedback. Note that any prior information about the erasure rates (e.g, knowing users' erasure rate distributions) can be used in Theorem 2 to improve the estimate of the optimal code degree. Nevertheless, simulation results show that this estimate is virtually as good as the optimal code degree.
An advantage of (1) is that a major part of it can be precomputed: as stated in Corollary 1, evaluatingd would require only a single matrix multiplication of complexity O(M 2 ). Note that this computational complexity does not grow with the number of users N .
Proof: See Appendix B.
where Π i,j denotes the element in the ith row and jth column of Algorithm 1 shows how RACE estimates the optimal degree for the first coded packet. As shown in the algorithm, the matrix Π is pre-computed, and the matrix V is simply filled in with the collected feedback. Therefore, the main computation of Algorithm 1 is to calculate the product Π × V which can be done in O(M 2 ).  The largest element of the above vector is at index i = 5, thus Algorithm 1 returnsd = 5 as the code degree.
Estimating optimal code degrees for multiple packets. After transmission of each coded packet, the optimal code degree can change. To estimate the new optimal code degree, RACE does not request feedback from users as this increases the communications overhead and delay. Instead, as shown in Algorithm 2, it estimates the number of packets each user has using its latest information about the user, and the code degree of the last transmitted coded packet.
To this end, Algorithm 2 maintains a M × M matrix D, a generalization of the vector V in Algorithm 1. The value of D i,j is an estimate of the number of users that have received i packets in the initial transmission phase, but currently have j (j ≥ i) packets because of possible recoveries by the coded packet transmissions. Initially, D is filled with the collected feedback from users, so the initial values of D are all accurate. After each transmission, the values of D are updated as and c is the code degree of the last transmitted coded packet. By Theorem 2, the parameter α c,j is an estimate of the probability that a node which has received i packets in the initial transmission phase, and currently has j packets has benefited from the last transmitted coded packet. In other words, D i,j is an estimate of the number of users that received i packets in the initial transmission phase but currently have j ≥ i packets. Using the updated matrix D, and by simply applying Theorem 2, Algorithm 2 esimates the code degree for the next coded packet. Collecting feedback. To statistically represent the set of receivers/users in the network, the receivers that send feedback are selected uniformly at random. To collect feedback from the selected users, different mechanisms can be employed. Following, we explain two possible feedback mechanisms.
For the first mechanism, we assume that the transmitter is aware of the IDs of the receivers. This is a reasonable assumption because receivers typically connect to the transmitter to receive the multicast service. To request feedback, the transmitter can then randomly select receivers, and embed the list of selected IDs in a packet to notify the selected receivers. To minimize collisions, the selected receivers can transmit their feedback in the same order as their IDs appear in the packet. Note that even without following such order of transmission, the MAC layers of the selected users are there to handle the contention. Also, our solutions require only a small number of feedback. Therefore, there is a smaller chance of collisions compare to the case where feedback is collected from all/majority of users. In addition, as shown in the simulations, our solutions are not sensitive to few possible feedback losses.
For the second mechanism, we assume that the transmitter does not have the IDs of the receivers, but has an estimate of the number of receivers. In this case, the transmitter can ask the receivers to send feedback with a probability p, set by the transmitter. For instance, if the transmitter estimates the number of receivers to be 100, and it wishes to collect about 20 feedback, then it can set p to be equal or slightly higher than 0.2. This solution has lower communication overhead than the first solution, and does not require knowledge of IDs of the receivers.
if G > Gain then 23: Gain ← G

V. SIMULATION RESULTS
Comparing RACE with the Optimal RIDNC encoder. We first compare the performance of RACE with the optimal RIDNC encoder. Recall that, by Theorem 1, in dense network, the optimal RIDNC is capable of recovering virtually as many lost packets as possible by any other recovery solution.
In the optimal RIDNC, the transmitter knows the erasure rates of all users, and receives feedback from all users after each transmission to calculate the optimal code degree. In RACE, however, the optimal code degree is estimated using a one-time feedback (right after the initial transmission phase), and without the knowledge of erasure rates. Figures 1, 2, and 3 compare the gain of RACE and the optimal RIDNC encoder for various number of coded packet transmissions. The gain is calculated as the total number of packets recovered divided by the total number of users, averaged over 1,000 simulation runs. As shown, RACE performs very close to the optimal RIDNC. This is despite the fact that RACE has no knowledge of erasure rates, and receives feedback from users only once.
Sensitivity of RACE to the number of feedback. In the next set of simulations, we evaluate the sensitivity of the gain of RACE to the number of feedback. Recall that RACE collects feedback only once (before the transmission of the first coded packet). Figures 4 and 5 show the result of our simulations for a dense network with 500 users. The dashed line shows the gain of RACE when feedback is collected from all users. The solid curve is the gain of RACE versus the number of feedback requested 1 . This result shows that RACE needs only a small number of feedback to nearly achieve its full gain. For instance, it shows that RACE can achieve 90% of its full gain using feedback from up to ∼ 2% of users.
Comparing RACE with the CrowdWiFi encoder. Among the existing solutions, two were reported to achieve near optimal gain: the recovery algorithm used by CrowdWiFi [2] (referred to as the CrowdWiFi encoder), and the Multi-Slot Max Clique [3]. The CrowdWiFi encoder has a better runtime 2 than Multi-Slot Max Clique, thus we used it as our baseline to evaluate the gain and speed of RACE.
CrowdWiFi by Streambolico [30] is a commercial system for broadcasting live video in dense networks such as stadiums, and conferences. A major contributor in the high performance of CrowdWiFi is its encoder, which works as follows. In the first step, the CrowdWiFi encoder selects a packet, say c, that is wanted by the most number of users. At step i > 1, the encoder selects a packet p such that c⊕p is instantly decodable by more users than c. If such a packet p exists, it replaces c with c ⊕ p and moves on to the next step; otherwise, it stops and returns c as the coded packet.
We implemented the CrowdWiFi encoder, and compared it against RACE. As shown in Figures 6 and 7, RACE can recover more lost packets than the CrowdWiFi encoder where the number of feedback is small. This is an advantage because the transmitter does not have enough time to collect many feedback when broadcasting for real-time applications. As the number of collected feedback increases, the gap between the gain of the two encoders reduces, and at some "cross point" the CrowdWiFi encoder can recover the same number of lost packets as RACE. To get to this cross point, however, a considerable number of feedback has to be collected. In addition, at this point, the CrowdWiFi encoder is significantly slower than RACE. For instance, when the number of packets is M = 20 and the maximum erasure rate is 20%, the cross point occurs around 0.15 × N feedback, as illustrated in Figures 6. As shown in Figure 8b, when M=20 and the maximum erasure rate is 20%, RACE is about a factor of 3.5F faster than the CrowdWiFi encoder, where F denotes the number of collected feedback. Combining the two, we get that RACE is 3.5×(0.15N ) > 0.5N faster than the the CrowdWiFi encoder at the cross point. This speedup factor ranges from 50 to 500 in a dense network with 100 to 1000 users.

VI. CONCLUSION
In dense networks, it is not practical to collect feedback from all or a large percentage of users. This is especially the case when broadcasting for real-time applications, which have urgent delivery deadlines. Considering this limitation, we proposed RACE, a fast and light random IDNC (RIDNC) encoder. We proved that, in dense networks, the optimal RIDNC encoder is capable of recovering nearly as many lost packets as possible by any other solution. Then, using simulations, we showed that RACE can recover virtually as many lost packets as the optimal RIDNC. Also, we compared RACE with the CrowdWiFi encoder, a fast and high performing packet recovery solution used in CrowdWiFi, a commercial system for broadcasting video in dense networks. The results show that RACE can recover more lost packets than the CrowdWiFi encoder in practice, where there is not enough time to collect many feedback. In addition, RACE is up to two orders of magnitude faster than the CrowdWiFi encoder. These make RACE a better solution than the state-of-the-art for recovering lost packets in broadcast for real-time applications in dense networks.                    Let C denote the set of packets XORed to generate the coded packet, and x i,C , 1 ≤ i ≤ N , C ⊆ P, be a binary random variable such that x i,C =    1 if the coded packet 1) is received at user i, and 2) results in a packet recovery at user i; 0 Otherwise Note that a user cannot recover any packet if it does not receive the coded packet. That is why the random variable x i,C is set to zero if the coded packet is not received at node i. Also, a received coded packet can result in a packet recovery only if the user is missing exactly one packet from the set C.
The random variable X C = N i=1 x i,C is the sum of N independent binary random variables, thus, by a Chernoff bound, we get P r(X C > (1 + δ)µ C ) ≤ e −δ 2 µ C 3 Let P C = 1 N · N i=1 P r(x i,C = 1) and p * = max C⊆P P C . We have µ C = N · P C and G R = max C∈P µ C = N · p * . By (2), we get The total number of subsets C of P is 2 M , and P r(X C > (1 + δ)G R ) ≤ ǫ 2 M for every random variable X C . Therefore, by the union bound, the probability that X C > (1 + δ)G R for at least one set C is at most with probability at least 1 − ǫ. Therefore, with probability at least 1 − ǫ.

APPENDIX B PROOF OF THEOREM 2
Let the binary random variable y ′ d,i be the number of recovered packet at user u i , and We have Note that