WARP Project Forums - Wireless Open-Access Research Platform

You are not logged in.

#1 2013-Nov-09 23:18:06

yeowl
Member
From: Cyberjaya
Registered: 2012-May-15
Posts: 44

Rate Control Mechanism in 802.11 Reference Design

Any rate control mechanism on MAC layer for the reference design for WARPv3?

Offline

 

#2 2013-Nov-10 10:21:39

chunter
Administrator
From: Mango Communications
Registered: 2006-Aug-24
Posts: 1212

Re: Rate Control Mechanism in 802.11 Reference Design

We haven't built any automatic rate control systems, but we have the hooks in place so users can add whatever scheme they want. The PHY itself supports transmitting and receiving at any of the 802.11g OFDM rates (6,9,12,18,24,36,48,54) Mbps.

At the highest level, any packet that gets dequeued from the transmit queue to be passed down to the DCF has a rate field that gets filled in. This occurs in the mpdu_transmit function. This function is what is responsible for sending a message to CPU_LOW to say that a new MPDU should be transmitted. Notice on Line 904 there is a call to wlan_mac_util_get_tx_rate. That function just returns whatever rate is present in the station_info struct associated with whatever device this packet is destined for. For an AP, there is a station_info struct for every associated station. For a STA, there is a single station_info struct for the AP that is associated to. So basically, one way to implement an rate control mechanism would be to change the tx_rate field in the station_info struct in response to whatever stimulus the rate control protocol needs. As a more concrete example, you could use the time when the CPU_LOW DCF reports back that it sent a packet as an opportunity to increase or decrease the rate that future packets to that station. In the IPC_MBOX_TX_MPDU_DONE inter-processor communication message handling, the framework calls "mpdu_tx_done_callback" which corresponds to the "mpdu_transmit_done" function in the AP and the STA. You could pretty easily build a protocol like AARF in these functions by keeping track of how many transmitted packets in a row were successfully ACKed and how many required retransmissions.

At the end of the day, the rate of transmitted packets is specified in CPU_LOW's DCF implementation here. That "rate" argument is lifted from the metadata of the packet that got passed down from CPU_HIGH in the mpdu_transmit function. Depending on how custom you want to get, you can ignore everything I've said up until now and just make sure you change that "rate" argument according to your protocol. For example, that would let you change the rate of the packet between retransmissions. In my above example, you can only change the rate between totally separate MPDUs.

Offline

 

#3 2013-Nov-10 21:09:40

yeowl
Member
From: Cyberjaya
Registered: 2012-May-15
Posts: 44

Re: Rate Control Mechanism in 802.11 Reference Design

Thanks for your explanation. Will definitely take a look on this.

Offline

 

Board footer