WARP Project Forums - Wireless Open-Access Research Platform

You are not logged in.

#51 2017-Jun-05 09:33:50

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

Re: Experiment with TokenMAC

warp_user wrote:

In terms of associating STAs to the AP network, I am planning to use hard association with STA MAC addresses already assigned to the AP at the start (rather than going through the registration via beacons). This will let me test in a real setup compared to wlan_exp set up.

I just want to point out that you can still use wlan_exp in conjunction with "real" Ethernet traffic instead of LTGs. We designed wlan_exp so that it could be used simply as a management interface for modifying the association state and Tx parameters of the network if you don't want it running the actual experiment. This would also avoid having to do an over-the-air association since wlan_exp reaches into the nodes' internal state to directly set the association.

warp_user wrote:

In addition can you let me know how to test that both stations are correctly assigned for reservations in the "set_new_reservation()" loop in the right order?

The order is arbitrary in that implementation. The first STA that gets serviced is the one with the lower AID. So, whoever you associate first will get the first slot. To verify that everything is configured correctly, you'll have to check the length of the association table. In the parlance of the v1.3 design, that association table is "my_bss_info->associated_stations". You can check it's length with "my_bss_info->associated_stations.length". With wlan_exp, you can retrieve the currenly associated stations and make sure both are there. Without wlan_exp, you'll have to print that value and be careful that the print isn't affecting the performance of your node. Alternatively, the UART menu will print out every associated station if you use the interactive menu by pressing the "1" key.

warp_user wrote:

With respect to connecting WARP radio boards, I use cabling with SMA connectors and currently there is a 50dB attenuation between the AP and the STA. Can you elaborate how to extend this for multiple STAs, with the use of a power splitter and essential attenuation between the STAs?

As I mentioned in the previous response, the hidden nodes with RTS/CTS example shows one particular way of connecting 3 nodes with coax cables and attenuators. In that setup, we intentionally wanted each STA to be hidden from each other, so a 50dB attenuator was added to each output of the splitter. That way, each STA's "view" of the other STA traversed 100dB of attenuation + the 10s of dB of isolation between the two output ports of the splitter. If you want a "fully connected graph" of a network where every device sees every other device with the same amount of attenuation, you'll have to do some back of the envelope calculations to figure out how much attenuation should be added to each of the 3 ports on the power splitter. For this MAC, however, the STAs don't really need to hear each other -- they only need to hear the token message from the AP.

Offline

 

#52 2017-Jun-14 04:52:48

warp_user
Member
Registered: 2014-Feb-27
Posts: 70

Re: Experiment with TokenMAC

Many thanks for your response, it is very useful for a successful implementation (still working on this though).
If I want to extend this to Token MAC design to more than two devices, can you recommend 2 way 3 way or 4 way splitters to be used in the setup.
I need your advise on couple more things,
I would like to interchange DCF and Token MAC based on the application/device type. For example a given application can choose to use Token MAC and for the rest of the time fall back to DCF. Could you please let me know where in the code this can be implemented effectively? My initial thought is the selection of which MAC lies in mac_high processor and both Token MAC and DCF have to be implemented in mac_low processor. Looking forward to your discussion on this.   

Thanks in advance

Offline

 

#53 2017-Jun-14 09:06:33

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

Re: Experiment with TokenMAC

We've had good luck with RF splitter/combiners from Mini-Circuits and Pasternack. When selecting a splitter be sure to consider its supported frequency range (coverage of >2.4GHz, >5GHz if you need it), insertion loss (lower the better) and isolation between neighboring ports (higher the better). Always ensure >30dB attenuation (combination of insertion loss, isolation and additional attenuation) between any two RF interfaces that might transmit.

I would like to interchange DCF and Token MAC based on the application/device type. For example a given application can choose to use Token MAC and for the rest of the time fall back to DCF. Could you please let me know where in the code this can be implemented effectively?

This will be challenging. The TokenMAC app note is based on NoMAC, so the app note code cannot fall back to the DCF as-is.

The two approaches I see, both pretty hard:
-Create a custom TokenMAC implementation based on the DCF instead of NoMAC; this is doable, but is a big project. The DCF is much more complicated than NoMAC. It is conceivable you could modify the DCF to optionally bypass all its normal medium access behaviors (essentially a run-time selection between DCF and NoMAC), then add token passing behaviors on top of this. In this scheme CPU High could instruct CPU Low to switch between DCF and TokenMAC modes.

