Posts Tagged ‘streaming video’

Mobile Data Plans that Work

Monday, June 7th, 2010 by Cam Cullen

Mobile data plans have been in the news quite a bit lately, with Verizon (LTE plans) and AT&T (iPad and iPhone plans) updating the market on their mobile data positions. Verizon has all but announced that there will be no unlimited data plans on their LTE network, which is now scheduled to go live in 30-40 cities in Q4 2010, and people will pay based on their usage. AT&T announced that they are doing away with the unlimited iPad plan (already) and will now support tethering for the iPhone (but only for a 2GB/month plan). Other mobile operators also would rather have data plans based on usage rather than unlimited plans, but it remains to be seen how long or if operators with rich data devices can hold out, or if the pain of congestion will hit their network as it has for AT&T.

But is the ideal answer for mobile data to always bill based on usage? Although I understand the issues that are driving the operators to implement usage based plans (cost control, congestion management, etc.), I think that there are hybrid plans that could significantly accelerate the adoption of mobile data usage (and fixed mobile substitution for some users). Mobile operators could serve their customers better by offering flexible plans that were targeted towards different “consumer” types on their mobile network that were sensitive to application usage and time of day. These plans would be ideal for the new generation of rich media devices (Android phones/tablets, iPhone, iPad, and laptops) and accelerate their adoption by the consumer groups that covet the devices but are still afraid of bill shock (which will be even higher now that overage charges are going to be pervasive). It has been proven that devices can sell data plans, but the plans can also stunt the usage of the devices if using them becomes too complicated and expensive.

What would these plans look like? Most plans would be similar to the existing plans, with usage meters for the majority of data and separate usage meters for the applications that are attractive to specific consumers, with streaming video, audio, and file sharing leading the pack. Although web pages can be a lot of data (I once read an analysis that said the BBC front page was 1MB of data, which could cost you a pretty penny when you are roaming!), the real problem for mobile operators are long-lived streaming or downloading applications that can cause persistent congestion in a cell or on the network. Some examples of targeted plans:

  • Streaming Video: Monday through Friday 8 a.m. to 6 p.m., 25GB of data, unlimited nights and weekends
  • Streaming Audio: Monday through Friday 8 a.m. to 6 p.m., 10GB of data, unlimited nights and weekends
  • Unlimited Web: Unlimited web browsing and email, 2GB streaming media and other applications
  • Social Media: Unlimited Facebook/MySpace/IM/email, 2GB other applications

These plans could either be an add-on to an existing data plan, or part of different bundles for users. A very attractive iPad plan would offer unlimited web browsing, but a usage meter on other applications. I don’t see these plans as being negative towards Network Neutrality, since they will be selected by the users – as an alternative to the pure usage-based plan that the mobile operator would also offer. Time-based plans are already popular among mobile operators for voice, and could easily be popular among students and business travelers (i.e. Nights and Weekends plans).

My concern is that placing restrictive limits on bandwidth usage will stifle or limit the potential of the nascent market for rich data devices, or limit their use to Wi-Fi networks, which completely misses the goal of upgrades to LTE and other high speed mobile data networks – which is to make access ubiquitous for users (and not ubiquitous just for email). The challenge of implementing these plans is on the systems that would be used to meter the different applications (i.e. DPI systems) to ensure that the application classification is accurate.

An innovative mobile operator that offered these plans as an alternative to a more restrictive plan could tip the scales in their favor when competing for the “high value” users for mobile data. In the highly competitive mobile market, operators that think outside the box and find ways to best leverage the technology that they are already deploying in their networks will emerge victorious and profitable. Flexibility will be a key success factor.

As a user – would you be more likely to purchase a plan that gave you flexibility in how you used your mobile broadband?  I know that I would.

iPad – Telecom Armageddon or Savior?

Monday, April 19th, 2010 by Cam Cullen

I was having a discussion with a service provider (wireline broadband, interestingly enough) and he asked me if I thought that the iPad would have a significant impact on his network. My initial reaction was no, but as we talked through the issue, my opinion shifted.

When asked that question, my first thought was that the iPad would not affect a wireline broadband network that much, right? It is only a small number of devices (relatively speaking), and it is not like it can be used for file sharing. Sure, it can stream video, but how often are you going to sit and watch video on an iPad?

