You are not logged in.
Hi, I have some doubts regarding the value of some MAC timing intervals.
a)In particular I have seen that the SIFS is set to 16 usec in the Reference Design. Why the choice of this value is the standard specifies 10 usec for this interval of time. In case can I just change it in 10 usec without any problem?
b) I have seen that in the code it is not specified any Signal extension period that the standard defines equal to 6 usec. Why you don't consider this value and the corresponding field in the packet.
c)Does this implementation consider in the design any NAVRESET TIMEOUT that normally is defined as 2*T_SIFS+T_CTS+aPHY-RX-START-DELAY+2*T_SLOT or it is not present? I didn't find it in the code.
Thank you for the reply
Offline
frenk88 wrote:
Hi, I have some doubts regarding the value of some MAC timing intervals.
a)In particular I have seen that the SIFS is set to 16 usec in the Reference Design. Why the choice of this value is the standard specifies 10 usec for this interval of time. In case can I just change it in 10 usec without any problem?
b) I have seen that in the code it is not specified any Signal extension period that the standard defines equal to 6 usec. Why you don't consider this value and the corresponding field in the packet.
These two questions are related. We went back and forth for a while on the 16 vs. 10 usec SIFS definitions that appear in the standard and concluded that, regardless, there needs to be 16 usec of idle time on the medium prior to the transmission of an ACK (or CTS, etc). Whether you consider this idle time to be 16 usec of SIFS (at 5GHz) or 10 usec of SIFS + 6 usec of signal extension (at 2.4GHz) is largely semantics. For simplicity, we just refer to SIFS as the idle time. As shown in our benchmarks here, the timing values for SIFS in the design are spot on with comparison to commercial 802.11 devices.
frenk88 wrote:
c)Does this implementation consider in the design any NAVRESET TIMEOUT that normally is defined as 2*T_SIFS+T_CTS+aPHY-RX-START-DELAY+2*T_SLOT or it is not present? I didn't find it in the code.
Thank you for the reply
NAVRESET is not currently implemented. To do so is certainly possible, but would require some more complex state in the DCF hardware core. The NAV is currently enforced directly in the MAC DCF core by reading the duration field of all incoming packets. It doesn't currently know about packet exchanges and scenarios under which it should "forget" the old NAV.
Offline
Thank you. I would like also to clarify some more doubts I have:
1) In the matlab file wlan_mac_hw_init.m I have found the value "PHY_RX_START_DLY = 25" usec. What's the scope of this paramenter in the reference design 802.11? Is it different from the TX_RC_PHYSTART_DLY parameter present in file wlan_phy_util.h?
2) The transmission of ACK packet as a reply to a data packet is implemented as autoresponder? In which file I have to look for to find the ACK mechanism?
3)I have taken a look to the graph of the throughput that you obtained with the reference design. i have seen that when payload=1500 byte it arrives near the theoretical value. Isn't it too high?
Thank you.
Offline
1) In the matlab file wlan_mac_hw_init.m I have found the value "PHY_RX_START_DLY = 25" usec. What's the scope of this paramenter in the reference design 802.11? Is it different from the TX_RC_PHYSTART_DLY parameter present in file wlan_phy_util.h?
When the C and M code disagree, trust the C code. Many of the MAC values require calibration in hardware to match the 802.11 timing requirements. The MAC and PHY models use software-configured parameters so this calibration requires only C code changes. The Sysgen models use default values in M for testing, but the values in C are the ones actually used in the full ref design.
2) The transmission of ACK packet as a reply to a data packet is implemented as autoresponder? In which file I have to look for to find the ACK mechanism?
This is implemented in the wlan_mac_dcf_hw.mdl core.
3)I have taken a look to the graph of the throughput that you obtained with the reference design. i have seen that when payload=1500 byte it arrives near the theoretical value. Isn't it too high?
Can you be more specific about which value you're looking at, and what seems wrong about it? We generated the throughput vs pkt size vs modulation rate graph experimentally, and verified our results mirrored the performance of a commercial 802.11g device in the same configuration.
Offline
I took a look of the graph here: http://warpproject.org/trac/wiki/802.11 … Throughput
In particular I have noticed that the value at a rate of 54 Mbps with a payload of 1500 byte is 29.6 Mbps.
I tried to calculate this value and what I get is 29.3 Mbps (ideal one). What surprise to me is that your value is above the one calculated by me.
In order to calculate this value I used the following step:
throghput = (L_PAYLOAD*8)/(T_DIFS+T_BACKOFF+T_DATA+T_SIFS+T_ACK)
with L_payload=1500 bytes, T_DIFS=34 usec, T_BACKOFF=(CWmin -1)*Tslot/2=67.5 usec , Tslot= 9 usec, CWmin=16 usec
T_DATA = T_PREAMBLE+T_SIGNAL+T_SYMB*CEILING(L_SERVICE+L_TAIL+(L_MAC+L_PAYLOAD))/N_dbps + T_EX =254 usec con
T_SIFS=16 usec T_ACK=50 usec, N_DBPS=216 (x data rate 54Mbps)
Which is the formula implemented in your code to calculate T_ACK and T_DATA that are respectively the time to trasmit the a data packet and an ACK packet? did you try also to verify your obtained throughput data through this formula?
Offline
I think the error in the calculation is in the use of T_ACK = 50µs, which is the duration of an ACK at 6Mbps including the 6µs of signal extension. ACK durations are a function of the rate being used. At the 54Mbps rate for DATA packets, ACKs are sent back at 24Mbps. The duration of an ACK at 24Mbps is only 28µs (not counting signal extension, which we lump into the SIFS calculation of 16µs instead of 10µs). I think that reduction in time for each packet accounts for the throughput difference.
Offline
Thank you for the reply. I did the calculation with the new T_ACK and the obtained throughput is compatible with yours.
What I think maybe wrongly is that the frames such as ACK, eventual RTS/CTS and also the MAC header of the DATA frames should be transmitted at the minimum rate (6 Mbps) in a way that all the stations can receive the information. E.g (how can a station far away from the transmitter update the NAV). In case can you provide me the reference where you take the information about the rate of 24 Mbps for the transmission of ACK packets.
I would like also to ask some additional things without open a new discussion:
a) Since I need to implement RTS/CTS mechanism at which rate do you think these packets should be transmitted (with a data rate of 54Mbps)?
b) I would like to implement a bidirectional communication between two devices: say one board programmed as STA sends a message to the AP and the AP, together with the ACK send also a data packet to this STA. Do you think that with the current implementation of the 802.11 reference design this can be done simply?
Thank you.
Offline
The key part of the standard that describes the rate of ACK (and other control packet) transmissions is 9.7.6.5.2 in 802.11-2012. The relevant text is this:
If a CTS or ACK control response frame is carried in a non-HT PPDU, the primary rate is defined to be the highest rate in the BSSBasicRateSet parameter that is less than or equal to the rate (or non-HT reference rate; see 9.7.9) of the previous frame. If no rate in the BSSBasicRateSet parameter meets these conditions, the primary rate is defined to be the highest mandatory rate of the attached PHY that is less than or equal to the rate (or non-HT reference rate; see 9.7.9) of the previous frame. The STA may select an alternate rate according to the rules in 9.7.6.5.4. The STA shall transmit the non-HT PPDU CTS or ACK control response frame at either the primary rate or the alternate rate, if one exists.
Basically, the ACK is sent at the highest basic rate that is lower than the rate of the packet it is a response to. The basic rates are the 1/2 rate codes (6Mbps, 12Mbps, 24Mbps). So, at a 54 Mbps data transmission receives an ACK at 24Mbps, since that is the highest basic rate less than 54. One helpful tip: you can verify that other 802.11 devices have this behavior using Wireshark on a computer that lets you capture 802.11 packets in wireless mode. If you do that, you can see that commercial 802.11 devices follow this rule.
Regarding the next two questions,
(a) CTS packets are treated just like ACKs as far as that paragraph in the standard is concerned, so it's the same. As far as RTS, I don't believe there are any restrictions on rate, but I'm not completely sure on that point. A useful test would be to enable RTS/CTS on a commercial 802.11 AP and use Wireshark to see what it does.
(b) That behavior should be pretty straightforward to add. I think it would be purely C modifications. There are many ways you could do this. For example, you could create a new type of packet (DATA+ACK = DACK?) and ensure that the DCF lower-level MAC treats it as an ACK for the purposes of MPDU transmission as well as passes it up to the AP/STA upper-level MAC for processing (like data packets currently are). Alternatively, depending on your application, you might be able to simply adopt the heuristic that the reception of a data packet within a TIMEOUT from someone you just transmitted to counts as an ACK. In other words, don't even bother with a custom packet type and just let DATA packets count as ACKs if they are received a SIFS after the last DATA packet you sent.
Offline
I need a couple of further clarification.
a)On the standard the EIFS time is defined as:
"The EIFS is derived from the SIFS and the DIFS and the length of time it takes to transmit an ACK frame at the lowest PHY mandatory rate. EIFS = aSIFSTime + DIFS + ACKTxTime, where ACKTxTime is the time expressed in microseconds required to transmit an ACK frame, including preamble, PLCP header and any additional PHY dependent information, at the lowest PHY mandatory rate"
Doing the computation of the ACK time at the lowest rate (6 Mbps) I obtain that:
ACKTxTime (6 Mbps) =16+4+4*CEILING((22+14*8)/24)+6 = 50 usec.
I saw that you set it at 128 usec. Why this value and how to you use it?
Offline
I think you caught us there. The value of 128µs was a large placeholder value during our implementation. We haven't fully characterized the EIFS in the latest beta. It should definitely be reduced.
Offline
Yes I think so. I would like to have your opinion on another thing.
Why the ACK frames, MAC header of Data frames and RTS, CTS packets aren't transmitted at the lowest data rate?
It should be ensured that all the stations (even the most distant that can only tranmit at 6 Mbps) can receive the ACK frame or at least the MAC header to update their NAV.
Consider for example the case where there are multiple stations 802.11g that use different transmission rate. In this case (and consequently in all the situations) it should be used the lowest rate for RTS, CTS, ACK and MAC Header of data frames.
What do you think about this?
Offline
The 802.11 rules for rate selection are given in IEEE 802.11-2012 section 9.7 "Multirate Support"- you should definitely read this section if you're interested in the complete rules for selecting rates for various frames.
The 802.11-2012 multirate section was complicated significantly by the 11n additions. For our current implementation (i.e. SISO only) the similar section in 802.11-2007 is much more readable and still valid. The 802.11-2007 PDF isn't free from the IEEE, but there are many copies online. Quoting 802.11-2007 section 9.6:
To allow the transmitting STA to calculate the contents of the Duration/ID field, a STA responding to a received frame shall transmit its Control Response frame (either CTS or ACK), other than the BlockAck control frame, at the highest rate in the BSSBasicRateSet parameter that is less than or equal to the rate of the immediately previous frame in the frame exchange sequence (as defined in 9.12) and that is of the same modulation class (see 9.6.1) as the received frame.
For the SISO OFDM PHY the mandatory rates are 6, 9 and 12 Mbps (i.e. the rates that use 1/2 rate coding). This means ACKs must be transmitted at 6Mbps (if the DATA frame was 6 or 9), 12 (DATA at 12 or 18) or 24 (DATA at 24, 36, 48 or 54).
The rules for RTS and CTS are also in that section. We haven't implemented these yet, so I'm not positive what the rules here are.
You can also observe this behavior with commercial devices using Wireshark in monitor mode. I definitely encourage you to try this. The standard can be hard to parse- it's often useful to verify your understanding by observing the behavior of other implementations.
Offline
I was directed to this thread. Very interesting discussion.
I have a question here:
T_SIFS=16 us
T_ACK@24Mbps is 28 us
The NAV I obtained from data packet is 43.5us which matches this value 16+28=44 us.
However,
T_ACK@12Mbps I obtained from NAV is 48-16=32 us
T_ACK@6Mbps from NAV is around 60-16=44 us
Why the T_ACK@6/12/24mbps are not linear with respect to their rates?
if T_ACK@24Mbps is 28 us, I expect T_ACK@12Mbps to be 56us. But here seems it's 32 rather than 56 us.
murphpo wrote:
The 802.11 rules for rate selection are given in IEEE 802.11-2012 section 9.7 "Multirate Support"- you should definitely read this section if you're interested in the complete rules for selecting rates for various frames.
The 802.11-2012 multirate section was complicated significantly by the 11n additions. For our current implementation (i.e. SISO only) the similar section in 802.11-2007 is much more readable and still valid. The 802.11-2007 PDF isn't free from the IEEE, but there are many copies online. Quoting 802.11-2007 section 9.6:To allow the transmitting STA to calculate the contents of the Duration/ID field, a STA responding to a received frame shall transmit its Control Response frame (either CTS or ACK), other than the BlockAck control frame, at the highest rate in the BSSBasicRateSet parameter that is less than or equal to the rate of the immediately previous frame in the frame exchange sequence (as defined in 9.12) and that is of the same modulation class (see 9.6.1) as the received frame.
For the SISO OFDM PHY the mandatory rates are 6, 9 and 12 Mbps (i.e. the rates that use 1/2 rate coding). This means ACKs must be transmitted at 6Mbps (if the DATA frame was 6 or 9), 12 (DATA at 12 or 18) or 24 (DATA at 24, 36, 48 or 54).
The rules for RTS and CTS are also in that section. We haven't implemented these yet, so I'm not positive what the rules here are.
You can also observe this behavior with commercial devices using Wireshark in monitor mode. I definitely encourage you to try this. The standard can be hard to parse- it's often useful to verify your understanding by observing the behavior of other implementations.
Last edited by ofdm2013 (2014-Feb-12 18:24:10)
Offline
Not all parts of the message are modulated with the same modulation order. At least the preamble of packets is typically of fixed length, which causes no linear change in time.
Offline
Christian is right -- as seen in the source code here, packet times are composed of a preamble time, PHY SIGNAL field time, and finally an (OFDM symbol time * # of symbols). Those first two components are fixed values irrespective of rate selection, accounting for the behavior.
Offline
Hi, I would like to ask some more things about the topic MAC timing parameters.
1) I have seen that you commented the EIFS parameter in the latest reference design that in the previously releases was set to 128 usec (that in reality should be 88 usec ). Why you no longer use this parameter that is used as interval of time to wait after the reception of a frame with errors? how long do you wait in these situations?
2) I think that PHY_RX_START_DLY that you set to 25 usec in the wlan_mac_hw_init.m file should be set to 24 usec as showed in the table 19-8 of the standard 2012.
3)Referiing again to the SIFS value that you set to 16 usec (in which you include the value of 6 usec of extension time interval in it), I need to separate the two and so setting pure SIFS=10 usec and put the 6 usec in a variable i.e T_EXT because in the all situations that it is required to wait SIFS I want wait the standard 10 usec and not 16 usec. Do you think that operating in this way is a problem or can be done without any problem running the design?
4) In the previuos reference design I have found that you used a Cwmin value = 15 that is the correct one to use as the 802.11 specifications for the calculation of the backoff. In the latest release I'm not able to find it any longer. Could you explain me how you change this parameter and its use.
5) Regarding the ACK TIMEOUT paramater, could you tell me where I can find it in the new reference design, how is calculated and used. I have calculated it for me it results 43 usec, using SIFS=10 usec and PHY_RX_START_DELAY=24 usec as said in 2)
Thank you
Offline
1) The latest reference design arbitrarily lowered it to a DIFS during a test -- I meant to raise that to 88 usec. Feel free to increase the #define of EIFS to 88 usec -- that's probably close. There may be some small hardware-specific changes to that value to actually make it correspond to 88 usec of over-the-air time.
2) There are a couple of things here. First, the MATLAB init files for any of the cores just provide default values into registers that are typically overwritten by software once the node boots. The only place the PHY_RX_START_DLY value is used is in the calculation of the ACK timeout. In software, the T_TIMEOUT value is overwritten as 80 usec. This is clearly too long -- the standard says it should be a SIFS+SLOT+PHY_RX_START_DLY. I'm honestly having trouble remembering where 80 usec came from. We'll look into it. Thanks for pointing that out. Also: 25 usec is taken from Table 18-17 of the 2012 standard (OFDM PHY @ 20MHz). Our PHY was built to the Chapter 18 spec.
3) The problem is that the MAC DCF HW core doesn't know about PHY signal extension. From its perspective, the SIFS starts immediately after the last sample hits the air. So, if you want to decouple SIFS from PHY signal extension, you'd need to modify that hardware design. For my own knowledge -- what is the situation that you would ever want to wait a SIFS without also waiting for the 6 usec PHY signal extension? We had figured there wasn't a scenario where that occurred so we were comfortable lumping the signal extension in with the definition of the SIFS time.
4) The minimum contention window is specified as a #define of DCF_CW_EXP_MIN in wlan_mac_dcf.h. The mapping of those contention window exponents to the actual window range can be found in the block of comments inside rand_num_slots() in wlan_mac_dcf.c. A DCF_CW_EXP_MIN of 4 corresponds to a random slot draw from [0,15].
5) As in my answer to 2), the timeout value is definitely wrong in the current design. That #define is how you can change it with just software
Offline
I was wrong about 3). The MAC DCF HW core *only* knows about the end of transmissions after the PHY signal extension. In fact, when that core is configured by software with amount of time it should wait before sending an ACK, the value that is written is actually ((T_SIFS*10)-((TX_PHY_DLY_100NSEC)+(PHY_RX_SIG_EXT_USEC*10))). That line is a little opaque, but basically the value it is writing is (16usec - 6usec - TX_PHY_DLY). So the "SIFS" time actually written to that core is indeed 10usec (offset by hardware start delay). As you can see in the SIFS calibration page, that value does line up with how other 802.11 devices perform over-the-air.
Long story short -- you could (and should) redefine T_SIFS to be 10 usec and simultaneously make sure that the value written to the MAC DCF core doesn't subtract the signal extension to give you the same behavior. Similarly, the core starts a timeout *after* the signal extension, so T_TIMEOUT should be set with T_SIFS = 10 usec.
Offline
Thank you for your reply,
Ok, I redefined the EIFS time to 88 usec and the T_TIMEOUT to 43 usec in the wlan_mac_low.h file without any further modification.
For the calculation to the 43 usec value I used a value of PHY_RX_START_DLY of 24 usec as said.
One thing here maybe I didn't understand well : since your reference design PHY specifications is based on chapter 18 (OFDM PHY) and you set your value as SIFS=16, PHY_RX_START_DLY = 25 and so on in accordance to table 18-17 (@20 MHz ) you have implemented "802.11a" and not "802.11g" right? Because the specification for 802.11g are given in the section ERP-OFDM in chapter 19 of the standard and the related timing values are the ones in table 19.8.
It is for this motivation that I would like to set the parameter as reported in this table and so SIFS=10usec and extension time= 6 usec separated , PHY_DLY=25 usec, ACK_TIMEOUT=43 usec (from the calculation) in order to be in agreement with the standard for 802.11g.
In a nutshell, once redefined the ACK_TIMEOUT and EIFS as above, if I set T_SIFS=10usec and so as you said (if I have understood right) deleting the 6 usec on the value that is written on the core and so leaving ((T_SIFS*10)-((TX_PHY_DLY_100NSEC)) have I done all the necessary modifications in the design in order to be fully compliant with the 802.11g specifications?
Offline
I agree with your interpretation. The parameters you have provided should work fine. We'll make the same adjustments in future releases. Thanks!
Offline
Dear chunter,
referring to a previous question I made in this topic in which I asked your suggestion about how to implement a bidirectional communication version of DCF (e.g similar to the reverse direction protocol in 802.11n) in which a STA or AP, after having received a data packet from a sender replies in turn to it with a data packet that must be considered by the first sender as an ACK for its initial packet and then the initial sender acknowledge this received packet. Of course between a reception and a transmission a station should wait the standard SIFS time
Long story short the situation I would like to implement is the following exchange when a station gains the channel (after DIFS) (eg):
----------DIFS elaspe--------------------
1) STA-->AP : data packet
----------SIFS elapse-------------------
2) AP-->STA : data packet + ACK
---------SIFS elapse-------------------
3) STA-->AP : ACK
Instead that the standard DCF mechanism:
---------DIFS elapse--------------------
1) STA-->AP : data packet
---------SIFS elapse--------------------
2) AP-->STA : ACK
I would like to have some further suggestions in the way to proceed.
1) Is it possible to use the autoresponder in a way that immediately, or a SIFS time later, after having sent an ACK packet to the sender a station send in automatic a data packet to the same station ? If yes, how?
2) Can I replace the transmission of ACKs with data packets in the autoresponder in order to respect SIFS time requirement to transmit the latters or have I to redefine the packets in a different way as they are? The problem here is that since the creation of data packets is defined in wlan_mac_high_framework, I'm not of course able to recall these packets in wlan_mac_low_dcf project.
Should be possible doing this or with the actual level structure (high and low) of the 802.11 reference design this is not allowed?
Remembering your previous answer regard what I asked about this bidirectional communication protocol:
chunter wrote:
That behavior should be pretty straightforward to add. I think it would be purely C modifications. There are many ways you could do this. For example, you could create a new type of packet (DATA+ACK = DACK?) and ensure that the DCF lower-level MAC treats it as an ACK for the purposes of MPDU transmission as well as passes it up to the AP/STA upper-level MAC for processing (like data packets currently are). Alternatively, depending on your application, you might be able to simply adopt the heuristic that the reception of a data packet within a TIMEOUT from someone you just transmitted to counts as an ACK. In other words, don't even bother with a custom packet type and just let DATA packets count as ACKs if they are received a SIFS after the last DATA packet you sent.
3) You suggested to create a new packet (DACK) in order to do what I want. Since this packet should be treated simultaneously as a data packet and an ACK, how should this packet be defined and at which level (high or low)?
How can I ensure that it will be treated as an ACK for MPDU transmission and it is passed up to upper level MAC as currently data packets?
4)Do you think that this new packet DACK should be defined from scratch or can I simply define another subtype of DATA packet called DACK in wlan_mac_802_11_defs.h as
#define MAC_FRAME_CTRL1_SUBTYPE_DACK (MAC_FRAME_CTRL1_TYPE_DATA | 0x00)
Thank you for any eventual useful further suggestions you give to me in how to prooced.
Last edited by frenk88 (2014-Mar-19 06:25:58)
Offline
frenk88 wrote:
1) Is it possible to use the autoresponder in a way that immediately, or a SIFS time later, after having sent an ACK packet to the sender a station send in automatic a data packet to the same station ? If yes, how?
No, the autoresponder in its current form can’t send a frame a SIFS interval after a previous Tx — it only allows you to send a frame a SIFS interval after a previous reception. Extending the autoresponder to this behavior would require changes to the HDL design. It’s an interesting idea though. We’ll discuss it and seriously consider adding that functionality to a future release. In the meantime, you could just manually send two transmissions one after another from software and I believe you’d be within a SIFS interval. You’d have to use an oscilloscope hooked up to some debug pins to make sure.
frenk88 wrote:
2) Can I replace the transmission of ACKs with data packets in the autoresponder in order to respect SIFS time requirement to transmit the latters or have I to redefine the packets in a different way as they are? The problem here is that since the creation of data packets is defined in wlan_mac_high_framework, I'm not of course able to recall these packets in wlan_mac_low_dcf project. Should be possible doing this or with the actual level structure (high and low) of the 802.11 reference design this is not allowed?
Getting the autoresponder to send a data packet instead of an ACK is easy — it will just blindly send from whatever packet buffer you tell it to send from. In the Reference Design, the packet buffer is filled in with an ACK frame. Instead, you can point it to a packet buffer that contains the data packet that you want to send.
As you’ve pointed out, however, the challenge is how you get a data packet into a packet buffer for it to send. You’d need to make sure that a data packet was ready and make the decision on whether or not to enable the autoresponder all within a SIFS interval. There isn’t time for CPU_LOW to ask CPU_HIGH to pull a data packet from the transmit queue that is destined for the transmitter address of the packet that was just received (i.e. RA address of outgoing = TA address of incoming) — you wouldn’t be able to get that sent out in a SIFS interval.
As a first step, one idea would be to handle the case of receiving a data packet from a partner that CPU_LOW is actively trying to transmit to. Basically, if you are currently backing off and waiting to send a packet to some node, then receiving a packet from that node would let you skip the rest of that backoff and send the packet after the SIFS interval. This obviously isn’t the general case where you can quickly send a DATA packet to any arbitrary destination that you have packets enqueued for, but I think it could still let you run some interesting experiments where an AP and STA have backlogged traffic for one another. Once this is working, you could then move towards generalizing it. At the moment only 2 Tx packet buffers for outgoing MPDUs (ping/pong buffering). 1 Tx packet buffer is used for outgoing ACKs. That leaves 13 unused tx packet buffers that you could use as a sort of “last mile” queue to 13 different stations. That would allow you to handle using the autoresponder to any one of those 13 possible destinations, which might be all you need depending on the size of the network you want to run your experiments with.
frenk88 wrote:
3) You suggested to create a new packet (DACK) in order to do what I want. Since this packet should be treated simultaneously as a data packet and an ACK, how should this packet be defined and at which level (high or low)? How can I ensure that it will be treated as an ACK for MPDU transmission and it is passed up to upper level MAC as currently data packets? 4)Do you think that this new packet DACK should be defined from scratch or can I simply define another subtype of DATA packet called DACK in wlan_mac_802_11_defs.h as
You probably want to hijack one of the reserved 802.11 type/subtype combinations for this kind of packet so that other 802.11-compliant stations on the medium safely ignore the non-standard frame. Take a look at Table 8-1 (page 382) of the 802.11-2012 standard. It defines all the different kinds of type/subtype combinations that 802.11 uses. You can see that an ACK is (type/subtype) = (01,1101). Notice that a DATA type of 10 with subtype of 1101 is reserved. So I would define DACK to be (10,1101). That’s actually pretty nice from a cleanliness standpoint, because it isn’t currently a valid a combination and happens to have the exact same subtype that an ACK does (which this packet acts as). In other words, I’d define it to be:
#define MAC_FRAME_CTRL1_SUBTYPE_DACK (MAC_FRAME_CTRL1_TYPE_DATA | 0xD0)
If it were me, I probably would let CPU_HIGH remain ignorant to this new packet type — it would only ever pass down and receive valid MPDU types/subtypes. In other words, I would do two things:
A) In the DCF reception handling, generalize this bit of code checking if the received frame is an ACK to:
if((rx_header->frame_control_1) == MAC_FRAME_CTRL1_SUBTYPE_ACK || (rx_header->frame_control_1) == MAC_FRAME_CTRL1_SUBTYPE_DACK){
return_value |= POLL_MAC_TYPE_ACK;
}This will make sure the DCF treats the reception of a DACK like it does with an ACK.
B) In the DCF reception handling, I would overwrite DACK packet types as normal DATA packet types just before passing them up to CPU_HIGH. Once you’ve dealt treated it like an ACK in my part A), then there isn’t really a need to keep that type around any more. If you overwrite it back to a normal DATA, when CPU_HIGH will process it just like normal.
Offline
Dear chunter, thank you for your last reply.
I still have some more doubts in my mind that I would like to know from you.
1) As a first test to do the bidirectional DCF communication I want to implement, I have inserted in the c file of AP and STA (wlan_mac_ap.c and wlan_mac_sta.c) a piece of code that whenever a packet is received respectively by a STA or AP, a packet is sent to the sender.
What I'm wondering is how can I proceed in SW in order that such packets are send immediately over the air having the priority to all the other in queue packets and without waiting the required DCF MAC times to access the channel because just doing as I did a packet is sent but it is treated as a normal packet and it has to wait to being transmitted following the DCF policy? I have thought to set a parameter to a value "true" in these situations (e.g int bidirectional_packet=1), pass it to CPU_low (wlan_mac_low_dcf) and at this point (if possible)block the Running of the Backoff related to this station (how?) in order to ensure immediate access to the channel to transmit this packet. Is this feasible? If this is possible how can I pass/making available the mentioned parameter from CPU_HIGH to CPU_LOW and set here a piece of code that allow to block the running of the backoff? Which function or which parameter I have to set in order to block the current backoff?
Can you indicate me also the files and the functions in which I have to operate to do this because I have no clear idea on this.
2) Referring to the point 1) of your reply, you said that it is possible that sending two packets one after the other from sw I respect SIFS time. So in order that the autoresponder of a STA or AP after having send an ACK in reply to a received packet, transmits to the same station a data packet, how have I to act?
3) Referring to your reply here:
As a first step, one idea would be to handle the case of receiving a data packet from a partner that CPU_LOW is actively trying to transmit to. Basically, if you are currently backing off and waiting to send a packet to some node, then receiving a packet from that node would let you skip the rest of that backoff and send the packet after the SIFS interval.
How and at which level have I to operate in order to do this? How can I check if I receive a packet from a station I'm currently trying to transmit and how can a running backoff be skipped.
This obviously isn’t the general case where you can quickly send a DATA packet to any arbitrary destination that you have packets enqueued for, but I think it could still let you run some interesting experiments where an AP and STA have backlogged traffic for one another. Once this is working, you could then move towards generalizing it. At the moment only 2 Tx packet buffers for outgoing MPDUs (ping/pong buffering). 1 Tx packet buffer is used for outgoing ACKs. That leaves 13 unused tx packet buffers that you could use as a sort of “last mile” queue to 13 different stations. That would allow you to handle using the autoresponder to any one of those 13 possible destinations, which might be all you need depending on the size of the network you want to run your experiments with.
With the "size of your network" do you intend the number of WARPs that I use to run my experiment? I have available 3 WARP boards (1 AP and 2 STA) with which do my experiment.
Can you explain me better about the fact that there are 2 Tx packets buffers for outgoing MPDUs (ping/pong buffering)? And about the others 13 unused packets which is their scope, where are they defined and how can I use them in order to put and take packets from them ? Till your answer I was thinking that in transmission phase the packets are put on some queues and they are draw out from this. Which is the relation between the queues and the buffers you mention?
i don't get the point of this.
4) What does it mean the flag DS of a packet and what is the destination DS? If I work just with wireless transmission and reception have I to give importance to this?
5) About the definition of the new subtype DACK packet you said that it's better that CPU_HIGH remain ignorant of such kind of packets. Do you mean that either the upper level MAC of AP and STA both in transmission and reception phase should don't know this packets?
So if I want to create and then send such packets from upper level MAC as actual DATA subtype are treated through the call of the the function wlan_create_data_frame() can I do this or not?
B) In the DCF reception handling, I would overwrite DACK packet types as normal DATA packet types just before passing them up to CPU_HIGH. Once you’ve dealt treated it like an ACK in my part A), then there isn’t really a need to keep that type around any more. If you overwrite it back to a normal DATA, when CPU_HIGH will process it just like normal.
At which point of the code you will put the overwriting from DACK to DATA packets? And you intend overwrite in this way?:
if ((rx_header->frame_control_1) == MAC_FRAME_CTRL1_SUBTYPE_DACK)
{
rx_header->frame_control_1 == MAC_FRAME_CTRL1_SUBTYPE_DATA;
}sorry for the many questions but I have still no clear idea in how to prooced in order to do the bidirectional communication protocol and I want to clarify in my mind these aspects.
Thank you again
Last edited by frenk88 (2014-Mar-24 05:22:18)
Offline
4) What does it mean the flag DS of a packet and what is the destination DS? If I work just with wireless transmission and reception have I to give importance to this?
The From/To DS flags indicate the ultimate source and destination for a packet in a network of APs and STAs and are required to interpret the address1/2/3 fields in each MAC header. Refer to the 802.11 spec or any of the many pages online for more details (this Cisco guide for example; see section 1.4).
2) Referring to the point 1) of your reply, you said that it is possible that sending two packets one after the other from sw I respect SIFS time. So in order that the autoresponder of a STA or AP after having send an ACK in reply to a received packet, transmits to the same station a data packet, how have I to act?
The auto response logic in the wlan_mac_dcf_hw core implements a simple state machine:
-After every wireless reception where FCS == good start a counter
-When the counter reaches the auto-tx interval:
-If auto_tx is enabled, immediately start a new PHY transmission
-If auto_tx is not enabled, reset
The MAC low code uses the state machine to transmit ACKs at a fixed interval (i.e. SIFS) after reception of a packet which requires an ACK response. You can see the corresponding code in wlan_mac_dcf.c:
//Prep outgoing ACK just in case it needs to be sent
// ACKs are only sent for non-control frames addressed to this node
if(unicast_to_me && !WLAN_IS_CTRL_FRAME(rx_header)) {
//Note: the auto tx subsystem will only fire if enabled by software AND the preceeding reception
//has a good FCS. So, as software, we do not need to worry about FCS status when enabling the
//the subsystem.
//Auto TX Delay is in units of 100ns. This delay runs from RXEND of the preceeding reception.
wlan_mac_auto_tx_params_g(TX_PKT_BUF_ACK, ((T_SIFS*10)-((TX_PHY_DLY_100NSEC))),TX_ACK_GAIN_TARGET);
tx_length = wlan_create_ack_frame((void*)(TX_PKT_BUF_TO_ADDR(TX_PKT_BUF_ACK) + PHY_TX_PKT_BUF_MPDU_OFFSET), rx_header->address_2);
//Auto-Tx enable requires rising edge; one rising edge results in 0 or 1 transmissions, depending on Rx FCS
wlan_mac_auto_tx_en(0);
wlan_mac_auto_tx_en(1);
wlan_phy_set_tx_signal(TX_PKT_BUF_ACK, tx_rate, tx_length + WLAN_PHY_FCS_NBYTES);
}This code checks if the received packet requires an ACK and, if so, enables the auto_tx state machine. This code *must* execute before the auto_tx counter reaches its target value. Otherwise the state machine will reset and no ACK will be sent.
The auto-tx state machine only implements Rx->Tx state. For Tx->Tx you must either modify the wlan_mac_dcf_hw core (harder) or imlement the flow in software (easier).
Offline
Dear murpho, in relation to your reply for the point 2) of my previous answer my question is : when you said that the flow of transmission ACK-->DATA to the same station can be implemented in software do you mean that I can act just in the function frame_receive() in wlan_mac_dcf.c? If yes, should i add after the code above you indicated to me, a portion of code that follows the same mechanism you explained to me (and present in the code above for ACKs) to set another "cycle" of the auto_tx_state machine but in this case for transmitting the DATA packet?(Here the problem is that I can't call the fuction wlan_create_data_frame () to prepare a data packet).
Thank you.
Offline