Improve RTT latency of NR gNB

RTT latency can be measured via a simple ping transmission test.

If we take an UL ping as example, RTT is mainly composed by the following time segments:

Ping data to arrive at UE MAC from application layer
UE MAC waits for a Scheduling Request (SR) occasion
Network receives the SR and schedules UL grants to allow the UE to send BSR and data
The received ping is forwarded to the destination server and looped back
The network waits for a DL slot to sends back the ping
The ping is received by the UE at application layer

Having a higher numerology, like 60 Khz SCS for FR1, reduces the slots duration, hence improves latency. However, at present we do not support mixed numerology and since SSB SCS must remain at 30 KHz, 60 Khz SCS cannot be used.

NOTE : For a tutorial showing the generic way of measuring / analyzing RTT, click here.

- Starting from test release 2021-11-19, we provide a NR SA TDD gNB configuration file optimized for latency:

gnb-sa-tdd-low-latency.cfg

The improvements are mainly due to:

Support of 1 ms TDD pattern
Low value for rx_to_tx_latency
k_min set to 2
Low sr_period

- If you are using a previous release, you can still try to optimize your latency by setting:

sr_period: 1,

The RTT is also shorter for a FDD frame configuration compared to a TDD one.

- If FDD cell is not supported, a balanced TDD UL/DL configuration should be used, like the one below:

tdd_ul_dl_config: {

pattern1: { period: 2.5, /* in ms */ dl_slots: 2, dl_symbols: 6, ul_slots: 2, ul_symbols: 4, }, }, k1: [4, 7, 7], k2: [6, 4],

To avoid extra delay between DCI and PDSCH in time segment 5, k0 should be always 0

k0: 0, /* delay in slots from DCI to PDSCH */

NOTE: starting from official release 2021-09-18, k values are automatically computed if not present in the configuration file

- If you get a collision between Uplink and NZP CSI-RS you can disable TRS, comment out this line

#define USE_TRS

- If you have a fast hardware, try changing the rx_to_tx_latency to 3 or 2. This will increase the real time requirements, so depending on the CPU you are using and the load you are generating on the gNB, it might not work well (you can monitor this with the 't cpu' lteenb monitor command; if the TX/RX diff column gets negative values, realtime gets broken).