Modeling and simulation of the IEEE 802.11e wireless protocol with hidden nodes using Colored Petri Nets

Abstract

Wireless technologies are continuously evolving, including features such as the extension to mid- and long-range communications and the support of an increasing number of devices. However, longer ranges increase the probability of suffering from hidden terminal issues. In the particular case of Wireless Local Area Networks (WLANs), the use of Quality of Service (QoS) mechanisms introduced in IEEE 802.11e compromises scalability, exacerbates the hidden node problem, and creates congestion as the number of users and the variety of services in the network grow. In this context, this paper presents a configurable Colored Petri Net (CPN) model for the IEEE 802.11e protocol with the aim of analyzing the QoS support in mid- and long-range WLANs The CPN model covers the behavior of the protocol in the presence of hidden nodes to examine the performance of the RTS/CTS exchange in scenarios where the QoS differentiation may involve massive collision chains and high delays. Our CPN model sets the basis for further exploring the performance of the various mechanisms defined by the IEEE 802.11 standard. We then use this CPN model to provide a comprehensive study of the effectiveness of this protocol by using the simulation and monitoring capabilities of CPN Tools.

1 Introduction

IEEE 802.11 networks are used in daily operations in both professional and personal spheres, including video streaming, social media and Internet of Things (IoT) applications. The original standard implemented the Distributed Coordination Function (DCF) as basic medium access mode using the Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA) method to detect collisions. However, DCF is unable to provide traffic differentiation for the variety of services and lacks of efficiency when the number of users increases. To partially mitigate this problem, Quality of Service (QoS) mechanisms in the IEEE 802.11e amendment [1] were introduced through the Enhanced Distributed Channel Access (EDCA) function as an extension of DCF.

Despite Wireless Local Access Networks (WLANs) were initially designed to provide short range connectivity, the tendency of the society to be permanently connected has made this wireless technology being extended to cover mid- and long-range communications and a higher number of devices through amendments such as IEEE 802.11ah [2]. This is especially relevant in outdoor deployments, i.e., urban and rural areas [3], to enable longer transmission coverage. This change in perspective puts the hidden node problem in the spotlight on research, in which several users erroneously sense simultaneously the medium as idle, therefore causing collisions and interference [4, 5]. To mitigate this effect, the IEEE 802.11 standard introduced the Request to Send / Clear to Send (RTS/CTS) exchange. However, its use is optional due to the significant overhead that it may incur [6]. The hidden terminal problem is intensified when managing QoS requirements of a mixture of services including video streaming [7], VoIP [8], and downloads of high-size files [9], which results also in the coexistence of saturated and intermittent traffic [10, 11].

Although all the working groups responsible for the 802.11 amendments have the common objective of optimizing Wi-Fi networks, the specific improvements aimed in each amendment are not necessarily aligned with the remaining ones, especially on a time difference between them. This is precisely the case of the DCF mechanism and the IEEE 802.11e amendment when it comes to long-range WLANs such as in IEEE 802.11ah [12, 13]. As a consequence of this misalignment, even a low number of users using QoS differentiation may bring the network to a saturation state in the presence of hidden nodes, thus leading to huge inefficiencies [14]. This heterogeneous ecosystem intensifies even more the necessity of validating in a unified manner the behavior of 802.11e in scenarios covering hidden nodes instead of analyzing each part of the problem separately, i.e., hidden nodes, channel access mechanisms, and traffic prioritization in IEEE 802.11.

Carrying out controlled experiments while taking into account this wide variety of scenarios using experimental testbeds or even high-level simulators is a major challenge. Moreover, relying on real-world testbeds presents the added drawback that commercial wireless cards do not often comply with all the requirements defined in the IEEE 802.11 standards, which makes the validation even more difficult and inaccurate [15]. For example, the difference in performance between the use of burst traffic or interference issues is so small that both phenomena are unable to be distinguished with these methods. A huge body of research has been devoted to study this issue using either simulation and experimentation [16,17,18,19], or analytical models aiming at shedding some light to the problem without involving costly and lengthy simulations that may not be able to collect all the hidden insights of the evaluated scenarios. Many of these analytical works are based on stochastic models, and especially on Markov chains [20,21,22,23,24], as well as on Petri Nets (PNs) models [7, 25, 26].

In this paper, we use Colored Petri Nets (CPNs) [27] to create a flexible and configurable model of the IEEE 802.11 protocol in the presence of hidden nodes with QoS support that allows us to analyze its behavior in various scenarios while jointly considering hidden terminals, various traffic patterns, and different types of services. Colored Petri Nets [28] are a mathematical formalism that enables the description of the behavior of concurrent systems rigorously, with the main advantage of having a graphical and intuitive representation, which allows us to easily create, edit, simulate and analyze the models by using the wide spectrum of existing PN tools. In particular, we have relied on CPNs, which extend the classical model with both data and time, and are supported by a widely-known tool, namely CPN Tools [29], which allows us to simulate the model and obtain performance results. Then, we have created a CPN model of the IEEE 802.11e protocol in network deployments considering hidden terminals. In this respect, we first study the effectiveness of the hidden-node mitigation and priority mechanisms in the context of a long-range wireless setup operating under extreme traffic conditions and in the presence of hidden-node issues. Then, we evaluate the performance of wireless network operating under moderate-load conditions and concurrently supporting delay-sensitive and delay-tolerant applications. Our evaluation tool and scenarios set the basis for further evaluation studies in the context of emerging wireless standards, such as the IEEE 802.11ah.

The remainder of the paper is organized as follows. Section 2 provides an overview of the IEEE 802.11 protocol and the main aspects of Colored Petri Nets. In Sect. 3, we present the CPN model proposed for the IEEE 802.11 protocol with priority classes. Section 4 presents the model validation. The evaluation methodology and the results obtained are discussed in Sect. 5. Section 6 describes the related work. Finally, we draw conclusions and lines for future research in Sect. 7.

2 Background

In this section we give an overview of the most relevant properties of the IEEE 802.11 standard, and afterwards we provide an introduction to CPNs.

2.1 IEEE 802.11 protocol

The description of the IEEE 802.11 standard can be divided into two main parts with respect to this work. First, the wireless medium access when introducing traffic priority classes is described. Second, the RTS/CTS message exchange in the presence of hidden terminals is outlined.

Table 1 Medium access parameters in IEEE 802.11e

2.1.1 Medium access with priority classes

The medium access method most widely used in the 802.11 family of standards is the so-called DCF function, in which all stations compete for the channel with the same priority. In this distributed method, 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 start the Backoff algorithm, a channel access arbitration algorithm that estimates the period of time that a station must wait before attempting retransmission due to the deferred operation.

Fig. 1

Interframe spaces in the DCF and EDCA functions

To calculate the waiting time, the Backoff algorithm selects a random value in the interval $[0, { CW} - 1]$. This interval takes as a parameter the Contention Window (CW), which is given by the physical layer and is represented by the low and upper bounds, ${ CW}_{ min}$ and ${ CW}_{ max}$. Initially, the size of CW is set to ${ CW}_{ min}$. After n erroneous transmissions, CW is increased following a sequence of $2^n$ until reaching the upper bound ${ CW}_{ max}$. If the maximum limit is reached, the frame is silently dropped. Otherwise, the current value is decreased by one every time the channel is sensed as idle for a DIFS period. When the counter reaches zero, the transmission begins. Nevertheless, this mechanism gives the same priority to all users and applications. This process is shown in Fig. 1, where the Short Interframe Space (SIFS) represents the time used by high priority actions such as ACKs. We remind the reader that the standard specifies a two-way handshake protocol for unicast transmissions in which the stations must confirm frame receptions using ACKs to ensure transmission reliability [30].

Given the lack of QoS, the IEEE 802.11e amendment [1] introduced EDCA as an extension of DCF while providing differentiated and prioritized traffic access. EDCA tackles this problem by defining four traffic Access Categories (ACs), namely Voice (VO), Video (VI), Best Effort (BE) and Background (BK), from highest to 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), which is also given by two bounds CW_min and CW_max.