-Figure out a way to load different .elf files into CPU Low at run time. This is technically possible (the debugger does it, plus the ILMB memory is writable by the CPU), but we have never tried this. And even if this worked it would require rebooting CPU Low to switch modes.

Offline

 

#54 2017-Jun-23 06:05:07

warp_user
Member
Registered: 2014-Feb-27
Posts: 70

Re: Experiment with TokenMAC

Many thanks for your very helpful suggestions.

With respect to the first method can you describe a bit more on implementation of 'a run-time selection between DCF and NoMAC'? Wouldn't this be implemented in CPU HIGH (either or both in wlan_mac_ap.c and wlan_mac_sta.c)?
Also how to notify the changes for selection (between DCF and NoMAC) from CPU HIGH to CPU LOW?
The selection concept is once each AP/STA finishes a NoMAC cycle it needs to go back to DCF until the next NoMAC cycle get started.

Thanks in advance

Offline

 

#55 2017-Jun-23 07:28:14

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

Re: Experiment with TokenMAC

CPU High can send an IPC message "Change MAC Protocol" - implementing this message in CPU High is straightforward. The hard part is implementing the actual protocol switch in CPU Low. We cannot provide detailed instructions for this as we've never tried implementing it.

Building a combined NoMAC+DCF is doable but will require extensive C code changes in CPU Low.
For example consider the two frame_transmit()
functions:
NoMAC frame_transmit()
DCF frame_transmit_general()

At a high level these functions do the same thing. A "TX_READY" message comes from CPU High indicating a new packet is ready for transmission. The frame_transmit() function runs the MAC protocol's Tx process for that packet, then returns a status message to CPU High. The DCF transmission process is, of course, way more complicated. The DCF implements RTS/CTS, deferral to medium activity, timeouts, re-transmissions, etc. It's definitely conceivable you can modify the DCF frame_transmit_general() function to behave like the NoMAC frame_transmit(), bypassing all this DCF-specific behavior to "just transmit and return" each packet. But there's no simple way to do this, you will need to modify the existing DCF code to add a "NoMAC mode" that can be enabled/disabled programmatically.

Offline

 

#56 2017-Jun-23 09:36:30

warp_user
Member
Registered: 2014-Feb-27
Posts: 70

Re: Experiment with TokenMAC

Many thanks for your quick response.

My initial thought is having both NoMAC and DCF MAC implemented in parallel (rather than changing the DCF frame_transmit() behave similar to NoMAC frame_transmit(). This will all be within CPU_LOW. In addition the switching between the two MACs (also at CPU LOW) is based on a selection criteria (may be coming from CPU HIGH).

When each MAC is operating the other has to be disabled and plan to achieve this by changing the status of the medium using a global variable similar to 'allow_new_mpdu_tx' as used in TokenMAC. This global variable will be checked to see whether the medium is clear before enabling each MAC. Once enabled the medium will be set to busy to avoid a clash in accessing the two MACs. Once each MAC completed its cycle then the global variable will indicate the medium is free for future MAC assignements.

Can you give any advise on this please?

Many thanks

Offline

 

#57 2017-Jun-26 08:44:04

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

Re: Experiment with TokenMAC

I think you'll have better luck implementing the CPU Low application as the combination of your required MAC behaviors, not as two MACs operating independently. Whatever the software is doing there is a single instance of the underlying hardware. The MAC core, for example, has one instance of the key blocks (DIFS timer, Tx A/B/C/D state machines, backoff slot counter, etc) used by the MAC software. You can design a MAC software application that switches between modes, but however complicated the software it must still use the single instance of the underlying hardware.

An important note - if you're going to undertake this custom MAC implementation, I would *strongly* encourage you to update to the latest release of the 802.11 Ref Design (currently v1.7.0). We've made a ton of improvements in recent releases, some of which will simplify this kind of custom application for CPU Low.

One general approach would be to recognize that most of the MAC protocol is implemented in the frame_transmit()[1] and frame_receive() functions. You could implement the DCF and NoMAC Tx/Rx functions in a single file (appropriately renamed), then call either the DCF or NoMAC versions per-packet based on the current "MAC Mode".

This isn't as simple as copy-paste-compile. For example frame_receive() is actually called (via a callback) by the low framework to handle Rx events that must be processed by software. You would need to switch this callback assignment when switching MAC modes. Another complication is that frame_transmit() relies on nested calls to frame_receive() (via wlan_mac_low_poll_frame_rx()) to handle Rx events that occur while a Tx is pending or following a Tx event (i.e. ACK Rx or Rx during timeout). The DCF frame_transmit() relies on feedback from the DCF frame_receive(), so you have to be careful about terminating all pending Tx/Rx activity before switching the Rx callback.


[1] The latest DCF actually has two frame_transmit() functions, one for multicast packets transmitted in a DTIM (frame_transmit_dtim_mcast()) and one for all other transmissions (frame_transmit_general()).

Offline

 

#58 2017-Jun-26 09:46:28

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

Re: Experiment with TokenMAC

murphpo's suggestion would definitely work, but I also think you could keep the two MACs relatively independent rather than mixing their behaviors into one large MAC. Disclaimer: this isn't a step-by-step how-to on how to build this. This is just how I would personally approach the problem if I was tackling it. I'm sure there are many subtleties I haven't thought of. You'll have to deeply study both MACs and the MAC Low Framework to do this.

Here's a high-level outline of how I'd go about implementing this project:

1) Add a global variable to the MAC Low Framework to track which MAC mode you are in (i.e. DCF or TokenMAC). Change this global variable in a new IPC message from CPU_HIGH.
2) You can't have multiple main() functions, so demote the main() in each MAC application by renaming to main_dcf() and main_nomac().
3) Add a new file and create a new top-level main() function that simply calls one of the two sub-main functions based upon the global variable you added in the first step (you'll have to extern the variable so that you can see it in the scope of this new file). You'll want to put this in a while(1) loop for reasons that will become apparent in the next step.
4) Finally, alter both while() loops in main_dcf() and main_nomac() to poll the status of the global variable you created (again, you need to extern the variable to see it in the scope of the NOMAC and DCF files). If the code notices that the global variable changes from its existing value, then you can "return;" out of the while loop and back to the top-level main(). Since you put the switch on the global variable in its own while(1) loop, the variable will get re-evaluated and the code will enter the sub-main() function of the other MAC.

