Skip to content

Not Abandoning Wireline After All?

In my last blog post, I discussed Verizon’s HomeFusion LTE-based fixed broadband offering.  I questioned the article in Telecompetitor suggesting the rollout meant that Verizon was abandoning the wireline business in favor of wireless. I concluded that this offer would likely only appeal to “… customers who do not have any Broadband Internet service, or who only have Satellite Broadband Internet service…”.

Interestingly I came across another article today in the Telecompetitor discussing Bend Broadband, a small regional cable company that has just launched a similar LTE-based fixed broadband service. This article quoted the Director of Marketing for Bend Broadband, who explained that they were “picking up people on the periphery”. The typical customer did not have any alternative other than dial-up, satellite, of marginal DSL service.

It’s rather satisfying to have your analysis confirmed so quickly.

Wireless Broadband Collides with Spectrum Crunch?

Sometimes, things are not what they appear to be. Earlier this month, Verizon announced it was offering LTE-based HomeFusion Broadband (SM) fixed wireless service throughout the country. Telecompetitor speculated this was linked to Verizon’s announcement that it would stop adding new DSL subscribers in markets where FiOS is available.  They went so far as to imply this was part of a master plan to abandon the wireline business in favor of wireless.

Meanwhile, an article in the Hillicon Valley reported that consumer groups were protesting to the FCC about Verizon’s decision to discontinue installing standalone DSL service.  Customers will be able to retain their existing standalone DSL service, but if they want to make any changes, they will have to move to a bundled voice and DSL service. The consumer group Public Knowledge suggested this is further evidence that Verizon is abandoning the landline business.

At the same time, we are also seeing reports of the looming spectrum crunch, suggesting that America is about to run out of available wireless capacity. Clearly something does not add up here – at least not until we look behind the headlines.

A closer look at the HomeFusion Broadband offering suggests that it was never intended to compete against FiOS, or even against DSL.  The top HomeFusion tier offers 12 Mbps download speeds, but has a mere 30 GB data cap, and costs $120 per month. With FiOS, on the other hand, $50 per month will get you higher download speeds (15 Mbps) with no data cap at all.  If you are interested in a FiOS bundle, you can add TV and phone service, for a combined bill of $85 per month. Other bundles are available, depending on your needs, with higher Internet speeds, more TV channels, or added phone features. As for DSL, the download speeds may be slower, but it is generally cheaper than FiOS, and doesn’t have any data caps either.  It’s clear that HomeFusion is not going to have much appeal in areas where FiOS or DSL are available.

HomeFusion isn’t going to compete against broadband from the cable companies either, with Comcast increasing their data caps from 250 GB to 300 GB. However, for customers who do not have any Broadband Internet service, or who only have Satellite Broadband Internet service, this could be a competitive offering.

Which brings us to the reports that standalone DSL will no longer be supported. This may simply be a recognition of what OTT providers have been saying for years.  Voice is nothing more than an app, so bundling it in with broadband internet access makes perfect sense. The protest from consumer groups doesn’t appear to recognize the full implications of the PSTN transition to Broadband.

This just leaves us with the question of the spectrum crunch.  Spectrum is primarily an issue in dense urban areas.  These are also the areas with competitive broadband internet offerings at much lower prices than HomeFusion. I suspect that the areas where HomeFusion will be attractive are unlikely to see a spectrum crunch anytime soon.

The confusion surrounding this issue illustrates the importance of an objective analysis of the implications of PSTN transition. When talk of PSTN sunset first emerged over a year ago, commentators like Tom Evslin implied that the PSTN based on a single dominant technology (copper twisted pair) would inevitably collapse and be replaced by a new dominant technology (presumably wireless).  What is actually emerging is far more complex, with many overlapping, cooperating and competing technologies. In this context, copper twisted pair will continue to be part of the equation for the foreseeable future. An independent analysis of these PSTN transition scenarios, as has been proposed by ATIS in their PSTN Transition Focus Group, would not try to identify winners and losers, but would instead produce a better understanding of how the various transition options could co-exist. This would be valuable input to the debate.

