Network Policy Control and the Migration to LTE

Transcription

1 Contents Executive Summary... 1 Market Drivers... 2 The Fall of Erlang and the Rise of IP... 3 LTE and Network Policy Control... 5 Key 3GPP Release 11 PCC Elements GPP PCC Theory of Operation LTE Challenges Meeting the Challenge of Today s Layer-7 Realities Duplicate functions for PCEF/TDF Network Policy Control Solutions for LTE Importance of Distributed Decision The Right Solution Conclusion Executive Summary As consumers adopt 3G data services, mobile bandwidth consumption is increasing at rates surpassing even fixed growth. At the same time, mobile operators are planning to move their 2G/3G networks to 4G as part of the Long Term Evolution (LTE) for mobile radio communications. This paper discusses LTE and how the 3GPP release 11 Policy and Charging Control (PCC) framework outlines the structure and resulting benefits of this future network architecture. However, before and even after the roll out of LTE, mobile operators must overcome the following key challenges: Congestion in the access network (e.g., during peak times). Bandwidth-intensive applications and malicious traffic conspiring to prevent many users from enjoying the network. A tiny percentage of subscribers consuming a disproportionate amount of bandwidth to the detriment of everyone else s quality of experience (QoE). The need to maximize revenue and profits in pre- and post- LTE networks by offering consumers a choice of services and consumption packages that can be managed with finegrained accuracy. Reliable policy control complicated by gateway performance limitations. The delta between standards-compliance and use case enablement. Different implicit signaling, traffic measurement implementations and compliances between network access equipment vendors. This paper describes how Sandvine s network policy control platform for mobile networks addresses these issues, providing a solution for today s 2G/3G networks and a path for seamless evolution towards 4G.

2 Market Drivers Subscribers have enthusiastically embraced 3G data services as smart phones, tablets, 3G data dongles and mobile applications make it easier for consumers to enjoy broadband content anywhere and at any time. Consumers are using smart phones for web surfing, ing, social networking and increasingly for real-time entertainment such as video streaming. Similarly, consumers are using 3G/4G-enabled laptops and tablets for online access and many are choosing mobile broadband as their primary connection method. This success, combined with the economic reality of providing mobile data services, is forcing providers to adopt new technologies that offer more cost-efficient network operation and value added data services for increasing revenue. On top of all these consumer drivers, there is an exponential increase in the use of mobile machine-to-machine applications (e.g., utility readings, cameras, healthcare monitoring, etc.) and enterprise cloud computing that will also drive significant growth. For a clear view into this emerging reality, download Sandvine s Global Internet Phenomena report here. Historically, in voice-dominated mobile networks, revenue growth was proportional to increased traffic volume, which allowed operators to tie network costs to the traffic growth associated with additional subscription. As shown in Figure 1, in a data-dominated mobile network with flat or fair usage rate pricing, the expectation is for the data traffic volume to increase exponentially while the data revenue increases only slightly. Figure 1: Coupling of traffic & revenue in mobile networks Revenue derived from each Gbyte of LTE data is in the vicinity of seven US dollars while in Europe it is about 2.50 US and as low as 63 cents US in some Scandinavian countries 1. To keep and increase profits, 1 Page 2

3 mobile operators have been forced to introduce technologies that decouple network costs from traffic volume to the greatest possible extent. First they must leverage the key LTE technology that lowers core operating costs the all-ip network. Figure 2: Coupling of revenue and network cost with LTE The LTE standard, which includes the System Architecture Evolution (SAE), uses a flat, all-ip architecture that provides efficient scaling in the packet core to lower the cost per bit as the traffic volume increases. The LTE architecture will allow operators to more closely couple network cost with revenue as traffic volumes grow. LTE radio access also has a flatter and more cost-effective architecture and radio coding/modulation than 2G or 3G technologies, further decreasing costs. In addition to the all-ip network, more efficient radio access, and the associated lower network costs, LTE also enables much higher peak data rates for devices - up to 326 Mbps. LTE does away with the circuit switched core network and transports all services, including voice, using the IP packet core network. As a result, mobile operators are beginning to adopt flow management and Quality of Service (QoS) techniques to manage the Service Level Agreements (SLAs) for subscription plans across the all-ip network and to lower the overall cost of network operation. To maximize the use of these capabilities and resources, operators are either improving or implementing another key technology for their business - network policy control. The Fall of Erlang and the Rise of IP Since the beginning of the 20th century, voice networks have been engineered for capacity according to the Erlang model. In comparison to data networks, voice networks have some key simplifications that allowed the modeling to occur: Voice is treated as constant bitrate (i.e., one voice circuit uses constant network bandwidth) Voice is treated as a symmetric path (both directions follow the same links) Voice is treated as a single path (no multi-path networks are used) Voice sessions start at a predictable rate according to human behaviour Voice packets are fixed size Sessions go from many-to-one (handsets to voice switch) and do not interact with each other Page 3

