This function packs P7 messages. At least RX_data.indication messages
might be much bigger than the global buffer that is used here. Allocate
the buffer on the stack, and make it bigger. Do not use the global
buffer, it's simply not necessary; increasing the global tx buffer size
might have negative effects elsewhere in the code.

That change might make the function reentrant. The mutex seems to only
guards the codec config. However, leave it to not introduce any
regressions as of now.

Modify the existing 4x4 60MHz USRP+COTS UE test to use nFAPI. The
throughput tests remain the same.

Similar to the parent commit, make the numerology in the VNF
configurable. Unlike for the PNF change, the VNF frame/slot info is in a
per-PNF connection structure to which the "oai_integration" code has no
access. So we need to hack the nfapi_vnf_p7_add_pnf() function signature
to take the numerology, to be able to save this on a per-PNF basis.

The fact that we store this on a per-PNF basis is not strictly required,
as the VNF cannot handle multiple numerologies as of now, either.
However, we might want to extend this in the future, so it seems prudent
to store this on a per-PNF basis, so that we could start handling
multiple numerologies at the L2 without the need to change the L1 or
nFAPI code itself.

Also, the numerology is not needed except for some code that deals with
timing over nFAPI. As of now, we don't use this code (nFAPI gets a
trigger every slot, as per the VNF request, see an earlier commit in
this series), but also here, let's not make the future more complicated
by storing the numerology for each PNF now (this could always be reverted).

For 4G, put numerology 0 (15kHZ SCS), which is the SCS that LTE uses.

Fill in the dynamically received numerology, and make the numerology at
the PNF configurable, following the changes in the parent commit.

The change for the reading is somewhat of a hack, because nFAPI, as of
now, does not really foresee to store the numerology, so we fill the
numerology during the start request, when the numerlogy has been
received in the config request, but at that time, the structure for the
time information (frame/slot) does not exist yet.

At both the PNF and the VNF, introduce a separate numerology field, and
pass the numerology when converting time information using macros from
nfapi_interface.h. The actually numerology is still hardcoded to 1 (as it
was before), but the follow-up commits will put a suitable numerology.

In both cases, but the numerology next to the frame/slot information.

Similarly as the parent commit(s):
- remove hardcoding to specific numerology
- avoid conversion when we don't need it

Similar as the parent comment, remove time macros. In this particular
case, we can just pass the exact frame/slot information, instead of
squeezing it in a single integer.

The next commits will modify the time macros used in the 5G nFAPI code
to handle different numerologies. As a preparation, remove all the
usages of these macros where they really don't matter (e.g., don't
convert if we don't need to).

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.