WARP Project Forums - Wireless Open-Access Research Platform

I'm a bit confused about the overall setup. Specifically what does "over wired connection" mean here? Ethernet, debug header, cabled RF? The protocol describes the wired connection operating on MAC timescales (i.e. wired Tx after 1 slot). This implies building the wired link in hardware. This is doable with the debug header; it's much harder with Ethernet (the Ethernet MAC cores assume interaction via C code drivers, and our design connects both Ethernet interfaces to CPU High).

sharanmanu91 wrote:

Q1. Is X_1 around 4-5 microseconds (as in 802.11) in WARP implementation of preamble-based detection?

So you aren't going to decode the frame and use any of the payload bytes? You want to only operate on packet detection even if that detection is from an interfering station that isn't your STA? Wouldn't it be safer from a protocol perspective to decode the response and make sure its from who you think it is?

If not, it's still a little of a subtle question. C-code in the CPU_LOW doesn't get involved until the PHY autocorrelates for the STF symbols in the preamble and then crosscorrelates for the LTF symbols and then sees and decodes and valid SIGNAL. This time is the delay from the first sample arriving and the rise of the "RX START" event. It's about 25usec in our design. It's how long it takes from the first sample over the air until this line is executed. Note it takes even longer to get to "frame_receive()" in the DCF because the framework has to wait for a valid HT-SIG in case it's an 802.11n packet.

If you don't need any payload bytes anyway, you could conceivably remove the above restrictions by modifying the PHY to assert a register for code to read immediately after the autocorrelation. That would get you close to the 4 usec number stated in your question.

sharanmanu91 wrote:

Q2. What is the expected value of X_2 using Ethernet cables and separately using debug headers?

For Ethernet, the answer would depend on the implementation. As murphpo mentioned, the ideal way to build it would to perform the Ethernet Tx and Rx processing directly in the fabric of the FPGA. For the WARPLab design, we needed to get software out of the loop when processing Ethernet triggers so we build a Ethernet Rx "sniffer" directly in the FPGA (see the Trigger Processor). But that was only Rx; you'd need to build a Tx that periodically sends a new frame to a different STA and can be stopped by software when the OFDM reception occurs. This is pretty difficult to do. If possible, you'd probably want to stick to software generation of Ethernet Tx frames. I'm not sure how low X_2 can be here. I'd recommend designing an experiment to find out. With some custom C code, you could rig up an experiment where one WARP node periodically generates an Ethernet Tx and another WARP node receives the frames and logs the system time when they are received. You could use the 802.11 Reference Design's wlan_exp logs for this. By analyzing the jitter between Rx events, you can have a feeling for what you can get away with for X_2. For example, in if the jitter between the supposedly-periodic transmissions is on the order of 10 usec, you know that you can't get away with slot accuracy.

For the debug header, you can run a similar experiment. You can have software control of the debug header. Just like the previous experiment, you can periodically assert an output on one node and poll/log an input on another and then analyzer the jitter after the fact.

chunter wrote:

For the WARPLab design, we needed to get software out of the loop when processing Ethernet triggers so we build a Ethernet Rx "sniffer" directly in the FPGA (see the Trigger Processor).

Q1. Is Trigger Processor module implemented for WARPNet?

chunter wrote:

For the debug header, you can run a similar experiment. You can have software control of the debug header. Just like the previous experiment, you can periodically assert an output on one node and poll/log an input on another and then analyzer the jitter after the fact.

Q2. Potentially, I would have multiple STAs taking part in CFP. It is mentioned in the Trigger Processor documentation that TRIGGER is only supported for broadcast transports. This TRIGGER would serve as a CF-POLL to a specific STA in my scenario and not broadcast. In that case, would it be better to work with debug headers? Is is possible to connect AP to multiple STAs this way?

Q3. Simplest way to assert a register after the autocorrelation? Unfortunately, I haven't performed such action previously.

Q4. Would it be feasible for AP to simultaneously receive over Wi-Fi from a STA and transmit over wire to another STA?

My experiment plan is as follows:
1. TokenMAC working for AP with 1 STA and AP with 2 STAs.
2. Jitter experiments for Ethernet packet transmission with Ethernet and debug headers
3. PHY register test for autocorrelation output.
4. TokenMAC with early token transmission wirelessly if PHY autocorrelation register indicates no autocorrelation.
5. TokenMAC with wired token transmission and wireless reception

Thanks,
Sharan

Last edited by sharanmanu91 (2017-Aug-09 10:05:38)

murphpo wrote:

Do you mean wlan_exp, the Python framework for experiments with the 802.11 Ref Design?

Oops yes I meant the Python framework wlan_exp for 802.11 reference design experiments.

Thanks for the feedback!

murphpo wrote:

Can you help us understand what the overall goal is with your experiment? I'm struggling to understand how you might mix communication via Ethernet with MAC behaviors. At first glance this is contradictory. If the nodes have a 1Gbps Ethernet connection they should use that to communicate (faster and more reliable than the wireless link). Is the Ethernet connection a proxy for something else in your protocol, like base stations with connections to a shared backbone, or some low-rate control connection among nodes? Why not transmit the CF-Poll packet wirelessly over the same interface you expect the CF-Poll response?

I'm sorry for the confusion! You are right, the wired link is used to mimic a uni-directional out-of-band non-RF control channel (not necessarily fast) for transmitting the CF-Poll. This is based on the hypothesis that the overhead in polling each client over RF might be inefficient when only a small subset of the clients have backlogged data.

I don't need to send actual data over the "wired" interface. Pulse signal over a single wire between AP and STA that indicates RF channel access to the client should suffice.

murphpo wrote:

In any case, I would suggest investigating the debug header before attempting to modify the Ethernet cores/code. Ethernet Tx and Rx from CPU Low is feasible but would require significant modifications to the ref design code and hardware architecture. The debug header, on the other hand, is directly accessible by both CPUs by default (see user guide for details). You can configure individual pins as inputs or outputs and poll the state of individual pins from either CPU. For example it would be straightforward to poll the state of an individual debug pin in the main() loop in CPU Low; this would provide the lowest-latency way to trigger MAC behaviors via the debug header. Whatever pins you use, be sure to connect the ground pins across any boards with connected debug pins.

Thanks a lot for your help, I will focus on the debug header implementation!