4 As a consequence, telephony network providers were able to build their network capacity according to simple and fixed design rules (e.g., 99.99% of calls would complete at the busiest hour). It is assumed the quality of a call is Boolean if it connects, it has perfect quality; if there is insufficient capacity, it is blocked (connection admission control). Early-generation mobile networks introduced some complexity to voice Erlang in that the hand-off between locations had to be handled as the user moved, but the overall rules and technologies stayed the same - an end-to-end circuit from the user handset to the mobile-switching center (and from there to the call recipient) started at a predictable, low rate and used a fixed capacity in a symmetric fashion on a single path. As data needs grew, IP packet-switched networks became the de-facto standard. Network engineering in data was performed based on peak observed load and forward-prediction models such as HoltWinters forecasting. Capacity-based billing models emerged between carriers based on 95-percentile. QoS switched from deterministic to probabilistic. Circuit-based QoS was replaced by per-hop behaviour. Within a service provider, QoS management may be performed using Differentiated Services Code Point (DSCP) to modify the probability on a per-hop-basis. QoS management between operators is rare. Operators typically provision managed services such as video and voice using traditional circuitswitched models, non-converged networks, or networks converged at the physical layer but partitioned using techniques such as Multiprotocol Label Switching (MPLS). Networks are normally treated as nonoversubscribed except for the last-mile consumer access. Applications requiring quality goals typically build them into the application (usually with buffering, or with complex codecs such as Skype s SILK, which allow for packet loss). The oversubscription in the fixed networks is normally sufficient for QoS-sensitive applications such as Skype and Netflix to function in a best-effort environment most of the time. Figure 3: MRTG utilised capacity chart, 95% line shown As mobile data emerged, network engineering based on observed trends became problematic. The high rate of adoption of new devices and new applications meant that capacity could not be added quickly enough. The disparity between busy and non-busy mobile sectors is now high in terms of volume, and the sectors that are busy vary due to mobility. Since data applications use variable packet sizes, they tend to interact with each other poorly as the links approach 70-80% utilization. In particular, latency tends to go up exponentially as the link utilisation goes over 75%. Applications which use TCP and large packets tend to dominate the throughput, creating latency issues for smaller packet applications. Page 4

5 120% % % 80 60% 60 40% 40 20% Latency (ms) Loss (%) Ethernet Utilisation vs. Loss/Latency 20 0% 0 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% Utilization (%) Loss Latency Figure 4: Ethernet utilization vs. loss/latency LTE and Network Policy Control Network policy control and the Policy Control and Charging (PCC) architecture are fundamental to any modern data network, whether 2G, 3G or 4G. Policy control is used by voice services to dynamically request QoS to ensure toll-quality communication, which is absolutely necessary in an all-ip network. Network policy control also allows operators to more accurately measure, manage and charge for different types of data services. As defined by 3GPP, PCC is a service-based framework (i.e., group of 5-tuple classifiers - source IP address, destination IP address, source port number, destination port number, and protocol ID of the protocol above IP) for flow-based online policy control, and online/offline charging. PCC supports both static (i.e., pre defined) and dynamic policy rules. In the PCC framework, the initial vision was that applications, such as IP Multimedia Subsystem (IMS) application servers (i.e., P-CSCF), requiring dynamic policy and/or charging control would be represented by the Application Function (AF). The AF is the element serving the specific content/application in IMS architecture. It was intended to signal the Policy and Charging Rules Function (PCRF) for dynamic control and, if admitted, the PCRF would install or invoke a policy rule on the Policy and Charging Enforcement Function (PCEF), thus allowing the transport of the desired application protocol. The AF, as written, is supposed to support dynamic changes to policy and charging at any time during an ongoing subscriber data session. This flexibility is meant to enable dynamic changes in, for example, data access rates and charging due to a subscriber s immediate need to complete a session-related task or resolve nonpayment of service. The integration of these different elements through standardized interfaces was projected to facilitate the implementation of IMS services in a streamlined and consistent manner. The 4G/LTE architecture is comprised of the following key functional entities: enode-b on the access side, and in the core network a Mobile Management Entity (MME), a PCRF and the SAE Gateway (SAE-GW). The SAE-GW, an umbrella term in some references, consists of both the Serving Gateway (S-GW) and a Packet Data Network Gateway (P-GW). Page 5

6 Figure 5: LTE/SAE network architecture and EPC The MME sits in the control plane and manages the mobile terminal handovers. The S-GW terminates the interface from the LTE radio access and provides the local mobility anchor. The P-GW terminates the interface to the S-GW, provides the IP session mobility anchor and provides interfaces to the external packet networks, including non-3gpp access. The P-GW is the key node for policy and charging enforcement. The enode-b is the Radio Access Network (RAN) node and provides the RAN anchor. For policy charging and control, LTE architecture references identify the PCRF as a key element. The PCRF, introduced in 3GPP release 7, is depicted for deployment in the control plane and was intended to manage the dynamic control of bandwidth, QoS, charging and usage by signaling to a PCEF in the bearer plane that actually enforces polices on the wire. The PCEF is defined as the entity that enforces flow-based policies (per the 3GPP 5-tuple service framework) on the wire and reports charging rule information to the Online Charging System (OCS) and Offline Charging System (OFCS). The PCEF may have both static and dynamic policies for bearer and service data flow control and measurements for charging (e.g., time, volume and events such as application access) and, due to its strategic positioning in the subscriber bearer plane, it has complete visibility of the entire spectrum of Over-the-Top (OTT) applications that comprise the majority of Internet traffic. Release 8 further enhanced the PCRF by widening the scope of the PCC framework to facilitate non 3GPP access to the network using the Bearer Binding and Event Reporting Function (BBERF) logical node, as shown in Figure 6. The BBERF is is a logical representation of non-3gpp gateways (e.g., AGW in 3GPP2, ASN-GW in WiMAX). It is needed to signal QoS information from the PCRF in the 3GPP domain into the non-3gpp domain s access network. Release 9 introduced real-time resource monitoring and enhancements to QoS control. Page 6

