Some more fixes for some bad conflict resolutions.
I ran:
git diff 2018.w04 2018.w05
And saw some problems with config_sib2.
There was also something strange in openair2/LAYER2/openair2_proc.c
in the function dump_eNB_l2_stats. Maybe the fix is wrong for
this one. To be checked.
Doing an iperf UDP uplink test, we could reach only 6Mb/s
with very good radio conditions instead of around 8Mb/s.
It turns out the MCS was limited to 16.
With this commit, we are back to a bit more than 8Mb/s
as it used to be.
(This is with a 5MHz bandwidth.)
The problem that may happen is that when the UE does not transmit
on PUCCH (for whatever reason) we may get no signal at all, and
thus compute a very low CQI. Later on we may ask the UE to transmit
louder which may lead to saturation and more problems.
The solution is simple: don't care about CQI in case of DTX
(and NACK also, as done for PUSCH).
Only FDD case done.
For TDD it seems that:
- nfapi structures are not correct. See nfapi_harq_indication_tdd_rel13_t
in nfapi/open-nFAPI/nfapi/public_inc/nfapi_interface.h, all the cases
(bundling, multiplex, ...) use nfapi_harq_indication_tdd_harq_data_t
- the function extract_harq does not handle TDD
Try to merge feature-68-enb-agent into develop
develop should be fast-forwarded later to this branch to complete the merge
This code does not compile yet. Among other things:
- the scheduler structure needs to be reworked for FlexRAN
- the config is structured differently. The files enb_config.{c,h} from develop
have been copied in here, the files with merge annotations are in
enb_config.{c,h}.before_merge
- the restart needs to be restructured, since the PHY vars data structure lives
in RC now
As reported by Emad Alizade:
According to "Issue255 256 257 paging reesta release" that has been
merged in develop version, we have a question: In rrc_eNB_free_UE()
function only all ulsch related memory of user has been cleaned, but
I think not only ulsch memory but also dlsch memory must be cleaned.
I tested the latest develop version and with repetition UE attach-detach
procedures we find that the dlsch memory has not been cleaned and after
repeat this sequence (45 times) assertion with cause UE_id!=-1 (no free
or exiting dlsch_context, dci_tools.c: fill_dci_and_dlsch() ) occurred
and no UE will be attached to system.
The fixes in this commit are from Emad Alizade.
Cedric Roux