inetmanet 802.11 RTS/CTS duration and TXOP

[Bjørnar Libæk]

The duration field in the RTS and CTS packet is used by the nodes to set the NAV, in order to not transmit in this time period. When using 802.11e, and a node wins a TXOP using RTS/CTS, the node is allowed to transmit multiple packets during the TXOP. In order to avoid that two-hop neighbors collide with these transmissions, is it not essential that the CTS contains the full duration of the entire TXOP period, not only the duration of the first frame exchange?

As far as I can see, this is not the case in the current implementation (Ieee80211NewMac.cc). Here, RTS duration field contains the transmission time of the first frame exchange only.

If understand correctly, the 802.11 standard [1] leaves this as an implementation choice. Section 7.2.1.1 of [1] describes the RTS frame format, and contains the following relevant text:

[ ]
For all RTS frames sent by STAs under EDCA, following a contention access of the channel,
the duration value is set in the following manner:
  - If the NAV protection is desired for only the first or sole frame in the TXOP, the duration value
    is set to the time, in microseconds, required to transmit the pending frame, plus one CTS frame,
    plus one ACK frame if required, plus three SIFS intervals.
  - Otherwise, the duration value is set to the remaining duration of the TXOP.
[/]

Is my understanding correct, that this is an implementation choice?
If yes, why is the first option used in inetmanet?

[1] IEEE 802.11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications. (2007 revision)

[Alfonso Ariza Quintana]

for simplicity, the possibility of to send multiples frames demands advanced queue management,
I must read this part of the standard but I suppose that can be related with the block ACK mechanism, with the actual frame interference model is not easy to implement the block ACK, is should be necessary to change the actual interference model.

---

Date: Wed, 18 Apr 2012 03:02:36 -0700
From: bli...@gmail.com
To: omn...@googlegroups.com
Subject: [Omnetpp-l] inetmanet 802.11 RTS/CTS duration and TXOP

--
Sent from the OMNeT++ mailing list. To configure your membership,
visit http://groups.google.com/group/omnetpp

[Bjørnar Libæk]

Alfonso,

I don't see why this is a matter of using block acks or not. If not using block acks, multiple MPDUs are transmitted within a TXOP, separated by individual ACKs. If using block acks, multiple MPDUs are transmitted back to back (separated by SIFS I guess) followed by a block ack. Either way, if the duration of field of the RTS, and consequently the CTS, only covers the first MPDU, the two-hop receivers are only instructed to hold back their transmissions in the first part of the TXOP, and may then collide after this.

Thus, I don't think implementation of block acks is motivated by this issue. That said, I also don't see why the interference model must be changed in order to implement block acks. Each frame in the sequence are transmitted and received separately, as normal MPDUs. The only difference is that the receiver MAC does not acknowledge each of these individual frames, but waits and sends a block ack at the end of the TXOP.

As I see it there are two possibilities. Either include the whole TXOP period in the RTS duration field, or update the two-hop neighbor's NAV when receiving each individual ACK during the TXOP. The latter requires changes to the FSM I guess, and I'm not sure if it is ok according to the standard.

[Bjørnar Libæk]

I forgot to mention that it is my understanding that current inetmanet implementation do already have support for multiple transmissions separated by SIFS within a TXOP. So the queue management issue is already handled.

kl. 12:23:24 UTC+2 onsdag 18. april 2012 skrev Alfonso Ariza Quintana følgende:

[Alfonso Ariza Quintana]

the block ACK needs that all the frames must be transmitted like a superframe, if you use the model of super frame the interference model tries all the super frame like a frame, but it's necessary to compute the error per every subframe, actually is not possible, the other mechanism, retain the channel it should be possible, it should be necessary check if the queues have more frames for the particular destination, but it possible to implement.

---

Date: Wed, 18 Apr 2012 04:23:29 -0700
From: bli...@gmail.com
To: omn...@googlegroups.com
Subject: Re: [Omnetpp-l] inetmanet 802.11 RTS/CTS duration and TXOP

Alfonso,

I don't see why this is a matter of using block acks or not. If not using block acks, multiple MPDUs are transmitted within a TXOP, separated by individual ACKs. If using block acks, multiple MPDUs are transmitted back to back (separated by SIFS I guess) followed by a block ack. Either way, if the duration of field of the RTS, and consequently the CTS, only covers the first MPDU, the two-hop receivers are only instructed to hold back their transmissions in the first part of the TXOP, and may then collide after this.

