Context-specific managed offload for mobile data...

© Disruptive Analysis Ltd, November 2010 Context-specific managed offload 1

Context-specific “managed offload” for

mobile data traffic

A Disruptive Analysis thought-leadership paper

Commissioned by Continuous Computing (now Radisys) November 2010

Author: Dean Bubley Contact: [email protected]

Disruptive Analysis Don’t Assume


Summary: One of the most popular ways to deal with mobile broadband traffic growth is to “offload” it, typically to WiFi access points or femtocells. Also giving improvements in indoor coverage, these methods reduce load on the main macro-cellular network, cost of backhaul, and can also improve users’ experience in terms of speed.

However, the range of possible offload options is proliferating fast; they also involve a complex mix of control by operator, end-user, device and/or third-party service providers. This is generating a requirement for mobile broadband operators to be more intelligent and strategic in how, where and what traffic they divert to these alternative accesses. As operators develop their own IP-based data services, they may wish to treat these differently to bulk Internet downloads in terms of data routing. There is also a significant potential role for fixed and cable operators to run “managed offload” services on behalf of the mobile carriers. Understanding and managing offload effectively will be a key driver in future profitability and reliability of mobile broadband services.

Background

This white paper covers a number of issues around next-generation offload of mobile data network traffic to reduce load on operators‟ Radio Access Networks (RANs) and core networks, as well as the role of Deep Packet Inspection (DPI) systems in enabling this. It has been written by the independent industry analyst and consulting firm Disruptive Analysis, and sponsored by Continuous Computing (now Radisys), as part of an initiative to promote thought-leadership, differentiation and innovative networking concepts for the mobile broadband and network policy-management marketplace. The opinions expressed are Disruptive Analysis‟ own, and are not specific endorsements of any vendor‟s or operator‟s products or strategy.

Introduction

The emergence of the offload concept The concept of mobile broadband offload first started to become a major theme in 20081. Disruptive Analysis and others noted that the bulk of mobile data on cellular networks was originated from, or destined for, the Internet, rather than the operator‟s own services, and was therefore unnecessary to push through all the complex core network machinery rather than connect via a more direct and inexpensive route straight to the Internet. Since then, an even more pressing concern has arisen: the need to offload the RAN because of heavy congestion from both the volume of network traffic and the associated signalling load from smartphones and their applications. Readers will no

1 http://disruptivewireless.blogspot.com/2008/06/is-internet-offload-next-bottleneck-for.html



doubt be very familiar with the general data explosion / tsunami / capacity crunch stories, and the iconic scissors-style graphs of data volumes out-stripping growth in revenues. Recently, a variety of offload solutions have emerged, mostly WiFi-based, and many intended for deployment with firefighting levels of urgency. Some of the early offload variants have been comparatively “clunky”, especially those involving user intervention to switch to WiFi, although improvements in connection manager software has made this somewhat more seamless. Longer-term and more elegant options are also now being proposed, notably with femtocells / small cells, Long Term Evolution (LTE) or later versions of the 3GPP standards, such as SIPTO (Selective IP Traffic Offload). The general aim is to get as much of the low-value, bulk Internet traffic off the mobile operator‟s network as quickly and painlessly as possible, with the lowest cost, with the aim of reducing current congestion and delaying future capex for upgrades. And if elements of the cost or management of the infrastructure can be borne by someone else (e.g., the user themselves), then so much the better.

Figure: Network congestion is prompting the desire to offload data

Source: Disruptive Analysis

It is important to recognise that some forms of offload connectivity demonstrate elasticity of demand – cheaper / faster local WiFi or femtocell connections may actually lead to the consumption of more data, rather than just substituting for what would have been expected over the normal macrocell / core network data path. Perhaps as much as 50-70% of notional offload traffic may really be incremental.

Offload vs. core-network policy management One of the paradoxes about mobile offload in the radio network is that it can work against some of the other policy-management techniques used by the operator. This is a common problem in traffic management where silo solutions are deployed in one part of an operator‟s system to solve a specific issue or bottleneck – but inadvertently cause “collateral damage” elsewhere.



