Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

3GPP Policy and Charging Control for Wireline Provisioning and Accounting

3GPP Policy and Charging Control Overview for Wireline Provisioning and Accounting

The 3rd Generation Partnership Project (3GPP) Policy and Charging Control (PCC) provides the unification of wireline provisioning and accounting for customers. Figure 1 shows the components of an overall 3GPP PCC architecture.

Figure 1: 3GPP PCC Architecture Overview3GPP PCC Architecture Overview

The four major components of the PCC architecture are:

  • Policy and Charging Rules Function (PCRF)—A centralized policy decision point that deploys business policy and charging rules to allocate broadband network resources and manages flow-based charges for subscribers and services. PCRF pushes the rules down to the Policy and Charging Enforcement Function (PCEF) using the 3GPP Gx protocol and online policy interface.

  • Policy and Charging Enforcement Function (PCEF)—A function that provides user traffic handling and QoS at the gateway, provides service data flow detection, and applies the rules received from the PCRF. PCEF optionally interacts with the Online Charging Function (OCF) within the Online Charging System (OCS) using the 3GPP Gy protocol to retrieve policy and charging authorization for quotas and credit control.

  • Online Charging System (OCS)—The component responsible for interacting with the PCEF. The PCEF optionally reports usage and receives additional authorizations from the OCS using the 3GPP Gy protocol. Broadband PCEF (BPCEF) interactions with the OCS use online session charging with centralized unit determination and centralized rating.

  • Offline Charging System (OFCS)—A process where charging information for network resource usage is collected concurrently with that resource usage. If credit-based authorization is not required, the PCEF applies policies and report usage to the OFCS using the 3GPP Gz protocol. You can also use the OCS as the primary accounting destination and use the OFCS as a backup.

Table 1 lists the functionality differences between PCRF and PCEF.

Table 1: Functionality Comparison Between PCRF and PCEF

Functionality

PCRF

PCEF

Charging policing implementation

Involved at different levels; aggregates information inside the hosting network and is considered part of the PCC architecture.

Involved at different levels; located at the gateway.

Functions included

Includes mainly policy control decision and flow-based control functions.

Includes policy enforcement and flow-based charging functions.

Predefined PCC rules

Activation or deactivation of predefined PCC rules can only be done by the PCRF.

Preconfigured by the PCEF.

Online and offline charging interactions

Not supported

Supported

The three other components that make up the PCC architecture in Figure 1 are:

  • Application Function (AP)—The Application Function interacts with applications or services that require dynamic PCC. The Application Function extracts session information from the application signalling and provides application session-related information to the PCRF using the Rx protocol.

  • Subscription Profile Repository (SPR)—SPR contains subscriber and subscription information on a per-packet data network (PDN) basis. The Sp protocol enables the PCRF to request subscription information related to a subscriber's service or session.

  • Bearer Binding and Event Reporting Function (BBERF)—The PCC rule needs to be mapped to a particular IP bearer to ensure the packets receive the appropriate QoS treatment. The association between a PCC rule and a bearer is referred to as bearer binding. The BBERF location depends on the access technology. For 3GPP, the BBERF is located in the serving gateway and uses the Gxx protocol.

Benefits of 3GPP Policy and Charging Control Architecture

  • Provides a unified framework for wireline subscriber provisioning and accounting.

Policy and Charging Enforcement Function Overview for Broadband Wireline Subscribers

The Policy and Charging Enforcement Function (PCEF) is one of four major components of the 3rd Generation Partnership Project (3GPP) Policy and Charging Control (PCC) architecture in Figure 2.

Figure 2: 3GPP PCC Architecture Overview3GPP PCC Architecture Overview

PCEF provides user traffic handling and quality of service (QoS) at the gateway, provides service data flow detection, and applies the rules received from the Policy Control and Charging Rules Function (PCRF). 3GPP defines Gx as the online policy protocol between the PCRF and the PCEF to provide control over policy and flow-based charges for subscribers. The PCRF is a centralized policy decision point that deploys business policy rules to allocate broadband network resources and manages flow-based charges for subscribers and services. Optionally, the PCEF interacts with the Online Charging System (OCS) using the 3GPP Gy protocol to retrieve policy and charging authorization for quotas and credit control.

PCEF provides support for the following environments:

Wireline Access Environment

For mobile subscribers, the user equipment requests services; for broadband wireline subscribers, the PCRF requests services. In the wireline environment, PCRF functions as the service requester, and the PCEF functions as the service receiver and enforcer.

Adapting the PCC model in a wireline environment provides these benefits:

  • Convenience

  • Advanced technology

  • Already implemented by the wireless branch of the carrier that often provides a much bigger business than the wireline branch

The PCRF controls the PCEF by pushing charging rules. Charging rules are reused as service (policy) rules to push policies. Charging rules may also have an associated rating group, or charging key. As a result, the PCEF configuration must define charging rules and mapping between credit control services (cc-services) and rating groups.

In many instances, both OCS and Offline Charging System (OFCS) 3GPP accounting services require Mobile Station International Subscriber Directory Number (MSISDN) be used for subscriber identification. The MSISDN is passed as the subscription ID. While each mobile user equipment device has an associated MSISDN, this information is not available for wireline subscribers. To enable the PCRF to dynamically pass subscription-ID parameters, and support a variety of authentication, authorization, and provisioning configuration, the Juniper attribute-value pairs (AVPs) in Table 2 have been allocated from the Juniper Vendor-ID space (2636) vendor-specific attribute (VSA).

Note:

If no dynamic-subscription ID is received, then neither OCS or OFCS communications are initiated.
Table 2: Allocated Juniper AVPs

AVP Name

Vendor-ID

AVP Type

Diameter Type

Diameter Flag

Juniper-Dyn-Subscription-Indicator

2636

10001

Enum

V

Juniper-Dyn-Subscription-Id

2636

10002

Grouped

VM

Juniper-Dyn-Subscription-Id-Type

2636

10003

Integer32

VM

Juniper-Dyn-Subscription-Id-Data

2636

10004

UTF8String

VM

The client system (router) sends the Juniper-Dyn-Subscription-Id-Indicator AVP to indicate support of the dynamic assignment of the subscription ID. The Juniper-Dyn-Subscription-Id-Indicator attribute has two values:

  • DYN_SUBSCRIPtION_NOT_SUPPORTED (0)

  • DYN_SUBSCRIPTION_SUPPORTED (1)

The server then sends the Juniper-Dyn-Subscription-Id AVP to the client that indicated support. This is a grouped AVP that contains the values to be sent as Subscription-Id-Type and Subscription-Id-Data.

