Amazon Tech Support

  • Subscribe to our RSS feed.
  • Twitter
  • StumbleUpon
  • Reddit
  • Facebook
  • Digg

Tuesday, 3 April 2012

Operator WiFi: Seamless is the wrong approach

Posted on 07:43 by Unknown
*Sign up for this blog's email list*     *Attend #TelcoOTT / Future of Voice workshops*

As well as #TelcoOTT services and voice & messaging, many of my meetings over the last month or two have been about WiFi - specifically, its evolution as a carrier-driven technology for offload and other purposes. I've been speaking with various operators, vendors and industry associations. I also participated in a recent webinar (sponsored by iPass, a client of mine) about this theme.

There appear to be two broad trends:

1) There is massive operator interest in large-scale WiFi deployments - for example, the Chinese operators, KDDI in Japan and various players in North America
2) However, there is also massive confusion and naivety about exactly how WiFi is going to be controlled, especially in terms of the user experience from the handset

There seem to be various underlying causes of this confusion:

1) Market participants from the cellular side of the industry are mistakenly assuming that "offload" is the only, or most important, use of WiFi on a handset - often without a decent definition of what offload actually means.
2) Some market participants know that there are multiple use-cases for WiFi, but are actually engaged in trying to subvert this so that their needs and requirements are better-served than those of end-users.

The problems can be largely summed up with a single word: "seamless". The cellular industry has an unhealthy obsession with getting rid of "seams", not understanding that sometimes they are valuable and worth keeping (or even worth adding deliberately).

Sometimes, seamless is good - for example, when a mobile phone user is moving and moves from one cell-tower to the next mid-call, without noticing. Having your phone automatically hook up to WiFi when you get home is good too.

But in other cases, seamlessness is a mixed blessing - for example in the case of international roaming. While it undeniably convenient at one level for handsets to transparently connect to a visited network, the downside is that this can lead to "bill shock", anticompetitive pricing or conditions - especially for the dark art of data roaming. This is why the European Commission is currently trying to re-introduce seams, potentially allowing users to select a separate roaming provider to their home operator. It is also why so many users create their own seam - switching off data roaming entirely.

