YOU ARE AT:BSS OSSReader Forum: The need for traffic detection function in LTE

Reader Forum: The need for traffic detection function in LTE

Editor’s Note: Welcome to our weekly Reader Forum section. In an attempt to broaden our interaction with our readers we have created this forum for those with something meaningful to say to the wireless industry. We want to keep this as open as possible, but we maintain some editorial control to keep it free of commercials or attacks. Please send along submissions for this section to our editors at: dmeyer@rcrwireless.com.

Mobile broadband is the fastest-growing medium for accessing the Internet and its unlimited array of content and services. With the rising use of smartphones, tablets and mobile-enabled laptops, consumer demand for downloading, creating and sharing content continues to increase exponentially. Moreover, subscribers left the mobile operator’s walled garden of services long ago in favor of a vast selection of over-the-top Internet content that is driving the demand for more mobile bandwidth.

Perhaps the most important initial factor that drove mobile broadband growth was its predominantly flat-rate billing model, which greatly affected usage patterns. Originally, mobile operators introduced flat-rate billing plans to encourage subscribers to use their mobile broadband service without worrying about the cost. As a result, 3G carriers face increasing over-the-top use that does not translate into proportional revenue growth and increasing congestion that negatively impacts the quality of experience for everyone on the network.

While LTE technology promises to deliver higher bitrates and more bandwidth, it won’t solve all problems. The increase in bandwidth will simply spawn a new generation of bandwidth-intensive applications that were previously insupportable. We already see video applications shifting to higher definition modes given the LTE access opportunity. Moreover, the issues of congestion, quality of service, and revenue generation will be felt across both mobile and fixed networks as they converge.

To remain competitive in this dynamic environment, LTE carriers are looking for ways to maximize their infrastructure investments while managing network use more effectively. Traffic detection function solutions are designed to enable broadband operators to optimize the delivery and performance of OTT applications and services; personalize the user experience by providing tiered service plans that allow subscribers to manage their own usage; and monetize network utilization through online and offline charging policies that meter over-the-top usage and dynamically adjust service availability and cost.

Deep packet inspection is at the heart of TDF and provides the ability to identify data flows in real-time and to leverage that information in order to enforce QoS and charging policies. Today, TDF solutions can be implemented in one of two ways, pure-play or embedded. But to truly realize the benefits of TDF, we must first compare these two architectures and analyze their functionality.

Functionality

A pure-play TDF solution comprises a dedicated, in-line network element that communicates with policy and online/offline charging systems. It employs DPI to identify subscriber-application traffic and enable policy-based QoS and charging actions to be enforced on the traffic flows in real time. Conversely, an embedded TDF solution integrates DPI capability to an existing network element such as a PGW that is already performing fundamental network tasks, including establishing and managing connections, service flow detection, traffic shaping and basic charging.

A pure-play TDF solution employs advanced flow inspection and analysis algorithms that identify data traffic per application, per subscriber and per network topology, plus the ability to act upon this valuable intelligence in real time by mapping it directly into policy enforcement and charging rules. Pure-play TDF integrates seamlessly in the operator network via standard 3GPP interfaces, and real-time traffic intelligence is delivered directly to PCRF and OCS/OFCS elements, enabling policy decisions and charging actions to be taken with the same level of granularity.

Alternatively, the DPI function embedded in today’s PGW is quite basic and therefore unable to identify specific OTT applications. It uses a simple textual method that “reads” the signature in the packet header and allows the PGW to identify 20 to 50 applications on average. It can also identify basic and known traffic patterns.

The embedded DPI function was introduced to the PGW after its original design, and therefore the integration of the function is not optimal. In some cases, in order to expedite availability, a third-party DPI element was employed by PGW vendors. This makes signature updates a cumbersome and lengthy process. As a result, these systems are usually limited to detecting types of applications (such as streaming video) rather than specific applications (such as YouTube), and their ability to identify OTT applications is severely limited.

Performance

Pure-play TDF systems are built for performance. When fully configured, a single pure-play TDF solution can inspect and identify the traffic of up to 8 million subscribers at speeds of up to 160 gigabits per second. As more LTE networks are deployed, the ability to monitor large volumes of traffic at high speeds becomes even more critical.

Since PGW and DPI functions compete for common resources in the same platform, mobile operators have noted that when the embedded DPI function is activated, PGW performance drops off significantly. Performance degradation of 50% is quite common as the PGW struggles to maintain its core functions and to handle the additional DPI load. This is especially true in LTE environments, where the PGW is being asked to perform these additional functions at much higher speeds and on larger volumes of traffic than in 3G networks. Also, PGWs tend to incorporate many more network functions than their GGSN counterpart, leaving even fewer resources for DPI. The result is a PGW whose performance is compromised by the add-on functions.

Other considerations

There are many other considerations that come into play when comparing pure-play and embedded TDF, such as scalability, traffic steering and more. For example, the modular architecture of a pure-play TDF means you can start small and scale upward as needed whereas n the embedded TDF platform, the ability to expand within the same platform is quite constrained. At some point, the only way to expand is to deploy additional PGW equipment. This is an expensive proposition.

When comparing apples-to-apples, the pure-play TDF solution clearly provides superior functionality, performance and scalability over embedded solutions. It also may offer a lower total cost of ownership. But that’s only part of the story. The pure play versus embedded argument is really more like comparing apples to oranges because the embedded solution simply cannot compete with pure-play TDF in terms of unlocking new revenues through policy, charging and service enablement.

ABOUT AUTHOR