In this instance, many of the DPI and policy boxes have been deployed “deep” in the network – either integral to GGSNs (Gateway GPRS Support Nodes), or between them and the Internet. This is much easier than deploying them in the RAN, as traffic is centralised on those links and so fewer elements are needed. The problem is that these boxes are not necessarily aware of RAN conditions, and especially offload activities, taking place closer to the end-user. For example, there is no real reason to compress or transcode video delivered via a femtocell, as it will not be contributing to macro radio network load. Worse still, it may mean that direct comparisons of image quality and download speed between (non-operator visible) WiFi and the femto, on the same broadband line, are unfavourable. So in scenarios where management servers are trying to limit congestion on the air interface, they may not be in possession of the full facts in order to make the right decisions policy-wise. In other words, offloaded traffic may still cause congestion somewhere, but not at the point that many DPI solutions would be aware of it. Disruptive Analysis believes that for this reason, standalone solutions for traffic management, especially in the core network (typically on the Gi interface), are going to become less useful over time. Instead, more holistic solutions make sense, where those DPI or policy servers are still used for specific tasks (such as video optimisation for operator / Internet mash-up services), but work collaboratively with other sub-systems to combat outright levels of RAN congestion. There will also be a shift towards deploying traffic management at RAN or aggregation levels, rather than just in the core.

Offload variants

A major complexity is the ongoing proliferation of offload sub-categories, and the use of the term fairly indiscriminately to group together a wide range of scenarios. The most important include:

Unmanaged WiFi offload in the home or office, where data traffic from a mobile device (e.g., smartphone) is converted into just another stream of bits over the main fixed broadband heading for the Internet, as if it were another fixed PC connected to the modem. The operator has no responsibility or direct cost for the connection to the Internet, although it may configure the device‟s software or hardware to make this possible or even forced. Theoretically, it is possible to perform unmanaged local offload with femtocells, but forthcoming standards such as LIPA (Local IP Access) are likely to involve the operator in the process, as legal responsibility for the last metres of access using licensed spectrum usually still reside with them.

Direct-managed offload in home / office, where the network operator retains some level of control and visibility over traffic offloaded from the device, over WiFi or femtocell. “Management” could involve policy control over when and how offload is conducted, or which traffic is diverted to bypass the operator‟s own network. It could also involve aspects of lawful intercept – particular for femtos using licensed spectrum. New standards such as SIPTO are relevant here.

Public WiFi offload. Increasingly, mobile operators are building networks of WiFi hotspots, or partnering with existing Wireless Internet Service Providers (WISPs) and aggregators such as Boingo or BT Openzone. A variety of software techniques such as WISPr2.0 help user devices connect to available



WiFi access points where possible, although often the offload traffic is not subject to the mobile operator‟s detailed policies.

Small cell offload. It is likely that some use of public mobile femtocells (or other “small cells”) will also emerge in the medium term, either in single-operator form, or shared, perhaps via roaming arrangements. In 2010, the femtocell industry has started focusing beyond residential access points, towards larger, outdoor-oriented cells, seen as a cheaper and more distributed alternative than traditional microcells and picocells. Variously called picocells, greater femtos, superfemtos, small cells and even macro-femtos, the principle is much the same. They are intended to support capacity addition or offload in dense areas, or to provide coverage in more remote regions, with the aid of inexpensive IP connections and minimal administration overhead in installation and provisioning.

3rd-party managed offload. In this scenario, the offloaded traffic over the broadband line (from WiFi or femto in the home), is identified by the fixed operator as being related to the mobile device and the operator. This would typically take place at the local exchange or cable head-end. The fixed / cable operator (which may be independent from the cellular provider) is involved, separating out certain traffic streams and diverting them away from the cellular core network. There may be a contractual relationship between the two service providers.

Offload in the MNO’s transport network. Both femtocell and macrocell traffic can be direct-connected to the Internet from the transport network, rather than transiting the whole expensive core infrastructure. Breaking out Internet traffic in this way reduces expenditure on upgrading SGSN / GGSN elements. This is another use-case for SIPTO, as well as various other proprietary architectures. In some cases, the offload may be performed by a 3rd-party transport provider (e.g., long-haul fibre), rather than the mobile operator‟s own aggregation infrastructure.

