Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Service Control Gateway Overview


This topic contains an overview of Service Control Gateway.

Service Control Gateway Feature Overview

The Service Control Gateway application resides on an MX Series router and is a subscriber-aware and application-aware service delivery network edge element, located between the gateway of the access network and the public network and network services, as shown in Figure 1.

Figure 1: Service Control Gateway
Service Control Gateway

Service Control Gateway enforces policy rules based on subscriber-awareness, application-awareness, and service data flow identification. Service Control Gateway provides services such as network address translation (NAT) and traffic load balancing as though they were provided directly on the access network gateway.

Service Control Gateway handles traffic from multiple types of access network gateways, providing access-independent subscriber-aware services in a converged manner for wireline and mobile access. Subscribers may be controlled by a broadband network gateway (BNG) in a wireline access network, by a gateway GPRS support node (GGSN) in a 2G or 3G network architecture, or by a Packet Data Network Gateway (PGW) in a 4G/LTE network architecture.

Service Control Gateway provides the following features and benefits:

  • Services such as application identification through deep packet inspection (DPI), HTTP header enrichment, traffic load balancing to servers, and NAT.

  • Support for subscriber-aware application-based policies by using enhanced policy and charging control (ePCC) rules.

  • Use of ePCC rules with policy and charging rules function (PCRF) servers that only support 3GPP standards prior to Release 11.

  • Support for subscriber-aware data-flow-based policies by using PCC rules.

  • Enforcement of PCC and ePCC rules that are received from a PCRF or that you configure on the Service Control Gateway.

  • Activation and deactivation of PCC and ePCC rules by a PCRF or a RADIUS server.

  • Static control of PCC and ePCC rules (no interaction with a PCRF or RADIUS server).

  • Redirection of subscriber flow toward external chained services or internal chained services (traffic steering).

  • Delivery of fixed-mobile convergence (FMC) services.

  • Reporting of application-start messages to the PCRF.

  • Reporting of revalidation timeout to the PCRF.

  • Logging and reporting subscriber session information to an external collector.

  • Reporting to a PCRF that a subscriber volume or time usage threshold has been exceeded.

  • Easy, quick, and cost-effective creation of personalized services.

  • Cost reduction of the value-added services LAN for the GGSN through optimal service orchestration.

Subscriber Setup

Before the Service Control Gateway can process data traffic based on subscriber-aware policies, it must set up a traffic detection function (TDF) subscriber session.

You can configure two types of TDF subscribers:

  • IFL-based—Subscriber sessions are initiated when you configure the subscriber and assign it a set of interfaces. All traffic that the Service Control Gateway receives on those interfaces shares the same IFL-based subscriber session.

  • IP-based—Subscriber sessions are initiated when the Service Control Gateway processes a RADIUS accounting start request for a potential subscriber from a GGSN, PGW, or BNG. An IP-based subscriber session is for one unique user IP address.

    Service Control Gateway examines the attribute-value pairs (AVPs) of the RADIUS accounting request (for example, the 3GPP International Mobile Subscriber Identity (IMSI) or the IPv4 address of the subscriber) and determines whether to create a subscriber session and whether to use dynamic policy control, static policy control, or RADIUS server policy control for the session. These decisions are based on the Service Control Gateway configuration.

Policy Enforcement

Service Control Gateway enforces PCC rules and ePCC rules based on the subscriber identity for the traffic. A PCC rule or ePCC rule specifies the actions to take on packets that match a particular condition.

A PCC rule identifies a service data flow (SDF) filter that the packet must match. An SDF filter can specify:

  • Source or destination addresses, subnets, and ports

  • Flow direction

  • Protocol

An ePCC rule identifies an application or group of applications that the packet must match. Service Control Gateway uses ePCC rules because 3GPP ADC rules are not supported by PCRFs that only support 3GPP standards prior to Release 11.

PCC or ePCC rule actions can include:

  • Redirecting HTTP traffic to a URL or to an IP address (ePCC rules only)

  • Forwarding packets to a routing instance (ePCC rules only) so that packets are directed to external chained services

  • Setting the forwarding class

  • Setting the maximum bit rate

  • Performing HTTP header enrichment (ePCC rules only)

  • Setting the gating status to blocked or allowed

PCC rules and ePCC rules for a subscriber are under either dynamic control, static control, or RADIUS server control, depending on the configuration you have created.

