WARP Project Forums - Wireless Open-Access Research Platform

You are not logged in.

#1 2013-Oct-11 12:42:46

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

Announcing 802.11 Reference Design v0.5 for WARP v3

We have just released the 802.11 Reference Design v0.5 Beta. This design includes fixes and feature improvements to the AP implementation as well as a completely new implementation of an 802.11 station (STA). With this design, a WARP v3 board can associate and communicate with WARP 802.11 APs or even non-WARP commercial 802.11 APs (provided that security is disabled). If there are any questions about the design or its use, please post them to the forums.

-Chris

Offline

 

#2 2013-Nov-04 13:58:55

NuisanceParameter
Member
Registered: 2012-Apr-19
Posts: 54

Re: Announcing 802.11 Reference Design v0.5 for WARP v3

I'm not sure if this is a bug, intentional, or not, but I've found a spot in the w3 80211 design, v0.5 where the transmit FSM can potentially get stuck and I thought I'd mention it here. Again, I tried to see if this was consistent behavior according to the 802.11a standard, but I wasn't able to find anything quickly that defined how an AP should handle this state. The high-level explanation is that the frame_transmit() function is not fail-safe.

In the main() function of wlan_mac_dcf.f, the low Microblaze enters an infinite loop to process Tx/Rx and peripheral events. We found that if an MPDU is en-queued, the inter-process message frame from the High to the Low processor is processed and the code eventually trickles down to the frame_transmit() function.

In frame_transmit(), the Tx PHY is initialized and triggered and then software enters an infinite loop to wait for the Tx PHY to indicate that the transmission has succeeded:

if((tx_status & WLAN_MAC_STATUS_MASK_MPDU_TX_DONE) || ((tx_status & WLAN_MAC_STATUS_MASK_MPDU_TX_STATE)==WLAN_MAC_STATUS_MPDU_TX_STATE_DONE)) {
...
} while(tx_status & WLAN_MAC_STATUS_MASK_MPDU_TX_PENDING);

The possible bad state (albeit very rare, I admit), occurs when the Tx PHY is unable to start transmission due to the backoff process always being high (CS signal is high, packet detect is always high, NAV set incorrectly, there are a number of pathological ways to make this happen, most of them just code/PHY/configuration mistakes, etc...). In this case, the Tx PHY and DCF PHY will never time out and the infinite software wait loop above will never return code execution to the main polling loop.

The reason why I think this could be improved is that while a well-functioning system should never have this problem (how often can a pending transmit node never capture the channel?), a mis-configured or active-development project would have a hard time catching this error since code execution never returns from frame_transmit(). Perhaps a software timeout or an error message might be appropriate in this case to detect when the Low software loop is stuck waiting for transmit to finish.

It may be somewhat picky, but I hope this is the kind of feedback you guys are looking for as we get more experience with this design.

Offline

 

#3 2013-Nov-04 14:17:06

NuisanceParameter
Member
Registered: 2012-Apr-19
Posts: 54

Re: Announcing 802.11 Reference Design v0.5 for WARP v3

Also, while I'm here, I'm sure you noticed that the v0.5 release doesn't prototype the void wlan_mac_init_hw_info(void) function.

Offline

 

#4 2013-Nov-04 15:58:33

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

Re: Announcing 802.11 Reference Design v0.5 for WARP v3

That's an interesting idea. I think we'll add an optional timeout to the DCF hardware core that could kill the while loop and return an error message back up to CPU_HIGH. We're very hesitant to implement that timeout in software because it would require adding another poll inside that while loop. That loop is the single most time-critical piece of software in the entire design -- the fact that it exclusively polls a single register right now is by design.

Strictly speaking, I think the behavior that it currently implements is correct, but I agree that it could be sensitive to development errors. If the medium is busy indefinitely, the DCF will and should sit there waiting for it to clear up. I don't believe 802.11 defines any kind of max deferral timeout. How long would it even be? A maximum CW draw of 1023 would be, at minimum, ~10ms before before a frame can hit the air. In a dense network where the backoff counter is getting paused a lot, it could be much longer. It's technically unbounded. We'll add the capability in, but leave it as an optional mode.

Offline

 

#5 2013-Nov-04 16:49:20

welsh
Administrator
From: Mango Communications
Registered: 2013-May-15
Posts: 612

Re: Announcing 802.11 Reference Design v0.5 for WARP v3

Also, thanks for the comment about the prototyping of the wlan_mac_init_hw_info function.  We have fixed that for the next release.

Offline

 

#6 2013-Nov-06 02:25:44

NuisanceParameter
Member
Registered: 2012-Apr-19
Posts: 54

Re: Announcing 802.11 Reference Design v0.5 for WARP v3

I've spent the better part of the day tracing packet transmission and reception signals through the software/VHDL project and while just about everything appears to make sense, I don't quite understand the post-TX logic in the software design. The background for this effort is that I'm trying to integrate custom radio hardware with its own timing into the 80211 reference design and I'd like to be sure not to disturb any timing unknowingly.

