Tag: optimisation

Telco digital twins: Cool tech or real value?

Definition of a digital twin

Digital twin is a familiar term with a well-known definition in industrial settings. However, in a telco setting it is useful to define what it is and how it differs from a standard piece of modelling. This research discusses the definition of a digital twin and concludes with a detailed taxonomy.

An archetypical digital twin:

  • models a single entity/system (for example, a cell site).
  • creates a digital representation of this entity/system, which can be either a physical object, process, organisation, person or abstraction (details of the cell-site topology or the part numbers of components that make up the site).
  • has exactly one twin per thing (each cell site can be modelled separately).
  • updates (either continuously, intermittently or as needed) to mirror the current state of this thing. For example, the cell sitescurrent performance given customer behavior.

In addition:

  • multiple digital twins can be aggregated to form a composite view (the impact of network changes on cell sitesin an area).
  • the data coming into the digital twin can drive various types of analytics (typically digital simulations and models) within the twin itself – or could transit from one or multiple digital twins to a third-party application (for example, capacity management analytics).
  • the resulting analysis has a range of immediate uses, such as feeding into downstream actuators, or it can be stored for future use, for instance mimicking scenarios for testingwithout affecting any live applications.
  • a digital twin is directly linked to the original, which means it can enable a two-way interaction. Not only can a twin allow others to read its own data, but it can transmit questions or commands back to the original asset.

Enter your details below to download an extract of the report

What is the purpose of a digital twin?

This research uses the phrase “archetypical twin” to describe the most mature twin category, which can be found in manufacturing, operations, construction, maintenance and operating environments. These have been around in different levels of sophistication for the last 10 years or so and are expected to be widely available and mature in the next five years. Their main purpose is to act as a proxy for an asset, so that applications wanting data about the asset can connect directly to the digital twin rather than having to connect directly with the asset. In these environments, digital twins tend to be deployed for expensive and complex equipment which needs to operate efficiently and without significant down time. For example, jet engines or other complex equipment. In the telco, the most immediate use case for an archetypical twin is to model the cell tower and associated Radio Access Network (RAN) electronics and supporting equipment.

The adoption of digital twins should be seen as an evolution from today’s AI models

digital-twins-evolution-of-todays-ai-models-stl-partners

*See report for detailed graphic.

Source: STL Partners

 

At the other end of the maturity curve from the archetypical twin, is the “digital twin of the organisation” (DTO). This is a virtual model of a department, business unit, organisation or whole enterprise that management can use to support specific financial or other decision-making processes. It uses the same design pattern and thinking of a twin of a physical object but brings in a variety of operational or contextual data to model a “non-physical” thing. In interviews for this research, the consensus was that these were not an initial priority for telcos and, indeed, conceptually it was not totally clear whether the benefits make them a must-have for telcos in the mid-term either.

As the telecoms industry is still in the exploratory and trial phase with digital twins, there are a series of initial deployments which, when looked at, raise a somewhat semantic question about whether a digital representation of an asset (for example, a network function) or a system (for example, a core network) is really a digital twin or actually just an organic development of AI models that have been used in telcos for some time. Referring to this as the “digital twin/model” continuum, the graphic above shows the characteristics of an archetypical twin compared to that of a typical model.

The most important takeaway from this graphic are the factors on the right-hand side that make a digital twin potentially much more complex and resource hungry than a model. How important it is to distinguish an archetypical twin from a hybrid digital twin/model may come down to “marketing creep”, where deployments tend to get described as digital twins whether they exhibit many of the features of the archtypical twin or not. This creep will be exacerbated by telcos’ needs, which are not primarily focused on emulating physical assets such as engines or robots but on monitoring complex processes (for example, networks), which have individual assets (for example, network functions, physical equipment) that may not need as much detailed monitoring as individual components in an airplane engine. As a result, the telecoms industry could deploy digital twin/models far more extensively than full digital twins.

