An error occurred fetching the project authors.
  1. 30 Nov, 2023 1 commit
    • Robert Schmidt's avatar
      Introduce separate gNB-DU ID in configuration · 6f14b118
      Robert Schmidt authored
      3GPP has the concept of a gNB-DU ID and a (separate) gNB ID (for gNB,
      CU). This commit introduces the gNB-DU as a separate ID that has to be
      set in the configuration file. It is necessary, as some entities, e.g.,
      the e2 agent, need to signal both IDs, e.g., to reconcile a CU and
      (multiple) DU(s) belonging together.
      6f14b118
  2. 20 Nov, 2023 1 commit
  3. 10 Nov, 2023 1 commit
  4. 31 Oct, 2023 1 commit
  5. 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
  6. 26 Oct, 2023 1 commit
  7. 22 Sep, 2023 7 commits
    • 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 SIB1 to MAC · a44a54f3
      Robert Schmidt authored
      The SystemInformationBlock 1 is handled at the DU and sent to the CU in
      the F1 Setup Request. Hence, move it down to the MAC.
      a44a54f3
    • Robert Schmidt's avatar
      Move MIB to MAC · 5d0ae84a
      Robert Schmidt authored
      The MasterInformationBlock is handled at the DU and sent to the CU in
      the F1 Setup Response. Hence, move it down to the MAC. Furthermore:
      
      - Change type because MIB_PDU_t is 4G type
      - Simplify schedule_nr_mib()
      5d0ae84a
    • 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
      Implement F1 Setup Request/Response to be used internally · aaae82d7
      Robert Schmidt authored
      - send F1 Setup using callback
      - store f1 setup req locally for reference
      - check F1 Setup Req against RRC data structures:
        * if matches: send F1 Setup Response using callback
        * if not matching: send F1 Setup Failure using callback
      - don't send CU config update by default, we don't need this
      - if the Setup Response does not contain a cell, don't activate. It is
        possible the CU sends a gNB-CU configuration update, which will
        initialize the structures
      aaae82d7
  8. 21 Sep, 2023 1 commit
  9. 20 Sep, 2023 1 commit
  10. 14 Aug, 2023 2 commits
    • Robert Schmidt's avatar
      Remove RA.crnti: it is not needed anymore · 93f59a3c
      Robert Schmidt authored
      The RA.crnti field is marked as being used by NSA mode, but it is not.
      OTOH, it is used in the case of RA with Msg.3 with C-RNTI MAC CE. The
      latter does not necessarily need it, though, as we can change the RNTI
      of the RA process when we receive C-RNTI MAC CE.
      
      This introduces a slight complication, though, as we cannot remove the
      MAC UE Context (generated when receiving Msg.3) directly when parsing
      the C-RNTI MAC CE. Previously, we had both rnti and crnti in the RA
      struct, and when sending Msg.4 after Msg.3 with C-RNTI MAC CE, we would
      remove the UE context (this is changed in the next commit). Therefore,
      we employ nr_mac_trigger_release_timer() which releases the UE after
      60ms, circumventing this complication.
      93f59a3c
    • Robert Schmidt's avatar
  11. 12 Aug, 2023 1 commit
    • Robert Schmidt's avatar
      Repair reestablishment and make it work via F1 · 7a298e73
      Robert Schmidt authored
      This commit repairs the reestablishment after the introduction of the CU
      UE ID in the CU, different from the DU UE ID. Now, the CU uses an
      identifier different from the RNTI, used in the MAC, to refer to UEs.
      
      To repair the reestablishment, a number of changes needed to be
      introduced:
      
      - Handle old_gNB_DU_UE_id in MAC
      
      The MAC handles the old_gNB_DU_UE_id field in the DL RRC Message. The
      commit adds encoding/decoding of the field. The MAC will drop the old
      UE, but retain the CellGroup of the corresponding UE(!). Because a UE
      releases the spCellGroup on reestablishment, the MAC does the same; it
      needs to reapply the old configuration after a reconfiguration. For the
      latter, introduce new variables to keep a "future" CellGroupConfig to be
      applied (reconfigCellGroup) and a flag (expect_reconfiguration) that
      applies the CellGroupConfig if a DL RRC Message transfer on DCCH, which
      is assumed to be the reconfiguration.
      
      - Add RNTI change in RLC
      
      The RLC needs to reuse the old UE context. Hence, we simply change the
      RNTI in the old context, and delete the new one.
      
      - No PDCP UE ID change
      
      The previous implementation of the PDCP used the RNTI; hence, the ID
      needed to be switch (as above for the RLC). Since the PDCP now also uses
      the CU UE ID, no identifier change is needed, and we remove all
      corresponding code.
      
      - No MAC modifications/update from CU
      
      As foreseen by the spec, the CU does not modify or change the
      cellGroupConfig in the RRC during reestablishment. This change will be
      generalized in the future to all of the RRC.  Also, the
      nr_rrc_mac_remove_ue() function has been removed: the MAC handles any UE
      changes autonomeously, without being triggered from the RRC explicitly.
      
      - Remove reestablish_rnti_map
      
      The RRC does not use RNTIs for UE identification. Hence, a
      reestablish_rnti_map to link two UEs to each other is not necessary
      anymore.
      7a298e73
  12. 08 Aug, 2023 1 commit
  13. 23 Jun, 2023 1 commit
  14. 26 May, 2023 1 commit
  15. 25 May, 2023 3 commits
  16. 12 May, 2023 1 commit
  17. 03 May, 2023 2 commits
    • Robert Schmidt's avatar
      10b996f5
    • 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
  18. 14 Apr, 2023 1 commit
  19. 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
  20. 17 Mar, 2023 1 commit
  21. 15 Mar, 2023 1 commit
  22. 09 Mar, 2023 1 commit
  23. 06 Mar, 2023 1 commit
    • Robert Schmidt's avatar
      RC: forward declarations and link physims better · 8a15fb7c
      Robert Schmidt authored
      The simulators have been changed: due to linker errors that would arise
      otherwise, a lot of functions are defined in them to avoid such errors.
      Some functions are also defined in header files; in this commit, we
      define most functoins in nr_dummy_functions.c, which is compiled in, not
      by including the C file, but by adding it to the target in
      CMakeLists.txt
      
      - nr_dlsim+nr_ulsim need NR_IF_Module_init(), so it cannot be in
        nr_dummy_functions, but the others need it
      - Link correcr NR_IF_Module_init() into these simulators, and reduce
        overall link list
      - Correctly link remaining simulators
      8a15fb7c
  24. 24 Feb, 2023 1 commit
  25. 23 Feb, 2023 1 commit
  26. 21 Feb, 2023 1 commit
  27. 19 Jan, 2023 1 commit
  28. 27 Dec, 2022 2 commits
  29. 27 Oct, 2022 1 commit