Modelling, simulation and performance evaluation of the IEEE 802.11e protocol with station mobility

IEEE 802.11e capabilities

The MAC protocol used in the 802.11 (Pazzi, Zhang & Boukerche, 2010) standards is the so-called DCF function, which makes all stations in the network compete to access the channel with the same priority. Under this protocol, before starting a transmission, the stations must sense the medium as free for a period given by the DCF Interframe Space (DIFS). If after this period the medium is still busy, they must initiate a Backoff procedure, which is performed by a channel access arbitration algorithm when two or more stations attempt to access the channel simultaneously, generating a collision. When this happens, these stations receive a signal to start the Backoff procedure and stop the transmission. The Backoff procedure delays the transmission for a certain time, thus allowing other stations to complete their transmissions.

Every time the Backoff procedure is triggered, the waiting times increase exponentially to reduce the collision probability with other stations. To calculate the waiting time, the algorithm selects a random value in the interval [0, CW − 1]. The value selected in this interval is directly determined by the contention window (CW). The CW is a parameter defined by the specific physical layer used and is given by the low and upper bounds CW_min and CW_max, respectively. The algorithm first sets the size of CW to CW_min, and then increases it after n erroneous transmissions following a sequence of 2ⁿ until the values reaches the upper bound CW_max. In this case (i.e., if the value of CW reaches the upper bound), the station must discard the frame. Otherwise, every time that the station senses the channel as idle for a DIFS period, one unit is subtracted from the current value. Therefore, this mechanisms allows the station to start the transmission when the counter decreases to zero. Nevertheless, this mechanism gives the same priority to all users and applications. This process is shown in the bottom part of Fig. 2, where the Short Interframe Space (SIFS) defines the period of time that can be employed by packets with high priority, such as ACKs. Notice that ACK control packets are specified by the standard in unicast transmissions to confirm the successful reception of data packets. Consequently, the waiting time of such control frames is lower than the one of data frames to avoid having a long time between the transmission of the data frame and its confirmation, and making the sender (erroneously) retransmit the frame if the ACK is not received after a given period of time.

The original IEEE 802.11 standard and the base DCF method do not provide any QoS assurance. To address this issue, the IEEE 802.11e amendment (LAN/MAN Standards Committee of the IEEE Computer Society, 2005) presented the Enhanced Distributed Channel Access(EDCA) function as an evolution of DCF to bring differentiated channel access and prioritize traffic categories, thus introducing the QoS level required. In this regard, EDCA introduces four traffic access categories (ACs), namely Voice (VO), Video (VI), Best Effort (BE) and Background (BK). While voice traffic has the highest priority and the smallest waiting time, background traffic is defined with the lowest priority. Each AC makes use of its own traffic queue and has its own set of medium access parameters: Arbitration Interframe Space (AIFS), Transmit Opportunity (TXOP), and contention window (CW). It should be noted that the stations employing DCF (i.e., without QoS support) maintain the use of the aforementioned DIFS period, while the QoS stations use the AIFS one. Conversely, the TXOP enables the transmission of several consecutive frames of the same AC without initiating a new sensing channel period. To ensure compatibility with the stations using DCF while respecting the traffic priorities, the standard establishes a fixed set of values for EDCA (Table 1). Variable σ in Table 1 represents the duration of the slot time given by the physical layer. As can be seen in the table, EDCA specifies different waiting times for each type of traffic.

The timing diagram for the different traffic classes in EDCA is shown in Fig. 2. Note that a station must sense the channel idle for a period equal to AIFS before attempting a transmission. Similarly to DCF, a station must follow the Backoff algorithm if it finds the medium busy (Bianchi, 2000).

RTS/CTS as carrier-sensing protocol

The IEEE 802.11 standard introduces Request to Send/Clear to Send (RTS/CTS) as a carrier sensing protocol for collision avoidance to solve the problems introduced by the presence of hidden nodes. Hidden nodes can be described as a set of two or more stations that are not within the coverage range of each other. Therefore, the standard channel sensing protocols are not able to detect whether these hidden stations are about to start a transmission, which consequently generates a huge number of collisions and retransmissions, especially in scenarios containing stations transmitting various traffic types, characterized by different requirements and channel access waiting times. An example of this problem can be observed in Fig. 3, where the coverage ranges of stations a and b do not have common areas despite being connected to the same access point (AP), therefore causing a collision when both of them start a new transmission.

