Mobile Network Congestion Management

Transcription

1 SOLUTIONS BRIEF SOLUTIONS CASE STUDY BRIEF Mobile Network Congestion Management INTRODUCTION This document summarises the Procera strategy towards congestion management methods for mobile networks. The document assumes high level understanding of the PacketLogic Platform and policy enforcement solutions in general. We will cover the congestion management problem in three different sections. In order of processing, these sections are correlation of control plane data to user plane data, detection of congestion and enforcement of policy to alleviate it. Data Sources PacketLogic Platform can receive control plane data from various sources and correlate this with user plane traffic. For congestion identification and management in a mobile network, we need to look at what location information we can receive in a network. This is useful for understanding areas of congestion and application of congestion management policies. RADIUS The most common deployment option for PacketLogic in UMTS uses RADIUS Accounting Request packets to identify parameters such as MSISDN, session IP, device model, cell ID, radio access technology, network MCC/MNC, SGSN information, etc. In this setup, PacketLogic Subscriber Manager (PSM) node receives the relevant RADIUS packets either as an accounting node where it can send an accounting response to acknowledge receiving the packets or it can receive a copy of these packets to process them. When the PDP Context is alive, the Start packet is received. This creates the MSISDN to IP mapping that we use in our policy. It also gives us the starting location of the data session which is the cell ID. In most mobile deployment scenarios, there will be no further updates on this data since operators do not enable frequent Interim Updates due to signalling load or licensing restrictions in the core network. This means we will only receive cell ID updates when the user does a handover from one RAT to another. Even when Interim Updates are available, we will not receive cell changes within the same NodeB/eNodeB. Please note that this is not a limitation on PacketLogic, but rather in most core networks. SNOOPING GTP-C GTP-C is the control traffic on the Gn interface for UMTS. For LTE, GTP-C can be snooped from S11 or S5/S8. Location and various other information can be gleaned from this interface so that there is no dependency on RADIUS. It is also possible to use this information together with RADIUS. The advantage of doing this is that we get handovers between enodebs, so we can get location accuracy down to the enodeb without requiring any interim AAA updates. GTP-C snooping is probably the most accurate location awareness we can get on a scale from the EPC. 1 PROCERANETWORKS.COM

2 OTHER SOURCES PacketLogic Subscriber Manager is a flexible product for receiving OSS/BSS data using a number of APIs such as JSON RPC, JSON Bulk, SOAP, Diameter (e.g. Gx), etc. Using these interfaces, it is possible to receive information from a number of core network elements as well as probes or other elements in the RAN. We work with the operator in finding the optimal method to receive the information we need, in the granularity that is required. Congestion Detection PacketLogic can use a number of available KPIs in detecting congestion for a group of connections. The important ones will be described in this section. KEY PERFORMANCE INDICATORS It is important to note that the KPI metrics below can be very useful in detecting congestion in a congestion domain. However, this is very much dependent on what the congestion domain is, what the granularity of the metric is and how these metrics are used in combination with each other. Please request from your Procera contact the PacketLogic Product Guide for more in-depth description of these metrics and how they are calculated. Throughput PacketLogic measures throughput for each connection for both upstream and downstream traffic. We use a granularity of 250ms for this metric since it is important to know the actual usage of traffic during a short interval and take into account bursts in traffic, especially for popular services like Youtube. Figure 31 THROUGHPUT GRANULARITY In the figure above, a data session which lasts slightly more than 3 seconds is shown. When looking at the data usage in 5-minute granularity (in purple), the peak for throughput shows 6 kbps. When the granularity is improved to 1 second (in green), the peak shows 1.5 Mpbs. When PacketLogic granularity of 250ms is used (in blue), the peak shows as 2.5 Mbps. Identifying these peaks and burstiness of throughput plays a key role in understanding congestion. 2