To ensure compatibility with the stations using DCF while respecting the traffic priorities, the standard establishes a fixed set of values for EDCA. These values are shown in Table 1, where $\sigma$ represents the duration of the slot time given by the physical layer. Unlike DCF, EDCA specifies different waiting times for each type of traffic. As shown in Fig. 1, a station must sense the channel idle for a period equal to AIFS before attempting a transmission. The AIFS is the translation of the DIFS period but allocated per AC when using QoS mechanisms, i.e., the DIFS is invalidated and four different values are instead used per type of traffic. Conversely, and similarly to DCF, the Backoff algorithm is executed in case of finding the medium busy with the exception of using a specific CW size on an AC basis. Finally, TXOPs enable the transmission of multiple streams without gaining medium access every time that a frame is transmitted and are exclusively used in real-time applications.

Fig. 2

Hidden node example scenario

Fig. 3

Working mode of the RTS/CTS protocol exchange

2.1.2 RTS/CTS carrier-sensing protocol

Despite the improvements introduced, the two medium access functions described above and the hand-shake protocol for frame acknowledgment have proved not to be enough to guarantee robust transmissions, especially in highly diverse scenarios that can involve hidden nodes. This phenomenon can be observed in the example depicted in Fig. 2. At a given time, station A sends a frame to station B, which cannot be heard by station C, since it is not in the coverage area. Therefore, station C apparently finds the medium idle and starts a new transmission to station B. As a consequence, the two frames collide at the receiver and station B is not able to decode any of them.

With the purpose of addressing this problem, the standard introduces the RTS/CTS protocol (illustrated in Fig. 3), which allows a station to indicate the intention to begin transmission by sending an RTS frame to the Access Point (AP). Upon its reception and if the medium is idle, the AP broadcasts a CTS frame to all the users in the network. Once the source station receives the CTS frame correctly, it can proceed with the transmission. The Network Allocation Vector (NAV), located at the MAC header of the RTS/CTS frames, gives an estimation of the amount of time that the medium will be busy in handling the transmission. On the basis of this information, the remaining stations must update their NAV time during which they are not allowed to sense the status of the channel. Therefore, regardless of their location, this protocol makes it possible to inform all the stations about the beginning of a new transmission, and the waiting time before sensing the channel again. As a result, collisions are reduced and the performance of the network is improved when hidden stations are present.

2.2 Colored Petri Nets

A Petri Net [28] is a directed bi-partite graph with nodes of two types: places (drawn as circles) and transitions (drawn as rectangles). An arc can connect either a place with a transition (pt-arc) or a transition with a place (tp-arc). Let P be the set of places, T the set of transitions, $X = P \, \cup \,T$ (nodes) and $F \subseteq (P \times T) \,\cup \, (T \times P)$ the set of arcs. For any node $x \in X$ (place or transition), we define the preconditions and postconditions of x, denoted by $~^{\bullet } x$ and $x^\bullet$ respectively, as follows: $~^{\bullet } x=\{y \in X \,|\, (y,x) \in F\}$, $x^\bullet = \{ y \in X \,|\, (x,y) \in F\}$.

Places usually represent states or system conditions, while transitions are the actions or events that produce changes in the system state. Places can have an associated marking, which is a natural number indicated beside the place (number of tokens in it). This number can be used for instance to indicate the number of packets or the number of processes in a queue.

Pt-arcs are also labeled with a natural number (arc weight) to indicate the number of tokens required to execute (fire) the outgoing transition. The value by default is one, in which case there is no need to explicitly indicate it. The same notation applies to tp-arcs, but in this case the weight indicates the number of tokens to be produced in the outgoing place when the transition is fired. Thus, for a transition to be fireable (enabling condition) all its precondition places must have at least as many tokens as the weight of the arc that connects them to the postcondition transition. The firing of a transition t has therefore the following effects:

• For each precondition place $p \in ~^{\bullet } t$, a number of tokens equal to the weight of the pt-arc (p, t) are removed from p.

• For each postcondition place $p \in t^\bullet$, a number of tokens equal to the weight of the tp-arc (t, p) are produced in p.

In the simple Petri net model, no time information is considered and no information can be associated to the tokens and places, which are two important features required to model concurrent systems. CPNs [27] are an extension to the original Petri nets which incorporate data and time, allowing the modeling of complex data structures attached to tokens and time restrictions in the sequence and synchronization of the processes involved. Thus, in CPNs, places have an associated color set (a data type), which specifies the set of permitted token colors at a given place. CPNs are supported by a widely-used tool, namely CPN Tools [29], which allows us to create, edit, simulate and analyze CPNs. The notation described below is the one used in this tool.

A place can have no attached information at all, as in the plain model. In this case, we indicate UNIT as the color set of the place. But a place can now have as a color set, for instance, the set of integer numbers ${ INT}$, a Cartesian product of two or more color sets as in ${ INT2}={ INT}\times { INT}$, a string $({ STRING})$, etc. In this case, each token has an attached data value (color), which belongs to the corresponding place color set. Furthermore, we can use the timed features of Colored Petri Nets. In this type of nets, a discrete global clock is used to represent the total time elapsed in the system model; and places can be either timed or untimed. In the case of timed places, their tokens have an associated timestamp, which indicates the time at which they will be available and thus usable to fire a transition. In CPN Tools, the current number of tokens in every place is drawn on a green circle on the right-hand side of the place, and the specific colors of these tokens are indicated by the notation n‘v, meaning that there are n instances of color v. The symbol ‘++’ (respectively ‘+++’ for timed tokens) is used to represent the union of colors in CPN Tools. Thus, a timed integer place (color set int timed) with a marking $4`3@5+++6`19@10$ has 4 tokens with value 3 and timestamp 5, and, 6 tokens with value 19 and timestamp 10.

The arc inscriptions are now extended to color set expressions, which are constructed using variables, constants, operators and functions. The arc expressions must evaluate to a color or multiset of colors in the color set of the attached place. These colors (tokens) will then be consumed or produced when the corresponding transition is fired, as explained below. Both pt-arc expressions and tp-arc expressions can have time inscriptions, with the syntax ${ expression}@x$. In the case of pt-arcs, these timed expressions are used to allow the corresponding transition to consume the tokens that match the expression in advance, i.e., these tokens can be consumed at a time equal to their timestamp minus the value x indicated in the arc expression. On the other hand, in the case of tp-arcs, the tokens produced by evaluating expression have an age equal to the current time increased by x time units (0 by default). Delays can also be indicated in transitions, with the syntax $@+x$, which means that all tokens produced will have the current time plus x as timestamp. Furthermore, transitions can have guards that restrict their firing, as well as priorities. Guards are Boolean expressions constructed by using the variables, constants, operators and functions of the model, and they must evaluate to true for the transition to be fireable. Transitions can also have an associated priority, so in the event of a conflict between two transitions that can be fired at a given time, the one with the highest level of priority is fired first. We only use two levels of priority, namely P_NORMAL (by default) and P_HIGH, the latter being higher than P_NORMAL. Priorities are indicated on the lower left corner of transitions, but in the case of P_NORMAL, these are not usually shown.

Fig. 4

CPN modeling a simple protocol

Let us now see how arc expressions are evaluated and the firing rule for CPNs. For any transition t with variables $x1,x2,\ldots$ in its input and output arc expressions, we call a binding of t an assignment of concrete values to each of these variables. A binding of a transition t is then enabled if there are tokens in its precondition places matching the values of the corresponding inscriptions. For instance, for the pt-arc expression $2`x++4`y$ we need to assign variable x a value such that we have 2 tokens with this value in the input place, and a value to y such that we have at least 4 tokens with this value in the input place. Thus, arc expressions are evaluated by assigning values to the variables, and these values are then used to select the tokens that must be removed or added when firing the corresponding transition. When no transition can be fired at the current time, time elapsing occur, but only up to a time at which some transition can be fired.

Example 1

Figure 4 shows a CPN modeling a simple protocol. In this CPN, places Start, TimeOut, St_fail, Sending and St_ok have the INTt color set, which stands for timed integer (int timed in CPN Tools). Place Medium has the ${ INT2}={ INT} \times {INT}$ color set. Transition Success has a guard associated (s=1), meaning that it can only be fired when the variable s is bound to 1.

At the initial marking only the places Start and Medium are marked. A function M_INIT is used to produce an initial marking for place Start (see Listing 1). Functions in CPN Tools are defined using an extended version of the ML language [31], and M_INIT has a natural number as argument, which indicates the number of tokens (stations) to be produced at the Start place. Notice that the dexp function is used to produce the timestamp for each token, which is generated by using an exponential distribution with rate 1/50. Therefore, the figure depicts the three tokens produced with integer values 1, 2, 3 (representing station identifiers), and timestamps 197, 194 and 308, respectively.