Managed vs. unmanaged offload From a mobile operator perspective, the main problem with unmanaged approaches to data offload is unpredictability. Where the operator is also the provider of WiFi hotspot services, or runs the user‟s own home broadband connection with a femto or WiFi capability, it is (theoretically) able to control the offload connection from end-to-end. It can put in place mechanisms to ensure adequate QoS, monitoring performance and ideally prioritising traffic against other flows. Potentially, it may also control the connection management software on the device in order to „force‟ traffic through the lowest-cost or least-congested connection. In the real world, the number of homes that might realistically have a single operator for both fixed broadband and all the household‟s various mobile devices is quite small. While family plans can be attractive, they are unlikely to be ubiquitous or complete. Some individuals may have company-issued devices, others may want operator-specific exclusives. As we move towards multiple devices per person (and niche products such as consumer electronics with embedded modems), the idea of a single operator becomes ever more remote.



Thus there will inevitably be many situations in which one mobile operator‟s traffic is offloaded onto another‟s network. This means it faces uncertainties in setup, contention against other applications running on the network, and the potential for service interruption or interception. Tensions are inevitable where a given fixed + mobile broadband operator is expected to support access from one of its direct rivals‟ femtocells, or via a MiFi-style personal hotspot.

Figure: Unmanaged offload via third-party network may cause problems


There is also the future threat of fixed / cable operators blocking or degrading offload traffic – especially in those ironic cases where mobile operators themselves have campaigned against Net Neutrality. Implementing similar DPI techniques to mobile operators, it could even be possible to discriminate on the basis of end-devices supplied by particular operators.

Shared-offload networks As well fixed and cable operators becoming involved in managed offload, another scenario is also becoming more likely: that of shared networks co-owned by a number of mobile carriers, or perhaps outsourced to a 3rd party such as a large vendor or managed services firm. Macro RAN sharing and outsourcing is already becoming quite common in some places, and it is possible that femto-sharing may also evolve in coming years. There are multiple architectures and ways of organising such operations, ranging from simple co-location on towers, through in-country roaming, to full sharing of active network infrastructure elements between multiple service providers. In many senses, de-facto networking sharing has also existed for years through Mobile Virtual Network Operator (MVNO) arrangements, with various retail operators effectively purchasing wholesale capacity on a host network. This area is likely to expand in complexity in coming years, as more innovative wholesale and infrastructure-ownership schemes are adopted. Various existing frequency bands are not large enough for 4 or 5 operators to share in wide-enough



allocations for the fastest implementations of LTE, while some territories are deliberately pursuing a path of wholesale mobile in the same fashion as open-access fibre. Whether this is all termed “offload” in general is largely a matter of semantics, but it seems likely that specific femtocell implementations will occur anyway, which certainly will need improved management by the host service provider.

The role of DPI & policy in next-gen offload

A broad range of issues & problems The previous sections highlight the growing fragmentation of the overall offload concept. Coupled with the interaction between network element, smartphones and third-party elements (such as connection management software), it seems inevitable that operators‟ policy infrastructure will need to grow more intelligent to cope with the various scenarios that will emerge. Detecting users, locations, applications or device type via DPI will become important in determining overall offload strategy, as well as (eventually) making granular decisions on the optimal routes for particular traffic in real-time. Device awareness, for example, may be an indicator of the user-friendliness of the WiFi implementation. Application-awareness may also be important, especially if the operator is working with an Internet or cloud-computing partner that is somehow optimised for one bearer type, or which is perhaps designed to work differently in specific contexts. In the managed-offload scenario, when either a 3rd-party fixed operator or a RAN-sharing consortium is involved in providing services to the host operator, there is an argument for that outsourcing provider to have its own mobile-focused DPI capabilities. While they may already have their own DPI facilities for fixed-broadband control (e.g., Peer-to-Peer (P2P) throttling), it is possible that this is not optimal for mobile-oriented task, such as device-type detection. In particular, it may be important for the fixed provider to identify femto-to-gateway traffic and signalling, which may need to be optimised in various ways. Often, Internet-destined data is easily identified, as the mobile device connects to a specific Internet APN (Access Point Name), which is a particular route across the network allocated to particular services. It is common for operators to give assign separate APNs for individual services such as the MMS (Multimedia Message Service) server, Internet access or perhaps a dedicated connection for BlackBerries or other devices. Most current mobile broadband traffic transits an Internet APN, although that does not necessarily equate to value to the network operator.

Which offload? The proliferation of offload types will inevitably lead to situations in which individual users have simultaneous access to multiple options. Most residential femtocells will be co-located with home WiFi. Small cells in public locations will coincide with WiFi hotspots. A given device may even have access rights for multiple SSIDs (Service Set Identifiers) on a single WiFi access, via different partnerships and affiliations. In