Note:

  • The PCRF server may use standard Subscription-Id AVP to communicate the dynamic-subscription ID to the router.

  • If both Juniper-Dyn-Subscription-Id and Subscription-Id are sent by the PCRF, the Subscription-Id value is used.

In many cases, wireline subscribers support only one IP family, which is required information for both AAA service and PCRF. To indicate this information, the Juniper-Network-Family-Indicator AVP has been allocated from the Juniper Vendor-ID space (2636) VSA in Table 3.

Table 3: Family Indicator AVP

AVP Name

Vendor-ID

AVP Type

Diameter Type

Diameter Flag

Juniper-Network-Family-Indicator

2636

10010

Enum

V

The client system (router) sends the Juniper-Network-Family-Indicator AVP to indicate which network families are associated with the service request and supported by the subscriber. When you configure the Juniper-Network-Family-Indicator AVP to indicate the associated network family, the system sends the information to the PCRF. The Juniper-Network-Family-Indicator attribute has four values:

  • UNSPECIFIED (0)

  • IPV4_FAMILY (1)

  • IPV6_FAMILY (2)

  • IPV4_IPV6_FAMILY (3)

Wireline customers often control user services solely through the PCRF and use the OCS as a convenient real-time usage monitoring mechanism rather than as an enforcement unit. To decrease the number of possible erroneous OCS configurations, include the force-continue statement at the [edit access ocs partition partition-name] hierarchy level to force the broadband PCEF (BPCEF) to limit the impact of negative responses from the OCS and quota expirations, and to prevent sending OCS notifications for affected rating-groups. Whenever the PCEF receives a negative response to any reported group, it stops reporting this group to the OCS.

Junos OS Environment

There are three categories of dynamic-profiles within the Junos OS environment:

  • client-dynamic-profiles

  • cos-service-dynamic-profiles

  • firewall-service-dynamic-profiles

Client-dynamic-profiles and cos-service-dynamic-profiles define bandwidth and other characteristics of the services provided to a subscriber; the firewall-service-profiles perform filtering and usage counting. For all of the dynamic-profiles’ categories, the service-dynamic-profile name is used as the value of a Charging-Rule-Name AVP.

When the service-dynamic-profile has no variables, or when defaults provided in service-dynamic-profile definition are requested, no additional elements are required. To provide custom values for a service-dynamic-profile, use the Charging-Rule-Definition AVP with additional VSAs.

The PCRF uses existing Juniper-Substitution VSAs (Vendor-ID 2636 and Type 2024) to supply attributes as a name-value pairs. The PCRF may also include parameters as positional notation for part of the rule name. The Redirect-Information AVP (Vendor-ID 10415 and Type 1085) supplies a value for the Redirect-URL parameter.

For every possible service-dynamic-profile parameter name requested by customers, a new Juniper-Parameter VSA is defined. Table 4 describes the initial set of fixed Juniper-Parameter VSAs.

Table 4: Initial Set of Fixed Juniper-Parameter VSAs

Parameter

VSA Name

Vendor-ID

Type

Diameter Type

Cos-Tcp

Juniper-Param-Cos-Tcp

2636

10005

UTF8String

V4-Firewall-Input-Filter

Juniper-Param-V4-Firewall-Input-Filter

2636

10006

UTF8String

V4-Firewall-Output-Filter

Juniper-Param-V4-Firewall-Output-Filter

2636

10007

UTF8String

V6-Firewall-Input-Filter

Juniper-Param-V6-Firewall-Input-Filter

2636

10008

UTF8String

V6-Firewall-Output-Filter

Juniper-Param-V6-Firewall-Output-Filter

2636

10009

UTF8String

If parameters or the Service-Identifier and Rating-Group are required to be indicated by the PCRF, the Charging-Rule-Definition AVP is used; otherwise, the Charging-Rule-Name AVP is used.

For instances when there is a Service-Identifier and Rating-Group combination, or when only the Service-Identifier or only the Rating-Group is specified, the combination must be unique among the rules installed for a subscriber. You configure the service-context-id on the router.

Understanding Gx Interactions Between the Router and the PCRF

The sequences of Diameter messages are exchanged by means of the 3rd Generation Partnership Project (3GPP) Gx protocol between the Policy Control and Rules Charging Function (PCRF) and the router acting as a Policy and Charging Enforcement Function (PCEF).

Starting in Junos OS Release 17.3R1, support for additional OCS and PCRF features are added using Gy and Gx protocols. The new statements:

  • accept-sdr is added for PCRF partition at the hierarchy level [edit access pcrf partition partition-name].

  • alternative-partition-name is added for OCS partition at the hierarchy level [edit access ocs partition partition-name].

They interact to perform the following subscriber access tasks:

Subscriber Login

The router sends a Diameter CCR request containing a fixed set of required information to a policy manager (PCRF) and receives a CCA response containing policies and other information. Gx provisioning is enabled for subscribers when you include the provisioning-order pcrf statement at the [edit access profile profile-name] hierarchy level. When an application requests AAA to activate the subscriber's session, the router sends a CCR-GX-I (where I represents INITIAL_REQUEST) message to the PCRF to request a fix set of provisioning information for the subscriber session, and receives a CCA-GX-I response message containing policies and other information, including the Result-Code AVP (AVP code 268).

When you configure the provisioning-order statement in the access profile, the broadband PCEF (BPCEF) module sends a provisioning request to the PCRF during the client activation. The following examples show a CCR-GX-I and CCA-GX-I packet exchange:

CCR-GX-I Packet Example

Note:

The T (potentially retransmitted message) bit recalculates when the CCR-GX-I is resent. This flag is set after a link failover procedure to remove duplicate requests.

CCA-GX-I Packet Example

Note:

If no rule-install AVP is defined in the CCA-GX-I, then the default rule is installed.

All event triggers, including those not yet defined, are acceptable. However, only a few event triggers actually generate events when implemented.

The PCRF returns a CCA-GX-I message that includes the Result-Code AVP (AVP code 268) that maps to the result categories listed in Table 5.

Table 5: Result-Code-AVP Categories

Result-Code-AVP Value

Result Category

SUCCESS(2001), LIMITED_SUCCSS(2002), and valid message

Grant

AUTHENTICATION_REJECTED(4001), UNKNOWN_SESSION_ID(5002), AUTHORIZATION_REJECTED(5003), and USER_UNKNOWN(5030)

Deny

UNABLE_TO_DELIVER(3002), REALM_NOT_SERVED(3003), TOO_BUSY(3004), LOOP_DETECTED(3005), and REDIRECT_INDICATION(3006)

