There’s a misconception that 5G drive testing will become redundant. The complexity of multiple layers of networks, the flood of new services and the device centric approach of 5G makes RF engineers a scarce resource. Investments in 5G are huge, resulting in tight deadlines and shorter time to market than ever. This network complexity combined with the proliferation of device types means that traditional drive testing processes are not fit-for-purpose.
The industry has a longer-term vision of a fully autonomous network. Indeed, the inclusion of ‘minimization of drive testing’ (MDT) features in 5G could be seen as suggesting that the end of the drive test in telecoms is nigh.
But while there can be no doubt that very nature of 5G networks makes legacy manual testing no longer a realistic or practical option and that operators can’t afford for their highly qualified RF engineers to be driving around manually testing, this does not mean the end of drive testing for 5G networks.
Although enhanced from LTE, the minimization of drive testing feature in 5G still only works if users are in the geographic area that requires testing, meaning drive testing will still be needed to complement the gaps of MDT, at least until the 5G network is fully autonomous.
The question therefore has to be: how can operators automate the drive testing process from being engineering driven to AI/ML data driven, from manual to autonomous and from something very few can do to something that can be done by anyone?
5G drive testing must become AI/ML data driven and automated
So – how is this done?
It all begins with knowing what, where and when to test. In many cases this is no mystery. Validating a new feature, a site or troubleshooting a problem, perhaps a benchmarking campaign; all these can prompt a decision to undertake testing. Only today, this decision-making process is one that this includes e-mails, phone calls and perhaps meetings.
What if – the site acceptance was automatically triggered by the new site being setup, and fed as an assignment to the Drive Testing team including the optimal drive route and acceptance criteria?
In this use case of Automated Single Site Verification (Automated SSV), the tester only needs to follow drive instructions while the application takes care of setting up the test, evaluating the collected data until acceptance was met, and the result available instantly when collected.
This isn’t a utopian view of the future. 5G operators are doing this today, using our Automated SSV use case based on TEMS Cloud, and including new Precision Drive Testing™ features that automate what, where and how to test.
What does automated workflow look like? For illustration, a basic one could look like this:
- Triggering the test – this can be done from any existing data source, planning, network or customer centric. In the case of Site Acceptance, it’s the Site information; in its simplest form – a file.
- The assignment includes what to test – as example – voice call, speed tests, mobility, latency. A pre-set test package for the use case.
- The assignment points to where to test. The site!
- The assignment is distributed to the correct team, with the correct equipment. Where the testers perform the test.
- The testers follow the instructions on the test device, telling them where to go, if to stay and when the test is completed.
- The result is fed back to the requester.
What’s under the hood of Precision Drive Testing™?
Let’s look a bit closer at our patent-pending Precision Drive Testing™ methodology and system.
Precision Drive Testing routines can be automatically triggered by use cases based on information and/or analytics results from network planning and performance management, services assurance, and customers’ data. Using this information combined with ML/AI techniques, Precision Drive Testing will calculate the best test route, what drive tests to perform and define the work order for each individual testing use case and process.
The trigger of the use case includes the automatic generation of:
- Use case specific tests scripts
- Definition of Done Criteria
- Context sensitive testing
- Log masks
- Automatic creation of sweet spots and drive routes
- Directions to the tester including error handling and Edge Analytics
- Instant reporting/data feed of the expected result
1. Use case specific tests
For the use case to be fulfilled, you will have to perform certain tests, like a specific number of voice calls with a pre-defined speech quality per call; or validating the throughput and/or latency towards a threshold. All these tests used to be defined manually and could even differ between engineering teams or engineers. Centralizing this, with a pre-set template for what tests to perform saves a lot of time for the tester, as well as the administrator and reduces the time needed to create, distribute and store test scripts.
In the example of Automated Single Site Verification, the application takes responsibility for creating the detailed test scripts automatically with locking functions and ensuring testing all PCIs. This saves time.
2. Definition of Done Criteria
It is very well known that in drive testing it is crucial to collect everything you need the first time. In order to do that, each use case also comes with Definition of Done criteria, such as number of voice and/or data calls, thresholds for signal strength or any other KPI you need to verify to execute a specific drive test use case. These DoD criteria are instantly evaluated at the edge, on the collection device itself. The tester will be informed where to go and once the DoD criteria are met, he is informed that the assignment is completed. This saves time as all data will be collected, neither more, nor less. Time saver!
3. Context sensitive testing
While performing tests, the application itself evaluates the network parameters, and criteria used to perform the correct test towards the correct criteria. Typical example would be speed tests that would differ for 4G vs 5G.
4. Log masks
This is a sensitive topic as the normal way to drive test is to collect everything at all times; but the fact is that different drive test use cases rely on different depth of data. Instead of collecting everything everywhere – you will get exactly what you need, saving network resources, storage and getting your results instantly.
5. Sweet spots & drive routes
Based on the Assignment given, there is also a clear view on where to test. But what is the optimal route? Taking a data driven approach, this can be calculated or even decided in real time. Going back to the example of Site Verification there are a few methods that you can use – you can of course just go to the center of the sector and hope for the best – but if you use predicted best spots from your planning data, or even scouted best spots, you would be much more likely to get your tests done as quickly as possible.
6. Directions and support for the tester
OK, so if the engineers are busy doing other things, then the tester will need really good instructions? Yes, they do. And yes, we provide these. The tester should only care about following instructions such as where to go, for how long to stay and when to move on. With instant feedback on when the DoD criteria are met so that next step can be taken, the test is completed in the shortest time possible. This allows for anyone to carry the test device, even a drone, as the directions can be fed into a machine. The evaluation towards the DoD criteria is done at the edge, at the same time keeping an eye on the test device if there is risk for high temperature or anything else that could impact the test result. The tester would then be notified on what actions to take before proceeding.
7. Instant reporting
Post processing is very good, but the word “post” is a bit worrying. Especially when talking about the need for shorter time to result. The data feed from the tester needs to be instant, to quickly close the loop of the assignment, resulting in fixing the problem, completing the task and getting ready for next step. The receiver of the result, be it man or machine, should be able to take the necessary action at the same time as the DoD is met.
Test equipment
Finally, we have to talk about the test equipment. One of the key differences between crowdsourced data and drive test data is that drive testing allows you to select what device is used to collect the data. The device with the right capabilities and quality will deliver the decision support needed.
The trick here is that you can still use a commercial off-the-shelf device. By utilizing our “diag logging kit” most commercial devices can be turned into a reliable, controlled test device.
The implications of this are significant. Not only can you now provide high quality clean data without the risk of “anyone” walking off with expensive test equipment, but it means that “anyone” can do the testing for you. It doesn’t have to be the experienced RF engineer, who could and should be deployed working on core engineering tasks such as RF optimization. Instead, it can be done by drone operators, even Uber drivers – essentially anyone with a smartphone.
5G demands that drive testing is transformed from engineering driven to data driven, from manual to autonomous and from something very few can do to something that can be done by anyone.
Precision Drive Testing brings a ML/AI based data-driven approach and automation to network testing, significantly reducing the cost and time of network performance and service assurance management and optimization. This has a crucial role for accelerating 5G deployments. Integrating 5G network data into RAN planning and automated assurance and operations, it doesn’t just automate 5G testing, it increases the speed and accuracy of 5G testing processes.
For more information on Precision Drive Testing™, and how it can help you accelerate your 5G roll-out, read our site verification solution brief or contact your local Infovista TEMS representative to get a quote.
