Transform Precoding (DFT-s-OFDM) in PUSCH

[danielschaeufele]

I'm currently doing some experiments with DFT-spread-OFDM in the PUSCH. There is a PUSCHConfig.transform_precoding parameter, which should control this, but it is never used, so my conclusion is, that this isn't implemented.

I'm interested in contributing and implementing this myself, but I'm not 100% sure how this feature should be best implemented. As far as I can see only the RessourceGridMapper has access to the information on which data symbol will be mapped onto which OFDM symbol. However, logically it seems to be a bit weird to me. Do you know a better place to implements this or should I add it to the RessourceGridMapper?

[jhoydis]

Hi,

DFT-spread-OFDM is indeed not implemented yet (and I have not looked into the standard for details). My understanding would be that this boils down to a small DFT on a few adjacent symbols in the frequency domain. If this is the case, this would happen prior to the mapping onto the resource grid. Do you agree?

[jhoydis]

Actually, I am not even sure if the precoding is done before or after mapping to the resource grid. Need to check the standard before continuing the discussion. The number of data symbols is the same for the OFDM symbols that do not carry DMRS.

[jhoydis]

After a quick look at TS 38.211 and TS 38.214, it seems that when transform precoding is enabled,

• there is only a single layer,
• DMRS and data are not multiplexed, i.e., numCDMGroupsWithoutData=2.

This means that the approach described above should work. You simply reshape the vector with data symbols to a matrix of size [number of allocated subcarriers, -1] and then apply the DFT from the left. That means that one could think about a PUSCHTransformPrecoder class that would get a list of punch_configs and that would sit between the LayerMapper and ResourceGridMapper.

Apart from this one would need to look at DMRS generation when transform precoding is enabled (it seems that low-PAPR sequences are used) and consider implementing PI/2-BPSK support for Mapper and Demapper.

[danielschaeufele]

Thank you for the advise. I will take a closer look at the standard and then implement it like you proposed.

[danielschaeufele]

The implementation for the transmitter seems to be pretty straight-forward so far. However, implementing the receiver seems to be much harder.

If I understand DFT-s-OFDM correctly, decoding works in the following way:

1. FFT computation to go from time domain to frequency domain
2. equalization in the frequency domain
3. IDFT computation
4. demapping and all the other steps from normal CP-OFDM

I think it is impossible to build a generic implementation that works for all detectors implemented by Sionna, so my proposal is to implement this only for the linear detector. To do that, I would either add a parameter to LinearDetector or create a new class LinearTransformPrecodingDetector. The first option has the disadvantage, that the generic MIMO detector has a dependency on a 5G NR PUSCH function, which seems to be really bad encapsulation. The second option has a bit of code duplication, as only a few lines would need to be added to LinearDetector. I'm unsure, which way is best or if there are even better methods, that I didn't think of.

[jhoydis]

Hm, if I understand it correctly, the only difference between a detector for OFDM and DFT-s-OFDM is that we have the FFT step prior to demapping for the latter. I think that there is no need to have an implementation for all detectors because DFT-s-OFDM is mainly used for single-stream transmissions.

I like your suggestion to create a LinearTransformPrecodingDetector class. However, I think that all linear detectors would perform equally for a single stream. The question is if there is any value in supporting MIMO detection for DFT-s-OFDM?

The PUSCH receiver would then need to select this new TransformPrecodingDetector if transform precoding is selected.

[danielschaeufele]

I finally managed to find time to continue with the implementation, sorry for the long delay.

I pushed my implementation here in case you already want to have a look: https://github.com/danielschaeufele/sionna/tree/transform_precoding

Currently I'm still missing documentation and tests. After I added those I will prepare a pull request.

I opted against implementing Pi/2-BPSK, because this is optional in the standard and it would need significant modification to the Mapper and Demapper.

[danielschaeufele]

Regarding the tests for the PUSCHTransmitter: I would like to add a new test case. Are there any instructions on how to do that and on how the test data is generated?

[SebastianCa]

There are no detailed instructions available for generating test cases, but they should cover all relevant scenarios (ideally some corner cases). Please ensure that the test cases are not too computationally demanding (e.g., they should run in a few seconds) to avoid excessive runtime for all unit tests.

For data generation, you can either test against a small dataset of pre-calculated cases or use a NumPy reference implementation.

[danielschaeufele]

For tests that only test a single module, I will do that (e.g. the tests for the Zadoff-Chu sequences are tested against the matlab implementation). However, I think it also makes sense to test the whole PUSCHTransmitter chain. As far as I can see, the tests in test/unit/nr/test_pusch_transmitter.py use predefined test files. The JSON files seem to be generated by test/unit/nr/pusch_test_configs/gen_test_configs.py, but there is no reference as to how the npy files have been generated. Additionally, adding a new loop for transform_precoding turned on/off is not going to work, because the parameters that can be used when transform_precoding is enabled are severely restricted (e.g. only a single layer is supported). So maybe it would make sense to add just very specific tests manually. Is this supported or will it break automatic generation in the future?

[SebastianCa]

It should be fine to add an additional "manual" test case for the supported set of parameters. However, please ensure that make test runs these cases automatically (which should be the case according to how I understand your question).

Btw: please ensure that non-supported configurations are detected during the initialization.