Mapping Between SRC Software, Junos OS, and PCC Concepts

This section describes the mapping between the SRC software and Junos OS concepts and the policy and charging control (PCC) concepts. During these discussions, refer to Table 11, which describes the mapping between SRC software and Junos OS terminology and the policy and charging control (PCC) function terminology.

Table 11: SRC Software and Junos OS Terminology Versus PCC Terminology

SRC Software and Junos OS Terminology

PCC Terminology

Subscriber session

IP CAN Session

Service with associated policies

PCC Rule

Service activation

Rule-Install

Service deactivation

Rule-Uninstall

Service accounting

Usage-Monitoring

Service templates, defined by SRC

Predefined Rule

Policies, defined by the PCRF

Dynamic Rule

Charging Rule Installation (Service Activation)

A PCRF can activate any number of non-parameterized and parameterized services (predefined PCC rules) in the same CCA or RAR message by providing a Charging-Rule-Install AVP. The Charging-Rule-Install AVP can contain multiple Charging-Rule-Name AVPs, one for each non-parameterized service to be activated. The Charging-Rule-Install AVP can also contain multiple Charging-Rule-Definition AVPs, one for each parameterized service session that is to be activated.

Note: The names appearing in the Charging-Rule-Name AVPs must be unique; the same name must not appear multiple times in the same Gx message.

The SRC 3GPP gateway expects to receive the following AVPs from the PCRF in CCA and RAR messages:

Charging-Rule-Install ::= < AVP Header: 1001 > 
       *[ Charging-Rule-Definition ] 
       *[ Charging-Rule-Name ] 
       *[ Charging-Rule-Base-Name ] 
       *[ AVP ] 

Where:

Charging-Rule-Definition ::= < AVP Header: 1003 >
   {Charging-Rule-Name}
   [Juniper-Substitution]

   *[Juniper-Substitution]

