## 3 Multiple-Access Reservation Receiver Initiation MAC (MAR-RiMAC)
### Collision Resolution  
As previously explained, the sequences are designed to cope with a maximal number of simultaneous transmissions (\(K\)). If more than \(K\) devices are trying to signal simultaneously, the sink will not be able to exclusively identify the signaling set (i.e., collision). Accordingly, in case the sink cannot identify the report-sending devices, it initiates a collision resolution procedure. The collision resolution protocol is based on the binary-tree Collision Resolution Protocol (CRP) (e.g., [57], Chapter 5). Specifically, after the sink realizes that it cannot identify the devices that have sent the RtT, it generates a designated \"Ready to Receive Retransmissions\" beacon (denoted by \"RtRR\"), indicating that all the contending (signaling) devices should participate in the collision resolution procedure. Obviously, all these devices are awake and waiting to be polled for their reports. After receiving an \"RtRR\", each of the colliding (reporting) devices draws a random decision on whether to signal again or stay idle. Explicitly, they signal again with a probability of 0.5 and stay idle otherwise. The devices that choose to wait (draw to stay idle) wait for all the devices that have chosen to transmit their sequence (draw to signal) to be polled for their reports, and, only after, try again to transmit their signals. Specifically, immediately after the sink finishes polling the reports of all devices that signal after the \"RtRR\", it transmits another \"RRtR\" for which all the devices that were involved in the previous collision, yet stayed idle after the previous \"RtRR\", transmit their sequences. The process repeats recursively such that in the case that, after \"RtRR\", more than \(K\) devices have decided to signal (more than \(K\) draw to transmit and, hence, the sink still cannot identify the signaling devices) the sink retransmits another \"RtRR\" for which only the devices that participated in this last failed attempt (collision) redraw and, with a probability of 0.5, retransmit or stay idle otherwise. Since the recursive process follows a tree structure in which each branch terminates by no more than \(K\) devices having transmitted their sequences, all the devices that participated in the first collision can track down the progress and determine their turn to retransmit their sequences. Note that the recursive process resembles the binary-tree CRPs; however, in contrast with these protocols, in which each branch of the tree terminates with no transmitting devices or a single transmitting device, now, each branch terminates with no more than \(K\) devices transmitting their reports. Figure 6 illustrates an example of the collision resolution procedure for \(K=4\). Note that after the sink's awakening RtR beacon, five devices attempt transmission. Since the sink cannot identify them, it sends an \"RtRR\", for which three devices have transmitted \"RtT\". After pooling the three devices, the sink sends another RtR beacon for which the two other devices can transmit their \"RtT\" signals and be pooled consequentially. Remark I: Even though the procedure applies to any \(K\), it is more efficient when the number of devices expecting to contend (with a report to send at a specific time epoch) is much lower than the overall number of devices (which is expected to be very high), i.e., it is most efficient when \(K<<N\) (in which \(N\) denotes the total number of devices). Note that this proportion is very realistic, as we expect the network to be dense, with a lot of reporting devices, yet since each device is expected to wake up and send a report only sporadically, we expect the number of waiting-to-transmit devices at a particular time to be relatively small. Obviously, the set of waiting-to-transmit devices changes at each transmission opportunity based on each device's objective, expected report frequency, duty cycle, etc. Note that when \(N\) is high and \(K\sim N\), other procedures, such as Binary Exponential Beacons (BEBs), work poorly.