# PROFEE: A Probabilistic-Feedback Based Speed Rate Adaption for IEEE 802.11 bc
## 2 Related Work  
Inherently, broadcast in the 802.11 standards is defined to be implemented without any acknowledgment (ACK) [12]. As mentioned, if more than one STA receives the broadcast message correctly, their corresponding ACKs will likely collide in the AP. However, sending no acknowledgment brings up many problems related to the uncertainty of the broadcast mechanism because it is impossible for the AP to know whether broadcast messages are beingreceived correctly. This problem makes it difficult for any rate-adaption algorithms to work properly. A trivial solution for this problem is continuously broadcasting messages with the lowest MCS available. Although this measure ensures that the maximum number of STAs receive broadcast messages correctly, the data rate will be the lowest, which might lead to a degradation in the quality of the broadcast content and the associated poor user experience. The problem of adapting the data rate has been addressed from four different perspectives in the past. In general terms, the first approach tries to decrease the number of feedback messages, the second approach makes the feedback messages collision-resistant, the third approach decreases the size of the feedback messages, and the last approach turns the broadcast messages into unicast (thus avoiding collisions since unicast ACKs are transmitted at different times). However, one aspect they all have in common is that they seek that the ACKs do not collide, thus allowing the AP to obtain feedback from the receiving STAs. In the first category, we have solutions to minimize the number of feedback messages sent by receiving STAs. The LBP [2] (Leader Based Protocol) uses the Automatic Repeat Request (ARQ) mechanism with ACK combined with leader-based techniques to minimize the number of sent ACKs, thus increasing the probability of ACK reception. Later, Ref. [3] used probabilistic NACK suppression to decrease the number of sent NACKs. A second approach tries to decrease the size of the feedback messages to decrease their probability of collision. In [6], the authors explored using ARQ messages combined with virtual ACK bitmaps significantly shorter than the actual ACK/NACK messages. The AP assigns small time slots to each STA in which they will answer with ACK pulses. Although this technique prevents collisions, it assumes that STAs previously received the time distribution correctly. A third solution makes the ACK/NACK collision-resistant, as in [4]. Although this proposal needs extra hardware, it increases the probability that the feedback is received correctly, even if obtained from collisions. Later, HIMAC [5] proposes using Unary Channels to transmit the feedback to overcome collisions. The last approach is to turn the broadcast messages into individual unicast messages as introduced in the BMW protocol proposed in [7], which was further improved in the BMMM protocol in [8] by grouping the transmissions into a single one and introducing Request for ACK (RAK) messages. Then, the author of [9] proposed an improvement that reduced the number of RAK transmissions. Later, a similar approach in which clients can request the AP to send a multicast stream as unicast was incorporated in the Directed Multicast Service (DMS) of the IEEE 802.11v amendment [10]. Apart from these four general categories, other particular approaches deal with similar problems. One of these approaches overcomes reception errors of multicast messages using the Groupcast with Retries (GCR), adopted in the IEEE 802.11 aa amendment [13]. Further, [PERSON]. [14] combined GCR with the Adaptive Auto Rate Fallback (AARF) method to change the modulation to decrease the Packet Loss Ratio. More recent solutions, such as the one presented by [PERSON] et al. [15], use the RSSI of unicast ACKs coming from non-eBCS APs and deep reinforcement learning to estimate the eBCS STAs. Their work assumes that the distribution on the eBCS and non-eBCS STAs is the same, which might only sometimes occur.