Speaking Engagements & Private Workshops - Get Dean Bubley to present or chair your event

Looking for a provocative & influential keynote speaker, an experienced moderator/chair, or an effective workshop facilitator?
To discuss Dean Bubley's appearance at a specific event, contact information AT disruptive-analysis DOT com

Friday, July 22, 2016

New Disruptive Analysis Report & Forecast on eSIM: Pre-Order Discount

I'm in the final stages of preparing a report on the status of the eSIM market, including forecasts for adoption and installed base, out to 2021.  

The report will focus on the use-cases for eSIM, and consider the drivers for, and barriers to, uptake in different sectors, including smartphones and IoT/wearables.

It'll be published in the next week or two after editing is complete, but if you wish to pre-order it, I'm offering a 15% discount, until publication date.

Some preliminary outputs:
  • There are numerous potential use-cases for “remote provisioning” of SIMs with mobile operator “profiles”, especially where the SIM hardware is built-into devices.
  • However despite theoretical benefits, eSIM adoption will have a slow start. 
  • 2016-17 deployment will mostly be early concepts, to allow operators and OEMs to gain experience of eSIM practicalities and refine implementation and processes. 
  • The market will then ramp up in 2019-2021 as cost, industry value-chain and user-experience problems are progressively solved.
  • In smartphones, eSIM adoption will be very gradual, driven by slow maturity of good user-experience of choosing an operator/plan, and the costs of implementation & support vs. device margin. In many ways, eSIM will be aligned with 5G's arrival, not 4G maturity
  • Apple may well be the eSIM king-maker - but will be conservative in adoption, especially in its iPhone flagship, where the near-term risks outweigh any benefits.
  • For many M2M/IoT devices, the eSIM decision is secondary to justifying the extra cost, space and power needs of the cellular radio itself. (As I discussed in February - see link here)
  • There remain unanswered questions about regulation, customer-support and business model for eSIM. Although some projected cost-savings or additional device connections are attractive for operators, it is unclear that OEMs will generate extra revenues quickly & painlessly enough, for them to support the technology in new mainstream devices.
  • eSIM is occurring alongside other technology trends in mobile - SDN/NFV virtualisation, LPWAN & LTE Cat-0/NB-IoT for IoT and so forth. It will need to coexist and be co-developed, which may bring additional complexities.
  • Alongside eSIM, we will also see continued innovation in other areas of SIM technology, both standardised and proprietary. Some use-cases (eg temporary/cheaper roaming subscriptions) can be offered using other approaches such as multi-IMSI MVNOs, or (less securely) early soft-SIM variants
  • Chicken-and-egg problem: until most operators support eSIM, handset vendors will still need removable SIM slots as well, or else produce multiple device variants
  • Definitions of "eSIM" need to be carefully examined. Many people do not understand the nuances and make inaccurate or confused predictions.
  • By 2021, over 500m mobile & IoT devices will ship with embedded, remotely-provisioned SIMs annually, driven mostly by smartphones, although vehicles and tablets show growth earlier
  • By end-2021, the installed base of eSIM-enabled devices will exceed 1 billion - although that is little more than 10% of the overall cellular universe at that time
The report is based on a large amount of primary research undertaken in recent months, among a broad cross-section of service-providers, vendors, industry bodies, regulators, startups and other commentators, as well as many years of analysis of SIM innovation (eg multi-IMSI SIM cards, which I first looked at more than 7 years ago - link). 
It examines both drivers and inhibitors of adoption, from the perspective of MNOs, OEMs and end-users. In particular, it covers a broad set of technical, commercial and regulatory issues that need resolution and experience, before eSIM can become a massmarket offer.

The report will be approximately 35 pages in length, and is aimed at strategy executives, CTOs, CMOs, enterprise architects & planning/operational staff at communications service providers, SIM & network equipment & software vendors, device vendors, investors, regulators, integrators, developers and similar organisations.
When published, the report, delivered as a PDF, will cost US$900 for a 1-3 user licence, and US$1500 for a corporate-wide licence (plus VAT in UK/EU as appropriate)

