Monday, June 27, 2011

BBTM part 2: Comverse & Continuous Computing


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.

No comments: