- 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.
!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
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()
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.
- 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
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.
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...
In the case of MIMO, we reused memory to point to the same PUCCH
resource. This is problematic, since ASN_STRUCT_FREE() would try to free
this resource twice.
This commit changes to create distinct memory for the PUCCH resources,
while putting the same configuration to still use the same PUCCH
resource from a radio configuration point of view.
The RRC should not trigger RLC bearer establishment: this should be done
only via F1, and in the remaining code (removed here), this principle
was violated.
Further, this code was doubly wrong, as it used the CU UE ID for the
RLC, setting up bearers with IDs 1,2,3 etc instead of the RNTI.
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.
Robert Schmidt