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
According to 3GPP TS 38.331 5.3.5.5.2 (Reconfiguration with sync), the UE
shall consider the target SpCell to be one with a physical cell identity
indicated by the physCellId
Move RRC radio parameters file to DU
A number of radio-related RRC parameters, e.g., CellGroupConfig, "originate" at
the DU and are sent to the CU for forwarding to the UE only. Similarly, there
are additional parameters, e.g., RLC-BearerConfig (part of CellGroupConfig),
that originate at the DU.
Hence, the DU decides about these parameters, depending on the MAC state and
capabilities. To clarify this, move the existing
openair2/RRC/NR/nr_rrc_config.{c,h} => openair2/LAYER2/NR_MAC_gNB/nr_radio_config.{c,h}
So that developers know that while those are RRC parameters, they originate at
the DU.
In other words, the CU/RRC is not supposed to use any of these functions in
the RRC. Correspondingly, includes of this file have been cleaned up (and when
they are not necessary at the MAC as well)
Enhance UE identity management in Initial UE Message and other NGAP improvements
This MR improves the Initial UE Message procedures by supporting simultaneous
presence of both 5G-S-TMSI and GUAMI. Previously, only one identity could be
used, leading to potential AMF selection failures. Now the presenceMask allows
both identities. The AMF selection is prioritizing GUAMI first, then falling
back to 5G-S-TMSI, and finally using PLMN or highest capacity.
Also, fix handling of selected PLMN identity in NGAP.
Refactoring:
- Select the AMF based on (1) absence of UE Identity (2) Presence of GUAMI
(3) Presence of 5G-S-TMSI
- Also refactored the AMF selection logic for better readability and reliability.
- Refactor and cleanup rrc_gNB_send_NGAP_NAS_FIRST_REQ
- Replace ngap_pdu_t with byte_array_t
- Add guami_t to ngran_types.h: refactor NGAP and RRC code to use one common
GUAMI type instead of two identical ones
Also:
- Bugfix in ngap_gNB_handle_ng_setup_response: use correct count for PLMNSupportList
Closes issue #801
A number of radio-related RRC parameters, e.g., CellGroupConfig,
"originate" at the DU and are sent to the CU for forwarding to the UE
only. Similarly, there are additional parameters, e.g., RLC-BearerConfig
(part of CellGroupConfig), that originate at the DU.
Hence, the DU decides about these parameters, depending on the MAC state
and capabilities. To clarify this, move the existing
openair2/RRC/NR/nr_rrc_config.{c,h} => openair2/LAYER2/NR_MAC_gNB/nr_radio_config.{c,h}
So that developers know that while those are RRC parameters, they
originate at the DU.
In other words, the CU/RRC is not supposed to use any of these functions
in the RRC. Correspondingly, includes of this file have been cleaned up
(and when they are not necessary at the MAC as well).
One of the next commits moves nr_rrc_config.c "down to" the MAC/DU. The
BearerConfig functions are only used at the DU, so move them here in the
corresponding file.
selectedPLMN-Identity IE in RRCSetupComplete is an Index (long) of the PLMN selected
by the UE from the plmn-IdentityInfoList (SIB1) (see 3GPP TS 38.331)
while
Selected PLMN Identity in NGAP INITIAL UE MESSAGE Indicates the selected PLMN
id for the non-3GPP access (PLMN Identity ID carrying MNC, MCC and MNC size,
9.2.5.1 3GPP TS 38.413)
The legacy code was setting Selected PLMN Identity in the latter to an ID
value as the former, however in NGAP the IE to be encoded is PLMN Identity 9.3.3.5
therefore:
* set plmn type plmn_id_t in ngap_nas_first_req_t
* check whether received selectedPLMN-Identity is within bounds
* select PLMN from gNB_RrcConfigurationReq by selectedPLMN-Identity ID
note: this commit is assuming that the plmn-IdentityInfoList in SIB1
is matching the PLMN list in gNB_RrcConfigurationReq
* in NGAP: store the PLMN in the NGAP UE context, no need to fetch the PLMN
in the NGAP instance since the UE context already tells what PLMN
was selected
Closes#801
* use bitmask to select presence of either 5G-S-TMSI or GUAMI
* select the AMF based on
(1) absence of UE Identity (2) Presence of GUAMI (3) Presence of 5G-S-TMSI
Related to #801
* add function to process AMF Identifier
* add function to select AMF
* set const parameters in utility nnsf functions
* adopt utilities for memory allocation
* improve readability and maintainability
* improve logging
ngap_pdu_t has the same definition as byte_array_t, so it is
replaced by the latter. This simplify the stack and reduces
duplicated code.
Also, add function create_byte_array to copy from an
existing buffer to a new byte_array_t and replaced
allocCopy with create_byte_array, and adopted
OCTET_STRING_fromBuf whenever possible.
Add CI test to force RRC IDLE and new connection setup with 5G-S-TMSI
This MR is a follow up to !2725 (merged)..
The primary goal is to introduce a CI test that enforces the following behavior:
- Forces the UE to enter RRC_IDLE state.
- Validates the UE's re-connection procedure using the 5G-S-TMSI as the UE
identity.
Fix RRC resources periodicity determination according to number of slots per period
Otherwise we may end up in scenarios where some channels would end in
the wrong TDD slot type
Add enc/dec library and unit test for E1 Bearer Context Modification Failure
This MR is adding:
- the enc/dec library
- unit test
- handler and callback in stack
For the E1 Bearer Context Modification Failure.
Release all SDAP entities for a UE in nr_rrc_going_to_IDLE().
With this change the SDAP entities of the UE are cleaned up
when going into RRC_IDLE, including tun sockets, threads etc.
A new SDAP entity is created when re-attaching to the network.
Signal gNB-DU config update CellStatus from DU to CU
Add the cell status to gNB-DU configuration update message, including
test. Use the gNB-DU configuration update to signal the cell status in
the stack.
This IE was not included in a previous refactoring round, but is at
least necessary to be decoded when interoperating with the OSC O-DU.
Improvements in handling UE context in gNB DU
The goal of this MR is to improve the handling of UE context in gNB DU.
To achieve this goal, the UE structure is created as soon as the gNB
receive a PRACH indication. At that stage the UE is placed in a new
structure containing UEs performing RA, untill RA is complete where it
is moved to the list of connected UEs. To simplify the code and to
improve the handling of initial procedures (see #751), DCI 10 and DCI 00
is used at every stage until the DU receives from CU the indication of
UE RRC reconfiguration being completed.
This is preparatory work to allow NSA-like modes to be used over F1 in
the future. Notably, it fills the F1 message for UE context setup with
GTP TEID, and fills additional information to "make the F1 encoder
happy" (fill in QFI etc). Also, provide some F1 fixes to make this work.
Remove stale UE connections, if relevant.
Add functionality to trigger the addition of a new RRC UE context (in
the CU) for NSA modes, using F1. This commit makes do-ra and phy-test
modes work. "True" NSA will work in the next commit, which also sends
the X2 addition request answer message.
Use the gNB-DU configuration update to signal the cell status in the
stack. At the DU, modify the code to always send this message --
previously, we only sent this message if a SIB1 update was necessary,
but now it's always, only including SIB1 updates if necessary.
At the CU, as we don't really have a use as of now, print the
information, but don't do anything with it.
- rewrite add_UE_to_list() and rewrite remove_UE_from_list() to simplify
list handling
- return pointer from get_new_nr_ue_inst(); it's completely freed by
delete_nr_ue_data()
- have add_new_UE_RA() add UE context to access list; remove with
nr_release_ra_UE()
- have add_connected_nr_ue() only add UE to connected list; to move from
access to connected use transition_ra_connected_nr_ue(); remove with
mac_remove_nr_ue() as previously
- free memory on problems during RA
- add some documentation
- in NSA/HO: check for pre-configured RA process
- there are asserts in all functions to clarify when a UE has RA
This commit does not introduce the callback on the CU-UP to trigger
a Bearer Context Setup Failure when the setup of the bearer context was unsuccessful.
This should be handled properly in the stack e.g. in e1_bearer_context_setup (a comment
in the code says "We assume all DRBs to setup have been setup successfully, so we always
send successful outcome in response and no failed DRBs")
Add Bearer Context Modification Request/Response enc/dec lib and adopt in stack
This MR is introducing the Bearer Context Modification Response enc/dec
library with relative unit test, and it is also adopting it in the
stack. Also:
- Refactor Security Information IE decoding function
- Adopt Bearer Context Modification Request lib in stack (introduced in
!3219 (merged))
Issue 947 and compilation improvements
This MR started with a small commit (03c7f151) to close#947. Little did
I know that I would be taken in a long journey through OAI compilation
hell.
Guido Casati