An error occurred fetching the project authors.
  1. 10 Nov, 2023 2 commits
  2. 04 Nov, 2023 2 commits
    • Robert Schmidt's avatar
    • Robert Schmidt's avatar
      Free F1 UE data struct only on UE release · 23025837
      Robert Schmidt authored
      Before this commit, as visible in the handler of an F1 UE release, it
      can happen that we forward the RRC Release message to a UE and start the
      release timer, while also removing the F1 UE data (containing e.g., the
      CU UE ID). This can lead to asserts, since there might still be
      subsequent traffic for such UE during a short time, while the DU does
      not have the secondary UE ID stored anymore.
      
      This commit changes the logic. It introduces function
      nr_mac_release_ue() that removes the UE at MAC and RLC, frees the F1 UE
      data (if applicable), and sends the complete, after timing expiry. If
      the UE is out of sync, this function is used to free the UE immediately.
      
      This fixes #685 and #698.
      23025837
  3. 27 Oct, 2023 1 commit
    • Robert Schmidt's avatar
      Read DMRS_UplinkConfig from BWP info when needed · dc88ca3b
      Robert Schmidt authored
      Before this commit, the DMRS_UplinkConfig was stored in a separate
      DMRS-related structure, although it is always referenced in the
      PUSCHConfig of the current UL BWP.
      
      Through certain code paths (e.g., retransmission), it could happen that
      an old DMRS_UplinkConfig was accessed that was freed (through new
      CellGroupConfig).
      
      In this commit, we always look up the DMRS_UplinkConfig in the current
      PUSCH config, which should always be up to date.
      dc88ca3b
  4. 26 Oct, 2023 1 commit
  5. 10 Oct, 2023 1 commit
  6. 06 Oct, 2023 1 commit
  7. 03 Oct, 2023 1 commit
  8. 02 Oct, 2023 1 commit
  9. 22 Sep, 2023 6 commits
    • Robert Schmidt's avatar
      Free scheduler UE data · d94a4e54
      Robert Schmidt authored
      d94a4e54
    • Robert Schmidt's avatar
      Forward UE capabilities to DU and use for CellGroupConfig · 3982cc2e
      Robert Schmidt authored
      - Forward UE capabilities in F1 handlers
      - Store at MAC
      - Update CellGroupConfig with UE Capabilities of the UE
      3982cc2e
    • Robert Schmidt's avatar
      Handle CellGroupConfig completely at MAC · 7e2487c2
      Robert Schmidt authored
      - MAC creates CellGroupConfig and sends to RRC
      - the RRC does not manually update the CellGroupConfig
      - MAC handles the RRC processing timer
      
      In this commit, any updates to the CellGroupConfig previously done at
      the RRC don't work. In other words, MIMO etc don't work; this is
      implemented in the next commit.
      
      Note that the change to take out spCellConfig during reestablishment is
      because after reestablishment, as per spec (38.331 5.3.7.2), the UE
      should drop the spCellConfig, which we generate by default on the first
      UE connection.
      
      Furthermore, add a new variable apply_cellgroup to signal if, after RRC
      processing timer, we wish to apply the CellGroup. In some situations,
      e.g., Msg.4 ack, we do not want to apply the CellGroup, because for
      instance in reestablishment, we await for a reconfiguration of cellgroup
      that would be triggered too early.
      7e2487c2
    • Robert Schmidt's avatar
      Move radio configuration parameters to MAC, SIB1 not initialized! · c9305639
      Robert Schmidt authored
      !SIB1 is not correctly filled! This commit does not work with COTS UEs!
      The next commit fixes this.
      
      - Move radio config (e.g., minRXTXTIME, SIB1 TDA, do_SRS, etc) down to
        MAC.
      - Some parameters in MAC are redundant: delete them.
      - Remove call to nr_mac_config_scc() from RRC and simulators, the MAC
        initialization routine calls it implicitly
      c9305639
    • Robert Schmidt's avatar
      Move ServingCellConfigDedicated to MAC · 0f897b40
      Robert Schmidt authored
      As with the ServingCellConfigCommon, the ServingCellConfigDedicated is a
      radio-related structure to be handled at the DU.
      0f897b40
    • Robert Schmidt's avatar
      Move ServingCellConfigCommon to MAC · 2b295315
      Robert Schmidt authored
      Note: the reestablishment is broken, and a later commit fixes it.
      
      The ServingCellConfigCommon is an inherently radio-related
      configuration. As such, it should be handled by the DU, not the CU.
      Therefore, move it "down" to the MAC.
      2b295315
  10. 23 Aug, 2023 1 commit
  11. 14 Aug, 2023 2 commits
  12. 11 Aug, 2023 3 commits
  13. 23 Jun, 2023 1 commit
  14. 10 Jun, 2023 1 commit
  15. 01 Jun, 2023 2 commits
  16. 26 May, 2023 1 commit
  17. 25 May, 2023 2 commits
  18. 23 May, 2023 1 commit
  19. 05 May, 2023 1 commit
  20. 03 May, 2023 2 commits
    • Robert Schmidt's avatar
      Introduce mutex for MAC scheduler · 31a10033
      Robert Schmidt authored
      Different threads (e.g., RRC, DU tasks) might access the scheduler at
      the same time as the thread that drivers the scheduler itself
      (ru_thread). To avoid data races, introduce this mutex.
      
      Most functions of the scheduler are only used internally and have been
      marked static in the previous commit. The remaining ones, in this
      commit, either lock the scheduler mutex sched_lock, or a comment has
      been added of the assumption of how such function is to be locked (e.g.,
      if it might be called from different places, or if it is called by a
      function that already locks the scheduler).
      31a10033
    • Robert Schmidt's avatar
      NR MAC: make many functions static · e7a8eb95
      Robert Schmidt authored
      To know which functions are used from outside and which are
      module-local, make many functions static. This will allow us to protect
      only those functions with a mutex for which it is necessary.
      e7a8eb95
  21. 28 Apr, 2023 1 commit
  22. 11 Apr, 2023 2 commits
  23. 07 Apr, 2023 1 commit
  24. 05 Apr, 2023 1 commit
    • Cedric Roux's avatar
      bugfix: change memory management of interface between PHY and MAC scheduler · 733c7e5e
      Cedric Roux authored
      This commit fixes a bug caused by global variables in the gNB_MAC_INST
      structure used to transfer MAC scheduler's results to the PHY layer.
      
      When using several threads in the PHY layer, it may happen that the
      MAC scheduler is called a second time by the second PHY thread for the
      next slot before the content of the global variables in the gNB_MAC_INST
      structure used to store the result of the MAC scheduler for the current
      slot have been consumed by the first thread, leading to unpredictable
      results (all of them certainly wrong).
      
      The solution is to introduce a small memory management module for the
      interface between the PHY threads and the MAC scheduler. The MAC
      scheduler now fills the data structures passed to it, and not a
      global variable anymore. The PHY layer manages the structures and
      ensures that no data is overwritten before being fully consumed by
      the various threads of the PHY layer.
      
      Some care has to be taken because several PHY threads will access the
      same structures at the same time for a given slot (in read mode, so
      it's okay). A mechanism of reference counting has thus been introduced.
      
      Only one CC is supported. This restriction should not be too hard
      to remove if/when needed. (The code before this commit does not seem
      to work for more than one CC anyway.)
      733c7e5e
  25. 27 Mar, 2023 2 commits