• Senior BT execs say new technology should respond to consumer, industry needs.
  • No appetite for a “step change” in radio; 5G backwards compatibility a must.
  • Coverage, reliability more promising areas for 6G improvement than peak data rates.


BT wants 6G to solve real-world problems

Source: NASA/Unsplash

Maria Cuevas and Paul Crane, both senior BT executives, saw pragmatism as a guiding principle for 6G R&D. Speaking on two separate and recent webinars, their messages were nonetheless near‑identical: forget any fanciful notion of ‘build‑it‑and-they-will‑come’, they indicated, and respond to what the market actually demands.

“[6G] is not simply setting a ten-times better target than 5G but solving real‑world problems”, said Cuevas, Principal Manager of Mobile and 5G Research at BT Labs.

Crane, Converged Network Research Director at BT, said the timing of 6G’s arrival will largely be determined by “when there’s a market need”.

No step change, thank you very much

Cuevas, speaking on a panel session at SMART: 2021 Future Networks Research Conference, which explored testbed requirements for 6G, stressed that “native support for 5G NR [New Radio]‑capable devices should be a design principle for 6G from the outset”.

Warming to her 5G backwards-compatibility theme, Cuevas said BT — much like other operators — does not want another radio introduced into the network that does not support previous devices, and that an upgrade path from 5G is essential.

“ We don’t want a step change in our networks. Whether it’s extending 5G NR into 6G, or co‑existence in some form of dynamic spectrum sharing arrangement, that has still to be seen. ”

— Cuevas.

Crane, taking part in a 6G Research & Innovation Summit roundtable discussion hosted by TelecomTV, also referenced “step change” as something industry needed to avoid. There was an imperative, he argued, to buck the trend of previous new cellular technologies that failed to provide backwards compatibility with the generation before. Crane pointedly added it was “very early days for 5G”, and that, when factoring in advances of the technology coming through the pipeline, it “will be with us for another 20 years”.

“ What we need to do now is look at not only the technologies we will be deploying in ten, 15, and 20 years’ time, but equally importantly look at how we go about doing that. We can avoid that step change and have a much more evolutionary approach where operators like ourselves can implement technology when there’s actual market demand, rather than building before demand. ”

— Crane.

Big‑picture thinking

Cuevas outlined various 6G testbed requirements, but put particular emphasis on measuring “practical performance rather than theoretical performance”. “Hardware emulation”, she said, “was more useful than computer simulation”.

Other new testbed requirements were needed, asserted Cuevas. “With highly distributed architectures, we need to evolve our testbed capabilities to explore the issues we need to overcome, which include the need to orchestrate over different domains”, she explained. “Timing and sync capabilities are going to become increasingly important to do that”.

Crane touched, too, on a network architecture evolution. “In five to ten years’ time, we will be thinking about a network as a set of distributed compute resource, which is running both network functionality and application functionality”, he noted. “The control of that, and automation of that control, is going to be crucially important”.


Paul Harris, Senior Standards Strategist at Vodafone — and co‑panellist with Cuevas — was in full agreement with BT’s desire to sweat 5G investment as much as possible, and not to get too focused on 6G data rates and “gutting” current radio systems in the process.

He argued that current 5G NR will deliver what is expected of 6G in terms of “practical speeds”, and that industry was “rapidly approaching theoretical limits of radio techniques”.

Harris’s views chimed with Crane’s, who thought “coverage and reliability” would be more fruitful areas of 6G improvement than peak data rates.