sync words format in ofdm carrier allocator block

[ghost]

Hi Bastian,

The sync words given in ofdm carrier allocator block have STF and LTF fields.

As per 802.11a standard, STF should have 2 symbols width i.e. a sequence of 160 samples. But i have noticed that STF(which is normalised) has 128 samples. Does this comply with standard or any other manipulation is done in carrier allocator block to make it as 2 symbols width.

First LTF symbol has rotation (as you have explained in another thread). Can you help understanding this. Is this done as per standard? Standard just specifies to add a Guard interval from the last half of LTS and does not mention anything of rotation. Kindly help.

Thanks

[bastibl]

The explanation for both is that the output of the carrier allocator is processed by the cyclic prefix block. For the short preamble (and all data symbols) there is no issue. It just copies 1/4 of the samples (16 per symbol) to the front. For the STS, this is 128 in, 160 out. The LTF has a unique format (1/2 LTF, LTF, LTF) that he cyclic prefix block would mess up. The rotation is there to compensate for that.

[ghost]

Thanks for the explanation.

Can you throw some light on how this compensation comes about. Do I need to go through the cyclic prefix block to know this. I wanted to know how actually you decoded this rotation since I need to work with another LTF field with same format (1/2 LTF, LTF, LTF). Does this rotation remain same for say an LTF with a length of 128 samples instead of 64.

Thanks

[bastibl]

It's created with this script: https://github.com/bastibl/gr-ieee802-11/blob/next/utils/sync_words.py

What the cyclic prefix block does is trivial. It copies 16 samples from the end to the front. If you would send the LTF through that, you'd have 1/4 LTF, LTF, 1/4 LTF, LTF. You have to rearrange your LTF so that it has the desired format when passing through the cyclic prefix. You have to think about how to do that for your case. What I needed here was a shift in time domain, which corresponds to a rotation in frequency domain (see the script).

[ghost]

Thanks for your kind explanation.

Does this change in LTF require any modification at receiver(as in for auto correlation of LTF). Can you guide as to where this change at transmitter affects in receiver(an overview if complete explanation is not possible).

Thanks

[bastibl]

If you want to use another preamble, you have to adapt the Sync Long block in the receiver. Otherwise it doesn't know what to look for. It cross-correlates the beginning of the signal with the know sequence to align to the OFDM symbols.

[ghost]

Hi Bastian,

Need a small clarification. What does MIN_GAP(set to 480) and MAX_SAMPLES(set to 540*80) in sync_short block signify and how their values should be determined.

Thanks

[bastibl]

MIN_GAP is the minimum number of samples between two frames. MAX_SAMPLES are the maximum number of samples of a frame. This number of samples will be piped into the flow graph once a frame is detected. The downstream blocks will consume as many as needed for the frame and drop the rest.

[ghost]

Thanks,

I have a confusion as to form which index samples are copied. We are delaying 16 samples and carrying out autocorrelation and since MIN_PLATEAU is set to 2 we are waiting for threshold to cross atleast twice(please correct if wrong) and then copying the samples..that implies already an offset of 32 samples in STF. Does the copying start from here? How this index is propagated in sync block while the control goes to 'COPY' case( I am confused since out(o) = in(o) and 0 is set to 0) .

Thanks

[bastibl]

I don't get the question. But in general frame detection works like this: At the beginning of the frame the autocorrelation rises and stays high during the short preamble. It is a plateau where many samples are above threshold. Once two consecutive samples are above the threshold, it's considered a frame start and MAX_SAMPLES are forwarded into the flow graph.

Looks like Figure 3 in here: https://www.bastibl.net/bib/bloessl2018performance/

[ghost]

My doubt is since we are delaying the symbol and performing autocorrelation, thus the autocorrelation starts to increase only after the specified delay and hence does this give rise to an offset in the extracted frame(like some samples in STF get missed which are at the beginning)

[bastibl]

I don't see why a delay should be a problem. Delayed with regard to what? Since it uses an autocorrelation with a lag of 16 sample, it is impossible to detect the frame at the first IQ sample. It's enough to be detected somewhen during the short preamble. Precise alignment happens later with the help of the long preamble. I guess it's a misunderstanding about how synchronization works.

[ghost]

Ok Thanks,

