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.

THE PRE-PUBLICATION DISCOUNT HAS NOW EXPIRED. PLEASE CLICK HERE TO PURCHASE & FOR FURTHER DETAILS.

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 3^rd-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 3^rd-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 3^rd-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 50^th 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 3^rd 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?