gured mostly for the downlink. Also, if the server response comes quickly, the packet does not need to wait at all for the downlink trans- mission. If the packet arrives in the uplink buffer in the worst case just when the uplink transmission has started, the packet has to wait for the whole TDD frame before the transmission can start. The average waiting time is half of the TDD frame. Typical TDD frame configurations are shown in Figure 10.12. We assume that the switching subframe is configured mostly for the downlink. If we have a 2.5 ms TDD frame at sub-6-GHz bands, the average waiting time in the uplink is 1.25 ms. The corresponding value in FDD would be half of the 0.5 ms frame, which is 0.25 ms. Therefore, the TDD frame adds on average 1.0 ms latency in the uplink. This value comes on top of the RTT shown in Table 10.8. Therefore, we can expect that the best-case RTT measurements with sub-6-GHz TDD with 30 kHz is 2.8 ms + 1 ms = 3.8 ms when using full TTI transmis- sion. The average waiting time in the uplink with mmW and 120 kHz is approx. 0.3 ms, which makes the best-case RTT approx. 1.5 ms. We can conclude that the sub-6-GHz TDD system will not be able to deliver 1-2 ms latency, but the best-case latency will be more than 3 ms. If we need 1-2 ms latency, then we have two options: a low band FDD solution with mini-slot for wide area low latency services or a mmW TDD solution for local area low latency services. Best-case latency values for example deployment options are shown in Table 10.10 and in Figure 10.13. An example RTT measurement with a pre-commercial 5G system with 3.5 GHz TDD is illustrated in Figure 10.14. The latency varies between 3.9 and 6.4 ms, which is close to the theoretical values. Table 10.10 Best case two-way latency summary for example deployment cases. System Best-case assumption latency (ms) Sub-1-GHz, FDD 15 kHz, full TTI, UE capability #1 Sub-6-GHz, TDD, 2.5 ms frame, 30 kHz, full TTI, UE capability #1 mmW, TDD, 0.625 ms frame, 120 kHz, UE capability #1 Sub-1-GHz, FDD 15 kHz, 2-s