For firm orders received before publication, a 15% discount is available. This only applies to credit-card and Paypal payments (see below), or where a purchase-order and invoicing details are submitted by email to information at disruptive-analysis dot com

[Note: Sometimes Paypal's credit-card transaction process is a little flaky, especially with corporate cards. Please drop me an email if you have problems]
 

eSIM Report, 1-3 users, Pre-order


eSIM Report, Corporate, Pre-order

Monday, July 18, 2016

My comments on BEREC's Net Neutrality guidelines consultation

I've been meaning to submit a response to the BEREC consultation on its draft implementation guidelines for the new EU Net Neutrality guidelines for some time. However, a combination of project-work and vacation has meant I've had to do just a fairly rapid set of comments at the last moment. 

I'm posting them here as a reference and further discussion-point. 

As a background, I think the guidelines are quite comprehensive - but have shifted the needle somewhat from the final EU regulation back towards the Internet-centric view of the world. However, the permissiveness around both zero-rating and (in certain circumstances) so-called "specialised services" seems a pragmatic compromise position. I tend to think that zero-rating is fine "in moderation" - it's basically the Internet equivalent of promotions and coupons. "Sponsored data" is an almost-unworkable concept anyway, so the regulatory aspect is largely irrelevant.

Specialised services are OK as long as they are genuinely "special" - something I've been saying for a long time (see post here). It should also be possible to watch for genuine innovation being catalysed / inhibited by the new rules - and then regulators and policymakers can take a more-educated view to revising them in a few years, based on hard evidence.

Anyway - the contents of my submission (reformatted slightly) are below:



Preamble

I am an independent telecom industry analyst and futurist, representing my own advisory company Disruptive Analysis. I advise a broad variety of telecom operators, network and software vendors, investors, NRAs, IT/Internet firms and others on technology evolution paths, business models and applications, and regulatory issues. I look at the issue of Net Neutrality particularly through the lens of what is, or what is not, possible – and also how the Internet value-chain, applications and user-behaviour are likely to evolve in future.

In the past, I have published research studies examining the possible roles and scale of “non-neutral” broadband & IAS business models. My primary conclusions have been that, irrespective of regulation, most proposed commercial models such as “paid prioritisation”, application-based charging or “sponsored data” are broadly unworkable, for many different technical and business reasons – such as growing use of encryption, plus the risks of false positives/negatives.

Overall, I see the guidelines as broadly positive, as they help clarify some of the many grey areas around implementing NN, and clearly try to close off future potential loopholes. Some aspects will likely be difficult to implement technically – notably the precise definitions and measurements of QoS / and “quality” – but the guidelines are good in setting the “spirit” of the law, even though in some cases the “letter” may be harder to achieve.

Listed below are comments that I feel could help to:

  • Clarify the guidelines further 
  •  Help future-proof them against changes in technology 
  •  Raise questions about possible evolution of the guidelines in response to those changes 
  •  Lock down a few additional possible loopholes
                                                                                                                       
Specific points on individual paragraphs: (reference to the guidelines doc here)

#10 – in locations where “WiFi guest access” is made available (eg visitors to a company’s offices), there is sometimes a sign-up or registration required, either via a splash-page, or simply via obtaining a password. Does this count as “publicly available”?

#11 – it should be clarified that there is a difference between corporate VPNs for connecting to a central site, and personal VPNs that are designed to secure/encrypt normal users’ access to the Internet. There is also a growing trend for corporate VPNs to be replaced by a new technology, software-defined WAN, which may itself use Internet access or even multiple accesses as transport.

#12 – Consideration of WiFi hotspots needs to distinguish between voluntary access (eg if a user obtains the cafĂ© password & registers independently) vs. automated “WiFi offload” by ISPs as an integral part of their IAS offering. The latter is a form of “public access”. Also, there are growing examples of ISPs using WiFi in public places, including outdoors, sometimes as part of “WiFi-Primary” public IAS.

#14 - It is worth distinguishing between capital-I “The Internet” (ie public Internet, addressable via the DNS system & IAS) and lower-case-I “internets” (internetworks) that are private domains.

#23-25 – This needs to reference what happens when “terminal equipment” becomes virtualised, through the imminent release of NFV (network function virtualisation) architectures. This could mean that either the “terminal” become a software-function in the ISPs’ data-centre, or could be (in part) pushed down as a “virtual network function” (VNF) to a general-purpose box at the customer site. Some providers are already discussing the concept of a “VNF AppStore” where the user can choose between different software “terminal” functions. It is unclear if this is permissible – or even mandatory.

#39 & #45 – the nature of software and Internet applications makes its increasingly hard to define categories. There are many blurred boundaries, overlapping categories, “mashups” and differentiated offers. How is the categorisation achieved, for example where a social network includes a large amount of video-streaming in its timelines? Is that equivalent to a “pure” video application? What about streaming of games? Is there a distinction between video-on-demand and live-streaming? This is particularly difficult where some functions such as voice communication are being included as “secondary features” embedded in many other applications, often via the use of 3rd-party platforms and APIs (application programming interfaces). There needs to be stronger guidance on how “categories” are defined and how disputed or ambiguous categorisation can be addressed.

#40 & #45 – a possible implementation option is to require ISPs to report the % of overall traffic (or % of particular user-classes) that is zero-rated.  If the total amount provided “for free” is less than (say) 10% of the total, it can a-priori be considered acceptable as it is unlikely to materially affect users’ choices. However, if it is higher this could trigger closely investigation by the NRA.

#43 – this section seems to focus more on established CAPs or possible new-entrants. It is unclear if this explicitly covers the needs open-source initiatives and general software-developers

#56 – There is a possible implementation option for NRAs to collect and hold configuration details for ISPs’ network equipment or software-equivalent VNFs, to allow retrospective analysis of network setup if disputes occur. This could be done on an encrypted / escrowed basis to maintain normal commercial confidentiality

#57 – the reference to encryption needs to explicitly include both app-level encryption (eg HTTPS / HTTP2) and more general “all-traffic” encryption using corporate or personal VPN “tunnels”

#57 & 58 – an implementation option for NRAs could be provision of a contact-point for internal ISP whistle-blowers to report infringement, or 3rd-party monitoring organisations (eg that use pattern-recognition to detect abuses)

#60 & #61 & #63 – categorisation is extremely hard, owing to application differentiation, complex hybrid and “mashup” applications, different levels of fault-tolerance built into applications by developers etc. For example, different VoIP applications use different approaches to error-correction, or are used differently (eg ordinary telephony vs. karaoke). In future there will also be a difference based on whether the application (at either end) is a machine rather than a person. Implied QoS when speaking to “Siri” or “Alexa” may have very different characteristics to speaking to a friend, despite being carried over VoIP. There may also be other dependencies – eg if network conditions have worse impact on badly-designed applications, or devices with other constraints (memory, CPU power, processing chips etc)

#64 – does “network management traffic” also include other types of operational (internal) ISP traffic such as billing records, customer-service inquiries & apps and so forth?

#71 – does “alteration” cover so-called “optimisation”, whereby various content such as a video or image can be paused, down-rated, reformatted etc.? Does it also cover “insertion” of additional data such as tracking codes / “supercookies”, or additional overlay advertising? Are “splash pages” (eg for WiFi registration) allowed?

#89 – Dimensioning may well be affected by other constraints, such as spectrum availability, location, economics of network coverage/capacity, or “emergent” unexpected trends in demand

#98 & #123 – this appears to define specialised services as “actually being special” rather than those capabilities that are normally delivered over IAS. How are hybrid specialised/non-specialised services to be treated?

#101 & #104 – technologies such as SD-WAN (software-defined WAN) allow improved QoS by linking together multiple IAS connections, which in aggregate can perform as well (or even better/cheaper) than one QoS-optimised connection. Should NRAs consider this option when determining if specialised services are valid? See http://disruptivewireless.blogspot.co.uk/2016/06/arbitrage-everywhere-inevitable.html  and http://disruptivewireless.blogspot.co.uk/2016/03/is-sd-wan-quasi-qos-overlay-for.html for more detailed discussion of this point

#111 – It is important to recognise that VPNs are increasingly used by consumers as well as businesses, often to provide a secure & privacy-protected path to the Internet over both public IAS and localised WiFi hotspots. The guidelines should specifically reference consumer VPNs.

#113 to #115 & #117 & #119 – It may be difficult to guarantee coexistence of IAS and specialised services over cellular/other radio networks, where factors such as location in a cell, mobility, density of users, coverage/interference etc are non-deterministic. Potentially the guidelines could advise use of different spectrum bands for IAS and specialised services, to mitigate these problems.

#113 & #116 – in future 5G architectures, we may see a concept called “network slicing”, where the radio and core networks are logically divided into “slices” suitable for different application classes – either broadly between Internet & specialised services of different types, or resold more granularly a bit like “super-MVNOs” to particular 3rd-parties on a wholesale basis. Where those parties are themselves CAPs, this could make interpretation of this section very difficult. If Netflix or Google or even a rival ISP/telco buy rights to a “slice”, how do the guidelines apply?

#131 – This guideline should potentially also include information/transparent guidance for application developers, who may be creating applications intended to run over the IAS provided

#152 – should coverage maps be 2-dimensional, or also include z-axis detail (eg speed in a basement / on the 50th floor of a tower block)? How can such maps cope with the trend towards self-optimising / self-reconfiguring networks of various types?

#167 & #180 – NRAs should potentially seek to maintain records of network configuration status (which may change abruptly with the advent of NFV & SDN). This could perhaps be stored securely & reliably using technologies such as Blockchain.

#172 & #179 – monitoring of aggregate volumes of traffic subject to price-discrimination (eg % of IAS traffic that is zero-rated) would be useful


General comments:
  • There needs to be consideration of meshed, relayed or shared connections which run directly between users’ devices. In device-to-device scenarios, does the owner/operator of an intermediate device become responsible for the neutrality of the “onward” link to 3rd parties? (which could be via any technology such as WiFi, Bluetooth, wired USB port etc) 
  •  There needs to be consideration that some of the more invasive mechanisms for traffic discrimination and control will in future move from “the network” to becoming virtualised software (provided by an ISP) that reside in edge-nodes at the customer premise, or even in customers’ mobile devices. It is unclear how the implementation guidelines deal with predictable near/mid-term trends in NFV/SDN technology, especially where there is no clear “demarcation point” in ownership between ISP and end-user. 
  • Equally, in future there may well be CAP companies that offer their services “in the network” itself, also with NFV/SDN. There needs to be careful thought given to how this intersects with Net Neutrality guidelines 
  • The evolution of artificial intelligence & machine-learning means that workarounds or infringements may become automated, and perhaps even invisible to ISPs, in future. This may also impact the nature of QoS as used for different applications. See http://disruptivewireless.blogspot.co.uk/2016/04/telcofuturism-will-ai-machine-learning.html for more details 
  •  Where wholesale relationships occur – eg MNO/MVNO, “neutral host” networks using unlicenced-band LTE, or secondary ID on the same WiFi hotspot – and the traffic-management / IAS functions are co-managed, how do the guidelines apply? Which party/parties is responsible?

Wednesday, June 29, 2016

A challenge for new software-based telecom services NFV and eSIM: demarcation points

A couple of months ago, I had a problem with my home broadband connection, which intermittently cut out, or needed the router to be switched on/off again.

When I arranged a call-out from a BT engineer, I was told in no uncertain terms that if the problem was with my house-wiring, I'd be charged a fee. If it was a fault with the termination box or router, or external wiring, then BT would fix or replace it.

In other words, the little white BT-branded box and socket is the "demarcation point". It's where BT Openreach's responsibility stops, and the customer's starts. (BT Retail also provides me with an Infinity router, for Internet access, but that's technically a different service component, rather than network access).