It’s also important to recognize that the transition will be about more than technology. Carriers have historically been criticized for being slow and inflexible. Perhaps what is needed is for carriers to act more like the OTT players, continually experimenting with different combinations of services and pricing. This would allow them to respond to both customer demand and OTT competition in creative ways. Viewed in that light, the initiatives highlighted here take on a different complexion.

Carrier Response to OTT Services

There is a growing sense of urgency about how carriers should respond to Over the Top (OTT) services.  A recent article in Mobile Europe outlines how carriers can stake their claim in the “OTT land grab”. The key is to identify assets that are of value to the OTT providers, and then offer those as services. The news from CTIA Wireless and a recent article in Synergy magazine present a similar picture, while complaining that most of the press still focuses on  the threat that OTT poses to carriers.  But this is changing, as illustrated by a number of recent developments. At Mobile World Congress in March China Mobile announced it was opening up its mobile platform to third party developers.  Telefonica has recently introduced TU ME, an internally developed OTT voice and messaging app. TU ME is truly open, being available beyond Telefonica’s customer base, and allowing third party developers to extend the applications.  T-Mobile has also shown the potential of OTT services with its Bobsled calling and messaging application.  Usage statistics show that 95%  of users are not existing T-Mobile customers, suggesting that this OTT app can be an effective strategy to reach customers outside of the carrier’s coverage area.

But not everyone is convinced the carriers will benefit from cooperation with OTT based on their current strategies. Dean Bubley argues that OTT players will only pay carriers for access to their APIs and services when these provide demonstrable value to the OTT, something which he does not see happening yet. Simply trying to act as a toll booth in the middle of the network will not be an effective strategy. On the contrary, he points to a number of examples where the OTT players are in effect charging the carriers for access to innovative OTT services. In spite of this, the carriers who cooperate with OTT players will be in a far better position than those who try to simply shut them out.

These two extremes appear to disagree, but in effect they are saying the same thing. To be successful, carriers will need to identify core competencies that bring real value to OTT providers.  Martin Creaner, CEO of the TM Forum, identifies six core competencies that will be critical to Communications Service Providers;  security, big data management and analytics, Customer Experience Management, product lifecycle management, revenue management and infrastructure management.  Most of the discussion in the industry currently focuses on the last item; infrastructure management.  Verizon Wireless is developing a “turbo button” API that would allow users to buy a temporary burst of bandwidth for their mobile phones. Both AT&T and Verizon have been talking recently about a “toll-free” data service. Comcast is using a managed IP network to deliver video traffic to its Xbox 360 Streaming service, and not counting this toward user’s bandwidth caps. These infrastructure management services could be valuable, but it will also be important for carriers to begin offering other core capabilities.

I think there is another perspective that is also worth considering here. The discussion about OTT services is usually portrayed in terms of “closed” carriers vs. “open” OTT players. This doesn’t quite line up with reality. A recent post observed that most OTT services are in fact walled gardens.  The goal of every successful OTT service is to lock users into their services. Interoperability between services is not an objective.  That is why a decade after the IM market exploded, many users still have a half dozen IM clients running all the time. There have recently been limited moves toward interoperability between IM platforms, but these tend to focus on incorporate contacts from partner systems rather than enabling full interoperability.  As the OTT community embraces HTML5 and WebRTC, the situation will get worse, rather than better.  WebRTC defines interoperability at the media level, and enables common client architectures based on browser technology, but it does not define service interoperability. WebRTC will lead to an explosion of real-time communications (RTC) capabilities in apps, but in general these apps will not be interoperable at the service layer. Fortunately, some carriers are beginning to realize that robust interoperability based on open standards, and global reachability, are core carrier strengths.  If carriers can work out how to build on that strength to offer interoperability and global addressing as a foundational service, and make it available through an appropriate set of APIs, it could change everything. Not all users care about interoperability between services, but for the ones who do, it is an extremely valuable capability.