7 Figure 6: Policy and Charging Control (PCC) for LTE/SAE & 3GPP Release 9+ Gx Usage Monitoring Usage Monitoring over the Diameter Gx interface was a feature introduced with 3GPP TS release 9. It reports usage volume information strictly through a Diameter Gx session between the PCEF and PCRF. As a relatively simplified concept of online charging, usage monitoring over Gx is only limited to volume (i.e., bytes) reporting. Reporting usage for time quota is not natively supported over the Gx interface, but deployments are relatively straightforward when compared to standards-based online charging using Diameter Gy. Key 3GPP Release 11 PCC Elements 3GPP release 11 added a Traffic Detection Function (TDF) with a Sd interface to the PCRF and the Sy interface between the OCS and PCRF. The intent of the Sd interface is to allow the PCRF to be aware of traffic protocols and applications for finer grained policy control by the PCRF while the Sy interface provides coordinated real-time billing and policy control. Both new interfaces increase the signaling complexity of the overall architecture. Before moving on it s important to thoroughly review the six main functions of the 3GPP PCC standards that manage services and QoS in modern networks. The following core functions are shown in Figure 7: SPR (Subscription Profile Repository) OCS (Online Charging System): optional - may be dealt with using Gy/CCR AF (Application Function): one per operator-provided service PCRF (Policy Charging Rules Function) PCEF (Policy Charging Enforcement Function) TDF (Traffic Detection Function): optional - may be merged into PCEF Page 7

8 Figure 7: 3GPP PCC block diagram, release 11 AF The AF, if involved, may provide the following application session related information (i.e., based on SIP 2 and SDP 3): Subscriber Identifier - typically the MSISDN (Mobile Subscriber Integrated Services Digital NetworkNumber) of the user, if known by the AF IP address of the UE Media Type, Media Format (e.g., media format sub-field of the media announcement and all other parameter information (a= lines) associated with the media format) Bandwidth Sponsored data connectivity information (e.g., allowing the flow to be zero-rated towards the consumer, and the charge in aggregate to be dealt with in some other fashion) Flow description (i.e., source and destination IP address, port numbers and the protocol) AF Application Identifier AF Communication Service Identifier (e.g., IMS Communication Service Identifier), UE provided via AF AF Application Event Identifier AF Record Information Flow status (for gating decision) Priority indicator, which may be used by the PCRF to guarantee service for an application session of a higher relative priority Emergency indicator Application service provider (i.e., the Diameter realm or business name) 2 Session Initiation Protocol, RFC Session Description Protocol, RFC 4566 Page 8

9 SPR The SPR may provide the following information for a subscriber, connecting to a specific packet gateway: Subscriber's allowed services (i.e., list of Service IDs) For each allowed service, a pre-emption priority Information on subscriber's allowed QoS, including: the Subscribed Guaranteed Bandwidth QoS; a list of QoS class identifiers together with the MBR limit and, for real-time QoS class identifiers, GBR limit. Subscriber's charging related information Spending limits profile containing an indication that policy decisions depend on policy counters available at the OCS that has a spending limit associated with it and optionally the list of relevant policy counters Subscriber category Subscriber's usage monitoring related information Subscriber's profile configuration Sponsored data connectivity profiles Multimedia Priority Service (MPS) Priority (user priority) IMS Signaling Priority PCRF A PCRF has two key functions in the 3GPP PCC standards: provisioning charging rules to the PCEF (performed on session initiation), and creating/destroying dedicated bearer PDP contexts (and thus radio bearers) in response to a request from an Application Function (AF). It is important to note that the use of a PCRF is optional; it is not a required element of a 3GPP network. The original framers of the 3GPP PCC specifications anticipated the PCRF installing dynamic rules (5tuple based) on a per-flow basis. In 3GPP R8 this was deprecated in favour of application detection and control (ADC) rules (giving much greater scale), and this was formalized in R11 in the May GPP TSG SA WG2 meeting. Figure 8: PCRF system architecture Page 9

10 PCEF The PCEF is the main component of PCC, and its use is non-optional. An operator can (and commonly does) have pre-provisioned PCC rules in the PCEF (other basic rules are also provisioned in the HLR/HSS). The PCEF typically gets subscription information from the AAA or S6a interface towards the HSS & AAA. The PCEF performs the following primary functions: Gate enforcement. The PCEF allows a service data flow, which is subject to policy control, to pass through the PCEF if and only if the corresponding gate is open. This provides a means of blocking unknown or unenforced traffic (and may be used to block, for example, users with no credit). Charging Trigger Function where through Diameter Credit Control it feeds information to an Online Charging System in order to track usage. Charging Data Function through offline charging records required for typical post-paid services and charging reconciliation. QoS enforcement: QoS class identifier correspondence with IP session-specific QoS attributes. The PCEF converts a QoS class identifier value to IP-session specific QoS attribute values (typically DSCP) and determine the QoS class identifier value from a set of IP-session specific QoS attribute values. PCC rule QoS enforcement. The PCEF enforces the authorized QoS of a service data flow according to the active PCC rule (e.g., to enforce uplink DSCP marking). IP-session bearer QoS enforcement. The PCEF controls the QoS that is provided to a combined set of service data flows. The policy enforcement function ensures that the resources which can be used by an authorized set of service data flows are within the "authorized resources" specified via the Gx interface by "authorized QoS". The authorized QoS provides an upper bound on the resources that can be reserved (GBR) or allocated (MBR) for the IP session bearer. The authorized QoS information is mapped by the PCEF to IP CAN specific QoS attributes. During IP-CAN bearer QoS enforcement, if packet filters are provided to the UE, the PCEF shall provide packet filters with the same content as that in the service data flow template filters received over the Gx interface. TDF 3GPP technical specifications and version 12 describe the relationship between the TDF, Policy Control and Charging Rules Function (PCRF), Policy and Charging Enforcement Function (PCEF), various Diameter interfaces and other related elements such as the Online Charging System (OCS). The key aspect that determines compliance as a 3GPP release 11 or higher TDF is support for the newly introduced Diameter Sd reference point described in TS Diameter Sd is used for communication between the TDF and PCRF using application detection and control (ADC) rules fully detailed in TS Decisions about which applications to detect can be installed locally to a TDF and/or to what the specifications refer to as a PCEF enhanced with ADC ; that is, a PCEF with an embedded TDF, which has embedded ADC rules. 5 The PCEF uses Policy Control and Charging (PCC) rules and the Diameter Gx reference point to communicate with the PCRF (in place since release 7 and also described in TS ). 3GPP release 12 introduced charging support to the TDF, effectively duplicating charging functions also described for the PCEF element. Both the TDF and PCEF elements must interpret monitoring keys from the PCRF and charging keys from the OCS. 6 Indeed, the charging 4 3GPP TS V ( ), section 4b 5 3GPP TS V ( ), section Ibid. Page 10