3 RTT External and Internal RTT is measured for each connection. External RTT refers to the round trip time from the PacketLogic Realtime Enforcement (PRE) to the server on the internet side. Internal RTT refers to the RTT from the PRE to the UE side and measures the latency in the operator network. These values can be measured for both TCP and UDP, using differing methods. We measure this data every 5 seconds by default. Packet Loss Packet loss is another good KPI for identifying problems in the network such as congestion. We measure packet loss for internal and external side of the PRE and can account for both upstream and downstream traffic. We measure this data every 5 seconds by default. Subscriber Count Subscriber count in a congestion domain is also a very important parameter in understanding congestion and is used by PacketLogic. CHOICE OF CONGESTION DOMAIN Once we have the metrics from data plane traffic, these are accounted for specific subscribers /sessions. Each session has a cell ID from the control plane data, often the starting cell of the user session. At this point, it is possible to track the congestion metrics at any aggregation level for PacketLogic. We could, for example, do this at cell ID level. This would give us an idea of total throughput, average RTT, packet loss and number of subscribers which can be used to detect whether the cell is congested. However, we need to keep in mind that some of the data accounted on a specific cell may no longer be relevant to that cell since the subscriber started the data session there and moved elsewhere in the network without a location update to the core network (please see section Data Sources on possible causes of this behaviour). Likewise, we could see data which should have been accounted on this specific cell actually being accounted on another cell due to the subscriber having started in that other cell. This makes cell based congestion detection non-optimal in most mobile network deployments unless integration with RAN elements is done. One of the ways of dealing with this that we recommend to operators is to use a NodeB/ enodeb domain for congestion detection. An enodeb covers a small area with proximate cells and it is very likely that the level of congestion in a enodeb is fairly consistent during peak usage periods. This means we eliminate the issue of not receiving intra-enodeb cell changes and identify/address congestion in a much more predictable way. OTHER METHODS OF CONGESTION DETECTION PacketLogic Platform is flexible in getting congestion data and does not force the operator to use PacketLogic congestion detection methods. It is possible to feed congestion data through the use of available APIs for PSM as described in the section Data Sources. A good example of this is deployed in one of our existing mobile customer networks. PSM periodically fetches congestion trending data for the cells in this network. We would get a colour coded congestion level for each cell, green, amber or red. We use this data in times of congestion to apply congestion management policies on the affected cells. The integration and testing effort required for this kind of deployment is minimal. 3

4 There is also the option of choosing a congestion management policy which does not depend on congestion detection from core network data. This will be covered in the Policy Enforcement section. BANDWIDTH DETECTION FOR MOBILE CELLS This is a concept where the policy platform tries to identify the available bandwidth in a mobile cell rather than simply identifying whether the cell is congested or not. Then, shaping is used to address the congestion based on this available bandwidth. After extensive testing of this approach, we came to the conclusion that the bandwidth information calculated using this method is inaccurate and does not help with congestion management. We would like to share our findings here and recommend better ways of managing congestion. In competitor platforms where this method is used, the detection is typically dependent on RTT information. This metric by itself could point to congestion in the cell as well as backhaul or other problems in the data path. Considering the possible inaccuracy of cell ID data for a subscriber which is mobile, the calculated bandwidth s accuracy is further deteriorated. Using the average RTT for bandwidth calculation also poses a problem in the live network since some users having bad coverage can easily skew the numbers badly. There is typically no feedback loop that tells the system to reduce shaping if the congestion does not reduce. Backoff is also a problem since it can cause inconsistent behaviour for the policy being applied. In order to prevent this, the policy is typically applied with a very poor granularity like 15 minutes which means that the sub-second fluctuations in a mobile cell will not be accounted for properly. This will mean excessive shaping in some cases or using a very high shaping threshold in others for extended periods of time. All in all, this is a concept which can possibly work fine in the lab, but will provide a very poor user experience in a live network. It will require the operator to accept sacrificing a big amount of the total burst bandwidth. This will mean making the service equally bad for all subscribers by taking the better performing subscribers down to a shaping level equal to the worst performing subscribers without allowing the worst performing subscribers any benefits since they are likely in this situation because of radio conditions and not congestion. Feedback from our research engineers on this concept was the following: Depending on radio conditions and the capabilities of the UE, the radio transmission time for a 1520 byte frame over the high speed downlink radio interface in 3G can be between 1ms and 300ms without any congestion on the cell level. Results of our research show that this method of bandwidth calculation is very ineffective in mobile networks. 4

5 Policy Enforcement Although detection of congestion is useful information to operators, in most cases operators would also want to act on this information. There are different policies that can be applied here with differing levels of complexity, dependency on detection of congestion or dependency on accurate location data. APPLICATION AWARE RAN This is an approach where congestion detection using core network data is not needed. Instead, we rely on the RAN scheduling to prioritise certain traffic based on operator s preference. For this purpose, PacketLogic marks traffic using DiffServe Code Point (DSCP) rewrite functionality. The traffic can be classified based on application type, subscriber tier or any other parameter which may be relevant in prioritising certain traffic over other packets in the RAN. The advantage of this method is that the configuration on PacketLogic is extremely simple and no integration is required on the control plane for this policy to be applied. The traffic is prioritised at every hop in the network where DSCP is used and most RAN vendors now support this functionality. It is also applied globally rather than per congestion domain. Because of the simplicity and effectiveness of this method, Procera strongly recommends that customers consider implementing this functionality. We would also recommend asking for Procera s research document which provides test results on the impact of latency and traffic prioritisation on web browsing traffic. SERVICE SPECIFIC SHAPING Service specific policies can be applied globally, per enodeb or per cell as required. Please see Choice of Congestion Domain section for our recommendations in selection of congestion domain. Video Shaping Nowadays, a large majority of traffic volume is caused by the OTT video services in a network. Looking at a typical European mobile network, at least 50% of the subscriber traffic is typically Streaming Media traffic of which 70% is YouTube traffic followed by other similar OTT services and Netflix. Mobile operators typically do not want to penalise these users, but need to find a way to reduce this traffic to allow them to defer CAPEX investment and provide a decent browsing experience for other subscribers during peak usage periods. One way to achieve this is to shape video traffic in a way that will force the OTT service to select a lower resolution than what it would have tried to offer without shaping. In our live network testing of this functionality, we saw that even smaller mobile devices are typically offered a 720p or 1080p resolution on a typical YouTube video. By shaping the video to specific resolutions, the following results were achieved: 480p resolution: ~50-60% volume reduction 360p resolution: ~70% volume reduction 240p resolution: ~80% volume reduction Based on the feedback from the test users, both 360p and 480p provided very good video experience without any stalls or noticeable difference in quality of picture. 240p also provided a smooth and positive experience, but the picture quality reduction was noticeable. 5

