This commit introduces the capability to handle multiple CU-UPs. It uses
a RB tree and puts the CU-UPs into the tree. Upon the connection, it
associates UEs to CU-UPs in a round-robin fashion.
The E1AP Setup Request contained the network configuration (IP address,
ports) as well as the actual E1AP Setup Request application data
(Supported PLMNs, ...). This has the drawbacks that
- The E1AP Setup Request is stored to retrieve IP addresses in the E1AP
module, which is confusing as the Setup Request, per standard, has no IP
info
- The CU-CP received an E1 Setup Request for configuration during start
up, but it did not actually receive such Setup Request, but merely the
IP configuration to set up the socket
This commit splits the E1AP Setup Request into a "real" Setup Request
for application data, and creates a new type e1ap_net_config_t to group
all IP configuration data. Further, a new ITTI message type
E1AP_REGISTER_REQ is introduced to group both types. What happens is
- RCconfig_NR_CU_E1() reads both E1AP application-level data and IP
configuration, as previously
- The data is sent to the CU-CP. It discards the E1AP Setup Request
data, and only uses the network configuration to set up the socket
- The data is sent to the CU-UP. It uses the network configuration to
connect to the CU-CP, and then sends the E1AP Setup Request to the
CU-CP.
Currently, the CU-CP still stores the Setup Request locally, which will
be changed in the next commit to send it to the RRC.
The DRBLists inside E1AP message are for E-UTRAN. We don't support that
with our CU-CP/UP yet, so remove it to reduce ambiguity and complexity.
For the same reason, we remove the CN Support, which for us is always
"NR".
- Use the same CU-UP in E1 as in CU-CP: we don't have a separate entity
to allocate IDs, and we just use the same as the CU-CP
- Correct gNB CU-UP/CP UE IDs in E1AP message types to 32bit
- Set CU UP UE ID explicitly for clarity
- Remove RNTI from E1 messages, E1 does not know what an RNTI is
CMake now takes the option ASN1C_EXEC to select an asn1c to use for
compilation. For instance, run with
cmake .. -GNinja -DASN1C_EXEC=/opt/asn1c/bin/asn1c
or
./build_oai --cmake-opt -DASN1C_EXEC=/opt/asn1c/bin/asn1c
to select the alternative asn1c. For instance, this is important for the
CI to allow to build multiple versions of OAI in parallel that might use
different commits of OAI.
Further, this patch introduces functionality to check for the support of
asn1c options that we require, and alerts the user if they are missing,
alongside a message of how to resolve the problem.
We don't work much on asn1c. The version we use has several bugs.
There is an active community out there that fixes bugs and improves
asn1c. Let's use their version.
The GTP module is common for 4G and 5G. It hardcodes the functions to
call when creating S1U and NGU tunnels. The S1U case is both applicable
for LTE and NR (NSA), which until now was not a problem as the PDCP data
forwarding functions where called pdcp_data_req. The issue is that in this
branch, the NR PDCP functions have changed to nr_pdcp_data_req_drb().
When setting up a GTP tunnel, we now pass the PDCP data forwarding
functions into GTP, since the caller knows whether it is in 4G or 5G,
but GTP itself does not.
Most targets don't need the symbols from the compiled RRC ASN.1
libraries, but only the headers. In particular when compiling individual
libraries (e.g., for tests), linking the full library makes the RRC
ASN.1 libraries compile and link, when they are not needed (only headers
are needed).
For libraries that can do without these headers, don't link them.
Robert Schmidt