Failure

All other Diameter Permanent-failure Result-Code AVPs greater than and equal to 5000, and all Diameter protocol error Result-Code AVPs greater than and equal to 3000 and less than 4000

Permanent-failure

Other Result-Code AVPs for invalid message or no-response

Failure

As shown in Table 6, the CCA-GX-I response processing depends on three factors:

  • Whether the local decision timeout has expired

  • The setting of the local decision

  • The result category

Table 6 also contains PCRF local decision timeout expiration actions.

Table 6: CCA-GX-I Response Processing

PCRF Local Decision Timeout

PCRF Local Decision

Result Category

Action

Not-expired

–

Grant

Clear the local decision timer, apply rules from the CCA-GX-I, notify the Online Charging System (OCS), and then acknowledge subscriber activation.

Not-expired

–

Deny

Clear the local decision timer and fail subscriber activation.

Not-expired

–

Failure

Retry the CCA-GX-I until the local decision time outs.

Not-expired

Grant

Permanent-failure

Clear the local decision timer, apply the default rule, acknowledge subscriber activation, and then keep retrying the CCA-GX-I.

Not-expired

Deny

Permanent-failure

Fail the subscriber activation and initiate the subscriber logout process.

On-expiration

Grant

–

Apply the default rule, keep retrying the CCA-GX-I indefinitely, and acknowledge subscriber activation.

On-expiration

Deny

–

Fail the subscriber activation and initiate the subscriber logout process.

Expired

Grant

Grant

If the CCA-GX-I contains rules, remove the default rules and install the received rules, and then notify the OCS and acknowledge subscriber activation.

Expired

Grant

Deny

Log out the client.

Expired

Grant

Failure

Keep retrying the CCA-GX-I indefinitely.

Expired

Grant

Permanent-failure

Take a long pause and then restart retrying the CCA-GX-I.

Expired

Deny

Deny

If subscriber still logging out, ignore subscriber; otherwise, no action required.

A subscriber login initiates the following sequence of events:

  1. A client application—such as DHCP, PPP, or static subscriber sessions—requests AAA to authenticate the subscriber.

  2. Authentication begins if the subscriber access profile specifies RADIUS authentication. Login continues when the authentication is successful. Login fails when the authentication-order statement in the profile does not specify RADIUS authentication or no authentication. Login also fails when authentication fails.

  3. Default services are activated for the subscriber. Any services that the authentication server includes in the authentication grant are activated. Additionally, a default service may have been configured for the client application.

  4. If the subscriber access profile specifies Gx provisioning, the router initiates the Gx message exchange by sending a CCR-GX-I message to the PCRF. The router waits for the PCRF to respond with a CCA-GX-I message within a non-configurable timeout period.

    When the PCRF responds within the timeout period and includes the Charging-Rule-Install AVP in the CCA-GX-I message, subscriber login is delayed while the router deactivates any default services and attempts to activate the specified services.

    • If all the specified services are activated, then the login completes.

    • If any of the services cannot be activated, the router sends the PCRF a CCR-GX-U (where U represents UPDATE_REQUEST) message with the status of the services (a rule report). The PCRF responds to this message with a CCA-GX-U that can contain a new set of services for activation.

    • The router ignores any default services, even If the CCA-GX-I message does not include any services. In this circumstance, no services are activated.

    If the PCRF does not return a CCA-GX-I within the timeout period, subscriber login completes.

    • The router searches first for services returned from the authentication server and activates any it finds. If no such services are found, then the router activates any locally configured default services. Subscriber login completes when default service activation is successful, but fails when any default service fails to activate. Because default services are not required to be present, login also completes when no default services are found.

    • If login completes (with or without a default service), the router periodically resends the CCR-GX-I message to the PCRF. If the PCRF subsequently returns a CCA-GX-I, the router deactivates the default service, if any, and then activates any services included in the CCA-GX-I. If the message does not include any services, then no services are activated, not even a default service.

    • If any of the services contained in the CCA-GX-I cannot be activated, the router sends the PCRF a CCR-GX-U message with the status of the services (a rule report). The PCRF responds to this message with a CCA-GX-U that can contain a new set of services for activation.

Subscriber Login Error Recovery

Starting in Junos Release 20.1R1, you can configure the router to recover from certain PCRF server errors by reinitializing the subscriber session to resync the router and PCRF server states. Some PCRF servers might not properly handle a situation where the CCA-GX-I messages that it sent to the router are lost. When the router retries sending the CCR-GX-I to the PCRF, the server is out of sync with the router because it has already sent a reply and is not aware that the router did not receive the message. This mismatch in state can lead to either of the following errors:

  • The PCRF server responds to the retry with a CCA-GX-I that contains the Diameter Result Code AVP (Code 268) with a value of 5012 (DIAMETER UNABLE TO COMPLY). This is considered a permanent failure (Table 5).

  • The PCRF server sends a RAR. The server expects the session to be active because it sent the CCA-GX-I to the router and is unaware that the message was not received. The server might send any of the following RAR messages:

    • RAR-GX-D to disconnect the session because it considers the session to be bad

    • RAR-GX-A to read information about the bad session

    • RAR-GX-U to update the session because it considers the session to be operating normally.

You can use the PCRF local-decision configuration to reinitialize the subscriber session in response to either or both of those errors.

  • Include the reinit-on-failure option for the permanent failure error.

  • Include reinit-on-rar option for the RAR error.

Note:

The reinitialization operation has these additional configuration requirements:

  • You must configure the local decision grant option.

  • You must configure the router to use an extended session ID so that it can maintain state for the original session and the new one tied to the same login event. To do so, configure the PCRF use-session-stamp option.

The reinitialization operation consists of the following steps in both cases:

  1. The router sends a session termination request, CCR-GX-T, to the PCRF to terminate the session. This is done in an attempt to get the router and PCRF server to have the same state for this session.

  2. The router waits a reinitialization timeout period to receive a CCA-GX-T. You can use the reinit-timeout option to specify a period different than the default.

  3. If the router either receives a CCA-GX-T within the timeout period or a CCA-GX-T does not arrive before the timeout expires, then the router sends a CCR-GX-I to the PCRF with a new, extended session ID. The extended session ID is conveyed in the Diameter Session-ID AVP (AVP code 263).

    The router forms the extended session ID by appending a session stamp that consists of the UTC time when the router creates the CCR-GX-I. For example, consider the following Diameter Session-Id AVP. The session ID is 23 and use-session-stamp is not configured:

    With use-session-stamp configured, the session timestamp is appended to the AVP value:

