locked
sdr_phy_ack_cache.c -- Design Advice? RRS feed

  • Question

  • Hello again;

     

    I'm hoping someone can point me in the right direction with regards to my implementation of the SORA ACK CACHE.

     

    As suggested previously, my implementation has been expanded so that the ACK cache described in the basic 802.11b (note: we are not using the 802.11a SDK yet) can utilize other kinds of packets (namely RTS/CTS).


    We've since then expanded on this in order to have it more applicable to our university's goals with respect to the SORA project. As such, our RTS/CTS design has changed drastically, and so has the number of FRAME_CTRL packets we need to use.

    Our design is fortunate enough to be able to reuse RTS/ACK packets when working with a simple two-peer setup, but our CTS packets are EXTREMELY dynamic, having at least two fields that can change at any given moment. This means that we fill up all the space allotted in the cache very quickly.

    Do you have any tips on how to "reset" the cache so we can either a) remove old, outdated CTS packets that we (probably) won't be using again, or b) completely restart the cache?

    I've tried calling the following code when I want to reset the cache, but it often results in a blue screen:

     

    		/////////////////////////////////////////RESET CACHE////////////////////////////////////////////////////
    		SdrPhyCleanupAckCache(&pAdapter->Phy.AckCacheMgr); //Wipe cache
      //FAILED_BREAK(hRes);
    		
    		//Refresh Cache
    		hRes = SdrPhyInitAckCache(							//Restart cache
         &pAdapter->Phy.AckCacheMgr, 
         ((PMP_ADAPTER)(&pAdapter->SdrContext.Nic))->Fdo, // System-dependant IoWorkItem
         &pAdapter->Phy,
         RadioInPHY(&pAdapter->Phy, RADIO_SEND), 
         MAX_PHY_ACK_SIZE, 
         MAX_PHY_ACK_NUM);
      //FAILED_BREAK(hRes);
    

     

    Similarly, sometimes our CTS code comes up with weird anomalies -- I'm wondering if anyone has a deeper explanation for these. For example:
    Our two additional fields beyond the scope of IEEE's definition of a 802.11 CTS packet are:

    "ChannelNumber" (the CTS packet from a destination tells the source what channel to hop to next)

    "SNR" (the CTS packet from a destination tells the source what the SNR was at the time of the RTS reception) //this can be expanded in the future to have a more hollistic use of SNR and more accurate with regards to how it's used; seeing as the SNR coming from a CTS is technically outdated the instant it's received...

     

    Our ChannelNumber field can be any number between 0 and 11, but our SNR is completely arbitrary. That said, our CTS design (again, heavily based off the ACK design supplied in the initial 802.11b release) reports on occasion that a CTS might "already exist in the cache" (hRes = E_PHY_FRAME_EXISTS), which is actually not true at all -- regardless of the fact that the SNR is often so arbitrary that no packet can be reused (again, why we have a need for a cache-reset function), sometimes no CTS with that channel number has been created yet, but the unit still thinks it has, and gives us that hResult.

     

    Any tips/pointers would be quite welcome!

     

    -Cory


    Wednesday, March 23, 2011 1:49 AM

All replies

  • Hi, Cory:

    If your cached packets are so dynamic, you 'd better take it as regular packet. Thanks.

    Regards

    Sen


    Sen Xiang (项森)
    Wednesday, March 23, 2011 5:40 AM
  • For cache reset, please call first SoraCleanPhyFrameCache, then init it again.


    Sen Xiang (项森)
    Wednesday, March 23, 2011 5:42 AM