Place Start models the initial station state, which consists of three stations which will start to transmit a message at their corresponding timestamps. Place Medium stands for the communication medium state. This place will always be marked with a single token. The first field of this token represents the number of stations that are currently trying to transmit a message, while its second field is a Boolean indicating whether there has been a collision. Thus, the initial marking of place Medium is (0, 0).

A station starts the transmission by firing the Send transition, which produces one token in place TimeOut and one token in place Sending. The token in Sending will be available after TSEND time units, while the token in TimeOut will be available after ${ TSEND}+{ TOUT}$ time units. In addition, the medium state is changed, increasing the number of stations trying to transmit and updating the collision state using the send function, which assigns the collision state to 1 when several stations are trying to transmit simultaneously.

At time 194 transition Send fires, producing the token 1‘2@214 in Sending and the token 1‘2@224 in TimeOut. Moreover, the token in Medium changes to (1, 0). Then, at time 197 station 1 starts its transmission, also producing one token in Sending, with value 1‘1@217 and one token in TimeOut with value 1‘1@227. Notice that place Medium also changes to (2, 1), indicating a collision. Neither of these transmissions can therefore be successful, so transition Fail is fired twice (notice the arc inscription (s, 1) from Medium), at times 224 and 227. The firing of Fail also removes the corresponding token for station n in place Sending. Thus, after both firings place Medium is marked again with (0, 0) and there is one token in place Start with value 1‘3@308.

Finally, station 3 starts at time 308, firing the Send transition, producing both tokens in TimeOut and Sending, and changing the marking of Medium to (1, 0). Then, transition Success fires at time 328, which also removes the corresponding token from TimeOut. Notice the timed inscription used in this pt-arc to consume this token in advance: $n@+({ TSEND}+{ TOUT})$. This pt-inscription, as indicated in Sect. 2.2, means that this token can be consumed ${ TSEND}+{TOUT}$ time units before its time stamp. Place St_fail collects the failed transmissions, while place St_ok collects the successful transmissions.

The CPN in Fig. 4 represents a very simple system. In general, we will have to deal with larger CPNs in which the use of the hierarchical features of CPN Tools will allow the decomposition of the model into various smaller subnets. These subnets, called pages in the CPN Tools terminology, should be linked using substitution transitions and fusion sets. Substitution transitions refer to transitions replaced by subnets represented in other pages, while fusion sets are sets of places used in different pages, which are functionally identical and therefore correspond to the same place from a formal viewpoint. In this paper, we have made use of fusion places to split the model into pages. The link of these pages is made through their common places, denoted by a blue fusion label at their left bottom corner.

3 IEEE 802.11 CPN model

In this section we first present the characteristics of the network system based on the IEEE 802.11 standard (and specifically on the IEEE 802.11e amendment) considered in the CPN model, and then we introduce the proposed model by describing its CPN pages.

3.1 IEEE 802.11 network system configuration

The problem analyzed in this paper verses on the impact of the priority mechanisms introduced in IEEE 802.11e. However, the system modeled does not aim to independently evaluate the performance of this mechanism of the standard, but to analyze its behavior when it is enabled in any Wi-Fi network, where we may find a broad set of traffic patterns and services, i.e., intermittent/saturated traffic, different bitrates, etc., channel states, and topologies. Moreover, it is our standpoint that the proposed system model must be as reusable as possible for any Wi-Fi network, i.e., any version of the standard, to pursue innovation by facilitating its modification and adaptability to any new version. With this objective in mind, the following constraints must be taken into account:

• The traffic priority mechanisms introduced in IEEE 802.11e must be a common factor in all the physical layers and can be used across different versions of Wi-Fi networks. Therefore, the variables defining both the physical and the channel access layers must be configurable enough for allowing further analysis of other versions of the protocol. In this respect, we can highlight physical and channel access timings, such as slot time, AIFS, CW_min and CW_max, as introduced in Sect. 2.1.

• The model must not enforce a specific transmission rate (which depends on the physical layer and is independent on the priority mechanisms) or a exact packet length for any traffic type. In this respect, both parameters must accept modifications regardless of the service type.

• Any Wi-Fi network must be able to manage traffic with different nature: burst or saturated traffic. However, the frequency of burst, i.e., intermittent, traffic can highly differ from each other. In this sense, traffic nature must be modeled using a parameter that allows setting its inter-arrival period and frequency.

• The model must not assume any network topology, user density or range. For that reason, the dimension of the network must be configurable. This constraint is translated into the impossibility of knowing at any moment if a given user is in the coverage range of any other. For that reason, regardless of the network dimensions, the possibility of enabling the RTS/CTS mechanism introduced in Sect. 2.1.2 must be included. It should be noted that one of the main objectives of our analysis is to verify the effectiveness of the priority mechanisms of the IEEE 802.11 protocol in the presence of hidden nodes.

Table 2 Parameters used for the CPN model

The previous constraints can be specifically translated into network specific parameters to be considered by the CPN model to cover a wide range of representative scenarios. Such a model is based on the following considerations:

• Network topology. The network consists of N stations randomly distributed in a way that they cannot overhear each other, with the goal of studying the effect of the hidden terminal problem.

• PHY/MAC layers. The network is modeled using configurable timings and transmission rates in order to analyze the behavior of current and future physical layers in the standard.

• Channel conditions. Communications take place where transmitted data are never affected by errors in the channel, apart from those caused by deferring time of the stations and frame collisions.

• Traffic bitrate. A station is either under (i) saturated condition, i.e., it always has a packet to transmit, or follows (ii) an intermittent transmission, based on a negative exponential distribution. Moreover, the data can be delivered at a given bitrate regardless of the distribution.

• Traffic type. Each station transmits a unique type of traffic as given by the IEEE 802.11e amendment, i.e., (i) background, (ii) best effort, (iii) video, or (iv) voice traffic.

• RTS/CTS control. The RTS/CTS exchange can be (i) enabled, or (ii) disabled for all the stations in the network.

Table 2 indicates the resulting parameters from the constraints described before, which can be adjusted for the analysis of any scenario. In particular, the integer variables shown in the table represent the specific values that have been maintained all along the experiments performed. Note that they have been selected with the aim of being compatible with IEEE 802.11b/g [32] (using long preamble option) given that most common wireless cards on the market follow these standards. However, the same study can be extended to any other physical layer by modifying the values of the PHY/MAC layers. Conversely, the values denoted as variable are further described in Sect. 5 given that they are modified across the various experiments to evaluate a wider number of scenarios. Notice how the variable names shown in this table are intended for facilitating human comprehension, therefore being the specific variable names used in the model described in Listing 2. Finally, a particular case is found in the variable Time Send, which can be defined as a common denominator across all the categories defined, since its value depends on the ones chosen for the rest of the variables.

The transmission times of a data frame and the corresponding acknowledgment are given by $T_{ data}$ and $T_{ ACK}$. The data rate follows the 802.11b/g PHY, taking 1 and 2 Mbps for the basic ($R_{B}$) and transmission rate ($R_{ TX}$), respectively. Hence, the transmission time (defined in the model as TIME_SENDING) varies depending on the scenario and the type of traffic. Finally, $T_{ RTS}$ and $T_{ CTS}$ provide the times needed by the RTS/CTS exchange.

$$\begin{aligned} T_{ data}= & {} { AIFS} + \frac{{ PHY}_{ header}}{R_B} + \frac{({ MAC}_{ header} + P) \cdot 8}{R_{ TX}} \end{aligned}$$

(1)

$$\begin{aligned} T_{ ACK}= & {} { SIFS} + \frac{{ PHY}_{ header}}{R_B} + \frac{({ MAC}_{ header} + { ACK}_{ size}) \cdot 8}{R_{ TX}} \nonumber \\\end{aligned}$$

(2)

$$\begin{aligned} T_{ RTS}= & {} { AIFS} + \frac{{ PHY}_{ header}}{R_B} + \frac{({ MAC}_{ header} + { RTS}_{ size}) \cdot 8}{R_{ TX}} \nonumber \\\end{aligned}$$

(3)

$$\begin{aligned} T_{ CTS}= & {} { SIFS} + \frac{{ PHY}_{ header}}{R_B} + \frac{({ MAC}_{ header} + { CTS}_{{ size}}) \cdot 8}{R_{TX}}\nonumber \\ \end{aligned}$$

(4)

3.2 CPN network model

In this section we describe the CPN model for the 802.11 protocol. This is a configurable and flexible model, which allows us to have different versions of the protocol by changing the model parameters, as indicated in Table 2 and more specifically in Listing 2, where we show a configuration example. For instance, a Boolean parameter RTS (see Listing 2) allows us to have two versions of the protocol, one using the RTS/CTS mechanism and another one not using this mechanism. In the CPN model, two station types are considered. On the one hand, stations that produce messages consecutively, i.e., as soon as a message has been delivered, a new message is in the queue to be sent, thus producing saturated traffic on the medium; and, on the other hand, stations that produce messages according to an exponential distribution, with the rate r2, as indicated in Listing 2.

The n1p parameter is an array representing the number of stations of each type (background, best effort, video, and voice) that send messages consecutively, while n2p represents the number of stations of each type that send messages by using the exponential distribution.

Thus, we can assign different values for nt1, nt2, n1p and n2p in order to model a variety of scenarios in the protocol execution. Listing 2 shows a scenario in which there are no stations sending consecutive messages (${ nt1}=0$) and there are 5 stations sending intermittent traffic using an exponential distribution (${ nt2}=5$). In this scenario, we have 3 stations sending video traffic and 2 stations sending voice traffic, in both cases following an exponential distribution (n2p). The other parameters are evident from their names. Notice that TIME_SENDING, AIFS, CWMIN and CWMAX are also defined depending on the station priority, i.e., on the type of traffic. There are also a significant number of ML functions in the CPN Model, which are required for several purposes, such as to initialize markings, to compute expressions in arc inscriptions, etc. These functions can be found in Listing 5 in Appendix A.

In this CPN, INTt is the timed integer color set. In general, ${ INTn}$ denotes a product color set of n integer types: ${ INTn}=\overbrace{{ INT} \times \ldots \times { INT}}^{n}$, and INTnt denotes its timed version.

The CPN model consists of eight pages, which are described below. Fusion places are then used to identify the shared places across these pages.

3.2.1 ProdMessages CPN page

In this CPN page depicted in Fig. 5, the initial messages to be sent by each station are produced in the Last_Arrival_Time place. These initial messages are generated by the function M_MSG, which generates a timed integer token for each station. The value of this token is the station number, and its timestamp is the time at which this message can be sent. As indicated in Listing 2, there are nt1 stations of type-1 (producing messages consecutively), and nt2 stations of type-2 (whose messages are generated using an exponential distribution). Therefore, stations are numbered so that the first nt1 stations are of type-1, and the remaining ones are of type-2.

Fig. 5

ProdMessages CPN page

Transition New_MSG is fired when a message can be sent. In particular, in addition to this, for type-2 stations the function gen_new_time produces a new token in Last_Arrival_Time to prepare the next message for this station, using the exponential distribution with rate r2. Place Total_MSG_(Ev) is a counter for the messages produced for type-2 stations, so it is updated when NEW_MSG is fired. Once NEW_MSG has been fired, a new token is written into place Time_Arrival_MSG, which represents the input message buffer.

A station starts processing a message by firing the transition init_st, which configures the station parameters (place ST_CONF). This place contains the station configuration with the following fields: station number, AIFS value, CWMIN, and CWMAX. Thus, the treatment of each station depends on the specific information written in the place ST_CONF for that station, which is taken from the different traffic types. The other precondition place of init_st is IST, which stores the station state information, with the following fields: station number, last medium state known (0 free, 1 busy), Backoff needed (Boolean) and CTS received (Boolean).

Once the transition init_st is fired, one token containing the station state information is written into the Start place to initiate the protocol. In addition, a token is written into the Process_MSG place, which indicates the time at which this station started this transmission (function intTime() returns the current simulation time).

Fig. 6

Start_station CPN page

3.2.2 Start_Station CPN page

In this CPN page illustrated in Fig. 6, the place MEDIUM contains one token in the color set INT2 for each station, with its local medium state information. The first field is the station number and the second field indicates whether the station is transmitting a message or not. We must recall that this message cannot be seen by any other station, except the AP. Function M_NULL is used to initialize the marking of place MEDIUM to (n, 0) for each station n. Place AP stands for the Access Point state information. This place always contains one token, with three integer values. The first field represents the number of incoming transmissions, the second field indicates whether the AP is sending a message (which is visible for all the stations), and the third field is usually 0, but in the event of a collision its value is 1, and it is set to 2 when a CTS message has been sent. The initial marking of place AP  is therefore 1‘(0, 0, 0).

A station starts a new frame transmission by firing transition start_st, which removes the corresponding token from place Start (fusion place with place Start  in page ProdMessages), and writes one token in place TM, delayed by the associated AIFS value.

The arc connecting transition start_st  with place ST_CONF  (fusion place with ST_CONF  in page ProdMessages) is used to read the specific AIFS value for this station. Thus, we guarantee that the station waits for at least AIFS microseconds before starting the transmission (see Sect. 2.1.1). Actually, when a medium-change condition is detected (transition MediumChange, which has high priority), this token in TM is updated (delayed by AIFS microseconds), with the newly required Backoff information and CTS-received information, thus guaranteeing that the medium is idle for this time before starting the transmission. Function need_backoff  returns 1 (backoff required) when the medium is busy or CTS has been received, and function update_cs returns 1 when a CTS message has been delivered. Thus, when the last medium state information known by the station (lms) differs from the current access point medium state (ap), transition MediumChange fires and updates the token in TM corresponding to this station.

Transition EndTM is fired when the wireless medium has been idle for AIFS microseconds, writing one token in place MedState. Note that the value 0 is used in the second field of the pt-arc inscription to indicate this state. Consequently, in this place we indicate the number of the specific station and whether the Backoff algorithm needs to be executed. Finally, place Control_Time_CTS is used to stop the stations when a CTS has been delivered, thus establishing a time-out before any other station can start the protocol, except the station indicated in the CTS message.

Fig. 7

StartSend CPN page

3.2.3 StartSend CPN page

In this CPN page places MedState, Control_Time_CTS, AP and Medium are fusion places, so they are the same as those with the same names in page Start_station. The behavior of this CPN page depicted in Fig. 7 depends on the value of the RTS constant, which enables and disables the RTS/CTS exchange.

• Without RTS/CTS exchange. Transition Start_Send is immediately executed so that the transmission starts. One token is written into the Wait_ACK place to activate a time-out (no ACK received), and another one delayed by the transmission time is written into the Sending_Message place, to indicate the transmission. In addition, both the local medium state and the AP medium state are changed accordingly (one more station transmitting and collision state updated by function update_med, which returns 1 if there were already transmissions in the medium).

• With RTS/CTS exchange. In this case, transition RTS_IMM is fired, which indicates that an RTS message is being sent. As a result, one token is written with the corresponding timestamp (delayed by the transmission time of RTS message) into the Sending_RTS place, and another one into the Wait_CTS place in order to activate a time-out (RTS collision).

Fig. 8

Backoff CPN page

3.2.4 Backoff CPN page

The Backoff  CPN page is depicted in Fig. 8. This page contains the first part of the Backoff algorithm, in which either the Backoff time is assigned and the station enters into the Backoff process or a message is dropped when the maximum value of the CW is reached. In this CPN page, places ST_CONF, Time_Arrival_MSG, Process_MSG and IST are fusion places, they are the same as those with these names in Fig. 5. In the same way, place MedState corresponds to the same place in Fig. 7. Thus, when one token in place MedState in the CPN page shown in Fig. 8 indicates that running the Backoff algorithm is required (the second field is 1), the transition Backoff fires, which updates the corresponding Backoff counter for this station (place Backoff_Counter). When the CW limit is not reached, the firing of transition CBO we produce a new token in the Backoff_Time place and another one in the BO place, which indicate the Backoff times and the stations in Backoff period, respectively. The Backoff time is therefore computed using the algorithm indicated in Sect. 2.1.1. Transition Dropfr will only fire in the event that the CW limit has been reached. In this case, the frame is dropped, so it is annotated in the Lost place and a new frame is produced for this station using the exponential distribution. Function new_i_delayed only produces one token for stations of type 1 (those producing saturated traffic), while new_arrival will produce one token in the IST place, but indicating that a Backoff period is required in the case of stations of type 1 (Fig. 9).

