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

Wednesday, October 28, 2026

VMO2 Finds AI-RAN Does Not Need GPUs


Virgin Media O2 has trialled AI-based channel quality estimation on a Nokia RAN at a busy site in Paddington, central London. Light Reading reported on 2 November, after withdrawing its earlier story, that the site ran on Nokia's existing Marvell custom silicon and not on an Nvidia GPU. Rob Joyce, VMO2's director of mobile access engineering, said the AI raised spectral efficiency by 20%. He also said a GPU is not required to do this and described Ericsson's silicon as very good. Ericsson CEO Per Narvinger has said about 60,000 base stations operated by its customers already run an AI successor to link adaptation on existing ASICs, with a gain of around 10%.

VMO2 has no GPU RAN in the £700 million tranche of network spending announced earlier this year, and Joyce favours a distributed RAN. Centralising GPU baseband would require CPRI or eCPRI links of 25 Gbit/s each, about 3 of them or 75 Gbit/s, to a site that has 10 Gbit/s of fibre today. In his words, a distributed deployment means putting additional baseband GPU resources at each site, which is the cost that has to be weighed against the gain.

The 20% and the 10% cannot be compared. They come from different vendors, different algorithms and different scales: 1 trial site against a deployed base of 60,000. Light Reading's report gives no baseline, test duration or site count for the 20%. I made the case in Ericsson and Nokia at odds on AI-RAN silicon that the decision to use AI in the RAN is separate from the decision to buy GPUs, and VMO2's engineering lead now says the same. That keeps the position from Is AI-RAN the future of telco? intact: the commercial case for GPU RAN depends on benefits beyond radio algorithms that ASICs can also run, and no operator has published a baseline or a cost per site to show it. For Nokia customers the choice is narrower than the technology case suggests, because Nokia's last custom silicon product is the one VMO2 trialled and its roadmap runs through GPUs.

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.