With dynamic control, PCC rules and ePCC rules are controlled by the PCRF. The PCRF either provisions the rules and sends them to Service Control Gateway in a Diameter message or sends a message to activate a rule that you have configured on Service Control Gateway. The PCRF uses the Gx interface to send Diameter messages to Service Control Gateway. Diameter AVPs that are unique to Service Control Gateway are described in Juniper Networks Diameter AVPs for Subscriber Aware Policy Control.

With RADIUS server control, you must configure rules on Service Control Gateway, and the RADIUS server activates and deactivates the rules.

With static control, the provisioning of rules and their activation and deactivation is controlled only by your configuration of the Service Control Gateway.

Application Identification

Application identification on Service Control Gateway performs DPI to determine whether the subscriber’s data packets match an application signature. This signature identifies the application that is being used. Juniper Networks provides a set of predefined application signatures that you can download.

You can also configure custom application signatures by defining:

  • Source or destination IP address or port

  • Type of ICMP messages

  • IP protocol

  • Layer 7 contexts such as HTTP and SSL that are further differentiated for stream contexts by the Layer 4 protocol type

After Service Control Gateway identifies an application for a subscriber’s traffic, it applies any matching ePCC rule to the traffic.

Service Control Gateway can also alert the PCRF that the subscriber has started using an application.

HTTP Header Enrichment

Service Control Gateway supports HTTP header enrichment. Subscribers accessing Web-based services often need to have content added to the HTTP headers sent back and forth as part of the client-server exchange. HTTP header enrichment adds information to HTTP headers, such as the subscriber MSISDN number.

You can configure HTTP header enrichment actions and assign them to the actions in an ePCC rule.

Service Selection

Service Control Gateway can use PCC and ePCC rules to redirect, or steer, a subscriber’s traffic to a third-party server to apply a service chain. The rule identifies a routing instance to apply to the traffic. You can configure different routing instances for traffic from the subscriber (uplink) and traffic to the subscriber (downlink).

Traffic Load Balancer

The Traffic Load Balancer (TLB) distributes traffic among multiple next-hop servers. TLB supports hash-based load balancing or random load balancing.

TLB performs health monitoring to verify that all the servers are available. TLB supports ICMP, TCP, HTTP, SSL Hello, and custom health check probes to monitor the health of servers in a group. When TLB discovers that a server is down, flows are steered to other servers until the server comes back up.

TLB provides application stickiness, meaning that server failures or changes do not affect traffic flows to other active servers.

TDF Subscriber Data Session Logging and Reporting

The logging and reporting function (LRF) logs data for TDF subscriber data sessions and sends that data in an IPFIX format to an external log collector using UDP-based transport. These data session logs can include subscriber information, application information, HTTP metadata, data volume, time-of-day information, and source and destination details.

The external collector, which is not a Juniper Networks product, may then use this data to perform analytics that provide you with insights about subscriber and application usage, allowing you to create packages and policies that increase revenue.

Subscriber Use Monitoring

For TDF subscribers that are under dynamic policy control, the Service Control Gateway can monitor the volume of traffic or amount of time the subscriber uses during a session, and send reports to the PCRF when a threshold is exceeded or when the PCRF requests a report. Subscriber monitoring can be for individual or multiple data flows or applications that appear in specific PCC or ePCC rules, or can be for the entire subscriber session.

Inter-Chassis Stateful Synchronization for Carrier-Grade NAT

Carrier-grade NAT (CGN) deployments can use dual-chassis implementations to provide a redundant data path and redundancy for key components in the router. Only long-lived flows are synchronized between the master and backup chassis in the high availability pair. NAT44 is the only translation type supported.

Service PICs and Session PICs

You must configure at least one service PIC and one session PIC on Service Control Gateway. Service PICs and session PICs use service interfaces on the Multiservices Modular PIC Concentrator (MS-MPC). A service PIC and a session PIC may use the same MS-MPC or different MS-MPCs. A Service Control Gateway configuration and other existing configurations cannot run on the same MS-MPC.

A session PIC supports access subscriber session setup and management and selects the service PIC for data processing. A session PIC also sets up a session with the PCRF or RADIUS policy server if one is being used. A session PIC is loaded with subscriber management software to perform these functions.

A service PIC provides application-aware and subscriber-aware policy enforcement and traffic steering. A service PIC is loaded with software plugins to perform the configured or requested services.

You can configure a service PIC or a session PIC as an individual PIC or with a backup for redundancy. You configure redundancy by including the primary and backup service interfaces in an aggregated multiservices (AMS) interface and specifying the AMS when configuring a service PIC or session PIC.