In effect, you are "rebooting" the low MAC whenever CPU_HIGH send the command to switch to the other MAC. It would re-execute everything that it normally does at boot.

Offline

 

#59 2017-Jun-26 10:32:38

warp_user
Member
Registered: 2014-Feb-27
Posts: 70

Re: Experiment with TokenMAC

Many thanks for both proposals and will study them in detail before undertaking this task.

Offline

 

#60 2017-Jun-30 11:03:53

warp_user
Member
Registered: 2014-Feb-27
Posts: 70

Re: Experiment with TokenMAC

In the second method proposed above, regarding adding a 'new file and create a new top-level main() function' will this file be added to the project as a separate folder or as a file inside one of the MAC folders (DCF or NoMAC)?

Many thanks

Offline

 

#61 2017-Jul-01 15:21:04

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

Re: Experiment with TokenMAC

You can organize the files in an SDK application project however you want. The SDK compiles all source files, then the linker pulls all the object files together.

Offline

 

#62 2017-Jul-27 05:28:57

warp_user
Member
Registered: 2014-Feb-27
Posts: 70

Re: Experiment with TokenMAC

Code:

//

1) Add a global variable to the MAC Low Framework to track which MAC mode you are in (i.e. DCF or TokenMAC). Change this global variable in a new IPC message from CPU_HIGH.
//

As specified in the above, a global variable is added to wlan_mac_low.c to change the MAC model to use in the main() function. I assume that this variable does not need to be accessed by CPU_HIGH. Change of this variable is done by based on an IPC message from CPU_HIGH, which is handled at wlan_mac_low.c.
My question is how to enable the generation of this new IPC message from CPU_HIGH which will get executed at wlan_mac_low.c. Is this something which can be done using callback functions?

In addition is there a way to debug wlan_mac_low.c and wlan_mac_high.c using xil_printf() messages at the output? Since the i/o is based on fpga programmed to CPU_LOW and CPU_HIGH this will only give debug messages for AP and STA (for cpu high) and wlan_mac_low.c (for cpu low).

Thanks in advance

Offline

 

#63 2017-Jul-28 11:10:59

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

Re: Experiment with TokenMAC

warp_user wrote:

As specified in the above, a global variable is added to wlan_mac_low.c to change the MAC model to use in the main() function. I assume that this variable does not need to be accessed by CPU_HIGH. Change of this variable is done by based on an IPC message from CPU_HIGH, which is handled at wlan_mac_low.c

That's right. The MicroBlazes can't directly access variables from each other. You have to use the IPC system to tranfer what you need between them.