What to watch for:

  • A good barometer for the success of “bandwidth as a service” will be the current dispute between Comcast and Netflix on Xbox 360 Streaming. Netflix is claiming the service violates Net Neutrality principles, while Comcast claims it is a managed IP video service. Watch for an FCC position on this and similar services.
  • Carriers are beginning to talk about cooperation with OTT providers, and about introducing APIs that would bring value to OTT services. Watch for concrete moves to partner with OTT players to introduce APIs that would go beyond simple bandwidth management.

WebRTC – Another Look

Expect to see a lot more about the importance of WebRTC as the specification is completed over the remainder of this year. In that vein, a recent blog by Alan Quale highlighted What WebRTC means to Telecoms. Alan’s blog provides valuable insight, but it may leave some readers with the impression that WebRTC is purely a Google initiative. True, it started that way, and Google continues to be a major supporter of the work. But with strong support from browser vendors like Mozilla and Opera along with many other communications companies, WebRTC has now moved into the open standards arena.  WebRTC (the standard, rather than the Google project) is being defined in a joint project between W3C (the WebRTC working group) and IETF (somewhat confusingly, in the rtcweb working group). The IETF is responsible for defining the WebRTC communications model, the security model, the protocols and the API requirements. The IETF charter indicates that all milestones will be complete by June of this year.  They won’t meet this deadline, but they will almost certainly complete the current milestones by the end of the year.  W3C  is responsible for specifying the WebRTC API. The W3C charter indicates the Proposed Recommendation (PR) for the API will be complete in Q4 2012, and shows an overall end date of 28 Feb 2013 for the working group. This timeframe is plausible. Early versions of the WebRTC API have already been released. Google Chrome released an early version in January, and deprecated the previous proprietary version of the API in March.  At the March IETF meeting, Mozilla demonstrated a browser based video chat app based on WebRTC, and early implementations of the WebRTC APIs will be available in Firefox’s developer stream in the near future. Microsoft HTML5Labs has released a number of prototypes of WebRTC APIs, with the most recently release in March of this year adding support for the W3C getUserMedia method. We are seeing support in the mobile browser segment as well, with  Opera introducing early versions of WebRTC into its mobile browser.  Firefox, Chrome, and IE account for nearly 80% of the browser market, and Opera is the largest mobile browser, so all of this points to near-standard versions of the WebRTC APIs being readily available before the end of this year. The initial functionality will be fairly limited, but it will allow app developers to begin using the APIs to introduce real-time communications into their apps.  This is good news for WebRTC.

The target audience for WebRTC is web developers. The WebRTC working group talks about adding real time audio to an app with twenty lines of code, or video conferencing with 100 lines. These are not necessarily literal targets, but it does set the tone for the work. Of course, optimizing for simple web applications will likely make interworking with legacy SIP clients more complex. The IETF working group has suggested that interworking with legacy SIP clients would ideally be possible without a media gateway, although it recognizes that a signalling gateway would almost certainly be required. However, a number of capabilities that are currently being considered for WebRTC make it likely that both media and signalling gateways will be required for interworking with legacy SIP clients. Many of these protocol choices, SRTP and DTLS for example, follow from the WebRTC security model. (Look for a discussion of the WebRTC security model in a future blog post.)  However, the need for signalling and media gateways to interwork with legacy SIP clients may not actually be that big of a deal. Most existing SIP clients are deployed by Enterprises and Carriers. Both have strong border security requirements, and would likely insist that all WebRTC traffic, both signalling and media, go through a Session Border Controller anyway.