The RTS/CTS protocol aims to serve as a solution to this problem. The main objective is to allow any station to announce its intention to start a new transmission, even if some stations in the network are not in the coverage area of the first one. The message exchange of the protocol is displayed in Fig. 4. By focusing on the previous example (Fig. 3), and in particular, on station a (in blue) starting a transmission, the protocol is established prior to this event as follows. Station b, which is the source of the new transmission, must first send an RTS frame to the AP. When the AP receives this control packet from any station, it must broadcast a CTS frame to all the remaining stations in the network to inform them about the imminent beginning of the transmission, therefore preventing them from starting a new one during a given period of time. This period is provided by the Network Allocation Vector (NAV), which is included in the RTS/CTS frames, and indicates an estimation of the time required by the source stations to occupy the channel. Then, the stations must set their own NAV time to the received one, thus avoiding channel sensing during this period.

As described above, it can be seen how the RTS/CTS protocol is of great help in scenarios with hidden nodes and how it greatly contributes to performance improvement and collision reduction. This is especially important when various types of traffic are present in the network, since in the event that more sensitive traffic is lost in collisions, the performance and the user experience suffer greatly.

Model configuration

We first present the parameters that allow us to configure the CPN model for the 802.11e protocol with station mobility (see Table 2). Some of them will not change in the course of the experiments, and the specific values considered for these are shown in Table 3. Type 1 stations generate saturated traffic, so they immediately produce a new frame after successful transmission. Type 2 stations use an exponential distribution whose rate can be assigned depending on the type of traffic (r2). The variables n1p and n2p indicate the number of type-1 and type-2 stations for each type of traffic: background, best effort, video and voice.

ProdMessages and Start_station CPN pages

Figure 7 shows the ProdMessages CPN page. The CPN depicted was configured with 4 stations of type 2, with 2 sending Background traffic and 2 Voice traffic, i.e., n2p = (2, 0, 0, 2) and n1p = (0, 0, 0, 0).

The transition NewMSG is used to produce new messages and init_fr_tr to take a frame from the queue and start transmission. The starting time for every transmission is saved in the place Process_MSG. The place IST is used to activate new transmissions from each station. A token (n, lms, nb) in this place indicates that station n is ready to start a new transmission, where lms is the last medium state known by this station (1 if busy, 0 otherwise), and nb indicates whether this station requires a Backoff algorithm to be executed before the transmission.

The Start_station CPN page is shown in Fig. 8. Place MEDIUM indicates the current medium state, taking into account the visibility groups. For each visibility group it contains the number of stations that are currently transmitting in that group, so the marking consists of pairs (ng, s), where ng is a group number and s the number of transmissions in that group. The information regarding the access point (AP) is indicated by the color set of place AP : current number of incoming transmissions, AP transmitting(1 or 0, as a Boolean), and collision detected (1 or 0). The color set of ST_CONF contains the following information: station number, AIFS, CWMIN, CWMAX and group number. AIFS, CWMIN and CWMAX are assigned using the priority level of each station, and the group number is initialized randomly, but with the goal of having the same number of stations in each group, or one station more in group 1 when the total number of them is odd.

When a station n is ready to start transmission, the start place is marked with one token (n, lms, nb). Transition start_st starts the medium check, but it can be delayed if RTS/CTS is used and a CTS message has been received, which makes this station wait (control by place Control_Time_CTS). A medium change is detected by the transition MediumChange, which is only fired when the current medium state is different from lms. The function mst is used to capture the current medium state, and need_backoff determines whether a Backoff should be performed or not. We omit here the details of these functions, which can be found in Appendix A. When the medium is free for this visibility group, transition EndTM is fired and the station n can start the transmission (place MedState is marked with a token (n, nb), where nb indicates whether Backoff is required).

StartSend and Backoff CPN pages

Figure 9 shows the StartSend CPN page. Transition Start_Send is used when RTS/CTS is not used (parameter RTS is 0) to start a message transmission, whereas RTS_IMM is used when RTS/CTS is used to start the RTS transmission. These transitions update the medium state information in the place Medium, as well as the AP state information in the place AP. In the event of a collision, this is indicated in the third component of the token in AP. Both transitions are loop-connected² to the place ST_CONF to obtain the binding for the ng variable (current number of the visibility group of station n). When these transitions are fired, a new token is produced in the corresponding Sending place (Sending_Message or Sending_RTS, depending on the use of the RTS/CTS protocol), as well as a token in the corresponding Wait place. Both the Wait_ACK and Wait_CTS places are used to set a time-out and thus detect a failure in transmission.