Table 7 provides details about how the router reacts to these errors based on the current local PCRF state.

Table 7: Router Actions Based on Local PCRF State

Local State

Action When PCRF Error Occurs

local-active—Subscriber is active with default services.

The router does the following:

  • Transitions to the local-reinit state.

  • Sends a CCR-GX-T to the PCRF.

  • Starts the local-decision reinitialization timer and waits for the CCA-GX-T reply from the PCRF.

local-grant—Default service provisioning is in progress.

When the default provisioning completes, the router does the following:

  • Transitions to the local-reinit state.

  • Sends a CCR-GX-T to the PCRF.

  • Starts the local-decision reinitialization timer and waits for the CCA-GX-T reply from the PCRF.

started—The local-decision timer is still running.

The router does the following when no default services are configured:

  • Transitions to the local-reinit state.

  • Sends a CCR-GX-T to the PCRF.

  • Starts the local-decision reinitialization timer and waits for the CCA-GX-T reply from the PCRF.

The router does the following when default services are configured:

  • Transitions to the local-reinit-early state.

  • Start provisioning the default services.

When the default provisioning completes, the router does the following:

  • Transitions to the local-reinit state.

  • Sends a CCR-GX-T to the PCRF.

  • Starts the local-decision reinitialization timer and waits for the CCA-GX-T reply from the PCRF.

Subscriber Update

Whenever a trigger event occurs on the router, an update request is sent to the PCRF. The following examples show a CCR-GX-U (where U represents UPDATE_REQUEST) and CCA-GX-U packet exchange:

CCR-GX-U Packet Example

Note:

The T bit recalculates when the CCR-GX-U is resent.

CCA-GX-U Packet Example

The PCRF returns a CCA-GX-U message that includes the Result-Code AVP (AVP code 268) that maps to the result categories listed in Table 8.

Table 8: Result-Code-AVP Categories

Result-Code-AVP Value

Result Category

SUCCESS(2001), LIMITED_SUCCSS(2002), and valid message

Success

UNABLE_TO_DELIVER(3002), REALM_NOT_SERVED(3003), TOO_BUSY(3004), LOOP_DETECTED(3005), and REDIRECT_INDICATION(3006)

Failure

All other Diameter Permanent-failure Result-Code AVPs greater than and equal to 5000, and all Diameter protocol error Result-Code AVPs greater than and equal to 3000 and less than 4000

Success

Other Result-Code AVPs for invalid message or no-response

Failure

Subscriber Logout

When the client application sends a subscriber logout notice to AAA, Gx sends a CCR-GX-T (where T represents TERMINATION_REQUEST) message to notify the PCRF that the provisioned subscriber session is being terminated.

Whenever a trigger event occurs on the router, a terminate request is sent to the PCRF. The following examples show a CCR-GX-T and CCA-GX-T packet exchange:

CCR-GX-T Packet Example

Note:

The T bit recalculates when the CCR-GX-T is resent.

CCA-GX-T Packet Example

The PCRF returns a CCA-GX-T message that includes the Result-Code AVP (AVP code 268) that maps to the result categories listed in Table 9.

Table 9: Result-Code-AVP Categories

Result-Code-AVP Value

Result Category

SUCCESS(2001), LIMITED_SUCCSS(2002), and valid message

Success

UNABLE_TO_DELIVER(3002), REALM_NOT_SERVED(3003), TOO_BUSY(3004), LOOP_DETECTED(3005), and REDIRECT_INDICATION(3006)

Failure

All other Diameter Permanent-failure Result-Code AVPs greater than and equal to 5000, and all Diameter protocol error Result-Code AVPs greater than and equal to 3000 and less than 4000

Success

Other Result-Code AVPs for invalid message or no-response

Failure

If the Result-Code value is Success, Gx notifies AAA, and AAA notifies the application that the logout is complete. If Gx does not receive a CCA-GX-T message, or if the Result-Code AVP has any other value or is missing, then the termination request is retried until the CCA-GX-T message is returned with Success. The router notifies the PCRF about subscriber logouts by sending another CCR request to be acknowledged by a CCA response. The PCRF may also use RAR requests to force subscriber logout or to change applied services.

If the Result-Code value is Failure, then the request is retried.

Subscriber Disconnect

To perform subscriber disconnects, the PCRF sends a RAR-GX-D (where D represents DISCONNECT) and the BPCEF responds with a RAA-GX-D message.

The following examples show a RAR-GX-D and RAA-GX-D packet exchange:

RAR-GX-D Packet Example

RAA-GX-D Packet Example

The PCRF returns a RAA-GX-T message that includes the Result-Code AVP (AVP code 268) that maps to the result categories listed in Table 10.

Table 10: Result-Code-AVP Categories

Result-Code-AVP Value

Result Category

DIAMETER_SUCCESS(2001)

Subscriber disconnect is in progress or the subscriber is not found

DIAMETER_UNABLE_TO_COMPLY(5012)

Subscriber is not removable

DIAMETER_TOO_BUSY(3004)

Too many outstanding disconnect requests
Note:

The BPCEF contains buffering space for at least 512 RAR-GX-D or RAA-GX-D messages.

Connectivity Fault Recovery

Gx does not rely on the connection state between devices to detect router or PCRF outages, because some events do not affect the connection state and others are not detected when there is a Diameter relay or proxy between the devices.

To mitigate connectivity faults with the PCRF, the router uses the following fault recovery procedures:

  • If the PCRF is not available, and if you installed and configured a default service, the subscriber login proceeds accordingly.

  • Unacknowledged provisioning requests replay indefinitely or until the subscriber logs out.

  • Logout requests wait for the final OCS interrogation to complete, and then any unacknowledged logout requests replay for 24 hours.

  • The router uses standard Diameter transport redundancy to communicate with redundant PCRFs.

An important aspect of Gx fault tolerance is that subscriber login and termination requests are retried (replayed) 24 hours until a satisfactory response is received from the PCRF. You can issue the clear network-access pcrf subscribers command to clear all PCRF subscribers.

Understanding Gy Interactions Between the Router and the OCS

Information or interrogations are exchanged by means of the 3rd Generation Partnership Project (3GPP) Gy protocol between the Online Charging System (OCS), and the router acting as a Policy and Charging Enforcement Function (PCEF). Broadband PCEF (BPCEF) interactions with the OCS use online session charging with centralized unit determination and centralized rating. PCEF optionally reports usage and receives additional authorizations from the OCS using the Gy protocol.