Then I started thinking about the real impact of the iPhone. Although the iPhone is a great device, and has certainly caused ATT issues in the US, and other operators abroad, as users take advantage of the media capabilities of the phone, it had a much broader effect on the industry as a whole (that incidently led directly to the iPad). Before the iPhone, phone-based data usage was mainly email (ala RIM and Blackberry devices) and light web browsing. The long lasting effect of the Blackberry was that people became used to being connected, and with the scarcity of Wi-Fi hotspots, people began to want always on mobile broadband, and business users began to purchase the data plans from mobile operators. Once the iPhone was released, it kick started the smartphone market like never before, and brought more users to the mobile broadband buffet. Every vendor wanted an “iPhone-killer”, and Android, Palm, Microsoft, and other operating systems began to proliferate on handsets at reasonable prices. These devices gave users a taste of what high quality media and browsing experiences could be had with mobile platforms, and even a taste of some really useful applications (phone-based GPS and mapping applications) that took advantage of the mobile data connections – including some streaming media and VOIP applications. The advent of flat rate mobile data plans (at least in name) for reasonable prices has spurred the demand for mobile broadband, and with so many devices able to connect to the mobile broadband network, has driven operators to invest heavily in the infrastructure to meet the increasing demand.

So the impact (I think) of the iPad will be similar. The “iPad-killer” race is on, with HP, Dell, Google, and many others racing to release devices based on Android or Windows that will compete with the iPad. There have already been application releases for Kindle and Netflix on the iPad, and more streaming applications will follow on these alternative platforms. I am not sure I want to watch all my TV on an iPad-like device, but it is easier than watching on a laptop or an iPhone. Add a camera and a USB port (hint, hint) to a device like this with a 10 hour battery life, and the potential for a truly portable media device is not a future – it is the present.

This is the future I see coming out of the iPad – one that has the potential to dramatically increase the usage (especially streaming media) on both wireline and wireless broadband networks. People will use their wireless at home and mobile broadband while traveling. If you are a heavy media consumer, traveling with an iPad and a laptop makes sense – I can read or watch movies on the plane with the iPad, do email on the laptop, and even multitask in hotel rooms – watching media on the iPad while working on the laptop.

So if you are a provider that is ready for this – and can deliver a high Quality of Experience to your users (and monitor it to make sure that you are delivering a high QoE) – you have a bright future ahead of you.

Me – I can finally have a data pad like I always saw on Star Trek.

Does LTE ♥ DPI?

Monday, February 8th, 2010 by Cam Cullen

There is a lot of talk in the industry about DPI and mobile operators. There was an article on Light Reading in 2008 titled “DPI (hearts) LTE” that explored this topic. The general belief is that mobile operators MUST have DPI in their network to survive and compete, due to a number of bandwidth and usage challenges. Operators are bracing for users that will treat their mobile connection in the same way that they use their fixed broadband networks today (i.e. streaming video, file downloads, peer-to-peer, etc). Since laptops are expected to be one of the earliest LTE devices supported in many of the early LTE deployments, the data requirements of LTE must be addressed from the initial deployment.

The debate has been stoked by the inclusion of a loose requirement in the SAE-GW for Deep Packet Inspection, aimed at application classification and QoS at Layer 7 (not traditional router-style Layer 4 filters). Many traditional GGSN/PDSN gateway vendors have begun to message that DPI is a part of their LTE solutions, and the expectations of mobile operators are rising daily. RFPs are coming at a rapid pace from mobile operators, and every one includes a request for information on how DPI can be deployed in an LTE network.

At Procera, our experiences working with mobile operators have convinced us that DPI will be a key technology for LTE deployments. Mobile operators need network intelligence on what is happening on their network, and the ability of DPI to reach back into the access network and correlate individual subscribers to their location in the Radio Access Network and manage congestion is a vital requirement to ensure a good Quality of Experience for operators. Tight integration with the BSS and OSS backoffice systems ensures that the DPI systems provide a single point of contact for network visualization that includes subscriber, device, location, service plan, and application knowledge. This information can also be used for billing, allowing service providers to create flexible billing packages based on location, time of day, on-net or off-net application, roaming, or usage volume.

