Showing posts with label Continuous Computing. Show all posts
Showing posts with label Continuous Computing. Show all posts

Monday, June 27, 2011

BBTM part 2: Comverse & Continuous Computing

Comverse


Comverse is proposing a full spectrum holistic solution to video optimization, including PCEF, DPI, Optimization, Charging and some aspects of  PCRF.
What caught my attention is their strong push for Gi based optimization vs. Gn. 

They advocate that  measure of congestion at RAN level is inconsistent and inconclusive.
The big push is certainly as well an attempt to ward off the network vendors (ALU, NSN, Ericsson, Huawei, ZTE), by arguing that there is an inherent conflict of interest when these vendors are both trying to sell carriers capacity and optimization at the same time. (My experience of working with all these companies is that 80% of the time, the right hand does not know what the left hand does and that for conflict of interest to exist, it would require a lot better organization and strategy than what I have observed).



Comverse proposes that for effective cell-based congestion detection, a mechanism such as a radius interim messages,  triggered at cell level, not Rnc, would provide an effective way to relay RAN congestion indications to the core.


I agree with the premises but I am not sure of the conclusion. A lot of the congestion at RAN level is also signalling and you could end up in interesting snowball effects with Radius messages (notably inefficient, that is one of the primary reasons for Diameter's invention) could greatly contribute to the congestion they are trying to stave off. 


Now, Diameter repeaters at RAN level... that could help.

Continuous computing
I was curious to hear from CC after their recent acquisition by Radisys in May. They present themselves as an "arm dealer" in the optimization and traffic offload war between vendors and offer some interesting perspectives.




Offload is a cost effective way to manage surges and traffic increases but presents significant challenges in CALEA (Legal interception from Law Enforcement Agencies) and charging and policy. 
Effectively, when traffic is offloaded at RAN level, you need paths to trombone it back to the core network for charging, PCRF and optimization functions if you want to get most of your investment, while satisfying both legal regulations and customer SLA.


The rest of the presentation focused of course on Continuous Computing's solution that collocates DPI, traffic offload (on Lu interface, between Rnc and SGSN) and interacts "seamlessly" with their  video optimization, tromboning traffic back to the core before going to the internet through Gi.


I don't think that the "just another bump in the wire" theory actually works for video, where every millisecond of latency counts against the user experience.






Friday, June 24, 2011

BBTM: The value circle and content based charging

Broadband traffic management North America took place in Boston, on June 21, 22.
Here are my notes from the event and highlights from the conference.




This is the first year that Informa holds this event in North America. After the great success of the UK edition last November, they decided to create regional offspring of the show in Middle East, North America and Asia, with the global edition still planned in the UK this November.


The show, like in the UK, featured most of the subjects that are relevant in Mobile Broadband:


  • Data offload,
  • Policy management and charging,
  • Video optimization,
  • Femtocells,
  • Traffic optimization...


The attendance and presentations were mostly vendors, with only a few carriers represented (AT&T, Verizon, Cricket, Telecom Italy). No doubt the ratio will change in the future as the show takes on a more visible role in North America.


Here are a few of the highlights from my perspective:


Jeff Eisenach - Navigant Economics
Jeff is a veteran of the US regulatory forums. He had an interesting presentation about the change from value chain to value circle in wireless. Forcing carriers to reconsider old notions such as "owning the customer".



















I quite like the concept. Now customers actually have relationships with content owners, aggregators, phone manufacturers and carriers... No one owns the customer, they are shared and in my mind it will force more concessions from carriers in the future beyond the revenue shares that we have seen between the likes of AT&T and Apple for iPhone.


My panel:
How Can Carriers Move Away From Unlimited Data Plans While Keeping Customers Happy?
with:

  • Mike Coward, Co-Founder & CTO, Continuous Computing
  • Fred Kemmerer, CTO, Genband
  • Chris Hoover, VP Product Marketing and Management, Openet
There are still a lot of talks about content-based charging from PCRF vendors. It seems to be the projected cure for all that ails mobile networks. Too much OTT in your network? Content-based charging is the solution. Too much P2P traffic? Content-based charging is the solution....


 When I asked how you reconcile content, transport and application offering the following example, it was clear that there is still a lot of work to do by charging and policy vendors to enable true content-based charging.


On my iPhone, I can watch video from the browser or from an app. Some apps, before serving you content ask your permission to push notifications or to use your location. If an app invokes a content and invokes gps or other network based service, how does the network operator is to understand that this video is YouTube, from the app, not the browser, invoking gps for location targeting and charging for the overall service?
Today, inevitably, the user gets charged for data transport of the video and the GPS call. Even if an operator offers all-you-can-eat YouTube, you still get charged for the GPS call, right? Because the network is not intelligent enough to make the contextual difference between me using my map app and invoking GPS or a third party app invoking GPS.

As more and more discussions about content based charging ensued, I offer that an operator attempting to derive revenue from OTT service will inevitably need to get closer to content and app providers.

Content providers will demand revenue share on revenues generated from their services. Otherwise, you will see content providers encrypting the traffic in an attempt to keep control of the user experience and to deny the operator the capability to throttle or mangle the content delivery.


Next generation DPI, traffic management, pcrf and proxies are necessary.
I believe that operators will have to extend quality of service (QOS) and quality of experience (QOE) control to the content provider, beyond the operators' walled garden, if they want an efficient revenue share or load share model.