If VNF and PNF are deployed through different processes, it's crucial to
maintain synchronization and ensure smooth operation. This commit
addresses the need to keep the VNF slot ahead of 2 (as required for
network deployment), while ensuring that PNFs wait appropriately to
avoid overtaking the slot. Specifically, this involves measuring slot
duration and implementing a wait mechanism to ensure that PNFs do not
exceed a slot duration of 300 microseconds. This ensures proper smooth
operation, especially in the case of RFsim.

Reset the counters. In monolithic, this happens in the scheduler; in the
PNF, without this change, it would trigger PDCCH again.
Co-authored-by: hsum <ming-hong.hsu@eurecom.fr>

This is already triggered in the same function.

Refactor pnf_phy_ul_dci_req(), pnf_phy_dl_tti_req(),
pnf_phy_tx_data_req(), pnf_phy_ul_tti_req(), to use L1 functions to
"load" L1 jobs to be executed, via L1 functions.

In monolithic, the sched_response mechanism ensures that FAPI messages
for one slot are not overwritten by scheduler instructions for the
following slots (i.e., it is like a memory allocation pool).

The allocation happens in nr_schedule_response(), not used by the PNF.
Hence, only deallocate when in monolithic.

The PNF uses a big ring buffer over all slots in a frame to ensure the
same.

FAPI sends those independently, so we cannot treat both on the arrival
of the first one.

If nothing is to be sent, nothing is to be done.

This function applied an sf_ahead, bigger than the actual slot
indication message sending (so a message could NEVER arrive on time!).
Reduce to zero, because this is when it should arrive for us.

FAPI says these lists should be for MAX_TDD_PERIODICITY (which is maybe
a frame, or a TDD period? but likely not two frames). Reduce to one
frame.

Also, the nFAPI code assumes one entire frame, so use that (this commit
necessary to actually make the PNF work, otherwise, the
packing/unpacking of the FAPI message would need to do 2 frames).

Closes: #876

Some L1 functions might get a pointer to P7 structures, and use SIMD in
which case the memory access needs to be aligned.

Upon reception of FAPI UL messages (e.g., RACH.indication), those
messages are put into queues, to be delivered in a single call,
NR_UL_indication(). Call the scheduler to trigger processing in UL.

Note that ideally, these queues should not exist at all, and messages
should just be delivered asynchronously, as this would lead to less
copying of messages. Currently, we fulfill the scheduler interface
instead.

Important! Trigger UL after having run DL scheduler and sent the
messages, to ensure short delay between Slot.indication, and the
response to those messages.

The previous designs seems to do:

    loop {
      poll_ind_queue()
      if (msg)
        scheduler;

      pselect() on messages;
      handle_message {
        if slot_ind
          put_ind_queue()
      }
    }

So basically, we artificially put a queue for slot indications in the
middle, but still handle it in the same thread(!). This for some reason
results in a big slow down if the PNF runs faster.

Now, we just do pselect(), waiting for messages. We handle the slot
indication immediately (the schedule should take some microseconds),
then return to pselect().

Use this function to implement distinct behavior for monolithic or PNF:

- monolithic: run the scheduler, as normal
- PNF: send a slot indication; the VNF will send an answer which the PNF
  will handle elsewhere.

Add function declarations to make nr_ulsim compile, as NR_IF_Module.c is
part of the MAC sources. As of now, this is necessary; I think the right
way would be to take NR_IF_Module.c out of the MAC, and make this a
"glue" library that sticks L1 and L2 together, in monolithic (in VNF, in
that case, we should not link in L1, and for the PNF not the L2,
creating separate executables... Rome was not built in one day).

the slot indication is sent from the tx_thread (tx_func()). Thus, we
don't need to send it a second time.

There is a reference counting mechanism used in monolithic. It does not
apply for the PNF.

The VNF should never call into the L1, it's L2/L3, by definition. Also,
it's not necessary.

We are required to store multiple PUCCH (e.g., for multiple UEs).
However, nr_fill_pucch() automatically freed the previously active PUCCH
structure. Of course(!) this does not make sense.

However, the problem is that init_nr_transport() allocated only one
PUCCH structure. Also this does not make sense to me. The problem was
that slot_ahead was 0, which logically cannot happen in this function
(because slot_ahead is illogical, we must give the radio some time). The
reason is that it uses if_inst->sl_ahead, which, prior to this commit,
was not set.

The init_nr_transport() function is called normally from main() through
init_eNB_afterRU(). In this case, we initialize if_inst->sl_ahead to
what is set in main(). In the PNF case, however, we call
init_nr_transport() from the PNF thread, when receiving the start
request. In the main(), we wait for this to happen, before setting
if_inst->sl_ahead. Hence, initializing this variable (which we should
safely be able to do) before solves the problem.

See also a later commit "Allow to use multiple PUCCH at once", in which
PUCCH handling in the case of PNF is reworked.

We might squash both commits.

Assign NFAPI_NR_CONFIG_SLOT_CONFIG_TAG tag in TLVs used for transmitting the TDD Slot configuration through CONFIG.request.

sync_var is set in main() (which likely is wrong in that the L1 code
sync itself, and not require the help of main()).

The radio gives the clock. Therefore, we do not need to keep the time
separately in the PNF.

Also, the VNF should not run the ru_thread, as this is an L1 thread.

This is to align with monolithic/FAPI, where we get slot indications in
each slot. In the nFAPI, this is replaced by timing information, such
that the VNF ticks automatically, and gets indications from the PNF on
early/late messages. The timing information handling is not implemented
in the present nFAPI implementation. Instead, we adopt the FAPI behavior
and send timing information in every slot, abusing it to be a slot
indication.

There is no need to add the PNF in nr_start_resp_cb(), because it has
already been done in nr_param_resp_cb(). This might be wrong, because 4G
does it only in nr_start_resp_cb(), but for the moment, since it is also
used in nr_param_resp_cb(), avoid the double add.

The same function is called in nr_start_resp_cb(), why there and not here?

At reception of nr_param_response, we receive the remote PNF information
on PNF/VNF. We have to store it.

In nr_start_response, it might not be correct and/or can be taken out.
The next commit will remove it.

maybe take this out

Maybe cosmetic

harmonize with monolithic

Now uses RC.nb_nr_L1_inst instead of RC.nb_nr_inst in order to configure the L1, since in PNF RC.nb_nr_inst is always 0, and so, it wouldn't configure the L1

Rename configs according to name guidelines. Put into right directory.