5G CPE testing has, in some ways, proved to be as much of an opportunity as a challenge. It has improved our testing capabilities by pushing us to create faster and more efficient techniques. In this second post of our 5G CPE Test Scenarios series, we will pick two more crucial scenarios that can come up.
End to End Latency
Ultra low latency is a selling point of 5G. The following are some of the factors affecting latency:
a) 5G core network
- Most of the initial 5G deployments over the world use NSA.
- NSA deployments, will use the LTE core network and hence the latency values will be higher.
- The real 5G latency numbers will be seen when the deployments start using the 5G Core network(SA).
b) Local WiFi network
- A heavily loaded badly designed local Wi-Fi network might result in collisions and dropped packets.
- Re-transmissions result in higher end to end latency as seen by the user.
c) The type of 4G/5G bearers used
- “Packet Delay Budget” – This IE informs to network nodes that how much delay can be tolerated for the packets passing through a particular EPS bearer. EPS bearer is a combination of radio and core network bearer.
- Bearers with different QCI values will have different packet delay budgets. Example: In 5G: 5QI80(Augmented Reality traffic) bearers have a delay budget of 10ms and 5QI6(Buffered video) bearers have a delay budget of 300ms.
- The latency values seen varies depending on the bearers used and the network load.
d) The CPE processor load
- At high client load and traffic conditions the CPE processor capacity might impact the latency.
Following from the above, latency testing needs to be divided into different parts:
1. Testing the 5G-only latency under different load conditions.
- Increase the number of clients from one to maximum possible number of clients over Ethernet to the CPE and run latency tests (eg: Ping, Qperf).
2. End to End latency
- This is the most important latency test since it translates to the end customer’s real experience.
- This test can be repeated for different client loads, background traffic conditions and time duration.
- Initiate a traffic that needs a particular QoS. The CPE should establish the bearer with the necessary QoS support in the back haul. Run a latency test for that bearer. Traffics like ping might use the best effort default bearer and will show a higher latency value. The latency value should be within the range of what is demanded by that particular QoS. This test might only apply for the later days of 5G evolution when real 5G traffics get launched.
| 5G Only latency | End to End latency | |||
| Traffic type | 5G NSA | 5G SA | 5G NSA +
WiFi mode – 11n/ 11ac/ 11ax |
5G SA +
WiFi mode – 11n/ 11ac/ 11ax |
| Voice | ||||
| Buffered video | ||||
| Live video | ||||
| TCP based apps(FTP, Iperf) | ||||
| Multi QoS traffic in parallel | ||||
In-device 3GPP/Non-3GPP inter working algorithms
(Critical when more 5G specific applications get launched)
- 5G CPE uses two technologies that really don’t understand each other.
- The non-3GPP part(WiFi) and the 3GPP part (4G/5G).
- The user traffic is initiated from the non-3GPP (Wi-Fi) side.
- It is important to correctly identify the type of traffic and communicate to the 3GPP side.
- Without this, the backhaul bearers with the required QoS will not get established
- Imagine using 5QI6 bearer(packet delay budget 300ms) for AR traffic (packet delay budget 10ms)!
- These algorithms are proprietary for each CPE vendor. This makes it even more critical for the operators to test this part. Any issue here does not show up in the initial days of 5G when customer density is low.
- It should also be noted that the traffic using real 5G improvements will get launched a bit late in the cycle (after a good number of CPEs are already in the market). Fixing issues at this stage can be quite expensive.
To test In-Device 3GPP/Non-3GPP coexistence algorithms the following can be used.
Initiate different traffics that need different QoS bearers and check if the right bearers are getting established. Some examples in NSA case where LTE bearers are used (list is not complete).
- QCI1 for conversational voice (Skype for Business, VoIP calls etc)
- QCI6 for buffered streaming videos (YouTube, Youku etc)
- QCI7 for live video (YouTube Live)
- QCI9 for TCP based applications (FTP, Emails etc)
For each type of traffic the right bearer type should be established. If there are different types of simultaneous traffic (typical case) there should be enough number of bearers to support each type of QoS requirements.
In the next post, we will pick our final set of test case scenarios and share our learnings with you. Till then, do share your experiences in 5G CPE testing in the comments section of this post.