Table of contents

  • Executive Summary
    • Choosing where to start
    • Complexity: The biggest short-term barrier
    • Building an early-days digital twin portfolio
  • Introduction
    • Definition of a digital twin
    • What is the purpose of a digital twin?
    • A digital twin taxonomy
  • Planning a digital twin deployment
    • Network testing
    • Radio and network planning
    • Cell site management
    • KPIs for network management
    • Fraud prediction
    • Product catalogue
    • Digital twins within partner ecosystems
    • Digital twins of services
    • Data for customer digital twins
    • Customer experience messaging
    • Vertical-specific digital twins
  • Drivers and barriers to uptake of digital twins
    • Drivers
    • Barriers
  • Conclusion: Creating a digital twin strategy
    • Immediate strategy for day 1 deployment
    • Long-term strategy

Related research

Enter your details below to download an extract of the report

The value of analytics, automation and AI for telcos Part 1: The telco A3 application map

Getting to grips with A3

Almost every telco is at some stage of trying to apply analytics, artificial intelligence (AI) and automation (A3) across its organisation and extended value network to improve business results, efficiency and organisational agility.

However, most telcos have taken a fairly scatter-gun approach to deploying these three interrelating technologies, with limited alignment or collaboration across different parts of the business. To become more sophisticated in their adoption of A3, telcos need to develop a C-level plan to manage deployments, empower business units supporting A3 to efficiently deploy resources, and create cross-functional implementations of these technologies.

The first report in this two-part report series supports telcos in this aim through a high-level mapping of the application areas which can be developed by a telco. It illustrates the opportunities and forms the foundation of our ongoing research in A3.

In the second part of the series, we estimate the potential financial value of each of the A3 application areas for telcos. The follow up is now available here: A3 for telcos: Mapping the financial value 

This research builds on STL’s previous reports covering telcos’ early efforts in implementing analytics, AI and automation within specific parts of their operations, as well as benchmarking their progress globally:

Introducing the telco A3 application map

The first section of this report goes further into the use of different types of A3 in the Telco A3 applications map. Our analysis focuses in turn on the six types of problems that are being addressed and how automation, analytics and/or AI can provide solutions – and for which types of problems and in which parts of a telco’s business each of these three technologies can have the greatest impact.

Summarising the six types of problems A3 can help with:

  1. Making sense of complex data – using analytics and ML to identify patterns, diagnose problems and predict/prescribe resolutions
  2. Automating processes – where intelligent automation and RPA helps with decision making, orchestration and completing tasks within telco processes
  3. Personalising customer interactions – where analytics and ML can be used to understand customer data, create segmentation, identify triggers and prescribe actions
  4. Supporting business planning – where analytics and ML can be used in forecasting demand and optimising use of existing assets and future investments
  5. Augmenting human capabilities – this is where AI solutions such as natural language processing and text analytics are used to ‘understand’ and act on human intent or sentiment, or surface information to customers and employees more quickly
  6. Frontier AI solutions – cutting edge AI solutions which have specialist uses within a telco, but are not widely adopted yet

Following our analysis of the key application areas, we look at how A3 is used not only for the individual parts of the business illustrated in the map, but how more sophisticated implementations require significant integration and interdependencies between A3 solutions across multiple areas of a telco’s operations.

It should be noted that this two-part series only considers the application of A3 to telcos’ internal operations and we will consider both the external monetisation of such services and their use in telco products in follow-up reports.

Enter your details below to request an extract of the report

How telcos should use the A3 map

  • Innovation teams within the telco should consider plotting their existing and planned A3 activities on a map such as that shown below
  • This map should be presented to the board and also socialised within IT and support teams such as customer care. It can be used to describe current top-level focus areas and those which are more nascent but considered key in the short and medium-term
  • The map can also be shared with vendor partners and other interested external parties to ensure that they are aware of the company’s priorities.

