Telstra Sells a Network Slice for Microsoft Teams

Telecoms.com's Nick Wood reported on 7 September that Telstra has launched Dynamic 5G for Video Calling, a business service that directs Microsoft Teams traffic onto a dedicated slice of its 5G network so that calls do not compete with other traffic during peak periods. Telstra's own description is that it "represents a move toward application-aware, business-grade connectivity, designed to prioritise performance for selected traffic, not just speeds." The operator names construction, utilities, transport and logistics as the sectors it is aimed at, where staff are on the move, temporarily located or in the field. Dynamic 5G is the umbrella brand Telstra launched for business slicing in 2025, and its distinguishing feature is a proof-of-value engine that monitors slicing traffic continuously and checks whether the customer is receiving the service promised; if it falls short, the customer does not pay. Telecoms.com sets the launch against T-Mobile US's SuperMobile business tariff, Deutsche Telekom's gaming and video-calling slices, EE's Fast Lane and VodafoneThree's SuperMobile in the UK, and cites ABI Research's forecast that the slicing market will grow from $6.1 billion in 2025 to $67.5 billion in 2030. No price, no slice parameters and no customer count were published.

3 slicing products in 3 weeks, sold 3 ways

Since 20 August, 3 operators have put differentiated network quality on sale in 3 different forms. EE sells a priority lane to consumers as a handset tariff, which I covered when Fast Lane launched. Vodafone sells a quality profile to developers through an API in Germany, without a price or a published profile. Telstra sells a slice to enterprises per application, with the application chosen by the operator and the enterprise buying the outcome. These are the 3 channels through which an operator can sell the same underlying capability, and it is useful to have all 3 on the market at once because they will produce different evidence. The tariff channel will produce an attach rate. The API channel will produce a call volume. The enterprise channel will produce a contract with a service commitment in it, and that is the only one of the 3 that forces the operator to state what the slice delivers.

The SLA clause is the news

When Vodafone launched quality on demand yesterday I wrote that the first thing a serious enterprise buyer would ask for was a service level, because a priority is not a reservation and a profile without published parameters tells the buyer nothing about what it is paying for. Telstra's answer is the proof-of-value engine. It does not publish the parameters either, at least not in what has been reported, but it commits to measuring the slice against what was promised and to not charging when the promise is missed. That is a commercially meaningful difference. It converts a best-effort improvement into a product with a defined failure condition, and it means Telstra is now generating, internally, a number no slicing launch to date has disclosed: how often a commercial slice fails to deliver what the customer bought. The pay-out rate of that engine is the honest measure of whether slicing works on a live network, and Telstra has built the instrument that produces it. Whether it will ever publish it is another matter, but the number now exists somewhere, which was not true of any of the other launches.

Application-aware means the operator picks the application

The product is sold for Teams, and only Teams. That is a practical choice, since Microsoft publishes the network endpoints its services use, which is what allows an operator to steer that traffic onto a slice without inspecting its content, and it is the application that a construction firm's site manager or a utility's field crew is most likely to be on. But it also shows where the operator's own control ends. Telstra decides which application qualifies, does the classification itself, and holds the only billing relationship. Microsoft is not a party to the arrangement, and the customer cannot extend the slice to another application without Telstra adding it. This is the same pattern that Fast Lane and the Vodafone API follow: the service is possible because it stays inside 1 administrative domain, with no counterparty to negotiate with and no shared model to agree. An enterprise that wants its own collaboration tool, its own robotics controller or its own agent to request the slice on demand, and to verify for itself that the promise was kept, is asking for the coordination layer that I argued no runtime supplies. The proof-of-value engine is a step toward it, because it is an audit trail, but it is Telstra's audit trail, read by Telstra, and the customer sees only the invoice it produces.

When Will We See Slicing as a Service?

I have been arguing for years that the natural fulfillment of the differentiated connectivity 5G promise would be slicing as a service. Specifically, network operators who will find themselves with ample capacity should create a platform that would allow third party to discover, configure, reserve and consume network resources on demand. Enterprise and government CIOs know better than telecom operators what their connectivity needs are and how they are going to evolve. They do not want to select a pre packaged slice that my correspond to some conditions or services at some point in time. They do not want to spend time educating the operator about their needs, because some of them are proprietary and become differentiating factors and they evolve over time. They are used to configuring cloud services. It is time for connectivity services to catch up.

Vodafone Launches Quality on Demand API in Germany

Vodafone announced on 7 September that its Quality on Demand network API is commercially available in Germany, the first market to get it, with more countries to follow. Light Reading's Tereza Krásová and Telecoms.com's Andrew Wooden both carried the release the same day. The API lets a business or developer select a predefined profile with specific network parameters for a customer's connection over Vodafone's 4G and 5G networks, and the release says the customer can choose the bandwidth level they need for as long as they need it. The example given is a payment provider whose card terminals keep processing transactions in a crowded stadium, concert or festival. Vodafone says it is running a proof of concept with a German broadcaster, not named, covering a football match with push-to-talk between production crew and return video over the mobile network, and it invites developers to propose applications in entertainment, transport, emergency response and remote maintenance. Johanna Wood, Vodafone's director of network APIs, said people use their phones for shopping, banking, public services and entertainment "around ten times a day" and that the API lets businesses "tailor network quality dynamically for specific use cases." The release places the launch inside the GSMA Open Gateway programme Vodafone joined in 2024, says the API follows a common industry standard so customers can scale it worldwide, and positions it alongside Vodafone's SIM Swap and Number Verify APIs, dedicated 5G slices and private networks. Telecoms.com notes that Number Verify 2.0 launched in Germany, the Netherlands and the UK in July. No price was published.

