At Telecom Europe LIVE, BT’s Mark Henry delved into APIs, VoNR, NaaS, carrier aggregation and more…
Mark Henry, Director of Network and Spectrum Strategy at BT, set out to answer the question, “How are we progressing with 5G Standalone?”. He stressed that this was indicative of where BT (and the wider industry is going) rather than official strategy or deployment plans.
He said private networks so far have been isolated infrastructure – “a network in a box on a customer’s premises”. Henry added, “Now we are moving to a model that is consumable as a service, although still with an on-prem build for certain elements, or a ‘private-lite’ network within the macro network”.
He added that there will also be a move from a connectivity-only set-up in private Standalone networks to more of a platform-like model; a shift from best effort regarding data (because of the lack of differentiation for types of traffic), to an end-to-end solution integrated with providers’ networks. Another step will be to have more diverse models than today.
What are the components of Standalone?
He said the four essential components of a Standalone private network are
• the SIM,
• Standalone-capable devices,
• RAN with 4-carrier aggregation to deliver service equivalent to non-Standalone but this isn’t available yet, but BT has upgraded the RAN in much of the country in readiness for Standalone with 10,000 more sites to go. Henry said he expects BT to achieve non-Standalone equivalence soon.
• 5G core.
Henry clearly and succinctly reminded us of the differences between the extended packet core (EPC) and 5G Standalone (and non-Standalone). BT, like many others, originally planned to launch 5G Standalone without deploying non-Standalone first. This was changed to get to market faster in places outside Europe [such as South Korea for the Olympic Games] and it did help operators derive value faster.
Now 5G is reaching maturity and we are entering the age of Standalone, Henry talked us through the benefits it brings: greater coverage at less cost including in-building with 700MHz; making better use of spectrum; greater reliability; and lower latency, with about a 10ms improvement. Trials are underway.
Network-as-a-Service is the goal
He said the big motivation was to be able to move from connectivity to delivering the Network-as a-Service (NaaS) and explored what advantages it brings for consumers and businesses, such as offering network slices and bringing far more intelligence to bear regarding how the network is used and move away from best effort.
He looked at the much used example of a gamer on a train who has subscribed to a reliable slice and what that means from the service providers’ point of view.
Voice might go via VoNR and a guaranteed quality uplink is used to stream to Twitch. Commuters pile in at a station who use best effort data, the gamer’s service is not disrupted. Then more commuters join who have also paid for guaranteed service which takes bandwidth away from best effort data customers. Gamer is unaffected.
If the train breaks down in a tunnel, then the network will try to give people enough resources to support all users and so the game stops working and perhaps the uplink fails. Only voice continues. So we will make things better but not 100% guarantee with radio unless you’re in a controlled environment, such as a private network.
How much must operators reserve for best effort data is not yet defined, although BT has been talking to the regulator about network slicing for about two years.
OneAPI will not rule them all
Other areas that are not ironed out are the APIs for exposing platform-based services in the core, as Titan.ium’s Patrik Rokyta pointed out. Henry said so far BT has built the service capability exposure function (SCEF) and the network exposure function (NEF), but think there should be a layer in between and we have an API management platform for existing APIs, so that’s probably the thing we’ll go through. There might be some mediation between the NEF and the SCEF to get to a successful set of APIs.
He said that he thought the OneAPI initiative is potentially the wrong approach, as there are thousands of APIs that are consumable, although he agreed you have to start with one that’s successful. He added that the [GSMA’s] CAMARA APIs overlap with “a whole bunch we’ve already done…so we’re fully behind that one and would like to see it successful. They can’t be proprietary, that won’t work. That’s my recommendation.”
Fast and slow progress
Francis Haysome of Appledore Consulting asked, “About the architecture, developers think it’s about minimal viable product and Agile. Which parts of this do you thinnk will be implemented quicker?”
Henry believes NaaS will happen, with the app stores as gatekeepers and that developers won’t want to talk to all the telcos, that part will come through aggregation and the software, so they can consume a standard API. The ecosystem will grow, but will be the slower part.
Another member of the audience asked about VoNR, noting that operators have been struggling to deploy VoLTE, especially in a roaming environment. Dimensioning a voice network is difficult, so how will operators cope with VoNR plus VoLTE plus legacy? This is extremely complex, different spectrums and capacities to deal with and on top of that, fallback strategies.
Henry agreed, “It is horribly complex but if you do fallbacks, you have to support them forever because there’s a device that needs fallbacks to work. Our approach is to VoNR is that every Standalone device deployed on our network must be upgradable to VoNR when it’s available and mature. Regarding VoLTE and roaming and all the rest of the question, that’s another presentation in itself. I can only say this time it will be different because we’ve already built the IMS.”