Bell Canada Launches Self-Serve Network as a Service

Bell Canada announced on 10 September the Bell On-Demand Network, which it describes as the country's first network-as-a-service platform aligned with the 7 customer experience attributes defined by Mplify, the industry body formerly known as MEF: on-demand, observable, manageable, programmable, secure, modular and flexible. TelecomTV carried the announcement in its 10 September roundup. The platform runs on Bell's fibre network with Cisco 8000 Series Secure Routers underneath, and the operator's description is that business customers can, through a single self-serve platform, "autonomously order, activate, manage and scale connectivity". The first product is On-Demand Internet, available in Ontario and Québec wherever Bell has deployed fibre, with additional networking, security, cloud connectivity and automation capabilities to follow. Bell's CTO Mark McDonald said customers "can now provision, scale and adjust their network in real time, getting the exact bandwidth and services they need, the moment they need them". No price, no provisioning time, no API documentation and no customer figure were published.

The customer configures, the operator does not pre-package

I have argued for some time that the natural end state of differentiated connectivity is slicing as a service: a platform through which third parties discover, configure, reserve and consume network resources on demand, because enterprise CIOs know their connectivity needs better than the operator does and are used to configuring cloud services rather than selecting from a catalogue. Bell's launch is that model applied to fixed access, and it is worth noting what is different from the 3 mobile launches of the past 3 weeks. EE sells a priority lane as a tariff, Vodafone sells a predefined quality profile through an API, and Telstra sells a slice for 1 application chosen by the operator. In each of those the operator decides what the product is and the customer decides whether to buy it. In Bell's description the customer decides the bandwidth and the timing, and the operator's role is to make the change when asked. That is the inversion the slicing-as-a-service argument depends on, and Bell states it as the product rather than as a roadmap.

Fixed first, because bandwidth on fibre is a reservation

It is not an accident that the self-serve model arrives on fibre before it arrives on mobile. When Vodafone launched quality on demand I wrote that a priority is not a reservation: a mobile profile improves the customer's place in the queue on a congested cell but does not guarantee what comes out of it, and the profile parameters were not published. On a dedicated fibre access line a bandwidth change is a reservation. The capacity exists, the router policy is deterministic, and the operator can honour the customer's chosen figure without a proof-of-value engine to check whether it did. That is why Bell can let the customer set the number and why the mobile operators cannot yet. It is also why the interesting part of Bell's roadmap is the part that is not launched: cloud connectivity and security are where the customer's requirement starts to depend on a second network and a second party, and the on-demand model will be tested at the first boundary it has to cross. Mplify's 7 attributes describe the customer's experience inside 1 provider's platform. They do not describe what happens when the customer's agent asks 2 providers for the same thing.

Programmable is the attribute that matters

Of the 7 attributes, 6 describe a good portal. The seventh, programmable, is the one that decides whether this is a self-serve web page or a network resource that a customer's own systems can consume. Bell's announcement describes a platform, not an API, and does not say whether the ordering, scaling and observability functions are exposed to the customer's software or only to a person logged into a portal. The distinction is the one I drew at DTW Ignite: the APIs that ship are the ones that ask the network a question, and the ones that ask it to change its behaviour on a third party's instruction are harder. On-Demand Internet is the second kind, in the easiest domain. If it is programmable in the Mplify sense, a customer's cloud automation or an enterprise agent can scale the access line up before a backup window and down after it without a human on either side, and Bell has built a resource the customer's software can reason about. If it is a portal, Bell has built a better ordering experience. The announcement does not say which, and it is the first thing a CIO evaluating it should ask.

What has not been published

