Tuesday, February 14, 2012

[Vendor Interview]: Broadband Systems' Cell-Aware Congestion Management Solution

Broadband Systems announced recently a new Ran Congestion Management solution, based on its SLG (Service Logic Gateway) technology - "a combination of a smart routing device and a carrier grade web proxy – both supporting a totally new level of subscriber and session logic".
The ".. RAN congestion management technology automatically detects the congested cells and manages them through selective shaping and/or user notification. Based on subscriber type, mobile data bandwidth may be decreased and mobile data access may get limited to a certain segment for the users in a congested cell. The users who are not in a congested cell are not affected at all by the measures taken upon the congested cells and the quality of their experience is not diminished .. The SLG proxy is capable of reducing the bandwidth requirements for video streams in congested cells by transforming the bitrates of video streams. Technically this is done by transforming the HTTP requests from relevant smart phones to the content provider (for example YouTube) so that the smart phone appears to ask for the same video stream – but in lower quality than HD".

Broadband Systems is a young start-up, founded in November 2010, and is based in Denmark. As detecting cell level congestion and identify the subscribers that are connected to it in real-time is a complex mission (see "Sandvine adds Mobility-aware Traffic Management Analytics and Enforcing, with Dynamic Control" - here), I asked Michael Andersen (pictured), the founder, to help me understand the solution.

Q: How do you detect per-cell congestion when placed on Gi interface?

A: We detect cell congestion at the IP traffic level using the established IP standards. Many smart phones support the ECN (explicit congestion notification) bit in the IP header and the solution quantifies these instances. In addition to this, the solution has knowledge of the PDP sessions from the mobile operator infrastructure and calculates the congestion rate of each cell with active sessions.

Q: What is the % of mobile devices, in real life network, that support ECN?

A: Our focus is very much to ensure that our solution is applicable to most networks. iOS devices support ECN and some Android devices appear to support it too. The import detail is that the solution gets enough information about cell congestion if just a percentage of the active devices in a cell support ECN.

Q: How do you get the knowledge of PDP session (to correlate IP flows to Cells)? Do you need RAN based probes? if not, is it applicable to most networks?

A: PDP session information is communicated from GGSN via RADIUS. The basic session correlation is very similar to what a real time data charging system does – except there is cell level logic instead of charging. In order to ease deployment and re-usability, we try to avoid direct communication with RAN level devices for congestion information.

Q: How do you reduce the bandwidth consumption of video traffic?

A: We do not transcode the video streams. Manipulating the headers to ask for lower quality video streams already does a significant difference. From the user perspective this is not very intrusive and from the mobile operator perspective it is more practical. For reference you can compare the bitrate of "Baseline" and "High" quality MP4 encoding used by YouTube.

Q: I understand that there are certain ways to it, depending on the video application/type (Adobe, Apple, MS). So do you support all?

A: Yes, in principle we support them all and can adopt to new ones. This is because our technology has a flexible decision point at this exact spot. The decision about if and how to change a streaming video request can be defined at the solution level by the mobile operator. However, in practice – most of our tests and experiments focus on Youtube traffic. This is because Youtube alone constitute more than 50% of all data traffic in many mobile operators.

Q: You say the solution considers the “subscriber type" – what does it mean?

A: Our solutions are deployed in the mobile operator data center. They have access to the subscriber databases (or INs) and can help the network make decisions that makes sense from a business perspective. Therefore the mobile operator can define logic that selects the order in which cell congestion is handled - for example subscribers with bundled mobile data can get reduced service before users with premium mobile data package.

Q: So, do you interface with PCRF systems? 

A: In a 3GPP based infrastructure our technology, the SLG, has the role of a PCEF that supports policies that go beyond megabit bandwidths and gigabytes quotas. We do have the protocol support and functionality to work with the broad range of PCRF vendors. …and we also have enough industry experience to know that these platforms tend to differ enough for each project to be different anyway ;-)

Q: Do you have live installations already/paying customers? 

A: This is new technology, it is not in production anywhere yet. However, we do have a business relationship with one of the largest mobile operators (headquartered in Europe) and solutions are being discussed with several of their affiliates. We expect live solutions around mid 2012.


  1. Orange clouds and pink ponies... Huge PR, no practice... Is this all that matters nowadays?

    There is no mobile network where every cell change is notified to the packet core, if there is such I would be interested to see their signaling load and how they cope with it... And even then... How is every cell change propagated to the GGSN? 3GPP? Anybody?

    I do not think so...

    1. I can only say that the post mentions a competitive solution, from Sandvine, that relates to your comment.

    2. It is possible to send ULI every update PDP ctcx, and from then to the RADIUS.
      Don't try at home....(signaling storm).

  2. Hehe, ULI in Update PDP Context yes :) But a cell change does NOT trigger Update PDP Context Request, right? And what about cell change in Standby/Idle? Going to Ready/Connected and triggering whatever to notify your current cell back to the GGSN? Nope, no way :) So far from real-life, just amazing...