And finally, there are times when seamless connection is outright bad - for example, if a device is "forced" to use a specific network, when the user or perhaps an app would prefer a different one. This is especially relevant for WiFi, where there are frequently various options for connection, with different ownership, speed, price, security and features. Most WiFi use is private connectivity (it's WLAN - ie wireless ethernet), not offload, and operators have no business becoming involved in it.
 
Think about an iPhone versus an iPod Touch. Any WiFi use on the iPod is by definition private - it can't be offload as it doesn't have a cellular radio to offload from. Therefore the same use on an iPhone should also be considered as private WiFi access, not offload, and outside of telco visibility and control.

Some of the proposed standards even suggest switching on the device WiFi non-consensually by the network (see this post of mine about OMA), while others such as the 3GPP's ANDSF tries to push or enforce preferences for network selection.

While for certain use-cases this might be beneficial (eg a Kindle-type device connecting to WiFi in the background, with no user intervention), in other cases it will lead to a significant restriction in user freedoms, and may directly inhibit some innovative business models. For example, O2 UK is exploring an onload model for WiFi, aiming to capture users from other network operators, rather than offloading its own subscribers' cellular traffic. There is plenty of scope for conflict where the device (and its SIM-driven seamless connection policies) contradict an app the user has empowered to make its own WiFi decisions.

Another angle on seamlessness comes from a venue-owners' perspective. Imagine that you run a cafe, with WiFi available for customers as perk (pun, apologies!) for their patronage. Your customers like it, some of them connect their phones or laptops, and come back regularly for coffee. Others ignore the WiFi sign for various reasons - perhaps because they are chatting rather than browsing Facebook or doing Skype video calls. Now imagine the same cafe with seamless WiFi. All customers' phones connect automatically. The net result is congestion - users get a poor experience, the cafe owner needs to upgrade the broadband connection, and meanwhile the atmosphere of the venue changes as people spend more time on their phones than with their friends. That is not a positive outcome for seamlessness and automated WiFi log-on. In some cases a little friction is a *positive* for loyalty and promotion - it gives the marketeer a better image of customer-friendliness, while limiting their extra capex/opex. The same is true of airline frequent flyer schemes, which gain loyalty despite the fact it can be hard to actually redeem points for flights.

There are also other insidious aspects here - various vendors I've spoken to have products that can monitor a user's entire handset WiFi experience, tracking which access points you connect to, perhaps enforcing policies even where those APs are not operator-owned or -affiliated. While there are some corner-case exceptions here (eg the perennial content-control for kids use case), this is not acceptable for massmarket use. Indeed, for many enterprises, an attempt by a carrier to check up on private WiFi use could constitute an unacceptable security breach.

Overall, many of the operators and standards bodies involved in carrier WiFi need to go back to the drawing board and start again. Their connection-management designs need to recognise that seams must sometimes remain visible to users, or applications acting on their behalf.

Another way to think about it is that seam=border . And borders can be crossed in many ways - a simple signpost by the roadside (eg in Schengen Europe), basic passport checks, more involved arrival cards, paid visas, deliberate illegal entry (smuggling). Or you can be taken across against your will, blindfolded in the back of a van.

Personally, I don't want my WiFi "trafficked" across borders without my consent. Seamless WiFi has its uses, but it should not be viewed as a universal target or "obvious truth" by the cellular industry.

*Sign up for this blog's email list*     *Attend #TelcoOTT / Future of Voice workshops*
Email ThisBlogThis!Share to XShare to FacebookShare to Pinterest
Posted in | No comments
Newer Post Older Post Home
View mobile version

0 comments:

Post a Comment

Subscribe to: Post Comments (Atom)

Popular Posts

  • Quick musing on Cloud Computing
    I just heard the phrase "Everything as a Service" during a presentation on Cloud, SaaS and other forms of managed service offering...
  • Apple, embedded SIMs, NFC and mobile payments - some speculation
    I wonder if I've just managed to join up the dots on something rather important: - Recent reports suggest that Apple is intending to use...
  • New Cisco VNI traffic report out
    One of the broadband industry's "bibles" has been published in a 2010 edition . Cisco's "Visual Networking Index...
  • Is the MID a market?
    MIDs (Mobile Internet Devices) are being pushed by some notebook OEMs and silicon suppliers as the next big convergent handheld category. I...
  • "You can't use my eyeballs for free"
    Let's look forward 10 years. We've all got augmented reality browsers on our handsets, or perhaps our 4G-connected sunglasses. They ...
  • Mobile traffic management - the Inter-technology war begins
    I've been following the proliferation of mobile broadband traffic management technologies for some considerable time now, having publish...
  • Pre-MWC notes for analyst relations staff
    OK, it's the time of the year when I get bombarded by emails and phone calls from a million people inviting me to briefings and similar ...
  • Mobile operators' future voice strategies decoded
    Apologies in advance, but this blog post is deliberately a bit of a tease. I'm not going to spell out the answer here, as it's too v...
  • Hosted mobile services in the recession - Caveat Emptor
    I used to work as an equity analyst at an investment bank back in 2000-2001. I remember an unending stream of first generation Application S...
  • Challenges in measuring offload volumes
    I suspect we're going to get bombarded with statistics in the next year, along the lines of "Operator X deployed Vendor Y's off...

Blog Archive

  • ►  2013 (31)
    • ►  October (2)
    • ►  September (3)
    • ►  August (1)
    • ►  July (2)
    • ►  June (6)
    • ►  May (5)
    • ►  April (1)
    • ►  March (3)
    • ►  February (3)
    • ►  January (5)
  • ▼  2012 (46)
    • ►  December (5)
    • ►  November (4)
    • ►  October (3)
    • ►  September (2)
    • ►  August (4)
    • ►  July (3)
    • ►  June (1)
    • ►  May (6)
    • ▼  April (4)
      • Some of my current thinking about RCSe / Joyn
      • Which operator app-level collaborations actually w...
      • London Telco-OTT & Future of Voice workshops April...
      • Operator WiFi: Seamless is the wrong approach
    • ►  March (1)
    • ►  February (9)
    • ►  January (4)
  • ►  2011 (73)
    • ►  December (4)
    • ►  November (10)
    • ►  October (8)
    • ►  September (6)
    • ►  August (3)
    • ►  July (5)
    • ►  June (7)
    • ►  May (9)
    • ►  April (4)
    • ►  March (7)
    • ►  February (6)
    • ►  January (4)
  • ►  2010 (130)
    • ►  December (4)
    • ►  November (10)
    • ►  October (10)
    • ►  September (6)
    • ►  August (9)
    • ►  July (7)
    • ►  June (19)
    • ►  May (19)
    • ►  April (11)
    • ►  March (18)
    • ►  February (7)
    • ►  January (10)
  • ►  2009 (126)
    • ►  December (4)
    • ►  November (14)
    • ►  October (9)
    • ►  September (8)
    • ►  August (9)
    • ►  July (10)
    • ►  June (21)
    • ►  May (14)
    • ►  April (2)
    • ►  March (11)
    • ►  February (15)
    • ►  January (9)
  • ►  2008 (94)
    • ►  December (24)
    • ►  November (26)
    • ►  October (25)
    • ►  September (19)
Powered by Blogger.

About Me

Unknown
View my complete profile