Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 

Understanding the Need for Services Control Gateway

 

The network edge is also considered a network element, which is aware of distinct subscriber sessions, and therefore it is typically responsible for the following operations:

  • Access protocol termination (for example, DHCP, PPP, L2VPN, L3VPN, VPLS, GTP)

  • Subscriber authentication (for example, RADIUS AAA, DIAMETER AAA)

  • Traffic aggregation and policing (for example, QoS, shaping, steering)

Typically, the tasks above are dependent on the access technology being used and, therefore, the subscriber experience is not consistent across the multiple devices utilized as operators leverage completely independent systems to control such NEs. Products such as a BNG (Broadband Network Gateway - terminating wireline broadband subscribers using protocols such as DHCP and PPP and Provider Edge – terminating wireline business users using protocols such as L2VPN, L3VPN and VPLS) are typically utilizing variations in protocols for subscriber authentication and, policy control, which are quite different from products such as MBG (GGSN/PGW - terminating wireless broadband subscribers using protocols such as GTP). The variations between these two applications is partially driven by different market forces, and different legacy deployment scenarios. The primary need and demand for fixed-mobile convergence (FMC) requires that not only the subscriber experience be consistent across accesses, but also that it is delivered with minimal operating costs. This demand for convergence is really coming along as wireless access performance (both throughput and latency) has gained ground to be on par with typical broadband usage, as well as the drive from operators who are optimizing their data services to provide a more access agnostic experience to their end customers.

Network operators, both fixed (Internet Service Providers [ISPs]) and mobile (Mobile Network Operators [MNOs]), understand that the delivery of services (aka the service layer) is their opportunity for differentiation and, therefore, for attracting subscribers, retaining them, and driving new service offerings which can be monetized in new and creative ways.

In well-established networks, the PE, BNG and/or GGSN (and even PGW in LTE networks) are largely legacy network devices which are often incapable of delivering the new services which the operator is demanding to remain relevant as a service provider. However, replacing such devices is not always viable or commercially feasible for the operator or for Juniper Networks. Often, the operator cites substantial difficulty operationally to replace these network elements.

In some scenarios, a single operator, who has a wireline and a wireless operation, has partitioned the ongoing operations, planning, and procurement of these domains. However, in the interest of driving a consistent set of service offering, charging methods for broadband access regardless of wireline or wireless access transport, the telecommunication union has unified these through standardized Policy and Charging Rules Function (PCRF) and Online Charging System (OCS) systems. While these PCRF and OCS can interoperate with these existing deployments of GGSN and of BNG (in different, but yet similar fashion), the integration of those legacy devices (GGSN and BNG) with the new PCRF and OCS has proven less than an easy task.

Taking into consideration all the above factors, Third-Generation Partnership Project (3GPP) introduced the concept of a Traffic Detection Function (TDF), which is a service delivery NE typically placed in the routing path of the GGSN and/or BNG (and therefore handling plain IP traffic) and controlled by the PCRF. Because the TDF is access-independent, it can deliver subscriber-aware services in a converged manner for fixed and mobile access. Indeed, a TDF can be positioned in routing path of sessions established over WiFi and thus unify the services and policy enforcement offered to WiFi access as well.

Majority of the wireline residential service providers are still using RADIUS as a way to dynamically provision, manage, control, collect stats for both subscribers and subscriber-aware services. These wireline service providers have spent heavy investment in integrating their RADIUS servers with their backend OSS/BSS systems as well. To serve this wireline segment of the market it is critical to offer our service solution to support the north-bound provisioning and control systems. Apart from RADIUS, some wireline service providers are also embracing the PCRF for service provisioning, but wants a variant of Gx interface that takes care of the nuances of wireline environment. Juniper Networks currently supports a non-standard Gx-Plus interface for BNG and also actively working within BBF (Broadband Forum) to standardizing it.

Services Control Gateway offers subscriber-aware services, which mostly overlaps with value-added services (VAS). VAS also interchangeably refers to subscriber-aware services. A consolidation of the various VASs is designed to enable them to be applicable for both fixed-line and mobile deployments. It also expands, by integrating with the Junos V App Engine (JVAE) Enhanced Data Plane (EDP) and Junos Content Encore (JCE), to function as a platform for service delivery encompassing Juniper Networks devices and third-party platforms. Services Control Gateway operates as an application-aware (Layer 7) element and, therefore, both Deep Packet Inspection (DPI) and Shallow Packet Inspection (SPI – Layer 4) become an integral part of its functionality.