Printer FriendlyEmail Article Link

Spirent TestCenter: Wifi: Stations floods the Tx with RTS during the prior client's RTS duration period.

Symptoms

On a normal WiFi environment the stations perform collision avoidance by setting it NAV (Network allocation Vector) when it hears another station transmitting. Request to Send/Clear to send is a mechanism that performs a NAV distribution and helps prevent a collision from occurring, this NAV distribution reserves the medium prior to the transmission of the data frame.
 
That being said it looks like every time a station sends an RTS, all other stations (including other Spirent Test Center stations) should be just waiting the NAV time, and should not transmit anything, so this is what we think it should happen (being c1= client 1 , and cn = client “N”):
  
 
C1 RTS --> 
           ----------+
           sifs      |
   <-- cts           |
sifs                 +---- NAV RTS (rts duration) - all other stations should set their NAV and wait for the duration      
   DATA -->          |
           sifs      |
   <-- ack           |
           ----------+
difs
 
 
C2 RTS --> 
           ----------+
           sifs      |
   <-- cts           |
sifs                 +---- NAV RTS
   DATA -->          |
           sifs      |
   <-- ack           |
           ----------+
difs
 
 
…
difs
 
 
CN RTS --> 
           ----------+
           sifs      |
   <-- cts           |
sifs                 +---- NAV RTS
   DATA -->          |
           sifs      |
   <-- ack           |
           ----------+
difs
 
 

However, capturing on STC side, you could see large recurring bursts of RTS frames from all of the virtual clients, frame 588 is an example of the lead RTS in the burst. The issue here is that this could lead us to think that our virtual clients do not set their NAV based upon the duration field of Frame 588.  
 

You can find attached customer's capture that shows this RTS flood we are explaining here
 
Environment
 
  • Wifi
  • RTS
  • CTS
  • NAV 
  • Network Allocation Vector
Explanation/Resolution

Spirent TestCenter WiFi does not work in the exact same fashion we explained before with RTS/CTS, while a single radio used for multiple client emulation, the transmission is going always sequentially for transmission, no really RF contention happening here as at a  time only one client is transmitting.

By design the single radio port will not transmit more than one frame at a time thus eliminating collisions and contention, and STC client(s) will not transmit when a CTS is detected and during the subsequent received packets.

So, in summary we can conclude:
  1. The single STC port does not conflict with any of its emulated clients.  Only one client is Tx'ing at any given time.
  2. Unless the destination is ready to Tx a CTS there is no contention on the channel.
  3. There has been example(s) with a commercial AP will flood the channel with RTS packets.

Our dev team have recreated the behavior you are seeing with only 1 station, and from the capture (snapshot below), the client retransmits RTS (packets 6160 through 6165) for next data when CTS has not arrived (It’s until packet 6166 when CTS arrives)
 
From IEEE80211 spec other stations update NAV once received RTS/CTS and defer their access of medium. However, for the station which doesn’t receive CTS after SIFS it still can send another RTS for next data transmission. In this case, the client that transmitted RTS is waiting for a CTS coming back from AP, and if it does not see a CTS coming back, then it will be timed out for the next window for transmission.  Then it will be moving on to the next client for the same RTS transmission until the AP sends back a CTS then the data transmission will happen.
 
From the initial capture we got that is showing the "RTS flood" (attached = 100UL_sniff.pcap) here is the section of the capture that shows once the AP sends a CTS back, one of the clients with MAC xx:xx:xx:20:00:21 started to transmit data. After it completes the transmission within the window, it gets back to the cycle of sending out RTS again, until another CTS comes from the AP. This time is for another client with MAC: MAC xx:xx:xx:20:00:224 for transmission:
 

 
 
 
enlightenedBased on that, it looks like there is no violation with standard with RTS/CTS/SIFi/NAV mechanism.


However, the STC captures (regular & sniffer) timestamp precision are suspect leading to positive, and negative, analysis, because as per some discussions with a customer on this topic, SIFS is 16uS and the timing on a proper RTS/CTS exchange is supposed to be:  RTS->SIFS->CTS. But our captures with a single client looks like could be violating the spec because the interval between packet 6162 and 6163 is only 2uS, using the same capture as above when the has been recreated with 1 single station:
 
  • So, that capture led us to stop and investigate further whether if STC is actually violating the RTS duration period or not.
  • The findings on STC capture are as follows:
  • The timestamp from the STC is not representative of the timestamp from the packet over-the-air (OTA).  This is by design due to a limitation that the timestamp is not available with the packet as the STC saves it for subsequent "View".
  • The process for STC packet capture is:
  1. As the packet is received in the STC FPGA it is stored in a memory file if Capture is enabled.
  2. When a user presses stop, and views capture the stored capture records are displayed in Wireshark format.
  3. Because the timestamp as was not available during capture store a new one is created using the STC OS(es) timer tick.  This will generate a very small timestamp increment between each capture record.
  • Because of this small timestamp increment, it is understandable why you could think STC was violating the RTS duration period. 
 
  • The following tests were run to determine if there was a problem(s):
 
  1. Run customers initial configuration to investigate if the duration period is violated between the burst of STC emulated client's RTS.
 
  • Because the STC capture timestamp could not be used in this test case we used an external (non-STC) Wireshark capture OTA.
  • In two views we noted the duration period was not being violated.
    • When an RTS received a CTS, we noted the STC was not interfering or violating the duration period:
 
  • When an RTS immediately following an RTS, we noted the subsequent RTS was transmitted with varying degrees of time.  In this example packet 19366 request a duration of 216 microseconds.  Packet 19371 is the next RTS from the STC and it is 325 microseconds plus the packet time for number 19367 - 19370.  This is a more accurate presentation than the STC capture timestamp.

 
  1. Run a configuration will two individual ports transmit on the same channel.  This is meant to see if the STC honors the duration period across WLAN ports.  From the STC capture, we observed RTS being honored OTA from each individual port.  Client from port 3 is 01:10:94:00:00:02 and the client from port 4 is 01:10:94:00:00:03. 

 
Root Cause
 
  • As per explanation above we concluded the STC does not violate the RTS duration period.
Attachments
Attachment

Product : WiFi,Spirent TestCenter,WiFi