5G is unlike earlier generations of radio network. In the first part of this series we talked about how it’s more of an ecosystem of technologies than a self-contained ‘G’, and we went on to outline the five most important considerations for new radio drive testing in this era of new technical challenges.
But exactly why does drive testing remain relevant for 5G NR and how does it need to change to accommodate new radio testing? Based on further extracts from our detailed white paper, these two crucial questions are the subject of this follow-up blog post.
Let’s dive straight in.
Why there’s still a need for drive testing in 5G NR
5G is designed to enable extensive machine learning (ML) and artificial intelligence (AI) at all network layers, from the physical layer to the application layer, as well as in all network nodes, including the end node (a.k.a. the device).
For networks and devices, these ML/AI-based techniques and protocols ensure self-aware communication by enabling network mechanisms to evaluate a device’s operational conditions and a user’s preference profile, and consequently to operate accordingly. Similarly, the device will benefit from algorithms that estimate a network’s load, and it uses this information to optimize its configurations, such as antenna and number of beams.
This is where questions on the need for drive testing of 5G NR, and why drive testing remains relevant, arise.
ML and AI-based network solutions
First, for this extensive intelligence to be enabled requires a series of ML and AI algorithms to operate in coordination on architectures based on upon interfaces and common data management platforms.
In late 2017, the International Telecommunications Union’s ITU-T Study Group 13 set up a Focus Group on ML for 5G (FGML5G), and it’s currently developing frameworks and architectures to support 5G network intelligence. Other forums and organizations opened work items related to the automation and AI to be embedded in the networks, such as ETSI ENI (Experiential Networked Intelligence) / 3GPP Service Area SA1 NetWorkDataAnalytics (NWDA) for predictable network performance.
However, with frameworks in place rather than thoroughly standardized solutions, network and device vendors will develop proprietary solutions that will need testing of ML/AI algorithm performance, and of the impact of their interaction from a user perspective, which can be accurately evaluated only using drive testing data.
Second, several other significant reasons have emerged from 5G characteristics that still require drive testing, such those in this non-exhaustive list:
Unlike all the previous Gs, 5G is user-centric, the network design being focused on quality of experience (QoE) rather than quality of service (QoS), with protocols and policies that enable user-centric network optimization.
This means that the most accurate behaviour can be evaluated only at the device level. Consequently, whenever QoE evaluation of a particular service or application is required, device-based testing is needed.
Spectrum and bandwidth diversity
5G NR comes with low, medium and high frequency spectrums, as well as large continuous bandwidths or narrower bandwidths aggregated using various techniques. This variety is expected to stress a device’s hardware and consequently the overall performance. Solutions for coping with all these are left open and not standardized, so they’re vendor-specific and expected to be different from device to device.
Without being exhaustive, we mention here couple of key examples:
- Extensive signal processing and RF front-end design that could result in overheating, especially in non-standalone (NSA) scenarios operating simultaneously lower and higher frequency bands (including 3.5GHz); and
- Multiple antenna positioning, which could impair beam finding and/or synchronization, especially in mmW scenarios, but also possible for the F1 (a.k.a. sub 6Ghz) spectrum range in indoor settings.
Therefore, device-based testing is a must for accurate evaluations of the impact of a device’s behaviour on network and service performance as perceived by users when working with 5G NR networks.
Complementing Minimizing Drive Testing functionality
Minimizing Drive Testing (MDT) functionality emerged with long-term evolution (LTE)/4G. Due to the heavy signalling involved that can artificially affect network and device (e.g. battery life, memory) performance, it is designed to work only when triggered by a network event and/or location in the network. So it’s immediate and logged. Therefore, LTE MDT isn’t mandatory functionality for 3GPP and is consequently barely used.
5G NR is inherently designed more leanly with self-contained transmission, thus enabling an enhanced MDT (Rel 16+) functionality better suited for real-time optimization.
We must wait to see how 5G MDT will exactly be used, but regardless, MDT still remains at physical layers, with measurements not directly related to QoE information. Thus, device-based measurements continue to be the only accurate QoE data source.
Device-based testing to accommodate vendor-specific SON-embedded solutions
Enhanced Self Organizing Networks (SON) functionality, with both distributed and centralized use cases, is expected to be at the core of 5G NR. However, as with LTE, SON algorithms won’t be defined or standardized, and we very much expect behaviour and performance from vendor to vendor to be different. In addition, each vendor can decide which of the distributed SON use cases it covers and/or if a centralized SON solution comes along.
This means that there will be a requirement for device-based testing to evaluate the performance and quantify the benefits of distributed (e.g. ANR, MLB) and/or centralized (CCO)SON algorithms, as well as their effect on user experience of various services.
How drive testing needs to change for 5G
With all these factors in mind, it becomes clear that 5G NR drive testing needs to considerably change from what we are used to. But what would these changes be? We’ll go into more detail in the future but here’s an overview of some of the things that will revolutionize drive testing:
Predictive drive test probes
Testing probes need to move from reactive to more proactive, and consequently cutting off post-processing time in order to enable faster problem detection and performance correction. Consequently, predictive testing solutions will ensure real-time diagnosis with ML-based root-cause analysis and prediction, and edge computing with on-device processing. In addition, predictive-based drive testing can play a crucial role for various verticals, such as connected cars, for which the predictive connectivity is at the core of automotive safety measures.
The 3D beamforming enabled by the mMIMO systems in 5G NR call for 3D testing. Drone-based test probes need to be deployed for evaluating and analysing 3D coverage and performance (e.g. throughput, latency) for outdoor as well as unreachable indoor locations mainly for IoT use cases.
Fully controlled, automated and precise drive testing campaigns
With the increased network densification of 5G NR, drive testing campaigns must be remotely controlled and empowered by automated location and time-scheduled test scripts, along with real-time data collection and streaming to cloud-based orchestration and analytics solutions. In addition, drive testing campaigns need to come with real-time detection and reporting of equipment malfunctioning to avoid faulty measurements that can artificially affect network performance evaluation.
Along with remote control and automation, we’ll see drive testing campaigns transformed into ‘precision’ drive testing, respectively driving where it matters, such as areas with estimated increased traffic and/or with problems detected based on other data sources, such as planning, performance management (PM) and crowdsourced (CS) data.
Crowdsourcing testing methodology
It is well understood that drive testing and crowdsourcing are to a large extent complementary testing methodologies. In the long run, drive testing is expected to evolve towards more crowdsourcing-type methodology, but this evolution is fully dependent on strict constraints that need to be met, such as:
- Active testing being supported, along with all the passive measurements in CS;
- Statistically reliable CS data needing to be proved or verified, because having representative samples is statistically more reliable than having a very large number of samples (ITU-T E.812) – it’s expected that a ‘reliability score’ will be defined and should include measures of spatial and temporal consistency and coverage, of data fluctuations, and of variability, as well as have an absolute number of measuring values;
- Making crowdsourcing available in ‘directed and controlled’ areas of interest for specific tests; and
As we can see, there are several specific 5G NR characteristics, but the most important one is user-centricity, which makes drive testing highly relevant and needed for 5G NR testing.
However, significant transformation through remote control, automation, cloudification, prediction and precision is required in order for drive testing to rise to the challenges and requirements of 5G NR testing.
In future blog posts, we’ll go into more detail about what you need to know on how drive testing supports launching and deploying 5G NR, and helps you to stay ahead of the competition and prepare the best experience for your users.
This blog post is based on a section of a detailed white paper, which you can download here.