Fig. 9

StartfromBO CPN page

3.2.5 StartfromBO CPN page

This CPN page contains the second part of the Backoff algorithm and the transitions that start the transmission of either the message or RTS frame, depending on the value of the RTS constant. The Backoff time is here decreased to zero by one or more firings of transition DecrBO, and then the transmission starts. In this CPN page, places BackoffTime and BO are the same as those with these names in Fig. 8. In the same way, AP, Medium, Wait_ACK, Sending_Message, Sending_RTS and Wait_CTS are the same as in Fig. 7, and Control_Time_CTS is the same place as in Fig. 6.

The Backoff time is updated by firing transition DecrBO, which is then fired at each time slot. Furthermore, when a CTS message is received by the station, this transition cannot be fired, since the station must wait for a time-out before restarting its activity. Place Control_Time_CTS is used again for this purpose. Once the Backoff time has elapsed, for the RTS/CTS version of the protocol the RTS message is sent (transition RTS_ABO), which is analogous to the transition RTS_IMM in the StartSend CPN page. In the case of the non-RTS/CTS version, transition Start_SendBO is fired, which starts the transmission, in the same way as Start_Send in the StartSend CPN page.

Fig. 10

RTS_CTS CPN page

3.2.6 RTS_CTS CPN page

This CPN page illustrated in Fig. 10 is used only if the RTS/CTS exchange is enabled. In this CPN page, places Sending_RTS, Wait_CTS, AP and Medium are fusion places, they are the same as those with these same names in Fig. 8. When an RTS message is being sent from any station, a token will be in the Sending_RTS place, indicating the station number with a timestamp equal to the time at which this transmission finishes. There is also one token for this same station in the Wait_CTS place, which is used to detect a collision. Thus, when the RTS transmission is successful (END_RTS transition), the Start_CTS transition fires, writing one token in the Sending_CTS place, with a timestamp equal to the end of the transmission. Otherwise, in the event of an RTS collision, the Coll_RTS transition fires, writing a new token in the Colls_RTS place, indicating the collision information. In addition, a station collision counter is updated in the Colls_RTS_ST place.

Note that after a collision one token corresponding to this station is also written in the TM place (see Fig. 6), indicating the last medium information known for this station (s) and that a Backoff process is required. Thus, as we saw in the Start_station CPN page in Fig. 6, this station will wait for the medium idle for a time equal to AIFS before starting its Backoff period.

Transition CTS_OK is fired when the CTS transmission is successful. This transition activates the UpdateTimes CPN page by writing one token in the Update_times fusion place. Finally, a CTS collision is detected by transition Coll_CTS. This transition can only be fired when there is a collision, when the CTS frame is being sent. Observe the value 1 (collision) in the third field in the expression of the pt-arc from AP.

Fig. 11

UpdateTimes CPN page

3.2.7 UpdateTimes CPN page

Figure 11 shows the CPN page that updates the time-outs that the stations (except the one that sent the RTS frame) must wait for transmitting once they have received a CTS message. Place Update_Times becomes marked with one token when transition CTS_OK is fired in the RTS_CTS CPN page. The token in the Stations place is an integer value that is initially equal to the number of stations. This number is decreased as transitions Update_other and Update_n are fired, which update the time-outs for the stations in the Control_Time_CTS place. Other stations except n increase the current simulation time plus a time-out value (function toutcts), so they will not be able to transmit further messages until this time-out elapses. Transition End fires when the number in the Stations place becomes 0, thus resetting this number to its initial value and starting the message transmission for station n. For this purpose, one token is written into the Sending_Message place, indicating that this station is sending a message, with a timestamp equal to the time at which this transmission finishes. Another token is written into the Wait_ACK place to activate a time-out for the reception of the ACK message. Notice the high priority of these transitions to enforce their firing before any other station could start a transmission at this same time. Thus, once CTS_OK is fired, the time-outs are immediately updated and other stations will be forced to wait.

Fig. 12

SendMessage CPN page

3.2.8 SendMessage CPN page

In this CPN page, shown in Fig. 12, we have again several fusion places. Places AP, Medium, Sending_Message and Wait_ACK are the places with the same names in Fig. 10, TM is the same as in Fig. 6, Backoff_Counter is the same place as in Fig. 8, and Process_MSG, Time_Arrival_MSG and IST are the same places as in Fig. 5.

After a successful transmission transition, End_Transm fires. Transition Start_ACK then fires after a SIFS delay to start the transmission of an ACK message. In this case, place Sending_ACK becomes marked with one token, indicating the station number, with a timestamp equal to the time at which this transmission finishes. In the event of a message collision, transition CollMSG fires, updating a counter in the Colls_MSG_ST place and writing one new token in the Colls_MSG place. In this case, a new token is also written into the TM place to retry the transmission, after an AIFS period waiting for the medium to be idle. After this period, the station will start a Backoff period.

Transition End_ACK fires when the ACK transmission is correct, whereas transition CollACK would fire in the event of an ACK collision, which is a very unlikely event, and which depends on the model parameters. When transition End_ACK fires, it means that the message transmission has been successfully performed. Therefore, a new token is written into the place SUCC_TRANS, indicating the station number, and with the timestamp at which the transmission terminated. A counter is also updated in the SUCC_TR_ST place. In addition, the average transmission time of this station is updated in the place Trans_Times. Finally, note that after a successful transmission, the Backoff counter of the station is set to 0, and a new message to be transmitted is produced in place Time_Arrival_Message in the case of a station of type-1, i.e., in a saturated state (function new_imm). A token is also written in the IST place to allow the station to start a new transmission (function new_arrival).

4 Model correctness validation

Validation has been done by defining a set of test cases, which are demonstrated by executing and testing the CPN model under the scenarios considered for them. We have identified 18 test cases to validate the behavior of the CPN model. These test cases check the protocol behavior, so they have been selected to verify that the CPN model behavior conforms the 802.11e wireless protocol, as presented in Sect. 2.1. Each test case is checked by considering several scenarios that cover the test case. Table 3 shows the test cases identified, indicating the CPN pages related with the tests, and thus checked using the specific scenarios associated, which are described in detail in Appendix B.

Most of these test cases can be checked just configuring the CPN model as indicated in the scenarios and running the model using the simulation engine of CPN Tools, but three monitors have also been required for this purpose. Monitors are a mechanism provided by CPN Tools to observe, modify or control a simulation in a CPN model. There are several types of monitor, among them, we have break point monitors and place contents monitors. Break point monitors are used to stop a simulation when a certain condition is fulfilled, for instance, a transition has been fired or a place reaches a certain marking. In contrast, a place contents monitor stops a simulation when a place is either marked (at least one token in the place) or empty (no token in the place), as indicated in the definition of the monitor.

Listing 3 shows the monitors defined for this purpose. The first one, BP_NoSevTransmCTSrec is a break point monitor defined for test case 11 (there cannot be two stations transmitting when CTS was received). This monitor would stop the simulation if the AP place reaches the marking 1‘(2, 0, 2) (line 7 of Listing 3), which indicates that two stations are transmitting and CTS was received, so the test in this case consists in checking that simulations are never stopped by the monitor. Monitor PC_With_RTS_No_CollsMSG is a place contents monitor, which checks that place Colls_MSG is never marked (line 11). This monitor is used to check test case 17 (no message collision when using RTS/CTS), so the test consists in checking that simulations are never stopped by the monitor when variable RTS is set to 1. Notice that message collisions refer to collisions when the message is being sent (after the RTS/CTS exchange). Obviously, we can have RTS and CTS collisions in this case. Finally, monitor PC_no_ACK_Coll is also a place contents monitor, which is used to check test case 18 (no ACK collision when using RTS/CTS), so it would stop the simulation in the event of an ACK collision. None of these monitors stopped the simulations throughout the proofs.

Table 3 Test performed in the CPN model validation

5 Evaluation

