WARP Project Forums - Wireless Open-Access Research Platform

You are not logged in.

#1 2016-Aug-02 11:40:33

sharanmanu91
Member
Registered: 2016-Aug-02
Posts: 17

Priority Contention at the AP

Hi,

I am currently trying to perform real-time wireless transmissions using WARPNet module and WARP v3 boards.

In my current project, I want this implementation:
Once an AP is triggered by our algorithm, it waits for channel to become idle and sends a data packet after PIFS after channel becomes idle. This is to guarantee winning the contention before any other user in the network.

Is there a way the contention window can be set to zero and I don't know if there's a way to shorten the DIFS time interval before backoff begins. Please provide suggestions on how I can make the changes.

Thanks,
Sharan

Offline

 

#2 2016-Aug-02 13:05:32

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

Re: Priority Contention at the AP

That’s definitely doable. And I think you can enable that behavior with just C changes to the low-level DCF in the 802.11 Reference Design.

I like to think of a PIFS as a -1 slot backoff. A transmission after a PIFS would occur 1 full slot before a device that happened to choose slot 0 in its backoff following a DIFS. So, given that, a pretty natural implementation would be to re-define a DIFS to be 1 slot shorter and make it so that normal channel access chooses a random number of slots between [1, CW+1] rather than [0, CW]. Your algorithm could then engage a channel access on a PIFS boundary by intentionally choosing the now-special slot 0 as its backoff.

I think you’d just need to do the following:

1. Change this line to “gl_mac_timing_values.t_difs = gl_mac_timing_values.t_sifs + (1*gl_mac_timing_values.t_slot);”. This will update registers in the MAC hardware core that use the DIFS definition in the DCF state machine.
2. Change the return in this line to “return (n_slots+1);”

Together, those two changes should basically(*) cancel each other out and you’d have a node that operated with normal DCF channel access. Then, finally,

3. For packets sent after your algorithm triggers, you’d want to replace “n_slots” in the call to wlan_mac_tx_ctrl_A_params() with 0.

One helpful tool you can use during this is an oscilloscope. Pin 0 on the WARPv3 board turns high whenever the PHY is actively transmitting and Pin 1 turns high whenever the PHY is actively receiving. Together, you should be able to get a picture of which slots are being used (kinda like this).

(*) Disclaimer: there is a subtle difference caused by reducing the DIFS and trying to back the change out in the slot selection. If a new packet to transmit arrives from the high-level MAC, it will only bother to start a backoff if the medium has not been idle for a DIFS period at the time the node is ready to transmit. So, if the medium were busy slightly more than a PIFS window before the new packet was ready to send, this new implementation would actually attempt a transmission whereas the previous implementation would correctly wait until the full DIFS + random backoff elapsed. This is subtle and it wouldn’t matter if the network is backlogged. It can be resolved, but I wouldn’t worry about it in the first cut of the design.

sharanmanu91 wrote:

It would be great if you clarify a few points in the disclaimer. Specifically, the time "when node is ready to transmit".
Let's say a packet P is sent to the AP from the computer at time T_0 when algorithm triggers but at that point the channel is busy.
Now, let T_1 be the time when channel becomes idle.

If T_1 - T_0 > DIFS, I still want the packet P to be transmitted PIFS after channel became idle. I expect your suggested code changes above would make the network function in this manner.

But from your disclaimer, it seems like the AP will take part in backoff for transmitting packet P if T_1 - T_0 > DIFS.
I will test out on an oscilloscope asap.

At time T_0, the MPDU is passed off to the MAC core for transmission and it is observed that "idle for DIFS" is false. Normally, this should start a backoff timer that begins at (T_1 + DIFS). For you, since you've redefined what a DIFS means, your node will "start a backoff" at (T_1 + PIFS). I put "start a backoff" in scare quotes because, by intentionally choosing n_slot = 0 in the call to wlan_mac_tx_ctrl_A_params(), you can guarantee that the backoff instantly terminates and the transmission occurs on the PIFS boundary.