The first part of the Backoff algorithm is implemented on the Backoff CPN page, as shown in Fig. 10. The transition Backoff starts the algorithm and increases the Backoff counter for station n in the place Backoff_Counter. The current value of CW for station n is obtained with the function get_cw, and it is stored in the place CW, together with the CWMAX value and the current number of the visibility group of the station n. When the current value of CW is greater than CWMAX, the transition Dropfr is fired, which means that a frame is lost. Lost frames are indicated by the marking of the place Lost. In the case of stations of type 1, which produce saturated traffic, a new frame is produced in the place Queue for this station, with the goal of starting a new transmission. A new token is also produced in the place IST, in order to activate a new transmission for this station n. In this case, Backoff is only required for type-1 stations(function new_arrival). The firing of Dropfr also removes the token that was produced for this transmission in the place Process_MSG.

Otherwise, when CW is less than or equal to CWMAX, the transition CBO is fired, which assigns the Backoff counter (place Backoff_Time) as indicated in the section “IEEE 802.11-Based Wireless Networks”, and creates a new token for this station n in the BOMed place, which contains the current medium state known for this station during a Backoff (function mst).

StartfromBO CPN page

Figure 11 shows the StartfromBO CPN page, which corresponds to the second part of the Backoff algorithm, in which the Backoff counter (place Backoff_Time) is decremented until reaching 0. Note that we can have several stations in Backoff at the same time, i.e., there can be several tokens in the place Backoff_Time corresponding to different stations.

Once the Backoff counter is 0, either a frame or RTS transmission starts, depending on the value of the constant RTS. However, the Backoff decrement must stop when the medium is busy, and the visibility groups must be taken into account when updating this information for each station. The transition DecrBO fires at the end of each slot time when the medium is free for station n. This transition decrements the Backoff counter in the place Backoff_Time. When this value is 0, either transition Start_SendBO (start frame transmission, when RTS/CTS is not used) or RTS_ABO (start RTS transmission, when RTS/CTS is used) is fired. In addition, when there is a medium state change, the transition MedChg is immediately fired (note the high priority) to update the information in the place BOMed and update the time at which the token in the Backoff_Time for station n will be available. Specifically, when the medium becomes free, a delay of AIFS microseconds must be applied (function update_bo_time), because the medium must be free during an AIFS period to restart the Backoff decrement.

Transitions Start_SendBO and RTS_ABO initiate a transmission, so a token is produced in the corresponding Sending place, as well as in the corresponding Wait place, as we showed on the StartSend CPN page, when a Backoff process was not required.

RTS and CTS CPN pages

Figures 12 and 13 show the RTS and CTS pages of the model. The RTS page is activated when a station is sending an RTS frame(place Sending_RTS marked). Obviously, several stations could try to send their RTS frames simultaneously, so there can be several tokens in this place. Collisions are detected by the marking in the AP place (third component). Thus, END_RTS is fired when there have not been any collisions in the transmission of an RTS frame, removing the time-out token in the place Wait_CTS. Otherwise, when there has been a collision, once this time-out expires the transition Col_RTS is fired, which records the collision in both the Colls_RTS_ST (counter of collisions for each station) and Colls_RTS (all collisions) places. The token written in the place TM allows the station to retry the transmission, but it must first check the medium state again, and Backoff is required (see Fig. 8: Start_station CPN page).

The firing of END_RTS writes a token in the place INIT_CTS, which, after the SIFS time, starts the CTS page (Fig. 13) for station n. Transition Start_CTS is used to send the CTS message, which updates the AP state information. Collisions of CTS frames occur when a station starts an RTS transmission just before the AP starts the CTS transmission. In this case, the transition Coll_CTS is fired, which records the collision in both the Colls_CTS (all collisions) and Colls_CTS_ST (collisions by station) places. Otherwise, when the CTS transmission is completed(firing of transition CTS_OK), the control times of the tokens in the Control_Time_CTS place must be updated for all the stations except that one sending the message. It should be remembered that these tokens are used to stop the station transmission activity when a CTS has been received. This action is performed by the firing of the transition NewTimes, which also writes a token in the Sending_Message place to indicate the transmission, and another one in the Wait_ACK place to detect failures.

SendMessage and SendACK CPN pages

