remove several unused files
remove mem_block_t that is never used in a different way than a simple heap buffer
move up IP address type and remove duplications of the same struct declaration
This commit introduces an additional (implicit) option that signals if
the E2 agent is to be activated or not. When reading the configuration,
we now check if all fields are set, and activate the E2 agent only if
this is the case. If not, we only print a warning and start the gNB
without the agent.
Note that previously, if not all fields are set correctly, the gNB
stopped.
To implement this behavior, it is necessary to change the defaults of
the RIC IP and the directory for SMs to a (non-NULL) default value.
Otherwise, the configuration system would not consider the field to be
set to the default, and wrongly assumes the field is set, even though it
is not; at least, this change is necessary to make config_isparamset()
return NULL if the configuration is not set.
3GPP has the concept of a gNB-CU-UP ID and a (separate) gNB ID (for gNB,
CU-CP). This commit introduces the gNB-CU-UP as a separate ID that has to be
set in the configuration file when running as a CU-UP. For the
CU/monolithic gNB, it is optional (but needs to be the same as the
gNB-ID if specified).
The CU-UP ID is necessary, as some entities, e.g., the e2 agent, need to
signal both IDs, e.g., to reconcile a CU-CP and (multiple) CU-UP(s)
belonging together.
Introduce a --no-itti-threads command line option to disable threading
in ITTI, and call message handlers in the current thread. This is being
introduced in order to increase repeatability when testing the nrUE with
the IQPlayer. Without this feature, runs with the IQPlayer will end up
differently, depending on the timing of ITTI threads, mostly when
sending messages to RRC and NAS.
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.
- avoid the finction duplication
- add the transform predoding to the nr_rx_pusch_tp
- add the MMSE for 2 layer which modulation greater than 16 qam
- can support to 256 qam for 1 layer and 2 layer
Use a struct to initialize the RRC at the beginning, and remove the
NRRRC_CONFIGURATION_REQ. This message is not necessary; the RRC/CU
should be initialized from the F1 Setup Request, coming from the DU.
Robert Schmidt