Two main forces are driving the explosion of mobile-network traffic. First, there’s the steady flow of technological changes in these networks, coupled with ever-evolving bandwidth speeds. Specifically, rates have grown from the early 1.8-, 3.6-, and 7.2-Mbit/s High Speed Packet Access (HSPA), to 21-Mbit/s HSPA+ and higher, to the soon-to-arrive 100-Mbit/s Long-Term Evolution (LTE). Second, bandwidth demands continue to soar due to the proliferation of wireless smart phones and devices and Internet video.

However, the average revenue per user (ARPU) remains flat or sees only incremental growth. More importantly, ARPU will maintain that pace well into the future. Thus, a solution is desperately needed to bridge the chasm today—and one that can evolve into the future.

Bottleneck Challenges

Demands for more bandwidth aren’t the only concern for engineers. There’s also the issue of traffic “burstiness” (Fig. 1). It can be summed up as follows:
• Data is much less predictable than voice traffic and much more bursty with massive traffic flows that can dwindle to nothing quickly (unlike the steady flow of voice).
• Service providers no longer have the luxury of predicting where and when they might see traffic growth.

Mobile-broadband data traffic runs between the user and the server at the application’s location. At any given time, many users reside on the same cell tower for business or personal Internet-related applications.

Continue on next page

The base transceiver station (BTS) at the cell tower is the first aggregation point, where users in the same coverage area come together. As a result, it also turns into the first bottleneck.

The second aggregation point is the basestation controller (BSC), radio network controller (RNC), or mobile switching center (MSC) . This is the first point of presence at the central office (CO), where it aggregates BTS traffic.

More aggregation points appear as we move up the network (Fig. 2, upper section). In general, the higher the aggregation points are located in the network, the greater the capacity. It’s also less likely that they will be affected by the bursty traffic, due to the law of large numbers and the nature of statistical multiplexing.

However, the greater the capacity of the aggregation point, the less visibility it has into the finer granularity of the traffic flow to recognize the problem and take effective action. That’s because these aggregation points are optimized for bulk traffic to save costs.

Since users generate the traffic demand, the closer the aggregation point is to the users, the more effective it is to detect the problem and correct it. As such, BTS is the closest to the users. It affords better visibility into the applications being used at the same BTS, which is highly subject to bursty traffic due to the law of small numbers. As such, BTS backhaul is the most effective point to address bursty traffic.

Continue on next page

While capacity must expand along the path for all aggregation points as traffic intensifies, it becomes another issue with bursty traffic, as it adds another order of magnitude to the capacity requirement. By addressing bursty traffic effectively, capacity can offer much greater bang for the buck (Fig. 2, again).

Solution Requirements And Options

These solutions come with two requirements. First, real-time recognition of the bursty traffic when it arrives and leaves the BTS is essential. Second, real-time action is mandatory to minimize the impact while maintaining quality of experience that’s superior to competitive providers.

Because users can have multiple applications with different levels of quality-of-service (QoS) requirements and subscription, one must be able to identify the traffic-flow behavior on a per-application and per-user basis. This requires the capability to perform real-time packet inspection deeper into sub-flows.

Once the traffic entering or exiting a bursty moment is identified, a real-time action can be taken to minimize the impact. Possible solution options include:
• Regulating and pacing the traffic on a per-user and per-application “as needed” basis based on its subscription profile or traffic behavior.
• Load balancing by using bandwidth from other under-utilized services when available temporarily.
• Offloading the Internet and “best effort” traffic to other less expensive transport vehicles while bypassing the equipment that offer premium QoS at a lower cost.

Solution Platform Requirements

A backhaul device has specific requirements:
• Real-time non-intrusive monitoring performed in hardware at wire speed.
• Packet inspection to recognize and identify the bursty traffic on a per-user and application basis.
• Programmable hardware, which delivers the flexibility to address evolving applications, and thus packet-inspection algorithms.
• Traffic offloading for Internet and “best effort” bursty traffic to other lower-cost transport vehicles, such as DSL, cable hybrid fiber coax (HFC), and passive optical network (PONs), wherever available at the BTS site. Furthermore, the alternative access network may also evolve over time. Therefore, a modular hardware and software platform is needed to accommodate the various access networks and their evolution.
• Traffic offloading to a separate network at the BSC/RNC/MSC site to bypass the network that offers stringent QoS to lower the overall cost.