The scenario I was trying to explain in my disclaimer relates to channel access when your algorithm does not intend to use a PIFS (i.e. you just want to perform normal DCF channel access after a DIFS). Suppose at time T_0 the medium has been idle for more than a PIFS but less than a normal DIFS. With these changes, the MAC core will try to evaluate the question of "idle for DIFS?" at time T_0. Because you've modified what a DIFS means, the answer will be yes when normally the answer would be no. But that only really matters for a new packet arrival from the high-level MAC in the narrow window between a PIFS and a DIFS. I suspect this won't change any fundamental results. That said, if you want to be totally legit, you could actually fix this behavior so that your changes to the design do operate totally like a standard DCF when you aren't otherwise trying to use the PIFS access. To do this, we have to get into a distinction between two related forms of DIFS in the 802.11 standard:

In the DCF code, notice that "gl_mac_timing_values.t_difs" is actually used in two spots:

Code:

wlan_mac_set_DIFS((gl_mac_timing_values.t_difs)*10);
wlan_mac_set_TxDIFS(((gl_mac_timing_values.t_difs)*10) - (TX_PHY_DLY_100NSEC));

Like any radio, the transmit circuitry of the WARP v3 hardware is not instantaneous. From the moment the MAC says "go" on a transmission, there is some delay before the first photon is emitted. That delay, determined empirically by us, is encoded into that "TX_PHY_DLY_100NSEC" #define. If you want a MAC to be able to start transmitting exactly on a DIFS boundary, you have to actually backdate the transmission TX_PHY_DLY_100NSEC earlier than the DIFS. The slot counter used in backoffs is keyed off of the TxDIFS register. The DIFS register is used exclusively for the evaluation of "idle for DIFS?" prior to starting the backoff state machine. More discussion about these two values is available here.

With the changes we have talked about thus far, you'd be changing both DIFS and TxDIFS to the new PIFS value. Instead, if you only changed TxDIFS but let DIFS alone at its standard value, I think you'd get the behavior you want and you'd address the issue in my disclaimer.

Last edited by chunter (2016-Aug-02 13:19:38)

Offline

 

#3 2016-Aug-02 15:31:39

Erica
Member
Registered: 2015-Oct-26
Posts: 18

Re: Priority Contention at the AP

Hi Chris,

My name is Erica and I'm working with Sharan on his project. As to implement our algorithm, I have a overarching python script that uses the wlan_exp functions to control the WARP nodes. Specifically, I generate a local traffic on the AP end using the following code, in which node1 is configured as AP and node2 as one STA:

Code:

 AP_ltg_id = node1.ltg_configure(ltg.FlowConfigCBR(dest_addr=node2.wlan_mac_address,
                                            payload_length=128, 
                                            interval=0.01), auto_start=True)

This will trigger the AP transmission every 10 ms. We want to implement our algorithm in a fully backlogged network and have the AP acquire the channel PIFS time after it became idle every time this specific downlink transmission is triggered.

I understand your suggestions except for Step 3. All transmissions call the same function you mentioned and I don't know how the wlan_exp controls the wlan_mac_dcf C functions. Could you please explain more on how I should "replace 'n_slots' in the call to wlan_mac_tx_ctrl_A_params() with 0" to implement our algorithm to the specific data flow?

Offline

 

#4 2016-Aug-02 16:33:06

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

Re: Priority Contention at the AP

This will trigger the AP transmission every 10 ms.

An important clarification - the LTG framework creates and enqueues packets in the usual per-station Tx queues, at the top level of the MAC code. The wlan_exp code above will create and enqueue a packet every 10 msec. The actual transmission times depend on other Tx traffic, medium activity, etc. The overall flow of Tx and Rx packets is described in the user guide.

I understand your suggestions except for Step 3. All transmissions call the same function you mentioned and I don't know how the wlan_exp controls the wlan_mac_dcf C functions. Could you please explain more on how I should "replace 'n_slots' in the call to wlan_mac_tx_ctrl_A_params() with 0" to implement our algorithm to the specific data flow?

There are two issues here:
(1) Identifying a specific LTG flow as special
(2) Marking packets from the special LTG so CPU Low can implement different timing for those packets

