Forum

Hi,

I am familiar with NAV distribution during normal data transfer, fragment burst, RTS/CTS etc. However I am confused when it comes to frame aggregation and TXOPs. 
Can anyone explain the values of Duration ID in the MPDUs of A-MPDU?Will the first MPDU contain the value for entire AMPDU or will it contain till the next MPDU or just SIFS+some amount of time?I was not able conclude any thing from looking at packet capture or from the 802.11 document. Need your expertise.
Also I have similar doubt in the TXOP. How the NAV gets distributed during txop.
The standard says that when multiple frames are sent during TXOP, we have to use protection. The RTS/CTS will reserve the time for TXOP. However I saw the next data frame's duration ID is very less (Its not CTS value - SIFS). So I am guessing CTS/RTS used here to protect from hidden node (just guessing).
I have so much of confusion when it comes to NAV distribution during TXOP and frame aggregation.
Tons of Thanks in advance.

Hi Sathwik,
                Bit of a late reply although not sure if you have had any luck on this. Happened to revisit the standard, after coming across your query and so am putting across my thoughts on this:
 To begin with & just for reference
|«------------------------ PPDU -------------------------»|
-----------------------------------------------------------------
|PLCP      |MPDU-1    | MPDU-2|....... | MPDU-n|
|Header    |                   |                |....... |                |
-----------------------------------------------------------------
&
                              |«---- MPDU ----»|
                              ------------------------
                              |MAC     | MSDU |
                              |Header |              |
                              ------------------------
∙ The PICS Proforma of the standard(2012) mentions this feature(Duration/ID rules for A-MPDU and TXOP) as Optional(B4.19/HTM8).
 That is to say that - as the implementation of this feature is not mandated towards PICS proforma, so the behavior that you observe in the specific DUT may not be wrt standard implementation unless it claims a "Yes" against this line item in its PICS statement.

∙ Now coming to what the standard has to say on this, I could find the following relevant pieces:
  * Sec. 8.2.4.2 - "The Duration/ID fields in the MAC headers of MPDUs in an A-MPDU all carry the same value."
This is followed by a foot note stating "...the reference point for the Duration/ID field is the end of the PPDU carrying the MPDU. Setting the Duration/ID field to the same value in the case of A-MPDU aggregation means that each MPDU consistently specifies the same NAV setting"
  * So from the above statement, the following can be said about Duration/ID for A-MPDU viz.,:
           Each MPDU in an A-MPDU should specify the Duration/ID of the entire duration as calculated for transmitting the complete PPDU(consisting of  'n' MPDUs)

     Hope this analogy helps you overcome the confusion to a greater extent. Any comments welcome.
P.S - I'm checking on the TxOP part of your query - shall try & revert soon.

The Pics Pro-Forma, which is really  a questionaire/check list for manufacturers, seems like it would be a fantastic way of comparing chipsets.   But you don't see these documents in public.  They don't appear to be available to radio manufacturers either, or if they are, they must be hidden from the public by NDA's.

I have compared the PICS against several chipsets and have often found supposedely required features missing.  I am of the opinion that it is an almost useless section in the standard.

The FCC, other regulatory bodies, and the Wi-Fi Alliance don't require this document.  So who bothers to fill them out if they're not required by anyone? 

A chipset has the features it has - period.  It seems like "marketing" has much more control over which chipset features are implemented than is controlled by  "engineering".

If anyone has actual experience to the contrary, I would love to hear about it.

Hi Howard,
                      Your point wrt the PICS Proforma is quite true and understandable. As a matter of fact, having been associated with the industry over the last 10 years, I can vouch for the points stated by you. In my reply above, my assumption was(& still continues to be) that the initiator of this thread(Sathwik) possibly has an engineering/R&D exposure.
   Nevertheless my point in referring to the PICS was with the intention of finding a reference from it(within the standard) for implementation of this feature. Yeah - you are correct in that no chipset maker would bother to provide a line by line comparison of features included or not supported via an official statement of the nature of PICS : More so when there's no specific motivation to do so.
  But as an internal practice within R&D/Engineering teams, for a feature to be implemented, a reference to the standard is mandatory practice. Consequently(and irrespective of presence or absence of PICS Statement), the end product would in all good faith, display(or be required to display) behavior in lines outlined by the standard. The necessity for this becomes more obvious if one takes into consideration factors like Interoperability in the field, absence of any publicly published features list most important being the proprietary ones, et al.

Thanks a lot guys for all the valuable information. :)

Ansuman,

I think you make a vailid point.

Having spent many years as a software engingeer, I found that one of the best ways to understand a piece of hardware, or software, was to read through all of the possible error messages that a piece of gear could issue - even when you didn't have any problems.

Although this is not exactly the same thing, it's similar.

I think I'll make a seperate document of the PICS Proforma for reference purposes.

Thanks Howard & Sathwick.
  Moving on to the TxOP part of your query/observation, I have attempted to explain the same below by juxtaposing the Standard vis-a-vis your observation.

* Graphical representation of what the Standard says on TxOP NAV Distribution:
   ______          _____           __________________        __________   
   |RTS     | SI    |CTS    | SI    |       DATA                       | RI   | Block-ACK | CF-End
 _|            | FS   |            | FS  |       (Frame Aggn)         | FS |                      |__
                |«-Nav1------------------------------------------------------------------------»|
                                       |«-Nav2--------------------------------------------------------»|   
                                                                                         |«-Nav3----------------»|
L-SIG1(RTS)    = Frame length @ RTS+CTS
L-SIG2(CTS)    = Frame length @ CTS+Block-ACK/CF-End
L-SIG3(Data)   = Frame Length @ PPDU+Block-ACK/CF-End

Nav1(RTS)    = Duration @ CTS till CF-End
Nav2(CTS)    = Duration @ Data(PPDU+Block-ACK) till CF-End
Nav3(Data)   =  Duration @ Block-ACK till CF-End

* Assumptions based on your observations:
    *  Network has a combination of both HT and non-HT(OFDM/ERP) PHYs
    *  Network is operating in Infrastructure Mode
    *  RTS/CTS is enabled in the AP
    *  The Data frame that you have referred to is the one(or any part of it assuming Frame-Aggregation is 'ON') depicted in my diagram above

* Notes:
       * L-SIG is part of the PLCP Header.
       * The 'Data Rate' & 'Frame Length'(aka L-SIG Durn) IEs in PLCP header length carry the info about PHY Rate(Clauses 16/17/18/19 as applicable) and Frame lengths as indicated above (Current frame+Following frame)
       * NAV aka MAC Duration is calculated as indicated above

 * Thus, if my assumption point#4 is correct, then the NAV/Duration ID of the Data Frame would be the time required to complete Block-ACK or CF-End(as indicated in my graphic above) and thus of a smaller value.
         Hope this analogy of the actual observation helps everyone out here. Any comments and or corrections welcome.

Ansuman,

Thats a great explanation. I did not get time to check the PICS Proforma. I ll get back to you once I go through it.

Sathwik,

Just remember that the PICS in the standard is an un-checked feature list.   You would need a copy from the radio manufacturer used in the device - if you really want to know what's available.

Having said that, using the PICS in the standard as a "possible" road map (treasure map ?), may allow you to find features that the device actually has, but that aren't advertized.
 
If you should ever find a source for completed PICS please share it.

PS:    I did make myself a copy of just the PICS Proforma from the standard.   It's seventy pages  long !

Howard,

I haven't received the PICS proforma. As you said its very hard to get it :(