SCF FAPI 222.10.02 had a bug on the description of CoreSetType:
0: CORESET is configured by the PBCH or SIB1
(subcarrier 0 of CRB0 for DMRS mapping)
1: otherwise (subcarrier 0 of CORESET)
That was fixed in SCF 222.10.04:
0: CORESET is configured by the PBCH or SIB1
(subcarrier 0 of the CORESET)
1: otherwise (subcarrier 0 of CRB0 for DMRS mapping)
That wrong description created a misunderstanding, to overcome it we "wrongly" added a third value. This commit fixes that and aligns the CoreSetType with FAPI 222.10.04
The UE will trigger new RA either with MAC CE C-RNTI or with new RRCSetupRequest:
- MAC CE C-RNTI: The ul_failure_timer will be reset
- RRCSetupRequest: New UE will be created and the previous one will be deleted
remove several unused files
remove mem_block_t that is never used in a different way than a simple heap buffer
move up IP address type and remove duplications of the same struct declaration
When the gNB does not receive PUCCH with Ack for Msg4 we have to consider Msg4 received by the UE, so we need to apply the CellGroupConfig sent to the UE.
There are two scenarios:
1 - The UE never decoded PDSCH for Msg4, the RA will fail because RA Contention Resolution timer, the UE will come with a new RA with new RRCSetupRequest
2 - The UE decoded PDSCH for Msg4, and if SR does not work and no resources for PUSCH, it will trigger RA with MAC CE C-RNTI in Msg3 (so, gNB must be ready for it)
The CellGroup is created considering UID, for example:
'pucchres0->startingPRB = 8 + uid;' and since we keep the CellGroup from
the previous RNTI/UID we should keep also the previous UID.
Considering the scenario where a UE did successful RRCReestablishment,
it was getting uid = 1, and uid = 0 was removed.
When another UE connected, it was getting UID = 0 (because 0 was already
free), and so the PUCCH 0 resource was conflicting with the first UE.
On that occasion, also correct the comment that describes the code, as
it was wrong/misleading.
- Implement: Extend the F1 encoding and decoding with Qos
- Implement: E1 decoding for QoS
- Fix: Modify the UE_MODIFICATION_REQUEST_MSG towards DU to contain QoS info based on E1AP context response
- Fix: Modify the E1AP and F1AP message structures
- Fill the Qos configuration to send to MAC
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.
Laurent THOMAS