The evaluation presented in this section has two goals: (1) to show the capabilities of CPNs as a performance evaluation and protocol analysis tool; and (2) to evaluate the effectiveness and/or shortcomings of the protocol mechanisms being introduced in the IEEE 802.11 standard.

With regard to the first goal, we have used the simulation and monitoring features of CPN Tools to collect the performance indexes of interest, as the number of successful transmissions, the times for these transmissions, the number of lost packets, etc. As said before, monitors allow us to observe, control and modify a simulation in CPN Tools. In particular, we now use a break point monitor to stop the simulation at the maximum simulation time (15 seconds), several count transition occurrence data collector monitors, which allow us to count the firings of the specified transitions, and two write-in file monitors, which allow us to gather the final markings of the specified places of the CPN, by writing them into text files.

Then, we have used the CPN Tools simulator engine to carry out the evaluation of a wireless network consisting of one AP and two or more wireless nodes. For each metric of interest, we have obtained the mean values, typical deviations and confidence intervals by repeating 100 trials of each network setup (scenario). The trials have been automatically launched using the replication function of the CPN Tools software. We have defined a break point monitor to stop the simulation process at the maximum simulation time whose value has been set to 15 seconds, and four count transition occurrence data collector monitors to collect the number of RTS, CTS, ACK and message collisions. These monitors allow us to count the number of times that the corresponding transitions have been fired. We have also implemented one write-in-file monitor to save in a text file the final marking of place Trans_Times. This marking provides us with the average station transmission times at the end of each simulation. Finally, a place MaxCols has been included to count the maximum number of consecutive collisions before a successful transmission, and a write-in file monitor was then defined to collect this information.

Listing 4 shows the code of two of the monitors implemented in our study. Monitor Max Time is the break point monitor to stop the simulation when the simulation time is greater than or equal to 15 seconds, while TransmissionT collects the final marking of place Trans_Times.

As for the second goal, the evaluation of the effectiveness and shortcomings of the protocol mechanisms being introduced in the IEEE 802.11 standard, we have defined three case studies. The first one sets the basis of our study while the two other cases are developed to further explore the effectiveness of the IEEE 802.11 mechanisms and their potential use in a multimedia scenario.

The first case study explores the performance of the hidden-node mitigation and priority protocol mechanisms under saturation conditions: a setup frequently used to determine the bounds of the capacity allocated to different traffic categories [33]. Under these conditions, we should be able to evaluate the two main performance metrics of interest provided by the priority and hidden-node mitigation mechanisms: throughput and losses. We evaluate individually the performance of the various traffic categories, i.e., a case when all the network nodes belong to the same traffic type, and a scenario supporting the highest (VO) and lowest (BK) type. The latter aims at exploring the effectiveness of the priority mechanism in the absence of feedback channel conditions, i.e., it emulates a setup as the one described in [26].

The second and third study cases explore scenarios supporting two types of traffic under different network load conditions. The scenarios of these two latter case studies have been defined taking into account the results obtained in the first part. They provide further insights on the choices to be made when setting the parameters of multi-priority scenarios in the presence of hidden nodes. The second scenario focuses on exploring the effectiveness of the priority and hidden-node mitigation mechanisms under hidden-node and non-saturated conditions: it provides further insight on the bandwidth allocated and losses to each priority as a function of the network load.

Regarding the third scenario, our goal is to explore the use of the BE priority as an alternative solution to support voice services. Accordingly, we first set up a scenario consisting of multiple nodes making use of the VO priority setting. We then make use of the BE service to explore the service received by the sources operating under the same conditions as the ones in the previous setting. The main goal is therefore to explore the use of a less-aggressive backoff mechanism, the BE, as a manner to enhance the multiplexing gain at the expense of degradation to the service provided to the VO sources. We also consider two different packet sizes. This latter parameter plays an important role in time-constrained applications, such as VO services.

5.1 Case study I: saturated traffic conditions

This case study allows us to explore the effectiveness and shortcomings of the hidden-node mitigation method and the QoS mechanisms under extreme conditions. The network setup consists of an AP and two stations operating under saturated conditions. All stations can sense the activity of the AP, but they cannot sense the activity of each other due to the distance between them.

Table 4 shows the scenarios considered in this case study, which are classified depending on the use of RTS/CTS or not. In these experiments, we have considered two packet sizes (100 bytes and 1500 bytes), regardless of the traffic priority, since the time wasted by collisions severely depends on the frame transmission time. Moreover, since the length of the Backoff mechanism depends on the traffic priority, each scenario analyzes a single traffic type, except for scenarios 1, 6, 11 and 16. These last scenarios, consisting of one BK and one VO stations, aim at evaluating the effectiveness of the priority mechanism. Notice that the [S] label next to the number of stations indicates the delivery of saturated traffic.

Table 5 shows the average performance results for the scenarios when the RTS/CTS mechanism is disabled, in which we report the total number of packets transmitted, the number of packet transmissions per traffic type, the number of packet losses, the network throughput, the number of collisions and the maximum length of consecutive collisions (collision chain). Notice that when the RTS/CTS handshaking is disabled, the number of collisions refer to the collisions suffered by the data and ACK packets. Table 6 shows the standard deviations and confidence intervals for the main metrics shown in Table 5. From the values of this second table we can observe that the values obtained are a good estimation of the protocol’s behavior.

Table 4 Evaluation scenarios for Case Study I

As seen from Table 5, scenarios 1–5, the number of packets successfully transmitted is substantially greater than in scenarios 6–10. We remind the reader that the packet length in the first five scenarios is set to 100 bytes, while in scenarios 6–10 it is set to 1500 bytes. From the results, it is clear that the use of short packets should be preferred in the absence of the RTS/CTS mechanism. Regarding the performance of scenarios 2–5, we notice that the highest priority traffic, i.e., VO, reports the worst results in terms of packets successfully transmitted. The highest throughput is reported for the BE traffic (scenario 2). These results can be explained by the fact that as the priority decreases, a longer Backoff period allows for the competing nodes to successfully solve the channel access conflict. As can be observed, the number of collisions reported for VO traffic is significantly higher than for the BK and BE services. However, it should be noted that the number of successfully transmitted packets of BK traffic is lower than the one reported for the BE traffic (scenarios 2 and 3). The number of lost packets and collisions for these two scenarios are very similar. These results clearly show that the highest priority services, i.e., VO and VI, are unable to solve channel access conflicts when the distance prevents them from sensing the ongoing transmission.

Scenario 1 explores the case when a station of the lowest priority, BK, competes against a VO node. As can be seen, under saturation conditions, the number of successfully delivered BK packets represent less than 1% of the total. This result clearly shows that the high-priority traffic is able to take full advantage of its privilege position. The low priority traffic is heavily penalized in the presence of hidden high-priority nodes.

Table 5 Performance results—Case Study I without RTS/CTS

Table 6 Standard deviations and confidence intervals—Case Study I without RTS/CTS

Table 7 Performance results—Case Study I with RTS/CTS

Table 8 Standard deviations and confidence intervals—Case Study I with RTS/CTS

Table 9 Evaluation scenarios for Case Study II

When long packet sizes are used (Scenarios 6–10), the performance of the IEEE 802.11e standard is heavily penalized. Under these scenarios, the highest priority services are unable to solve channel access conflicts, since the packet transmission time is longer than the Backoff mechanism. As depicted in Fig. 13, when the stations are unable to detect the activity of each other, they transmit their data frames as soon as their corresponding Backoff periods expire. Then they wait for the corresponding ACK frames. As soon as the ACK timeout expires, they attempt to transmit once again their frames following a second Backoff period. However, depending on the timing relation between the data frame transmission time and the Backoff time, their frames may once again collide. This process may repeat up to the number of attempts defined by the standard for each traffic class, see Table 1. As seen from the results of scenarios 9 and 10, the VO and VI services will be severely affected by the presence of hidden nodes when the use of long frames is preferred. For these two services, all the collisions involve data frames. In the case of the lowest priorities, which make use of a longer Backoff period, collisions may also involve ACK packets. From the above results, it is clear that the use of shorter packets provide much better results. This is simply explained by the fact that when a station is unable to detect the activity of the others, the length of the collision period is equal to the packet transmission time, and thus a longer packet results in a longer collision period. The number of consecutive collisions reported confirms that the ratio between the packet transmission time and the length of the Backoff period plays a major role on solving channel access conflicts. In the case of scenarios 9 and 10, the VI and VO traffic are unable to transmit a single packet, the length of the collision chain is equal to the number of collisions involving data packets. The best results are obtained for short packets and a longer Backoff period (see Table 5). Therefore, the use of RTS/CTS control frames should help to reduce the time to solve conflicts.