This is the launch the Open Gateway programme was built around

When EE put a consumer network slice on sale last month, I listed as 1 of 4 things to watch whether the same capability would show up as a priced quality-on-demand API through Open Gateway. 17 days later it has shown up, without a price. That is still a milestone. Quality on demand was the API the whole programme was designed to showcase, the one that would prove a network could sell a differentiated attribute to a developer rather than a bigger data bucket to a subscriber, and it has been the slowest of the 4 headline APIs to reach commercial availability anywhere. The APIs that did ship first were single-attribute lookups, number verification, SIM swap, location, the class I argued at DTW Ignite was the class that ships because it asks the network a question rather than asking it to change its behaviour. A group operator making quality on demand generally available in its largest European market moves the harder API into the same category, and that should be recorded before the rest. It is consistent with the position I set out in July, that network APIs are the earliest-stage of the credible new revenue lines, worth investing in for position while sizing near-term revenue with restraint.

The buyer is a payment provider whose customers are on 3 networks

The structural difference from EE's Fast Lane is who is paying. EE sells the attribute to its own subscriber, through a tariff, and the subscriber is on EE by definition. Vodafone sells it to a third party, and the third party's end users are spread across Vodafone, Telekom and O2 in roughly the proportions of the German market. A card-terminal vendor at a stadium can buy uninterrupted payments only for the share of its terminals, or its customers' phones, that happen to be on Vodafone. For the developer, the API is worth Vodafone's market share until somebody aggregates it, and the release addresses that by saying the API follows a common standard and so scales worldwide. A common interface is not a common network. The standard makes the developer's call portable; it does not make the other 2 German operators answer it, and the aggregation layer the operators created for exactly this purpose is not mentioned in the release. The developer proposition for quality on demand in Germany is therefore still a partial one, and the launch is best read as Vodafone establishing its own endpoint ahead of whatever the 3 operators eventually offer together.

4G and 5G tells you what the product is

Fast Lane runs on EE's 5G standalone core and moves the customer onto a dedicated slice. Vodafone's API works over 4G and 5G, which means it is not a slice. It is a policy applied to the session, a prioritised bearer with a profile attached, of the kind mobile networks have been able to set for years and have rarely exposed to anyone outside the operator. That is why it can launch nationally now rather than waiting for standalone coverage, and it is also why the release describes the result as stable and high-performing rather than as a number. A priority is not a reservation. It improves the customer's position in the queue on a congested cell; it does not guarantee what comes out of the queue, and the profile parameters that would let a buyer know what it is paying for are not published. VodafoneThree's SuperMobile slice in the UK, launched last week, attached a published minimum speed to its consumer product. The German API, sold to businesses that will build service commitments of their own on top of it, has not yet done the same, and that is the first thing a serious enterprise buyer will ask for.

It ships because it stays inside 1 estate

The pattern from Fast Lane holds here in a different form. Quality on demand as launched is a bounded request inside a single administrative domain: 1 operator, 1 profile, 1 session, 1 billing relationship with the developer. No counterparty negotiates the profile, no ontology has to be agreed across an ownership boundary, and no audit trail has to be accepted by 2 parties. That is the class of capability I argued no runtime supplies the coordination for and that therefore ships only when the coordination is not needed. The question the API opens, and does not answer, is what happens when the buyer is not a developer but a system: a checkout agent, a delivery routing engine, a broadcaster's production controller deciding per session whether a given profile is worth its price against a given cell load. At that point the network's AI and the customer's AI are negotiating a resource across a boundary, and the API gives them a verb without giving them a shared model of what the verb commits either side to. Vodafone's release does not address that case, and it is the case its enterprise customers will bring first.

What has not been published

No price, no pricing unit, no profile parameters, no service level or remedy, no named paying customer, no statement of what the profile delivers on a cell that is already saturated, which is the only condition under which the product matters, and no volume figure from the July Number Verify launch that would indicate what developer uptake of Vodafone's APIs looks like. The broadcaster proof of concept is unnamed and uncosted. 4 things to watch. First, a price list, because the moment quality on demand has a published unit price it becomes possible to compare the developer channel against the tariff channel EE chose. Second, whether the 3 German operators offer a single quality on demand call, through the aggregator or bilaterally, since that is the point at which the payment provider's business case stops being a fraction. Third, the first named enterprise customer with a transaction volume, which would be the first demand-side evidence for the API the programme was built around. Fourth, whether Vodafone Germany also sells the same profile to consumers as a tariff, because an operator that does both is telling the market which channel it thinks the capability belongs in.