That is all well and good, but how does it relate to LTE? These requirements are also valid for 3G deployments, and are even deployed on some 2G networks today. The challenge for LTE and DPI pushes the boundaries of the DPI that is deployed on networks today because the scalability, performance, and service expectations will exponentially increase with LTE deployments over 3G. 10G links are a minimum performance requirement, and the bandwidth and session count per user will skyrocket as mobile devices become more capable of multi-tasking and cloud-based applications take hold. It will not be acceptable to do “a little” DPI, as all traffic will be required to receive DPI treatment. LTE networks will be service and application oriented, as operators will push new applications as a way to justify the higher rates for LTE services, and DPI will be required to recognize and prioritize real-time services.

Many providers of Mobile Gateway solutions will also claim this functionality, and try to convince operators that their integrated DPI solution is “good enough” to provide equivalent functionality for a LTE deployment. But there are some issues with integrated solutions that should cause operators to pause before deploying an integrated solution. The first is that an integrated solution ties you to a single vendor for your deployment, and ties your upgrade in capabilities to what your integrated solution can be upgraded to. Standalone solutions provide more flexibility, and give you more leverage as best-in-breed solutions increase in performance and capabilities. Integrated solutions also tend to suffer from performance and scalability decreases when additional functions are activated in the systems, of which DPI has traditionally been one of the most processor intensive applications on a CPU module. The “single chassis” argument that is commonly made by integrated vendors is also often an invalid one, as the performance and scalability requirements of a full DPI deployment often exceed the capabilities of an integrated chassis. Although LTE deployments will start small, requiring additional chassis systems just to activate DPI functionality will negate any advantage of an integrated solution.

The story of LTE and DPI is just starting to be written, but we are sure that the two will be tightly intertwined together going forward.

Do’s and Don’ts in Bandwidth Control

Wednesday, December 2nd, 2009 by Jon Linden

Suddenly it all happens at once. We went from zero to two events focused on DPI in one week – Light Reading’s virtual tradeshow Policy Control & Deep Packet Inspection, and Informa’s Broadband Traffic Management event IRL in London early last week. These events are good validation that DPI has grown up to get proper attention.

I was on-site at the event in London – and I apologies for the hotel lobby background noise on my line in the LR panel discussion. But I also had the pleasure to be on a panel in London together with Benny Lim from SingTel and David Hodgers from O2 Ireland, moderated by Mark Newman from Informa. The topic was “Lessons Learnt: The Do’s and Don’ts of Bandwidth Control”.

So what are the lessons learnt on bandwidth control? Let me quickly go through my conclusions and what I told the audience. When looking at do’s and don’ts I see two categories: what works and what ‘s ethical. The latter is more challenging with today’s fast moving social media where bad news travels fast and subscribers vote with their feet.

How do you manage this? Well, don’t expect to “get away with it”. Internet users are savvy and operators in London confirmed that non-transparency came back to bite them. You must be able to defend what you’re doing, and a good test is if you’d accept it yourself. Greed is not an acceptable reason, though a viable business case normally is.

Do’s and don’ts also depend on what you’re trying to achieve. DPI and bandwidth control spans over a broad range of applications, from network protection and congestion control to quality assurance and service differentiation. We tend to be very introvert and technology-driven in this industry, but you must start from business benefits and objectives in order to define intentions and make it understandable to your end-users.

The key to what works is knowing what’s going on. It’s not an option to guess what your customers do and how your network is doing. And conditions change – all the time. What used to be 80% filesharing a year and a half ago is today replaced with 40% streaming video as the largest bandwidth consumer. A policy rule-set that is not up-to-date will cause some strange consequences.

I wish I could provide a blueprint for what works, but every situation is unique. Your product mix, fixed and/or mobile, target groups, price positioning, and on top of this there are geographical differences like what applications are used and what bandwidth control practices are accepted.

This means that the number one thing to do is try. You will have to try it out and assess the outcome in your specific situation and your environment. I know this sound scary, but be adaptive, be quick, and make sure you make qualified decisions based on facts rather than guesstimates and assumptions.

Let me also summarize my don’ts: Don’t lie – be transparent. Don’t insert packets – honor integrity. Don’t get introverted and super techie – understand your business and your customers. And don’t do nothing – this is the most expensive decision of them all…

Let me wrap up with one more suggestion for what you should do: Keep it simple! Complexity kills this cat. If it’s too complicated you won’t be able to communicate to your subscribers, it’ll be impossible to update and change, and you won’t be able to measure if you successfully achieved what you intended to. This is hard to make simple – which is why we, Procera, are here to help ;-)