## 4 Performance Evaluation
### Clique Topology  
The first part of the simulations considers a clique topology in which all devices can sense one another (no hidden terminals). We present results for different numbers of devices (2, 5, and 20 devices) and for various traffic loads (mean inter-arrival times of 0.9, 0.95, 1, 1.35, 1.5, 2, 5, and 10 s per packet). Since the devices' cycle interval is 1 s, lower inter-arrival times imply that the devices mostly wake up backlogged. On the other hand, an average inter0 arrival time of 10 s/packet indicates a very light load in which, most of the time, there is at most one backlogged device (low collision probability), especially when the number of devices is low. In order to improve the latency, both protocols support the transmission of several packets per cycle (per wake-up), i.e., after transmitting a packet, the device checks whether it has more packets to send, and if it does, it remains awake and contends for additional transmissions. The device goes to sleep only when it is not backlogged (its queue is empty). We emphasize that this multi-packet transmission per cycle enhancement was implemented for both MAR-RiMAC and RI-MAC. Figure 7 depicts the average latency vs. the inter-arrival times for different numbers of devices. The results clearly depict that, as far as the latency is concerned, the performance of both protocols is quite similar, with a slight advantage for the RI-MAC protocol. On the one hand, MAR-RiMAC imposes a slightly higher overhead due to the four-way handshake, yet this overhead is negligible with respect to the cycle time or even the packet transmission time. On the other hand, the contention-handling mechanism of MAR-RiMAC is less time consuming than RI-MAC's, yet since all devices can hear one another, RI-MAC's collision resolution mechanism is very efficient. Note that the longer it takes the sink to resolve collisions, the longer it stays awake, which, on the one hand, increases the latency incurred by the collision resolution mechanism, yet can reduce the average latency by two means. First, the longer the sink stays awake, the more backlogged devices are waking up while the sink is awake, and they can transmit their packets before it goes to sleep, rather than waiting for the next time the sink wakes up. Second, a packet that arrives when the device is awake (e.g., contends for transmission or resolves collision) will be transmitted before the device goes to sleep, while a packet that arrives while the device is asleep will wait for the next cycle. We will re-examine this observation in the following. Note two prominent phenomena: First, interestingly, the average sojourn time for both protocols seems quite high, especially for the low traffic loads, e.g., the average sojourn time for \(N=2\) devices with an inter-arrival time average of 0.9 s/packet is 0.75 s for both the MAR-RiMAC and the RI-MAC protocols. However, note that packet arrival times are independent of device wake-up times. Accordingly, the time clapsing between the arrival of a packet and the next wake-up time of its respective device is, on average, half a cycle (0.5 s). Accordingly, a packet that arrives while its device is asleep will need to wait, on average, half a cycle before its device is awake. After the device is awake, it needs to wait for the sink to be awake before transmitting a packet. Since the wake-up times of the devices are chosen arbitrarily, and since the results presented herein are averaged over all the devices and over multiple runs, the elapsed time between wake-ups of a device and the sink is, on average, an additional half cycle. More interestingly, the results show that for both protocols, the average sojourn time is lower for higher traffic loads than for lower traffic loads, e.g., the average sojourn time for \(N=20\) devices with an