Something similar is true with my mobile phone - the SIM card represents the demarcation-point for the connectivity part of Vodafone's service offering. It is essentially part of the network, rather than part of my phone. While I need operator settings and configurations to be pushed down to my device (eg APNs for Internet), that again is something separate.

Now consider what happens in a more software-driven, virtualised world.

For fixed connections, we may find either some sort of white-box termination unit (residential or business) down to which might be pushed virtual functions like a vRouter, vFirewall, vSmartHomeServer or whatever. Or alternatively, those virtualised functions might be located in a data-centre or local exchange server - there's a lot of talk about cloud-based vSetTopBoxes, for example.

And in mobile communications, we are starting to see eSIMs emerge for some use-cases, in which the manufacturer embeds a physical SIM chip in devices, and operator profiles get pushed down to it, or potentially switched between.

In both those cases, and various other forms of virtual/physical scenarios, we are moving from a world of clear and unambiguous demarcation points, to a world in which they are much less well-defined.

Today, if people switch SIM cards over to use a different network, or if a SIM stops working and needs replacing, or if consumers churn from one home broadband provider to another, then the lines of responsibility are pretty clear and obvious. There's very little finger-pointing that can occur.

But what happens with an eSIM? Is the manufacturer responsible if it stops working? Or is that the fault of the operator whose profile is working on it, the service provider which packaged and downloaded that profile, the software vendor(s) involved, the retailer where the device was bought - or worse, a second operator if the failure occured during a switch-over to a new profile? Who pays for the diagnosis, or for replacing the whole device if the eSIM can't be separated out? What happens if data is lost? Who is liable?