No price relative to a standard business fibre contract, no provisioning time for a bandwidth change, no statement of whether the platform is API-accessible or portal-only, no minimum term or change frequency, no customer count and no date for the cloud connectivity and security capabilities. 4 things to watch. First, published API documentation, which is the test of the programmable attribute. Second, the price of a bandwidth change against the price of a permanent upgrade, because the on-demand model only pays for the customer if variable capacity is priced below fixed capacity over the period it is used. Third, whether Bell extends the same self-serve model to its mobile network, where it would need 5G standalone slicing and a service level of the kind Telstra attached to its slice. Fourth, whether the cloud connectivity capability, when it arrives, lets the customer configure the far end as well as the access line, which is the first crossing of an administrative boundary and the point at which slicing as a service stops being a single-operator product.

Agentic AI Could Raise Telco Opex by 30%

Two reports published on 10 September describe the same balance sheet from opposite ends. Bain & Company, as reported by Telecoms.com's Mary Lennighan, warns that operators could see operating costs rise by around 30% without any gain in productivity or growth if agentic AI is bolted onto legacy operating models. The consultancy describes an emerging agentic operating model in which traditional costs account for 70% to 80% of an operator's total and AI costs for 20% to 30%, with the risk that the legacy 70% to 80% never goes away. The same morning, TelecomTV's James Pearce published a second cut of the AI-Native Telco Index, the 276-page evaluation of 56 operators based on published material from January to June 2026, and found that 20 of the 56 frame their AI strategy primarily around revenue, 28 balance revenue and efficiency, and only 6 are primarily focused on efficiency. TelecomTV names the 6 as KPN, Proximus, Spark New Zealand, BT Group, Comcast and Rogers. It also notes, in the same article, that across all 56 operators cost savings remain the most clearly measured AI-related financial impact.

A new cost layer on top of the old one

Bain's argument is about arithmetic rather than technology. Model prices have fallen almost 10 times in the past year, according to the report, but token usage is rising faster as staff find new uses in network operations and customer care. At roughly half the token price, a 4.5 times increase in usage doubles the bill. The recommendation is to measure the cost of a business outcome, a resolved customer issue or a closed network incident, rather than the cost per token, and to hold someone accountable for model drift and token spend. AT&T is the worked example: it redesigned its orchestration so that large supervising agents delegate to smaller specialised models, which by AT&T's own account cut costs by up to 90% while tripling throughput. Bain's 3 cost traps are the token bill, the dual operating model in which human teams keep running the process while AI performs isolated tasks at the edges, and the low-risk demonstration that improves efficiency at the margin without touching the P&L. Internal chatbots, call summaries and copilots are named in the third category. This is the cost side of the 3 money flows I set out in July, when I argued that cost avoidance and revenue must be separated before an operator can say what AI is worth to it. Bain adds the point that cost avoidance is not automatic either: the avoided cost has to be removed from the organisation, and a process that is augmented rather than replaced removes nothing.

Revenue is the stated priority, savings are the measured one

The Index finding runs the other way. When I covered the first edition of the Index on 7 September the observation was that none of its 4 dimensions was financial. The second cut is TelecomTV's answer, and it is a useful one, because it reads the same public record for money rather than for capability. Of the 20 revenue-first operators, 11 are Tier 2 operators with annual revenues between $2 billion and $10 billion, 11 are in Asia and 4 in the Middle East, which TelecomTV reads as evidence that the shift toward AI revenue is not being led from Europe or North America. The examples with numbers attached are few. Bell Canada reported around C$700 million of AI-powered revenue in 2025, up 60%, and targets around C$2 billion a year by 2028. SK Telecom's AI datacentre business grew 92.5% year on year to 136.2 billion won in the second quarter, with AI B2B and B2C services at 61.3 billion won, up 24.5%. Indosat Ooredoo Hutchison reports sovereign AI cloud income separately, $28 million in 2025 with guidance of $60 million in 2026, and its Zankore joint venture with Nvidia, Nokia and Ooredoo raised $3.1 billion in debt this week to build 200 MW of GPU capacity by early 2027. On the efficiency side, KPN targets around €100 million a year in operating cost savings by 2030, Proximus folds AI into a €180 million efficiency programme, and Spark credits its churn model with reducing customer loss by up to 30%. TelecomTV also cites GSMA Intelligence's finding that only 35% of telco AI initiatives include a revenue objective. Read together, the picture is that revenue is what operators now say, savings are what they can measure, and 2 of the 3 operators publishing AI revenue lines, SK Telecom and Indosat, are selling compute or cloud capacity, which is the first of the 4 credible revenue lines in the July post and the one that looks least like a telecom service. Bell has not said what its C$700 million comprises.

