• State
  • Locked Locked
  • Replies 7 replies
  • Subscribers 40 subscribers
  • Views 470 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

WL6/1273 with WM6.5, Station never completes BlockAck-session-establishment as "Initiator"

ohad shatil
Prodigy 80 points

Hi,  

I test 11n Block Ack (BA) feature with WL6/1273 in a product that is WM6.5.   I configure all respective parameters of [ "BaPolicyTid_x" ,  "HT_BA_POLICY_X"]   to make the Station as an "BA initiator& receiver" (value of 3).

What I see in wireless-trace is the following:  As the Station connects to the AP, it sends a proper Action-frame with BA-initiation to the AP.  When the AP replies with Action-frame of "BA success", the Station never hears it (TI FW does not Ack several retries of the AP).  Then as AP times out on that Action-frame reply attempts, it then itself initiates a BA session towards the Station (i.e. other direction) and then TI FW does hear it correctly, being the "receiver" of the BA session.  Then the session is established ok.

As I saw that issue, I also tested with changing the dot11PowerMode to 1 (CAM), but still the TI-FW does not "hear" the AP's reply to Station's initiation.

So, conclusion is so far I can not make the Station be a successful "BA Initiator"

Is this a know issue ?  is the "hearing" problem due to FW being on a different channel at that time?  I imagine the FW "must" return to the Serving frequency at the time it should expect the reply (much like it would do when serving actual data ?)

What other configurations shall I try out?

let me know if you want to get a wireless-trace of these experiments.

 

Thanks,

Ohad.

Motorola Solutions

  • 0
    TI__Genius 9240 points

    Hi Ohad,

    I have forward that question, you will get answer in the forum shortly.

    Thanks,

    Eyal

  • 0 in reply to Eyal a
    Prodigy 80 points

    Any update on that?

  • 0 in reply to ohad shatil
    TI__Genius 9240 points

    Hi Ohad,

    I am sorry, however i will not be able to support WM6.5. Related issues, since we don’t have platform that run on WM6.5, and we do have platform on Linux, therefore i cannot reproduce nor support such questions.

    Sorry for that,

    Eyal

     

  • 0 in reply to Eyal a
    Prodigy 80 points

    Hi Eyal,

    This issue does not seem to me to be Platform / OS dependent.  It looks like totally on-chip SW (FW) behavior that yields that.  That is, the Driver appropriately sends an Action frame to initiate BlockAck session, but then the FW does not even 802.11-Ack the Action frame response from the AP.  i.e. looks like FW is either asleep or went to auto-scan other channels.   I can send you air traces if you want to see that.  Then, when AP "understands" that there was a failure, it "initiates" the session (as "initiator") and then the FW does hear it and the Driver can get in sync in response to it.  All in all, the TI stack can never act as BlockAck-session "initiator", just as a "receiver".

    Can you try this out with whichever platform / reference-design you have ?  I can send you air traces if you want to see what is expected by 11n standard.

    If you are successful in being BlockAck "initiator", can you please email me a Log showing that, with details of which Platform and FW version it is ?   could be that there's some fix or configuration that I do not have.

    Thanks a lot,

    Ohad Shatil

    ohad.shatil@motorolasolutions.com

  • 0 in reply to ohad shatil
    TI__Expert 6985 points

    Hi Ohad,

    If you are able to provide a sniffer trace, that would be helpful, although I understand the scenario you are describing.

    Do you see this will all APs, or only a select few?

    Thanks, Bill

  • 0 in reply to William List
    TI__Expert 6985 points

    Hi Ohad,

    In the INI, please try setting the following parameter:

    BaInactivityTimeoutTid_0 = 0

    This may solve the issue you are facing. Let me know.

    Bill

  • 0 in reply to William List
    Prodigy 80 points

    6746.default.zipHi Bill,

    thank you for the advice.  I have tried it and it did not help.  

    I attach here two pcap files (one as with default INI of MCP2.5.1, and one with your suggested change).

    (I am trying to attach, let me know if you get them thru the posting, otherwise please provide email so I can email them to you ....).

     

    note the pcaps are captured in lab conditions without interferrers.  pcaps are raw, not filters applied.

    please observe the following (note that packet # taken from the "default" capture, the other one shows same issue in different packet # ..):

    packet# 101, MCP2.5.1 device get assoc-rsp from AP.  end of association exchange  (connection is open, no security).

    packet# 106, device sends Action -> BA Request

    packet # 108, AP sends Action -> BA Response.6675.BaInactivityTimeoutTid_0_zero.zip

    packets 109, 110, 111, AP re-sends the Action frame (retries) as device did not 802.11-Acknowledge, and never does.

    AP times out on the BA-Response eventually.

    AP then has its own timeout for entire BA Session, so INITIATE a BA-Request of its own, packet# 114

    Then device 802.11-Acks it (p# 115), and sends BA-Response (p# 116).   Then all is well afterwards.

     

    Thanks,

    Ohad.