## 4 Performance Evaluation
### Simulation Setup  
We utilized the OMNeT++ network simulation environment with the INET Framework enhancement (version 5.6) to evaluate our protocol. As the connectivity model, we deployed the unit disk graph model, which assumes that each sensor node is equipped with a single omnidirectional antenna and all sensors transmit at the same power. The area within which a signal from one sensor can be received and decoded by another sensor is modeled as a circle, with a radius denoted by the transmission range. We evaluated the suggested protocol in various network densities by generating diverse scenarios comprising a single sink and a varied number of devices. The size of the deployment area was fixed, and the devices were distributed uniformly over the deployment area. We focused on topologies in which all devices were within transmission range with the sink, i.e., could transmit directly to the sink. We examined two basic topologies under this setup: In the first set of simulations, all devices were within transmission range of one another (single-hop topology with no hidden terminals). In the second set, the transmission range was set to allow hidden terminals, i.e., some of the devices were out of transmission (and sensing) range of other devices. In the latter setup, we ensured that there was at least one pair of devices hidden from one another. Since the paper concerns a data collection MAC protocol, our evaluation focuses on traffic generated by the devices destined to the sink (upstream traffic). Traffic was generated at each device according to the Poisson process with varied intensity (arrival rate), where we examined various traffic loads ranging from very high, to moderate, to very light traffic. The sleep interval was set to one second, and the initial wake-up time of each device was randomized in our evaluation. Each simulation lasted 1000 s, and was repeated at least 100 times under different seeds. The results presented herein are an average over the 100 runs. For the MAR-RiMAC, we utilized the ASC scheme that limits the number of devices that can transmit reservations simultaneously. We kept this number at 4 (\(K=4\)), which is very conservative. As discussed in Section 3.2, the number of minislots (\(T\)) required for the reservation process depends on the supported number of reservations taht can be transmitted simultaneously and still be decoded (\(K\)) and the total number of devices (denoted by \(N\)). The duration of each such minislot should encompass the maximum propagation delay between any device and the sink and the time required by the sink to identify that there is a transmission in progress, which can be very short, as it only corresponds to the duration required by the sink to sample the channel and identify that there is a transmission in progress (sufficient for the energy detection mechanism). Both the propagation delay in a few-hundred-meter topology as well as the energy detection mechanism are in the order of a few micro-seconds. In the simulations, we set the duration of \(T\) across all our simulations to be constant (the same as a preamble), which, under \(K=4\), can support over 70 users. Note that the performance under the CSS scheme is expected to be superior to that of the ASC that is depicted below for two reasons. First, the duration of a CSS is much briefer than \(T\). Second, while the number of simultaneously transmitted reservations supported by the ASC is limited by \(K\), with CSSs, the number of simultaneously transmitted reservations is limited by the number of CSSs, i.e., if each device in a neighborhood is assigned a unique CSS, no reservation collisions will occur regardless of the number of simultaneously transmitting devices. For comparison, we also implemented the RI-MAC protocol ([9]). In the following, we present the results attained by both protocols. Accordingly, the main parameters are taken from the RI-MAC paper ([9]). The key parameters we used are summarized in Table 1.  
In the sequel we present the results attained by both protocols.