11 sections of TS often describe the PCEF and TDF elements as one entity; for example, the credit management section of TS is addressed at the PCEF/TDF element having or receiving PCC/ADC rules. 7 Annex Q of TS provides the following view of the logical relationship between these elements and their interfaces when online charging and an OCS are also in play: PCRF Gx, Sd Sy OCS Gy, Gyn PCEF/ TDF Figure 9: Usage Monitoring via Online Charging System (3GPP TS v , Annex Q) The TDF may be deployed in two different ways: it may signal on a per flow basis after detection towards the PCRF, or it may act to perform the gating/redirection/bandwidth limitation without informing the PCRF. The latter use case is more common as over-the-top applications often operate at much greater scale than the PCRF is capable of handling. For those cases where service data flow description cannot be provided by the TDF to the PCRF, the TDF performs gating, redirection, bandwidth limitation, and metering (for charging) of detected applications. OCS The OCS is out of the scope of PCC, but does have a recent (and not widely adopted) interface towards the PCRF for purposes of coordinating policy with credit. A common approach is to perform this function via the PCEF directly (as it too communicates with the OCS via Diameter Gy). The OCS, if involved, may provide policy counters status for each relevant policy counter towards the PCRF over the newly emerging Sy interface. In addition, the PCEF has a connection via Gy towards the OCS, and can make its own evaluation of rules based on credit responses. 7 Ibid, section Page 11

12 3GPP PCC Theory of Operation Figure 10 shows the overall PCC system and its interconnections to non-pcc components. Figure 10: 3GPP block diagram, expanded, with core PCC components shaded The general signaling flow through the 3GPP PCC architecture is initiated by either the user (session initiation) or via the AF/TDF. The following five major signaling flows are important to describe: 1. Subscriber initiates bearer (creates PDP context): When the subscriber registers their device to the network, after authentication by the S-GW and the HSS, a default bearer is created on the P-GW. The PCEF initiates a message with Gx to load the rule-set for the user (which is ultimately stored in the SPR). 2. Application-function initiated change: When activated, the AF signals the PCRF via Rx to indicate a new service flow (matched using IP header bits), selecting the QoS and charging parameters. The PCRF provisions this rule into the PCEF with the appropriate TFT & QCI, which commences the QoS and charging as specified by the AF. 3. TDF-initiated change: Conceptually this is identical to the Application-function initiated change, except that it is based on detecting an application, rather than the user initiating the application. 4. Network-initiated change (RAT change, loss of bearer, QoS change, etc): Based on a rule on the PCEF, a trigger can be sent towards the PCRF (using Diameter Gx). Examples include quota exceeded, start use of an application, entrance to a specific location, etc. 5. PCRF-initiated change. The PCRF is free to run internal logic on conditions it is aware of, and change the provisioning of rules on the PCEF using a Gx RAR. TFT In 3GPP, a TFT (Traffic Flow Template) is a classifier that matches on fields on the inner-ip of a GTP-U tunnel. This in turn causes differentiated radio-bearer performance. The filter can match on any or all of the following fields: Source address (with subnet mask) IP protocol number (TCP, UDP) Destination port range Source port range Page 12

13 IPSec Security Parameter Index (SPI) Type of Service (TOS) (IPv4) Flow-Label (IPv6 only) Whether using the static-tft model or the dynamic Gx-signaled TFT model, the same sequence occurs: a dedicated bearer (secondary PDP context) is created, and traffic is forced to match it. An operator has a choice of dynamically creating PDP contexts using Gx, in which traffic matching the TFT filters into the context based on rules in the PCEF, or having dynamic PDP creation done by the packet gateway itself based on traffic matching with pre-provisioned values. This can be useful if an upstream device on SGi will mark packets matching certain conditions with DSCP. Figure 11: TFT mapping to PDP context on 3G (dedicated bearer analogous to secondary) The LTE version of the standards allows up to nine TFTs to be used per bearer. In prior revisions, there is only one TFT allowed, which is important to note if QoS handoff between HSPA and LTE, or LTE and CDMA is needed. The TFT selects which PDP context is used, and the QCI label is a short-hand for the QoS parameters within the context. Note the QCI is a short-hand label only. The standardized QCI characteristics are given as rough guidelines in Table of 3GPP TS (v11.3.0), reproduced here: Table 1: Table from 3GPP TS V QCI Resource Type 1 (Note 3) 2 (Note 3) 3 (Note 3) 4 (Note 3) GBR (guaranteed bitrate) Priority Packet Delay Budget Packet Error Loss Rate 2 100ms 10-2 Conversational Voice 4 150ms 10-3 Conversational Video (live) 3 50ms 10-3 Real time gaming 5 300ms 10-6 NonConversational Video (buffered) Page 13 Example Service