Starting in Junos OS Release 17.3R1, support for additional OCS and PCRF features are added using Gy and Gx protocols. The new statements:

  • accept-sdr is added for PCRF partition at the hierarchy level [edit access pcrf partition partition-name].

  • alternative-partition-name is added for OCS partition at the hierarchy level [edit access ocs partition partition-name].

Starting in Junos OS Release 18.1R1, broadband PCEF provides the file backup for OCS data when both primary and alternative paths to the OCS are not available. The CCR-GY-T frames are stored in the files on remote location. The backup is supported at the hierarchy [edit access ocs partition partition-name].

After subscriber provisioning has been completed between the Policy Control and Rules Charging Function (PCRF) and PCEF, the router begins sending the following interrogations between the OCS and PCEF:

First Interrogation to the OCS

During the first interrogation, the router sends a Diameter CCR request containing a fixed set of required information to the OCS charging server. The OCS charging server then replies with validity-time, rating groups, and usage-quotas.

Note:

For this implementation phase, the router allows subscriber access without waiting for the OCS to respond, and the OCS always grants necessary quotas.

To configure a list of charging services to communicate information with the OCS over the Gy protocol, configure the charging-service-list ocs statement at the [edit access profile profile-name] hierarchy level. The following examples show a CCR-GY-I and CCA-GY-I packet exchange:

Note:

The T (potentially retransmitted message) bit recalculates when the CCR-GY-I is resent. This flag is set after a link failover procedure to aid the removal of duplicate requests.

CCR-GY-I Packet Example

CCA-GY-I Packet Example

Intermediate Interrogation to the OCS

After the router has sent a fixed set of required information to the OCS charging server, the OCS charging server replies with validity-time, rating groups, and usage-quotas. Validity-time and quota expirations trigger intermediate interrogation events.

Whenever a trigger event occurs on the router, an update request is sent to the OCS. The following examples show a CCR-GY-U (where U represents UPDATE_REQUEST) and CCA-GY-U packet exchange:

CCR-GY-U Packet Example

CCA-GY-U Packet Example

Final Interrogation to the OCS

When the client application sends a subscriber logout notice to AAA, Gy sends a CCR-GY-T (where T represents TERMINATION_REQUEST) message to notify the OCS that the provisioned subscriber is being terminated.

Whenever a trigger event occurs on the router, a terminate request is sent to the OCS. The following examples show a CCR-GY-T and CCA-GY-T packet exchange:

CCR-GY-T Packet Example

CCA-GY-T Packet Example

Connectivity Fault Recovery

Gy does not rely on the connection state between devices to detect router or OCS outages, because some events do not affect the connection state and others are not detected when there is a Diameter relay or proxy between the devices.

To mitigate connectivity faults with the OCS, the router uses the following fault recovery procedures:

  • If the OCS is not available, you can configure to allow subscriber traffic by setting the force-continue statement at the [edit access ocs partition partition-name] hierarchy level.

    Note:

    The force-continue statement is a required configuration statement.

  • Unacknowledged first and intermediate interrogations replay indefinitely or until the subscriber logs out.

  • Unacknowledged final interrogations replay for up to 24 hours.

  • The router uses standard Diameter transport redundancy to communicate with redundant OCSs.

  • You can configure transport redundancy events to trigger failures in application traffic.

An important aspect of Gy fault tolerance is that subscriber login and termination requests are retried (replayed) 24 hours until a satisfactory response is received from the OCS. You can issue the clear network-access ocs statistics command to clear all OCS statistics.

Abort Session Requests

The OCS may issue an ASR (Abort-Session-Request) when the receiving MX Series router collects final data and posts the final interrogation. After the MX Series router receives the response, it stops updating the OCS for the session involved.

Gy File Backup Overview

The Gy protocol, also known as OCS, is based on incremental usage reporting while retaining the intermediate data. Therefore, the OCS server includes multiple failure protection mechanisms such as diameter transport redundancy, alternative path to OCS, and file backup. Starting in Junos OS Release 18.1R1, broadband PCEF provides the file backup when neither primary nor alternative paths are available. The CCR-GY-T frames are stored in the files on remote location.

The OCS backup comes into effect when the OCS final-response-timeout expires. The data is queued for backup process and subscriber logout proceeds to pcrf session termination. In all cases, the backup operations are controlled by the following configuration parameters:

  • backup-limit—limit on the total number of backup entries. After the limit is reached, new subscriber’s login fails or oldest backup entries are dropped depending upon backup-overflow settings.

  • backup-timeout— timeout for backup operation.

  • backup-overflow—controls action when number of backup entries exceeds backup-limit.

OCS SFTP-Backup

The stfp-backup is the first backup mechanism implemented. The operations are controlled by the following parameters:

  • accumulation-timeout – The files are written after the file accumulation time of the first CCR-GY-T submission.

  • accumulation-count – The files are written after the number of requests are fulfilled for the file-account-count.

  • accumulation-size – The files are written after its size is reaches the accumulation size limit.

  • retry-interval – Every failed write operation is retried after this interval until backup-timeout is accumulated.

  • response-timeout – The timeout on individual sftp command response.

Note:

The OCS SFTP-Backup server is configured by its address, login, password, directory and file-prefix. A target directory exists by default, if not, the directory is created. If a target file with the same name already exists it will be overwritten.

Benefits of Gy File Backup

  • Provides yet another way to deal with instability of internal network.

Understanding Interactions Between the PCRF, PCEF, and OCS

The Policy and Charging Rules Function (PCRF), Policy and Charging Enforcement Function (PCEF), and Online Charging System (OCS) interact to provide and charge for subscriber services. These interactions include subscriber login, service updates to existing sessions, connection and monitoring, and subscriber termination and logout.

Figure 3 shows the components of an overall 3rd Generation Partnership Project (3GPP) Policy and Charging Control (PCC) architecture. The PCRF pushes the rules down to the PCEF on the MX Series router using the 3GPP Gx protocol. The PCEF provides service data flow detection, and applies the rules received from the PCRF. Optionally, the PCEF interacts with the OCS using the 3GPP Gy protocol to retrieve policy and charging authorization for quotas and credit control. Broadband PCEF (BPCEF) interactions with the OCS use online session charging with centralized unit determination and centralized rating.

Figure 3: 3GPP PCC Architecture Overview3GPP PCC Architecture Overview

The PCRF can also push changes to rules applied to an existing session. However, modifications to rating groups is not supported. You are also required to set the force-continue statement at the [edit access ocs partition partition-name] hierarchy level.

Login Interactions