future, devices will also be capable of connecting simultaneously to both cellular and WiFi, exacerbating the situation still further. This added complexity will lead to a broad range of possible scenarios conflicting – with differing outcomes for the operator in terms of network load, cost and visibility / control. Adding in the use of MiFi-style personal hotspots and tethering, it may even become possible for an operator to offload traffic to another cellular network, deliberately or “accidentally”. [Note: the author is writing this section in a café, in which he can use the WiFi via the café‟s own loyalty scheme, via an extension of his home broadband subscription, or via his mobile operator‟s offload collaboration with the hotspot provider]. At the moment, very little thought is being given to the most likely or most (un)desirable scenarios. Disruptive Analysis believes that a combination of rich network monitoring, intelligent policy management, smart and usable client-side connection management will be needed. In many scenarios, the operator may not retain absolute control over the final outcome, but at least gaining an understanding will be very important indeed.

The emergence of SIPTO and LIPA A long-term potential option is around a forthcoming 3GPP standard called SIPTO, standing for Selective IP Traffic Offload. This particularly relates to femtocell and RAN offload, where particular traffic is routed via different connections directly to the Internet, or via the operator‟s core. A related standard is called LIPA (Local IP Access), which relates to the breakout of connectivity to the local network in the home or office. The Traffic Offload Function (TOF) is the key element in the network here, which will be needed to perform a variety of tasks including policy enforcement and assorted “border” functions such as dealing with Network Address Translation (NAT) headers and lawful interception. It remains unclear exactly what the mechanism and algorithms for selection policy will be in SIPTO, or how these are constructed and maintained. Exactly what traffic goes back via the operator core network, and what goes straight to the local network or Internet? In some scenarios, it might be done with “shallow inspection”, such as involving connections to particular APNs, or via particular ports. However, that may not provide sufficient granularity – and in particular may mean that the operator loses sight of valuable but low-volume information about user behaviour. Consider a scenario in which a user requests a large 2GB video file to be downloaded. It is definitely painful to ship a huge movie across the RAN and core when it could be offloaded locally. But there is value to the operator in capturing certain data about the transaction – the title of the movie, perhaps, or the content provider. This meta-data becomes even more important if the user starts consuming another operator‟s content or services – perhaps a 3rd-party Voice over IP (VoIP) application from a competing telco. The question is how that 1MB of valuable information is kept “on net”, while the other 1.999GB is diverted. Ultimately, it may even be desirable or necessary to implement some form of packet inspection in the WiFi router or femtocell itself.



LIPA is particularly relevant for some home-networking scenarios, especially where there is a desire to use UPnP (Universal Plug and Play) over a 3G femtocell. Use cases might include connection of a mobile phone to the TV or home media server, and in theory if the data transits licensed 3G / 4G spectrum, the operator needs to maintain some visibility and control for legal reasons. (This would not generally apply for WiFi connections, unless the operator somehow configured the device to only allow “managed” WiFi access under its control – a scenario that Disruptive Analysis feels is generally unlikely). LIPA and SIPTO imply that some forms of data inspection – and in some instances, active traffic-shaping and policy control – may need to be pushed out towards the very edge of the network.

VoLTE, mashups and other future operator-hosted services In the future, an increasing proportion of mobile operators‟ own services are going to be IP-based. In particular, with the shift to LTE it will be necessary for voice services to transition to VoIP – either with the 3GPP / GSMA-recommended VoLTE (Voice over LTE) architecture based on IMS (IP Multimedia Subsystem), or one of numerous other possible mechanisms, such as VoLGA (Voice over LTE via Generic Access) or operator partnerships with Skype or Google. In such cases, it is likely that operators will want their own VoIP traffic (and perhaps related elements such as video-sharing) to be given the highest priority and protected against unnecessary latency or possible congestion. This may mean a different approach to offload is needed for such protected services – especially when the path is unmanaged, routed via a 3rd-party‟s access such as WiFi or via femtocell connected over an independent fixed-provider‟s broadband. Where the offload is managed by a third party (or an operator‟s own affiliate), there will still be a need to discriminate between VoIP and other services. It is possible that the selection here will be aided by the choice of different APN names for in-house services, which can be assigned to different classes of service. However this may be more complex in situations where the operator works with a third party such as Skype or an outsourcing provider. There may also be scenarios in which an operator chooses not to offer its own VoIP, but instead to offer priority treatment to the user‟s preferred provider under a “bring your own telephony” arrangement. Even greater complexity may arise where voice or other operator capabilities are “mashed up” with web or additional applications – such as player-to-player conversations within an Internet video-game. In such scenarios, DPI may well be needed to assemble a complete picture of how the user is communicating – and whether a given service needs protection against offload to a lower-quality network, or even might benefit from well-managed offload instead. There will also be requirements to anchor the call and manage mobility, if offload processes are not to break important cellular capabilities such as handoff. This suggests that any “offload control function” will need to work closely with elements such as RNCs (Radio Network Controllers), especially where the user has to move between two RNCs, as this process is normally assisted by the SGSN (Serving GPRS Support Node).