The number the business case is missing

Put the 2 reports side by side and the missing figure is obvious. The Index counts operators that talk about revenue and reports the revenue lines that exist. Bain estimates the cost that agentic AI adds and warns that the legacy cost may stay. Neither report, and no operator in the Index, publishes both halves for the same company: AI-attributed revenue, AI-attributed savings actually removed from the cost base, and the AI compute and token cost that Bain says will make up 20% to 30% of the operating model. Bell's C$700 million is a revenue figure with no cost of sale attached to it in public. SK Telecom's AI datacentre revenue is real, but it is a hosting business whose margin is set by power and GPU depreciation, not by the network. KPN's €100 million is a 2030 target. Bain's own preferred use cases, autonomous network incident resolution and proactive churn prevention, are the workflows where the operator has to redesign the process end to end and retire what it replaces, and they are also the workflows where the data has to be fit for an agent to act on. Deutsche Telekom's Ahmed Hafez told the AI-Native Telco Forum on 8 September that DT's network data "is not ready" for machines and that data quality demands will start appearing in supplier RFQs, which is a cost that precedes any saving. Bain's framing is the right one for the report I am completing on autonomous networks: cost per resolved incident, before and after, with the platform, compute and data cost inside the denominator. That is the number that converts a proof into a P&L entry, and it is the number no one in the Index has yet published.

What has not been published

No operator has published AI revenue, AI savings and AI operating cost for the same period. Bell has not disclosed the composition of its C$700 million or the margin on it. AT&T's 90% cost reduction is its own account, relayed by Bain, with no base figure. The Bain report itself is available from Bain; the figures here are as reported by Telecoms.com. 4 things to watch. First, whether any of the 20 revenue-first operators reports AI compute or token spend alongside AI revenue in a quarterly filing, since that would be the first complete line item. Second, whether a legacy cost is visibly retired and attributed to agentic automation, in headcount, systems or supplier spend, rather than a saving being projected. Third, the on-demand recording of the AI-Native Telco Forum session on closing the attribution gap between deployment and financial outcomes, with Deutsche Telekom, Everpure and TM Forum, which TelecomTV says will be posted within days. Fourth, whether the 2027 edition of the Index adds a financial dimension and, if it does, whether it measures cost of outcome the way Bain proposes.

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.

TelecomTV Publishes First AI-Native Telco Index

TelecomTV published its first AI-Native Telco Index on 7 September, the day before its AI-Native Telco Forum opens in Düsseldorf. Ray Le Maistre's article describes a 276-page report assessing 56 operators against 4 dimensions, foundation readiness, strategic intent, execution evidence and transformation velocity, each made up of 5 indicators, using published evidence only, with a cut-off of 30 June 2026. The index assigns each operator 1 of 7 archetypes rather than a rank; the decision not to publish a league table was taken with the ANTA steering board, whose members come from Axiata, Deutsche Telekom, Orange, NTT Docomo and Rakuten Mobile. 9 operators are placed in the top archetype, AI Vanguard: AT&T, China Mobile, Deutsche Telekom, KDDI, NTT and NTT Docomo, Rakuten Mobile, SoftBank Corp, Telefónica and Verizon. 5 are Infrastructure Architects, 15 are Strategic Accelerators and 1 is at Transformation Pending. The stated rule is that "announce does not mean executed": a commitment is recorded as a commitment, and a deployment is recorded only where the operator has published something showing it is running. SK Telecom, which the article notes is often named the leading AI-native operator, is a Strategic Accelerator because many of its efforts were still at the planning stage at the end of June. A 12-page executive summary is free; the full index is available to ANTA partners and licence holders. This post works from TelecomTV's article; neither the summary nor the full report was read for it.