I was referring to that lag of 16 samples and assumed that after detection frame should be passed from the start of STF. That seems clear!

[ghost]

Hi ,

The LONG symbol used for cross correlation seems to be different compared to that defined in the standard. After going through previous issues, seems there is some manipulation with scaling factor(calculate in a script in utils folder). Can you throw some light as to why this scaling is required and how you deduce the scaling factor to the one described in script. Are there any corresponding scaling changes in ifft block at transmitter that result in including this scaling factor. Is this specified in standard(as to how this scaling changes are to be done.)?

Thanks.

[bastibl]

The standard defines the long preamble in frequency domain. Cross-correlation is done in time domain. Scaling doesn't matter.

[ghost]

Then direct ifft of standard defined frequency samples can be used for cross correlation right..why the sync long block has long preamble with a scaling factor?

If I were to change LTF, do I need to go through the same procedure?

[bastibl]

Again, scaling doesn't matter in the receiver. You are only interested where the correlation is high not how high it is. And yes, if you want to calculate the autocorrelation, you'd have to convert to time domain too.

Scaling matters only at the transmitter, since all symbols should have the same average power. I normalized it, so that the average power is 1.

[ghost]

Hi,

Can you specify why CRC is always validated againstc a constant value in decode_mac block? Is this defined by standard?

[bastibl]

Was easier to implement (and I think it is faster). You can just as well process psdu_size-4 bytes and compare them to the last 4 bytes.

[ghost]

Fine... How is that constant value determined? (General CRC implementation would result in remainder of all zeroes when divided with polynomial after checksum is appended).

[bastibl]

IEEE 802.11 does not use the remainder but the inverse. Please see the standard. It suggests to use a similar approach, resulting in a constant remainder. (Albeit they preset the initial remainder to all 1s, resulting in a different constant value.)

[ghost]

Thanks!! Is there any way you could suggest to verify the flow of data from one block to another in gnuradio, when we make some maodifications? (Like a sink or any method to monitor the packet flow )

[bastibl]

Either GUI sinks, debug output in the block, or (as you suggested) a file sink and use some scripts to verify the data.

[ghost]

Hi, Can you cite any refernces as to how phase offset correction using pilot carriers is done in frame equaliser block?. Could not get how it is done.. If possible can you kindly explain as to how it is done?

[bastibl]

How phase offset is compensated depends on the equalizer. The simplest one is the LS equalizer (just Google for it), which uses the initial estimated of the channel (calculated with the long preamble).

[ghost]

Hi, The windowing paramter in iift at transmitter is set to 1/sqrt(52) as shown. Does this has anything to do with normalising the power?. Can you explain why is it required and if would the transmitter operation has to do anything to with this windowing?

Thanks in advance

[bastibl]

Yes, it normalizes the average signal power to 1. This simplifies, for example, adjusting SNR power levels in simulations. With real hardware it is only important to use the "Multiply Const" block (which is placed after the PHY output) to make sure the signal is (mostly) within [-1; 1].

[ghost]

Thanks,

How would we be able to configure the constant value in the "Multiply Const" block?

[bastibl]

It is already adjusted in all flow graphs that use hardware. I'd recommend to just leave it like that. If you really want to adjust the amplitude somewhere in the flow graph, use a time sink after the multiply const block, visualize the maximum, and adjust the value accordingly (such that I and Q are in [-1; 1]).

[ghost]

Hi, Have a small query regarding auto correlation for frame detection. We normalize the auto correlated stf values to 1. But the moving average window values differ as shown in figure below One is summed over 48 and the other over 64. Isn't that these windows are to be identical for normalisation. Please correct if I am wrong.

Thanks

[bastibl]

You are right, the autocorrelation is not normlized to one.

This is done on purpose to avoid high variance of the autocorrelation during frame start (or frame end depending on which 48-sample power window would have been chosen). The autocorrelation considers samples from 48+16 (the lag value). When the samples in the [49,64] window have much higher power, I noticed that autocorrelation might be triggered on noise. To avoid a more complicated implementation, I just average over 64 samples and adapt the sensitivity value in Sync Short accordingly.

[ghost]

Thanks a lot for explanation

[ghost]