This login sequence of events is triggered by detection of service data flow on the PCEF. This is typically a DHCP DISCOVER or PPPoE PADI packet sent by the subscriber (the CPE):

  1. The PCEF sends a CCR-GX-I to the PCRF with information identifying the subscriber.

  2. The PCRF replies with a CCA-GX-I to the PCEF with instructions on which rules to apply for the subscriber.

  3. The PCEF installs the requested services/rules for the subscriber.

  4. If OCS is being used, the PCEF sends the first interrogation to the OCS using a CCR-GY-I message, and the OCS sends applicable reports to the PCRF using a CCA-GY-I message.

    If configured, the PCEF sends a notification by means of a CCR-GX-U message to the PCRF after the requested services/rules are processed.

    • The rule is reported to the PCRF as inactive when both of the following are true:

      • The service-dynamic-profile instantiation fails.

      • Resource-Allocation-Notification (ENABLE_NOTIFICATION) is set for the charging rule.

      When the rule is reported as inactive, it does not affect subscriber login or other rules.

    • The rule is reported to the PCRF as active when all of the following are true:

      • The service-dynamic-profile instantiation succeeds.

      • Resource-Allocation-Notification (ENABLE_NOTIFICATION) is set for the charging rule.

      • The SUCCESSFUL_RESOURCE_ALLOCATION event trigger is set in the request.

    • The report is not sent when there are no rules to report.

  5. The PCRF replies back with a CCA-GX-U message.

  6. The PCEF activates the services for the subscriber.

Update Interactions

This update sequence of events is triggered by an RAR-GX-U message received by the PCEF from the PCRF.

  1. If the update request contains any installation or modification of rules with rating groups, then the PCEF rejects the request; otherwise, it acknowledges the request by sending an RAA-GX-U message to the PCRF.

  2. The PCEF starts the service removal and installation process.

  3. The PCEF waits for the service removal and installation process to complete, and if applicable, starts the final data collection process for reporting to the OCS. When the final statistics are collected, the PCEF sends a CCR-GY-U request to notify the OCS. This is a part of the removal process for an existing service in each of the following cases:

    • When the service being removed has a rating group.

    • When a new rule with a rating group was added.

    • When rules with a rating group were both removed and added.

  4. The PCEF sends applicable reports to the PCRF using a CCR-GX-U message.

    • The rule is reported to the PCRF as inactive when both of the following are true:

      • The service-dynamic-profile instantiation fails.

      • Resource-Allocation-Notification (ENABLE_NOTIFICATION) is set for the charging rule.

      When the rule is reported as inactive, it does not affect the update or other rules.

    • The rule is reported to the PCRF as active when all of the following are true:

      • The service-dynamic-profile instantiation succeeds.

      • Resource-Allocation-Notification (ENABLE_NOTIFICATION) is set for the charging rule.

      • The SUCCESSFUL_RESOURCE_ALLOCATION event trigger is set in the request.

    • The report is not sent when there are no rules to report.

Quota Expiration and Validity-Time Interactions

For quota expirations and validity-time interactions, the router sends an intermediate interrogation to the OCS using a CCR-GY-U message and processes the OCS response.

Connection and Monitoring Interactions

When establishing a connection with the PCRF, OCS, or Diameter Relay/Proxy server, the Diameter daemon performs a standard Capability Exchange Request (CER)/Capability Exchange Answer (CEA) transaction. You use existing Junos OS Diameter infrastructure to configure an appropriate topology with the necessary redundancy features. Additionally, you can use the same Diameter connection for both PCRF and OCS communications, and other applications.

The following examples show two different communication connection scenarios:

CER Example with a Dedicated Connection Used to Communicate with the PCRF

Note:

If you set the send-origin-state-id statement for the router at either the [edit access pcrf partition partition-name] or [edit access ocs partition partition-name] hierarchy level, then the Origin-State-Id is included in Diameter level messages such as: CER, Device Watchdog Request (DWR)/Device Watchdog Answer (DWA), and Disconnect Peer Request (DPR)/Disconnect Peer Answer (DPA).

CER Example with a Dedicated Connection Used to Communicate with Both PCRF and OCS

Note:

The Auth-Application-Id: 4 field and value is the authentication application ID for the OCS. This is the difference between the first and second examples.

You monitor and manage connections using standard DWR/DWA and DPR/DPA messages.

Logout Interactions

This logout sequence of events is triggered by either of the following:

  • A subscriber logout request, such as a DHCP RELEASE or PPPoE PADT packet.

  • The PCEF receives a RAR from the PCRF with a request to terminate a subscriber session.

The following sequence occurs when the logout is triggered:

  1. The system infrastructure notifies the OCS that the subscriber logout has started.

  2. If applicable, the OCS starts the final data collection process.

    • If the service being removed has a rating group, final data for this service is required to be reported. The OCS starts final data collection as necessary.

  3. Both the PCRF and the PCEF wait for the final interrogation process to complete.

  4. The PCEF sends a termination request (CCR-GX-T message) to the PCRF and then waits for the answer (CCA-GX-T message) from the PCRF.

  5. The PCEF completes the subscriber logout process.

Understanding Upstream and Downstream Messages for the PCRF

The MX Series router implements a number of measures to protect against data overload for both downstream and upstream transactions. Downstream transactions are protected by throttling input from the network under overload conditions. The upstream transactions are protected by limiting both the number of outstanding requests and using slow retries of the first unacknowledged message for a reliable recovery.

Built-in features of the Policy and Charging Enforcement Function (PCEF) environment provide protection from overload resulting from an excessive subscriber login rate. If there are too many rule changes and disconnect operations due to Reauthorization Request (RAR-GX) messages, the router sends a Reauthorization Answer (RAA-GX) response with the result-code: DIAMETER_TOO_BUSY (3004).

Within the router’s AAA component, a session represents a subscriber (client) session entry in the Session Database (SDB).

Note:

This is a representation of subscriber session only; it is not a connection-independent permanent identifier similar to a phone number. If subscriber disconnects and reconnects, and it receives a different session ID for the second connection.

The session ID is conveyed in the Session-Id (AVP Code 263). There is a one-to-one correspondence between a session and the Session-Id value. The session ID is globally and eternally unique because it is bound to the unique router identity and used to identify a user session without any reference to other information. The same subscriber could be mapped to several sessions, such as one from a disconnect and reconnect event. However, the session is always associated with a single subscriber. The Session-Id AVP has the following default format:

The DiameterIdentity field is the value you configure for the Diameter origin-host. Internal Session-Ids are 64-bit integers assigned in ascending order. Both numeric parts of the Session-Id string are generated using %010u format, which guarantees that Session-Id AVP values are in the same order lexicographically as internal 64-bit sessions.

