The 5G-RFsim F1 test tested multiple DUs at one CU. This
functionality is retained in the new F1+E1 test.
The 5G-RFsim E1 test tested a single CU-UP at a single CU-CP. Here, we
extend to use multiple CU-UPs, one for each DU. The associated is
ensured by using three different F1-U transport networks, one for each
DU/CU-UP pair.
- Test only one DU at the CU (3 DUs is tested in F1+E1)
- Harmonize IP configuration to make it simpler to reuse in the F1+E1
test
- Speed up the test by reducing the number of steps to deploy core/RAN
- Add traffic test
binding the local address for SCTP is pointless, because we don't really
care through which interface SCTP traffic goes. Actually, we even might
want to set the DU remote_n_addr and the the local_n_addr to addresses
in different networks, because we might want to have GTP traffic go
through a different interface than SCTP, as done in the CI test for E1.
MR-2401 changed the argument to the init_nrUE_standalone_thread
to be zero instead of the ue_id_g. This causes every port to be
opened for multiple UEs to have the same value, therefore only
allowing one UE to be connected to the proxy. If the ue_id_g
global is an issue, we should open a new ticket for a proper fix.
We set the RFsim TCP socket to non-blocking. Thus, it may happen that we
cannot write() to the socket when the kernel cannot handle the request,
in which case we wait some time before trying again. This is the
correct/expected behavior.
Since this is *normal*, an error message is not justified; we did not
even print a message in this case before commit 21790f9c4f introduced it.
When setting up bearer(s) through F1, the corresponding F1 message has
QoS fields for the DRB(s) to be set up, as well as for all flows
associated to this DRB. In this commit, set the DRB QoS field to be
equal to the first flow (it is unclear/unspecified how it should be set
up, based on the flows), which was not set before and therefore
contained unitialized data.
The F1 module uses this data, and in split mode, F1 message generation
failed due to uninitialized data.
We reuse RRC UE IDs at the RRC. Previous to this commit, we did not
release a UE at the CU-CP's PDCP (for SRBs). Thus, when reconnecting a
UE, the PDCP might not be in a good state, since we did not release the
previous PDCP UE context.
Integration: 2023.w50
See merge request oai/openairinterface5g!2474
* !2460 bugfix: initialize TX and RX antennas separately
* !2471 fix a useless computation done in case we activate LOG_D
* !2417 PDSCH precoding optimization
* !2436 Fix the DoS vulnerability in RA procedure
* !2472 (ci): adding new packages in cuup dockerfiles
* !2463 NR UE RRC MAC configuration improvements
* !2475 Fix gNB RA procedures when Msg4 Ack not received
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
When the gNB does not receive PUCCH with Ack for Msg4 we have to consider Msg4 received by the UE, so we need to apply the CellGroupConfig sent to the UE.
There are two scenarios:
1 - The UE never decoded PDSCH for Msg4, the RA will fail because RA Contention Resolution timer, the UE will come with a new RA with new RRCSetupRequest
2 - The UE decoded PDSCH for Msg4, and if SR does not work and no resources for PUSCH, it will trigger RA with MAC CE C-RNTI in Msg3 (so, gNB must be ready for it)
Robert Schmidt