Table of contents

  • Executive Summary
  • Introduction
  • The A3 problem/solution types
    • Type 1: Complex data uses A3 to conquer size and speed
    • Type 2: Automation to replace or augment human resources
    • Type 3: Personalisation uses algorithms to reveal what’s next
    • Type 4: Bringing optimisation and forecasting into planning
    • Type 5: Augmenting human capabilities focuses on chatbots
    • Type 6: Frontier AI solutions are the leading edge of the A3 future
  • Cross-type applications of A3
    • Concept 1: Sharing data between boxes using a data lake
    • Concept 2: The flow of data across different A3 application areas
  • Appendix 1: Further definition of applications by type
    • Type 1: Making sense of complex data
    • Type 2: Automating processes
    • Type 3: Personalising customer interactions
    • Type 4: Supporting business planning
    • Type 5: Augmenting human capabilities
    • Type 6: Frontier AI solutions
  • Appendix 2

Enter your details below to request an extract of the report

Broadband 2.0: Mobile CDNs and video distribution

Summary: Content Delivery Networks (CDNs) are becoming familiar in the fixed broadband world as a means to improve the experience and reduce the costs of delivering bulky data like online video to end-users. Is there now a compelling need for their mobile equivalents, and if so, should operators partner with existing players or build / buy their own? (August 2011, Executive Briefing Service, Future of the Networks Stream).
 Telco 2.0 Mobile CDN Schematic Small
  Read in Full (Members only)    Buy This Report    To Subscribe

Below is an extract from this 25 page Telco 2.0 Report that can be downloaded in full in PDF format by members of the Telco 2.0 Executive Briefing service and Future Networks Stream here. Non-members can buy a Single User license for this report online here for £595 (+VAT) or subscribe here. For multiple user licenses, or to find out about interactive strategy workshops on this topic, please email contact@telco2.net or call +44 (0) 207 247 5003.

To share this article easily, please click:

//

Introduction

As is widely documented, mobile networks are witnessing huge growth in the volumes of 3G/4G data traffic, primarily from laptops, smartphones and tablets. While Telco 2.0 is wary of some of the headline shock-statistics about forecast “exponential” growth, or “data tsunamis” driven by ravenous consumption of video applications, there is certainly a fast-growing appetite for use of mobile broadband.

That said, many of the actual problems of congestion today can be pinpointed either to a handful of busy cells at peak hour – or, often, the inability of the network to deal with the signalling load from chatty applications or “aggressive” devices, rather than the “tonnage” of traffic. Another large trend in mobile data is the use of transient, individual-centric flows from specific apps or communications tools such as social networking and messaging.

But “tonnage” is not completely irrelevant. Despite the diversity, there is still an inexorable rise in the use of mobile devices for “big chunks” of data, especially the special class of software commonly known as “content” – typically popular/curated standalone video clips or programmes, or streamed music. Images (especially those in web pages) and application files such as software updates fit into a similar group – sizeable lumps of data downloaded by many individuals across the operator’s network.

This one-to-many nature of most types of bulk content highlights inefficiencies in the way mobile networks operate. The same data chunks are downloaded time and again by users, typically going all the way from the public Internet, through the operator’s core network, eventually to the end user. Everyone loses in this scenario – the content publisher needs huge servers to dish up each download individually. The operator has to deal with transport and backhaul load from repeatedly sending the same content across its network (and IP transit from shipping it in from outside, especially over international links). Finally, the user has to deal with all the unpredictability and performance compromises involved in accessing the traffic across multiple intervening points – and ends up paying extra to support the operator’s heavier cost base.

In the fixed broadband world, many content companies have availed themselves of a group of specialist intermediaries called CDNs (content delivery networks). These firms on-board large volumes of the most important content served across the Internet, before dropping it “locally” as near to the end user as possible – if possible, served up from cached (pre-saved) copies. Often, the CDN operating companies have struck deals with the end-user facing ISPs, which have often been keen to host their servers in-house, as they have been able to reduce their IP interconnection costs and deliver better user experience to their customers.