Most assessments of operator AI progress, including most vendor-sponsored surveys, score intent: budgets planned, priorities ranked, use cases identified. This index scores what has been published as running, and it records an announcement as an announcement. That is the distinction between field-validated and commercially validated that AI-RAN claims have needed for 2 years, applied here across the whole operator estate, and the SK Telecom result shows the rule working. An operator with a clear strategy, disclosed investment, revenue already generated and a large revenue target still lands below the top tier because its published evidence at the cut-off described plans rather than operations. Producing that result about the operator most often cited as the leader, in a report whose steering board includes 5 operators, is a sign the methodology was allowed to run.

No financial dimension yet

The 4 dimensions measure readiness, intent, execution and speed. None measures return. An operator reaches AI Vanguard by publishing the most evidence that AI systems are in production across its operations, and that is a real achievement, but it is the same class of evidence as the customer-experience award that TM Forum gave Google Fiber last week: proof that it works, not proof of what it is worth. The index is explicit that it measures transformation progress and not who is better, and that framing is useful, because it means nobody should read the Vanguard list as the operators making money from AI. I argued in July that most of what operators call AI monetization is cost avoidance, and that the discipline starts with refusing to aggregate cost saving, defended revenue and new revenue; an index that counts deployments without asking which of the 3 flows each one serves cannot make that separation either. The industry now has a reliable way to count deployments. It does not yet have a published operating cost per subscriber, per activation or per ticket, before and after, from any of the 9, and until one of them publishes that figure the index measures the input side of a business case whose output side remains an estimate.

Because the method admits only what an operator has published, an operator that publishes more scores higher, other things being equal. 4 of the 9 Vanguard operators are Japanese, 2 are American, 1 is Chinese and 2 are European, and 2 of the 9, NTT Docomo and Rakuten Mobile, sit on the steering board that shaped the method. The article says archetype assignment is an editorial judgement based on the evidence analysed, and there is no reason to doubt that. The point is narrower: operators with a corporate habit of publishing technical detail, and operators for whom the network is a marketing asset, will be over-represented at the top of any evidence-based index, and operators that run production AI quietly will be under-represented. The index cannot correct for that without abandoning its rule, and it should not abandon its rule. The caveat applies to every evidence-based index, this one included.

Everything the index can see is inside 1 operator's estate: its data foundations, its stated strategy, its deployments, its pace. That is the version of autonomy that ships, and it is where the evidence should be collected first. The next stage, in which an operator's network AI has to coordinate with an enterprise AI, a cloud provider's AI or another operator's AI, produces almost no published evidence yet, because the coordination layer that would make it work is the one I argued no runtime supplies and that NGMN has since itemised even for coordination inside a single operator. An index built on published deployments will show that stage as empty for some time, and the absence will be accurate. A future edition could usefully add an indicator for it: whether the operator has published any interface, ontology or audit model through which an external agent can act on its network, since the developer APIs alone do not answer that question.

What has not been published

The per-operator scores, the weighting of the 20 indicators, the definition of "running" used for execution evidence, and whether any indicator captures financial disclosure are all in the licensed report and not in the article. The 56-operator list is published; the archetype of each operator outside the 3 named tiers is not. 3 things to watch. First, whether the 2027 edition adds a return dimension, or an indicator for published cost or revenue attributable to AI, which would be the single most useful change to the method. Second, whether any of the 9 Vanguard operators publishes an operating cost figure for an automated domain against its pre-automation baseline in the next 12 months, since they are now on record as the operators with the most to show. Third, where SK Telecom lands next year: the article expects it to be among the strongest profiles, and if the planned efforts have become published deployments by then, the index will have shown it can measure movement and not only position.