use --fapi-tracer with build_oai to activate
(basically set FAPI_TRACER to True in CMakeLists.txt)

the file /tmp/fapi.c will be produced at runtime

then cd openair2/LAYER2/MAC and compile fapi_replay.c to replay it

this is forbidden, libscheduler.a is not happy

use mac_rlc_status_ind instead
(at first I thought I could not use it and wrote
mac_rlc_get_buffer_occupancy instead)

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

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.