# Real-Time Station Grouping under Dynamic Traffic for IEEE 802.11 ah
## 4 Real-Time RAW Parameter Optimization
### Transmission Interval Estimation  
The first main step of the algorithm is determining the estimated transmission interval \(t^{s}_{int}\) and next transmission time \(t^{s}_{next}\) for each station \(s\in\mathcal{S}\). As shown in Algorithm 1, they are estimated based on successful and failed transmissions during the previous beacon interval. A station's transmission is regarded as successful if the AP received at least one packet from the station. If a station was assigned a RAW slot, but no packets were received by the AP during that slot, it is considered a failed transmission. The failed transmission can be be caused by the lack of packets in the station's transmission queue, or by a collision or interference. The algorithm consists of three main blocks: (i) the previous transmission failed (lines 1-3); (ii) the previous transmission was successful, but the one before failed (lines 4-6); and (iii) the last two transmissions were successful (lines 7-16). First, if the previous transmission failed, the transmission failure counter \(\pi^{s}_{\textit{failed}}\) is increased by 1 (line 2). Additionally, this means that the estimated transmission interval \(t^{s}_{int}\) of station \(s\), is too short, as we assume \(s\) had no packets in its transmit queue. In reality, a transmission failure can also be caused by collisions. However, as RAW aims to minimize collisions, we can assume the probability of transmission failure caused by collision is low enough to be ignored. Increasing \(t^{s}_{int}\) sharply could result in overestimation, which results in fewer packets being delivered to the AP and more packets being dropped due to the overflow of station's transmission queue. Although increasing \(t^{s}_{int}\) slowly can lead to a more accurate estimation, it may waste channel access time, as some stations will be assigned RAW slots without transmitting packets, while there will be no channel access time left for other stations that need it. For this reason, the increase of the estimated transmission interval \(t^{s}_{int}\) follows the multiplicative-decrease principle of the Transmission Control Protocol (TCP) congestion control, and it is increased by the number of subsequent failed transmissions multiplied by two. As the number of failed transmission attempts increases, the algorithm assumes its estimation is more wrong and it will increase the interval faster. In the second case (lines 4-6), the failure counter \(\pi^{s}_{\textit{failed}}\) is set to 0 and the transmission interval is estimated as the time difference between the last two successful transmissions. If an accurate \(t^{s}_{int}\) is obtained in case 2, the next transmission will succeed and lead to case 3 (lines 7-16) in which the two last transmissions are successful. If only one packet is received (case 3.1), \(t^{s}_{int}\) is updated in the same way as in case 2 (lines 9-10). If, on the other hand, \(t^{s}_{int}\) is underestimated, \(s\) may transmit multiple packets to the AP (case 3.2, lines 11-12). In that case, the estimated transmission interval is reduced by 1 beacon interval (line 12). Finally, there are two more cases where the current estimated transmission interval is not larger than the beacon interval (i.e., \(t^{s}_{int}\leq 1\)) and multiple packets were received from the station \(s\) by the AP (i.e., \(\pi^{s}_{b,r}>1\) (cases 3.3 and 3.4). In case 3.3 (lines 13-14), the number of received packets is higher than the estimated number of expected packets (i.e., \(\tau^{s}_{b,r}>1/t^{s}_{int}\)) and the transmission interval is reduced by adding 1 to the inverse (line 14). Case 3.4 (lines 15-16) represents the inverse case, where fewer packets are received than estimated, and the transmission interval is increased by subtracting 1 from the inverse (line 16). Finally, the next transmission time is calculated as the last successful transmission plus the newly estimated transmission interval (line 17).