WebRTC will fundamentally change the communications landscape by making it very easy to add real-time communications (RTC) to applications.  Today, applications like Skype, Google Voice, GoToMeeting, WebEx, Join-Me, and Live Meeting all include real-time communications capabilities. But these are complex native apps, or require browser plug-ins. They introduce complexity, degrade performance, and introduce vulnerabilities. On the other hand, WebRTC apps will be able to run directly on the web browser.  This means:

  • WebRTC apps will be able to take advantage of standardized mechanisms for NAT and Firewall traversal. Very small app development teams will be able to reliably do things that only large development teams can do today.
  • WebRTC apps will be implemented in JavaScript, hosted on a Web server, and downloaded and run on the browser. Simple audio mixing and media rendering capabilities will be provided by the browser.  Users will not have to install the app on their computer or Smartphone, simplifying the user experience.
  • Security vulnerabilities will be addressed by regular browser updates, and new functionality will simply be introduced in the Web Server. The user will not need to regularly update apps.
  • WebRTC apps will be platform independent. Today’s RTC applications have unique clients for each desktop and mobile platform, and these must be developed, maintained and upgraded by separate teams. This makes lifecycle management expensive for the developer and for the user. WebRTC apps will dramatically reduce these costs.

With the availability of WebRTC, expect to see a proliferation of very simple apps with RTC functionality.  This will include everything from simple multi-player games with a browser based audio chat capability, to conference bridges on little league baseball team websites. These apps will be browser based and platform independent.  They will not have to be installed on your computer and updated regularly to add functionality or address security vulnerabilities. These apps will take advantage of browser updates, and the platform independent app will reside on the Web server. WebRTC will also allow today’s native apps to introduce simple browser based clients that will dramatically reduce lifecycle management costs.

With all that WebRTC can do, it is important to also realize what it will not do.

  • WebRTC will not make phone numbers irrelevant. As long as PSTN users want to reach you – think of your Grandmother here – there will be a role for phone numbers. And don’t confuse a phone number with a PSTN phone. You cannot buy a domain name today without providing a ZIP code, even though you’ll never receive mail from the domain registrar. If anything, WebRTC will increase the need for a universal identifier. Many Internet services and social networks recognize this, and are working to address this need. But phone numbers have a number of attractive properties that could allow them to be particularly effective in fulfilling this role.  This is a very real opportunity for carriers. The question is whether or not they will be able to seize it in time.
  • WebRTC will not allow all apps to talk to each other, at least not without a signalling gateway. The whole point of WebRTC is to allow app designers to add RTC capabilities without having to worry about the intricacies of SIP, or XMPP, or whatever. The media descriptor (SDP) that will be generated and interpreted by the browser will be fully standardized, but the transport of that information is left entirely up to the app.  WebRTC will make it easy for a developer to include RTC capabilities in a web app, but it will not make it easy to talk to the next cool RTC enabled app that comes along. If you want a sense of the WebRTC future, look at instant messaging. The IM market is characterized by innovation, speed to market, and isolated islands. WebRTC might interwork at the media level, but at the signalling level it will look a lot like the IM market.

WebRTC will unleash  a wave of innovative real-time communications applications from web developers both large and small. It will make it economical to develop RTC apps targeted at extremely niche markets. It will allow amateurs to develop personal RTC apps. This will create a rich and vibrant communications ecosystem.  But for the subset of communications that require universal reachability – and it is a subset – there will still be a role for directory systems that allow you to reach anyone, and for gateways that interconnect between systems.

This post was prepared with input from Mike Leeder. Mike is an Expert, Visionary and Evangelist for Applications, Communications, and Disruptive technologies.

Behind the Headlines…

Headline:

An important or sensational piece of news. The purpose of a headline is to attract attention.

Behind the Headlines…

A more detailed look at the latest headlines, focusing on the technical substance behind the story. The purpose of Behind the Headlines is to provide a more balanced perspective on the current headlines, highlight the implications of the latest developments, and give readers the information they need to understand the technical reality behind the headlines…