You can also configure the router to use an extended session ID, where it appends a session stamp to the ID. The session stamp consists of the UTC time when the router creates the CCR-GX-I. In this case, the Session-Id AVP has the following format:

The first 64 bits of the AVP remain unchanged, enabling the PCRF to trace reinitializations.

You always configure the router to use the extended session ID when it reinitializes the session in response to PCRF server errors. See Understanding Gx Interactions Between the Router and the PCRF for more information.

The Policy and Charging Rules Function (PCRF) pushes rules and messages down to the PCEF using the 3GPP Gx protocol and online policy interface. The PCRF and Gx protocol include the following messages:

Common Upstream Messages

The upstream messages for Credit Control Response for Initiation, Update, and Termination (CCR-GX-I, CCR-GX-U, and CCR-GX-T) and RAA-GX may include the following rules, parameters and data:

Event-Timestamp AVP

The following shows an AVP for CCR-GX-I, CCR-GX-U, and CCR-GX-T, and RAA-GX messages between the PCRF and Gx:

If you configure the Event-Timestamp AVP, it is included in the downstream message. The message definition in Table 11 varies depending on the transaction.

Table 11: Event-Timestamp AVP Message Definition

Message

Definition

CCR-GX-I

Subscriber login timestamp

Charging Rules Installation Notifications

The following notifications show a failed installation example and a successful installation example of charging rules installation for CCR-GX-U messages between the PCRF and Gx:

Note:

If unacknowledged reports are still pending at the time of the client logout, these charging rules are included in CCR-GX-T messages.

Notification Reporting a Rule Installation Failure

Notification Reporting a Rule Installation Success

Event Trigger Commands

The following shows a predefined event trigger command for CCR-GX and RAA-GX messages between the PCRF and Gx:

Common Downstream Messages

The downstream messages for Credit Control Answer for Initiation and Update (CCA-GX-I and CCA-GX-U) and RAR-GX may include the following predefined rules with parameters and data:

Note:

The CCA-GX-T (Termination) message is not included as a downstream message.

Charging Rule Installation Commands

The following example shows predefined rule installation commands for CCA-GX and RAR-GX messages between the PCRF and Gx:

Note:

Some PCRFs may be unable to generate a Resource-Allocation-Notification AVP. As a result, the report-resource-allocation statement at the [edit access pcrf partition partition-name] hierarchy level provides generated reports by default.

Charging Rule Removal Commands

The following example shows predefined rule removal commands for CCA-GX and RAR-GX messages between the PCRF and Gx:

The router processes all rule removal operations before any rule installation operations enabling you to simultaneously request both removal of an existing rule and installation of a rule having the same base name in a single transaction.

Event Trigger Commands

The following shows a predefined event trigger command for CCA-GX and RAR-GX messages between the PCRF and Gx:

If the SUCCESSFUL_RESOURCE_ALLOCATION (22) trigger value exists in the downstream data, the Broadband PCEF reports successful installations of rules marked with Resource-Allocation-Notification AVP in the Charging-Rule-Install AVP.

Note:

Some PCRFs may be unable to generate this event trigger. As a result, the report-successful-resource-allocation statement at the [edit access pcrf partition partition-name] hierarchy level provides generated reports by default.

Configuring the OCS Partition

The Online Charging System (OCS) works within a specific logical system:routing instance context, called a partition.

Note:

Currently, only a single partition is supported; you must configure it within the default logical system:routing instance context.

Before you configure the OCS partition, perform the following task:

Configuration for the OCS partition consists of naming the partition and then defining or associating a numerous parameters to define the characteristics of the partition.

To configure the OCS partition:

  1. Create the partition or specify the name of an existing partition.
  2. Specify the Diameter instance for the OCS partition.
    Note:

    Currently, only the default Diameter instance, master, is supported.

  3. (Optional) Configure the Called-Station-ID AVP used in all CCR-Gy packets for the partition.
  4. (Optional) Configure the 3GPP-Charging-Id AVP used in all CCR-Gy packets for the partition.
  5. (Optional) Configure the Destination-Host AVP value used in the CCR-GY-I message.
  6. (Optional) Configure the Destination-Realm AVP value used in all CCR-GY messages
  7. (Optional) Configure the OCS partition to the draining state to make substantial configuration changes quickly.
  8. (Optional) Configure the amount of time in seconds before the OCS partition responds and begins to drain after it has been placed in the draining state.
  9. (Optional) Configure the amount of time in seconds before the OCS partition stops attempting to send the final interrogation during the subscriber logout process.
  10. Configure the OCS partition so that subscriber traffic is allowed before the first OCS interrogation and services are not removed by the PCEF when it receives negative responses from the OCS.
  11. (Optional) Configure the GGSN-Address AVP value used in all CCR-GY messages.
  12. (Optional) Configure the 3GPP-GGSN-MCC-MNC AVP value used in all CCR-GY messages.
  13. (Optional) Configure the number of outstanding requests from the OCS to the OCS server that can be retried when the requests are improperly answered.
  14. (Optional) Specify that the Origin-State-ID AVP is included in Diameter base protocol level messages for the partition, and synchronized with the latest value sent to aid in monitoring changes in value.
  15. (Optional) Configure the information concatenated as a string in usernames that the OCS partition sends to the PCEF to identify the subscribers.
    1. (Optional) Include the underlying or physical interface name.
    2. (Optional) Use the specified character to separate the components of the username.
    3. (Optional) Include the specified domain name.
    4. (Optional) Include the interface name.
    5. (Optional) Include the client hardware MAC address from the incoming packet.
    6. (Optional) Include the NAS-Port-ID (RADIUS attribute 87) that identifies the physical interface that subscriber is using.
    7. (Optional) Include the name of the host that originates the Diameter message.
    8. (Optional) Include the name of the realm that originates the Diameter message.
    9. Include the username.
    10. (Optional) Include the specified prefix.
  16. (Optional) Configure the information required for providing file backup for OCS data.
    1. (Optional) Include the limit on the total number of backup entries for the OCS data.
    2. (Optional) Include the timeout for backup operation.
    3. (Optional) Include the action on the number of backup entries over limit.
  17. (Optional) Configure the information required for providing the stfp-backup mechanism implemented for OCS data.
    1. (Optional) Configure the length of time to write the file after the first CCR-GY-T was submitted.
    2. (Optional) Configure the accumulation-count statement to set a specific value.
    3. (Optional) Configure the accumulation-size statement to set a specific value.
    4. (Optional) Configure the retry-interval statement to set a specific value.
    5. (Optional) Configure the response-timeout statement to set a specific value.
    6. (Optional) Configure the routing-instance statement to set a specific value.
    7. (Optional) Configure the address statement to set a specific value.
    8. (Optional) Configure the port statement to set a specific value.
    9. (Optional) Configure the directory statement to set a specific value.
    10. (Optional) Configure the file-prefix statement to set a specific value.
    11. (Optional) Configure the node-ipv4-address statement to set a specific value.
    12. (Optional) Configure the ssh-login statement to set a specific value.
    13. (Optional) Configure the ssh-connection-linger statement to set a specific value.
    14. (Optional) Configure the ssh-log-verbose statement to set a specific value.
    15. (Optional) Configure the ssh-passphrase statement to set a specific value.

