Tackling RAN Congestion with Predictive Congestion Management
Tackling RAN Congestion with predictive congestion management
While data revenues power the growth of mobile operators’ businesses, RAN Congestion is on the rise as network spending can’t keep pace with the rate of increase in data traffic, threatening customer satisfaction and capital expenditure budgets.
Operators that best manage the impact of RAN Congestion, have an opportunity to differentiate their service, and optimize the allocation of network capacity. Combining predictive network analytics software and dynamic policy management provides operators with:
- Intelligence to predict the impact, by location and device, of data traffic spikes and demand anomalies
- Real-time targeted policy controls, to prioritize network resource decisions
- Granular visibility to efficiently manage network data capacity to balance service delivery and network performance goals
Register to attend this webinar to discover how to increase network efficiency, and meet subscribers’ quality of experience expectations.
Presenters:
Gary Rieschick, Director of Solutions, Openet
Russ Green, Senior VP Product Management & Customer Services VPIsystems Inc
Tags; Archive, Openet, RAN, telecoms.com
Is PCRF capable of accepting SNMP traps from Performance Management system (which would signal cell congestion when some predefined threshold is crossed) and on this basis apply some service logic which at the end generates certain policy to be enforced over PCEF?
Good question and yes SNMP traps could be send to the PCRF. It could also be sent to the Predictive Management system to compare what’s been predicted versus what’s happening in real-time to update any predictions.
-gjr
Good afternoon, would it be of help to collect data from probing system concerning congestion and users in a cell?
Fundamentally, the predictive concept is intended to avoid the need for costly probe installation. However, if probes already exist in the network, they could be used as an adjunct to the data collection.
The more data that can be provided to the RAN Congestion Manager the better the predictions. This includes information from probing systems. Openet is in discussions with a few operators that want to use both predictive and reactive congestion management approaches. This means the predictive piece will be in place as outlined in the webinar and the probes would be feeding the RAN Congestion Manager as well. If there is an anomaly that wasn’t predicted then the RAN Congestion Manager can make adjustments based on the new trend. It can also report and store this anomaly for weighing this event as part of a future prediction (e.g. it can be factored into the predictions algorithm).
Subscribers usage patten change. For example, on Champions league evenings, there could be congestion from users checking results or sending photos from stadium etc.. Or at the end of season when football is over, there may not be congestions at the times earlier programmed into the PCRF. This means the parameters for congestion and application of policy has to be changed often in the network (human intervention). How does this work considering efficiency of the system to address congestion when there is congestion? Not applying congestion control when there is none.
The primary function here that maybe didn’t come across clearly in the webinar is that the RAN Congestion Manager has an event editor to include planned events such as football games. This allows it to make event aware predictions in times of events and remove the weight of these events when they aren’t scheduled to avoid over managing non-congested areas.
How can we use the PCRF to relief CS cells from PS R99 Traffic which is causing PS congestion? our Network Setup is F1 R99, F2 PS HSDPA, F3 PS HSDPA
How will you define Busy Hour Fair Usage?
Traditionally busy hour is defined by operator network usage statistics, that tell them when their network has reached peak capacity. The predictive congestion management solution uses forecasts to automatically forecast by location where issues may arise, and apply policies to pre-empt congestion and deliver a better QoE.
Does the system actually predict the congestion before it happens, or does it sample the data of a network already in a congested state and then applies the correct policies to correct it.
It actually predicts the congestion but can make updated corrections based on recent network trending data. See my response to mhandy below for more details on a related question.
As the prediction is based on What, Where, How and When? It comes to me that different policies will be applied to Congestion caused by a Blackberry user than an N95 Nokia user. What are these policies applied?
The applied policies are based on a large number of variables. Note that the PCRF will make policy decisions based on things such as device type as you mentioned but also on things such as but not limited to: subscriber type (business, government or regular consumer), service plan (regular vs. premium), roaming vs non-roaming, application type (premium content versus regular Internet traffic), consumption level (over/under fair usage limit), location (congestion area versus non-congested area), etc. The key is that the operator determines how these variables are prioritized to determine how to apply policies in times and areas of congestion.
Still can’t find the benefit of “prediction” compared to “reaction” mechanisms especially in cases of unpredicted large traffic events.
Re: mhamdy@etisalat.ae
Still can’t find the benefit of “prediction” compared to “reaction” mechanisms especially in cases of unpredicted large traffic events.
Prediction is useful as it addresses the entire network continuously. Rapid data growth means that thresholds are creeping over congestion limits somewhere in the network and this keeps that in check. As you point out, there are still unpredictable events that have to be dealt with. There are two categories; (1) “known” events like a political rally, holiday event or similar. The system can be told about this – which can be used to modify the prediction and policy application (2) “instant” events like an accident or similar that causes immediate changes. This does require reaction which can be handled using the manual feedback mechanisms as in (1). Without a widespread deployment of monitoring probes throughout the network, you can’t completely cover the reactive events but this approach comes a long way towards this
There are several benefits of the predictive approach over the reactive approach. Note that a high percentage of congestion is reoccurring. This reoccurring congestion is identified by tracking, measuring and monitoring historical information. Historical information is good but by itself it isn’t as accurate as when used in combination with trending data which can be recent KPI data that has been reported in the last 30 minutes or potentially even less. Then the last area is calendar data which is based on planned events that can be used as part of the prediction algorithm used to predict congestion with a high level of accuracy. Anyhow, network planning and forecasting tools have been around for quite some time now and have gotten effective at reporting near term congestion with accuracy levels of up to 80% or higher. If the operators Policy Management system can proactively put in stricter policies in advance of the time and area of congestion then this allows for more intelligent policies. This creates a better customer experience and a more cost effective solution than using probes which only send triggers once congestion has occurred. Of course operators can lower the thresholds on the triggers to minimize this issue but this would also dramatically increase the signaling to the PCRF which may create a signaling storm in the call control layer. So what are the benefits? Most cost effective solution (less expensive than probes for 80% or more congestion issues), better experience for key subscribers and premium content due to proactive policies, etc.
In cases when the 20% of the time where a network anomaly has occurred which was not predicted there’s a key component to the solution that I may not have clearly communicated during the webinar. Note that the PCRF pulls down the predictions on a daily basis for expected congestion for the next 24 hours. The RAN Congestion Manager is still getting network trending data from KPIs that are reported in increments as low as every 15 to 30 minutes. If there is a new area of congestion that wasn’t predicted then it can be included in an updated prediction from the RCM to the PCRF. This is done by the PCRF which sends a message to the RCM every 15 minutes asking if there are any modifications to the predictions. With this capability the PCRF can still manage a large majority of the unpredicted large traffic events which are beginning to occur.
Good question by the way!
-gjr
How do expect the PCRF to assiciate a device with an eNodeB/RNC
The PCRF requires an association of request to the originating eNodeB or NodeB. In the case where there is a congestion issue determined at an RNC or other aggregation point, the congestion prediction can determine which NodeBs should be targeted. So in essence, the PCRF doesn’t need to know about the RNC, it gets this information at the NodeB level
Are there existing products that can perform the predictive aspect of this discussion? In particular, I’m wondering about the sort of “feedback loop” predictive model, where the system observes behaviours and patterns without congestion management, for say a weeks time, then can make a prediction for the following week. Once congestion management is implemented, the results would theoretically be improved, and the predictive engine needs to take into account these changes each week. I’m wondering how that works.
Yes – the Openet/VPIsystems solution implements this predictive model with feedback. The system does “learn” over time with resulting prediction improvements. This tuning process as you suggest is carried out over a few weeks during system implementation. Examples of tuning mechanisms are to determine the “gain” on reaction to predicted congestion.
how effective is prediction of congestion for a network which is changing, for example, rolling out LTE, or consolidating sites etc?
Is the Network Capacity Planning Node connected to the PCRF implemented as part of the Gx interface?
There is no network capacity node, as such. There is a passive system for collecting performance data. That is used to generate the congestion forecast, and those forecasts are fed into the PCRF. And those policy rules are typically implemented over Gx.
See response to mhandy below for the answer to the first part of your question. Congestion relief is measured by the RAN Congestion Manager which is constantly reconciling the success of the predictions versus the actual network performance. This is why the feedback loop is critical to allow the RCM to know where and how much throttling was done by the PCRF.
Good question!