6 The video shaping can be configured to be aware of certain parameters like device type, screen size, subscriber tier, location, etc. It can also be configured to work during peak usage periods. It does not require a calculation of available bandwidth in a congestion domain since the shaping is typically done based on connections or subscribers depending on OTT service and required behaviour. For more information on our Video Shaping, please request the Video Traffic Management document from your Procera contact. Background Traffic Shaping For congested domains, background traffic such as ios downloads, App Store, Play Store, Windows Update, itunes and other heavy file downloads can be heavily shaped. This policy can also include backup services such as Dropbox, Google Drive, Google Photos and icloud to free up bandwidth for real time sensitive protocols. These policies can optionally be time of day based allowing them to run at full speed during night time when there is less impact of congestion since some subscribers may be physically located in the same area 24/7 (such as mobile broadband dongle users) and the operator will want these subscribers to be able to download their data. Other subscribers who are more mobile will get their heavy downloads completed when they move away from the congested area. HEAVY USER POLICIES This type of policy has the aim of identifying heavy users and penalising them in some way. PacketLogic can do this kind of policy in a very flexible way based on operator s preferences. For example, it is possible to keep track of usage in fixed or sliding window type periods, set thresholds on total or specific service or service group volumes and set policies using available actions like specific service (described above in Service Specific Shaping section) or subscriber shaping or filtering. It is also possible to have several tiers of usage where different policies are applied (e.g. shape P2P at first threshold, shape all services at second threshold, block certain services at third threshold, walled garden at final threshold). This policy can be applied globally, per enodeb or per cell as required. Please see Choice of Congestion Domain section for our recommendations in selection of congestion domain. 6

7 Conclusion There is a significant difference between identifying congestion in a fixed and mobile network. Mobile network congestion fluctuates very rapidly and it is therefore important to look at the trend in multiple KPIs such as number of subscribers, throughput, latency and packet loss to identify congestion correctly. Due to this rapid fluctuation, shaping congestion domain at a total bandwidth is not an effective method of congestion management and causes very poor subscriber experience. We recommend detecting congestion at nodeb/enodeb level and enforcing a policy from the list in section Policy Enforcement. Application Aware RAN policies are very effective where they are supported by the network vendor. Service specific policies are recommended where Application Aware RAN policies cannot be used. Procera provides the PacketLogic Platform which allows all these policies to be deployed in a flexible way based on operator s requirements. Figure 2 TRAFFIC PERSPECTIVE IN MOBILE AND WIFI DEPLOYMENTS Service Provider Access Network Mobile Radio Access Network (RAN) Service Provider Core Network OSS/BSS/PCRF /OCS/OFCS Policy Interfaces Subscriber Perspectives Traffic Perspective Applications Wi-Fi Router Internet Fixed Wireless PacketLogic Client (Dynamic LiveView) PacketLogic Insights (Engineering, Customer Care Executive) Content v ABOUT PROCERA NETWORKS Procera Networks, the global Subscriber Experience company, is revolutionizing the way operators and vendors monitor, manage and monetize their network traffic. Elevate your business value and improve customer experience with Procera s sophisticated intelligence solutions. For more information, visit proceranetworks.com or follow Procera on Twitter CORPORATE OFFICES Procera Networks, Inc Fremont Blvd Fremont, CA P F CORPORATE OFFICES Procera Networks Birger Svenssons Väg 28D Varberg, Sweden P. +46 (0) F. +46 (0) ASIA/PACIFIC HEADQUARTERS Unit B-02-11, Gateway Corporate Suite, Gateway Kiaramas No. 1, Jalan Desa Kiara, Mont Kiara Kuala Lumpur, Malaysia Copyright Procera Networks. All rights All rights reserved. reserved. All other All other trademarks trademarks are property are property of their of respective their respective 7owners. owners. PROCERANETWORKS.COM