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.
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.
Suspend RBs at UE
In case of suspended radio bearer (by RRC), the MAC needs to discarded received
PDUs and avoid to transmit using LCID related to that RB
SPEC 38.331 section 5.2.2.6
Inform MAC that UL SYNC got lost because of T430 expiry
- Send message NR_MAC_RRC_CONFIG_RESET with cause UL_SYNC_LOST_T430_EXPIRY to MAC
Reacquire SIB19 after T430 expiry
This is not checked in this commit
- RACH needs to be performed through probably PDCCH order to reobtain UL-SYNC
- system usecase involving Recovery from T430 expiry not tested yet as that requires changes on gNB side.
Spec 38.331 section 5.2.2.4.21 indicates this
1> start or restart T430 for serving cell with the timer value set to ntn-UlSyncValidityDuration for the serving cell
from the subframe indicated by epochTime for the serving cell;
NOTE: UE should attempt to re-acquire SIB19 before the end of the duration indicated by ntn-UlSyncValidityDuration and epochTime
Epochtime IE
When explicitly provided through SIB, or through dedicated signaling, the EpochTime is the starting time of a DL
sub-frame, indicated by a SFN and a sub-frame number signaled together with the assistance information.
For serving cell, the field sfn indicates the current SFN or the next upcoming SFN after the frame where the message indicating the epochTime is received.
This field is mandatory present when ntn-Config is provided in dedicated configuration.
gNB implementation related to epochtime will be done in a separate merge request.
NR UE fallback to RRCSetup from RRCReestablishment
Implementation of the procedure to handle reception of RRCSetup as response
to RRCReestablishment request
[E2 agent] E2AP README update and OAI-FlexRIC CI pipeline improvements
- E2AP README - add OSC nearRT-RIC section; update with proper FlexRIC
links, and explanations on prerequisites, as well as for xApps
- OAI-FlexRIC CI - use separate containers for xApps
- add reference files for CU-UP/CU-CP
- add logging for KPM NSSAI condition
Fix NR reestablishment by implementing the "DRB-suspend" at the MAC.
This means that the during reestablishment, gNB MAC discards received
DRB packets, and does not schedule DRB. Fix a couple of additional
issues in reestablishment. # Please enter a commit message to explain
why this merge is necessary,
For additional information, see
https://gitlab.eurecom.fr/oai/openairinterface5g/-/merge_requests/2668#note_119369
The spCellConfig is to be dropped during reestablishment and to be
applied after reconfiguration. Implement this using the
RRCReconfigurationComplete acknowledgment from the CU to the DU,
applying the spCellConfig if present (which signals a prior
reestablishment). Remove a prior flag that is not needed anymore, and
do not "guess" when is the reconfiguration, because it is now handled in
the case of the ack.
The spCellConfig is not relevant as long as we use a common search space
for DCIs (and the activation of dedicated search space happens after
applying spCellConfig). For PUCCH, there is the PDSCH transmission of
RRCReconfiguration which gets ack'ed in the default PUCCH.
RRCReconfigurationComplete is sent in PUSCH (again through common
search space). In theory, there cannot be another PUCCH before the
application of spCellConfig, as all bearers are still suspended, and
there should not be another SRB1 transmission in the meantime, as only
one RRC transaction can be active at a time.
Co-authored-by: francescomani <email@francescomani.it>
Add a flag for each RB that tracks suspension state. Mark all RBs
(except SRB1) as suspended on reestablishment, and de-suspend on
reconfiguration. Only check RLC status for non-suspended RBs. For UL
data traffic, check that DRB/SRB2 exist (SRB1 should be there as soon as
the UE context exists).
Fix various bugs and inconsistencies in config read, SCTP, ITTI, GTP
Fix bugs across various layers, mostly layer 3, including memory leaks.
See the commits for more details.
SRS configuration
- Fix segmentation fault, a memory leak, and LOGs for SRS usage
NFAPI_NR_SRS_BEAMMANAGEMENT
- Refactor SRS configuration;
- Add SRS ResourceSet to get the SNR measurements at MAC layer
In this MR we have 2 SRS ResourceSet, for the same SRS Resource. This
way, in addition to obtaining the UL-RI, we also obtain the SNR in the
MAC and fill the PRB Black list.
This branch has been tested with COTS UE and with RFSim. The measured
values seem correct.
Using the USIM interface in the MAC is non-sensical (violates layer
separation). Add header include in nr-softmodem.c, which previously came
through nr_mac_gNB.h -> usim_interface.h.
Add configurable values of NR RLC and NR PDCP to the configuration file
This is for the gNB (the UE gets the values from the gNB).
The physical simulators were also adapted (we put the previously
hardcoded values that were everywhere in the code into the simulators
themselves). I don't think we need to have those values configurable for
the simulators, but I can study the possibility to add this if someone
tells me it's important (if not important I prefer not to do it, I am
not sure if it is trivial to do or not).
Add the ability to pack/unpack 2 new TLVs for analog beamforming
total_num_beams_vendor_ext and analog_beam_list
Add the unpack related changes for the first 2 vendor extension TLVs introduced related to beamforming.
For the moment the packing is guarded by an Assert to ensure it is not used.
Add the necessary utility function changes to support these VE TLVs
Add the necessary changes to the corresponding unitary test for pack/unpack,
commented for the moment, since the packing is disabled with an Assert.
ASN_SEQUENCE_ADD is calling realloc which is allocating memory for the
'array' which was not freed.
> Direct leak of 32 byte(s) in 1 object(s) allocated from:
> #0 0x7ce97deb4c38 in __interceptor_realloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:164
> #1 0x5813fba02574 in asn_set_add /openairinterface5g/n2-handover-preparation/cmake_targets/ran_build/build/openair2/RRC/LTE/MESSAGES/asn_SET_OF.c:27
> #2 0x5813faf6c672 in createSRBlist /openairinterface5g/n2-handover-preparation/openair2/RRC/NR/rrc_gNB.c:331
> #3 0x5813faf9aa78 in rrc_gNB_generate_RRCSetup /openairinterface5g/n2-handover-preparation/openair2/RRC/NR/rrc_gNB.c:421
> #4 0x5813fafba2ee in rrc_handle_RRCSetupRequest /openairinterface5g/n2-handover-preparation/openair2/RRC/NR/rrc_gNB.c:1243
> #5 0x5813fafba2ee in rrc_gNB_process_initial_ul_rrc_message /openairinterface5g/n2-handover-preparation/openair2/RRC/NR/rrc_gNB.c:2019
> #6 0x5813fafcdc3a in rrc_gnb_task /openairinterface5g/n2-handover-preparation/openair2/RRC/NR/rrc_gNB.c:2761
> #7 0x7ce97c894ac2 in start_thread nptl/pthread_create.c:442
> Direct leak of 32 byte(s) in 1 object(s) allocated from:
> #0 0x7ce97deb4c38 in __interceptor_realloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:164
> #1 0x5813fba02574 in asn_set_add /openairinterface5g/n2-handover-preparation/cmake_targets/ran_build/build/openair2/RRC/LTE/MESSAGES/asn_SET_OF.c:27
> #2 0x5813faf6c672 in createSRBlist /openairinterface5g/n2-handover-preparation/openair2/RRC/NR/rrc_gNB.c:331
> #3 0x5813faf7d89d in get_RRCReconfiguration_params /openairinterface5g/n2-handover-preparation/openair2/RRC/NR/rrc_gNB.c:660
> #4 0x5813faf914b3 in rrc_gNB_generate_dedicatedRRCReconfiguration /openairinterface5g/n2-handover-preparation/openair2/RRC/NR/rrc_gNB.c:716
> #5 0x5813faf96856 in rrc_CU_process_ue_context_setup_response /openairinterface5g/n2-handover-preparation/openair2/RRC/NR/rrc_gNB.c:2190
> #6 0x5813fafcd3ed in rrc_gnb_task /openairinterface5g/n2-handover-preparation/openair2/RRC/NR/rrc_gNB.c:2796
> #7 0x7ce97c894ac2 in start_thread nptl/pthread_create.c:442
dynamically allocated memory is pushed to the seq_arr that
is doing a memcpy, so it can be either or better allocated
in the stack instead
> Direct leak of 16 byte(s) in 1 object(s) allocated from:
> #0 0x7efd8f6b4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
> #1 0x577888f3457e in fill_neighbour_cell_configuration /openairinterface5g/n2-handover-preparation/openair2/GNB_APP/gnb_config.c:1914
> #2 0x577888f3457e in RCconfig_NRRRC /openairinterface5g/n2-handover-preparation/openair2/GNB_APP/gnb_config.c:2108
> #3 0x57788869a0d2 in create_gNB_tasks /openairinterface5g/n2-handover-preparation/executables/nr-softmodem.c:253
> #4 0x57788869a0d2 in main /openairinterface5g/n2-handover-preparation/executables/nr-softmodem.c:619
> #5 0x7efd8e029d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
the dynamically allocated memory is pushed to the seq_arr that
is doing a memcpy, so it can be either or better allocated in the
stack instead
> Direct leak of 48 byte(s) in 1 object(s) allocated from:
> #0 0x7d4c934b4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
> #1 0x577622a40137 in fill_neighbour_cell_configuration /openairinterface5g/n2-handover-preparation/openair2/GNB_APP/gnb_config.c:1933
> #2 0x577622a40137 in RCconfig_NRRRC /openairinterface5g/n2-handover-preparation/openair2/GNB_APP/gnb_config.c:2109
> #3 0x5776221a30f2 in create_gNB_tasks /openairinterface5g/n2-handover-preparation/executables/nr-softmodem.c:253
> #4 0x5776221a30f2 in main /openairinterface5g/n2-handover-preparation/executables/nr-softmodem.c:619
> #5 0x7d4c91e29d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
seq_arr_push_back is doing a memcpy so locally allocated memory can be freed after.
Allocate in stack.
> Direct leak of 64 byte(s) in 2 object(s) allocated from:
> #0 0x7ec4bb8b4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
> #1 0x55895aae1b1f in fill_measurement_configuration /openairinterface5g/n2-handover-preparation/openair2/GNB_APP/gnb_config.c:2015
> #2 0x55895aae1b1f in RCconfig_NRRRC /openairinterface5g/n2-handover-preparation/openair2/GNB_APP/gnb_config.c:2112
> #3 0x55895a246112 in create_gNB_tasks /openairinterface5g/n2-handover-preparation/executables/nr-softmodem.c:253
> #4 0x55895a246112 in main /openairinterface5g/n2-handover-preparation/executables/nr-softmodem.c:619
> #5 0x7ec4ba229d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
Inside of passing the RRCReconfiguration buffer, call RRCReconfiguration
message generation inside the F1 callback. This will simplify the code in the
rrc_CU_process_ue_context_setup_response() function once the N2 handover case
is introduced. In rrc_CU_process_ue_context_setup_response(), with presence
of the HO context, the HO ACK callback is called only once and depending
on the type of HO it will do either RRCReconfiguration for F1 and
HandoverCommand for N2.
The byte_array reference contains the pointer to the
encoded RRC buffer to be used in the handover acknowledge
callback (e.g. in F1 to trigger RRCReconfiguration)
This is necessary because the function was re-establishing PDCP only for SRB2
however according to specs 3GPP TS 38.331 RadioBearerConfig, PDCP shall be
re-established for SRB1 and/or SRB2 whenever the security key used for the
radio bearer changes, with some exceptions for SRB1 (i.e. when resuming
an RRC connection, or at the first reconfiguration after RRC connection
reestablishment in NR, do not re-establish PDCP for SRB1).
* the input param "reestablish" is converted into a bitmap to indicate
whether PDCP should be re-established for the SRB1 and/or SRB2.
* For convenience the bitmap is 0-based, with index 1 corresponding to SRB1,
index 2 to SRB2.
This commit is keeping the legacy re-establishment, that is re-establishment
of PCDP for SRB2 only.
according to TS 38.331, RRCReconfiguration messages can be carried
in a container by different RRC messages, e.g. HandoverPreparationInformation,
HandoverCommand, RRCResume etc.. therefore before the introduction of new
RRCReconfiguration messages, e.g. for handover, a new design seems to be necessary
in order to improve modularity and maintainability of the code.
The goal of this commit is to make the generation of RRCReconfiguration
messages more modular by (1) preparing the RRCReconfiguration parameters
data in RRC (2) pass it to ASN1 for IEs allocation (3) encode to buffer
The following changes are introduced:
(1) introduce struct nr_rrc_reconfig_param_t to store the RRC parameters relevant
to encode the RRCReconfiguration IEs
(2) add RRC function get_RRCReconfiguration_params to fetch nr_rrc_reconfig_param_t
data from the UE context and
(3) pass it to the ASN1 encoder, e.g. do_RRCReconfiguration
(4) add a function build_RRCReconfiguration_IEs to allocate memory and build the
ASN1 NR_RRCReconfiguration_IEs_t and
(5) adopt it in do_RRCReconfiguration
(4) add free_RRCReconfiguration_params for memory management of nr_rrc_reconfig_param_t data
(6) add test for rrc_reconfiguration
get_RRCReconfiguration_params:
This function prepares RRCReconfigurationParams for RRC encoding.
Motivation of this change: depending on the RRCReconfiguration
message to be encoded, the ownership of ASN1 memory allocation
should belong to the ASN1 layer, therefore this function is
preparing the nr_rrc_reconfig_param_t data to pass to the
ASN1 encoder to build the ASN1 message and encode to buffer
The function is preparing the params for the IEs that are
either mandatory or shared among different RRC messages.
Specific fields that depend on the message to be encoded are then
added afterwards in the caller. The input param to indicate
re-establishment has been split between SRBs and DRBs, since
depending on the scenario the PDCP re-establishment can vary.
This will be addressed in a later commit.
This function is also handling xid.
build_RRCReconfiguration_IE:
The long term goal is to transfer ownership of memory allocation in ASN1 encoding to
build_RRCReconfiguration_IE, then by calling ASN_STRUCT_FREE_CONTENTS_ONLY
on dl_dcch_msg, all IEs allocated in the context are freed after encoding to buffer.
In the long term, createDRBlist, createSRBlist can also be brought into the context
of build_RRCReconfiguration_IEs and free the ASN1 structure after encoding.
This improves maintability and helps preventing memory leaks.
Currently, what is not allocated in the context, is nulled and freed outside.
free_RRCReconfiguration_params:
this function frees memory allocated to build the nr_rrc_reconfig_param_t data,
including the NR_DRB_ToAddModList_t and NR_SRB_ToAddModList_t. The function
freeDRBlist has been removed since no longer necessary.
dedicated_NAS_msg_list:
dedicated_NAS_msg_list handling has also been refactored, by:
(1) fetch the NAS PDUs from the UE context in get_RRCReconfiguration_params,
which translates to (2) passing an array of dedicatedNAS-MessageList + size
to the ASN1 encoding function where (3) the ASN1 encoding logic for the
dedicated_NAS_msg_list IE has been moved
Note, 3GPP TS 38.331:
dedicatedNAS-MessageList: SEQUENCE (SIZE(1..maxDRB)) OF DedicatedNAS-Message
* differentiate the 2 functions based on the input: either NR Cell ID or PCI
* enhanced variables naming to distinguish the parameters
* add logging for debugging purposes
Robert Schmidt