From what I gather, a packet can be either transmitted successfully (no ACK was required, so assume it made it), transmitted and ACK reception timed out (packet is considered lost, update CW and re-transmit), or the PHY can be currently be receiving a packet when transmission and timeout finishes. Now, as far as I can tell, the signal that sets the WLAN_MAC_STATUS_MPDU_TX_RESULT_RX_STARTED in the WLAN_DCF return status is generated when the Signal field of the received ACK (or arbitrary packet--I don't think we know yet) is decoded properly. In order to properly tell if the received packet was an ACK and was meant for us, we'd have to decode the very next symbol containing the MPDU.

The code in question is the following; my comments added as // NP:

Code:

case WLAN_MAC_STATUS_MPDU_TX_RESULT_RX_STARTED:
	expect_ack = 1;
	// NP - this is non-blocking, so it doesn't appear as if we're waiting for the whole ACK to be received.
	rx_status = poll_mac_rx();
	if((rx_status & POLL_MAC_TYPE_ACK) && (rx_status & POLL_MAC_STATUS_GOOD) && (rx_status & POLL_MAC_ADDR_MATCH) && (rx_status & POLL_MAC_STATUS_RECEIVED_PKT) && expect_ack){
		// NP - good ACK, decode MAC header
		update_cw(DCF_CW_UPDATE_MPDU_RX_ACK, pkt_buf);
		n_slots = rand_num_slots();
		wlan_mac_dcf_hw_start_backoff(n_slots);
		REG_CLEAR_BITS(WLAN_RX_DEBUG_GPIO, 0xFF);
		return 0;
	} else {
		// NP - this seems to assume a bad ACK, but can't it be indeterminate if we haven't completed reception yet?
		if(update_cw(DCF_CW_UPDATE_MPDU_TX_ERR, pkt_buf)){
			n_slots = rand_num_slots();
			wlan_mac_dcf_hw_start_backoff(n_slots);

			REG_CLEAR_BITS(WLAN_RX_DEBUG_GPIO, 0xFF);

			return -1;
		} else{
			n_slots = rand_num_slots();
			wlan_mac_dcf_hw_start_backoff(n_slots);
			REG_CLEAR_BITS(WLAN_RX_DEBUG_GPIO, 0xFF);
			return frame_transmit(pkt_buf, rate, length);
		}
	}
break;

Now, obviously, this code all works in practice and I've verified this. What I'm looking for is a confirmation that the whole ACK is received by the time the above code is executed, or that I'm mis-interpreting the code somehow.

Thanks for the help,

NP.

Last edited by NuisanceParameter (2013-Nov-06 02:26:08)

Offline

 

#7 2013-Nov-06 07:54:58

murphpo
Administrator
From: Mango Communications
Registered: 2006-Jul-03
Posts: 5159

Re: Announcing 802.11 Reference Design v0.5 for WARP v3

From what I gather, a packet can be either transmitted successfully (no ACK was required, so assume it made it), transmitted and ACK reception timed out (packet is considered lost, update CW and re-transmit), or the PHY can be currently be receiving a packet when transmission and timeout finishes. Now, as far as I can tell, the signal that sets the WLAN_MAC_STATUS_MPDU_TX_RESULT_RX_STARTED in the WLAN_DCF return status is generated when the Signal field of the received ACK (or arbitrary packet--I don't think we know yet) is decoded properly. In order to properly tell if the received packet was an ACK and was meant for us, we'd have to decode the very next symbol containing the MPDU.

The control flow here is subtle. The mac_dcf_hw Tx state machine terminates when a timeout occurs or an RX_START event is received. The state machine doesn't care if the RX_START corresponds to an ACK- that's the software's job. This was our way of mapping 802.11-2012 section 9.3.2.8 to hardware.

If an RX_START occurs it could either be the expected ACK, a packet for another node or a packet for which an ACK must be transmitted. We wanted to avoid duplicating code between the idle->receive events and tx->receive events, hence the call to poll_mac_rx() in frame_tramsmit(), the same function called in the main loop to catch new receptions. poll_mac_rx() processes the SIGNAL field and switches on OFDM vs DSSS receptions. It then passes control to frame_receive(), which blocks until the RX_END event occurs (via wlan_mac_dcf_hw_rx_finish()). This function returns the status bits used by frame_transmit() to decide whether the RX_START resulted in the expected ACK (MPDU Tx successful - reset CW, start backoff and return) or not (MPDU Tx unsuccessful - bump CW, start backoff and try again).

Offline

 

#8 2013-Nov-06 11:30:04

NuisanceParameter
Member
Registered: 2012-Apr-19
Posts: 54

Re: Announcing 802.11 Reference Design v0.5 for WARP v3

Thanks for the detailed response, Patrick.

I was missing the calls to frame_receive() in poll_mac_rx(). This makes sense now. In terms of readability, I think the code is just fine as it is; I just added big comments around the blocking sections so that I won't miss them again.

Offline

 

#9 2014-Nov-07 00:13:27

waqas123
Member
Registered: 2014-Nov-07
Posts: 1

Re: Announcing 802.11 Reference Design v0.5 for WARP v3

I'm not sure if this is a bug, intentional, or not, but I've found a spot in the w3 80211 design, v0.5 where the transmit FSM can potentially get stuck and I thought I'd mention it here. Again, I tried to see if this was consistent behavior according to the 802.11a standard, but I wasn't able to find anything quickly that defined how an AP should handle this state. The high-level explanation is that the frame_transmit() function is not fail-safe.

In the main() functi

Offline

 

#10 2014-Nov-07 08:17:06

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

Re: Announcing 802.11 Reference Design v0.5 for WARP v3

I remember seeing that bug in and around the v0.5 era of the design and other users have reported the same thing. It has definitely been fixed as of the v1.0 design. I haven't seen any instability in that design. Here is the changelog for the versions of the design. While that bug isn't explicitly listed, we must have corrected it in some of transmission state refactoring in the designs after v0.5.

Offline

 

Board footer