The HO is completed (from a pure RAN perspective) when receiving
reconfiguration complete. In that case, remove the HO context, and
signal successful handover through the callback. For the F1 handover,
this means releasing the UE at the source DU.
Co-authored-by: batuhanduyuler <batuhan.duyuler@firecell.io>
Co-authored-by: rmagueta <rmagueta@allbesmart.pt>
We expect the UE's RRC Reconfiguration Complete to come through the
target DU, as the "new UE" at the target CU. Also, function
CU_handle_UL_RRC_MESSAGE_TRANSFER() checks that the UL RRC Message,
through which we will receive RRC Reconfiguration Complete, matches the
DU UE ID stored in RRC. Since the DU UE ID will be the one at the target
DU, while up to now, we stored the DU UE ID at the source DU.
Correspondingly, update the DU UE ID to the one at the target DU; also
update the corresponding assoc_id.
Co-authored-by: batuhanduyuler <batuhan.duyuler@firecell.io>
Co-authored-by: rmagueta <rmagueta@allbesmart.pt>
In this commit, handle the reception of a UE context setup response, in
the case of handover. In that case, store the gNB-DU UE ID and C-RNTI of
the UE at the target DU, and trigger a reconfiguration towards the UE at
the source DU via the callback.
To ensure that the CU-UP's PDCP is SN-aligned with the UE, use
cuup_notify_reestablishment() to reset the bearers with PDCP
reestablishment, which has already been implemented in the last commit.
Co-authored-by: batuhanduyuler <batuhan.duyuler@firecell.io>
Co-authored-by: rmagueta <rmagueta@allbesmart.pt>
This is preparatory work to handle the UE context setup response from
the target DU. There are two cases:
- "Initial" UE context setup response (during connection setup): we need
to inform the CU-UP via an E1 message of the new bearers (GTP tunnel
update)
- F1 handover: we need to inform the CU-UP via an E1 message that there
are DRBs to reestablish
There are two different functions, e1_send_bearer_updates() and
cuup_notify_reestablishment(), to do this. Harmonize the code, before
implementing the actual handover logic in the next commit.
Add a function to trigger an F1 handover, including the corresponding
telnet function implementation. The function looks up source&target DU,
creates a HO context, and reads PDU information to send a UE context
setup request to the target DU towards which to handover.
Co-authored-by: batuhanduyuler <batuhan.duyuler@firecell.io>
Co-authored-by: rmagueta <rmagueta@allbesmart.pt>
Functions get_qos_char_from_qos_flow_param() and
get_qos_characteristics() will be used in rrc_gNB_mobility.c to read PDU
information for handover. Move the definitions to a header to reuse
later.
HandoverPreparationInformation will be used in the follow-up commit to
trigger a handover.
Co-authored-by: batuhanduyuler <batuhan.duyuler@firecell.io>
Co-authored-by: rmagueta <rmagueta@allbesmart.pt>
This F1 message sends us the CellGroupConfig of the UE. Store it in case
we need it. For instance, at least in OAI, it is possible to make a
handover without a DRB (this might or might not be standard compliant).
However, in this case, we did never receive a UE context setup request,
which stores the CellGroupConfig. Hence, store the first CellGroupConfig
we receive, to be able to do e.g., handover.
RETURN_IF_INVALID_ASSOC_ID() checks if an assoc_id (of a DU) is valid.
It will be also used in the mobility RRC module later. Move it to the DU
header (where it logically belongs) to move it from there.
Prior to this commit, after RA failure, the DU would send a UE context
release complete, without actually requesting one. This could lead to
inconsistent state between DU and CU, because the CU might just discard
this (unrequested) message, and not actually trigger a release [1].
Thus, refactor the release request into a function, and use it to
request release of a UE for which RA has not been completed. If the CU
does not know the UE, release the UE immediately.
[1] One possibility would be that during reestablishment, the CU would
request to look up an old DU UE ID when it has been released, resulting
in
Assertion (oldUE) failed!
In dl_rrc_message_transfer() /home/oaicicd/robert/openairinterface5g/openair2/LAYER2/NR_MAC_gNB/mac_rrc_dl_handler.c:860
CU claims we should know UE bc7f, but we don't
After RA, in the case of HO, we need to make sure to use the right radio
configuration (MCS table, etc). This commit is important to make HO
actually work.
Our initial CellGroupConfig always contains LCID1, because in normal
connection setup, the DU has to automatically set it up anyway. In
handover/UE Context Setup, the CU requests to set up SRB1 (which we
assume to be LCID1), but we reuse the initial CellGroupConfig. To not
have SRB1 added twice, skip in this case.
This commit implements adding a new UE on the target DU in case of
handover. We identify this case by the fact that the gNB-CU did not send
a gNB-DU UE ID (which is optional in F1AP, but not in our
implementation), such that we know there is no corresponding UE, which
therefore has to be created.
If it happens that there is a handover preparation information, we read
the UE capabilities from this information, and subsequently trigger the
creation of a new UE.
Another change is that for all bearers that we are asked to setup, we
add reestablishRLC so that the UE does a reestablishment during the
reconfiguration.
As we have to remove the reconfigurationWithSync and reestablishRLC IE
after application of the CellGroupConfig (because we might reuse the
CellGroupConfig later), free these IEs. As there are now multiple fields
to free, introduce a separate nr_mac_clean_cellgroup() function that
handles cleaning of the CellGroupConfig.
Co-authored-by: batuhanduyuler <batuhan.duyuler@firecell.io>
Co-authored-by: rmagueta <rmagueta@allbesmart.pt>
The next commit will modify the UE context setup request procedure to
(possibly) receive UE capabilities through Handover Preparation
Information, which extracts the UE capabilities for the UE to be setup.
To avoid code duplication, extract the code that will be needed in UE
capability extraction from Handover Preparation Information.
Implement the Transmission Action Indicator F1AP forwarding logic, and
add it to the F1 internal representation structure. After the
transmission interrupt timer (during which SRB1 can send messages), the
UE will be out-of-sync (we assume it's not there anymore).
Co-authored-by: batuhanduyuler <batuhan.duyuler@firecell.io>
Co-authored-by: rmagueta <rmagueta@allbesmart.pt>
Implement the HandoverPreparationInformation F1AP forwarding logic, and
add it to the F1 internal representation structure.
No logic is implemented in this commit.
Co-authored-by: batuhanduyuler <batuhan.duyuler@firecell.io>
Co-authored-by: rmagueta <rmagueta@allbesmart.pt>
Refactor the RRC processing timer to be a generic "transmission
interrupt" timer, and use NR_timer_t for it. Also,
depending on the kind of RRC processing (see 38.331 table 12.1-1),
timing requirements might be different. However, the DU does not always
know which RRC processing is ongoing, and does not get this information
via F1. Hence, introduce a "worst case" delay time, which aligns with
the spec (it says these times are "minima") and is accepted by COTS UE.
The gNB MAC might need to stop transmission either for some time (RRC
processing), or continuously (transmission stop requested by CU). Those
can be handled in one common timer implementation. The continuous case
will be used in a follow-up commit.
Co-authored-by: Luis Pereira <lpereira@allbesmart.pt>
pyflakes warns about various errors, addressed here. For cls_cluster.py,
remove (unknown) sys.exit and replace through Exception, as sys.exit()
has the unwanted effect that the CI script would stop. Instead, raise
an Exception that would show the problem in the HTML, and ensures that
the script runs until the end.
These are the warnings flagged by pyflakes.
cls_cluster.py:297:4: undefined name 'sys'
cls_containerize.py:39:1: 'subprocess' imported but unused
cls_containerize.py:41:1: 'threading' imported but unused
cls_containerize.py:43:1: 'multiprocessing.Process' imported but unused
cls_containerize.py:43:1: 'multiprocessing.Lock' imported but unused
cls_containerize.py:43:1: 'multiprocessing.SimpleQueue' imported but unused
cls_containerize.py:49:1: 'cls_cluster as OC' imported but unused
cls_containerize.py:50:1: redefinition of unused 'cls_cmd' from line 42
cls_module.py:28:1: 'os' imported but unused
cls_module.py:29:1: 'sys' imported but unused
cls_module.py:34:1: 'subprocess' imported but unused
cls_module.py:35:1: 'datetime.datetime' imported but unused
cls_module.py:211:11: undefined name 'sshconnection'
cls_oaicitest.py:37:1: 'pexpect' imported but unused
cls_oaicitest.py:47:1: 'cls_cluster as OC' imported but unused
cls_oaicitest.py:54:1: 'matplotlib.pyplot as plt' imported but unused
cls_oaicitest.py:55:1: 'numpy as np' imported but unused
cls_oai_html.py:34:1: 'sys' imported but unused
cls_oai_html.py:41:1: 'multiprocessing.Process' imported but unused
cls_oai_html.py:41:1: 'multiprocessing.Lock' imported but unused
cls_oai_html.py:41:1: 'multiprocessing.SimpleQueue' imported but unused
cls_physim.py:37:1: 'multiprocessing.SimpleQueue' imported but unused
cls_static_code_analysis.py:39:1: 'time' imported but unused
cls_static_code_analysis.py:40:1: 'multiprocessing.Process' imported but unused
cls_static_code_analysis.py:40:1: 'multiprocessing.Lock' imported but unused
cls_static_code_analysis.py:40:1: 'multiprocessing.SimpleQueue' imported but unused
epc.py:41:1: 'multiprocessing.Process' imported but unused
epc.py:41:1: 'multiprocessing.Lock' imported but unused
epc.py:41:1: 'multiprocessing.SimpleQueue' imported but unused
main.py:60:1: 'pexpect' imported but unused
main.py:66:1: 'datetime' imported but unused
main.py:68:1: redefinition of unused 'subprocess' from line 63
main.py:70:1: 'multiprocessing.Process' imported but unused
main.py:70:1: 'multiprocessing.Lock' imported but unused
main.py:70:1: 'multiprocessing.SimpleQueue' imported but unused
provideUniqueImageTag.py:2:1: 'os' imported but unused
When running, nr_psbchsim, we get this UBsan error:
openair1/PHY/NR_UE_ESTIMATION/nr_adjust_synch_ue.c:79:16: runtime error: member access within misaligned address 0x0ff4278c791c for type 'struct nrUE_params_t', which requires 8 byte alignment
The problem is that the corresponding definition of
get_nrUE_params() in psbchsim.c does not actually return the UE params,
but void, so we might or might not get something that resembles valid
data in nr_adjust_synch_ue.c. Fix this by including nr-uesoftmodem.h
(that provides the correct declaration) and define it correctly. Due to
type mismatches, also adapt downlink_frequency, uplink_frequency_offset,
and openair_cfg (which might result in the same type of bugs).
This adds DTX detection in PUCCH 2 receiver. This is detected by MAC
already which will drop PUCCH 2 indications that are detected as DTX.
For the moment this uses the same pucch0_dtx_threshold value indicated
in L1 section of the configuration file. The feature firstly reduces
unnecessary logging on stdout and the use of invalid CSI measurements in
the MAC scheduler.
Closes: #547
- Fixes#853, #854, #858, #859, #862
- handle repeated NGAP Initial context setup requests, thereby fixing assert:
Assertion (!ue_p->as_security_active) failed!
In rrc_gNB_generate_SecurityModeCommand() /home/eurecom/raymond/openairinterface5g/openair2/RRC/NR/rrc_gNB.c:2590
logic error: security already activ
- A lot of cleanup: remove almost all use of protocol_ctxt_t in 5G RRC and use
existing pointers instead
Introduce two tests for NR RLC AM entity:
- test_nr_rlc_am_entity
- benchmark_nr_rlc_am_entity
The benchmark can be used to verify processing time improvements for NR RLC AM
entity. The benchmark creates two entities and creates an unbalanced
communication channel between them with 10% loss packet loss and 100:1 PDU sent
ratio. This allows the lists in RLC to build up and triggers RLC AM code
related to looking through the segment/pdu lists.
Example benchmark output:
ubuntu@zeus:~/bpodrygajlo/openairinterface5g/cmake_targets/build$ ./openair2/LAYER2/nr_rlc/tests/benchmark_nr_rlc_am_entity
[LOG] init aborted, configuration couldn't be performed
log init done
CMDLINE: "./openair2/LAYER2/nr_rlc/tests/benchmark_nr_rlc_am_entity"
[CONFIG] debug flags: 0x00400000
2024-10-16T14:58:20+02:00
Running ./openair2/LAYER2/nr_rlc/tests/benchmark_nr_rlc_am_entity
Run on (8 X 4700 MHz CPU s)
CPU Caches:
L1 Data 48 KiB (x4)
L1 Instruction 32 KiB (x4)
L2 Unified 1280 KiB (x4)
L3 Unified 12288 KiB (x1)
Load Average: 0.48, 0.27, 0.20
***WARNING*** CPU scaling is enabled, the benchmark real time measurements may be noisy and will incur extra overhead.
--------------------------------------------------------------------
Benchmark Time CPU Iterations
--------------------------------------------------------------------
BM_nr_rlc_am_entity/100 50096 ns 50097 ns 13101
BM_nr_rlc_am_entity/256 140386 ns 140387 ns 4868
BM_nr_rlc_am_entity/1024 536323 ns 536311 ns 1309
BM_nr_rlc_am_entity/4096 2084464 ns 2084385 ns 338
BM_nr_rlc_am_entity/16384 8309318 ns 8309458 ns 81
BM_nr_rlc_am_entity/20000 9843792 ns 9843774 ns 68
- Update links for the latest Ubuntu 24.04 LTS iso file
- Update docker install to the latest instructions on the official website
- Update UHD to v4.7.0.0 and update dependencies for Ubuntu 24.04
Test configuration: Tested SIB19 reception on SCS120 Khz + 50Mhz bw
config file used:
targets/PROJECTS/GENERIC-NR-5GC/CONF/gnb.sa.band257.u3.32prb.usrpx410.conf
+ NTN config commands used
sudo ./nr-softmodem -O ../../../targets/PROJECTS/GENERIC-NR-5GC/CONF/gnb.sa.band257.u3.32prb.usrpx410.conf --sa --rfsim -d
sudo ./nr-uesoftmodem --band 261 -C 27533280000 -r 32 --numerology 3 --ssb 72 --sa --rfsim -d --ue-scan-carrier
The Issue is that SIB19 is not being received because of CRC error, only
SIB1 was being received.
This changes the way T_IDs are defined. The T_ID macro was using a
integer to pointer cast in order to provide type safety. This trick
disables some compiler optimizations, as explained here:
https://clang.llvm.org/extra/clang-tidy/checks/performance/no-int-to-ptr.html.
Removing the type cast reenables the compiler optimizations.
This MR aims to address warnings raised when compiling for ARM ( tested
with cross compilation, not directly on ARM hardware ). The addressed
warnings are as follows:
- An unused variable in file oai_dfts_neon.c
- Wrong printf format specifier related to oai_cputime_t
- Wrong parameter type in qam64_qam64 call
This MR closes issue #844
Also, correctly set the pkg-config search path for libraries for the
target system. Also closes: #746
A UE might send a ULInformationTransfer without the actual content present
(intentionally or not). Check this and handle appropriately to avoid
a segfault when reading the empty NAS message.
Closes: #862
Pass UE context pointer directly. In the switch, do not return to not
create memory leaks (after the switch, memory is freed). Move the
function up to make it appear before the use of the function.
Pass UE context, without protocol_ctxt_t, for cleanup. Remove the return
from within the switch, as this would lead to memory leaks; nothing is
executed after the switch statement (except for freeing memory).
The existing check for the initialization of GTP is wrong; GTP returns
-1 if it could not initialize. Correct this, such that the DU will stop
if GTP cannot be initialize.
If we continue, the DU is requested to set up a GTP tunnel; because GTP
is not initialized, it assumes it is in monolithic/no F1, and does not
set up a tunnel. The F1 UE Context setup response encoder then fails
with this assertion:
Assertion (tnl->teid > 0) failed!
In DU_send_UE_CONTEXT_SETUP_RESPONSE() ../../../openair2/F1AP/f1ap_du_ue_context_management.c:415
Exiting execution
../../../openair2/F1AP/f1ap_du_ue_context_management.c:415 DU_send_UE_CONTEXT_SETUP_RESPONSE() Exiting OAI softmodem: _Assert_Exit_
Aborted
Closes: #853
A UE might send a MeasurementReport without the actual IEs present
(intentionally or not). Check this and handle appropriately to avoid
assertion
Assertion (measurementReport->criticalExtensions.present == NR_MeasurementReport__criticalExtensions_PR_measurementReport && measurementReport->criticalExtensions.choice.measurementReport != ((void*)0)) failed!
In rrc_gNB_process_MeasurementReport() ../../../openair2/RRC/NR/rrc_gNB.c
Closes: #859
A UE might send a UE Capability Information without unsolicitatedly
(intentionally or not). Check this and handle appropriately to avoid
assertion
Assertion (UE->xids[xid] == RRC_UECAPABILITY_ENQUIRY) failed!
In handle_ueCapabilityInformation() ../../../openair2/RRC/NR/rrc_gNB.c
Closes: #858
A UE might send a rrcReestablishmentComplete without the actual IEs
present (intentionally or not). Check this and handle appropriately to
avoid assertion
Assertion (reestablishment_complete->criticalExtensions.present == NR_RRCReestablishmentComplete__criticalExtensions_PR_rrcReestablishmentComplete) failed!
In handle_rrcReestablishmentComplete() ../../../openair2/RRC/NR/rrc_gNB.c:1364
Closes: #854
Prior to this commit, if we receive an Initial Context Setup Request for
a UE that has AS security set up, the gNB asserts with
Assertion (!ue_p->as_security_active) failed!
In rrc_gNB_generate_SecurityModeCommand() openairinterface5g/openair2/RRC/NR/rrc_gNB.c:2590
logic error: security already activ
However, TS 38.413 says:
> The AMF may initiate the Initial Context Setup procedure if a
> UE-associated logical NG-connection exists for the UE
(I interpret this as "it might happen anytime")
> store the received Security Key in the UE context and, if the NG-RAN
> node is required to activate security for the UE, take this security key
> into use.
(I interpret this as "do not set up AS security again")
In this commit, handle if we receive an Initial Context Setup Request
for an existing UE context. As said in the spec, we store the keys. If
security is not active, we trigger RRC Security Mode Command. If it is
active, we skip Security, and directly set up a PDU session. If there is
also no PDU session, we simply forward the NAS message, and acknowledge.
If there was no AS security, after security, the gNB would trigger the
setup of PDU sessions (if any), and then forward any NAS PDUs, which is
stated in the if block if AS security is already active.
Prior to this commit, the include path for some libraries found through
pkg-config when cross compiling is not correct:
$ grep include CMakeCache.txt
blas_INCLUDEDIR:INTERNAL=/usr/include/x86_64-linux-gnu
...
This is because we did not tell pkg-config to search in the right path.
Since for cross-compilation, we install packages in parallel in the
system, override the primary directory where the .pc files located, in
the cross-compilation toolchain file for cmake.
Closes: #746
rrc_gNB_process_security() does not only set (process) the security
algorithms, but also checks for those. However, we don't use the check.
Simplify the function, to reintroduce the check later. Rename to
set_UE_security_algos() to better reflect what the functions do.
Resolve error:
nfapi/oai_integration/aerial/fapi_nvIPC.h:56:16: error: unknown type name ‘nvipc_params_t’
56 | int nvIPC_Init(nvipc_params_t nvipc_params_s);
By including the header. Also, move the definiton of the struct to the
MAC, where it is actually stored, and out of the radio common_lib.h,
since this is not a radio (split 7/8) parameter.
When compiling aerial, we compile without CUDA support (see e.g.,
docker/Dockerfile.gNB.aerial.ubuntu22). Hence, do not check for it in
aerial for the moment, we won't use it for the foreseeable future.
In Aerial bindings (FAPI-Aerial), the NFAPI mode must be
NFAPI_MODE_AERIAL (otherwise, we would not be executing this code).
Hence, the switches don't make sense. Remove them.
The check can more easily be checked with
git show <commit> --ignore-all-space
As is visible at the top of the patch, for compiling aerial_lib (the
binding FAPI-Aerial), we always add ENABLE_AERIAL. Thus, all the code
within ENABLE_AERIAL will be compiled; we can also simply take it out.
We can directly read from buffers, so the memcpy() only takes time.
Also, limit the scope of the variables for the unpacking of
RX_DATA.indication.
Co-authored-by: Rúben Soares Silva <rsilva@allbesmart.pt>
These functions look up the numerology, and code can be harmonized:
- ssb_index_from_prach()
- find_SSB_and_RO_available()
- schedule_nr_prach()
The next commits also need to look up the numerology from the
UplinkConfigCommon. This provides the common implementation to be used
in follow-up commits.
