One of the hidden trends that I've been watching for a while, in the complex world of mobile broadband traffic management, is now starting to come to the surface: the action is moving down to the device/handset itself.
While a lot of manufacturers of "big iron" boxes like to imagine that the core network or the RAN is all-seeing and all-powerful, the truth is that any discussion of "end-to-end" is only true if it extends out to the user's hand (or ideally, retina or ear-drum). That is where quality of experience (QoE) really manifests itself and where radio decisions (especially about WiFi) are controlled. Anything observed or inferred from within the network about the handset is a second-best simulacrum, if that.
That's not say that the network-side elements are not useful - clearly the policy engines, offload and femto gateways and analytical probes in the RAN have major (even critical) roles to play, as well as the billing/charging functions allowing the setting of caps & tiers - even if I am less convinced by the various optimisation servers sitting behind the GGSN on the way to the Internet.
But most major network equipment vendors avoid getting involved in client software for devices for a number of reasons:
There are various use cases and software types emerging around device "smarts" for assisting in mobile traffic management, for example:
However, one that I will highlight as being very interesting is Mobidia [not a client], which aims to put control into users' hands, rather than boxes in the network making arbitrary policy decisions. For example, it's one thing for an optimisation server to guess whether the user prefers a "non-stalling" but degraded video - but quite another (and much better) solution, for a software client to let the user participate directly in that decision and trade off quality vs. impact on their monthly data quota, via an app. I was very impressed when speaking to them, especially in comparison with some of the purely network-centric DPI/policy/optimisation vendors I met in Barcelona. I think this type of user involvement in policy will be an important piece of the puzzle.
Management of WiFi connectivity is another area where device-level touch points are important. Although some aspects can be managed from a device management / configuration box in the network - or via standards like 802.11u - that is only ever going to be a partial answer. There will need to be a proper on-device client with a UI, in order to get the experience right in all contexts. (I'll do another post on WiFi offload soon as there's other important issues, especially about the idea of backhauling traffic through the core).
Overall - device-based policy management is difficult, messy, heterogeneous and difficult to monetise. But it is going to be increasingly important, and the most far-sighted network vendors would do well to look to incorporate the "real edge" into their architectures.
While a lot of manufacturers of "big iron" boxes like to imagine that the core network or the RAN is all-seeing and all-powerful, the truth is that any discussion of "end-to-end" is only true if it extends out to the user's hand (or ideally, retina or ear-drum). That is where quality of experience (QoE) really manifests itself and where radio decisions (especially about WiFi) are controlled. Anything observed or inferred from within the network about the handset is a second-best simulacrum, if that.
That's not say that the network-side elements are not useful - clearly the policy engines, offload and femto gateways and analytical probes in the RAN have major (even critical) roles to play, as well as the billing/charging functions allowing the setting of caps & tiers - even if I am less convinced by the various optimisation servers sitting behind the GGSN on the way to the Internet.
But most major network equipment vendors avoid getting involved in client software for devices for a number of reasons:
- The standards bodies are generally very poor at specifying on-handset technology beyond the radio and low-level protocols, and even worse at encouraging OEMs to support it. Few network equipment firms are willing to go too far down the proprietary route
- There is a huge variety of device types and configurations, which means that vendors are likely to need to develop multiple complex solutions in parallel - a costly and difficult task. It is also unclear how device-level software can be easily monetised by network vendors, except in the case of integrated end-to-end solutions.
- There are various routes to market for devices, which makes it very difficult to put operator-centric software on more than a fraction of products. In particular, buyers of unlocked devices such as PCs or "vanilla" smartphones are going to be vary wary of installing software seen as controlling and restricting usage, rather than offering extra functionality
- Testing, support, localisation, upgrades and management are all headaches
There are various use cases and software types emerging around device "smarts" for assisting in mobile traffic management, for example:
- Offload assistance and WiFi connection management
- Security such as on-device application policy and encryption
- User alerting - or operator feedback - on congestion and realtime network conditions from the handset's point of view
- Quota / data-plan management
- Feedback to the network on device status (eg power level, processor load etc)
- User control of application data traffic
- Low-level connectivity aspects
However, one that I will highlight as being very interesting is Mobidia [not a client], which aims to put control into users' hands, rather than boxes in the network making arbitrary policy decisions. For example, it's one thing for an optimisation server to guess whether the user prefers a "non-stalling" but degraded video - but quite another (and much better) solution, for a software client to let the user participate directly in that decision and trade off quality vs. impact on their monthly data quota, via an app. I was very impressed when speaking to them, especially in comparison with some of the purely network-centric DPI/policy/optimisation vendors I met in Barcelona. I think this type of user involvement in policy will be an important piece of the puzzle.
Management of WiFi connectivity is another area where device-level touch points are important. Although some aspects can be managed from a device management / configuration box in the network - or via standards like 802.11u - that is only ever going to be a partial answer. There will need to be a proper on-device client with a UI, in order to get the experience right in all contexts. (I'll do another post on WiFi offload soon as there's other important issues, especially about the idea of backhauling traffic through the core).
Overall - device-based policy management is difficult, messy, heterogeneous and difficult to monetise. But it is going to be increasingly important, and the most far-sighted network vendors would do well to look to incorporate the "real edge" into their architectures.
"Anything observed or inferred from within the network about the handset is a second-best simulacrum, if that."
ReplyDelete>>> I'd differ; while handset/device involvement is essential, the network view is tantamount as IT sees all the traffic. As an analogy, driving in a car and without any network (aka google traffic map input), you wouldn't know you have hit traffic congestion until you actually have. At that point you are already stuck. I think google traffic (a.k.a network in this use case) plays a leading role. Having said that, the device intentions are very important as you mentioned since the network cannot guess that in isolation.
<<<<<
"The standards bodies are generally very poor at specifying ...."
>>>> Not entirely correct, 3GPP has extensively defined Access Network Domain Selection Function (ANDSF) ; almost too much standardization if you ask my opinion. However, the problem is smartphone architecture. mobile devices are no longer closed devices under the control of device vendors like samsung, LG etc. Smart Phones (e.g. Android based) are more integrated where HTC takes a generic h/w, slaps on a QC SoC, ports android and ships them out. In this design, where will such policies reside. In android OS ? Do you think Google will look at 3GPP specs like ANDSF and implement them .. i doubt it .. as 3GPP is more of a TELCO fest than WWW.
Hi Dean
ReplyDeleteHave you seen our (INQ's) stuff on WiFi management?
Automatic WiFi on-off based on known locations of AP's, known networks.
Toes in water, but the right direction.
Cheers
Mike
Dean,
ReplyDeleteBased on previous posts, i see you did research on Traffic Management. Not sure if you know this but i happened to take a close look at my Verizon data (dongle) plan and noticed the following fine print and you might be interested in looking at this (I am personally pretty impressed at the detail and candidness; there is some spin in the last para though):
------------------------------------
Verizon Wireless is deploying optimization technology in parts of its 3G mobile broadband network. This network management technology is designed to transmit data more efficiently, ease capacity burdens on the network, primarily from video files, and improve the user experience with faster downloads and decreased Internet latency.
Given the increasing web traffic for downloading video files, video optimization in particular benefits both the user as well as the network by facilitating sustainable online video browsing using only the required amount of data while enhancing the video experience and making room for other users to enjoy higher browsing speeds. Although much effort is invested to avoid changing the file during optimization, and while any change to the file is likely to be indiscrnabile, the process may minimally impact the appearance of the file as displayed on a device.
The optimization techniques are applied to all content files coming from the Internet Port 80 that use the most common compression formats. The form and extent of optimization depends on the compression format of the content file, but does not depend on the content of the file, the originating web site, or the user’s device. No distinction in the application of these techniques is made based on the source website or originator of the content. The system optimizes files based strictly on the type of file and the relevant file formats (recognizing that some file types are not modified). Accordingly, all content, including Verizon Wireless branded content, of the same type will be subject to the same process.
YOUR Blog post would not take more than 4K characters as a Post so the full copy is at :
http://www.rghai.com/post/3624281672/interesting-disclaimer-on-my-verizon-mifi-data-contract