An error occurred fetching the project authors.
  1. 03 Oct, 2019 1 commit
  2. 01 Jul, 2019 1 commit
  3. 11 Apr, 2019 1 commit
  4. 05 Apr, 2019 1 commit
  5. 04 Apr, 2019 1 commit
  6. 30 Mar, 2019 1 commit
    • 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
  7. 27 Feb, 2019 1 commit
  8. 14 Feb, 2019 1 commit
  9. 23 Jan, 2019 1 commit
  10. 18 Jan, 2019 1 commit
  11. 15 Jan, 2019 1 commit
  12. 14 Jan, 2019 1 commit
  13. 07 Jan, 2019 1 commit
    • Cedric Roux's avatar
      fix a lot of file mode · aea6b4b5
      Cedric Roux authored
      For whatever reason most of the files had their permission
      changed from 644 to 755, which is not wanted.
      aea6b4b5
  14. 07 Dec, 2018 1 commit
    • Robert Schmidt's avatar
      F1AP_UE_CONTEXT_RELEASE_REQ: implement in DU · f3f2bc58
      Robert Schmidt authored
      * MAC differentiates between DU/eNB
      * sends ITTI message to DU task for F1AP_UE_CONTEXT_RELEASE_REQ
      * message is dispatched to correctly in DU_TASK
      * sender correctly fills IDs and cause and sends
      f3f2bc58
  15. 18 Nov, 2018 1 commit
  16. 20 Oct, 2018 1 commit
  17. 17 Oct, 2018 1 commit
  18. 03 Sep, 2018 14 commits
  19. 30 Jul, 2018 1 commit
  20. 05 Jul, 2018 1 commit
  21. 26 Jun, 2018 1 commit
  22. 29 May, 2018 1 commit
  23. 22 Apr, 2018 1 commit
  24. 08 Apr, 2018 1 commit
  25. 13 Mar, 2018 1 commit
  26. 08 Mar, 2018 1 commit
    • Cedric Roux's avatar
      cleanup MAC PDU generation (plus some general cleanup) · 1a8d81ba
      Cedric Roux authored
      The code was very unclear and potentially buggy.
      This new version is more robust.
      
      We can waste up to 2 bytes because the last header in the MAC PDU
      does not contain a length field and when we request data from RLC
      we suppose a 3-bytes MAC header. This might be optimized at some
      point, but the benefit would be low.
      
      This commit also contains some general cleanup:
      - formatting
      - variables' types: let's use 'int' instead of trying to be clever
        by using small types that may generate bugs if the value is
        too big
      - remove 'tpc_accumulated' which was globally used for all UEs
        and has no purpose other than logging. We may want to rework
        a bit the TPC machinery at some point. As the code is today
        we may repeatedly send TPC over and over without caring about
        the 3GPP limits, in which case no one knows how the UE is
        supposed to behave: does it clamp the current max value or does
        it accumulate over and over and take the clamped value to compute
        its actual power? If we send a reverse TPC (reduce power instead
        of increase) does it do it immediately or does it have to decrease
        n+1 times if we previously ordered it to increase n times?)
      
      We do not address the problem of prioritizing LCIDs. As of today there
      is only one dedicated traffic channel (DTCH), so it's not a problem
      at this point.
      
      What has been tested:
      - monolithic eNB 5/10/20MHz with one cots UE, TCP/UDP UL/DL. At 20MHz the
        machine used was not capable of keeping up, generating lots of Us
        and Ls when the throughput reaches 60Mb/s. USRP B210 was used.
      1a8d81ba
  27. 01 Mar, 2018 1 commit