Integration 2021 wk06 c
- Feb 09, 2021
-
-
Robert Schmidt authored
-
hardy authored
-
hardy authored
-
hardy authored
-
- Feb 08, 2021
-
-
Sakthivel Velumani authored
-
Sakthivel Velumani authored
-
Robert Schmidt authored
This reverts commit 71e297de.
-
- Feb 07, 2021
-
-
Robert Schmidt authored
-
Robert Schmidt authored
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.
-
Robert Schmidt authored
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.
-
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
-
-
-
-
-
-
-
- To check the current slot is the scheduled slot(UL slot - K2) and only execute the post processor in scheduled slot.
-
-
-
-
-
Robert Schmidt authored
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
Robert Schmidt authored
-
-
-
Robert Schmidt authored
-
Robert Schmidt authored
-
Robert Schmidt authored
This commit enables more slots so that the "real UE" preprocessor can schedule them. The DL phytest preprocessor continues to only schedule slots 1 & 3. This is because the OAI-UE needs to have PUCCH scheduled at least six slots in advance. Since we do not support this (yet), but assume that two slots are enough, we schedule the UE only in slot 1 & 3 so it has 6 slots until slot 7 to send PUCCH.
-
Robert Schmidt authored
-
Robert Schmidt authored
-
Robert Schmidt authored
-
Robert Schmidt authored
-
Robert Schmidt authored
-
-
made L1 DLSCH encoding stateless. harq_pid/round information are not kept in PHY. Full channel encoding is performed for each transmission of a transport block. Still to be done: test, then cleanup data structures and fix unitary simulations.
-
Robert Schmidt authored
-
Robert Schmidt authored
-
Robert Schmidt authored
mac_remove_nr_ue(): no need to memset sched_ctrl, since it is done on connection of a UE
-
Robert Schmidt authored
the whole UE_sched_ctrl is initialized in add_new_nr_ue(), which will also init the per-UE HARQ.
-
Robert Schmidt authored
-
Robert Schmidt authored
-
Robert Schmidt authored
-
Robert Schmidt authored
-
Robert Schmidt authored
Before this commit, the DLSCH scheduler would construct the MAC PDU by reading RLC data into a memory on the stack, and then construct the PDU with CEs first. There are at least two problems: - we need to keep track of the exact number of bytes of CEs (cumbersome) to calculate the number of MAC SDUs to include - we needlessly copy data around. This commit does the following instead: - write all CEs first (no need of keeping track of this in DLSCH and a separate function) - then read MAC SDUs directly into nFAPI as much as possible or necessary, without recopying
-
Robert Schmidt authored
-
Robert Schmidt authored
-
Robert Schmidt authored
-
Robert Schmidt authored
-
Robert Schmidt authored
-
Robert Schmidt authored
-
Robert Schmidt authored
According to SCF222, a single PDCCH allocation groups DCIs that are within the same BWP and CORESET. Therefore, if we want to allocate multiple DCIs, we need to decouple PDCCH allocation and DCI (previously jointly done in nr_configure_pdcch()), especially to be forward compatible. ***Note that as of this commit, we would still allocate different PDCCH PDUs for multiple UEs (which we do not support yet, anyway)*** nr_configure_pdcch(): simply take out DCI allocation. nr_generate_Msg2(): separately allocate dci_pdu in common RA SS, and rename DCI payload variable. Also, reorganize the function so that it is first checked for CCE allocation and messages nFAPI messages are allocated afterwards. nr_schedule_ue_spec(): separately allocate dci_pdu in UE-specific SS. Rename DCI payload variable. nr_schedule_ulsch(): separately allocate dci_pdu in UE-specific SS. Rename DCI payload variable. nr_fill_nfapi_dl_sib1_pdu(): separately allocate dci_pdu in common SS.
-
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
SCF222 says that dci_pdu in PDCCH PDU (nfapi_nr_dl_tti_pdcch_pdu_rel15_t) should be an array, and not its members.
-
Robert Schmidt authored
-
Robert Schmidt authored
-
Robert Schmidt authored
Initially, filling the PDCCH and PDSCH nFAPI messages was split into a separate function (in an attempt to keep the code structure similar to LTE). However, this proved as not helpful: the nr_fill_nfapi_dl_pdu() just filled the messages, with a parameter list almost size as long as the actual messages (because most parameters are kind of independent). This made no sense, so we put it back. Also, from an understanding POV, they just fill a message as specified in SCF222, so it should not be a problem.
-
Robert Schmidt authored
-
Robert Schmidt authored
-
Robert Schmidt authored
-