Hi all,
This merge request to resolve issue #401 (closed)
Bug summary
Location: Function nr_generate_pucch2 in openair1/PHY/NR_UE_TRANSPORT/pucch_nr.c.
Return wrong length of m-sequence
-
In sec 6.4.1.3.2, 38.211, for each OFDM symbol, the DMRS for PUCCH format 2 is generated from an m-sequence, with the length of : 2_PRBs_12/3 = number of PRBs_4_2 (in which, 2 is to include real and image part of a complex number, 4 is the number of DMRS symbols in 1 PRB).
-
In the function nr_generate_pucch2, m-sequence is generated by calling function lte_gold_generic(), which returns an uint32_t variable. The returned sequence just corresponds to 16 symbols for DMRS, and covers 4 PRBs per OFDM symbols.
-
So, if the number of PRBs for PUCCH format 2 is more than 4 (the number of PUCCH symbols per OFDM symbol >16), the length of the generated m-sequence is not enough. This leads to incorrect generated DMRS. Reset m-sequence after each symbol
-
In addition, as I understand, the variable named m (local variable of nr_generate_pucch2) is used as DMRS symbol index in an OFDM symbol. Therefore, it must be reset after each OFDM symbol.
Resolve
While fixing the bugs related to pucch format 2 generator, I have found that the function lte_gold_generic() is also used inaccurately in other places.
For example: nr_group_sequence_hopping, nr_cyclic_shift_hopping, and nr_pucch2_3_4_scrambling. The problem is lte_gold_generic() returns a sequence of 32-bit length, however to get the correct results, we may need a longer sequence. I fixed the code and verified it with Keysight Vector Signal Analyzer. Now, the generated signal for pucch format 0,1, and DMRS of format 2 can be detected by Keysight Vector Signal Analyzer.
Currently, the bug in function nr_pucch2_3_4_scrambling has not been fixed yet (because the encoding for pucch format >2 has not been integrated, caused difficult for me to testing).
Please check my merge request and tell me if you have any doubt.
Regards, Son