A similar set of questions apply with 3rd-party VNFs, or other software functions which drive underlying connectivity, or sit in the data path. We may be entering a world in which there is a "VNF AppStore" model - where the customer chooses between different software routers, or WiFi controllers, or firewalls. For businesses it may be possible to sell ethernet-style connectivity, and let the CIO take responsibility for those other connectivity-oriented functions, but that's clearly not an option for the consumer market.

This is different to higher-level virtual applications - if a game or a VoIP service stops working, but the network connection is still live, it's reasonable to assume that the connectivity function isn't to blame. 

Overall, there's a lot of opacity here - nobody really knows how to deal with network responsibilities, in a world where there are no clear demarcation points. It's a set of lessons that will need to be learned very soon - and which will probably involve regulators or other authorities in disputes.

Friday, June 24, 2016

Arbitrage Everywhere: The inevitable multiple-connection network future

The previous inevitable risk: Encryption

For years, encryption of data was ignored by the telecoms industry as a possible risk. Operators and vendors hyped the potential of DPI, "app-aware networks", the "optimisation" of video, insertion/blocking of adverts, and assorted other ways to monitor or change end-user data traffic.


Yet in the background, the use of both encrypted websites (with HTTPS), and "tunnelled" VPNs was becoming more widespread. Many apps' traffic is encrypted between smartphone and server. Such techniques stop or impede a large amount of in-network management taking place - whether one views such as actions as "value-added" or "non-consensual interference".

