IEEE 802.11 Transmit Opportunity¶
Transmit opportunity (TXOP) is a MAC feature in 802.11. TXOP increases throughput for high priority data by providing contention-free channel access for a period of time. This showcase demonstrates frame exchanges during a TXOP.
TXOP is available in QoS mode as part of EDCA (Enhanced Distributed Channel Access), and it is a limited time period of contention-free channel access available to the channel-owning station. During such a period the station can send multiple frames that belong to a particular access category.
The benefit of TXOP is that it increases throughput and reduces delay of QoS data frames via eliminating contention periods between transmissions. TXOP can be used in combination with aggregation and block acknowledgement to further increase throughput.
More precisely, access categories have different channel access parameters, such as AIFS (Arbitration Interframe Spacing), duration, contention window size, and TXOP limit. In the default EDCA OFDM parameter set in the 802.11 standard, these values are set so that higher priority packets are favored (the MAC waits less before sending them, the contention window is smaller, and they can be sent in a TXOP). The default parameter set specifies a TXOP limit of approximately 3 ms for the video category, and 1.5 ms for the voice category. The background and best effort categories have a TXOP limit of 0, that is, they do not use TXOP (they can send only one MSDU before having to contend for channel access again).
A station can send frames to multiple recipients during a TXOP. In addition to QoS data frames, other frames can be exchanged in the course of the TXOP, such as ACK and BlockAckReq/BlockAck frames, and other control and management frames.
TXOP in INET¶
In INET, the TXOP is enabled automatically when the station is in QoS mode, i.e.
uses HCF (
qosStation = true in the MAC). The TXOP limit for an access
category can be set by the
txopLimit parameter in the TxopProcedure
module of that access category. The module is located at
in the module hierarchy; there are four
edcaf (EDCA Function) modules for the
four access categories:
The default value for the
txopLimit parameter is
-1 for all ACs,
meaning the 802.11 standard default values are used:
Our goal is to demonstrate complex frame exchange sequences during the TXOP, such as the transmission of QoS data frames, aggregate frames, RTS and CTS frames, acks, and block acks.
In the example simulation, one host is configured to send video priority UDP packets to the other. The host sends 1200B, 3400B and 3500B packets. The RTS, aggregation and block ack thresholds are configured appropriately so that we get the following frame exchanges for demonstration:
The 1200B packets are block acked
Two of the 1200B packets can be aggregated; the aggregate frames are block acked
The 3500B packets are sent after an RTS/CTS exchange, the 3400B ones are not, both are normal acked
Thus, the list of all alternative frame sequences that can repeat during the TXOP is the following:
(1200B + 1200B) aggregated
3400B + ACK
RTS + CTS + 3500B + ACK
BlockAckReq + BlockAck
ADDBA Request + ACK
ADDBA Response + ACK
In INET, frame exchange sequences are described by frame sequence (
These classes describe the order of frames allowed in a frame exchange.
For example, frame combinations possible in a TXOP are described by the
TxOpFs class. Other classes include
The simulation uses the following network:
The simulation is defined in the
General configuration in
There are two UDP applications in
host1, sending small (1200B) and large
(randomly 3400B or 3500B) packets to
*.host1.numApps = 2 *.host1.app[*].typename = "UdpBasicApp" *.host1.app[*].destAddresses = "host2" *.host1.app.destPort = 1000 *.host1.app.messageLength = 1200B *.host1.app.sendInterval = 0.12ms *.host1.app.startTime = exponential(0.1ms) *.host1.app.packetName = "small" *.host1.app.destPort = 2000 *.host1.app.messageLength = intuniform(0,1) == 1 ? 3500B : 3400B *.host1.app.sendInterval = 0.2ms *.host1.app.startTime = exponential(0.1ms) *.host1.app.packetName = "large" *.host2.numApps = 2 *.host2.app[*].typename = "UdpSink" *.host2.app.localPort = 1000 *.host2.app.localPort = 2000
QoS is enabled in both hosts, and a classifier is included. The port numbers in the classifier are configured to put all UDP packets in the voice access category:
*.host*.wlan[*].mac.qosStation = true *.host*.wlan[*].classifier.typename = "QosClassifier" *.host*.wlan[*].classifier.udpPortUpMap = "1000 VO 2000 VO"
IP and 802.11 fragmentation is turned off:
*.host1.wlan[*].mac.mtu = 15000B *.host1.wlan[*].mac.hcf.originatorMacDataService.fragmentationPolicy.fragmentationThreshold = 15000B
Block acks are enabled:
*.host*.wlan[*].mac.hcf.isBlockAckSupported = true
The aggregation, RTS, and block ack thresholds are also set appropriately to produce the desired frame sequences:
**.hcf.originatorMacDataService.msduAggregationPolicy.maxAMsduSize = 3000 **.hcf.rtsPolicy.rtsThreshold = 3475B **.hcf.originatorAckPolicy.maxBlockAckPolicyFrameLength = 3400B
The following image shows frame exchanges during a TXOP, displayed on a linear-scale sequence chart:
The gap between the frames is a SIFS; the TXOP frame exchange is preceded and followed by a much longer contention period. This frame exchange sequence was recorded with 24 Mbps PHY rate. When using higher rates, more frames could fit in a TXOP, as the TXOP duration is independent of the PHY rate.
This frame sequence is just an example. Various combinations of frames can be sent during a TXOP. Observe the simulation for other combinations.
The TXOP in the image is about 1.8 ms, which is longer than the 1.5 ms TXOP limit. This is due to a limitation in INET’s implementation: it is not checked whether the last frame fits in the TXOP limit, only that its transmission can be started within the limit.