WARP Project Forums - Wireless Open-Access Research Platform

You are not logged in.

#1 2015-Sep-17 05:42:33

juvebogdan
Member
Registered: 2013-Sep-17
Posts: 76

About ibss ref design

Hi,

I'm confused with line 381 in dcf.c . Why do you transmit when length is less than threshold? Does that mean that if that is ok and fcs is good then something is received other than data frame? And in line 499 you again transmit. Why is this needed?

Also, why do we need mpdu_info (rx_frame_info)? Is that only for logging purpose?

Last edited by juvebogdan (2015-Sep-17 05:44:30)

Offline

 

#2 2015-Sep-17 08:48:28

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

Re: About ibss ref design

You can see the why RX_LEN_THRESH is used in the comment at the beginning of the frame_receive() method:  see here.  As you can see from the code, the first transmit only occurs if the received packet length is less that or equal to RX_LEN_THRESH, while the second transmit only occurs if the received packet length is greater than RX_LEN_THRESH.  Therefore, only one transmit occurs during the method, but the timing of when that transmit occurs is different depending on the length of the received packet.


The mpdu_info is used to log information about the reception for later processing by the receive processes.  As you can see in wlan_mac_ibss.c, while we primarily log all the information in the mpdu_info, it carries information about the FCS state of the reception and the mpdu_rx_process() method uses that to determine whether to discard the packet.  As you can see from the definition of rx_frame_info, there is a lot of useful information in that structure.

Offline

 

#3 2015-Sep-17 09:04:45

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

Re: About ibss ref design

Adding further clarification to welsh's comment, that length-dependent behavior you identified is to ensure that ACKs get set up to sent within a SIFS interval. frame_receive() gets called while a packet is still being received by the PHY. For large packet receptions (>RX_LEN_THRESH), the code has a lot of time to do stuff while it is waiting on the reception to complete. We exploit this window of time to pipeline the responsibilities of the low-level MAC with the continued reception occurring in the PHY. So, for example, the low-level MAC is doing things like calculating the Rx power in dBm based on the RSSI values all while the frame is still being received. For long packets, it can do these various tasks and then still have enough time to set up an ACK transmission within the SIFS interval after the reception. For short packets (<RX_LEN_THRESH), this isn't the case. We don't have a lot of time to do all of that processing. So, instead, we prioritize setting up the ACK transmission (which involves waiting for the entire reception to complete to check the FCS status), and then we get around to doing the other tasks after the reception is complete.

Offline

 

#4 2015-Sep-17 10:09:33

juvebogdan
Member
Registered: 2013-Sep-17
Posts: 76

Re: About ibss ref design

Thank you for your answers.

I want to transmit every packet using different rate and different channel. Also i want to use RTS/CTS handshake to negotiate this channel but to keep RTS/CTS communication on one default channel. Is it possible to use ibss ref design. It seems that beacon transmissions would be compromised, also probes etc.

Can i somehow check if channel is idle like i could in OFDM ref design and store that information in RTS header? All i can see is that i can send to support core information weather to condition transmission on idleness of channel.

Offline

 

#5 2015-Sep-17 11:07:28

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

Re: About ibss ref design

juvebogdan wrote:

I want to transmit every packet using different rate and different channel. Also i want to use RTS/CTS handshake to negotiate this channel but to keep RTS/CTS communication on one default channel. Is it possible to use ibss ref design. It seems that beacon transmissions would be compromised, also probes etc.

That should definitely be possible with some pretty straightforward C changes to the CPU_LOW. You could include the new channel in a customized RTS frame and confirm it with the responding CTS frame and then have both nodes re-tune to the new channel from the upcoming DATA and ACK frames. Would you then hop back to the "control" channel or would you stay on the new channel? Either should work fine. It's not quite the same but you should check out our tutorial on frequency hopping using the 802.11 Reference Design. One small subtlety: it takes about 100 µs for the radio to tune to a new channel. This means you can't tune within the 16 µs SIFS window between the CTS and the DATA frame without elongating it. Currently, both the CTS and Data transmission uses the postRxTimer1 timer to schedule a transmission after the completion of the reception. This timer is set to a 16 µs SIFS by wlan_mac_low_framework. postRxTimer2 isn't used by the Reference Design, so you could set that one to a value larger than ~100µs and tell the MAC core handling the Data transmission to use postRxTimer2 instead of postRxTimer 1. This would leave the gap between RTS and CTS at 16 µs, the gap between DATA and ACK at 16 µs, and only elongate the gap between CTS and DATA to >100µs to account for the radio re-tuning time. I think your changes only need to affect the CPU_LOW design, so they should work regardless of the CPU_HIGH design you are using (AP, STA, or IBSS).


juvebogdan wrote:

Can i somehow check if channel is idle like i could in OFDM ref design and store that information in RTS header? All i can see is that i can send to support core information weather to condition transmission on idleness of channel.

I don't quite follow. If you are transmitting an RTS, the channel by definition is idle since the RTS will only transmit if CCA has not been busy for at least a DIFS. That support core feature allows a transmission to occur regardless of the instantaneous state of the channel. This behavior is dictated by the 802.11 standard for ACK transmissions. If you need to add some kind of metric to the design and communicate that metric to the receiving node, you can modify the RTS packet to include whatever you want.

