An error occurred fetching the project authors.
- 30 Nov, 2023 1 commit
-
-
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.
-
- 20 Nov, 2023 1 commit
-
-
francescomani authored
-
- 10 Nov, 2023 1 commit
-
-
rmagueta authored
-
- 31 Oct, 2023 1 commit
-
-
Sakthivel Velumani authored
Each active LCID at MAC is configured with NSSAI that is sent from AMF with PDU session setup request
-
- 27 Oct, 2023 1 commit
-
-
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.
-
- 26 Oct, 2023 1 commit
-
-
Laurent THOMAS authored
-
- 22 Sep, 2023 7 commits
-
-
Robert Schmidt authored
- Forward UE capabilities in F1 handlers - Store at MAC - Update CellGroupConfig with UE Capabilities of the UE
-
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.
-
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
-
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.
-
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()
-
Robert Schmidt authored
As with the ServingCellConfigCommon, the ServingCellConfigDedicated is a radio-related structure to be handled at the DU.
-
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
-
- 21 Sep, 2023 1 commit
-
-
Robert Schmidt authored
-
- 20 Sep, 2023 1 commit
-
-
rmagueta authored
-
- 14 Aug, 2023 2 commits
-
-
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.
-
Robert Schmidt authored
-
- 12 Aug, 2023 1 commit
-
-
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.
-
- 08 Aug, 2023 1 commit
-
-
Robert Schmidt authored
-
- 23 Jun, 2023 1 commit
-
-
francescomani authored
-
- 26 May, 2023 1 commit
-
-
Robert Schmidt authored
-
- 25 May, 2023 3 commits
-
-
Robert Schmidt authored
-
Robert Schmidt authored
-
Robert Schmidt authored
-
- 12 May, 2023 1 commit
-
-
francescomani authored
-
- 03 May, 2023 2 commits
-
-
Robert Schmidt authored
-
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).
-
- 14 Apr, 2023 1 commit
-
-
Robert Schmidt authored
-
- 05 Apr, 2023 1 commit
-
-
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.)
-
- 17 Mar, 2023 1 commit
-
-
francescomani authored
-
- 15 Mar, 2023 1 commit
-
-
Thomas Schlichter authored
-
- 09 Mar, 2023 1 commit
-
-
francescomani authored
-
- 06 Mar, 2023 1 commit
-
-
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
-
- 24 Feb, 2023 1 commit
-
-
francescomani authored
-
- 23 Feb, 2023 1 commit
-
-
francescomani authored
-
- 21 Feb, 2023 1 commit
-
-
francescomani authored
-
- 19 Jan, 2023 1 commit
-
-
laurent authored
-
- 27 Dec, 2022 2 commits
-
-
francescomani authored
-
francescomani authored
-
- 27 Oct, 2022 1 commit
-
-
francescomani authored
-