Figure 14 shows the SendMessage CPN page. When a station n is sending a message there will be a token in the place Sending_Message with its station number. If no collision has occurred, this transmission finishes correctly with the firing of the transition End_Transm. Otherwise, in the presence of collisions, the transition CollMSG will be fired, indicating the collision in both the Colls_MSG and Colls_MSG_ST places. In this case, a new token (n, 2, 1) is also produced in the TM place, in order to retry the transmission, but the medium state must be checked and a Backoff process is required (see Fig. 8). After a successful transmission, the ACK transmission starts (place Sending_ACK marked by the firing of transition Start_ACK).

In Fig. 15 we can see that an ACK transmission can terminate correctly (transition End_ACK) or there can be an ACK collision (transition CollACK). ACK collisions are recorded in both the Colls_ACK and Colls_ACK_ST places, and a new token is produced in the TMP place to retry the transmission. Successful transmissions are recorded in the SUCC_TRANS and SUCC_TR_ST places. In addition, the number of successful transmissions for each station and the average transmission times are calculated in the place Trans_Times. Moreover, in the case of type-1 stations, a new token is produced in the place Time_Arrival_MSG to start a new transmission (function new_imm).

MovGroup CPN page

We use a deterministic model of mobility, with several goals in mind. First, we consider specific mobility scenarios that we can analyze, and the results obtained from simulations can be interpreted in relation to those scenarios. In addition, the simulations must be repeated several times in order to obtain representative results from a statistical point of view, so these executions must be repeated on the same mobility assumptions.

The simulations are executed for a total model time of 15 s, with periods of mobility every 3 s. The total simulation time was chosen to be long enough in order to allow us to obtain performance results from which we can draw conclusions regarding the impact of the network configuration, the number of stations and their mobility. The time for the mobility windows (3 s) was also chosen to allow us to see the impact on performance of the current number of stations in each group. As an illustration, for a configuration with a single type-1 station producing voice traffic, i.e., n1p = (0, 0, 0, 1), n2p = (0, 0, 0, 0), we obtain approximately 11561 messages sent in 3 s using RTS/CTS, and 17910 without RTS/CTS. When RTS/CTS is used, the transmission time for a single message is approximately 259 microseconds (Backoff included). These numbers justify the decision of taking 3000000 microseconds (3 s) for each period, which is enough time to obtain reliable performance results for each period. Although the residence time of the stations in a given coverage sector will heavily depend on the scenario, such as pedestrians on the move in a building or outdoors or vehicular communications, our results allow us to evaluate the performance of the MAC protocol mechanisms as the network setup changes.

Stations are initially divided into two mobility groups of the same size, unless there is an odd number of stations, in which case there will be one more station in group 1. Then, every 3 s some stations move from group 2 to group 1, thus modeling a situation in which a group of people tend to converge at the same location, and thus get closer to each other. However, mobility is problematic when a station is trying to send a frame, so to avoid problems we restrict mobility, and stations can only move to group 1 when they are not transmitting. As a consequence, mobility is delayed until the corresponding station is not transmitting a frame. This is a small delay that hardly affects the comparability of the results when simulations are repeated several times.