14 5 (Note 3) 1 100ms 10-6 IMS Signaling 6 (Note 4) 6 300ms 10-6 Video (Buffered streaming) TCP 7 100ms 10-3 Voice, Video (Live), Interactive Gaming 300ms 10-6 Video (buffered streaming), TCP 7 (Note 3) Non-GBR 8 (Note 5) 8 9 (Note 6) 9 NOTE 1: A delay of 20 ms for the delay between a PCEF and a radio base station should be subtracted from a given PDB to derive the packet delay budget that applies to the radio interface. This delay is the average between the case where the PCEF is located "close" to the radio base station (roughly 10 ms) and the case where the PCEF is located "far" from the radio base station, e.g. in case of roaming with home routed traffic (the one-way packet delay between Europe and the US west coast is roughly 50 ms). The average takes into account that roaming is a less typical scenario. It is expected that subtracting this average delay of 20 ms from a given PDB will lead to desired end-to-end performance in most typical cases. Also, note that the PDB defines an upper bound. Actual packet delays - in particular for GBR traffic - should typically be lower than the PDB specified for a QCI as long as the UE has sufficient radio channel quality. NOTE 2: The rate of non-congestion related packet losses that may occur between a radio base station and a PCEF should be regarded to be negligible. A PELR value specified for a standardized QCI therefore applies completely to the radio interface between a UE and radio base station. NOTE 3: This QCI is typically associated with an operator controlled service, i.e., a service where the SDF aggregate's uplink / downlink packet filters are known at the point in time when the SDF aggregate is authorized. In case of E-UTRAN this is the point in time when a corresponding dedicated EPS bearer is established / modified. NOTE 4: If the network supports Multimedia Priority Services (MPS) then this QCI could be used for the prioritization of non-real-time data (i.e. most typically TCP-based services/applications) of MPS subscribers. NOTE 5: This QCI could be used for a dedicated "premium bearer" (e.g. associated with premium content) for any subscriber / subscriber group. Also in this case, the SDF aggregate's uplink / downlink packet filters are known at the point in time when the SDF aggregate is authorized. Alternatively, this QCI could be used for the default bearer of a UE/PDN for "premium subscribers". NOTE 6: This QCI is typically used for the default bearer of a UE/PDN for non-privileged subscribers. Note that AMBR can be used as a "tool" to provide subscriber differentiation between subscriber groups connected to the same PDN with the same QCI on the default bearer. PCC rule parameters QCI QoS class indicator ARP Allocation/Retention Priority -- information about the priority level, pre-emption capability, and pre-emption vulnerability. ARP priority is 1 15, 1 has highest priority. 1-8 are used within the operator domain, 9-15 are used when roaming. GBR guaranteed bitrate MBR maximum bitrate SDF service data flow Packets matching the rule (the TFT) will be routed into a bearer that matches the settings (via the QCI) of ARP, GBR, and MBR. Page 14

15 LTE Challenges In LTE networks, there are technological advances in the RAN that significantly improve capacity, performance and QoS. The core network architecture, EPC, has also evolved to support these advances. Nonetheless, operators moving to LTE networks are still faced with a number of challenges that must be overcome to utilize all of the benefits of this evolution. As mobile operators increase data service speeds, they will begin to see many of the same challenges their fixed counterparts have already faced. Operators will need to manage bandwidth usage fairly to prevent a few users from negatively impacting the Internet experience of many others. They will also face bandwidth-intensive applications that cause traffic congestion and denial-of-service attacks that can prevent many subscribers from enjoying the network. Of course, managing bandwidth usage fairly is even more important on a shared radio channel with many subscribers contending for service. Moreover, with a radio network, two subscribers that should be getting the same service and QoS may actually have vastly different QoS based on their channel quality. Having policy that ensures consistent QoS as much as possible despite subscriber channel quality is critical for ensuring a consistent subscriber experience. Compounding all of this is the need for mobile operators to improve top line revenue with new services. In today s 2G/3G networks, the need to increase margins is critical and many operators cannot wait several years for the expensive migration to LTE they need to reduce network congestion and provide service choices to subscribers right now. Even though LTE promises a lower cost per bit and will offer superior data throughput, operators will still need to simultaneously maintain or increase the revenue per bit through advanced, differentiated services. PCC provides a framework for enabling AFs to signal policy requests such as granting subscribers access to applications, charging and QoS. However, this presents a challenge for operators because PCC was designed for legacy walled-garden applications, while the current market demand is for open Internet access and OTT services such as Facebook and YouTube. As a result, there are few if any applications other than IMS voice that are capable of signaling policy requests to the PCC infrastructure. The challenge for operators has now become how to implement Network policy control for bandwidth-intensive OTT services like Netflix. The following are key questions a network operator needs to answer: 1. Will dynamic PCC (flow-based) rules be used? This dramatically impacts the scale of the PCRF deployment, the use of Diameter routing agents, and the signaling load on the evolved packet core. 2. Will Application Detection and Control (ADC) rules be used? The richness of capabilities of the PCEF will be the gating factor for services. 3. Will static PCC rules be used? An upstream marking device with application awareness may be needed. 4. Is QoS in the radio sufficient? If not, all rules need to apply to both the enodeb (via the TEID and PDP context) in addition to other network technologies using their own proprietary methods (e.g., RSVP-TE, DSCP, MPLS-EX, ) Page 15