In the mobile industry, the use of CDNs is much less mature. Until relatively recently, the overall volumes of data didn’t really move the needle from the point of view of content firms, while operators’ radio-centric cost bases were also relatively immune from those issues as well. Optimising the “middle mile” for mobile data transport efficiency seemed far less of a concern than getting networks built out and handsets and apps perfected, or setting up policy and charging systems to parcel up broadband into tiered plans. Arguably, better-flowing data paths and video streams would only load the radio more heavily, just at a time when operators were having to compress video to limit congestion.

This is now changing significantly. With the rise in smartphone usage – and the expectations around tablets – Internet-based CDNs are pushing much more heavily to have their servers placed inside mobile networks. This is leading to a certain amount of introspection among the operators – do they really want to have Internet companies’ infrastructure inside their own networks, or could this be seen more as a Trojan Horse of some sort, simply accelerating the shift of content sales and delivery towards OTT-style models? Might it not be easier for operators to build internal CDN-type functions instead?

Some of the earlier approaches to video traffic management – especially so-called “optimisation” without the content companies’ permission of involvement – are becoming trickier with new video formats and more scrutiny from a Net Neutrality standpoint. But CDNs by definition involve the publishers, so potentially any necessary compression or other processing can be collaboratively, rather than “transparently” without cooperation or willingness.

At the same time, many of the operators’ usual vendors are seeing this transition point as a chance to differentiate their new IP core network offerings, typically combining CDN capability into their routing/switching platforms, often alongside the optimisation functions as well. In common with other recent innovations from network equipment suppliers, there is a dangled promise of Telco 2.0-style revenues that could be derived from “upstream” players. In this case, there is a bit more easily-proved potential, since this would involve direct substitution of the existing revenues already derived from content companies, by the Internet CDN players such as Akamai and Limelight. This also holds the possibility of setting up a two-sided, content-charging business model that fits OK with rules on Net Neutrality – there are few complaints about existing CDNs except from ultra-purist Neutralists.

On the other hand, telco-owned CDNs have existed in the fixed broadband world for some time, with largely indifferent levels of success and adoption. There needs to be a very good reason for content companies to choose to deal with multiple national telcos, rather than simply take the easy route and choose a single global CDN provider.

So, the big question for telcos around CDNs at the moment is “should I build my own, or should I just permit Akamai and others to continue deploying servers into my network?” Linked to that question is what type of CDN operation an operator might choose to run in-house.

There are four main reasons why a mobile operator might want to build its own CDN:

  • To lower costs of network operation or upgrade, especially in radio network and backhaul, but also through the core and in IP transit.
  • To improve the user experience of video, web or applications, either in terms of data throughput or latency.
  • To derive incremental revenue from content or application providers.
  • For wider strategic or philosophical reasons about “keeping control over the content/apps value chain”

This Analyst Note explores these issues in more details, first giving some relevant contextual information on how CDNs work, especially in mobile.

What is a CDN?

The traditional model for Internet-based content access is straightforward – the user’s browser requests a piece of data (image, video, file or whatever) from a server, which then sends it back across the network, via a series of “hops” between different network nodes. The content typically crosses the boundaries between multiple service providers’ domains, before finally arriving at the user’s access provider’s network, flowing down over the fixed or mobile “last mile” to their device. In a mobile network, that also typically involves transiting the operator’s core network first, which has a variety of infrastructure (network elements) to control and charge for it.

A Content Delivery Network (CDN) is a system for serving Internet content from servers which are located “closer” to the end user either physically, or in terms of the network topology (number of hops). This can result in faster response times, higher overall performance, and potentially lower costs to all concerned.

In most cases in the past, CDNs have been run by specialist third-party providers, such as Akamai and Limelight. This document also considers the role of telcos running their own “on-net” CDNs.

CDNs can be thought of as analogous to the distribution of bulky physical goods – it would be inefficient for a manufacturer to ship all products to customers individually from a single huge central warehouse. Instead, it will set up regional logistics centres that can be more responsive – and, if appropriate, tailor the products or packaging to the needs of specific local markets.

