WARP Project Forums - Wireless Open-Access Research Platform

You are not logged in.

#1 2015-Dec-31 22:57:48

linron
Member
Registered: 2015-Dec-01
Posts: 9

How to transmit a frame at a specified time?

Hi,

How can I transmit a frame at time specified by me in 802.11 reference design? In my application, one node (say A) receives a beacon from another node (say B), and node A can record the time (say rcv_time) when it receives the beacon. Then node A wants to transmit a data frame at time rcv_time+delta, where delta is the time offset I want to specify. How can I do it? I know I can get rcv_time by accessing timestamp in rx_frame_info, but I do not know how to specify the delta in the transmitting frame. Can someone answer me?

Offline

 

#2 2016-Jan-01 09:00:56

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

Re: How to transmit a frame at a specified time?

There are a couple of different ways that behavior can be achieved:

1. In CPU_HIGH, you can use the scheduler to call a function you write at the rcv_time+delta time. You can set up the scheduled event from the context of processing a received beacon. In that context, you can calculate rcv_time+delta because you know what the RX START timestamp is of the beacon itself. The function you write would then enqueue your transmission. This is the easiest / most straightforward solution, but the downside is that the transmission time won't occur exactly at rcv_time+delta. You'd only be enqueuing your transmission at that time. The DCF in CPU_LOW might currently be working on another transmission at the time you enqueue it. Or the medium might be busy and the transmission will be deferred. rcv_time+delta is a pretty loose approximation of the transmission time if you go this route.

2. Alternatively, you'll have to modify CPU_LOW if you want to transmit exactly at the rcv_time+delta time. The notion of a scheduled transmission at exactly a particular time isn't really compatible with the random-access DCF. So, it may make sense to start with NOMAC as the base for your modifications.

Offline

 

#3 2016-Jan-09 07:12:48

linron
Member
Registered: 2015-Dec-01
Posts: 9

Re: How to transmit a frame at a specified time?

Thanks. I adopted the second method and modified the NOMAC. However, I find that it is still hard to realize it. At first, I get the rcv_time and specify the delta in CPU_High. Then in MAC_LOW( NOMAC), I obatin current_time by using get_usec_timestamp(). If current_time equals to rcv_time+delta,then let the MAC_LOW transmit a frame, else wait until current_time reach the specified time. But the function get_usec_timestamp() consumes a very long time (about 2ms) each time when I determine if the current_time meets the requirement. Therefore, under this condition, frames usually cannot be sent. In my application, I hope the time spent on obtaining current_time is less than several us, so that I can control the transmit time precisely. How to do it?

Last edited by linron (2016-Jan-09 07:13:36)

Offline

 

#4 2016-Jan-09 16:16:54

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

Re: How to transmit a frame at a specified time?

What version of the reference design are you using?

the function get_usec_timestamp() consumes a very long time (about 2ms)

That should not be right.  The reference design uses the current time all over the place.  In the latest reference design, the get_mac_time_usec() function (i.e. the replacement for get_sec_timestamp()) is just a couple of peripheral register accesses and takes less than a microsecond to run.

Offline

 

#5 2016-Jan-10 03:31:08

linron
Member
Registered: 2015-Dec-01
Posts: 9

Re: How to transmit a frame at a specified time?

I am using Mango_802.11_RefDes_v1.3.0. In the NOMAC, I call the function  get_usec_timestamp()  two times without interval, and each time I use the xil_printf()to display the current_time. According to my observation, the function (access the time) seems consume a long time because the difference between two timestamps is about 2000. The following is my code:

...
xil_printf("ts1=%d", get_usec_timestamp());
xil_printf("ts2=%d", get_usec_timestamp());
...

In addition, in the version of 802.11 v1.3.0, there is no function called get_mac_time_usec(). It may be in v1.4.0. Can I still obtain a timestamp very quickly in the version of v1.3.0? If not, I have to switch to v1.4.0.

Moreover, in the latest version, what is the difference between MAC Time and System time? For example, when a node receives a frame from another one, there is a timestamp in rx_frame_info. Is this timestamp from System time or MAC time?

Last edited by linron (2016-Jan-10 03:59:30)

Offline

 

#6 2016-Jan-10 08:57:47

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

Re: How to transmit a frame at a specified time?

It's the xil_printf() that is taking that much time, not the get_usec_timestamp(). Printing to UART is slow and is not a safe action in any timing critical functions. In both 1.3 and 1.4 the current time can bet read very quickly (two u32 word reads).

In 1.4, we created the system time to be a usec count that is never reset or modified. It starts counting when the FPGA is configured and just keeps going. MAC time, which is all there was in 1.3 and prior releases, can be modified. For example, a STA updates it MAC time whenever it receives a beacon from an AP. The timestamp in rx_frame_info is the MAC time -- this allows the timestamps of Tx and Rx events at separate nodes to be compared since the MAC times are kept in sync by the 802.11 TSF.

Offline

 

#7 2016-Jan-11 04:52:55

linron
Member
Registered: 2015-Dec-01
Posts: 9

Re: How to transmit a frame at a specified time?

You are right. The  xil_printf() takes too much time.

Furthermore, if I want to control the transmit time more accurately (the minimum unit for time is less than 1us, say 500ns), how to do it in version 1.3.0? Actually, in my application, sometimes  it needs to send a frame at time ts+x, where ts is the timestamp and x is 0.5us. By modifying the NOMAC, I can transmit a frame at a time ts that is specified by timestamp, but I do not know how to transmit it at ts+0.5us. do you know how to do that?

Last edited by linron (2016-Jan-11 07:51:33)

Offline

 

#8 2016-Jan-11 09:34:04

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

Re: How to transmit a frame at a specified time?

Quantizing the time to the nearest microsecond is somewhat arbitrary.  The standard 802.11 functions do not need finer resolution.  If you look at the version 1.4 FPGA Architecture, we have moved time keeping into the wlan_mac_time_hw pcore.  This is where the 160 MHz system clock is quantized into the microsecond counter.  It is possible to add registers to that pcore that have a finer time resolution (I would leave the current registers in place so that you don't affect the existing implementation that relies on microsecond timing).  Also, depending on your time scales, you could make this register only 32-bits which would decrease the number of register accesses needed to get the time.  We needed to use 64 bits for the time because we needed a maximum time greater than ~4300 sec (i.e. 2^32 / 1e6).

Even if you get a finer time resolution, it is going to be difficult to respond in 0.5us.  CPU Low runs at 160 MHz (i.e. it has a clock period of 6.25ns).  This means that there are only 80 CPU Low clock cycles in 500 ns which is not many cycles to execute instructions.  If you find that you cannot meet the timing you need, then you will have to explore creating a custom hardware core that meets your requirements.

Offline

 

#9 2016-Jan-11 09:52:59

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

Re: How to transmit a frame at a specified time?

Can you clarify what Rx-to-Tx timing you're looking to build? For example, are you trying to transmit a packet precisely X usec after receiving a packet, for small X?

If so, the better solution would be to use the MAC core (wlan_mac_hw) Tx controllers to sequence the Rx/delay/Tx operations. This is the same logic we use to built RTS/CTS and DATA/ACK (i.e. receive packet, send response exactly 1 SIFS interval later).

Offline

 

Board footer