16 Meeting the Challenge of Today s Layer-7 Realities Although 3GPP release 9 is now widely deployed, many questions still remain about implementation. Just as PCC was designed for a walled-garden service structure that never materialized, the 3GPP release 9 framework also suggests overly-simplistic policy control architecture. The availability in LTE of multiple bearers does not provide the fine-grained control required in today s environment. Standards do not account for the need to identify and manage traffic for hundreds of popular OTT applications with various bandwidth and QoS demands, all on essentially a few bearer channels each with a loose definition of QoS. Subscriber behavior is unpredictable from a resource admission perspective and the open Internet calls for an efficient strategy where the network nodes are capable of making decentralized decisions at the speed at which new flows are exchanged with the network. The behavior of typical users on the popular Facebook and YouTube websites is to continuously access multiple embedded applications through simple hyperlink click requests that can translate into tens of different new flows per application access in a model that is completely orthogonal to the IMS or walled garden mechanism, where service typically equals a single service flow. As shown in Figure 12, many concept and logical reference diagrams presume to show the PCEF function residing inside the physical gateway node and lacking decision capabilities. The PCEF element must handle the extremely high incremental processing capacity required to measure subscriber QoE for congestion management, and accurately meter subscriber data sessions for revenue-generating services. The physical implementation of 3GPP concepts must address the reality of how consumer demand affects network behavior and resources. PCC plans and concepts drawn up for networks with robust, internal application functions did not foresee the current, contrary trend toward OTT services. Sp Subscription Profile Repository (SPR) AF Online Charging System (OCS) Rx Policy and Charging Rules Function (PCRF) Sy Gxx Sd Gx Gy BBERF TDF PCEF PCEF Gz Gateway Offline Charging System (OFCS) Figure 12: Overall PCC logical architecture from 3GPP TS V ( ) Many operators are reporting a signaling storm upon deploying centralized decision-making architectures. But why is this happening? It often comes down to the sheer number of data flows Page 16

17 combined with relatively short flow lifetimes. Recall the Google study described in the URL Access Control use case. Put simply, it is impossible to scale when there is a single point responsible for all policy decisions. The messaging intensity of PCC architecture is determined by the location of the required data, the data s dynamism and the functional partitioning which then requires access to the data. It is most logical to allocate decision functionality to the point where the data is most dynamic on the data plane. Subscriber context awareness One of the most important aspects of a network policy control solution is the ability to obtain and maintain the subscriber context from initiated data sessions. This involves obtaining the IP address, device, network access type and application from the data session, and then adding external business data (such as subscriber service plan) to act on the service flow for measurement, policy, reporting and charging. Moreover, with the rapid proliferation of applications coming from the iphone platform and now with Google s Android, a key component is the ability to craft enforcement and measurement policies based on Layer-7 information. As tablets and smart phones become more powerful, the use of encrypted P2P and signature-evading OTT VoIP and video communication applications will only increase. Subscriber Session Mapping With the introduction of LTE, IP allocation is done by the P-GW. The P-GW network attach procedure will likely make use of an internal DHCP function. In addition, the AAA function will also evolve towards being an internal function and not be located on an external node. The migration to IPV6, and the effect on subscriber awareness for network policy control, must also be considered. Because LTE will not necessarily guarantee an external AAA function, alternate sources for the subscriber-to-bearer and IP mapping are required. Policy control and charging requires the accurate identification of the subscriber corresponding to the data session IP and bearer. Depending on the desired use case, the typical deployment location for the Sandvine PCEF is on the S5/S8 (separate S-GWs and P-GWs) and S1-U, and S11 or S6a interfaces (for combined S-GWs and P-GWs). The S5 interface is between the home S-GW and the home P-GW, while the S8 interface is between the roaming S-GW and the home P-GW. Sandvine passively monitors GTP-Cv2 signaling to extract the necessary bearer information required for subscriber mapping. This can be achieved directly on the S5/S8 interface or via the S1-U and S11 or S6a interfaces. An alternate approach is to passively monitor the P-GW s Gx session establishment and extract the bearer information. Duplicate functions for PCEF/TDF Release 11 3GPP specifications recognized the importance of OTT traffic identification in policy control with the introduction of the Traffic Detection Function (TDF) and Sd reference point. The TDF and Sd reference point are important steps towards aligning standards with the needs and functions of present day network policy control. 3GPP release 12 added credit control and charging functions to the TDF, better acknowledging today s service creation opportunities and challenges. The TDF may also provide usage monitoring towards the PCRF (so that the PCRF can provide an additional form of metering when an OCS is not present or capable) using the Sd interface. Page 17