Issue (1) requires some way to mark an LTG flow. The reference Python and C code do not implement this. The only parameters passed to FlowConfigCBR() are the destination address, payload length and packet creation interval. The "right" way is to add a flags field to the FlowConfigCBR() class and all of the sub-classes/structs in wlan_exp and C that handle LTG config. This is doable but tedious.

The quicker method would be to use a magic value for one of the current params as your "special LTG" flag. For example you could define payload_length=100 as the special length, then translate that into the tx_frame_info_t flag (see below) in the AP's ltg_event() function.

Issue (2) is straightforward. There is a 'flags' field in the tx_frame_info_t struct associated with each packet. CPU High creates the tx_frame_info_t for every packet it enqueues. The reference code only defines four flags, leaving 4 bits you can use for custom flags. The tx_frame_info_t is copied into the Tx packet buffer when CPU High prepares a packet for CPU Low. CPU Low uses the tx_frame_info_t fields during its Tx preparations. Your custom code in CPU Low can look for a TX_FRAME_INFO_FLAGS_USE_PIFS flag and react as needed.

Offline

 

#5 2016-Aug-03 15:50:57

Erica
Member
Registered: 2015-Oct-26
Posts: 18

Re: Priority Contention at the AP

Thanks for your clarification. I made modification to the codes as you instructed and I still have one question.

I noticed there's the payload_length variable in the AP's ltg_event() function, which is modified with 802.11 MAC header and then fed into the wlan_mac_high_setup_tx_frame_info function with the custom flags. Can I ask how the value of this variable (in line #981) is related to the payload_length given to the python function ltg.FlowConfigCBR()? I'm thinking writing an if-statement based on the payload length here to raise a different flag for the special LTG flow we want to label.

Last edited by Erica (2016-Aug-03 15:51:48)

Offline

 

#6 2016-Aug-03 16:43:10

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

Re: Priority Contention at the AP

The payload length specified in the Python command for configuring an LTG is everything except the 24-byte MAC header and 4-byte FCS. The idea is that this value is how many useful bytes a frame can carry. Any additional bytes that get tacked on are purely MAC overhead.

The "payload_length" in ltg_event() is what gets passed down in the tx_frame_info_t struct. It includes the entire length of the packet (+28 bytes longer than what you specified in Python). That would be a good place for your if statement. Just as a sanity check, you can put a xil_printf there and look at the UART output of the board and make sure it is doing what you think it is doing.

Offline

 

#7 2016-Aug-09 16:15:49

Erica
Member
Registered: 2015-Oct-26
Posts: 18

Re: Priority Contention at the AP

Thank you Chris! I made it.

Offline

 

#8 2016-Aug-15 14:40:44

sharanmanu91
Member
Registered: 2016-Aug-02
Posts: 17

Re: Priority Contention at the AP

Hi Chris,

Let's say we have a network in which AP is the only node generating data packets. It generates a new packet 10 ms after the previous data packet transmission ended. To implement this, we would need to figure out when the CPU_low completes packet transmission and then begin a counter of 10 ms. When 10 ms is reached, we want the new data packet to be generated at CPU_HIGH of AP.

Erica and I are unsure of how this interaction can work out between CPU_LOW and CPU_HIGH? Please help us out with this implementation!

Thanks,
Sharan

Offline

 

#9 2016-Aug-15 16:00:51

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

Re: Priority Contention at the AP

Could you clarify what these packets from the AP actually are? Are they like beacons, being transmitted at regular intervals of 10ms, but their payloads are only minimally changing? Or are they new data MPDUs being transmitted after 10ms of silence? When you say "generates a new packet 10 ms after," does that mean you want the transmission to start 10ms after or does it mean that a packet gets enqueued 10ms after?

I think there are a few different approaches you could take (e.g. staying purely in CPU_LOW vs. taking a round trip between CPU_LOW and CPU_HIGH), but I need to know a little more about the algorithm before I can offer a meaningful suggestion.

Offline

 

#10 2016-Aug-15 20:55:25

sharanmanu91
Member
Registered: 2016-Aug-02
Posts: 17

Re: Priority Contention at the AP

Hi Chris,

Thanks for the suggestions! I would like to clarify the experiment:

1) The packets are new data MPDUs being transmitted after 10 ms of silence.