Thus, I don't think implementation of block acks is motivated by this issue. That said, I also don't see why the interference model must be changed in order to implement block acks. Each frame in the sequence are transmitted and received separately, as normal MPDUs. The only difference is that the receiver MAC does not acknowledge each of these individual frames, but waits and sends a block ack at the end of the TXOP.

As I see it there are two possibilities. Either include the whole TXOP period in the RTS duration field, or update the two-hop neighbor's NAV when receiving each individual ACK during the TXOP. The latter requires changes to the FSM I guess, and I'm not sure if it is ok according to the standard.

kl. 12:23:24 UTC+2 onsdag 18. april 2012 skrev Alfonso Ariza Quintana følgende:ld

[Bjørnar Libæk]

Ok, I'm not sure we are on the same page here:) I'm talking about EDCA TXOP (distributed/contention), not HCCF (centralized coordination). As I understand, there is no concept of superframes when using EDCA. When using EDCA TXOP, normal data frames are transmitted back to back. Refer to section 9.9.1.4 "Multiple frame transmission in an EDCA TXOP" in the standard [1]. According to section 9.10.1, Block ACKs can be used both in EDCA TXOP or in polled TXOPs (HCCF), and allowes the transmission of a "block of MPDUs". It states nothing about any superframe. Do you have a reference describing the superframe, or better, a  pointer to the specific section describing this in the 802.11 standard?

Regarding the duration field of the RTS, checking the queues as you suggest may be a bit "dangerous". As cited my first post in this thread, the duration should either cover the first data frame only, or the entire TXOP. The transmitting node may only have one queued packet to a destionation at the start of the TXOP, but may receive others during the transmission of the first. If chosing to let the duration only cover the first (and only one at the RTS transmission time), the node should really not be allowed to use the entire TXOP if more packets arrive during it. But this is just my intuition speaking.. It would be nice if anyone with good 802.11e knowledge could clarify this. I think it is important to understand what the standard specifies before doing any changes here. My limited insight into 802.11 is certainly not enough.

I did however test a very simple change, where the RTS duration is always set to cover the remainder of the TXOP. In the case I studied, I did see some improvement in the packet loss, but the the case was a very dense network with not many hidden nodes.

[Alfonso Ariza Quintana]

send multiples frames with the same RTS/CTS is relatively easy, I must read the standard and to see the timer, it's necessary to modify lightly the FSM and introduce a conditional jump but is relatively easy.

---

Date: Thu, 19 Apr 2012 00:51:13 -0700

[Bjørnar Libæk]

I'm not sure you need to change the FSM. I think it is enough to change the set the duration field correctly like this:

Ieee80211RTSFrame *Ieee80211egMac::buildRTSFrame(Ieee80211DataOrMgmtFrame *frameToSend)
{
    Ieee80211RTSFrame *frame = new Ieee80211RTSFrame("wlan-rts");
    frame->setTransmitterAddress(address);
    frame->setReceiverAddress(frameToSend->getReceiverAddress());
    bool useExtendedRTSDurationTXOP = true; //libak added.
    if(!useExtendedRTSDurationTXOP)
    {
        //libak: this is the original implementation. RTS duration only covers first frame exchange.
        frame->setDuration(3 * getSIFS() + computeFrameDuration(LENGTH_CTS, basicBitrate) +
                       computeFrameDuration(frameToSend) +
                       computeFrameDuration(LENGTH_ACK, basicBitrate));
    }
    else
    {
        //let the duration cover the whole TXOP period. Substract the length of the RTS and one SIFS.
        frame->setDuration(TXOP[currentAC] - computeFrameDuration(LENGTH_RTS, basicBitrate) -  getSIFS() );
        //TODO: possibly truncate duration if not having enough frame in queue to fill the TXOP. However, new
        //      frames may arrive during transmission of the ones present at this time, so may not be a good ide
    }
    return frame;
}

[Alfonso Ariza Quintana]

I must read the standard and study the behaviour,

---

Date: Fri, 20 Apr 2012 03:21:42 -0700