An error occurred fetching the project authors.
- 05 Mar, 2021 1 commit
-
-
Xue Song authored
-
- 04 Mar, 2021 2 commits
- 02 Mar, 2021 1 commit
-
-
matzakos authored
-Remove redundant calls to mac_rlc_data_ind for DTCH case
-
- 26 Feb, 2021 2 commits
- 19 Feb, 2021 2 commits
-
-
Florian Kaltenberger authored
-
guhan authored
-
- 18 Feb, 2021 1 commit
-
-
Francesco Mani authored
-
- 17 Feb, 2021 1 commit
-
-
Robert Schmidt authored
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
-
- 15 Feb, 2021 4 commits
-
-
Cedric Roux authored
go figure...
-
Cedric Roux authored
- a new section in the configuration file to select security algorithms, with new code to deal with it - cleanup CG-ConfigInfo: specs seem to indicate that we must not add mcg_RB_Config; the gNB has to deal with that - as a consequence, modify fill_default_rbconfig() that is called in every cases and needs security and bearer parameters The new section in the configuration file looks like: security = { # preferred ciphering algorithms # the first one of the list that an UE supports in chosen # valid values: nea0, nea1, nea2, nea3 ciphering_algorithms = ( "nea0", "nea2" ); # preferred integrity algorithms # the first one of the list that an UE supports in chosen # valid values: nia0, nia1, nia2, nia3 integrity_algorithms = ( "nia0" ); };
-
Cedric Roux authored
-
Cedric Roux authored
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.
-
- 12 Feb, 2021 13 commits
-
-
Robert Schmidt authored
-
Cedric Roux authored
- compute correct kgNB - propagate properly NR security capabilities of an UE (involves: rrc, s1ap, x2ap)
-
guhan authored
-
Mahesh authored
-
kn.raju authored
-
kn.raju authored
-
kn.raju authored
-
kn.raju authored
* 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
-
kn.raju authored
-
kn.raju authored
-
kn.raju authored
-
kn.raju authored
-
kn.raju authored
-
- 11 Feb, 2021 1 commit
-
-
Mahesh authored
-
- 10 Feb, 2021 2 commits
-
-
Laurent Thomas authored
-
heshanyun authored
-
- 09 Feb, 2021 3 commits
-
-
Robert Schmidt authored
-
dir authored
-
yincong authored
-
- 08 Feb, 2021 2 commits
-
-
Sakthivel Velumani authored
-
Robert Schmidt authored
This reverts commit 71e297de.
-
- 07 Feb, 2021 5 commits
-
-
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
-