Fig. 13

Timing diagram of two VO sources operating under hidden-node conditions

Table 7 shows the results for the previous scenarios when the RTS/CTS handshake mechanism is implemented. Table 8 shows the corresponding standard deviations and confidence intervals. Similarly to scenarios 2–5, in scenarios 12–15, the lowest number of transmitted packets is reported for the VO traffic. The best results for a single priority scenario are reported for the BE traffic. A slight decrease in this metric is reported for the BK traffic, confirming that the length of the Backoff period results in a slight bandwidth waste, i.e., idle slots. In scenario 11, BK traffic is again heavily penalized by the presence of the VO node. Although the number of transmitted packets is lower when using long packets (scenarios 16–20) rather than when setting a shorter length, the throughput in bits per second is considerable higher. Take for instance scenarios 15 and 20. In scenario 15, 2414 packets of 100 bytes are transmitted, resulting in a throughput of 125.73 Kbps. By contrast, the throughput for scenario 20, where 1500 bytes packets are used, is 898.44 Kbps. Therefore, the use of RTS/CTS proves being more effective when reserving the channel to transmit long packets. This is an important issue to be considered when setting the network parameters. However, it should be noted that some services, such as VO traffic, impose heavy constraints in terms of the packet length to be used.

5.2 Case study II: non-saturated traffic conditions

The main goal of this case study is to explore the shortcomings of the priority mechanism defined by the IEEE 802.11e standard in conditions of intermittent traffic in the presence of hidden nodes. Since we are particularly interested on evaluating the priority setting defined by the standard, we consider a system consisting of one AP, one BK station and one VO station. The network load is varied from 400 to 800 Kbps, representing moderate network load conditions. Recall that the nominal network data rate is 2 Mbps. The network load has been set through the average packet inter-arrival time of each station using an exponential distribution. The scenarios considered for this case study are shown in Table 9, once again classified depending on the use of RTS/CTS. We consider again two packet lengths and the five aforementioned network load conditions. Notice that the [I] label next to the number of stations indicates the delivery of intermittent traffic (Tables 10, 11).

Table 10 Performance results—Case Study II without RTS/CTS

Table 11 Standard deviations and confidence intervals—Case Study II without RTS/CTS

Tables 10 and 12 show the results for this case study when disabling/enabling the RTS/CTS mechanism, respectively. In addition, Tables 11 and 13 contain the corresponding standard deviations and confidence intervals for the main metrics. In the absence of RTS/CTS, Table 10 depicts that the priority mechanism can provide a better service for the VO traffic when a short packet is preferred (scenarios 21–25). In all of these scenarios, except for scenario 21, the number of transmitted VO packets is higher than the number of transmitted BK packets. Notice that in the case of scenario 21, the use of a shorter Backoff period plays against the VO traffic. This is due, as explained in the analysis of the first case study, to the ratio between the packet transmission time and the length of the Backoff period.

When a long packet is used (scenarios 26–29 in Table 10), the number of transmitted VO packets is significantly lower than the number of BK packets. Once again, this is mainly due to the lower number of transmission attempts before dropping a VO packet. The results in Table 12 prove the effectiveness of the RTS/CTS mechanism when short packets are used. As seen from the outcomes from scenarios 32–35, the number of VO packets is substantially higher than the number of BK packets. The same trend can be observed in scenario 31 with respect to scenario 21. Scenarios 36–40 demonstrate how the use of a long packet for the voice service should be avoided. As can be observed, the number of VO packets being served is higher than that for the scenarios 26–30 when RTS/CTS is not enabled. However, the number of VO packets transmitted is still lower than the number of BK packets. In other words, the priority mechanisms are not able to provide a better service to the high priority traffic, i.e., the VO packets.

Table 12 Performance results—Case Study II with RTS/CTS

Table 13 Standard deviations and confidence intervals—Case Study II with RTS/CTS

Figure 14 shows the transmission times for BK and VO services for all the scenarios considered in Case Study II. As seen in Fig. 14a, c, the use of RTS/CTS reports a longer transmission time for the BK traffic, while the transmission time of the VO traffic remains unchanged. A higher delay is observed for BK packets when RTS/CTS is enabled, due to the greater number of transmitted BK packets in this case. However, this extra delay should not have an impact on the QoS provided to the BK traffic, because the BK traffic is delay tolerant. Figure 14b, d shows the transmission times when a longer packet length is used. In this case, the use of RTS/CTS produces shorter packet transmission times for the BK traffic. Despite this improvement, the use of long VO packets should be avoided.

Fig. 14

Transmission time in Case Study II for different packet sizes and traffic types

5.3 Case study III: multimedia scenario

Table 14 Evaluation scenarios for Case Study III

This case study first presents a network setup consisting of one BK and several VO stations. The VO sources will then be replaced by BE nodes to analyze how in some specific cases we can profit from low traffic priorities to address some shortcomings of the IEEE 802.11 control mechanisms. Table 14 shows the scenarios considered, where in this case the RTS/CTS exchange is always enabled and stations only produce intermittent traffic. Scenarios 41–47 consist of one BK source and a varying number of VO sources. The BK node uses 500 bytes packets, while the VO packet length has been set to 50 bytes. This scenario then reflects a more realistic setup, where VO sources make use of short packets, while BK traffic is used for data traffic. The second part of the tables, i.e., scenarios 48–54, defines a setup consisting of one BK source and a varying number of BE nodes. Notice that BE nodes share the same system parameters than the VO sources in scenarios 41–47. This type of study has been explored in various network contexts with the aim of exploring the use of other network services, e.g., BE, to carry VO traffic.

Table 15 Performance results—Case Study III with RTS/CTS

Table 16 Standard deviations and confidence intervals—Case Study III with RTS/CTS

Table 15 shows the outcomes of Case Study III, and the corresponding standard deviations and confidence intervals are shown in Table 16. From the results obtained for scenarios 41–47, it is clear that as the number of VO sources operating under hidden-node conditions increases, the performance of both traffic types, i.e., BK and VO, heavily degrades. We also notice that the service received by the VO traffic improves with respect to the one received by the BK traffic. However, the overall performance of the service is useless for the purpose of providing the required QoS guarantees. In scenarios 48–54, the performance offered by BE nodes is considerably higher than the one reported by the VO service in scenarios 41–47. From these results, taking into account that both traffic types, i.e., VO and BE, share the same traffic characteristics in terms of packet size and bitrate, we can conclude that relaxing the Backoff procedure of the VO under hidden-node conditions may prove beneficial. However, such approach proves useful only for a very limited number of nodes operating in the presence of hidden nodes.

Fig. 15

Transmission time in Case Study III for different packet sizes and traffic types

Figure 15 shows the transmission delay for the two scenarios. This metric is a key performance index for voice communications. As seen from the figure, the delay reported for BE is higher than the one reported for VO. Despite this increase, the delay experienced by BE traffic is within the QoS requirements of VO traffic. Therefore, further tuning of the Backoff period may be worth to explore in order to accommodate a larger number of VO sources.

Note: The CPN model and the results obtained for the scenarios considered can be found at the URL http://dx.doi.org/10.17632/d6csk9yvry.3.

6 Related work

Petri Nets have been shown to be very useful in modeling and evaluating communication protocols, and in particular the so-called High Level Petri Nets (HLPNs), which extend the basic model by using hierarchic constructions and data/time extensions, as is the case of CPNs. Thus, we can find many works that use different extensions of PNs to model communication protocols. In the area of wired protocols we can mention the work of Cambronero et. al. [34], in which CPNs and CPN Tools have also been used for the modeling of the 1-wire protocol, which is typically used to communicate a master device with some small inexpensive devices, such as digital thermometers and weather instruments, using low data rates and long ranges over a single shared bus.

