MR978 :
We have incorporated 5G NR nFAPI into the develop branch
P5 and P7 interfaces for NR have been implemented.
With this MR, downlink transmission through nFAPI will be possible.
We have also made sure that 4G nFAPI can be used from within the develop branch.
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
- 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" );
};
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
hardy