Fixed and cable providers At present, fixed broadband operators generally tolerate the use of user-configured access to home WiFi from cellular devices. Often, with devices such as PCs or smartphones, the WiFi setup may be done purely by the user, without any form of prompting from operator-controlled software. Attitudes may change in cases where the MNO-provided connection software deliberately encourages WiFi offload, perhaps via prompts for the user to input security credentials. Often, it will be almost-impossible to distinguish „operator-encouraged‟ offloading against user-chosen, but the awareness that this is occurring is likely to harden negotiating stances, or attitudes towards throttling or other traffic management techniques. There are two different scenarios here – if the device just „breaks out‟ on to the open Internet, it looks essentially indistinguishable from a PC or other product. But if it establishes a connection to a known operator gateway‟s IP address, perhaps with a VPN „tunnel‟ for that telco‟s own services, then it is much easier to identify. Using DPI, it may be possible for a fixed operator to start to piece together the evidence of how mobile data is being offloaded to its infrastructure. That knowledge may be useful in developing partnerships between fixed and wireless service providers, or as a means of controlling such offload traffic if volumes rise to unsustainable levels. There may even be business models for the fixed / cable operators to assist in the operation of femtocells – perhaps by “grooming” the connection for sync and signalling, or even providing extra overhead bandwidth. For example, consider the situation of a use who subscribes to 6Mbit/s broadband on a line that could actually support 20Mbit/s. The excess capacity could enable offload traffic via a femto to operate faster than the native DSL line speed, if the MNO paid a premium to its fixed partner.

Figure: Fixed & cable telcos can use DPI for managed offload services




Application-specific offload As mentioned above, mash-ups are likely to cause considerable difficulties for policy management generally, and offload in particular. DPI implementations will need to be aware of linkages between different streams of data, which may initially appear distinct, but which mesh together in the device and the eyes of the user. Multi-tasking operating systems may also mean that there is no “right” answer to offload, as different applications might be optimised for use over different bearers. The increasing richness of software and application used on smartphones and other devices will no doubt cause further difficulties in the future – for example, as important services move from being standalone native applications to become browser-based functions, it may be more difficult to distinguish them effectively, or apply them to an appropriate class or quality of service. At the moment, many QoS parameters assume that World Wide Web traffic can be classed as delay-insensitive “interactive” data. That may no longer hold true, for example if an investment company builds an HTML5-based trading application. It is also not always true that voice is the most important application, worthy of protection above other data services. An open question here is whether application-centric offload will come from the perspective of offloading everything except specific services (e.g., operator VoIP), or vice versa, offloading only specific services (e.g., P2P file-sharing or video-streaming from specified sites). Given the diversity and rapid evolution of new Internet-based services, Disruptive Analysis feels that the former approach is more likely, as otherwise operators will be forced to monitor new services continually – a huge and never-ending task. Another area of evolution with mobile broadband is around the different types of network congestion caused by particular applications – for example, the impact of sheer volume of traffic vs. signalling loads. It may be appropriate to offload signalling-heavy traffic such as Instant Messaging (IM) and social networking in a different way to bulk applications such as video downloads. Upstream-heavy traffic (e.g., P2P file-sharing) may cause different problems to more downstream-oriented flows, and again require differential treatment.

User-specific offload At the moment, there is an assumption that all possible traffic that can be offloaded, should be offloaded – but there may be instances where this is not the preferred option. It may be that when the network is uncongested, operators might wish to keep more traffic on-net, particularly compared with using WiFi. This might give better control over Quality of Service (QoS), or permit valuable user data to be captured that might otherwise be lost. There may also be reasons to keep particular users on-net more than others, perhaps because they are being prioritised – or perhaps because they have greater sensitivity to the perceived security risks of offload, especially where it is unmanaged. There could also be differential offload policies for roaming customers, for example where the home operator has a different set of local offload partners to the visited network.