With regard to wireless protocols, Hu et al. [35] have also developed a CPN model of the IEEE 802.11 DCF protocol. In particular, their work focuses on the modeling of the original DCF mechanism, including the use of the RTS/CTS exchange in order to address the hidden-node problem. That is to say, since their work does not cover the priority mechanisms introduced in the IEEE 802.11e amendment, the authors focus on evaluating the potential benefits of using RTS/CTS to tackle the hidden station problem. Similarly to our approach, they assume an error-less channel in which all losses are caused by channel access conflicts.

Hu and Jiao [36] present a CPN model of the IEEE 802.15.6 MAC protocol. Similarly to our approach, their aim is to show the benefits of using CPNs in the modeling of the various features of a given protocol. Their model is developed by using hierarchical and symmetrical modeling techniques. However, they leave the tuning and parameter adjustments of the protocol as issues to be considered in the future. That is to say, they do not look into the impact that the various parameters may have on the performance of the protocol under different scenarios.

Somappa and Simonsen [37] used a model-based development technique to generate the code of a medium access protocol derived from a CPN model. Their main goal was to show the benefits of deriving the actual code of an operational MAC protocol fully complying with the specifications and expected performance requirements.

Alves and Margy [38] have introduced a novel behavioral approach to the beacon-enabled IEEE 802.15.4 standard using CPNs. Similarly to our work, they test different values of the system parameters of the beacon-enabled MAC protocol of the 802.15.4 standard. They provide numerical results and a comparative analysis with results obtained from an experimental setup.

There are also many works using other extensions of Petri nets. For instance, Perez et al. [26] use the Mobius tool, which is based on Stochastic Petri Nets (SPNs). SPNs extend the basic model by considering that transitions fire after a probabilistic delay determined by a random variable (usually a negative exponential). They focus on the tuning of the EDCA parameters. However, they do not take into account the use of the RTS/CTS mechanism as a major parameter having a big impact on the performance of IEEE 802.11, when facing hidden-node issues and high population (node) densities.

Heindl and German [39] have also used SPNs for the evaluation of the IEEE 802.11 protocol. They propose a detailed model and two compact models of this protocol to analyze the distributed coordination function, which is the fundamental contention-based access mechanism. These models are used to investigate different physical layer options and the influence of several system parameters. These same authors extended this work in [40], where they claim that although most of the performance studies based on SPNs must adopt simplified assumptions (usually not proven to be accurate enough) because of both the expressive and simulating limitations associated to this formalism, they have developed an SPN that captures the main relevant aspects of the system to be modeled. In addition, they use simulation techniques to show a quantification of the influence of features such as Backoff time, Extended Interframe Spaces and Timing synchronization function. Even more, they claim to have identified the conditions under which simplifying parts of the model can be done with the aim of generating a model compact enough to be properly simulated and analyzed. This model, therefore, has the intrinsic limitations derived from the SPN model. In contrast, we propose a richer, flexible and scalable parameterized model based on CPNs, in which the RTS/CTS handshake mechanism can be enabled or disabled, and which also includes four types of prioritized traffic.

Moraes et al. [41] have also proposed a SPN model for the simulation and analysis of the IEEE 802.11e EDCA communication protocol, with the goal to analyze the behavior of the EDCA function associated to Quality of Service (QoS) stations. Specifically, they use Stochastic Activity Networks (SANs) to produce a compact and efficient model, which is then analyzed using the Möbius tool. The model presented in [41], therefore, lacks of some features that we have included in our CPN model, such as four types of prioritized stations, configurable use of RTS/CTS and scalability.

El Masri et al. [24] proposed a pattern-based Markov chain model of the IEEE 802.11e EDCA communication protocol with four types of traffic and including the virtual collision phenomenon. The model is divided into three basic patterns (similar to our CPN pages), and they define a separate Markov chain for each basic pattern and the global model which connects all of them. Performance analysis is then made using the Markov chain at the steady state, thus producing a set of formulas with the performance indicators, such as throughput, probability to access the medium and probability of medium being busy. It is therefore a rigid model, in which the transition probabilities must be set up to analyze the system behavior.

Zairi et al. [42] used HLPNs for formal modeling and analysis of Wireless Sensor Networks (WSN). Specifically, they proposed a model which represents the behavior of each WSN node. The modeled behaviors include the application, the protocols, an abstraction of the hardware energy consumption model and the environment, as viewed by the nodes. The authors claim that the proposed model is symmetrical since the considered WSNs are homogeneous, where all the nodes follow the same behavior. According to the authors, the main advantage of the model is that it is symmetrical and has a modular structure, so they consider that combining modular verification and symbolic reachability graphs will reduce the problem of the state space explosion and reduce the effort required to check properties. In a following paper [43], they completed the model by focusing on energy aspects. Then, they focused on the radio interface, which is controlled by the MAC component, since they consider it consumes the most energy. Then, the proposed model is used to evaluate the lifetime of the network and to estimate energy consumption.

Mokdad et al. [44] have assessed the performance of a multiple-priority (QoS) MAC protocol using two performance evaluation tools, namely Stochastic Automata Networks (SANs) and CPNs. They justify the use of CPNs for evaluating the transmission process. According to the authors, SANs are not designed to assess the performance of the transmission process when considering certain relevant system parameters. In the second part of the study, they show the benefits of using CPNs to model and simulate different scenarios. They obtained numerical results for two scenarios, allowing the modeling and evaluation of the priority mechanisms of the MAC protocol under study.

7 Conclusions

In this paper we have developed a CPN model for evaluating the performance and, more importantly, the effectiveness of the IEEE 802.11e priority mechanism. We have numerically evaluated the performance under various system operating conditions. We have identified some shortcomings of the protocol mechanisms defined by the IEEE 802.11e amendment. Regarding the priority mechanism, we have found out that the proposed parameter setting has serious limitations when operating in the presence of hidden nodes. Our study is particularly relevant in the context of wireless networks based on the IEEE 802.11 standard. Following current trends in the deployment of wireless networks in rural areas, we have considered long-range wireless network scenarios.

One of the main benefits of the model presented is its flexibility. By just changing the configuration parameters, we can analyze a great variety of scenarios that jointly consider several aspects of an IEEE 802.11 network. In addition, as the CPN model is divided into separate pages, it could be easily modified in order to consider possible variations of the protocol or incorporate the new amendments that are introduced in the new versions of the standard. Thus, as future work we intend to further explore the performance and effectiveness of other mechanisms on the IEEE 802.11 standard, and in particular on the IEEE 802.11e amendment and the newest IEEE 802.11ax standard. The study of the latter is of particular interest since it extends the use of collision avoidance mechanisms, namely, carrier sensing threshold. Our future plans will focus on exploring the performance of a protocol architecture integrating both mechanisms, i.e., a dynamic RTS/CTS mechanism and the carrier sensing threshold. The selective use of RTS/CTS may be performed on the basis of network operating conditions: number of active stations and priorities, overall network load, variable number of hidden stations and the carrier sensing area. Regarding the changes required in order to consider a dynamic RTS/CTS mechanism and overall network load, these do not require significant modifications in the CPN model. These changes mainly affect the guards in the transitions Start_Send, RTS_IMM and modify the functions gen_new_time and tsend, which produce new packets and set the transmission times, respectively. The same scenarios that have been considered in this paper could then be used in order to analyze the impact of these changes. However, introducing the effect of a variable number of hidden stations and the carrier sensing area will require further changes in the CPN model to capture the required information. Thus, the scenarios here considered should be extended with the appropriate configuration information in order to establish the stations that are visible from each station and the carrier sensing area.

Appendices

Appendix A

Listing 5 contains the main function declarations used in the CPN model.

Table 17 Test cases used for the model validation (part I)

Appendix B

Tables 17, 18, 19, 20 and 21 contain the scenarios and the expected output for them that have been identified for the model validation. These scenarios allow us to check the test cases presented in Table 3. For these proofs, we remove the initial marking M_MSG(nt) from place Last_Arrival_Time. In addition, unless we say otherwise, we assume that the tokens on the place Control_Time_CTS have a timestamp smaller than or equal to the current time of simulation (Time). All other places keep their initial markings, unless we say otherwise in the scenarios. In some cases, some places and transitions have been included in the tests to enforce the marking scenarios at specific times, in order to have the configuration required for the test case in an easy way.

Table 18 Test cases used for the model validation (part II)

Table 19 Test cases used for the model validation (part III)

Table 20 Test cases used for the model validation (part IV)

Table 21 Test cases used for the model validation (part V)