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

Need an experienced, provocative & influential telecoms keynote speaker, moderator/chair or workshop facilitator?
To see recent presentations, and discuss Dean Bubley's appearance at a specific event, click here

Thursday, March 17, 2011

WiFi highlights an inconvenient truth about QoS...

... it's not always needed.

Increasingly, smartphones get used with WiFi. Some estimates suggest that up to half of data usage now goes over WiFi. Most of that WiFi is connected from homes, offices or public hotspots over backhaul provided by an operator other than that providing the cellular connection to the smartphone. Although in some cases there is an offload agreement in place, there is usually no direct measurement or control of QoS end-to-end.

But some operators have (or are launching) their own data and content services - whether it's a content site, their appstore, remote backup or even RCS. This means that some of the access will come in to the operator domain via the open Internet. This isn't new in itself - technologies such as UMA/GAN have been around for a while, as have assorted softphones, remote access clients and so forth. But what this implicitly means is that for some of the time, at least, operators are happy to have their services accessed by their customers over the public Internet. With all of the potential downsides that suggests.

Plus, this means that in those situations, the operator is itself acting a so-called "OTT" provider, riding for free on somebody else's pipes. Are they first in the queue to offer to pay their ADSL/cable saviours for QoS guarantees? No, I thought not.

So the obvious question has to be - if it's OK to connect via an unmanaged network some of the time, then why not all of the time? Are they warning their customers that reliability might be lower if they connect via WiFi? What rights do their customers have if performance is below par?

Now obviously in most cases here the fixed connection used for WiFi is faster than the mobile network would have been - so "quality" in some regards is arguably actually better. But it's still not actively monitored and managed, and both the Internet portion of the access and the WiFi radio itself are subject to all sorts of contention, congestion, packet loss and other threats.

I know that various attempts are being made to bring WiFi into the operator's control - or at least visibility and policy oversight - with selective offload and ANDSF and I-WLAN and various proprietary equivalents. But even these will not cover all situations, even when viewed throught the rosiest tinted glass.

But surely, if a QoS-managed and policy-controllable network is that critical, surely there ought to be explicit notifications to users that they are accessing the service via an unmanaged connection? Maybe, in extremis such access should even be blocked?

Flipping this around the other way.... if it's OK for your access customers to access your services over the Internet on an OTT basis, at least some of the time, why not also let other people access those services as well?

2 comments:

Mark Grayson said...

Hi Dean

I view QoS as a probabilistic issue; there is a probability that it won't be exercised, e.g., if resources are abundant.

QoS procedures should be able to remedy conditions when resources are scarce. Which brings to focus a couple of key use cases:

i) WiFi is unlicensed and there may be non-WiFi interferers located in close proximity to the user - what "QoS functionality" is available to remedy such situations?

ii) Cellular has coverage holes - by their nature if I'm in a hole, resources are for sure constrained - what "QoS functionality" is available to remedy such situations?


Cheers,
Mark Grayson
Cisco

Richard Bennett said...

Your better implementations of voice over WiFi do in fact use QoS: It's called WMM, a subset of the QoS standard for WiFi, 802.11e. The way this works is by playing with the collision avoidance delay variable for WiFi.

So your premise is false.