Note: some modifications have been done to the UE too, but for syntactic
reasons. The UE may fail to work, not tested.
For the UE, we have the problem of handling properly SecurityModeCommand.
We don't verify its integrity. This is a bit complicated to handle properly
and may require some API changes in the PDCP layer. So, as of today, the
integrity of this message is not verified.
Also, NSA mode has been touched, but it should not be a problem. But not
tested, so not sure.
At this point we are successfully able to build.
Additionally, we can run the scenario,
however, it does not pass. It seems that the gNB
is not connecting to the proxy correctly. Just
wanted to push the progress so far. FYI, the items
that had to be changed to correct the linking issues
were the following:
- mac_rrc_data_ind_ue vs. nr_mac_rrc_data_ind_ue
- rrc_data_req vs. nr_rrc_data_req
- mac_rrc_data_req_ue vs. nr_mac_rrc_data_req_ue
- rrc_data_req_ue vs. rrc_data_req_nr_ue
- rrc_data_req vs. nr_rrc_data_req
The listed functions should be declard in the LTE/NR
UE directory depending on the functionality. Several
were mixed. i.e.: LTE functions being called in NR UE.
Also, removing siWindowLength, siWindowLength_int,
SIBType, SIBPeriod, and siPeriod_int from the NR UE RRC.
These variable were not used in the NR UE and are defined
for LTE only.
Lastly, in the NR_IF_Module.c of the NR UE, the global
variable def_dci_pdu_rel15 is not accessible. Need to
revisit this. For not it is commented out.
Updated the configuration files. Added a sleep to
ensure that the LTE UE gets attached to the EPC
before the bearer is modified to be gNB. Updated
the ifconfig tunnel up command to be brought up
by the NR UE socket when in NSA mode. Lastly,
started the gNB PDCP layer in S1 mode.
Once the LTE UE's tunnel interface with the EPC
is ready to be established, if we are in NSA mode,
we do not want to launch the tunnel interface
from the LTE UE side, but in the NR UE. Via itti_msgs
we send the string containing the tunnel interface
'up' command to the NR UE and bring it up from the NR UE.
-If the gNB crashes when the X2 connection is established with the eNB, an sctp shutdown event is received from the eNB. However the x2 data related with
the connection were not removed from the RB tree. Then if the gNB tried to reconnect, it made the eNB exit because the eNB had kept the previous data.
Now we remove the x2 data as soon as the sctp shutdown event is received so that the eNB does not exit anymore at the next connection attempts.
-User plane traffic validation with OAI UE and OAI CN:
-Downlink ping initiated from the CN is received at the IP interface of the UE. However it seems that there is some packet corruption preventing the generaration of ping reply.
-Uplink ping initiated from the UE reaches the OAI CN machine. However no ping reply is seen yet either.
Melissa Elkadi