To some of us, it was a matter of when and how, not if, encryption became (near-) ubiquitous, driven by Moore's Law and more-powerful devices, fears about security and privacy, and perhaps push-back against unwanted intervention by ISPs and other intermediaries.

The advent of Snowden's revelations and the parallel Net Neutrality controversies helped catalyse today's predictable situation - a lot of traffic has "gone dark", much to the chagrin of the telecoms community.

My view is that this was not just predictable, but inevitable. And lo, it has come to pass. 


The next inevitable risk for telcos: Multiple Network Connections & Arbitrage

We are now starting to see the signs of the next inevitability: arbitrage across multiple networks and connections - and more importantly, between multiple service providers. This is being aided by more/cheaper types of connection, ever-better software control of connectivity, and some creative hardware "hacks".

Some signs have been around for a while:
  • Least-cost routing by enterprises' telephony systems, especially to avoid international direct-dialling costs.
  • Multi-SIM mobile phones, to allow users to switch between networks and minimise prices
  • Rapid growth of (free) 3rd-party WiFi usage on smartphones, implicitly competing against cellular (paid) data services.
  • Redundant fibre connections into offices or data-centres, to add resiliency and reduce the risks of failure.
  • Cellular back-up for fixed connections of various types (eg branch-office routers) 
Of course, service providers themselves do much the same - multiple transit providers for voice, multiple sub-oceanic connections, and so forth. In some cases it adds reliability, in some it helps arbitrage costs.

