Split out E1AP net config from Setup Request

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.
This commit is contained in:
Robert Schmidt
2023-10-25 20:22:32 +02:00
parent 5c07c326ea
commit a23984c7ae
9 changed files with 76 additions and 56 deletions
+1 -1
View File
@@ -403,7 +403,7 @@ static int create_gNB_tasks(ngran_node_t node_type)
if (node_type == ngran_gNB_CU || node_type == ngran_gNB) {
MessageDef *msg = RCconfig_NR_CU_E1(false);
instance_t inst = 0;
createE1inst(UPtype, inst, &E1AP_SETUP_REQ(msg));
createE1inst(UPtype, inst, &E1AP_REGISTER_REQ(msg).net_config, NULL);
cuup_init_n3(inst);
itti_free(TASK_UNKNOWN, msg);
RC.nrrrc[gnb_id_start]->e1_inst = inst; // stupid instance !!!*/