Avoid delays in tx_data.request handling by avoiding big malloc()s and
copy operations. Reimplement function to (1) peek the frame/slot
numbers, (2) decide on buffer, and (3) unpack directly into
pre-allocated memory.
Co-authored-by: hsum <ming-hong.hsu@eurecom.fr>
Co-authored-by: chenyi <Yi-Quan.Chen@eurecom.fr>
Co-authored-by: Rúben Soares Silva <rsilva@allbesmart.pt>

Some messages might arrive for the wrong slot; in those cases, the
message has to be dropped. The next commits will make use of this
functionality.

The next commits refactor the rx handling of messages in the PNF. To
efficiently handle them, provide a "peek()" function that gives us the
frame/slot for which a message is destined. This allows to decide if a
message is on time and select a destination buffer, before unpacking it
completely, avoiding copies.

The time that a message between PNF/VNF to arrive depends mostly on the
transport. To allow for some delays, there is a slot_ahead time, during
which the VNF is allowed to schedule and send instructions to the PNF.

This can be multiple slots; the 1ms hitherto given might typically too
short. Increase to 10ms, to encompass a wider range of slot_ahead times.

Make the corresponding log message of when old (stale) message are
removed a bit clearer with respect to times.

This is the first commit in which nFAPI works. Follow-up commits improve
performance.

The usage of this flag in the L1 is simply wrong: either, the NFAPI mode
runs L1, or not. Correspondingly, add an assert to check this invariant.

In the NR_IF_module, the correct check to do is for VNF (implying no L1,
or "emulation of L1" [which is not true]), in which case we use
queues.

The L1 receives a pointer to the L1 payload to use for PDSCH generation.
This would overwrite an existing pre-allocated pointer. Remove this
preallocation. Instead, allocate it in the simulator (the only place
that actively uses this buffer allocation; in nr-softmodem, it's lost by
assigning a pointer). Allocate with an extra byte, because the payload
(in bits) might not be a multiple of 8 bits/1 byte, so the CRC is in the
last 3 bytes.

Also, improve the log with frame/slot information if the PDSCH payload
pointer is NULL.

The function now utilizes simpler variable names and logic to determine
if a given NR P7 request falls within the timing window.

The logic for determining if a request is within the timing window is as follows:
- The function calculates the absolute difference between the current
  and received SFN slots, taking into account the possibility of
  wraparound.
- If the absolute difference is greater than half of the maximum SFN
  slot value, it subtracts this difference from the maximum SFN slot
  value to get the actual difference.
- The function then checks if this difference is less than or equal to
  the specified timing window. If it is, the request is considered to be
  within the window.

Additionally, the commit updates the function signature to return a
boolean value for better readability and consistency.

Changes made:
- Simplified variable names for readability
- Improved logic for handling wraparound scenarios
- Updated function signature to return a boolean value
Co-authored-by: Rúben Soares Silva <rsilva@allbesmart.pt>

Since commit defc97ec ("Msg2 and Msg3 at gNB: check allocation before
committing to Msg2"), the scheduler calculate Msg2/Msg3 frame/slot
before allocation of Msg2, and not when receiving Msg1. It also respects
the RA response window correctly.

Correspondingly, we don't need to calculate here if the RACH.indication
is within the time window. The scheduler will do this.

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()).