But it is end-user controlled, or OS/device-controlled multiple connections, or those provided as a 3rd-party overlay, which are now becoming more important. And the next generation of multi-access options are now emerging:

  • Enterprise SD-WAN, typically using multiple "vanilla" Internet connections as a cheaper option vs. MPLS WAN connections, providing a sort of quasi-QoS. I recently wrote a post on this (link) and also a full report as part of my work on STL Partners' Future of Networks research stream (link)
  • Multi-IMSI SIM cards, either for cheaper roaming (eg Truphone) or cross-network coverage (eg Google Fi)
  • eSIM / eUICC - which may allow end-users to switch between operators more quickly, although probably not in real-time. (Note: I am currently concluding detailed research on the potential of eSIMs - watch this space, or drop me a message)
  • Potential combinations of licensed & unlicenced connectivity in multi-standard LPWAN chips, perhaps via the ETSI/Weightless partnership (link)
  • Various device-to-device and mesh technologies, that can pool or share connectivity between multiple users within close proximity.
  • Multi-point cellular network technologies, especially with MIMO/beam-forming linking a device to multiple cell-sites simultaneously (from the same single-operator network, though)  
One important thing to recognise is that the time for switching / control of the multi-network function varies significantly - it may be realtime, it may take seconds or minutes or even hours to complete. There are also differences in whether the main purpose is "bonding" to increase aggregate throughput, or for resiliency, least-cost routing or differential performance/security characteristics of various types. However, all are still specific examples of the same underlying trend and concept.
 
With the advent of 5G or later variants of 4G, we can also expect to see various home-broadband multi-access combinations linked with fibre or cable emerge. We may also see multi-radio cellular devices connecting to different MNOs' networks simultaneously, although that would have power-consumption implications (which might be OK for in-vehicle use, or public-safety workers' outfits with large batteries).

There are undoubtedly other forms of multi-connection system or business model that may evolve - and may also be accelerated by 5G standardisation, SDN, SDR, or other imminent changes.


Arbitrage Everywhere

But all of this is actually an example of a wider phenomenon - smarter software is creating the possibility of "arbitrage everywhere". From a telecom point of view this means that any device, any application, any location, any user has the ability to use cheaper/easier/alternative connectivity.

The criteria for selection, switching or bonding network access will proliferate and become more sophisticated over time. We may see differential routing based on application or traffic type, security optimisations, trade-offs of computing resource vs. battery power, desire for privacy, a function of cloud-service providers - there will be a widening variety of possibilities. Here, we will also see machine-learning and AI start to get involved as well - something I discussed in another recent post (link).


The other variable is the owner/controller of the "arbitrage layer". It will be a mix of direct user-control, OS-level automation and connection-management, telco-control, and others such as external SD-WAN and XaaS providers.

This will have a particular impact on telco providers wanting to offer their own network-integrated services. If they cannot be sure that a given user or device is always connected via their network, it is questionable how much value can be based on offering those functions only sometimes. This is particularly important when considering things like network QoS, or "telco cloud", or perhaps mobile-edge computing (MEC). Obviously many things (especially IoT things) will remain single-connection, or perhaps multi-connection from the same provider. But many others will move, inevitably, towards multiple connections, from multiple network providers. This trend is already seen in areas such as SD-WAN and WiFi/cellular use.

Network arbitrage and selection is itself only one aspect of broader trend. Software will generally get smarter, and allow us to source products or services from multiple providers. Price arbitrage is already common in some sectors (eg online flight booking, or comparison websites), but we should expect it to become a ubiquitous feature of our lives in many other regards.

When everything is virtualised, it becomes easier to choose between 2, 3, or N variants from different providers. We can use them simultaneously, or switch between them. Networks are just one domain to face this inevitability.


If this topic if of interest to you - or related areas around network evolution, 5G, SDN/NFV, and future strategic developments of service providers & related value chains, - then please get in touch via information AT disruptive-analysis DOT com to discuss opportunities for workshops, due-diligence projects or speaking engagements.