This file is 8y old. It does not seem to serve any purpose. Remove it.

the L1 needs both a PDU (in TX_data.req) as well instructions for
the actual transmission (in DL_TTI.req) to encode a PDSCH message. In
nFAPI, it can happen that a DL_TTI.request message has been received
(configuring the PDSCH transmission), without the TX_data.request having
reached the PNF. The L1 assumes to have the PDU.

To avoid problems, ensure that only the pair of DL_TTI.req/TX_data.req
is delivered. Otherwise, drop either message.

nFAPI has a mechanism to segment messages that are too big for transport
over a given medium (see e.g. SCF 225, section 2.3.2).

The maximum segment size of 10000 makes that for larger payloads, e.g.
TX_data.request, many small segments are to be sent. This can create or
increase delays on the transport. On the other hand, the currently only
available transport mechanism, UDP, allows to transport packets of up to
almost 65535 bytes. Correspondingly, increase the maximum segment size
so that less segments are to be created, and potentially, less delay is
to be incurred.  # Please enter the commit message for your changes.
Lines starting

Same as parent.
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>

Same as parent.
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>

Same as parent commit.
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>

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.