Offline

 

#6 2015-Sep-18 03:13:02

juvebogdan
Member
Registered: 2013-Sep-17
Posts: 76

Re: About ibss ref design

I wasn't clear enough on my second question. i want to send RTS even in situations when channel is not idle and include that information in the header. On the other hand i want to send CTS only when channel is idle but based on the information in the RTS header on idleness on the transmission to adjust rate of DATA packets. That's why i asked is it possible to check idleness and not just condition transmission on it.

Offline

 

#7 2015-Sep-18 10:22:00

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

Re: About ibss ref design

Do you need the exchange to actually be RTS and CTS frames? Or do you just need some generic exchange of short frames to convey that information? If you don't need to interoperate with Wi-Fi devices, it might be easiest to build the protocol you are envisioning as a modification to the simple NOMAC project rather than a modification to the more complicated DCF.

As for the instantaneous channel state, the MAC hardware support core does actually provide this information in a register that the MAC software can read. Our existing code doesn't need this, so it isn't currently read anywhere. See these definitions in wlan_mac_low.h. Reading the "WLAN_MAC_STATUS_MASK_NAV_BUSY" bit out of the MAC status register will let you know whether or not the NAV is currently running. Reading the "WLAN_MAC_STATUS_MASK_CCA_BUSY" will tell you whether or not physical carrier sensing has been idle for a DIFS period. ORing these two bits together can give you the boolean "busy or free" that you can feed into the construction of your packet exchange.

Offline

 

#8 2015-Sep-21 12:31:29

juvebogdan
Member
Registered: 2013-Sep-17
Posts: 76

Re: About ibss ref design

I don't need interoperability but i like retransmission mechanism in dcf which i want to keep. You said that for my application i don't need to worry about CPU High design but if i communicate channel using RTS/CTS on which channel beacon transmissions would occur since they don't use RTS/CTS? Do i need to modify that part or i can switch it off and disable:

wlan_mac_schedule_event_repeated(SCHEDULE_COARSE, ASSOCIATION_CHECK_INTERVAL_US, SCHEDULE_REPEAT_FOREVER, (void*)association_timestamp_check);

I don't have much experience with registers and Xil_In32 function. What is the address of status register for NAV? Can i make this function in mac_low, i mean is this ok:

boolean NAV() {

return (Xil_In32(ADD) & WLAN_MAC_STATUS_MASK_CCA_BUSY) | (Xil_In32(ADD) & WLAN_MAC_STATUS_MASK_NAV_BUSY);

}

And about adding values to RTS and CTS frames. For channel information i can just add   u8 channel in appropriate struct?

Last edited by juvebogdan (2015-Sep-21 12:33:15)

Offline

 

#9 2015-Sep-23 11:23:06

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

Re: About ibss ref design

juvebogdan wrote:

I don't need interoperability but i like retransmission mechanism in dcf which i want to keep. You said that for my application i don't need to worry about CPU High design but if i communicate channel using RTS/CTS on which channel beacon transmissions would occur since they don't use RTS/CTS? Do i need to modify that part or i can switch it off and disable:

wlan_mac_schedule_event_repeated(SCHEDULE_COARSE, ASSOCIATION_CHECK_INTERVAL_US, SCHEDULE_REPEAT_FOREVER, (void*)association_timestamp_check);

That's a deeper protocol question that I can't really answer since I don't fully understand the application. How should any multicast traffic work (where beacons are just an example)? Should they be sent on the control channel? By definition, a handshake to negotiate a different channel is kind of out of the question for multicast, so I'm not sure what the alternative would be.


juvebogdan wrote:

I don't have much experience with registers and Xil_In32 function. What is the address of status register for NAV? Can i make this function in mac_low, i mean is this ok:

boolean NAV() {

return (Xil_In32(ADD) & WLAN_MAC_STATUS_MASK_CCA_BUSY) | (Xil_In32(ADD) & WLAN_MAC_STATUS_MASK_NAV_BUSY);

}

There is already a macro that is used throughout the design for reading the full MAC status register. It is wlan_mac_get_status(). So, using that macro, your example turns into:

Code:

boolean NAV() {

return (wlan_mac_get_status() & (WLAN_MAC_STATUS_MASK_CCA_BUSY |  WLAN_MAC_STATUS_MASK_NAV_BUSY));

}

juvebogdan wrote:

And about adding values to RTS and CTS frames. For channel information i can just add   u8 channel in appropriate struct?

Yeah, that's probably the easiest approach. Alternatively, you could treat the extra channel information as a "payload" that follows the RTS header in much the same way that DATA packets have a payload following the normal 802.11 MAC header without explicitly adding those bytes to the struct definition. But since you are talking about adding a fixed amount of information to each RTS, modifying the struct is easiest.

Offline

 

#10 2015-Sep-24 01:55:48

juvebogdan
Member
Registered: 2013-Sep-17
Posts: 76

Re: About ibss ref design

I don't really need multicast. Can i disable it? Or just let devices to form IBSS in the beggining and then disable scheduled association_timestamp_check? Can this work?



Or just make RTS/CTS handshake with multicast RTS with beacon transmissions just to make it work.

Offline

 

Board footer