remove specific directory for LTE SIM management tools
This is very old code has never been integrated with the "main" OAI
cmake infrastructure and more recent libraries.
This MR integrates the three binaries for LTE virtual sim management in
the regular build process and log system
Remove the --usim-test option: to my knowledge, it's not used by users,
and is misleadingly placed in various places where there should not be a
difference w.r.t. USIM configuration.
When making the changes, I assumed that --usim-test would be 0 (the
default), which is the case in all executables when not specified in
options except for the nr_dlsim, nr_pbchsmi, nr_ulsim simulators.
The only exception is the initialization of PDCP from the MAC, which is
not correct (the PDCP is in the CU, so it does not make sense to call it
from the MAC which is in the DU). Instead, always initialize from main,
even in the NSA case (NSA was covered by the incorrect initialization
from MAC).
This in turn let to some more cleanup around function du_rlc_data_req().
After receiving GTP packets at the DU, they were given to the PDCP to
enqueue the packet at RLC. This does not work anymore, since the PDCP is
not initialized; it also does not seem necessary, as this enqueue
functionality is necessary to decouple PDCP and RLC to avoid deadlocks
in monolithic, but in split-mode, this cannot happen. Instead, call
directly into the RLC when receiving GTP packets.
Measurement gaps
Scheduling measurement gaps to provide sufficient time for the UE to
re-tune its transceiver to the target carrier, complete the set of
measurements and then re-tune its transceiver back to the original
carrier.
Add WLS as a transport option for VNF/PNF, refactor existing options
This MR adds a new transport mechanism for the VNF and PNF split, using
the Intel WLS library, which makes use of DPDK and shared memory to
transport messages. This transport mechanism is what is used to
interface with Radisys ODU, while also working with OAI VNF/PNF.
The VNF and PNF have been refactored so that the transport-specific
functions are isolated from the rest of the logic, and as such,
interchangeable by means of function pointers.
The same change is done for the packing/unpacking procedures, allowing
to switch between FAPI and nFAPI encoding.
This MR also reduces the amount of duplicated code, by refactoring the
VNF with Aerial, which now only has the transport-relevant functions, as
well as the ones that are unique to it ( for example, the unpacking
procedures where a secondary data buffer is used for the message
payloads )
Additionally a new callback is added to the VNF to process
ERROR.indication messages, which currently only indicates which message
originated the error, and which error occurred.
The changes done in this commit are to contribute the supporting changes
for the existing "Initial support for RedCap" feature in gNB.
In this patch, handle and store the RedCap related IE's present in "NR
UE Capability Information" msg which are
- 'supportOfRedCap-r17'
- 'supportOf16DRB-RedCap-r17'
- 'longSN-RedCap-r17'
- 'am-WithLongSN-RedCap-r17'
use 'longSN-RedCap-r17' and 'am-WithLongSN-RedCap-r17' IEs to set the SN
length to either 12 Bit or 18 Bit accordingly.
Previously, we only supported intra-frequency handovers, so the
measurements where only for intra-frequency, reusing the same
measurement object. Now that we would support inter-frequency handover,
also add multiple MeasObjects for each neighbor.
bugfix: UE AMBR is optional
This was a problem with open5gs and more than one PDU session. The core network
sets UE AMBR only once, leading to failure in the gNB for the second PDU session.
(A proper handling of AMBR has to be develop at some point in the gNB.)
This was a problem with open5gs and more than one PDU session.
The core network sets UE AMBR only once, leading to failure in the gNB
for the second PDU session.
(A proper handling of AMBR has to be develop at some point in the gNB.)
continuously update SIB19 information for rfsim NTN LEO scenarios
Contains mainly these changes:
- gNB: add function nr_update_sib19() allowing to update SIB19
information
- rfsimulator: update SIB19 contents every frame for LEO channel
simulations
- NR UE: improve initial timing advance calculation from SIB19
Before, we only considered ta_Common_r17 and the SAT position from SIB19
to compute the initial timing advance value. This is good enough if the
satellite does not move too fast (e.g. GEO satellite).
Now we also consider ta_CommonDrift_r17, ta_CommonDriftVariant_r17 and
the SAT velocity together with the epoch time from SIB19. This improves
the accuracy of the initial TA computation, esp. for LEO satellite
scenarios.
Various fixes for UE handling, HO doc updates
- On release request, search both attach and connected list to free a UE.
- on DU disconnect, only release the correspnonding UE contexts.
- When no AMF for the UE, auto-release the UE (NGAP would also send an
answer, but better check first)
- implement a "grace period" before the DU/MAC automatically releases a
UE: this is to avoid cases in which (for whatever reason) the UE
release request is not honored by the CU. In order to not fill up UE
contexts unnecessarily, the DU will eventually (after 10s) drop the UE
context
- some clarification in HO tutorial
Mark non-existing AMF UE NGAP ID through invalid INT64_MAX number
(permitted range is up to 2^40-1). Check for this range in the RAN
function, as we might otherwise pass the invalid AMF UE NGAP ID to the
agent, which would assert with
nr-softmodem: /oai-ran/openair2/E2AP/flexric/src/lib/3gpp/enc/enc_gnb.c:83: enc_gNB_UE_asn: Assertion `gnb->amf_ue_ngap_id < 1UL << 40' failed.
In other words, don't send KPM messages for a UE which has no valid AMF
UE NGAP ID yet (which follows from the fact that the spec requires an
AMF UE NGAP ID; the previous behavior of simply sending 0 could be
considered a bug, because it's not the UE's true AMF UE NGAP ID).
NR RRC Reject UE
Improvements in procedures to handle RRCReject message both at gNB and
UE. At gNB we send RRC Reject if the UE cannot be given resources to go
into connected mode.
Direct leak of 512 byte(s) in 1 object(s) allocated from:
#0 0x7f37634e5e2b in realloc.part.0 (/lib64/libasan.so.8+0xe5e2b) (BuildId: 7f1aa7e2e600e8c9d54ce6e3d36f3d31bfe7949a)
#1 0x000000fbb9ad in encode_dyn_cb /home/richie/w/f1-refactor-ue-context/build/openair2/RRC/LTE/MESSAGES/per_encoder.c:23
#2 0x000000fc279e in asn_put_few_bits /home/richie/w/f1-refactor-ue-context/build/openair2/RRC/LTE/MESSAGES/asn_bit_data.c:220
#3 0x000000fc279e in asn_put_few_bits /home/richie/w/f1-refactor-ue-context/build/openair2/RRC/LTE/MESSAGES/asn_bit_data.c:192
#4 0x000000fc2ce5 in asn_put_many_bits /home/richie/w/f1-refactor-ue-context/build/openair2/RRC/LTE/MESSAGES/asn_bit_data.c:293
#5 0x000000fb8c33 in OCTET_STRING_encode_uper /home/richie/w/f1-refactor-ue-context/build/openair2/RRC/LTE/MESSAGES/OCTET_STRING_uper.c:306
#6 0x000000fd191a in SEQUENCE_encode_uper /home/richie/w/f1-refactor-ue-context/build/openair2/RRC/LTE/MESSAGES/constr_SEQUENCE_uper.c:403
#7 0x000000fd191a in SEQUENCE_encode_uper /home/richie/w/f1-refactor-ue-context/build/openair2/RRC/LTE/MESSAGES/constr_SEQUENCE_uper.c:403
#8 0x000000fcb140 in CHOICE_encode_uper /home/richie/w/f1-refactor-ue-context/build/openair2/RRC/LTE/MESSAGES/constr_CHOICE_uper.c:177
#9 0x000000fd191a in SEQUENCE_encode_uper /home/richie/w/f1-refactor-ue-context/build/openair2/RRC/LTE/MESSAGES/constr_SEQUENCE_uper.c:403
#10 0x000000fcb140 in CHOICE_encode_uper /home/richie/w/f1-refactor-ue-context/build/openair2/RRC/LTE/MESSAGES/constr_CHOICE_uper.c:177
#11 0x000000fcb140 in CHOICE_encode_uper /home/richie/w/f1-refactor-ue-context/build/openair2/RRC/LTE/MESSAGES/constr_CHOICE_uper.c:177
#12 0x000000fd191a in SEQUENCE_encode_uper /home/richie/w/f1-refactor-ue-context/build/openair2/RRC/LTE/MESSAGES/constr_SEQUENCE_uper.c:403
#13 0x000000fbc1ed in uper_encode /home/richie/w/f1-refactor-ue-context/build/openair2/RRC/LTE/MESSAGES/uper_encoder.c:27
#14 0x000000fbc73a in uper_encode_to_new_buffer /home/richie/w/f1-refactor-ue-context/build/openair2/RRC/LTE/MESSAGES/uper_encoder.c:85
#15 0x000000e10fbd in do_RRCReconfiguration /home/richie/w/f1-refactor-ue-context/openair2/RRC/NR/MESSAGES/asn1_msg.c:586
#16 0x000000805712 in rrc_gNB_encode_RRCReconfiguration /home/richie/w/f1-refactor-ue-context/openair2/RRC/NR/rrc_gNB.c:652
#17 0x000000893860 in nr_rrc_f1_ho_acknowledge /home/richie/w/f1-refactor-ue-context/openair2/RRC/NR/rrc_gNB_mobility.c:280
#18 0x0000008079ac in rrc_CU_process_ue_context_setup_response /home/richie/w/f1-refactor-ue-context/openair2/RRC/NR/rrc_gNB.c:2139
#19 0x0000008330d8 in rrc_gnb_task /home/richie/w/f1-refactor-ue-context/openair2/RRC/NR/rrc_gNB.c:2771
#20 0x7f3763428ee5 in asan_thread_start(void*) (/lib64/libasan.so.8+0x28ee5) (BuildId: 7f1aa7e2e600e8c9d54ce6e3d36f3d31bfe7949a)
During refactoring, I had asan errors in the next line. It took me some
time to figure out that a DRB ID 0 is not valid (cf.
get_next_available_drb_id() and get_drb(), they enforce this).
Direct leak of 48 byte(s) in 1 object(s) allocated from:
#0 0x7fea71ee6f0b in malloc (/lib64/libasan.so.8+0xe6f0b) (BuildId: 7f1aa7e2e600e8c9d54ce6e3d36f3d31bfe7949a)
#1 0x0000007f29c0 in malloc_or_fail /home/richie/w/f1-refactor-ue-context/common/utils/utils.h:86
#2 0x0000007f29c0 in cuup_notify_reestablishment /home/richie/w/f1-refactor-ue-context/openair2/RRC/NR/rrc_gNB.c:872
#3 0x000000808002 in rrc_CU_process_ue_context_setup_response /home/richie/w/f1-refactor-ue-context/openair2/RRC/NR/rrc_gNB.c:2126
#4 0x0000008330d8 in rrc_gnb_task /home/richie/w/f1-refactor-ue-context/openair2/RRC/NR/rrc_gNB.c:2770
#5 0x7fea71e28ee5 in asan_thread_start(void*) (/lib64/libasan.so.8+0x28ee5) (BuildId: 7f1aa7e2e600e8c9d54ce6e3d36f3d31bfe7949a)
Direct leak of 32 byte(s) in 1 object(s) allocated from:
#0 0x7f672d6e5e2b in realloc.part.0 (/lib64/libasan.so.8+0xe5e2b) (BuildId: 7f1aa7e2e600e8c9d54ce6e3d36f3d31bfe7949a)
#1 0x000000fbb4ed in encode_dyn_cb /home/richie/w/f1-refactor-ue-context/build/openair2/RRC/LTE/MESSAGES/per_encoder.c:23
#2 0x000000fbbeeb in _uper_encode_flush_outp /home/richie/w/f1-refactor-ue-context/build/openair2/RRC/LTE/MESSAGES/uper_encoder.c:126
#3 0x000000fbbeeb in uper_encode /home/richie/w/f1-refactor-ue-context/build/openair2/RRC/LTE/MESSAGES/uper_encoder.c:36
#4 0x000000fbc27a in uper_encode_to_new_buffer /home/richie/w/f1-refactor-ue-context/build/openair2/RRC/LTE/MESSAGES/uper_encoder.c:85
#5 0x00000081037c in handle_ueCapabilityInformation /home/richie/w/f1-refactor-ue-context/openair2/RRC/NR/rrc_gNB.c:1549
#6 0x000000813ced in rrc_gNB_decode_dcch /home/richie/w/f1-refactor-ue-context/openair2/RRC/NR/rrc_gNB.c:1902
#7 0x0000008334f2 in rrc_gnb_task /home/richie/w/f1-refactor-ue-context/openair2/RRC/NR/rrc_gNB.c:2741
#8 0x7f672d628ee5 in asan_thread_start(void*) (/lib64/libasan.so.8+0x28ee5) (BuildId: 7f1aa7e2e600e8c9d54ce6e3d36f3d31bfe7949a)
Move the filling of DRBs to set up for UE context setup/modification
request into the corresponding functions, and use malloc() deliberately
to avoid memory leaks. In fact fill_drb_to_be_setup_from_e1_resp()
allocates memory dynamically (and has to do that), so the easiest is to
do the same for DRBs. The most straight-forward way seems to be to then
dynamically allocate all memory for F1 UE context setup/modification
request messages, and free with the corresponding free functions,
which removes a couple of memory leaks.
Similarly to the commit "Use F1 UE context setup/modif Request in
stack", we do both UE context setup/modification response at once
because of some functions that are shared by the MAC message handler.
Use the new, tested F1 UE context setup request and modification
requests in the stack.
We have to do both at once, because there are some functions that are
used by handlers for both messages, notably
- handle_ue_context_drbs_setup()
- handle_ue_context_srbs_setup()
(+ and some functions called by those two). For instance, the first uses
the (new/old) type f1ap_drb_to_be_setup_t/f1ap_drb_to_setup_t which is
shared. The alternative would be to duplicate the functionality
temporarily, and I want to avoid unnecessary code churn.
The previous condition was wrong: if a UE did not have the assoc_id of
the DU that connected (i.e., it was connected to another DU then the one
disconnecting), it was marked for deletion. Instead, skip those UEs.
Adds 3 new function pointers to the P5 and P7 PNF structures, allowing to configure which function to use to pack/unpack the messages, as well as unpack the message header, being then used seamlessly regardless of using the FAPI or nFAPI functions.
Changes the header unpack and message unpack functions to return true on success and false on failure, instead of an int
Cleanup PDU Session Handling in RRC/NGAP
Currently, NGAP and RRC share the same structures and responsibilities when
handling PDU Session information: this creates tight coupling, redundancy, and
makes the code harder to maintain.
- NGAP should be responsible only for: Protocol-specific encoding/decoding
(3GPP TS 38.413)
- RRC should own: PDU Session handling and storage in the UE context
This MR is the first step in a broader refactoring of the PDU Session handling
code across NGAP and RRC layers, with the goal of splitting responsibilities
cleanly between both modules.
- Unified gtpu_tunnel_t for tunnel endpoint config (formerly f1u_tunnel_t)
- Refactored and relocated PDU Session struct definitions for better separation
between NGAP and RRC
- Moved pdusession_t for PDU Session handling out of NGAP, now defined and
managed by RRC only
- Defined 3GPP TS 38.413 message-specific structs in NGAP module
- NGAP now decodes NGAP PDU Session Resource Setup/Modify IEs and transfers
decoded data to RRC via ITTI
- Add helper functions to copy from NGAP message to pdusession_t
- Introduced new encoders/decoders/helpers in NGAP for handling PDU Session
Resource Setup/Modify procedures (e.g. decode_pdusession_transfer)
- Migrated to NGAP and removed duplicated logic for QoS information decoding
(fill_qos)
- Improved logging of GTP tunnel info
- Merged redundant functions (f1u_dl_gtp_update and f1u_ul_gtp_update)
- Removed unused code and obsolete types
- do free_func in seq_arr_erase_it on the provided range and updated unit test
- Other fixes and simplifications (e.g. simplified and clarified naming of
tunnel/session parameters and structs)
This cleanup improves code readability, has a high code churn (the deletions are
~159.7% of the insertions) and prepares for better modularity before the
refactoring of PDU Session handling in RRC/NGAP.
Enabling usage of ulsyncvalidityDuration timer in SIB19
ntn-UlSyncValidityDuration in SIB19 from Spec 38.331 v17.12 A validity
duration configured by the network for assistance information which
indicates the maximum time duration (from epochTime) during which the UE
can apply assistance information without having acquired new assistance
information. The unit of ntn-UlSyncValidityDuration is second. Value s5
corresponds to 5 s, value s10 indicate 10 s and so on.
ntn-UlSyncValidityDuration-r17 ENUMERATED{ s5, s10, s15, s20, s25, s30, s35,s40, s45, s50, s55, s60, s120, s180, s240, s900}
Implementation of epochtime is under discussion.
It can be configured in configuration file according to the above
enumeration. For GEO - 240s, MEO - 20s, LEO-5s can be used.
Robert Schmidt