As an example, there might be a million requests for a particular video stream from the BBC. Without using a CDN, the BBC would have to provide sufficient server capacity and bandwidth to handle them all. The company’s immediate downstream ISPs would have to carry this traffic to the Internet backbone, the backbone itself has to carry it, and finally the requesters’ ISPs’ access networks have to deliver it to the end-points. From a media-industry viewpoint, the source network (in this case the BBC) is generally called the “content network” or “hosting network”; the destination is termed an “eyeball network”.

In a CDN scenario, all the data for the video stream has to be transferred across the Internet just once for each participating network, when it is deployed to the downstream CDN servers and stored. After this point, it is only carried over the user-facing eyeball networks, not any others via the public Internet. This also means that the CDN servers may be located strategically within the eyeball networks, in order to use its resources more efficiently. For example, the eyeball network could place the CDN server on the downstream side of its most expensive link, so as to avoid carrying the video over it multiple times. In a mobile context, CDN servers could be used to avoid pushing large volumes of data through expensive core-network nodes repeatedly.

When the video or other content is loaded into the CDN, other optimisations such as compression or transcoding into other formats can be applied if desired. There may also be various treatments relating to new forms of delivery such as HTTP streaming, where the video is broken up into “chunks” with several different sizes/resolutions. Collectively, these upfront processes are called “ingestion”.

Figure 1 – Content delivery with and without a CDN

Mobile CDN Schematic, Fig 1 Telco 2.0 Report

Source: STL Partners / Telco 2.0

Value-added CDN services

It is important to recognise that the fixed-centric CDN business has increased massively in richness and competition over time. Although some of the players have very clever architectures and IPR in the forms of their algorithms and software techniques, the flexibility of modern IP networks has tended to erode away some of the early advantages and margins. Shipping large volumes of content is now starting to become secondary to the provision of associated value-added functions and capabilities around that data. Additional services include:

  • Analytics and reporting
  • Advert insertion
  • Content ingestion and management
  • Application acceleration
  • Website security management
  • Software delivery
  • Consulting and professional services

It is no coincidence that the market leader, Akamai, now refers to itself as “provider of cloud optimisation services” in its financial statements, rather than a CDN, with its business being driven by “trends in cloud computing, Internet security, mobile connectivity, and the proliferation of online video”. In particular, it has started refocusing away from dealing with “video tonnage”, and towards application acceleration – for example, speeding up the load times of e-commerce sites, which has a measurable impact on abandonment of purchasing visits. Akamai’s total revenues in 2010 were around $1bn, less than half of which came from “media and entertainment” – the traditional “content industries”. Its H1 2011 revenues were relatively disappointing, with growth coming from non-traditional markets such as enterprise and high-tech (eg software update delivery) rather than media.

This is a critically important consideration for operators that are looking to CDNs to provide them with sizeable uplifts in revenue from upstream customers. Telcos – especially in mobile – will need to invest in various additional capabilities as well as the “headline” video traffic management aspects of the system. They will need to optimise for network latency as well as throughput, for example – which will probably not have the cost-saving impacts expected from managing “data tonnage” more effectively.

Although in theory telcos’ other assets should help – for example mapping download analytics to more generalised customer data – this is likely to involve extra complexity with the IT side of the business. There will also be additional efforts around sales and marketing that go significantly beyond most mobile operators’ normal footprint into B2B business areas. There is also a risk that an analysis of bottlenecks for application delivery / acceleration ends up simply pointing the finger of blame at the network’s inadequacies in terms of coverage. Improving delivery speed, cost or latency is only valuable to an upstream customer if there is a reasonable likelihood of the end-user actually having connectivity in the first place.

Figure 2: Value-added CDN capabilities

Mobile CDN Schematic - Functionality Chart - Telco 2.0 Report

Source: Alcatel-Lucent

Application acceleration

