1. 15 Apr, 2019 9 commits
  2. 13 Apr, 2019 1 commit
  3. 12 Apr, 2019 3 commits
  4. 11 Apr, 2019 4 commits
  5. 10 Apr, 2019 1 commit
  6. 09 Apr, 2019 3 commits
  7. 08 Apr, 2019 2 commits
  8. 05 Apr, 2019 2 commits
  9. 04 Apr, 2019 4 commits
  10. 03 Apr, 2019 4 commits
  11. 02 Apr, 2019 2 commits
  12. 01 Apr, 2019 2 commits
  13. 30 Mar, 2019 3 commits
    • Cedric Roux's avatar
      bugfixes for UL scheduling · a5a16903
      Cedric Roux authored
      - size of PUCCH has been fixed to:
          - 2 RBs for N_RB_UL = 25 (1 RB at top of resource grid, 1 RB at bottom)
          - 4 RBs for N_RB_UL = 50
          - 6 RBs for N_RB_UL = 100
        this is arbitrary and will need some rework at some point.
        This may be also wrong. PUCCH size actually depends on DL traffic
        (if the ack/nack is not done in PUSCH) and scheduling request
        configurations.
      - add sched_frame %= 1024 at one needed place
      - reserve RBs for retransmission
        this was not done so new transmissions were scheduled in the same
        RBs. Since the code works with the notion of 'first_rb' only, it
        was decided to skip all RBs lower than those retransmitted. This
        works but is not correct (imagine we have to retransmit RB 23, then
        all RBs < 23 will not be used for new transmission). The work to
        fix this properly is complex, a lot has to change, so let's do it
        this simple way for now.
      - sort_ue_ul was not correct
        - add the function maxround_ul to use the correct 'round' (the one
          from DL was used, which is totally wrong)
        - be sure to use the correct frame/subframe to get the correct HARQ pid
      a5a16903
    • Cedric Roux's avatar
      bugfix: access correctly round_UL · 0e38852b
      Cedric Roux authored
      0e38852b
    • Cedric Roux's avatar
      bugfix: fix cqi_req usage in UL scheduler · 26118ed8
      Cedric Roux authored
      For retransmission, let's use cqi_req used for the 1st transmission.
      
      Maybe incorrect, should check the specs. (In the worst case, we
      simply won't decode this transmission at all. No big deal.)
      26118ed8