Integration: `2025.w08`
Closes#772
See merge request oai/openairinterface5g!3273
* !3263 Free ITTI message after receiving it at MAC from RRC
* !3268 Upgrade SIMDe commit
* !3269 chore(ci): change image rentention from 4weeks to 3weeks
* !3227 fix(nrLDPC_coding): timers in DL encoding, fix(ldpctest): Confusion in sizes
* !3270 Update of gNB-N300-Timing-Phytest threshold
* !3272 Fix: write NSSAI info of F1AP Cell Info struct
* !3259 UE DCI no candidates
* !3264 Fix "Received Nack" log for Msg4/MsgB and minor improvement in RA logs
* !3228 Add option to use global noise power for all RX channels in RFSimulator
* !2725 Use 5G-S-TMSI as UE identity in RRCSetupRequest
During refactoring, the previously implemented NSSAI field of the cell
info structure was not written to F1AP ASN.1 structures anymore;
eq_f1ap_cell_info() also conveniently omitted the corresponding equality
check. Add this back so the CU can correctly receive the NSSAI in case
of F1 split operation.
Fixes: f278b00837 ("Add encoding/decoding library for F1AP Setup
Request (Interface Management) ")
[E2 agent] Multi RC REPORT service styles support
Issue: unforeseen capability of having the same RAN Parameter ID across
different REPORT service styles.
Solution: keep only RAN Parameter IDs from REPORT styles that are
supported by OAI. Implement sequence array where each element is
combination of RIC request ID (unique per RIC SUBSCRIPTION) and Event
Trigger Definition. This way we can properly check further conditions
for a certain RAN Parameter ID. (e.g. if xApp is subscribed to RRC
Connected and/or other modes, for "RRC State Changed To" RAN Parameter
ID)
Next steps: for new RAN Parameter ID, add new sequence array.
FHI72: remove polling, fix memory leak
- FHI72 used polling to track the next slot. This is not necessary, a
simple queue does the job and allows to save one core that was
previously at 100%
- Remove a workaround to avoid a memory leak (fixes#812); allows to
also run RFsim/USRP/otehr radios when compiling for FHI72
fix NTN LEO scenarios
- gNB: add support for NTN parameter ta-CommonDrift-r17
- NR UE: fix application of NTN TA information
- NR UE: add command line parameter ntn-initial-time-drift to compensate
time drift during initial sync
- NR UE: fix writeTimestamp inconsistencies
- NR UE: add MAC state UE_RECEIVING_SIB ensuring to start RA only after
successfully receiving SIBs
- rfsimulator: update earth radius for LEO simulation to match UE
position in ue.conf file
- update conf files for NTN LEO scenario
- update description how to run NTN scenarios in RUNMODEM.md
- fix: ta-Common is a round-trip-time, not a one-way delay
- NR UE: simplify calculation of next_tx_slot_and_frame by moving up
assignment of duration_rx_to_tx
- cellbarredNTN indicates notbarred in SIB1 if NTN access is available
- Removed b66 NTN and enabled B254 NTN conf file in CI
- NR UE: RRC layer now explicitly tells MAC layer when the RA procedure
can be started
- move NTN LEO config to band 254 and update doc/RUNMODEM.md
Closes#901
Add check on force_local in custom_command CI handling
The force_local flag was introduced earlier in the main CI script in
order to run a CI test locally.
The flag was still missing in the Custom_Command handling, which was
still targeting the node specified in the test configuration file. This
was causing a failure in the tests with custom commands and therefore
limiting the scenarios that could be run locally.
With this commit, if force_local is enabled the node for the
Custom_Command is set to localhost.
Refactor and extend NAS Registration Request
Extended NAS Registration Request generation and encoding according to
8.2.6 of 3GPP TS 24.501. Main topics:
- NAS Registration Type
- NAS KSI
- integrity protection
- NAS container encoding
Improvements:
- Add 5GMM Modes in NAS
- Introduced 5GMM state machine
Fixes:
- add 5GMM Capability IE to Registration Request
- closes#881, #819
Dynamic PDCCH aggregation level
The aggregation level search order for PDCCH candidates is modified:
- the search starts from desired_agg_level_index, which is a value from
0 to 4 proportial to pdcch_cl_adjust.
- pdcch_cl_adjust is a value between 0 and 1 that indicates PDCCH
channel quality by averaging HARQ DTX rate. A value of 0 means perfect
channel, a value o 1 means impaired channel.
Also added configuration option for number of PDCCH candidates per
aggregation level.
first_rx_set is polling-specific: it makes the polling loop wait to only
check the frame/slot counter once we set it for the first time. However,
that is equivalent to checking the frame/slot directly, which will also
be 0 in the beginning.
first_read_set seems to have the function of making frame/slot time
advance only if we started to read the samples in
xran_fh_rx_read_slot(). I interpret that as "only advance the time if
the gNB is reading from xran", which does not make sense to me, because
xran advances the time anyway. Also, polling would not notice, and
no-polling would simply warn about double messages. So the outcome is
likely the same, whether first_read_set is set or not.
I checked in multiple CI runs; it happens that first_read_set is always
set already when oai_xran_fh_rx_callback() is called anyway.
xran_fh_rx_read_slot() uses polling (a loop over cnt++) to wait for the
next frame/slot. The reasons I have been told is "it does not work
differently", or "there are real-time problems". None of those seem to
be true; by default disable polling, and use the queue instead.
It is possible to enable polling with the cmake option
OAI_FHI72_USE_POLLING=ON. Documentation has been updated to inform about
this change.
The queue L1_rx_out was in place to keep RX/TX processing relatively
"close" to each other (in terms of time, since in RFsim, they might
advance faster than realtime; see also parent commit). This lead to a
memory leak in radios that do not use ru->feprx (no front-end processing
for RX, e.g., PRACH), as the code to read the L1_rx_out messages was
inside a block of if (ru->feprx). Move it out so that the queue is
always read and messages are freed to eliminate the memory leak, and
remove the workaround for FHI72 to avoid this memory leak.
This also allows to run RFsim when compiling FHI72, which was not
possible before this commit.
Closes: #812
Some radios (e.g., RFsim) can run faster. A mechanism has been put in
place to keep RX/TX frame/slot numbers not too far from each other.
Refactor in a separate function with documentation to make this clearer.
E1AP enc/dec lib improvements
This MR is including some fixes and improvements for the E1AP library,
focusing mostly on Bearer Context Management:
- struct reorganization: split setup and modification request messages
into distinct structures, ensuring compliance with 3GPP TS 38.463
specifications
- add encoding/decoding sub-functions for different IEs
- improvements to Bearer Context Management: Implemented various
improvements to the E1 Bearer Context Setup Response and Request,
including the adoption of encoding/decoding sub-functions for
different IEs
- use lib functions whenever need (e.g. cp_bearer_context_setup_request
in cucp_cuup_e1ap.c)
- handle optional struct members as pointers
- updated copy/equality check utility functions
EDIT: The MR is also including the changes from !3222 (closed):
> While testing E1 with security enabled for DRBs, it was found that
> data traffic was not functional.
>
> The problem was that security settings were modified in the PDCP
> reestablishment happening when receiving Bearer Context Modification
> Request.
>
> So some restructuring was done.
>
> The actual fix is in 18176297, the others are for support. Basically
> we introduce a boolean to check if the security settings are present in
> Bearer Context Modification Request and we change PDCP security settings
> only if they are.
>
> (Note that in OAI CU security settings are not sent in Bearer Context
> Modification Request, so we could also remove all this, but we need to
> be compatible with other cu-up and/or cu-cp.)
Added Support of 35Mhz,45Mhz,70Mhz Bandwidth
Added Support of 35Mhz,45Mhz,70Mhz Bandwidth for 30Khz Subcarrier
Spacing, Also added 35Mhz, 45Mhz bw for 15Khz Subcarrierspacing.
Referred Spec TS 38.101 v18.6.0 section 5.3.2, table 5.3.2-1
Reset E1 UE contexts after E1 Setup Response
38.463 sec. 8.2.3 says
> This procedure also re-initialises the E1AP UE-related contexts (if
> any) and erases all related signalling connections in the two nodes
> like a Reset procedure would do.
Hence, delete all contexts after reception of E1 Setup Response. This
minimizes a risk of receiving an E1 bearer setup req for an existing UE,
which currently leads to an assert [we trust the CU-CP does not send the
same UE ID twice, as we only "mirror" the existing UE ID]. After this
MR, this is what happens if these entities fail:
- CU-CP fails: all context lost implicitly, upon reconnection, both DU
and CU-UP reset all contexts (like "start from zero")
- DU fails: CU-CP triggers NGAP UE context release request immediately
(radio connection with UE lost), all UE contexts attached to this DU
cleared (like "start from zero" for affected DU)
- CU-UP fails: initially, nothing (UE has no user plane); upon
reconnection of CU-UP, CU-CP triggers NGAP UE context release request
(cause radio connection with UE lost) and sends F1 Reset to DU, all UE
contexts associated to this DU cleared (like "start from zero")
for the last case, a possible improvement could be to use the F1 Reset
message to only clear affected UE conetxts. I chose not to do this,
because this MR is very big now already, and possible "victim" UEs
that were not at that CU-UP will reconnect as well
As in deba3ae066 ("Reset CU-UP E1 UE contexts after E1 Setup
Response"), the CU-CP should reset the E1 UE contexts after E1 Setup
Response. 38.463 sec. 8.2.3 says
> This procedure also re-initialises the E1AP UE-related contexts (if
> any) and erases all related signalling connections in the two nodes like
> a Reset procedure would do.
In the case of CU-CP, this is a bit more complicated. More precisely, we
need to wait for the CU-UP to be available again before informing the DU
about the loss (implemented via an F1 Reset message), because otherwise,
the UE might reconnect immediately, before the CU-UP is online again.
Hence, on connection loss, we mark affected UEs (by setting their E1
association ID to 0); as long as the CU-UP does not connect, nothing
will happen (but UEs don't have user plane). Upon CU-UP connecting
again, we request release of the UEs via NGAP (similarly to what is done
if the DU goes offline, see invalidate_du_connections()), free the UE
contexts locally, and send an F1 Reset message to the DU, because
38.473 sec 8.2.1.2.1 says
> a failure at the gNB-CU [...] has resulted in the loss of some or
> all transaction reference information [...] a RESET message shall be
> sent to the gNB-DU.
The core should accept and send an NGAP release command message; since
no UE contexts are to be found (already deleted), the CU-CP will just
send a release complete (together with some warnings).
It might be possible to more gracefully handle the situation (e.g., as
described in 38.401 section 8.9.5 "Change of gNB-CU-UP"), but
- we lack the PDCP SN exchange
- the current procedure has the advantage of being equivalent to
"restart of the entire gNB", with less downtown.
The next commit will use rrc_remove_ue() to delete a CU(-CP+-UP)
context. However, we don't send NGAP UE context release at that moment
(we will instead *request* the release); more generally, it's not clear
that every user of rrc_remove_ue() wants to actually send this message.
Hence, refactor the code by separately calling
rrc_gNB_send_NGAP_UE_CONTEXT_RELEASE_COMPLETE() where appropriate.
nFAPI: make 4-layer on 100MHz work
5G nFAPI headers specify 32 bits for the length field, so use it also
when segmenting messages. This should stabilize 4-layer MIMO operation
on 100MHz with nFAPI.
Deadlock avoidance in rfsimulator
This change introduces a countermeasure for deadlock in rfsimulator. The
deadlock happens when all entities are waiting for new data to come in,
and happens with 2+ clients, when a new client connects. I think this
issue is due to ordering of fullwrite calls, resulting in out-of-order
delivery of packets and eventually trashing the packets on the receiving
side. The out-of-order delivery warnings are printed just before the
system deadlocks but I have not found a better solution so far. The
workaround makes the server never lock up permanently by ignoring the
client failure to write on time after 10 tries.
This was tested locally for both UE as server and gNB as server and
works correctly, causing the deadlock to clear and the added log to be
printed several times when the deadlock is detected, after which the
system goes back to normal.
I have some gdb output of the executables during deadlock:
UE:
$7 = {conn_sock = 98, lastReceivedTS = 3226163740, headerMode = true, trashingPacket = false, th = {size = 13184, nbAnt = 1, timestamp = 3226150556, option_value = 0, option_flag = 0}, transferPtr = 0x7f6a500018a8 "\200\063", remainToTransfer = 24,
circularBufEnd = 0x7f6a503b3ac0 "", circularBuf = 0x7f6a501f1ac0, channel_model = 0x0}
(gdb) p t->buf[5]
$8 = {conn_sock = 97, lastReceivedTS = 0, headerMode = true, trashingPacket = false, th = {size = 0, nbAnt = 0, timestamp = 0, option_value = 0, option_flag = 0}, transferPtr = 0x7f6a50001900 "", remainToTransfer = 24, circularBufEnd = 0x7f6a50575ad0 "",
circularBuf = 0x7f6a503b3ad0, channel_model = 0x0}
nextRxTimestamp 3225937740
nsamps = 30720
gNB 1:
(gdb) p t->buf[0]
$4 = {conn_sock = 95, lastReceivedTS = 3226026876, headerMode = true, trashingPacket = false, th = {size = 1, nbAnt = 1, timestamp = 3226026875, option_value = 0, option_flag = 0},
transferPtr = 0x7f8dfc003ab8 "\001", remainToTransfer = 24, circularBufEnd = 0x7f8e1c3ff010 "", circularBuf = 0x7f8e1c23d010, channel_model = 0x0}
nextRxTimestamp 3225996956
gNB 2:
lastReceivedTS = 3226026875
$2 = {conn_sock = 95, lastReceivedTS = 3226026875, headerMode = true, trashingPacket = false, th = {size = 1, nbAnt = 1, timestamp = 3226026875, option_value = 0, option_flag = 0},
transferPtr = 0x744898003ab8 "\001", remainToTransfer = 24, circularBufEnd = 0x7448bc2e7010 "", circularBuf = 0x7448bc125010, channel_model = 0x0}
nextRxTimestamp 3226026875
As you can see all executables are in have_to_wait state.
38.463 sec. 8.2.3 says
> This procedure also re-initialises the E1AP UE-related contexts (if
> any) and erases all related signalling connections in the two nodes like
> a Reset procedure would do.
Hence, delete all contexts after reception of E1 Setup Response. This
minimizes a risk of receiving an E1 bearer setup req for an existing UE,
which currently leads to an assert [we trust the CU-CP does not send the
same UE ID twice, as we only "mirror" the existing UE ID].
Make the same change as in parent commit, i.e., write the full 32-bit
segment size.
I could not test this, as we do not reach these rx_data.indication
length. It's based on the fix in the parent commit, and to avoid future
bad surprises.
The 5G nFAPI message length is 32bits. In particular tx_data.requests
can be longer than 64kB. When segmenting, we should correctly write the
message of the current segment (across all 32bits), because the
length would interpreted wrongly otherwise.
This fixes a bug in which tx_data.requests were discarded for 4-layer DL
MIMO on 100 MHz with this message:
P7 unpack message length is greater than the message buffer
Further, increase the type of various (segment-related) variables to 32
bits. Currently, the maximum segment size is sxt to 65000 bytes (and in
will likely remain, because the maximum UDP size is 65536);
nevertheless, increase it in case we will ever go beyond this.
See also commit dee68e6319 ("nFAPI: increase maximum segment size to
65000")
Simplify usage of the old segment decoding libraries with the slot coding interface
This MR transforms the segment coding libraries into slot coding
libraries by statically linking the adaptation layer and the segment
coding libraries.
Therefore they can be used directly in ldpctest which uses the segment
coding interface as well as in all the other PHY simulators and the NR
softmodem which use the slot coding interface.
It is not anymore needed to use the
--nrLDPC_coding_segment.segment_shlibversion
flag. Instead a segment coding library can be directly chosen with
--loader.ldpc.shlibversion
since it implements the slot coding interface.
Downgrade gNB power limit LOG from "warning" to "debug"
Downgrade the UE power limited LOG from LOG_W to LOG_D. This is to avoid
flooding stdout when UE in low coverage enters power limited state for a
longer period of time. The same information can be inferred from the
periodic UE print which also contains PH value (negative PH values
indicate that the UE is power limited)
Also, correct some typos in PH calculation.
Closes#885
Changes to support multiple TDD patterns
- Updated the configuration changes for 2 Patterns
- Update the TDD table configuration for NFAPI
- Added the tdd bitmap for the period
- Adapted the bitmap for UL/DL for the multi TDD pattern
- Updated the RACH procedure for multi TDD pattern
- Updated DL and UL scheduler for multi TDD pattern
Parametrized JenkinsNode and JenkinsResource
Parametrized variables in Jenkinsfile for automated tests on Colosseum
after update of OAI Jenkins server.
NAS 5GS refactor
The goal of this MR is to reorganize the NR NAS code into:
- enc/dec library functions (5GS, 5GMM, 5GSM, NR_NAS_defs.h,
nr_fgs_nas_lib.c)
- handlers and callbacks (nr_nas_msg.c)
The following changes are introduced:
1. migrate 5GS enc/dec lib (5GMM and 5GSM) to a dedicated folder
2. add a nested CMakeLists structure
3. refactor NR NAS enc/dec functions
4. refactor NR NAS messages struct definitions
5. remove most of dependency from NAS LTE
6. further refactor of PDU Session Establishment Accept processing to
separate enc/dec from handling
7. made naming of 5GS definitions consistent whenever necessary
8. cleanup unused code
9. remove redundant struct definitions
Also:
1. fix decoding of AMF Set ID in 5G-S-TMSI UE identity
2. replace Byte_t directly with uint8_t
FHI72: fix for a distributed antenna array for xran F release
in the Rx callback I reset the number of section descriptions/number of
fragments to 0, but for each antenna up to max number of antennas per
RU, instead of up to max number of distributed antenna array
Ensure execution of processSlotTX in order in NR UE
Make sure that processSlotTX is executed in slot order.
There is a bug that causes decoding error when processSlotTX is executed
out of order. The root cause is not known at this point, but this change
avoids the bug altogether.
Add IQ file recording and IQ file viewer to ImScope
This changeset introduces the following changes to ImScope:
- Added the ability to record IQ data using the same mechanism as
ImScope.
- Added a new executable target imscope_iq_file_viewer for viewing IQ
files.
- Introduced a command line argument --imscope-record that enables data
recording mode.
- Refactored a lot of the scope code
Usage:
- To record IQ data, run a modem with --imscope-record flag. The
recording happens whenever a modem calls dumpScopeData, which
currently is done only in gNB on PUSCH DTX and PUSCH CRC NOK. There
is a limit of ~1GB of files written by the thread in a signle run to
avoid accidentally exhausting disk space. If a directory imscope-dump
is available the data will be recorded there in .imscope files.
Otherwise files are written to the directory the modem was run. This
is done so that the directory can be mapped in a docker container.
- To view recorded IQ files, use the new executable
imscope_iq_file_viewer. This can be done by running:
./imscope_iq_file_viewer <path_to_iq_file>
Replace <path_to_iq_file> with the path to the IQ file you want to view.
Dockerized development environment
This commit introduces a fully dockerized dev env you can start on any
machine that has docker without installing any direct OAI dependencies
on host.
This allows to migrate development environments between machines easily.
Several complementary scripts were added to enable smooth transition
between your docker environment and host environment. Your user and sudo
should work inside the environment.
In its current state, the environment can be used to compile
nr-softmodem with 7.2 FHI but it cannot run it due to missing
dependencies.
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.
E1 Setup enc/dec library and unit test
This MR is adding a library for E1 Setup enc/dec functions:
- E1 CU-UP Setup Request
- E1 CU-UP Setup Response
- E1 Setup Failure
and relevant unit tests
F1AP IDs: Add update, fix concurrency bug
I suspect a concurrency bug: For instance, during reestablishment, the
CU needs to update the DU UE ID under which the UE is identified in the
DU. Previously, the CU would remove, then add the DU UE ID info. At the
same time, the PDCP thread might look up the information. This can lead
to asserts. Modify the code to do the update under (one) lock.
Also, refactor some code.
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.
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).
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
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>
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.
Since commit defc97ec16 ("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.
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>
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.
Robert Schmidt