- 22 Sep, 2023 25 commits
-
-
Robert Schmidt authored
-
Robert Schmidt authored
-
Robert Schmidt authored
-
Robert Schmidt authored
-
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
-
Robert Schmidt authored
-
Robert Schmidt authored
In NSA case: do not send SIB1
-
Robert Schmidt authored
-
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
Previously, filling of F1 Setup Request depended on reading the RRC; hence, for timing reasons, we only initialized and sent the F1 Setup Request once the MAC and RRC are ready. After moving SCC, SCD, MIB, and SIB1 to MAC, the MAC does not depend on an RRC being present anymore, and hence, the F1 Setup Request does neither. In this commit, we read the F1 Setup Request after initializing the MAC.
-
Robert Schmidt authored
-
Robert Schmidt authored
-
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
-
Robert Schmidt authored
As with the ServingCellConfigCommon, the ServingCellConfigDedicated is a radio-related structure to be handled at the DU.
-
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.
-
Robert Schmidt authored
The PCI is given to the CU from the DU in the F1 Setup Request message. It is a part of the DU, so move it "down".
-
Robert Schmidt authored
-
Robert Schmidt authored
-
Robert Schmidt authored
-
Robert Schmidt authored
The F1 Setup Response contains the cell(s) to activate. Hence, prevent the radio from starting by waiting for the F1 Setup Response before continuing.
-
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 15 commits
-
-
Robert Schmidt authored
Use a struct to initialize the RRC at the beginning, and remove the NRRRC_CONFIGURATION_REQ. This message is not necessary; the RRC/CU should be initialized from the F1 Setup Request, coming from the DU.
-
Robert Schmidt authored
-
Robert Schmidt authored
-
Robert Schmidt authored
Before this commit, we did not read the ServingCellConfigCommon (SCC) completely at start; rather, we read most (but not all) of it, then also the minRXTXTIME, and at RRC initialization in openair_rrc_gNB_configuration(), we filled the pusch-TimeDomainAllocationList into the SCC, depending on the minRXTXTIME. The reason might be that we read part of the SCC, use that to fill the NRRRC_CONFIGURATION_REQ, read also the minRXTXTIME (part of the RRC config), and then we have all we need to "finalize the SCC". Since we move everything to the MAC, I avoid too much upfront code changes, hardcode the minRXTXTIME (and check with an assert), and undo this in a later commit when the "RRC config" relevant for radio parameters, e.g., minRXTXTIME, is moved to MAC. I verified the equality of the SCC before (at the end openair_rrc_gNB_configuration()) and after (at the end of get_scc_config()) this commit manually using a printf, assuming that after RRC initialization, we didn't do any further modifications to the SCC. But in fact, I cannot know that we don't do it...
-
Robert Schmidt authored
- Simplify code by reading the SCC in a separate function - Fill the F1 Setup Request message correctly in case of FDD, from SCC
-
Robert Schmidt authored
-
Robert Schmidt authored
-
Robert Schmidt authored
-
Robert Schmidt authored
-
Robert Schmidt authored
-
Robert Schmidt authored
-
Robert Schmidt authored
-
Robert Schmidt authored
-
Robert Schmidt authored
-
Robert Schmidt authored
-