Add undocumented Aerial ERROR.indication vendor specific error codes
This MR adds the remaining vendor-specific ERROR.indication error codes
that are undocumented in the Aerial online documentation, but are
present in the cuPHY-CP/scfl2adapter/lib/scf_5g_fapi/scf_5g_fapi.h
header file.
This change stems from the appearance of an undocumented error code
during testing (SCF_ERROR_CODE_L1_MISSING_UL_IQ = 0x44) It aims to ease
the comprehension of the errors thrown by Aerial L1.
Integration `2026.w06`
* !3690 [FHI72] Support large DU delay profiles in the xran F, and include ProtO-RU emulator designed to run 7.2 with an USRP
* !3887 Update RHEL UBI image source to `registry.redhat.io`
* !3882 Change Aerial to pack directly in nvIPC message buffer
* !3895 CI: Ensure OAI-FLEXRIC-RAN-Integration-Test pipeline always uses latest commit for non-MR builds
* !3873 Ensure noise power is non-zero
* !3889 Enable imscope for split7.2
* !3801 Resolve "7.2 split ru_thread slot miss
* !3898 Fix config_libconfig_get for string
* !3876 Removing the duplicate loop in ULSCH power computation
Closes#972
See merge request oai/openairinterface5g!3888
Removing the duplicate loop in ULSCH power computation
- Removing the duplicate loop in ULSCH power computation.
- The logs obtained are as follows:
[NR_MAC] UE dc65: 134.11 Generating RA-Msg2 DCI, RA RNTI 0x113, state 1, preamble_index(RAPID) 42, timing_offset = 5 (estimated distance 195.3 [m])
[PHY] PUSCH not detected in 134.17 (307,302,50)
[PHY] PUSCH not detected in 134.17 (311,309,50)
[NR_MAC] 135 4: RA RNTI 41c5 CC_id 0 Scheduling retransmission of Msg3 in (135,8)
[NR_MAC] 135 4: RA RNTI a3cc CC_id 0 Scheduling retransmission of Msg3 in (135,8)
[PHY] PUSCH not detected in 134.18 (310,312,50)
[NR_MAC] 135 5: RA RNTI dc65 CC_id 0 Scheduling retransmission of Msg3 in (135,9)
[PHY] PUSCH not detected in 135.8 (309,309,50)
[PHY] PUSCH not detected in 135.8 (313,308,50)
[NR_MAC] 13515: RA RNTI 41c5 CC_id 0 Scheduling retransmission of Msg3 in (135,19)
[NR_MAC] 13515: RA RNTI a3cc CC_id 0 Scheduling retransmission of Msg3 in (135,19)
[PHY] PUSCH not detected in 135.9 (308,300,50)
[NR_MAC] 136 4: RA RNTI dc65 CC_id 0 Scheduling retransmission of Msg3 in (136,8)
[NR_PHY] [RAPROC] 135.19 Initiating RA procedure with preamble 6, energy 19.1 dB (I0 63, thres 120), delay 4 start symbol 0 freq index 0
[PHY] PUSCH not detected in 135.19 (310,310,50)
[PHY] PUSCH not detected in 135.19 (312,310,50)
[NR_MAC] 135.19 UE RA-RNTI 010b TC-RNTI 0888: initiating RA procedure
[NR_MAC] UE 0888: Sync beam index 0
[NR_MAC] UE 0888: Msg3 scheduled at 136.17 (136.10 TDA 2) start 0 RBs 8
[NR_MAC] UE 0888: 136.10 Generating RA-Msg2 DCI, RA RNTI 0x10b, state 1, preamble_index(RAPID) 6, timing_offset = 4 (estimated distance 156.3 [m])
- For the same scenario, develop branch gives exactly the same result. When
there is no PUSCH, the power measured for ULSCH and noise are practically
the same. Furthermore, the value in develop branch is also approximately
310 for the same noise level.
Add xran_queue_length atomic variable to count the number of messages in
oran_sync_fifo (as notifiedFIFO_t does not do this). Use this to
tolerate some double messages (e.g. excessive processing delay), but
start to skip if messages accumulate.
Prior to this change, "Detected double sync message" was printed each
time there was more than one message, which reflected the previous
behavior when using polling, but the gNB might catch up if it is only
once. The new logic ensure that we don't skip individual slots but do so
once messages start to accumulate.
Ensure noise power is non-zero
Prior to this commit, noise power estimation could be zero because of a
call to clearArray() in gNB_I0_measurements(). This is problematic, as
this can lead to a noise power of 0 if all symbols in a RB are used,
which in turn leads to a spike in SNR.
To avoid this, use an intermediate array to store noise power, and only
update n0_subband_power if not all RBs are used (i.e., we can detect
noise power). Further, use an exponential moving average to smoothen
noise estimation.
Fixes: fb4235fd ("changes in PUCCH0 SNR measurement, testing for
PUCCH power control")
Prior to this commit, noise power estimation could be zero because of a
call to clearArray() in gNB_I0_measurements(). This is problematic, as
this can lead to a noise power of 0 if all symbols in a RB are used,
which in turn leads to a spike in SNR.
To avoid this, use an intermediate array to store noise power, and only
update n0_subband_power if not all RBs are used (i.e., we can detect
noise power). Further, use an exponential moving average to smoothen
noise estimation.
Fixes: fb4235fd50 ("changes in PUCCH0 SNR measurement, testing for
PUCCH power control")
CI: Ensure OAI-FLEXRIC-RAN-Integration-Test pipeline always uses latest commit for non-MR builds
Related MR -> mosaic5g/flexric!77
For push events, we have:
sh "git fetch"
sh "git checkout -f ${commitID}"
We need to do a reset hard so that the run is executed on synchronized
develop branch.
In the pipeline, we see:
17:38:34 + git checkout -f develop
17:38:34 Previous HEAD position was 9cb79027e4 Merge branch 'integration_2026_w05' into 'develop'
17:38:34 Switched to branch 'develop'
17:38:34 Your branch is behind 'origin/develop' by 526 commits, and can be fast-forwarded.
17:38:34 (use "git pull" to update your local branch)
After implementing the fix:
Below are the runs for pipeline triggered by a merge request event:
https://jenkins-oai.eurecom.fr/job/OAI-FLEXRIC/229/https://jenkins-oai.eurecom.fr/job/OAI-FLEXRIC-RAN-Integration-Test/3788/
In the OAI-FLEXRIC-RAN-Integration-Test pipeline, which is executed by
Build with Parameters from OAI-FLEXRIC
We see the pipeline took the latest develop:
11:26:02 + git reset --hard origin/develop
11:26:02 HEAD is now at 9cb79027e4 Merge branch 'integration_2026_w05' into 'develop'
Change Aerial to pack directly in nvIPC message buffer
This MR changes the Aerial pack/send procedures to pack the messages
directly into the nvIPC message buffers.
This saves the use of some memcopy calls, as well as clean up the code.
The P7 message packing/send is now only handled in the file
`fapi_nv_p7.c`
Add 3 functions in fapi_nvIPC.c to allow message allocation, release and
send from fapi_vnf_p7.c
Add 2 functions to access the memory pool sizes allocated from nvIPC, as
we can't use sizeof to report the buffer size to the packing functions
Remove now unused aerial_send_P5_msg , aerial_send_P7_msg and
aerial_send_P7_msg_with_data functions
Now Aerial only has one function to handle sending P5 and another to
send P7 messages
Remove fapi_phy_api_msg from fapi_nvIPC.h as it is duplicated in
nr_fapi.h
Update RHEL UBI image source to registry.redhat.io
This merge request updates the RHEL UBI base image source to registry.redhat.io,
aligning with Red Hat’s supported container registry and avoiding potential
access or availability issues with registry.access.redhat.com.
[FHI72] Support large DU delay profiles in the xran F, and include ProtO-RU
emulator designed to run 7.2 with an USRP
This MR does the following:
- we patch xRAN to support large DU delay profiles (i.e., T1a/Ta4 values larger
than a TTI)
- we update the FHI72 docs to introduce ProtO-RU, a software implementation of a
Split-7.2 O-RU with large delay profile
- we provide an example configuration for ProtO-RU
Details on the xRAN patch:
In xRAN, it appears that T1a/Ta4 values are assumed to be within a TTI. When
T1a/Ta4 values larger than a TTI are used, this causes two issues:
(1) C-plane packets to be generated later than expected, and
(2) oai_xran_fh_rx_callback() receives the wrong timing information, resulting
in potentially empty/stale PUSCH/PRACH data to be read.
In the xRAN patch, we modify xRAN to make it handle large T1a/Ta4 values properly.
The changes include:
(1) three additional variables in offset_num_slots_* (xran_dev.h),
(2) modify "xran_timing_create_cbs" and "xran_timer_arm_for_deadline"
(xran_cb_proc.c), and
(3) revise "tx_cp_dl_cb" and "tx_cp_ul_cb" (xran_main.c).
Additionally, we add additional guard conditions to prevent xran_tx_proc.c from
sending U-plane packets when it is not a downlink slot.
In xRAN, it appears that T1a/Ta4 values are assumed to be within a TTI.
When T1a/Ta4 values with larger than a TTI are used, this causes two issues: (1) C-plane packets to be generated later than expected and (2) oai_xran_fh_rx_callback() receives the wrong timing information resulting in potentially empty/stale PUSCH/PRACH data to be read.
In this patch, we modify xRAN to make it handle large T1a/Ta4 values properly.
The changes include: (1) three additional variables in offset_num_slots_* (xran_dev.h), (2) modify "xran_timing_create_cbs" and "xran_timer_arm_for_deadline" (xran_cb_proc.c), and (3) revise "tx_cp_dl_cb" and "tx_cp_ul_cb" (xran_main.c).
Additionally, we add additional guard conditions to prevent xran_tx_proc.c from sending U-plane packets when it is not a downlink slot.
Integration `2026.w05`
* !3850 Update vrtsim timing job thread
* !3853 Clear memory in shm_td_iq_channel after RX
* !3823 Fix RSRP overflow
* !3766 UE support to send CSI report on PUSCH
* !3848 Initial implementation of O-RU for 7.2 emulator
* !3860 NGAP: improve error handling in RRCReconfiguration from Handover Command decoding
* !3507 Create Debian and Redhat packages with CPack
* !3875 Fix FFT size for xran_fh_tx_send_slot_BySymbol() and xran_fh_rx_read_slot_BySymbol()
* !3593 NR UE: add support for multiple RF frontends
* !3769 Add Ethernet PDU session support and make PDU session request configurable
* !3831 semi-manual remove of not used #define commands
* Update RFsim4G UE configs for RFsim changes after !3593
* !3821 [FHI72] [xran F] Handle fragmented (un)compressed packets
* !3732 Implement TS 38.473 transparency for CellGroupConfig forwarding and handle re-establishment on a different DU
* !3880 Prevent the PNF from sending P7 messages after sending a STOP.indication
* !3868 CI: Upgrade Aerial pipeline to 25-3
* Revert one CI XML change after !3732Closes#1045, #837, and #1043
See merge request oai/openairinterface5g!3877
The CI test proved not as stable as expected (because the UE triggers A3
events which we don't want), so revert this functionality while we work
on a new pipeline.
This reverts commit bc62e8abca.
Prevent the PNF from sending P7 messages after sending a STOP.indication
Upon stopping the PNF, when sending the STOP.indication to the VNF, set
pnf_p7->terminate to 1.
Add a check on the PNF P7 send functions to not send a message after
pnf_p7->terminate is set.
This prevents the PNF from sending SLOT.indications after stopping,
which sometimes was causing the VNF to process a SLOT.indication after
it had received the indication to STOP.
Also, this MR adds a sanity check on the VNF P7 message handler to
ignore any P7 messages it receives after having it's own terminate flag
set to 1
This MR closes issue #1045
[FHI72] [xran F] Handle fragmented (un)compressed packets
In both E and F, the radio-transport fragmentation is not supported, and
all the "fragmented" (not seen as fragments in the xran, only as
sections) packets contain "E-bit" equal to 1. Per spec, the value 1 for
"E-bit" signifies the last fragment of one symbol. For more info, please
see "ecpriSeqid" section in the spec.
In E:
- nRBStart and nRBSize is updated according to the sent/received packet;
- max sections = 1;
- when a packet is fragmented, the xran uses memcpy(pos, iq_data_start,
size) function, and nothing is stored in start_prbu , num_prbu ,...
In F:
- nRBStart and nRBSize is only used for C-plane messages;
- nPrbElm represents the number of sections for DL only;
- based on the nPrbElm, each section contains UP_nRBStart and UP_nRBSize
parameters which represent the start and number of PRBs in one section
or one fragment;
- when a packet is fragmented, the xran uses nSecDesc and sec_desc to
extract the packet section content, and the data is stored in
start_prbu , num_prbu ,...
Previous work on the fragmentation in F:
- #884
- !3394 - only increases the XRAN_MAX_FRAGMENT from 4 to 6, since it was
only tested with BFP 8, but not end-to-end unfortunately. But this MR
fixes all the issues.
Tested with VVDN RU, 2x2, 16 bits, 100MHz, 30kHz, MTU <= 9216 B, and
Quectel UE RM520N-GL Revision: RM520NGLAAR03A03M4G.
Implement TS 38.473 transparency for CellGroupConfig forwarding and handle re-establishment on a different DU
This MR implements the following fixes that are relevant in RRC
procedures (e.g. re-establishment, reconfiguration):
1. Transparent CellGroupConfig forwarding
This MR implements TS 38.473 transparency requirements by ensuring that
the CellGroupConfig IE is transparently forwarded from the gNB-DU to the
UE without any re-encoding at the gNB-CU. The CU stores and forwards the
encoded bytes transparently, while the DU is responsible for all
encoding and modifications (e.g., reestablishRLC flags). Motivation
Motivation: The 3GPP TS 38.473 specification mandates that the
CellGroupConfig IE shall be transparently signaled to the UE.
Previously, the CU was re-encoding CellGroupConfig depending on the
scenario, instead of retrieving it from the DU, violating the
transparency requirement. CU may decode for internal use but must not
re-encode for forwarding. Solution
Solution: Core Principle: The CU stores the encoded CellGroupConfig
bytes received from the DU and forwards them directly to the UE without
any re-encoding. The DU handles all encoding and modifications.
Key Changes:
1. Transparent Forwarding in RRC Reconfiguration
- Modified build_RRCReconfiguration_IEs() to use pre-encoded bytes
directly
- Changed parameter from cell_group_config to cgc (encoded byte
array with buffer and size)
2. Encoded Bytes Storage
- Added byte_array_t mcg field to RRC UE structure to store encoded
CellGroupConfig
- Added store_cgc() helper function to save encoded cell group in
the RRC UE Context at gNB (from F1AP messages)
3. DU Encoding Responsibilities
- Add gNB-DU Configuration Query IE support to trigger cgc encoding
to request CellGroupConfig from DU
- DU encodes CellGroupConfig with proper reestablishRLC flags
during re-establishment
- DU removes SRB1 from rlc-BearerToAddModList during
re-establishment (SRB1 re-establishment is done before
RRCReconfiguration)
4. New functions
- Add rrc_detect_reestablishment() function to detect
re-establishment during UE Context Modification
- Extracted rrc_gNB_first_reconfiguration_after_reestablishment()
function to handle first reconfiguration after re-establishment
- Added dump_cgc() and dump_mcg() utility functions for debugging
purposes
5. Re-establishment Flow
- rrc_gNB_process_RRCReestablishmentComplete() requests
CellGroupConfig from DU via gNB_DU_Configuration_Query in UE
Context Modification Request
- DU detects re-establishment and add reestablishRLC IEs
- CU stores encoded CGC from the UE Context Modification Response
and forwards it transparently in subsequent RRC Reconfiguration
Testing
Manual Testing:
- RRC re-establishment procedure completes successfully
- RRC Reconfiguration after re-establishment includes all DU-provided information
Issues fixed
Closes issue #837
2. Trigger UE Context Setup fallback upon reestablishment on DU
different from the original one
As per 38.401 §8.7: if the UE accesses a DU different from the original
one during re-establishment, the CU must trigger UE Context Setup toward
the new DU. This refers to steps 9-10 and steps 9’-10’. Either one or
the other can be executed during re-establishment.
e.g. if this happens during handover, it shall trigger a UE Context
Setup fallback on the CU.
This MR implements the required behavior by:
- Adding a new helper function rrc_handle_f1_ho_reestab_on_target() to
handle F1 handover reestablishment on target DU. The function triggers
UE Context Setup procedure when the UE reestablishes on the target DU
during an ongoing F1 handover.
- Calling this function when detecting that the UE is reestablishing on
the target DU during handover, i.e.: (1) from
handle_rrcReestablishmentComplete(), as per 38.401 §8.7, NOTE on steps
9-10: CU gets UL RRC MESSAGE TRANSFER from a DU different than the
original (2) from rrc_CU_process_ue_modification_required, as per
38.401 §8.7, NOTE on steps 9'-10': CU gets a UE CONTEXT MODIFICATION
REQUIRED from a DU different from the original one.
Also:
- add helper rrc_fill_f1_ue_context_setup and adopt it in handover
- move DRB list filler fill_drb_to_be_setup into rrc_gNB.c and rename it
rrc_fill_f1_drb_to_setup for consistency
See also TS 38.401 Figure 8.7-1 "RRC connection reestablishment
procedure" for reference
3. DU: Handle missing old UE context in DL RRC Message Transfer
During F1 handover reestablishment, the CU may forward a DL RRC Message
Transfer to the target DU with old_gNB_DU_ue_id included, even though
the target DU does not have the old UE context yet.
The code previously used AssertFatal when the old UE context was not
found, causing a crash: "CU claims we should know UE %04x, but we don't"
According to TS 38.473, the gNB-DU shall release the old gNB-DU UE F1AP ID only:
> if the gNB-DU identifies the UE-associated logical F1-connection If
> there is no matching connection, there is nothing to release.
Fix:
- Check if old UE context exists before accessing it
- If old UE does not exist, log error, clean up any stale F1 UE data,
and return early (do not deliver RRC message since reestablishment
can't be completed)
The goal is to address a recurrent issue in the F1 pipeline, see
jenkins-oai.eurecom.fr/job/RAN-SA-Handover-CN5G/514:
Assertion (oldUE) failed!
In dl_rrc_message_transfer() /oai-ran/openair2/LAYER2/NR_MAC_gNB/mac_rrc_dl_handler.c:956
CU claims we should know UE 35ce, but we don't
The sufficient number of fragments needed for MTU 1500 and 8b compression is 6.
However, XRAN_MAX_FRAGMENT must be incremented by one (6+1 = 7).
In the MR https://gitlab.eurecom.fr/oai/openairinterface5g/-/merge_requests/3394, XRAN_MAX_FRAGMENT was increased to 6,
but the Tx data was actually copied 5 times, and unfortunately I haven't tested end-to-end back then.
This commit was successfully tested with Liteon FR1.
Robert Schmidt