In general, for a total number of n stations, when n is even, there are initially n/2 stations in each group, and when n is odd, there are (n + 1)/2 stations in group 1 and (n − 1)/2 in group 2. Mobility is permitted at times 3, 6, 9 and 12 (4 cycles), and the number of stations that move at cycle i is computed as follows: (1)${\displaystyle \mathit{St\_to\_move}\left(m,i\right)=\left\{\begin{array}{cc}M\left[m,i\right]\hfill & \mathit{if}m\le 4\hfill \\ M\left[1+\left(\left(m-1\right)\mathit{mod}4\right),i\right]+\left(m-1\right)/4\hfill & \mathit{otherwise}\hfill \end{array}\right.}$ where/denotes the integer division and m is the number of stations that are initially in group 2, i.e., the total number of stations that must move to group 1 in the 4 cycles of mobility. Function M is defined as indicated in Table 4.

For instance, for n = 3 (total number of stations), there are initially 2 stations in group 1 and 1 station in group 2. Only one station must move to group 1 (m = 1), and this movement occurs at cycle 3 (time 9). In the case where n = 16, we have m = 8, so 2 stations move to group 1 at each cycle.

In Fig. 16, the place PERIOD indicates the following time at which the movements will take place. It is updated with either the firing of transition change or no_change, which increment the token timestamp with the constant time_to_move_st (3000000). Place MOV indicates the stations to move at a certain cycle. Transition no_change is fired when no movement must be made at the current cycle, and thus it simply increments the second value in the token in MOV (current cycle). Otherwise, when one or several movements must be made, transition change is fired, which updates MOV and produces one token for every movement in the place MOVST. Afterwards, transition Move_st fires (due to its high priority) as many times as the tokens we have in MOVST, and at each firing it changes the visibility group of one station that is in the Start state from 2 to 1. Note that this restriction can slightly delay the movements of some stations, until they are in the Start state (once they have finished some transmission), but as mentioned above, these little delays hardly affect the final results.

Other models of mobility

The CPN model presented is designed to support any number of visibility groups, the only page that needs to be changed is the MovGroup CPN page, which implements the specific model of mobility considered. Function M_STCONF, which produces the initial marking of place ST_CONF, should also be extended to indicate the initial number of stations in each visibility group.

On the MovGroup CPN page the changes would mainly affect the bottom part of the CPN, from place MOVT downwards. In principle, both functions ischange and movst should be rewritten according to the new model of mobility, but these changes do not affect the net structure. However, depending on the model of mobility considered, the way in which mobility is implemented by transition Move_st could require structural changes or just simple modifications in the arcs connecting Move_st with place ST_CONF.

Model validation

Validation was carried out by defining a set of test cases which captured the protocol requirements, and all of them were checked by establishing the appropriate scenarios that allowed their validation. Table 5 shows these test cases.

Single priority scenarios

The first two scenarios explore the performance when all stations implement a single priority class, namely VO or BK. Figures 17 and 18 show the network-wide throughput and packet-loss rate results for both traffic classes. In the figures on the left, the results corresponding to the RTS/CTS protocol are presented, while the ones on the right show the results obtained without making use of the protocol. Note that in both figures, the captions in the left part of the legend correspond to the VO traffic, while the colors on the right side correspond to the BK traffic. As can be seen from the figures, the performance results of the VO are very similar in both cases, i.e., with/without RTS/CTS. In the case of a network consisting of 15 and 20 VO stations, the throughput improves as the stations move into the same group. It is clear that the inability to detect the presence of a large number of active nodes has an impact on network performance. The results show that in the case of a network supporting only VO stations, the use of RTS/CTS does not help to mitigate the hidden-node problem. In fact, the IEEE802.11 standard recommends that RTS/CTS should be activated under high-load traffic conditions, with stations mobility and with packet lengths longer than a certain (RTS) threshold, typically 500 bytes.

In the case of the BK traffic, Figs. 17 and 18 show similar results for the case of 5 BK stations. When comparing the results obtained for 5 BK stations with the ones reported for five VO stations, it is interesting to note that the number of BK and VO packets transmitted during the period in which the stations are evenly distributed (time 3s), are quite similar. However, in Fig. 18 we can observe that the BK traffic reports a zero loss packet rate when the RTS/CTS mechanism is used, but a slight loss rate when the mechanism is disabled.Since the BK packet lengths are longer than the recommended RTS threshold, the use of the RTS/CTS mechanism proves effective. Furthermore, the BK traffic throughput is significantly higher when taking into account that the BK packet length is an order of magnitude longer than the VO packet length. In the case of a larger number of BK stations, i.e., 15 and 20, Fig. 17 (left) shows that when stations are evenly distributed between the two groups, the BK throughput considerably increases with respect to the throughput reported when the RTS/CTS is disabled (Fig. 17 (right) at time 3s). However, the figure also shows that the use of the RTS/CTS mechanism slightly penalizes the throughput of the BK traffic in the case when all nodes are placed in the same group, i.e., the throughput reported for the BK at time 15s is slightly higher in the case when the RTS/CTS mechanism is disabled. Figure 17 also shows that when the network’s load is high (15 and 20 stations), the throughput for BK traffic shows a much higher increase to the one reported for the VO traffic. This is the result of an increasing number of collisions of the voice traffic, given the shorter packet lengths used by the VO service. Furthermore, since the Backoff times of the voice traffic are shorter than ones implemented for the BK traffic, the VO stations attempt to access the channel at a higher rate, resulting in a higher number of collisions, and consequently a lower throughput. Note that in all cases, the deviation of the results obtained over the various repetitions of each experiment is almost negligible. For instance, we can observe one of the greatest deviations in the whole performance evaluation in Fig. 17 (right), in which for 15 BK stations at time 15s the standard deviation is 123.29. In this respect, it can be stated that this is a practically insignificant value and that no major differences can be seen over the runs of the experiments.

A contrasting view of the above results is shown in Fig. 18, which depicts the percentage of lost packets over time. In this case, we can observe that the BK traffic is the most affected in the scenarios consisting of a larger number of stations and in the absence of the RTS/CTS protocol when the stations are evenly distributed between the two groups. This protocol proves effective at preventing the long BK data packets from colliding (Fig. 18, left). This statement is supported by the number of RTS frames colliding as a function of time (see Fig. 19). As can be seen from the figure, a higher number of collisions involving RTS packets occur at the beginning of the simulation, when half of the stations cannot sense each other. The figure also shows that the scenarios exhibiting the worst results correspond to those consisting of a larger number of stations, i.e., 20 stations.

In the case of VO traffic, Fig. 18 shows that the use of the RTS/CTS does not prove as effective as for the case of the BK traffic, i.e., the lost packet rate for the VO traffic with/without RTS/CTS exhibits similar values. In fact, in the scenario consisting of 20 stations, the VO packet loss rate is just slightly lower during the first period, i.e., when the VO stations are evenly distributed between the two groups. In the final period, i.e, when all VO stations join the same group, the use of the RTS/CTS protocol only slightly affects the performance of the VO traffic. In fact, the use of RTS/CTS increases the network load, resulting in a higher packet collision probability. By contrast, for BK traffic, in the scenario with 20 stations, a great difference (from 45% to 8%) is observed when enabling the RTS/CTS protocol and the stations are separated into two groups without a common coverage area (at time 3s).

Two-priority scenarios

The second set of scenarios considered a combined workload, with two concurrent traffic types: BK and VO. In this case, the number of stations evaluated varied from 2 to 12 for each traffic type (voice and background), which makes a range of [4, 24] in the stations present. Figures 20, 21 and 23 present the results in terms of throughput, packet loss rate and RTS collisions (when RTS/CTS is used) for the whole network. Taking into account the upper bound in the number of stations derived in the scalability analysis (24), Fig. 21 shows an extremely high percentage of messages lost when the 24 stations are evenly distributed between the two sectors. As can be observed, a protocol with such a number of messages lost would be of little use, i.e., with 24 stations we are at the limits of the application of this protocol for the parameters considered.

Figure 20 shows that the CPN model properly reflects the expected behavior for the workload considered, with both traffic types. For a low number of stations (from 2 BK + 2 VO up to 8 BK + 8 VO) the throughput is nearly the same in both cases (with and without RTS/CTS). In the case of a scenario with a larger number of stations, the use of RTS/CTS proves effective when the stations are evenly distributed between the two sectors. However, when all the stations move into the same sector (from 12 seconds on), the results when the RTS/CTS protocol is disabled are much better given that no extra control overhead is introduced in the network. It is important to highlight that under a configuration consisting of the same number of stations distributed between two traffic types, the network is exposed to a different traffic load. For instance, in the case of 10 VO and 10 BK stations, 20 in total, the network is exposed to a heavier load than in the case of 20 BK stations in our previous experiments. This is due to the shorter backoff period of the VO traffic. On the contrary, the same two-type network configuration will exhibit a lower network load when compared to a network supporting 20 VO stations.

We can also observe that the number of lost packets in the whole network is greater in all the cases in which the RTS/CTS protocol is disabled (Fig. 21). These results are confirmed by the lost packet ratio separated by traffic type, as shown in Fig. 22. Each line displays the results associated with a specific traffic type. For instance, the entry “BK traffic (4 BK STAs + 4 VO STAs)” shows only the percentage of lost packets corresponding to the background traffic when the network is composed of four background and four voice stations. In particular, in Fig. 22, it is possible to see that the most sensitive traffic (voice) is the one experiencing more losses given that it is more affected by collisions than background traffic. It can be observed that enabling the RTS/CTS protocol reduces the percentage of lost traffic for both types. In fact, the RTS/CTS mechanism proves more effective in improving the performance of the BK traffic when the stations are evenly distributed. For instance, in the case of 12 BK and 12VO stations, the BK packet loss drops from 30% to approximately 6%, i.e., a five-fold drop. As for the VO traffic, when RTS/CTS is enabled the lost packet percentage drops by approximately one fourth. Note that for the sake of readability, Fig. 22 only shows the per traffic type results when there are eight, 16 and 24 stations. However, the same results can be derived from the ones presented in Fig. 23.

In line with the above findings, Fig. 23 depicts the evolution over time of the RTS collisions (when RTS/CTS is used) when considering two traffic types. As in the case where a single traffic type was present (Fig. 19), it can be observed that background stations produce a higher number of RTS collisions, due to the long waiting times and the channel usually being occupied by the stations transmitting voice traffic.