Offload and charging / billing One of the usually-unmentioned consequences of mobile offload is how it fits with the operator‟s billing and charging systems. As more wireless providers move to tiered and capped pricing for data, or more sophisticated tariffs based on other variables, offload needs to be factored in. There have already been cases in which WiFi traffic is essentially invisible and zero-rated against the user‟s quota, while using a femtocell from the same provider counts against the monthly allowance. Given some evidence that good offload performance can increase overall traffic usage, this raises the invidious possibility that the end-user may “pay triple” for the data plan: their home broadband, the femtocell itself, and maybe even extra overage charges. There may also be issues where operators attempt to charge differential prices for certain applications or services – the notion that watching the same content, on the same device, in the same location may cost different amounts may lead to customer confusion and dissatisfaction. As a result, it is going to become very important that billing systems become “offload aware” for a whole set of possible reasons. The same rationale may also need to be extended to other areas of Operating and Billing Support Systems (OSS / BSS), for example customer service functions.

Conclusions

This paper has highlighted the importance of mobile traffic offload, as well as the growing number of ways it can be achieved. Over time, the use cases for each are likely to get significantly more complex – and operators will seek to differentiate their services and better support customers with more granular approaches to offload than today‟s architectures permit. In theory, any offload element ought to have some form of DPI capabilities as well, and be able to use policy management to determine what to offload, how to manage the flows to and from the core network, and communicate with other policy elements elsewhere. While this sounds sensible, it is likely to become much more complex with local offload via femtocells or WiFi, together with scenarios such as shared and managed offload involving 3rd-party operators, or multi-radio devices. The net result is that operators will ultimately have to blend network-side DPI and offload capabilities with greater control and visibility at the device level – for example, through better connection-management software. They may also need to interoperate with other players‟ offload solutions to develop more holistic and shared approaches. As a starting point, a much better understanding is required of how users are actually using offload today, what costs are saved, what improvements gained – and what unintended secondary problems and issues might be generated. Overall, Disruptive Analysis believes that DPI functions have an important role to play in managing offload for the mutual benefit of all parties, especially as the more sophisticated scenarios start to become real. In terms of where in the network it will



be best to put DPI functions, Disruptive Analysis believes that this will need to move closer to the edge, perhaps in some sort of gateway box which performs security tasks and other management functions. However, this will be largely dependent on the type(s) of offload being exploited – and how much of the work could also be done elsewhere – for example in a handset-resident client.

About Disruptive Analysis

Disruptive Analysis is a technology-focused advisory firm focused on the mobile and wireless industry. Founded by experienced analyst Dean Bubley, it provides critical commentary and consulting support to telecoms / IT vendors, operators, regulators, users, investors and intermediaries. Disruptive Analysis focuses on communications and information technology industry trends, particularly in areas with complex value chains, rapid technical / market evolution, or multi-sided business relationships. Currently, the company is focusing on mobile broadband, network policy-management, operator business models and services, voice and personal communications applications including VoIP and IMS, smartphones, Internet/operator/vendor ecosystems and the role of governments and regulation in next-generation networks. The company produces research reports and white papers, conducts consulting projects on technology strategy and business models, and provides speakers and moderators for workshops and conferences.

For more detail on Disruptive Analysis publications, workshops and consulting / advisory services, please contact [email protected]

Disruptive Analysis‟ motto is “Don’t Assume”. Website: www.disruptive-analysis.com Blog: disruptivewireless.blogspot.com Twitter: @disruptivedean

Intellectual Property Rights / Disclaimer All Rights Reserved. No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form by any means, electronic, mechanical, photocopying, recording or otherwise, without the prior permission of the publisher, Disruptive Analysis Ltd. Every reasonable effort has been made to verify research undertaken during the work on this document. Findings, conclusions and recommendations are based on information gathered in good faith from both primary and secondary sources, whose accuracy it is not always possible to guarantee. Disruptive Analysis Ltd. disclaims all warranties as to the accuracy, completeness or adequacy of such information. As such no liability whatever can be accepted for actions taken based on any information that may subsequently prove to be incorrect. The opinions expressed here are subject to change without notice.

http://www.disruptive-analysis.com/

Context-specific managed offload for mobile data...

Documents

Transcript of Context-specific managed offload for mobile data...