Does LO Offset setting help in case we are experiencing a frequency offset? We had some changes to existing module but due to some issue need to disable the frequency offset compensation in frame equaliser block. We are losing some packets and then when we set some LO offset there was minimal loss. So Does LO offset help in freq synchronisation? Also is there any reference for residual and sampling offset correction(how d_epsilon , beta , d_er ,etc are decided to be the one in module)? Could you please help in this regard.

Thanks.

[bastibl]

I'm not sure what you mean. LO offset correction is not implemented for fun but to compensate the LO offset. When you disable or remove it, it will degrade performance. The LO offset correction is a shift in frequency domain, such that the subcarriers are centered around the center frequency. I guess that's what you mean with frequency synchronization. See this paper for further information on the algorithm: https://ieeexplore.ieee.org/document/1405033

[ghost]

Thanks for the reference.

I mean whether the variable "LO offset" set in flowgraph which is given to uhd_tune_request would help in correcting this offset which is corrected as a part of frame euqualiser, sync shot and sink short blocks..Kindly give your inputs with this regard

[bastibl]

This is completely unrelated. This parameter is for LO Offset tuning to move the DC spike out the band of interest. Please see the UHD manual: https://files.ettus.com/manual/page_general.html#general_tuning_dsp

[ghost]

Hi Bastian,

Thanks for the reference on sampling and residual frequency offset correction.

I have doubt regarding beta calculation for LTF. It is as shown in figure below, since for LTF pilots are not added.

Can you please explain how you got to the method above.

Thanks

[bastibl]

What exactly are your doubts? LTF sends data on these subcarriers (even though its different from the pilots, therefore the special case) and they are used for compensation.

[ghost]

Like why exactly it is just not the sum for calculating the argument but arg(sample-11 - sample-25 + sample-38 + sample-53).. is there particular reason for this kind of calculation?

[bastibl]

This would be another estimator. There is no right or wrong. The one that is currently used weighs the contributions from subcarriers with higher amplitude (and therefore maybe better SNR) higher.

[ghost]

Can you cite any reference for this estimator or any way which one could decide on this way of estimation

[bastibl]

E. Sourour, H. El-Ghoroury, and D. McNeill, “Frequency Offset Estimation and Correction in the IEEE 802.11a WLAN,” in 60th IEEE Vehicular Technology Conference (VTC2004-Fall), Los Angeles, CA: IEEE, Sep. 2004, pp. 4923–

4927. DOI: 10.1109/VETECF.2004.1405033.

They use the same strategy for estimating the frequency offset, which is a similar problem.

[ghost]

Thanks for all the help

[ghost]

This would be another estimator. There is no right or wrong. The one that is currently used weighs the contributions from subcarriers with higher amplitude (and therefore maybe better SNR) higher.

I am sorry to trouble you..but what i was asking for was how the beta calculated for LTF symbols which does not have pilot symbols in frame equaliser block after sync long..i see the reference given does not specify this. Attaching the part of the code which i was referring to.

[bastibl]

Again,

LTF sends data on these subcarriers (even though its different from the pilots, therefore the special case) and they are used for compensation.

The LTF is a whole pilot symbol. A pilot is a known constellation on a subcarrier. On the LTF all subcarrier constellations are known. And they are used for compensation. What exactly is the problem here?

[ghost]

Like why exactly only the specified sub carriers are used for compensation and how to determine these are the subcarrier positions to be used out of 64 available subcarriers.

[bastibl]

You can also use more subcarriers or implement it however you think fits. Currently, it just does the same thing for all symbols, i.e., compensation is done on the LTF just like any other data symbol with comb pilots. Feel free to change it to your needs. This are not the one and only true subcarriers. It's just implemented similar to data symbols.

[ghost]

Thanks

[ghost]

Hi, For performance analysis of the Transmitter , you have reproduced the following results shown in picture (specified in your report)

Can you please let me know how SNR is set and Frame deliver ratio is captured.

We have snr calculation in Receiver flow graph, can it be used for calculating SNR ( say if we are transmitting between two USRP's and evaluating performance)

Thanks

[bastibl]

The frame delivery ratio can be computed since you know how many frames you sent and how many you received... Both experiments used normal WLAN cards as receiver. Some of them annotated metadata (like SNR) in the radiotap header when put in monitor mode.

[ghost]

How could this be done if there is no commercial card but when we are transmitting between two USRPs

Can the SNR value calculated in equalisation be used..?