18 The latest standards have significantly closed the gap on what the industry refers to as standardslag, but because standards do not address the individual needs of service providers there will always be a need to fill gaps with proprietary features that meet present-day realities. Standards were never intended to fully specify all functionality but instead serve mainly to ease multi-vendor interoperability. The competitiveness of use cases that leverage functions to detect, measure, control and meter Layer-7 traffic depend less on compliance with the latest communication reference point than it does on vendor features built on top of a standards-based framework. Since network policy control solutions have had application detection and control at their core since long before release 11 standards were drafted, all of the functions described for the TDF in 3GPP release 12 exist already as vendor features built or not built over a standards-based framework. Many standalone PCEF elements and their Gx reference points are enhanced to incorporate application detection and control, metering for charging and even measurements. The Sd and Sy interfaces have the potential to dramatically increase the signaling load between PCC architecture nodes, creating the potential for a costly and quality-impacting storm of signaling that limits the deployment of advanced Layer-7 use cases. Success or failure will depend on individual vendor features that optimize standards-based signaling to enable advanced use cases. As of release 12, the standards remain vague regarding how topology/location information will be provided from the PCRF to the TDF. Some vendors offer location awareness using proprietary features. Theoretically, the standards provide an optional mechanism for every location change to be propagated from the RAN all the way to the PCRF. However, for practical reasons this has not been implemented, and therefore the TDF as purely described in the latest standards will face a similar problem. 8 Dual IPv4 & IPv6 Stack With LTE, the migration to IPV6 is unavoidable so many PCC solutions will require dual stack support. Incoming IP packets may be using IPV4, but they must be conveyed to the user terminal as an IPV6 packet. Network Address Translation (NAT) will therefore be a standard function of the P-GW or another network element. Figure 13 shows how IP packets would be conveyed if IPV4 packets were encapsulated in IPV6 packets (IP-in-IP). Something similar would occur for IPV6 packets encapsulated in IPV4. The consequence of this encapsulation is that any PCC solution needs to be able to inspect IPV4 and IPV6 packets and continue to obtain the service flow data, such as application and device type. Sandvine provides the required capability of inspecting both IPV4 and IPV6 packets. Figure 13: LTE Dual Stack support 8 To learn about Sandvine s approach to the TDF and latest standards, see Technology Showcase Traffic Detection Function. Page 18

19 Network Policy Control Solutions for LTE The challenges described in this paper raise questions about how to best support the PCRF element s central role as decision-maker in the network policy control planning model presented by 3GPP specifications. Advanced policy requires the following elements: 9 Context awareness policy, measurement and charging based on knowledge derived from the subscriber session such as the application, access network, device type, dynamic measurements, location and time, as well as imported external business data, such as subscriber service plan. The ability to map subscriber s identity to IP address, device, network type and location for measurement, policy and charging. The ability to signal external policy nodes such as GGSN or P-GWs, or even legacy nodes using Charge-of-Authorization (CoA), for optimal policy action. The ability to perform intelligent traffic management without the need for PCRF signaling at every decision point (millions of service flows per second). The ability to provide uniform, technology- and vendor-agnostic dynamic measurements, policy, reporting and charging. The ability to support dual IPV6 and IPV4 stacks, and IPv6 transition technologies. The ability to roll up all of the above to provide advanced policy in support of critical operator use cases. Finally, all of these features must be supported and, in some cases, enabled by a comprehensive network business intelligence framework that provides a detailed historic and present view, but also supports automatic synthesis and analysis of data to reveal trends for service monitoring and revenue planning. All of these capabilities are for a single purpose to create dynamic measurements, policy, reporting and charging that increase ARPU, control cost and retain subscribers. How can mobile operators capitalize on OTT usage trends and congestion control technology in their current data networks with an eye on the migration towards LTE? To address the OTT issue, meet current revenue demands and fully leverage improvements in the RAN and core networks, mobile operators must upgrade from the coarse-grained policy control associated with traditional 2G/3G solutions to a fine-grained solution that functions across all network types. Advanced, fine-grained policy control provides the ability to enforce QoS and charging policies from the IP flow level (layer 3) up to the application and service level (Layer-7). This allows operators to implement fair use, tiered services and sophisticated charging tariffs in present and future networks. This capability is not optional if operators want to compete in the emerging open Internet services environment where third-party OTT service providers, as well as handset vendors, can capture more of the value enabled by LTE networks. Importance of Distributed Decision A standalone PCEF, with a policy decision engine that processes traffic and enforces policy in real time, allows the core network to focus on the essential functions of managing mobile core user traffic such as address allocation, user plane data routing and handoffs. For example, mandating a PCRF to send 9 For a complete overview of Sandvine s standards-based solutions for LTE, see Technology Showcase Sandvine, LTE and the Evolution of Network Policy Control. Page 19

