Pages

Pages

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.

Monday, June 13, 2016

Microsoft / LinkedIn helps kill the phone number as a primary B2B identifier

I'll keep this focused, as there will be hundreds of articles dissecting the MS / LI acquisition that will no doubt cover most angles.

For me, the key element is that LinkedIn has one of the only "identity spaces" that allows people from different companies to connect. The two other most-popular ID types, which cover company-to-company communications, are phone numbers and email addresses. Unlike those, LinkedIn actually has a functioning searchable directory, with real names and mutual-connection "opt-in" model to reduce spam. It also follows people from job to job.

Other options are very minor - some business-people connect via Twitter's messaging function, some have industry-specific IM systems like Bloomberg & Symphony in finance, and some interact via channels on Slack and similar services niche collaboration platforms. 

Three other identities stand out - Google ID (used for HangOuts and a few strange folk on G+), Skype, and Lync/Skype for Business. Some business-people probably end up communicating via iMessage but that's usually triggered via an initial phone-number exchange, as is WhatsApp and pretty much all the other major mobile messaging services.

None of the other UC/UCaaS services from Cisco, Avaya, Unify, Mitel or Broadsoft-enabled operators really have their own inter-company addressing, directory and search/discovery function, although they can sometimes use specific federation techniques, or indeed integrate with Microsoft's Office365 and other systems.

If it can put the pieces together, Microsoft now has:
  • LinkedIn's real-name addressing
  • Outlook / Office365's ability to link email addresses to presence and Microsoft's own identity space
  • Skype IDs for both consumers and individual business-people
  • Phone numbers provided for SkypeIn and PSTN Calling in Skype4B
  • WebRTC/ORTC for "guest access"
  • Dynamics for CRM / sales automation
It is thus now the only company that can legitimately claim to control directories for both internal and external connections among business users, plus a fair number of consumers as well. It is already quite common for people to use LinkedIn as a surrogate contact database, when they cannot immediately find someone's phone number or remember their email address - especially when they move jobs.

(It should however be noted that LinkedIn tends to polarise opinion quite a lot - while it has a proportion of regular users who exploit it for networking, recruitment, groups and articles, it also has many members that have neglected profiles and limited active use. I'd been expecting LinkedIn to add realtime communications with WebRTC for some time but nothing has appeared - although it will be interesting to see if there's been anything behind the scenes that Microsoft will accelerate).

That has big implications for two groups:
  • Telcos will see the role of the phone-number diminish further in a B2B context, as it becomes ever-closer to being just a lowest common-denominator fallback option. Added to its diminishing scope for B2C (because of in-messaging chat, app notifications etc), this doesn't augur well for E.164's continued primacy
  • Cisco, Broadsoft and others need to think closely how to tie together inter- as well as intra-company connections. I'll be interested to see if Cisco tries to leverage its Apple relationship, or if the UCaaS platform-players try to lean on Google [Which has been cropping up regularly at events, pitching Android for Work]. We could also see attempts by competitors to federate their various cloud platforms - perhaps using something like Matrix.org as an intermediary.
This also puts the pressure on Facebook to step up with its long-promised enterprise offer, and means that any sign that Slack, HipChat or peers are gaining viral adoption will be greeted with enthusiasm (and perhaps acquisition offers). We will also see redoubled interest in industry-specific federated messaging in healthcare or finance or government verticals.

[There are also impacts on other companies like Salesforce in the CRM arena, but I'll leave that for others to discuss]

Of course, all this is contingent on Microsoft/LinkedIn gaining approval from competition authorities - and of course also assumes Microsoft can do a rather better job with integration than it managed with Skype in the first place.

But overall, this is hugely important - and has ramifications that extend across the business communications sphere, and may ultimately prove to be (another) nail in the coffin of the phone number & PSTN as the primary B2B identity-space.

Sunday, June 05, 2016

The rise of Managed Voice Infrastructure... or perhaps VIaaS or UCaaSaaS ?

Over the last year or so, I've watched the emergence of a new category of communication service - but it's quite hard to define a decent name for the trend.

In essence, it's where telcos/SPs offer some form of VoIP, either for consumer telephony or enterprise UC/hosted-PBX... but don't actually manage the infrastructure internally themselves. Instead, a vendor manages and delivers the capability via its own software/cloud-based platform. The SP sells (perhaps customising / integrating / bundling) the "outsourced" service to final end-users. It's not really the same as a straightforward channel play (eg resale of SaaS applications), because there's typically various network and OSS integration aspects, such as the need for SBCs, link with numbering and perhaps QoS, coupling with emerging NFV strategies etc.

The most prominent providers are probably:
  • BroadSoft BroadCloud
  • GenBand Nuvia
  • Alianza Cloud Voice Platform
  • Metaswitch MetaSphere Cloud Services
In addition to these, there are probably more that I'm not fully aware of. Alongside this, various other vendors are offering managed/hosted VoLTE, API/PaaS platforms and other applications (yes, even Jibe's hosted-RCS, now owned by Google) also intended to be offered through SP channels.

But for me, the main event here is service providers outsourcing their "core" telephony functions - including business-oriented comms which typically go beyond just voice - to vendor-controlled cloud platforms.


If you take the view that it's too difficult for SPs to develop their own innovative and differentiated consumer-voice or UCaaS platforms, then the next question is whether they really add any value by deploying their own servers for somebody else's application either. This is especially true for "vanilla" applications like PSTN telephony, SIP trunking and basic hosted-PBX functionality.

The answer is probably one of scale, risk-appetite, and the ability and willingness to attract software developers - as well as the target audience of end-users that a given SP faces. Larger operators ought to be able to have the resources to develop unique and well-customised propositions, even if they are based on a vendor's application platform or straightforward standardised telephony functions. 

Smaller providers - especially in rural areas - may find the idea of such hosted/wholesale offers more intriguing, especially as the cost-models may allow then to phase in such products over time without heavy upfront investmentment. 

In developing countries, the initial user-base for UCaaS might be very low as well - especially if broadband infrastructure is still being built-out and adopted by small businesses. Again, a wholesale offer might make sense, assuming the data-centres are close enough and long-haul links suitable.

There may also be a fixed/mobile divide here - it could be argued that residential fixed/cable operators have better things to focus on than infrastructure for delivering a commodity telephone service that few people use. Or, perhaps, mobile-centric operators may not have the ability and willingness to deal with the hybrid fixed/mobile nature of most UCaaS.

I think we're still at early stages here. Vendors are mostly being quite cautious, to avoid looking as if they compete with their SP customers, or are taking too much of the available profit-pool in that sector. Yet as NFV matures, both telephony and UCaaS do start to look a bit more like today's other SaaS offers - which can be hosted in telcos' own data-centres, but are more often anchored in Microsoft's or Amazon's.

It's also hard to come up with a pleasing category-name for this. Some people have suggested "wholesale telephony", but that's too closely-similar to various other traditional bits of the wholesale/transit market. "White-label voice & UC" is another option, but I've spoken to some people who recoil from that. "Cloud voice" can apply to about a dozen separate intersections of communications and cloud, so is too vague in my view. For the business side, I quite like UCaaSaaS but that's too much of a mouthful, although it looks fun on screen.

Maybe "VIaaS"?
Voice-Infrastructure as a Service? Or my current favourite: MVI, Managed Voice Infrastructure? Some will grumble that it makes the video and messaging/collaboration bits look like second-class citizens, but I think it perhaps captures the essence of what's occurring - and it also spans both consumer VoIP telephony and UCaaS.