An increasingly important aspect of CDNs is their move beyond content/media distribution into a much wider area of “acceleration” and “cloud enablement”. As well as delivering large pieces of data efficiently (e.g. video), there is arguably more tangible value in delivering small pieces of data fast.

There are various manifestations of this, but a couple of good examples illustrate the general principles:

  • Many web transactions are abandoned because websites (or apps) seem “slow”. Few people would trust an airline’s e-commerce site, or a bank’s online interface, if they’ve had to wait impatiently for images and page elements to load, perhaps repeatedly hitting “refresh” on their browsers. Abandoned transactions can be directly linked to slow or unreliable response times – typically a function of congestion either at the server or various mid-way points in the connection. CDN-style hosting can accelerate the service measurably, leading to increased customer satisfaction and lower levels of abandonment.
  • Enterprise adoption of cloud computing is becoming exceptionally important, with both cost savings and performance enhancements promised by vendors. Sometimes, such platforms will involve hybrid clouds – a mixture of private (Internal) and public (Internet) resources and connectivity. Where corporates are reliant on public Internet connectivity, they may well want to ensure as fast and reliable service as possible, especially in terms of round-trip latency. Many IT applications are designed to be run on ultra-fast company private networks, with a lot of “hand-shaking” between the user’s PC and the server. This process is very latency-dependent, and especially as companies also mobilise their applications the additional overhead time in cellular networks may otherwise cause significant problems.

Hosting applications at CDN-type cloud acceleration providers achieves much the same effect as for video – they can bring the application “closer”, with fewer hops between the origin server and the consumer. Additionally, the CDN is well-placed to offer additional value-adds such as firewalling and protection against denial-of-service attacks.

To read the 25 note in full, including the following additional content…

  • How do CDNs fit with mobile networks?
  • Internet CDNs vs. operator CDNs
  • Why use an operator CDN?
  • Should delivery mean delivery?
  • Lessons from fixed operator CDNs
  • Mobile video: CDNs, offload & optimisation
  • CDNs, optimisation, proxies and DPI
  • The role of OVPs
  • Implementation and planning issues
  • Conclusion & recommendations

… and the following additional charts…

  • Figure 3 – Potential locations for CDN caches and nodes
  • Figure 4 – Distributed on-net CDNs can offer significant data transport savings
  • Figure 5 – The role of OVPs for different types of CDN player
  • Figure 6 – Summary of Risk / Benefits of Centralised vs. Distributed and ‘Off Net’ vs. ‘On-Net’ CDN Strategies

……Members of the Telco 2.0 Executive Briefing Subscription Service and Future Networks Stream can download the full 25 page report in PDF format here. Non-Members, please see here for how to subscribe, here to buy a single user license for £595 (+VAT), or for multi-user licenses and any other enquiries please email contact@telco2.net or call +44 (0) 207 247 5003.

Organisations and products referenced: 3GPP, Acision, Akamai, Alcatel-Lucent, Allot, Amazon Cloudfront, Apple’s Time Capsule, BBC, BrightCove, BT, Bytemobile, Cisco, Ericsson, Flash Networks, Huawei, iCloud, ISPs, iTunes, Juniper, Limelight, Netflix, Nokia Siemens Networks, Ooyala, OpenWave, Ortiva, Skype, smartphone, Stoke, tablets, TiVo, Vantrix, Velocix, Wholesale Content Connect, Yospace, YouTube.

Technologies and industry terms referenced: acceleration, advertising, APIs, backhaul, caching, CDN, cloud, distributed caches, DNS, Evolved Packet Core, eyeball network, femtocell, fixed broadband, GGSNs, HLS, HTTP streaming, ingestion, IP network, IPR, laptops, LIPA, LTE, macro-CDN, micro-CDN, middle mile, mobile, Net Neutrality, offload, optimisation, OTT, OVP, peering proxy, QoE, QoS, RNCs, SIPTO, video, video traffic management, WiFi, wireless.