2923e50ed0
This commit fixes two related issues:
1. SDAP Header Mapping Bug (cucp_cuup_handler.c):
The original code incorrectly mapped SDAP header configuration from
internal E1AP representation to ASN.1 enum values. The internal
representation (`bearer_context_sdap_config_t`) uses true=present/false=absent,
while ASN.1 enum (`E1AP_SDAP_Configuration_t`) uses
0=present/1=absent. The fix correctly inverts the mapping:
- Internal true (1) → ASN.1 0 (present)
- Internal false (0) → ASN.1 1 (absent)
The commit also clarifies internal representation in the stack.
2. Test Overhead Adjustment (nr-cuup-load-test.c):
The change in (1) led to a failure in nr_cuup_functional_test
with assertion: "size % 4 == 0" in recv_ng()
- Changed UL packet overhead from 3 bytes to 2 bytes in sender_thread()
- Before the SDAP fix, the test incorrectly accounted for 3 bytes:
* 2 bytes PDCP header (correct)
* 1 byte SDAP header (incorrectly included)
- After the SDAP fix, SDAP headers are correctly set to absent, so
only 2 bytes (PDCP header) are needed
This ensures the test sends packets with the correct header size,
matching what CU-UP expects after the SDAP configuration fix.
The load test does not enable SDAP headers, therefore the original 3-byte
overhead was possibly a workaround for the SDAP header bug.
With the bug fixed, the test correctly uses 2-byte overhead (PDCP header).
This is a simple tester for the CU-UP. It configures the CU-UP via E1, and can stream data via GTP in uplink and downlink directions.
[[TOC]]
Overview
From a schematic point of view, the tester/CU-UP interaction looks like this:
+-------+
+------>| CU-UP |<------+
| +-------+ |
| | |
| F1-U | E1 | NG-U
| (data) | (control) | (data)
| | |
| +-------+ |
+------>|tester |<------+
+-------+
The tester is for performance testing of a CU-UP, and behaves like an integrated DU/CU-CP/UPF from the CU-UP's point of view.
The tester and CU-UP have an E1 connection through which control information is exchanged, e.g., configuration of UEs/bearers and associated information. In other words, towards the CU-UP, the tester appears like a CU-CP.
Further, for each UE/bearer, CU-UP is configured with GTP IP information and the corresponding TEID. The CU-UP will forward downlink data arriving on NG-U on the F1-U interface, and uplink data arriving on F1-U on the NG-U interface. In other words, on the F1-U interface, the tester appears like a DU to the CU-UP, and on the NG-U interface, the tester appears like a UPF to the CU-UP.
A test scenario is fixed to these steps:
- The tester sets up a number of UEs via the E1 interface (it is possible to see the message exchange in Wireshark).
- The tester streams data in downlink/uplink (from the CU-UP's point of view) and measures how much data is lost.
- The tester releases all the UEs via the E1 interface, and disconnects from the CU-UP.
Note: The tester uses the same GTP module as the CU-UP. Thus, data might not only be lost at the GTP interface of the CU-UP, but also at the tester.
Usage
You can build the CU-UP and the tester like so:
cd ~/openairinterface5g
mkdir build && cd build && cmake .. -GNinja && ninja nr-cuup nr-cuup-load-test params_libconfig
./tests/nr-cuup/nr-cuup-load-test
./nr-cuup -O ../tests/nr-cuup/load-test.conf
This builds both tester and CU-UP in the directory build/, then starts the
load tester with default values
- 1 UE
- 10s of Test
- 60 Mbps of traffic in both downlik/uplink with a packet size of 1400 bytes
To see the available options, run
./tests/nr-cuup/nr-cuup-load-test -h
The configuration file load-test.conf matches the default
tester configuration (F1-U GTP traffic over non-standard port 2153, NG-U GTP
over 2152, tests on localhost). The configuration file includes this
non-standard port 2153 as the GTP module, as of now, cannot bind on the same
interface and port for both F1-U and NG-U due to internal limitations.
Limitations
- The tester does not yet create/remove UEs during a traffic test.
- It might be possible to integrate with an external GTP traffic generator, but we did not test this.