20 primitive policy signals for millions of IP service flows to the GGSN or P-GW severely loads both the PCRF and core network nodes. Instead, a standalone PCEF solution can interact with the PCRF to activate rules on a per-subscriber basis. The key to a scalable solution is to integrate PCEF and PCRF functions to maximize the ability to make decisions and take actions at the same place conditions are detected. In terms of pure efficiency, it is appropriate to only have central decisions made remotely when a subscriber-specific condition has changed (thereby impacting entitlement such as QoS or usage quotas, and even then as described in the pre-paid quota management use case analysis this can also be distributed to a large extent). By extension, network-related conditions are handled locally by the distributed network element. Network conditions can be understood, and decisions based on network conditions can be made directly, by the intelligent enforcement layer on the data plane instead of asking for permission to implement an action that could have already been known. Figure 14 shows how a decision-making hierarchy can cut the number of policy transactions by orders of magnitude at each functional layer (the absolute numbers in this figure are dependent upon deployment characteristics and are meant primarily to illustrate the relative ratios of messages between the planes). The data plane, which makes decisions on a session, flow and packet level, tackles millions of transactions per second. By distributing these decisions across many elements with joint policy decision point (PDP) and policy enforcement (PEP) functions, each instance has a manageable number of transactions and the model scales to actual network environments. 10 The control plane is only called into matters for a subset of the data plane s transactions and experiences anywhere from 100 transactions per second to 50,000 still a much lower number than that facing the data plane. The control plane focuses on subscriber and session-level decisions. The management plane addresses a much lower rate of transactions by virtue of only being called upon for subscriber-level decisions like provisioning. Figure 14: Relative transaction rates and decision levels for distributed network policy control architecture As the name implies, LTE is an evolutionary path from 3G to 4G. Therefore, the evolutionary path of network policy control must support both 4G and legacy 2G/3G networks to ensure advanced data services work across all networks and for all customers. Operators must uniformly manage 2G/3G, WiFi and LTE simultaneously, and without significant latency, jitter or throughput variations. It s important to note that 3GPP specifications are not implementation plans and, even with 4G/LTE networks, access 10 For a detailed overview of Sandvine s approach to distributed decision, see the whitepaper Distributed Decision in Network Policy Control. Page 20

21 equipment vendors will use different implicit signaling that requires considerable work for interoperability testing. The Right Solution Ultimately, the right solution is one that allows the network policy control platform to trigger the right policy at the right place and time, and for the right subscriber and device. 1. Right Policy: Correctly identifying the application, subscriber location and associated service flows and, then tying this to the correct policy 2. Right Place: Enforcing the policy with the optimal element - either the PCEF, the P-GW, or any other element the policy decision point (PCRF) needs to signal to in converged architectures 3. Right Time: Addressing the current packet, the next packet, or the next IP flow 4. Right Subscriber and device: Associating the policy to the correct subscriber and device as they move throughout the network Right policy, right time, and right place means making a policy decision in real time at wire speed in the bearer plane. A common approach based on 3GPP TS is for the PCEF to act as an AF to request, via Rx, rules from the PCRF, which are then pushed via Diameter Gx back to the PCEF for enforcement. However, this is not efficient in the current Internet environment where millions of new flows per second must be evaluated to manage Layer-7 traffic. Implementing individual PCRF evaluations for every Layer-7 flow requires a significantly higher number of PCC rules, increasing the solution s performance footprint, increasing latency and hampering the viability of complex workflow deployments. As they relate to network policy control, 3GPP standards are not intended to constrain deployable use cases but to establish the baseline operating parameters for component interoperability. This means that it is important to support the latest applicable 3GPP standards for a particular CSP deployment, and to then going beyond with enhancements that actually enable advanced Layer-7 policies that minimize latency by activating behaviors, workflows and applicationbased traffic actions at the data intersect point. Sandvine s approach is to use Diameter Gx, based on 3GPP TS , to communicate rule names from the PCRF to the PCEF, which are then associated with local PCEF policies. The PCEF supports a real-time policy engine that removes the need to constantly pull complex policies from a PCRF or wait for an application to push them. As a concrete example, a PCRF may contain the names of several dozen video streaming and social networking plans. The PCRF manages subscriber session-level decisions, including associating subscribers with plans, and sends this to the PCEF. The PCEF contains a detailed policy of how to manage the Layer-7 data flows on a per-subscriber basis for each plan. Decisions for rapid flow rates are made at the point where fast-changing conditions are detected on the wire eliminating concerns of about latency caused by Layer-7 signaling operations. This flexible approach empowers network operators to create much richer policy sets for charging and enforcement solutions that go beyond minimalist interpretations of the 3GPP standards solutions that will function reliably in 2G, 3G or 4G networks regardless of the access method. With no need to signal a PCRF at every decision point, this approach substantially reduces signaling traffic. For accurate traffic metering, and to enforce fair usage, tiered services and usage-based policies, solutions must determine and execute the enforcement or notification action in real time. Traditional 3GPP proposals attempting to address this problem focus on the coordination of policies in the PCRF, while pre-paid credit control would be managed by the OCS. This creates a hole in terms of managing non pre-paid users and synchronizing information between the PCRF and the OCS. An architecture that Page 21

22 is already signaling-intensive requires additional message exchanges to resolve the synchronization problem. 3GPP has formalized this OCS-to-PCRF interface with the Sd interface specification. Conclusion The move to LTE will lower the overall cost per bit, but mobile operators will still need to focus on creating new revenue streams with new services and suppressing operating costs with effective traffic optimization. When operators begin to deploy their LTE-based 4G networks, they will need a solution that provides end-to-end QoS management while focusing on the following five critical areas: 1. Containing bandwidth usage costs 2. Developing better bandwidth monetization 3. Reducing the congestion impact to maximize subscriber quality of experience 4. Manage the incremental processing capacity requirements of advanced network policy control 5. Support migration of 2G/3G to LTE while maintaining consistency in policy, measurement and charging Traffic Volume Revenue Quantity Profitability Network Cost (LTE/SAE) Time Voice Dominant Data Dominant Figure 15 Improving LTE profitability with advanced network policy control Page 22

23 Headquarters Sandvine Incorporated ULC Waterloo, Ontario Canada Phone: European Offices Sandvine Limited, UK Swindon, UK Phone: [email protected] Copyright 2013 Sandvine Incorporated ULC. Sandvine and the Sandvine logo are registered trademarks of Sandvine Incorporated ULC. All rights reserved