2) I want the packet to get enqueued 10 ms after the previous transmission. Thereafter, the AP sets its backoff counter to zero and transmits this new data MPDU PIFS duration after the channel becomes idle.

Thanks,
Sharan

Offline

 

#11 2016-Aug-16 11:54:24

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

Re: Priority Contention at the AP

We're still struggling to understand the node behaviors you've described.

Does your protocol require a new transmission exactly 10 msec after the end of the previous Tx waveform? If so, CPU High cannot implement the "wait for 10 msec" interval since it cannot trigger an immediate PHY transmission following the interval.

This is a fundamental point - CPU High cannot cause the immediate transmission of a packet. CPU High enqueues a packet after preparing it for transmission (after receiving it from Ethernet, after the LTG framework creates a packet, or after the MAC code creates a management frame). CPU High then dequeues packets whenever there is a free Tx packet buffer in the ping/pong buffers between CPU High and CPU Low. After dequeuing a packet CPU High sends a TX_MPDU_READY message to CPU Low via the IPC mailbox. Sometime later CPU Low processes this message and submits the packet to the MAC core for transmission. The latency through this path is variable. It depends on other activity in CPU High, queue occupancy, activity in CPU Low, etc.. There is no fixed timing relationship between CPU High enqueuing a packet and the Tx PHY turning that packet into a waveform. Please be sure to review the user guide Packet Flow page, which describes this pipeline in detail.

Another important point - in the setup you've described, where the AP is the only active node and is only transmitting once per 10 msec, PIFS vs DIFS is irrelevant. If the medium has been idle for 10 msec a node is allowed to transmit a new packet immediately. In this case the DCF will not wait a DIFS interval after being provided a new packet - the new packet will be transmitted immediately after being submitted to the MAC core (see this thread for a related discussion). The DIFS/PIFS intervals are used to align the boundaries of the backoff slot timers at all nodes with pending transmissions. If there are no pending transmissions when the medium goes idle, there are no active backoff counters so the DIFS/PIFS intervals don't matter.

Offline

 

#12 2016-Aug-16 12:42:31

sharanmanu91
Member
Registered: 2016-Aug-02
Posts: 17

Re: Priority Contention at the AP

Hi Patrick,

Thank you for your feedback! I am sorry for the earlier confusion regarding the experiment scenario.

We would like the AP's CPU_HIGH to enqueue a new data MPDU 10 ms (this is just an example value) after the previous data MPDU transmission ends from AP's CPU_LOW. I understand the time duration between the data MPDU enqueued at AP's CPU_HIGH and getting passed to AP's CPU_LOW is a variable. Also, the time between CPU_LOW and the actual PHY transmission is a variable. That is totally fine!

I had explained that there is just AP generating packets in the network to simplify the explanation but clearly it didn't work out. In our actual experiment, we would be having 1 or 2 other nodes with fully backlogged traffic and transmitting to the AP. Yes, I completely agree if the AP was the only one generating the packets then PIFS/DIFS wouldn't matter.  I wanted to focus more on the 1st question about enqueueing a data MPDU in CPU_HIGH after 10 ms of previous transmisson. Hence, I didn't explain the reason for PIFS in more detail.

I hope this clears up our setup! The main question is: How can we setup a counter at the AP that begins countdown from 10 ms (example) immediately after a data MPDU's transmission is completed? Once the countdown completes, a new data MPDU is generated by the AP's CPU_HIGH.

Thanks a lot,
Sharan

Offline

 

#13 2016-Aug-16 14:18:20

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

Re: Priority Contention at the AP

If you need to enqueue a packet at a specific time, you can use the scheduler framework in the upper MAC framework. The upper MAC executes code following reception of a TX_PKT_BUF_DONE message from CPU Low. This message includes the timestamps of every waveform that was transmitted for a given MPDU (multiple waveforms in case of retransmissions). This timestamp records the TX_START event (first sample to the antenna). You can calculate the timestamp of the TX_END event by adding the duration of the transmission to the TX_START timestamp. You could then schedule your new transmission for 10 msec after that TX_END time. For example:

Code:

u32 tx_delay = 10000 - (get_mac_time_usec() - prev_tx_end_time);
wlan_mac_schedule_event_repeated(SCHEDULE_FINE, tx_delay, 1, custom_mpdu_creation_function);

Offline

 

#14 2016-Aug-16 16:42:22

sharanmanu91
Member
Registered: 2016-Aug-02
Posts: 17

Re: Priority Contention at the AP

That's great! We will try it out asap.

Thanks,
Sharan

Offline

 

#15 2016-Aug-17 15:17:58

Erica
Member
Registered: 2015-Oct-26
Posts: 18

Re: Priority Contention at the AP

Hi,

Thank you for all the help so far! I think I still have some minor questions about the coding.

I inserted your suggested code in the upper MAC framework under "case IPC_MBOX_TX_MPDU_DONE" and calculate the prev_tx_end_time from the structure tx_frame_info. I used the TX_FRAME_INFO_FLAGS_USE_PIFS flag bit we set previously to label the flow we want to manipulate here. However, this flag is established when a specific payload_legnth is given to the traffic flow, and I use the FlowConfig class functions and its sub-classes (i.e. FlowConfigCBR) in the Python framework to create the traffic flow and specify the payload_length.

My question is: if we want to create a custom_mpdu_creation_function in the C code, how should we specify the payload_length and make sure it is used as a tag for the tx_frame_info flags? And how should we control the whole experiment via the Python framework? Thank you very much.

Offline

 

#16 2016-Aug-17 17:14:49

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

Re: Priority Contention at the AP

Erica wrote:

I inserted your suggested code in the upper MAC framework under "case IPC_MBOX_TX_MPDU_DONE" and calculate the prev_tx_end_time from the structure tx_frame_info.

Before going too much further into this, I want to briefly highlight one architectural thing that may turn out to be important. The whole CPU_HIGH software design relies heavily on callbacks to a common framework. The idea is that the MAC High Framework implements features that are common to all CPU_HIGH applications (AP, STA, IBSS) and the applications themselves are responsible for attaching functions to the framework that should be called upon certain conditions. The reason I'm bringing this up is that one alternative to modifying the IPC_MBOX_TX_MPDU_DONE case directly in the framework is to instead implementing your new code in the AP code and attach a function to the framework via the wlan_mac_high_set_mpdu_tx_high_done_callback. The framework is set up to call the application code on the IPC_MBOX_TX_MPDU_DONE event. The default AP code doesn't care, so it doesn't bother attaching a function to that callback. This line is where the framework calls that callback. You can see that it calls it with two arguments, a tx_frame_info_t* tx_frame_info and a tx_high_entry* tx_high_event_log_entry. So, you'd need to create a function that takes in those two arguments if you want to attach it to the framework.

This isn't necessarily better than directly modifying the framework like you did. Just pointing it out in case it makes things easier (e.g., that you need access to some variable state in the AP and would have to do some awkward externing of global variables to see that state in the framework).

Erica wrote:

I used the TX_FRAME_INFO_FLAGS_USE_PIFS flag bit we set previously to label the flow we want to manipulate here. However, this flag is established when a specific payload_legnth is given to the traffic flow, and I use the FlowConfig class functions and its sub-classes (i.e. FlowConfigCBR) in the Python framework to create the traffic flow and specify the payload_length.

My question is: if we want to create a custom_mpdu_creation_function in the C code, how should we specify the payload_length and make sure it is used as a tag for the tx_frame_info flags? And how should we control the whole experiment via the Python framework? Thank you very much.

Yeah, this is tricky. Your application has outgrown the concept of the FlowConfigCBR LTG. For you, the "schedule" that the LTG is following isn't as simple as periodically enqueuing things. I can think of three options, that each hit different points in the tradeoff between flexibility and implementation difficulty.

