This was causing oaisim to fail way too often at the startup
of a connection.

Things should go better with this patch.

It may not be the end of the story, the use of retrans_num_bytes_to_retransmit
is not clear to me. The problem I see is: what if the max number of
retransimission has been reached (if that has a meaning at all in RLC AM)?
will this value be decreased or not?

not sure about c-rnti

Merge branch 'feature-31-ff-scheduler-api' of https://gitlab.eurecom.fr/oai/openairinterface5g into feature-31-ff-scheduler-api

From IS-wireless, plus modifications to the code.
Note that MAX_NUM_CCs is forced to 2 in the ff-* files.

Merge branch 'feature-31-ff-scheduler-api' of https://gitlab.eurecom.fr/oai/openairinterface5g into feature-31-ff-scheduler-api

there is surely a bug that triggers that behavior

This reverts commit d453a03a.

For whatever reason the simulation does not work anymore, I have
to revert this commit for things to work again...

Merge branch 'feature-31-ff-scheduler-api' of https://gitlab.eurecom.fr/oai/openairinterface5g into feature-31-ff-scheduler-api

where it should have been frame*16+subframe)

Merge branch 'feature-31-ff-scheduler-api' of https://gitlab.eurecom.fr/oai/openairinterface5g into feature-31-ff-scheduler-api

does not handle TPC, plus the FAPI specification is not
clear about TPC, so let's handle that part in openair.

Merge branch 'feature-31-ff-scheduler-api' of https://gitlab.eurecom.fr/oai/openairinterface5g into feature-31-ff-scheduler-api

Conflicts:
	openair2/LAYER2/MAC/ff-mac.h

Conflicts:
	openair2/LAYER2/MAC/eNB_scheduler_dlsch.c