You are not logged in.
Hi,
My objective is to implement an extended version of PCF wherein
1. AP and STAs are connected both by wired connection and associated over RF.
2. Only contention-free access takes place i.e. no DCF
3. CF-POLL are transmitted from the AP to the STAs over wired connection
4. If STA is backlogged, the CF-poll reply (including data) is transmitted over RF. AP ACKs the CF-Poll over RF.
5. If STA is not backlogged, it doesn't transmit any frame. Consequently, after wait time of one slot time, AP transmits next CF-Poll over wired.
6. AP can remain in RX mode over RF throughout except to send an ACK for a received poll
7. STA can be in TX mode over RF throughout except to receive an ACK corresponding to their CF-Poll reply.
8. AP is in TX-mode exclusively over wired and STA is in RX mode exclusively over wired. Imagine this as a uni-directional channel from AP with the objective of transmitting CF-Poll.
Clearly, standard compliance is not a constraint in the above implementation objective. It would be great if you can provide your thoughts on the feasibility of implementing the above and how to go about it.
Thanks,
Sharan
Offline
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).
Offline
Thanks murphpo! By "wired", I was thinking more in the lines of Ethernet but I want to understand a bit more about the capabilities. Let's consider the "wired TX after 1 slot (9 microseconds)" isn't a mandatory requirement. For the following scenario:
There is a single AP and two clients A and B. AP is conducting a contention-free period via round-robin polling of clients.
time 0: AP transmits poll request to client A over wired
time X_1: AP doesn't detect any reply from client A using 802.11 preamble-based detection.
time X_2: AP transmits poll request to client B
Q1. Is X_1 around 4-5 microseconds (as in 802.11) in WARP implementation of preamble-based detection?
Q2. What is the expected value of X_2 using Ethernet cables and separately using debug headers?
Thanks,
Sharan
Offline
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.
Offline
Thanks a lot @chunter for the detailed info and advice!
chunter wrote:
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 it's from who you think it is?
Actually, it is the other way around. If the AP detects any preamble, it will not send any CF-POLL to next client until the response is detected and made sure is not from an interfering station. In contrast, if AP doesn't detect any packet through preamble-based detection, then it immediately proceeds to transmit CF-POLL for next client in schedule.
I will try both Ethernet and debug header approaches. I plan to use the WARPnet experimental framework. Thanks!
Last edited by sharanmanu91 (2017-Aug-09 08:24:44)
Offline
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)
Offline
Q1. Is Trigger Processor module implemented for WARPNet?
You'll have to clarify what you mean by WARPNet. "WARPnet" was the experiments framework for the old OFDM Reference Design. This code hasn't been touched in a long time. Do you mean wlan_exp, the Python framework for experiments with the 802.11 Ref Design?
Either way the Trigger Processor is part of the WARPLab Reference Design. There is no overlap between the 802.11 Ref Design and WARPLab Ref Design. You could certainly borrow parts of the WARPLab hardware design (like the warplab_trigger_proc core) to create a custom 802.11 Ref Design hardware project with trigger I/O.
Offline
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!
Offline
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?
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.
Offline
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!
Offline