If we cannot send Msg.2, then basically the RA process is dead (because
the UE expects it at a fixed time). Hence, cancel the RA process, so
that we do not pick it up again after 1000 frames.
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)
PDU Length is as per SCF 222.10.02: The total length (in bytes) of the
PDU description and PDU data, without the padding bytes. From
TX_DATA.request we get 8 (2 bytes PDU_Length + 2 bytes PDU_Index + 4
bytes num_TLV ) and from each TLV we get 4 + value size ( 2 bytes tag +
2 bytes length + value size without pading)
Therefore, add function to compute PDU_length() value for
TX_Data.request, taking into account how many TLVs there are.
compute_PDU_length() does not rely on access to `nfapi_nr_pdu_t`.
Put it into nr_mac_common.c to avoid introducing dependencies.
- 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
After removing RA.crnti, there is no need to use a separate function
nr_generate_Msg3_dcch_dtch_response() to generate Msg.4 (yes, the
function mentions Msg3 but it does Msg3 response == Msg.4).
Also, using nr_generate_Msg4() has the advantage that it waits until we
have the reconfiguration available in RLC to be sent to the UE. Finally,
we can delete the old nr_generate_Msg3_dcch_dtch_response() as we don't
need it anymore.
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.
We don't work much on asn1c. The version we use has several bugs.
There is an active community out there that fixes bugs and improves
asn1c. Let's use their version.
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).
To know which functions are used from outside and which are
module-local, make many functions static. This will allow us to protect
only those functions with a mutex for which it is necessary.
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.)
