- FAPI structures not to be used as config_req at MAC since that FAPI is
just for communication between MAC and PHY
- additional frame_type member added to the FAPI struct
In FDD mode, the UE_mode switches to PUSCH mode before the initial TA value was applied.
Because of this, the ta_command was misinterpreted.
Fix this by adding 31 to the initial TA comamnd and handle it the same as TA updates.
1) Only count new transmission as scheduled bytes (which is then
compared against the BSR)
2) When subtracting scheduled bytes after successful reception, subtract
TBsize from correct HARQ process
- scheduled_response was called regardless of the UL config in the PRACH slot
this was leading to wrong behaviour since it was interfering with the
UL config of PUSCH
The code is forced to use nea2, no matter what the UE supports.
After 2^18 PDCP packets, it will fail to work (we don't use HFN yet).
These limitations will be fixed in later commits.
The existing security function was not reused, because it does too
much memory allocation and initializes the security context at each
ciphering. So here comes nr_pdcp_security_nea2_cipher(). And also
the ciphering is done inplace. To be changed if necessary.
* add the RA process to handle to command parameters
* Do not create the RAR_pdu into an intermediate array, but directly
into the nFAPI TX_req
* Slightly restructure nr_generate_Msg2() to first make AssertFatal()
checks, then proceed allocating
As the precedent commit, this commit deals with the realtime problems
that we currently have on the CI bench.
For DL HARQ feedback, nFAPI does not give us the HARQ process ID.
Instead, we have to figure this out "from timing", i.e., if we trigger
PUCCH reception, we will get a message with HARQ if we instructed the
PHY to do so. If we have real-time problems, it seems (I cannot verify:
don't have real time problems) that we do not get the nFAPI message with
HARQ feedback. Thus, we need to skip the HARQ processes that should have
been processed in the past, which happens in this commit.
At the time of this commit, the CI has realtime issues. This can mean
that the HARQ result is delivered in a delayed fashion. Before this
commit, we were asserting on whether the slot corresponds to the HARQ
process's expected feedback slot, but a particular feedback might be
delayed under realtime issues, and we actually don't care about the
timing since we get the HARQ process ID.
Instead, we loop through the HARQ processes for which we wait for a
feedback in the beginning until we have the right process (which did not
seem to cause a problem till now, but who knows.
cig