warp_user wrote:

My question is how to enable the generation of this new IPC message from CPU_HIGH which will get executed at wlan_mac_low.c. Is this something which can be done using callback functions?

It's just like what you did for the TokenMAC extension. In that example we created two new types of message, IPC_MBOX_TOKEN_NEW_RESERVATION and IPC_MBOX_TOKEN_END_RESERVATION. For this you'd create another IPC message over which you'd set the state of the new global variable.

warp_user wrote:

In addition is there a way to debug wlan_mac_low.c and wlan_mac_high.c using xil_printf() messages at the output? Since the i/o is based on fpga programmed to CPU_LOW and CPU_HIGH this will only give debug messages for AP and STA (for cpu high) and wlan_mac_low.c (for cpu low).

You can't view both UART outputs at the same time. The design has a UART mux for selecting between the CPU_HIGH and CPU_LOW UARTs over the single microUSB connector. The rightmost DIP switch will let you toggle between them. You can add prints to either CPU for debugging, but you can only view one at a time over the single connector.

Offline

 

#64 2017-Aug-02 11:55:24

warp_user
Member
Registered: 2014-Feb-27
Posts: 70

Re: Experiment with TokenMAC

Once dcf mac is in Release 1.3 in (http://warpproject.org/trac/wiki/802.11/Changelog) when the STAs are associated with the AP, they do not increment their hex displays accordingly (they stay at ‘0’). In 0.96 Beta Release once STAs are associated they get incremented. Is this the intended behavior in Release 1.3 in contrast to 0.96 Beta Release? Since token MAC changes are done in Release 1.3 it is needed to use dcf function in Release 1.3 as well in the combined model.
Thanks in advance

Offline

 

#65 2017-Aug-03 09:32:29

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

Re: Experiment with TokenMAC

No, that is not the intended behavior. Does that behavior occur with the stock unmodified bitstreams provided in the reference bitstreams? Any chance that the leftmost User I/O DIP switch is raised on either of your boards? The 1.0 release added the behavior where the leftmost DIP switch can be used to prevent automatic association on boot. That's my best guess as to why you are seeing a difference in behavior between 0.96 and 1.3.

Offline

 

#66 2017-Aug-03 10:23:12

warp_user
Member
Registered: 2014-Feb-27
Posts: 70

Re: Experiment with TokenMAC

Many thanks, indeed the problem was with user I/O DIP switch.

Offline

 

#67 2017-Aug-10 06:44:42

warp_user
Member
Registered: 2014-Feb-27
Posts: 70

Re: Experiment with TokenMAC

I have merged DCF and Token MAC and currently running tests only in AP first.
For simplicity I am choosing preferred MAC by setting a global variable at top level main()function (associated with CPU low). The very first problem I have encountered is beacon signals. Once AP is programmed with DCF can see beacon generations using a spectrum analyser. But once programmed with Token MAC beacon signals are not there (no signal is generated).

Can you describe the step by step relationship between beacon_transmit()and CPL Low functions?

I could not fully implement the two MACs in parallel as it is too big (elf files) for the fpga. Therefore common functions are shared between two MAC implementations in CPU LOW. Can you advise on how to reduce the elf size as well.

I am using version 1.3

Many thanks

Last edited by warp_user (2017-Aug-10 06:45:49)

Offline

 

#68 2017-Aug-13 15:37:55

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

Re: Experiment with TokenMAC

There's not a lot we can do to help debug your custom code. I would suggest adding xil_printf() statements in the beacon_transmit() function and in the CPU Low functions which handled IPC message reception and packet transmission. If beacons are being generated but not transmitted, you should be able to isolate where the beacon_transmit -> transmission flow breaks. If beacons are not even being generated, you will know to focus on CPU High and the scheduled execution of beacon_transmit().

Offline

 

#69 2017-Aug-15 03:07:44

warp_user
Member
Registered: 2014-Feb-27
Posts: 70

Re: Experiment with TokenMAC

Many thanks for your quick response.

In current implementation the duration is of fixed length as specified below.

Code:

 
#define DEFAULT_RESERVATION_DURATION_USEC 2000

I need to change the above allocation period to be equal to the length of each STA’s transmission queue length. The purpose is to keep the medium occupied until all the packets in each STA queue is served. Can you point me where these changes can be done in CPU HIGH and as well as which queues need to be considered in this case?
Many thanks

Offline

 

#70 2017-Aug-15 09:11:10

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

Re: Experiment with TokenMAC

I need to change the above allocation period to be equal to the length of each STA’s transmission queue length. The purpose is to keep the medium occupied until all the packets in each STA queue is served. Can you point me where these changes can be done in CPU HIGH and as well as which queues need to be considered in this case?

This is certainly possible but not something we have ever implemented. At a high level you will need to change how the reservation time periods are implemented. You will need to monitor reservation status in the poll_tx_queues() context to trigger reservation changes ahead-of-schedule when the target queue is found to be empty.

Offline

 

#71 2017-Aug-25 06:30:26

warp_user
Member
Registered: 2014-Feb-27
Posts: 70

Re: Experiment with TokenMAC

I have done the following modifications to change the reservation period according to the queue size at each STA/AP.

They are as follows; definition of new IPC message in ‘wlan_mac_ipc_util.h’ as

Code:

#define IPC_MBOX_TOKEN_QUEUE_LENGTH		22

The following function pointer is defined and initialized in wlan_mac_high.c.

Code:

volatile function_ptr_t 	 token_queue_length_callback;
token_queue_length_callback = (function_ptr_t)nullCallback;

This is called in wlan_mac_high.c, in the function for the case of IPC_MBOX_TOKEN_NEW_RESERVATION and IPC_MBOX_TOKEN_QUEUE_LENGTH

Code:

void wlan_mac_high_process_ipc_msg( wlan_ipc_msg* msg ) {
...

	case IPC_MBOX_TOKEN_NEW_RESERVATION:
		            token_stats_start_callback( ((ipc_token_new_reservation*)msg->payload_ptr)->addr,
		                                        ((ipc_token_new_reservation*)msg->payload_ptr)->res_duration );
		            token_queue_length_callback();
	break;

	case IPC_MBOX_TOKEN_QUEUE_LENGTH:
		            token_queue_length_callback();
	break;
  ...
}

Callback function is defined in wlan_mac_high.c as follows;

Code:

void wlan_mac_high_set_token_queue_length_callback(function_ptr_t callback){
    token_queue_length_callback = callback;
}

Introduce a new function ‘set_queue_length()’ in wlan_mac_ap.c to calculate the queue length and update with reservation duration according to the queue length values.

Code:

void set_queue_length(){
...
curr_station_info = (station_info*)(next_station_info_entry->data); 

current_qsize = (queue_num_queued(AID_TO_QID(curr_station_info->AID)));
	if (current_qsize == 0)
			ipc_payload.res_duration = 0;
	else
			ipc_payload.res_duration = current_qsize*DEFAULT_RESERVATION_DURATION_USEC;

			ipc_mailbox_write_msg(&ipc_msg_to_low);
			curr_station_info_entry = next_station_info_entry;
...

}

Callback function defined in wlan_mac_high.c is called inside main() of wlan_mac_ap.c and inside poll_tx_queues() of wlan_mac_ap.c in capturing the set_queue_length();

Code:

wlan_mac_high_set_token_queue_length_callback((function_ptr_t) set_queue_length);

I am not clear about calling this inside CPU LOW, currently in wlan_mac_low.c inside the function void process_ipc_msg_from_high(wlan_ipc_msg* msg){
there isn’t a call for this. 

case IPC_MBOX_TOKEN_QUEUE_LENGTH:
            // do nothing

Can you describe if this needs to be called inside CPU LOW and if I have missed any important points as well in this case? In addition can you suggest a way of debug and test this implementation please.

Many thanks

Offline

 

#72 2017-Aug-29 10:34:58

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

Re: Experiment with TokenMAC

That looks like the right approach to handling the new IPC message in CPU High. Did you also implement the construction/sending of that message from CPU Low? And do you intend that message to be 1-way (i.e. only Low -> High)? If so there's no reason to implement a "case IPC_MBOX_TOKEN_QUEUE_LENGTH" in the IPC message handler in CPU Low.

Offline

 

#73 2017-Sep-06 10:20:40

warp_user
Member
Registered: 2014-Feb-27
Posts: 70

Re: Experiment with TokenMAC

I haven’t implemented the message construction from CPU Low. Can you point me on how to construct this message and where in CPU Low this has to be stated in order to initiate the new IPC message (IPC_MBOX_TOKEN_QUEUE_LENGTH) in CPU High please.

In addition I need some of clarifications of following please. 

(1) With respect to AID in the following function (this is in CPU HIGH) in determining the queue size what is the AID value for AP? Does it always take the value of 1?

Code:

//
queue size = (queue_num_queued(AID_TO_QID(curr_station_info->AID)));
//

(2) I assume the queue size in the above is returned as number of packets, then what is the value of packet size, is it 1528 bytes (1500 bytes payload + 24 bytes header + 4 bytes FCS)?

(3) When assigning the ‘RESERVATION_DURATION_USEC’ based on the queue length the calculation I have used is based on PHY rates, for example if the queue length is 10 packets then 10*1528 bytes need to be sent, for a 54Mbps rate  this will take around 2.3 ms.
Since the queue length is calculated in CPU HIGH is it correct to use PHY rates such as 18Mbps, 54Mbps etc..? As CPU HIGH is closer to MAC layer is it better to use 67% of the PHY rates, 36Mbps instead of 54Mbps?

In addition what is the safe value for the processing delay for each packet in token ring application? For example if the processing delay is 1ms (may be lower) for each packet then reservation duration for 10 packets will be 2.3 + 10 ~ 13ms. Also in relation to this what will be the default reservation value when queue length is zero, when there aren’t any packets to be transmitted in each AP or STA queue?

Many thanks in advance

Offline

 

#74 2017-Sep-06 11:34:58

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

Re: Experiment with TokenMAC

warp_user wrote:

I haven’t implemented the message construction from CPU Low. Can you point me on how to construct this message and where in CPU Low this has to be stated in order to initiate the new IPC message (IPC_MBOX_TOKEN_QUEUE_LENGTH) in CPU High please.

It's basically the same thing as the High->Low flow that the TokenMAC walked you through. Here is an example of a Low->High message being sent and here is where it is received and processed.

warp_user wrote:

(1) With respect to AID in the following function (this is in CPU HIGH) in determining the queue size what is the AID value for AP? Does it always take the value of 1?

Code:

//
queue size = (queue_num_queued(AID_TO_QID(curr_station_info->AID)));
//

The AP has no AID. Are you asking which QID is used at the STA node for frames that are addressed to the AP? Because the STA only ever has to send to a single unicast address (the AP), there isn't any need for any AID<->QID mapping. The STA uses a total of three queues. One is for multicast frames, one is for management frames, and one is for data unicast frames.

warp_user wrote:

(2) I assume the queue size in the above is returned as number of packets, then what is the value of packet size, is it 1528 bytes (1500 bytes payload + 24 bytes header + 4 bytes FCS)?

The PHY supports a maximum transmission of 2048 bytes. Since there is other metadata that must be dealt with in addition to the payload of every transmission, each queue entry is 4096 bytes.


warp_user wrote:

(3) When assigning the ‘RESERVATION_DURATION_USEC’ based on the queue length the calculation I have used is based on PHY rates, for example if the queue length is 10 packets then 10*1528 bytes need to be sent, for a 54Mbps rate  this will take around 2.3 ms.
Since the queue length is calculated in CPU HIGH is it correct to use PHY rates such as 18Mbps, 54Mbps etc..? As CPU HIGH is closer to MAC layer is it better to use 67% of the PHY rates, 36Mbps instead of 54Mbps?

The overhead during data transmission of TokenMAC is lower than the DCF since it is all contention free, but I'm not sure exactly what throughput you can expect. These are numbers you'd probably need to experiment with and tweak in your final implementation.

warp_user wrote:

In addition what is the safe value for the processing delay for each packet in token ring application? For example if the processing delay is 1ms (may be lower) for each packet then reservation duration for 10 packets will be 2.3 + 10 ~ 13ms. Also in relation to this what will be the default reservation value when queue length is zero, when there aren’t any packets to be transmitted in each AP or STA queue?

I'm not sure what the default reservation value should be. The extension you’re describing is not something we have characterized extensively. You’ll have to choose sensible defaults based on your own experiments with the extended design

Offline

 

#75 2017-Sep-07 10:39:10

warp_user
Member
Registered: 2014-Feb-27
Posts: 70

Re: Experiment with TokenMAC

Many thanks for the prompt response.

Regarding the query on queue length I need to calcuate the queue length at the AP, i.e. number of unicast packets AP got in its queue that needs to be delivered for each STA. There are only two types of queues defined in wlan_mac_ap.h (for multicast and mamangement frames) opposed to the three types defined for STA queues.

In addition I need to build a test and verification case based on the time stamp at each point from CPU LOW to CPU HIGH to understand the proceesing and other delays. Can you give some advise and starting point for this please?

Many thanks

Offline

 

Board footer