Configuring the PCRF Partition

The Policy Control and Rules Charging Function (PCRF) works within a specific logical system:routing instance context, called a partition.

Note:

Currently, only a single partition is supported; you must configure it within the default logical system:routing instance context.

Before you configure the PCRF partition, perform the following task:

Configuration for the PCRF partition consists of naming the partition and then defining or associating numerous parameters to define the characteristics of the partition.

To configure the PCRF partition:

  1. Create the partition or specify the name of an existing partition.
  2. Specify the Diameter instance for the PCRF partition.
    Note:

    Currently, only the default Diameter instance, master, is supported.

  3. (Optional) Configure the Destination-Host AVP value used in the CCR-GX-I message.
  4. (Optional) Configure the Destination-Realm AVP value used in all CCR-GX messages
  5. (Optional) Configure the PCRF to the draining state to make substantial configuration changes quickly.
  6. (Optional) Configure the amount of time in seconds before the PCRF responds and begins to drain after it has been placed in the draining state.
  7. Configure the an IP connectivity access network (IP-CAN) that best fits your operating environment and access network.
  8. (Optional) Configure the router to use the extended format for the session ID.
    Note:

    This step is mandatory when you configure the router for local reinitialization. You might also find it useful even when you do not configure local reinitialization.

    Note:

    This configuration also affects OCS sessions without any further configuration. The session ID for a given subscriber is the same for both Gx and Gy sessions.

  9. (Optional) Configure local-decision attributes for the PCRF partition to determine the behavior when the PCRF is unavailable or the PCRF does not respond in a timely manner.
    1. (Optional) Configure subscriber login to proceed.
      Note:

      You can restore the default behavior where login does not proceed by specifying deny instead of grant.

    2. (Optional) Specify how long the router waits for the PCRF to respond before using the local decision to log in the subscriber.
  10. (Optional) Configure local-decision attributes for the PCRF partition so that the router reinitializes the PCRF session if the PCRF server response to the CCR-GX-I from the router is lost.
    Note:

    For local reinitialization, you must also configure the following:

    • The grant option

    • The use-session-stamp option with the partition statement

    1. (Optional) Configure reinitialization to occur when the PCRF responds to a CCR-GX-I retry from the router with an unable-to-comply error code (5012) in AVP 268.
    2. (Optional) Configure reinitialization to occur when the PCRF erroneously responds to a CCR-GX-I retry from the router with any type of RAR.
    3. (Optional) Specify how long the router waits for the PCRF to respond with a CCA-GX-T before using the local decision to log in the subscriber.
  11. (Optional) Configure the amount of time in seconds before the PCRF stops attempting to send a subscriber logout message.
  12. (Optional) Configure the number of outstanding requests from the PCRF to the PCRF server that can be retried when the requests are improperly answered.
  13. (Optional) Specify that the PCRF sends local report downstream messages by default.
  14. (Optional) Specify that .the PCRF reports by default when installation fails for rules marked with the Resource-Allocation-Notification AVP in the Charging-Rule.
  15. (Optional) Specify that the PCRF reports by default when installation either fails or succeeds for rules marked with the Resource-Allocation-Notification AVP in the Charging-Rule.
  16. (Optional) Specify that the Juniper-Dyn-Subscription-Id-Indicator AVP is included to indicate support for dynamic assignment of the subscription ID.
  17. (Optional) Specify that the Juniper-Network-Family-Indicator AVP is included to indicate the network families that are associated with the service request and supported by the subscriber.
  18. (Optional) Specify that the
  19. (Optional) Specify that the Origin-State-ID AVP is included in Diameter base protocol level messages for the partition, and synchronized with the latest value sent to aid in monitoring changes in value.
  20. (Optional) Configure the subscriber data to use in the PCRF partition messages to identify subscribers.
    1. (Optional) Include the underlying or physical interface name.
    2. (Optional) Use the specified character to separate the components of the subscription identifier.
    3. (Optional) Include the specified domain name.
    4. (Optional) Include the interface name.
    5. (Optional) Include the client hardware MAC address from the incoming packet.
    6. (Optional) Include the NAS-Port-ID (RADIUS attribute 87) that identifies the physical interface that subscriber is using.
    7. (Optional) Include the name of the host that originates the Diameter message.
    8. (Optional) Include the name of the realm that originates the Diameter message.
    9. Include the username.
    10. (Optional) Include the specified prefix.
    11. (Optional) Include the subscriber VLAN tags. You can use this instead of the interface-name option when the outer VLAN tag is unique across the system, which is dependent on your network topology and use case.

      (Optional) Include the subscriber VLAN tags. You can use this instead of the interface-name option when the outer VLAN tag is unique across the system, which is dependent on your network topology and use case.

  21. (Optional) Identify the subscriber with a custom or predefined type value during the login session in CCR-GX-I and CCA-GX-I messages.
  22. (Optional) Configure the amount of time in seconds before a PCRF partition stops attempting to send an updated rule report response using a CCR-GX-U message.

Configuring OCS Global Parameters

You can configure global attributes of the 3rd Generation Partnership Project (3GPP) Diameter credit control service charging system for the Online Charging System (OCS), which interacts with the Policy and Charging Enforcement Function (PCEF).

Currently, the only configurable global attribute is the service context identifier allocated by the service provider or operator. This value corresponds to the Service-Context-Id AVP, which together with the Service-Identifier-AVP uniquely and globally identifies the Diameter credit control service.

To configure the OCS global parameters:

  • Configure the service context identifier.

Related Documentation

Change History Table

Feature support is determined by the platform and release you are using. Use Feature Explorer to determine if a feature is supported on your platform.

Release
Description
19.2R1
Starting in Junos Release 20.1R1, you can configure the router to recover from certain PCRF server errors by reinitializing the subscriber session to resync the router and PCRF server states.