Juniper-Substitution::= < AVP Header: 2024>
     {Juniper-Substitution-Name}
     {Juniper-Substitution-Value"}

Table 12 describes these AVPs.

Table 12: AVP Definitions

AVP

Code

Type

VendorID

Description

Charging-Rule-Name

1005

UTF8String

VID_3GPP

To activate a parameterized default service session, specify the serviceName in the format: ruleName@00010001 and specify the ruleName in numeric format.

Juniper-Substitution-Name

2025

UTF8String

VID_JNPR

Name of parameter as defined in the SRC policy definition.

Juniper-Substitution-Value

2026

UTF8String

VID_JNPR

Value to assign to the parameter.

Installing Non-Parameterized Predefined Charging Rules

Non-parameterized predefined charging rules are equivalent to activating an SAE service with no parameters.

The Charging-Rule-Install AVP provides the list of Charging-Rule-Names. The Charging-Rule-Name AVP sent by the PCRF must correspond to the SRC service name.

Note: The Charging-Rule-Base-Name AVP is not supported and is ignored by the SRC 3GPP gateway.

Installing Parameterized Predefined Charging Rules

Parameterized predefined charging rules are equivalent to activating an SAE service with parameters.

The Charging-Rule-Definition AVP must be provided with the list of parameters in a list of Juniper-Substitution-Name AVPs.

Note: Only default sessions are supported.

Example of Charging-Rule Installation

The following example Charging-Rule-Install AVP, sent by the PCRF, activates the services “foo1” and “foo2” with no parameters. It also activates the service “123” with two parameters and the service “456” with one parameter.

AVP: Charging-Rule-Install(1001)
        AVP: Charging-Rule-Name(1005) val=foo1  <- Activate service foo1
        AVP: Charging-Rule-Name(1005) val=foo2  <- Activate service foo2
    AVP: Charging-Rule-Definition(1003) vnd=VID_3GPP  <- 3GPP AVP for activating parameterized service “123” with 2 parameters
            AVP: Charging-Rule-Name (1005) vnd=3GPP val=123@00010000
      AVP: Juniper-Substitution (2024) vnd=JNPR
      	          AVP: Juniper-Substitution–Name(2025) vnd=JNPR val=rate
          AVP: Juniper-Substitution–Value(2026) vnd=JNPR val=5
      	      AVP: Juniper-Substitution (2024) vnd=JNPR
          AVP: Juniper-Substitution–Name(2025) vnd=JNPR val=color
      	          AVP: Juniper-Substitution–Value(2026) vnd=JNPR val=red
AVP: Charging-Rule-Definition(1003) vnd=VID_3GPP  <- 3GPP AVP for activating parameterized service “456” with 1 parameter
            AVP: Charging-Rule-Name (1005) vnd=3GPP val=456@00010001
      AVP: Juniper-Substitution (2024) vnd=JNPR
          AVP: Juniper-Substitution–Name(2025) vnd=JNPR val=rate
          AVP: Juniper-Substitution–Value(2026) vnd=JNPR val=10

In this example, foo1, foo2, 123 (rate, color), and “456” (rate) are configured services in the SRC software.

Charging Rule Removal (Service Deactivation)

A PCRF can deactivate any number of non-parameterized and parameterized services (predefined PCC rules) in the same CCA or RAR message by providing a Charging-Rule-Remove AVP. The Charging-Rule-Remove AVP can contain multiple Charging-Rule-Name AVPs, one for each non-parameterized or parameterized service to be deactivated.

The following AVPs are expected by the SRC (PCEF) from the PCRF in CCA and RAR messages:

Charging-Rule-Remove ::= < AVP Header: 1002 > 
       *[ Charging-Rule-Definition ] 
       *[ Charging-Rule-Name ] 
       *[ Charging-Rule-Base-Name ] 
       *[ AVP ]

Note: Charging-Rule-Base-Name AVP is not supported and is ignored by the SRC 3GPP gateway.

Example of Charging-Rule Removal

The following example Charging-Rule-Removal AVP, sent by the PCRF, deactivates the SRC services called “foo1”, “foo2”, and “123”.

AVP: Charging-Rule-Remove(1002)
             AVP: Charging-Rule-Name(1005) val=foo1 <- Deactivate service foo1
             AVP: Charging-Rule-Name(1005) val=foo2 <- Deactivate service foo2
             AVP: Charging-Rule-Name(1005) val=123@00010001  <- Deactivate service 123                                       

Charging Rule Report

The SRC 3GPP gateway can send charging rule reports for any number of non-parameterized and parameterized services in the same Credit Control Update (CCR-U) request or RAA message. This is achieved by providing a Charging-Rule-Report AVP for each failed service. The Charging-Rule-Report AVP contains a single Charging-Rule-Name AVP (for a non-parameterized or a parameterized service).

Charging-Rule-Report ::= < AVP Header: 1018 > 
       *[ Charging-Rule-Name ] 
       *[ Charging-Rule-Base-Name ] 
				 [ PCC-Rule-Status ]
			    [ Rule-Failure-Code ]
				*[ AVP ]

Note: The Charging-Rule-Base-Name AVP is not supported and is never sent by the SRC 3GPP gateway.

Service Accounting

You can perform service accounting for one or more PCC rules.

When a PCRF requests service accounting, it needs to include an Event-Trigger AVP, set to “USAGE_REPORT”. This setting must be set in either the RAR message (if the PRCF initiates the PCC rule changes), or the CCA message (if the user equipment initiates the rule changes).

The PCRF may also provide usage threshold levels to the SRC 3GPP gateway at session establishment or modification time (CCA or RAR message). This is done, by setting those thresholds in the grouped Grant-Service-Unit AVP per Monitoring-Key in the Usage-Monitoring-Information AVP. The threshold level may be defined for:

The Monitoring-Key AVP format is similar to the format of the Charging-Rule-Removal and Charging-Rule-Report AVPs:

The SRC 3GPP gateway does not support SESSION_LEVEL monitoring. This means that the only supported value for the Usage-Monitoring-Level AVP is PCC_RULE_LEVEL.

The SRC 3GPP gateway sends accounting updates when it receives interim updates from the SAE for the service session. This is done by setting the usage counters in the Used-Service-Unit AVP within the Usage-Monitoring-Information AVP. Like the Granted-Service-Unit AVP (for setting the threshold), the Used-Service-Unit AVP is a grouped AVP and the SRC 3GPP gateway uses the CC-Total-Octet, CC-Input-Octets, and CC-Output-Octets AVP within the Used-Service-Unit AVP to report the usage to the PCRF. The SRC 3GPP gateway sends this only in CCR messages (not in RAA messages). The reporting is done when any of the following conditions are met:

Related Documentation