1. The "right" way to do this is to create a new type of LTG. The "CBR" label is really just the pairing of the "periodic" ltg schedule with a "fixed" ltg payload. Really, you're describing a new type of schedule where the conditions for calling the application's ltg_event() isn't governed strictly by the amount of time that has passed since the last call to ltg_event(). Picture making a new type of schedule that calls ltg_event if and only if a variable gets set to 1. That variable could be controlled by your changes in mpdu_tx_high_done_callback(). This is the most formal solution that retains all of the existing wlan_exp flexibility. But it might be overkill for what you want to do.

2. Another approach is just abandon the LTGs entirely and just do this manually in C. You could create a simple wlan_exp command for enabling or disabling the traffic flow. One nice thing about this is that the hack of tying a specific payload length to the PIFS or DIFS switch is no longer necessary. custom_mpdu_creation_function() can use whatever payload length it wants as long as it sets the TX_FRAME_INFO_FLAGS_USE_PIFS flag.

3. This is out there, but do you really need the packets to be created and enqueued at a specific time? Or is it equivalent to say the AP shall not de-queue any packets for a certain amount of time after each transmission? If so, you could just let the LTG enqueue stuff at its leisure but only upon the spigot in poll_tx_queues() after your scheduled event has expired. It's pretty goofy, but imagine setting a global variable to 1 in your implementation of IPC_MBOX_TX_MPDU_DONE. If this variable is 1, then force wlan_mac_high_is_dequeue_allowed() to return 0. Then set the global variable back to 0 after your scheduled event expires and manually call poll_tx_queues(). At this point, the application will see that it is allowed to dequeue the next packet. This would in effect force a minimum time after a transmission before any future transmission occurred. Just an idea.

Offline

 

#17 2016-Aug-19 12:06:00

Erica
Member
Registered: 2015-Oct-26
Posts: 18

Re: Priority Contention at the AP

Could you explain more on approach 2? We need the packets to be created and enqueued an exact amount of time after the previous transmission has been finished.

If I'm going to write this custom_mpdu_creation_function(), where should I locate it and how should it interact with other functions in the packet generation codes? Is there some tricky way to use the existing packet generation functions instead of writing a new function?

As I'm not familiar with how the Python wlan_exp passes down information to the low-level C code, I have no idea how to use a wlan_exp command for enabling or disabling the traffic flow. All I know about the wlan_exp is from the framework documentation, which only lists the functions and classes.

I'm sorry for asking this all along.

Offline

 

#18 2016-Aug-22 09:34:58

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

Re: Priority Contention at the AP

Erica wrote:

Could you explain more on approach 2? We need the packets to be created and enqueued an exact amount of time after the previous transmission has been finished.

If I'm going to write this custom_mpdu_creation_function(), where should I locate it and how should it interact with other functions in the packet generation codes? Is there some tricky way to use the existing packet generation functions instead of writing a new function?

I don't have a step-by-step on how to accomplish approach 2, but I can point out a couple of fundamentals that you should study because similar ideas will be needed in your implementation. Packets get created all over the place in CPU_HIGH. Here is where a probe request is created and enqueued into the MANAGEMENT_QID queue. Here is where an LTG data is created and enqueued into STATION_ID_TO_QUEUE_ID(station_info->ID). There are other examples, including data packets from the Ethernet portal and management handshake packets. You'll want to do something similar in your custom_mpdu_creation_function() that gets called at some fixed interval after the previous MPDU_DONE IPC event. poll_tx_queues() is then responsible for checking queue contents and calling the framework function for passing down the next MPDU that should be transmitted.

Erica wrote:

As I'm not familiar with how the Python wlan_exp passes down information to the low-level C code, I have no idea how to use a wlan_exp command for enabling or disabling the traffic flow. All I know about the wlan_exp is from the framework documentation, which only lists the functions and classes.

Python only ever directly interacts with the wlan_exp C code in CPU_HIGH. That code can then interact with CPU_LOW with IPC messages. For approach 2, however, I don't think you'd need Python to talk to CPU_LOW. You just need to make a new Python command that enables or disables the behavior of calling custom_mpdu_creation_function() after the MPDU_DONE IPC event.

