Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
openairinterface5G
openairinterface5G
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Merge Requests 16
    • Merge Requests 16
  • Analytics
    • Analytics
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Commits
  • oai
  • openairinterface5Gopenairinterface5G
  • Merge Requests
  • !510

Merged
Opened Feb 15, 2019 by HOAI SON DANG@danghoaisonDeveloper
  • Report abuse
Report abuse

issue401-nr-pucch-dmrs-format_2

  • Overview 24
  • Commits 7
  • Changes 7

Hi all,

This merge request to resolve issue #401

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

Edited Feb 20, 2019 by Florian Kaltenberger
Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
1
Labels
bugfix
Assign labels
  • View project labels
Reference: oai/openairinterface5g!510
Source branch: nr_fix_pucch_dmrs

Revert this merge request

This will create a new commit in order to revert the existing changes.

Switch branch
Cancel
A new branch will be created in your fork and a new merge request will be started.

Cherry-pick this merge request

Switch branch
Cancel
A new branch will be created in your fork and a new merge request will be started.