See merge request oai/openairinterface5g!1291
MR !1277 : fixes for nr_set_pdsch_semi_static
MR !1225 : Cleanup and first step to enhance cpu measurments
MR !1278 : NR cleanup separation macphy
MR !1289 : Nr dlsch retransmission fix pucch allocation
MR !1270 : Removing hardcoded value of min channel bw for type0 pdcch
MR !1283 : Bugfix simultaneous RACH with multiple UEs
cherry-picks :
* MAC statistics in separate thread
* CI conf files update
integration of integration_2021_wk41_bwt-abs into develop, completed week 42
MR !1273 : [CI] adding Docker Hub push pipeline
-When we merge to develop, this pipeline will automatically push images to hub.docker.com
MR !1267 : Enabled multi-threading for gNB L1 tx
-PHY PDUs like PDCCH PDU, PDSCH PDU, SSB PDU and CSI PDU have been removed from PHY_VARS_gNB structure.
Instead, they are made as a part of thread message for L1 Tx processing.
Two such thread messages are used so that two independent L1 Tx processing threads can be executed at once.
Monolithic mode works fine with rfsimulator. nfapi mode changes are integrated by not tested. Let the CI test it.
MR !1285 : [CI] test sa nsa
-Dev of nsa and sa test pipelines
MR !1266 : Changes for initialBWP size different than Coreset0
-Changes for initialBWP size different than Coreset0. Tested with 50 MHz 2x2 configuration, initialBWP with 133 PRBs.
-Other fixes and improvements to get a more stable 5G NR connection
Also, reverted some init_pdcp logic to match
the develop branch and added NSA mode. Lastly,
added additional error checking for cellConfig
to avoid crash in MAC layer.
Also, this commit changes the len argument in the
pusharray32 to match the actual field type (uint16_t).
There is also simple name change from sf -> slot.
The new queueing system is not a permanent solution.
It was simply a way for us to try to handle late
dl_tti_requests. If we queue every single ul_tti_req
that we get, the queue gets full very quickly becasue
we only remove ul_ttis from the queue when a uci has
been populated with a matching sfn/sf. Because of this,
we only queue ul_ttis if we have a uci_indication
prepared already. Rarely, a dl_tti_req will arrive at
the NRUE too late, and the NRUE does not have time
to create the uci_ind so we dont process the corresponding
ul_tti. A seprate queue was made to hold all other ul_ttis
the arrive in the NRUE (this queue will continuously
get full and then emptied) but will occasionally hold
a ul_tti that corresponds to a uci that hasnt
been populated yet.
Melissa Elkadi