Offline

 

#19 2016-Aug-22 20:25:22

sharanmanu91
Member
Registered: 2016-Aug-02
Posts: 17

Re: Priority Contention at the AP

Hi Chris,

Thanks a lot for sharing the possible 3 approaches! I find the approach 3 to best suit for us. You are right: We don't really need the packet to be created and enqueued at a specific time. We just need  the packet to be dequeued from CPU_HIGH at a specific time after the transmission of previous packet ends at CPU_LOW.

We will go ahead with the Approach 3.

Thanks,
Sharan

Offline

 

#20 2016-Aug-23 17:06:28

Erica
Member
Registered: 2015-Oct-26
Posts: 18

Re: Priority Contention at the AP

Hi,

We're implementing approach 3. As we might want to change the delay time (10 ms is just an example), is it possible to control a global variable in wlan_mac_high via the wlan_exp Python scripts? Thank you very much!

Offline

 

#21 2016-Aug-23 17:43:44

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

Re: Priority Contention at the AP

Please refer to the extending wlan_exp page in the user guide. This page explains how to extend the wlan_exp Python and C for custom commands that interact with CPU High and CPU Low.

Offline

 

#22 2016-Sep-06 22:33:32

sharanmanu91
Member
Registered: 2016-Aug-02
Posts: 17

Re: Priority Contention at the AP

Hi Chris and Patrick,

Is there a way to obtain the time between a packet entering CPU_LOW and the first transmission attempt of the packet at the PHY layer? I am using the log entries defined in http://warpproject.org/trac/wiki/802.11 … ntry_types

For a specific packet lets say packet X, using the timestamp when X got enqueued in CPU_HIGH and the time_to_accept, I find out the timestamp at which X  got dequeued to CPU_LOW. However, the time_to_done only provides the total time when the packet transmission finally completed including the retransmissions of X. When a new packet entered CPU_LOW, the next log entry in the timestamp of CPU_LOW need not be of X but could be of already existing packet Y or Y's retransmissions.

Is there a way to obtain a time_to_first_transmit which is basically the time when a packet arrived in CPU_LOW and it's first transmission attempt at the PHY layer? If this is not possible, is there a way to disable retransmissions for a specific node in the network. Any of these would be great. Thanks!

Offline

 

#23 2016-Sep-07 00:11:48

sharanmanu91
Member
Registered: 2016-Aug-02
Posts: 17

Re: Priority Contention at the AP

Actually, I just figured the tx_attempt and num_tx log entries can help me find out the timestamp of the first attempt, second attempt, etc.
Sorry for not finding it earlier.

But I still got the question: Can we disable retransmissions for specific nodes in the network? If so, how to go about it?

Offline

 

#24 2016-Sep-07 09:12:33

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

Re: Priority Contention at the AP

sharanmanu91 wrote:

But I still got the question: Can we disable retransmissions for specific nodes in the network? If so, how to go about it?

The retry limits aren't implemented per-node. The DCF applies the same dot11ShortRetryLimit and dot11LongRetryLimit for any and all frames that need the 802.11-2012 9.3.4.4 recovery procedure.

If you really want to disable all retries, you can lie to the DCF and claim that packet being transmitted is a multicast packet (which have no retries since there are many receivers). That will ensure that the frame_transmit() context exits immediately after transmitting rather than waiting around for an ACK. This is pretty easy to do. Just omit "TX_FRAME_INFO_FLAGS_REQ_TO" from the call to "wlan_mac_high_setup_tx_frame_info()" for any frames that you do not want to require timeouts.

One weird outcome of this is that your receiving nodes will still send an ACK, which is pointless since the transmission state machine terminates regardless of whether or not the transmission is successful. You could actually define a totally new nonstandard packet type and modify the DCF to look for that packet type when deciding whether or not to send an ACK.

Offline

 

#25 2016-Sep-07 09:48:28

sharanmanu91
Member
Registered: 2016-Aug-02
Posts: 17

Re: Priority Contention at the AP

Okay converting the specific packets to multicast packets would be an easy fix, thanks a lot!

Offline

 

Board footer