• 3GPP TS 23.203 V7.6.0 (2008-03): 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Policy and charging control architecture (Release 7)

• 3GPP TS 29.212 V7.8.0 (2009-03): 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Policy and Charging Control over Gx reference point (Release 7)

• 3GPP TS 29.213 V7.4.0 (2008-03): 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Policy and Charging Control signalling flows and QoS parameter mapping; (Release 7)

• RFC 3588, Diameter Base Protocol; September 2003

• RFC 4006, Diameter Credit-Control Application; August 2005

• Binding: Binding is the generation of an association between a Service Data Flow (SDF) and the IP CAN bearer (for GPRS a PDP context) transporting that SDF.

  The QoS demand in the PCC rule, as well as the SDF template are input for the bearer binding. The selected bearer will have the same QoS Class as the one indicated by the PCC rule.

  Depending on the type of IP-CAN and bearer control mode, bearer binding can be executed either by the PCRF, or both PCRF and PCEF.

  • For UE-only IP-CAN bearer establishment mode, the PCRF performs bearer binding. When the PCRF performs bearer binding, it indicates the bearer (PDP context) by means of Bearer ID. The Bearer ID uniquely identifies the bearer within the PDP session.

  • For UE/NW IP-CAN bearer establishment mode, the PCRF performs the binding of the PCC rules for user controlled services, while the PCEF performs the binding of the PCC rules for the network-controlled services.

  Prior to Release 16.0, the rule binding was getting rejected. In 16.0 and later releases, the binding of PCEF rules will be successful when BCM mode is set to UE-only for EPS IP-CAN bearer without "bearer-ID" in the PCRF messages such as RAR or CCA-U.

  In the 3G to 4G handover scenario, rule binding and rule removal will be successful in UE-only mode and any filter (and related info) changes because of this modification/installation/removal will not be notified to UE as updates in UE only mode cannot be sent to UE. These rules are only considered for charging and the expectation is that the same rules are again modified in 4G (if handover is done) so that the filters (and related info) can be notified to UE.

  In releases prior to 18, P-GW/GGSN does not send CCR-U with Charging Rule report for rule binding failure occurred during 4G to 3G HO in a collision case where create/update bearer response in 3G/4G is pending and update bearer of 3G HO is received. In 18 and later releases, CCR-U is generated and sent to PCRF for reporting rule failure when the collision happens during GnGp HO scenario.

  This additional Gx message (CCR-U) triggered will require multiple CCR-Us to be configured when RAT_TYPE trigger is enabled. Otherwise, the subscriber call will be dropped whenever the collision happens during HO.

• Gating Control: Gating control is the blocking or allowing of packets, belonging to an SDF, to pass through to the desired endpoint. A gate is described within a PCC rule and gating control is applied on a per SDF basis. The commands to open or close the gate leads to the enabling or disabling of the passage for corresponding IP packets. If the gate is closed, all packets of the related IP flows are dropped. If the gate is opened, the packets of the related IP flows are allowed to be forwarded.

• Event Reporting: Event reporting is the notification of and reaction to application events to trigger new behavior in the user plane as well as the reporting of events related to the resources in the Gateway (PCEF).

  • Event triggers may be used to determine which IP-CAN session modification or specific event causes the PCEF to re-request PCC rules. Although event trigger reporting from PCEF to PCRF can apply for an IP CAN session or bearer depending on the particular event, provisioning of event triggers will be done at session level.

    Note that in 11.0 and later releases, RAR with unknown event triggers are silently ignored and responded with DIAMETER_SUCCESS. In earlier releases, when unknown event triggers were received in the RAR command from PCRF, invalid AVP result code was set in the RAA command.

  • The Event Reporting Function (ERF) receives event triggers from PCRF during the Provision of PCC Rules procedure and performs event trigger detection. When an event matching the received event trigger occurs, the ERF reports the occurred event to the PCRF. If the provided event triggers are associated with certain parameter values then the ERF includes those values in the response back to the PCRF. The Event Reporting Function is located in the PCEF.

    In StarOS releases prior to 14.0, SUCCESSFUL_RESOURCE_ALLOCATION ( 22 ) event trigger was sent for rules irrespective of successful installation. In 14.0 and later releases, SUCCESSFUL_RESOURCE_ALLOCATION ( 22 ) event trigger will be sent under the following conditions:

    • When a rule is installed successfully (and the event trigger is armed by PCRF and resource-allocation-notification is enabled).

    • On partial failure, i.e., when two or more rules are installed and at least one of the rules were successfully installed. (and the event trigger is armed by PCRF and resource-allocation-notification is enabled).

    On complete failure, i.e., none of the rules were installed, the event-trigger SUCCESSFUL_RESOURCE_ALLOCATION ( 22 ) will not be sent.

    Important

    In this release, event triggers "IP-CAN_CHANGE" and "MAX_NR_BEARERS_REACHED" are not supported.

• QoS Control: QoS control is the authorization and enforcement of the maximum QoS that is authorized for a SDF or an IP-CAN bearer or a QoS Class Identifier (QCI). In case of an aggregation of multiple SDFs (for GPRS a PDP context), the combination of the authorized QoS information of the individual SDFs is provided as the authorized QoS for this aggregate.

  • QoS control per SDF allows the PCC architecture to provide the PCEF with the authorized QoS to be enforced for each specific SDF.

  • The enforcement of the authorized QoS of the IP-CAN bearer may lead to a downgrading or upgrading of the requested bearer QoS by the Gateway (PCEF) as part of a UE-initiated IP-CAN bearer establishment or modification. Alternatively, the enforcement of the authorized QoS may, depending on operator policy and network capabilities, lead to network-initiated IP-CAN bearer establishment or modification. If the PCRF provides authorized QoS for both, the IP-CAN bearer and PCC rule(s), the enforcement of authorized QoS of the individual PCC rules takes place first.

  • QoS authorization information may be dynamically provisioned by the PCRF, or it can be a predefined PCC rule in the PCEF. In case the PCRF provides PCC rules dynamically, authorized QoS information for the IP-CAN bearer (combined QoS) may be provided. For a predefined PCC rule within the PCEF, the authorized QoS information takes affect when the PCC rule is activated. The PCEF combines the different sets of authorized QoS information, that is the information received from the PCRF and the information corresponding to the predefined PCC rules. The PCRF knows the authorized QoS information of the predefined PCC rules and takes this information into account when activating them. This ensures that the combined authorized QoS of a set of PCC rules that are activated by the PCRF is within the limitations given by the subscription and operator policies regardless of whether these PCC rules are dynamically provided, predefined, or both.

    Important

    In this release, QoS Resource Reservation is not supported.

• Provisioning and Policy Enforcement of Authorized QoS: The PCRF may provide authorized QoS to the PCEF. The authorized QoS provides appropriate values for resources to be enforced.

• Provisioning of "Authorized QoS" Per IP CAN Bearer: The authorized QoS per IP-CAN bearer is used if the bearer binding is performed by the PCRF.

• Policy Enforcement for "Authorized QoS" per IP CAN Bearer: The PCEF is responsible for enforcing the policy-based authorization, that is to ensure that the requested QoS is in-line with the "Authorized QoS" per IP CAN Bearer.

• Policy Provisioning for Authorized QoS Per SDF: The provisioning of authorized QoS per SDF is a part of PCC rule provisioning procedure.

  • Policy Enforcement for Authorized QoS Per SDF: If an authorized QoS is defined for a PCC rule, the PCEF limits the data rate of the SDF corresponding to that PCC rule not to exceed the maximum authorized bandwidth for the PCC rule by discarding packets exceeding the limit.

  • Upon deactivation or removal of a PCC rule, the PCEF frees the resources reserved for that PCC rule. If the PCRF provides authorized QoS for both the IP-CAN bearer and PCC rule(s), the enforcement of authorized QoS of the individual PCC rules takes place first.

• • Provisioning of Authorized QoS Per QCI: If the PCEF performs the bearer binding, the PCRF may provision an authorized QoS per QCI for non-GBR bearer QCI values. If the PCRF performs the bearer binding the PCRF does not provision an authorized QoS per QCI. The PCRF does not provision an authorized QoS per QCI for GBR bearer QCI values.

    Important

    Only standards-based QCI values of 1 through 9 are supported. QCI values 1 through 9 are defined in 3GPP Specification TS 23.203 "Policy and charging control architecture".

  • Policy Enforcement for Authorized QoS per QCI: The PCEF can receive an authorized QoS per QCI for non GBR-bearer QCI values.

• Other Features:

  • Bearer Control Mode Selection: The PCEF may indicate, via the Gx reference point, a request for Bearer Control Mode (BCM) selection at IP-CAN session establishment or IP-CAN session modification (as a consequence of an SGSN change). It will be done using the "PCC Rule Request" procedure.

    If the Bearer-Control-Mode AVP is not received from PCRF, the IP-CAN session is not terminated. The value negotiated between UE/SGSN/GGSN is considered as the BCM. The following values are considered for each of the service types:

    • GGSN: The negotiated value between UE/SGSN/GGSN is considered.

      In the following scenarios UE_ONLY is chosen as the BCM:

      Scenario 1:

      • UE-> UE_ONLY

      • SGSN-> UE_ONLY

      • GGSN-> UE_ONLY

      • PCRF-> NO BCM

      Scenario 2:

      • UE-> UE_ONLY

      • SGSN-> UE_ONLY

      • GGSN-> Mixed

      • PCRF-> NO BCM

    • GTP-PGW: BCM of UE_NW is considered.

    • IPSG: BCM of UE_ONLY is considered.

    • HSGW/SGW/PDIF/FA/PDSN/HA/MIPV6HA: BCM of NONE is considered.

  • PCC Rule Error Handling: If the installation/activation of one or more PCC rules fails, the PCEF includes one or more Charging-Rule-Report AVP(s) in either a CCR or an RAA command for the affected PCC rules. Within each Charging-Rule-Report AVP, the PCEF identifies the failed PCC rule(s) by including the Charging-Rule-Name AVP(s) or Charging-Rule-Base-Name AVP(s), identifies the failed reason code by including a Rule-Failure-Code AVP, and includes the PCC-Rule-Status AVP.

    If the installation/activation of one or more new PCC rules (that is, rules that were not previously successfully installed) fails, the PCEF sets the PCC-Rule-Status to INACTIVE for both the PUSH and the PULL modes.

    If a PCC rule was successfully installed/activated, but can no longer be enforced by the PCEF, the PCEF sends the PCRF a new CCR command and include a Charging-Rule-Report AVP. The PCEF includes the Rule-Failure-Code AVP within the Charging-Rule-Report AVP and sets the PCC-Rule-Status to INACTIVE.

    In releases prior to 18, P-GW/GGSN does not send CCR-U with Charging Rule report for rule binding failure occurred during 4G to 3G HO in a collision case where create/update bearer response in 3G/4G is pending and update bearer of 3G HO is received. In 18 and later releases, CCR-U is generated and sent to PCRF for reporting rule failure when the collision happens during GnGp HO scenario.

    This additional Gx message (CCR-U) triggered will require multiple CCR-Us to be configured when RAT_TYPE trigger is enabled. Otherwise, the subscriber call will be dropped whenever the collision happens during HO.

  • Time of the Day Procedures: PCEF performs PCC rule request as instructed by the PCRF. Revalidation-Time when set by the PCRF, causes the PCEF to trigger a PCRF interaction to request PCC rules from the PCRF for an established IP CAN session. The PCEF stops the timer once the PCEF triggers a REVALIDATION_TIMEOUT event.

• Provisioning of Charging-related Information for the IP-CAN Session.

• Provisioning of Charging Addresses: Primary or secondary event charging function name (Online Charging Server (OCS) addresses or the peer names).

  Important

  In this release, provisioning of primary or secondary charging collection function name (Offline Charging Server (OFCS) addresses) over Gx is not supported.

• Provisioning of Default Charging Method: In this release, the default charging method is sent in CCR-I message. For this, new AVPs Online/Offline are sent in CCR-I message based on the configuration. The Online/Offline AVP received at command level applies only to dynamic rules if they are not configured at PCC rule level.

• Detect a packet belonging to an SDF.

  • Select downlink IP CAN bearers based on SDF filters in the PCC rule.

  • Enforce uplink IP flows are transported in the correct IP CAN bearer using the SDF filters within the PCC rule.

• Identify the service that the SDF contributes to.

• Provide applicable charging parameters for an SDF.

• Provide policy control for an SDF.

• Dynamic PCC Rules: Rules dynamically provisioned by the PCRF to the PCEF via the Gx interface. These PCC rules may be either predefined or dynamically generated in the PCRF. Dynamic PCC rules can be installed, modified, and removed at any time.

• Predefined PCC Rule: Rules preconfigured in the PCEF by the operators. Predefined PCC rules can be activated or deactivated by the PCRF at any time. Predefined PCC rules within the PCEF may be grouped allowing the PCRF to dynamically activate a set of PCC rules over the Gx reference point.

• Rule Name: The rule name is used to reference a PCC rule in the communication between the PCEF and PCRF.

• Service Identifier: The service identifier is used to identify the service or the service component the SDF relates to.

• Service Data Flow Filter(s): The service flow filter(s) is used to select the traffic for which the rule applies.

• Precedence: For different PCC rules with overlapping SDF filter, the precedence of the rule determines which of these rules is applicable. When a dynamic PCC rule and a predefined PCC rule have the same priority, the dynamic PCC rule takes precedence.

• Gate Status: The gate status indicates whether the SDF, detected by the SDF filter(s), may pass (gate is open) or will be discarded (gate is closed) in uplink and/or in downlink direction.

• QoS Parameters: The QoS information includes the QoS class identifier (authorized QoS class for the SDF), the Allocation and Retention Priority (ARP), and authorized bitrates for uplink and downlink.

  Important

  In earlier releases, ECS used only the Priority-Level part of ARP byte for bearer binding, (along with QCI). Now the entire ARP byte is used for bearer binding (along with QCI). Since the capability and vulnerability bits are optional in a dynamic rule, if a dynamic rule is received without these flags, it is assumed that the capability bit is set to 1 (disabled) and vulnerability bit is set to 0 (enabled). For predefined rules, currently configuring these two flags is not supported, so as of now all predefined rules are assumed to have capability bit set to 1 (disabled) and vulnerability bit set to 0 (enabled).

• Charging key (rating group)

• Other charging parameters: The charging parameters define whether online and offline charging interfaces are used, what is to be metered in offline charging, on what level the PCEF will report the usage related to the rule, and so on.

1. At the context level, configure IMSA service for IMS subscribers as described in Configuring IMS Authorization Service at Context Level.

2. Within the same context, configure the subscriber template to use the IMSA service as described in Applying IMS Authorization Service to Subscriber Template.

3. Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration . For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.

• Control over the user plane traffic handling at the gateway and its QoS.

• Service data flow detection and counting, as well as online and offline charging interactions.

• For a service data flow that is under policy control, the PCEF allows the service data flow to pass through the gateway if and only if the corresponding gate is open.

• For a service data flow that is under charging control, the PCEF allows the service data flow to pass through the gateway if and only if there is a corresponding active PCC rule and, for online charging, the OCS has authorized the applicable credit with that charging key.

• If requested by the PCRF, the PCEF will report to the PCRF when the status of the related service data flow changes.

• In case the SDF is tunnelled at the BBERF, the PCEF informs the PCRF about the mobility protocol tunnelling header of the service data flows at IP-CAN session establishment.

• Control over the user plane traffic handling at the gateway and its QoS.

• Service data flow detection and counting, as well as online and offline charging interactions.

• For a service data flow that is under policy control, the PCEF allows the service data flow to pass through the gateway if and only if the corresponding gate is open.

• For a service data flow that is under charging control, the PCEF allows the service data flow to pass through the gateway if and only if there is a corresponding active PCC rule and, for online charging, the OCS has authorized the applicable credit with that charging key.

• If requested by the PCRF, the PCEF reports to the PCRF when the status of the related service data flow changes.

• In case the SDF is tunnelled at the BBERF, the PCEF informs the PCRF about the mobility protocol tunnelling header of the service data flows at IP-CAN session establishment.

• Control over the user plane traffic handling at the gateway and its QoS.

• Service data flow detection and counting, as well as online and offline charging interactions.

• For a service data flow that is under policy control, the PCEF allows the service data flow to pass through the gateway if and only if the corresponding gate is open.

• For a service data flow that is under charging control, the PCEF allows the service data flow to pass through the gateway if and only if there is a corresponding active PCC rule and, for online charging, the OCS has authorized the applicable credit with that charging key.

• If requested by the PCRF, the PCEF will report to the PCRF when the status of the related service data flow changes.

• In case the SDF is tunnelled at the BBERF, the PCEF informs the PCRF about the mobility protocol tunnelling header of the service data flows at IP-CAN session establishment.

• Rule Name
• Rating Group
• Service ID
• Online Charging
• Offline Charging
• QCI
• ARP
  • Priority Level
  • QCI
  • QVI
• Max-Requested-Bandwidth
  • UL
  • DL

• AMBR
  • UL
  • DL
• QCI
• ARP
  • Priority Level
  • QCI
  • QVI

• In the event of CCR-U failure, CCR-U was triggered to PCRF only on receiving subscriber event.
• When a CCR-U failure happened and a call continued without Gx, unreported volume is lost as the threshold is set to infinity. In next CCR-U triggered to PCRF, the cumulative volume was sent to PCRF.
• RAR was rejected with result-code diameter_unable_to_comply (3002) when the validity timer is running.

• When send-usage-report is configured, the CCR-U with usage report will be sent immediately after the local-policy timer-expiry.
• The unreported usage will not be returned to ECS. Thus, usage since last tried CCR-U will be sent to PCRF.
• RAR will be accepted and the rules received on RAR will be installed even when the timer is running.

• If the PCRF deletes or loses session information during a Gx session update (CCR-U) initiated by the gateway, PCRF will respond back with DIAMETER_UNKNOWN_SESSION_ID resulting in session termination even in the case of CCR-U.
• If the PCRF deletes or loses session information and an Rx message is received, PCRF will not be able to implement corresponding rules and will result in failure of subscriber voice or video calls.
• For subscriber's existing Rx sessions and active voice/video calls, PCRF will not be able to initiate cleanup of the sessions towards the gateway and can result in wastage of the resources in the network (dedicated bearers not removed) or can result in subscriber not able to place calls on hold or conference or remove calls from hold.
• For out of sync scenarios, PCRF and gateway could be implementing different policies and can result in wastage of resources or in poor subscriber experience. Existing behavior does not provide for a way to sync the entire session information.

1. PCEF after receiving the message from PCRF parses the time monitoring related AVPs, and sends the information to IMSA.

2. IMSA updates the information to ECS.

3. Once the ECS is updated with the time monitoring information from PCRF, the PCEF (ECS) starts tracking the time usage.

4. For session-level monitoring, the ECS maintains the amount of time usage.

5. For PCC rule monitoring, usage is monitored with the monitoring key as the unique identifier. Each node maintains the time usage information per monitoring key.

6. The PCEF continues to track time usage after the threshold is reached and before a new threshold is provided by the PCRF. If a new usage threshold is not provided by the PCRF in the acknowledgement of an IP-CAN Session modification where its usage was reported, then time monitoring does not continue in the PCEF for that IP CAN session.

• Usage Monitoring at Session Level
• Usage Monitoring at Flow Level

• Usage Threshold Reached: PCEF records the subscriber usage and checks if the usage threshold provided by PCRF is reached. Once the condition is met, it reports the usage information to IMSA and continues monitoring. IMSA then triggers the CCR-U if "USAGE_REPORT" trigger is enabled by PCRF. The Usage-Monitoring-Information AVP is sent in this CCR with the "CC-Time" in "Used-Service-Unit" set to track the time usage of the subscriber.

• Usage Monitoring Disabled: If PCRF explicitly disables the usage monitoring with Usage-Monitoring-Support AVP set to USAGE_MONITORING_DISABLED, PCEF stops monitoring and reports the usage information (when the monitoring was enabled) to PCRF if the usage monitoring is disabled by PCRF as a result of CCR from PCEF which is not related to reporting usage, other external triggers, or a PCRF internal trigger.

• IP CAN Session Termination: When the IP CAN session is terminated, the accumulated subscriber usage information is reported to PCRF in the CCR-T from PCEF.

  PCRF uses RAR message and includes Session-Release-Cause AVP in it to initiate IP CAN Session Termination. However, there are some scenarios where PCRF may want to terminate the IP CAN Session in CCA messages. In order to avoid an unnecessary additional message, PCRF can inform P-GW to terminate the subscriber in CCA-U message itself. Hence, in 17.0 and later releases, the Session Release Cause has been added in CCA messages for all Gx dictionaries.

• PCC Rule Removal: When the PCRF deactivates the last PCC rule associated with a usage monitoring key, PCEF sends a CCR with the usage time for that monitoring key. If the PCEF reports the last PCC rule associated with a usage monitoring key is inactive, the PCEF reports the accumulated usage for that monitoring key within the same CCR command if the Charging-Rule-Report AVP was included in a CCR command; otherwise, if the Charging-Rule-Report AVP was included in an RAA command, the PCEF sends a new CCR command to report accumulated usage for the usage monitoring key.

• PCRF Requested Usage Report: When PCRF provides the Usage-Monitoring-Information with the Usage-Monitoring-Report set to USAGE_MONITORING_REPORT_REQUIRED, PCEF sends the time usage information. If the monitoring key is provided by PCRF, time usage for that monitoring key is notified to PCRF regardless of usage threshold. If the monitoring key is not provided by PCRF, time usage for all enabled monitoring keys is notified to PCRF.

• Event Based Reporting: The event based reporting can be enabled through the CLI command event-update send-usage-report events . When an event like sgsn change, qos change or revalidation-timeout is configured under this CLI, time usage report is generated whenever that event happens.

• The configuration for enabling Time Reporting over Gx is same as the Volume Reporting over Gx configuration. If a time threshold is received from PCRF then Time monitoring is done, and if a volume threshold is received then Volume monitoring will be done.

• The maximum accepted monitoring key value by the PCEF is 4294967295. If the PCEF sends a greater value, the value is converted to an Unsigned Integer value.

• The event-update CLI enables time usage report to be sent in event updates. The optional keyword reset-usage enables to support delta reporting wherein the usage is reported and reset at PCEF. If this option is not configured, the behavior is to send the time usage information as part of event update but not reset at PCEF.

• This command is used to perform server selection at diabase when the hosts could not be selected by IMS Authorization application or when the hosts selected by the IMS Authorization application is inactive. For example, host table is not configured in IMSA service, host table is configured but not activated, none of the rows in prefix table match the subscriber, host template is not associated with IMSA service, host template could not select the hosts.
• on-host-select-failure : Specifies to perform server selection at Diabase when the hosts could not be selected by IMS Authorization application.
• on-inactive-host : Specifies to perform server selection at diabase when the hosts selected by application are inactive.
• This CLI command is added in policy control configuration mode to maintain backward compatibility with the old behavior of terminating the call when server selection fails at IMS Authorization application.

• value must be an integer value from 1 through 12. The default value is 1.

• netloc-ran-nas-cause : Enables the Netloc-RAN-NAS-Cause feature. By default, this supported feature will be disabled.
• If the supported features "netloc-ran-nas-code" and "netloc" are enabled, then netloc-ran-nas-cause code will be sent to PCRF.

• ADC does not support group of ruledefs.
• Registration of the duplicate application IDs are not supported.
• Readdress/Redirection for P2P flows will not be supported.
• Redirection happens only on transactions of GET/Response.
• Port based, IP Protocol based, and URL based applications are not supported.
• Pre-configured options (precedence, redirect-server-ip) for dynamic ADC rules are not supported.
• Simultaneous instances of an application for the same subscriber are not distinguished.
• Flow recovery is not supported for application flows.

• The keyword "adc-rules " will be available only when the feature-specific license is configured.
• For ADC 6th bit of supported feature will be set.

[ default | no ] diameter encode-supported-features  

• When dynamic charging-rules with the Charging-Rule-Definition AVP are activated from PCRF, the PCRF can specify the GoR name configured in ECS as TDF-Application-Identifier.

• When dynamic charging-rules with the Charging-Rule-Definition AVP are activated, the PCRF can remove or modify the rule through the Charging-Rule-Definition using RAR. During rule activation or modification, the PCRF can add, modify or remove the charging-rule attributes of the rule.

• A Gx message might contain both Standards based MUTE and the custom MUTE.
• Standards based MUTE is given preference over the custom MUTE/UNMUTE.
• A dynamic ADC rule can be installed and modified with a custom MUTE.
• Custom-Mute-Notification AVP can be sent by the PCRF in CCA-I and RAR.
• A dynamic ADC rule can be modified with a custom UNMUTE.
• On a custom MUTE for a given dynamic ADC rule, PCEF sends a single APPLICATION_START/ APPLICATION_STOP response for the entire application traffic rather the per flow APPLICATION_START /APPLICATION_STOP response.
• On a custom MUTE for a given dynamic ADC rule, if no APPLICATION_START has been sent prior to the custom MUTE then a single APPLICATION_START is sent on the next flow packet that hits the dynamic rule.
• On a custom MUTE for a given dynamic rule, the APPLICATION_START response is sent with the flow's 5-tuple information.
• On a custom MUTE for a given dynamic rule, the APPLICATION_START response is sent with TDF-Application-Instance-Identifier = 0.
• On a custom MUTE for a given dynamic rule, a single APPLICATION_STOP is sent when the last flow associated with the given dynamic rule is terminated. Such an APPLICATION_STOP will not contain 5-tuple information of the last flow and is sent with TDF-Application-Instance-Identifier = 0.
• On a custom UNMUTE for a given dynamic rule, APPLICATION STARTs response is matched with the given dynamic rule and then sent to all the forthcoming flows.
• There is no change in behavior for a custom UNMUTE, which has not been custom MUTED or standard MUTED before UNMUTING. APPLICATION_STARTs and APPLICATION_STOPs is continued to be sent per flow as before.
• On a custom UNMUTE, PCEF sends an APPLICATION_STOP each for all flows that terminate then onwards.
• A given dynamic rule is recovered in both SR and ICSR including the Custom MUTE/UNMUTE status. The APPLICATION_START status for a given dynamic rule is check-pointed and recovered. This ensures that an extra APPLICATION_START is not sent to the PCRF post recoveries.

• priority priority : Specifies a priority for the specified action. priority must be unique and an integer from 1 to 2048.

• ecgi-change : This keyword specifies to install ECGI-CHANGE event trigger. If enabled, ECGI-CHANGE event trigger is sent from local-policy.

• This CLI command is configured in local-policy if operator wants to enable ECGI-Change notification in MME by sending a CRA value.

• priority priority : Specifies a priority for the specified rule. priority must be unique and an integer from 1 to 2048.

• ruledef ruledef_name : Associates the rule with a specific ruledef. ruledef_name must be an existing ruledef within this local QoS policy service.

• actiondef actiondef_name : Associates the rule with a specific actiondef. actiondef_name must be an existing actiondef within this local QoS policy service expressed as an alphanumeric string of 1 through 63 characters.

• ecgi-change : Enables a new event to detect ECGI-CHANGE and applies specific action for the ECGI-CHANGE event as defined in actiondef configuration.

• continue : Subsequent rules are also matched; otherwise, rule evaluation is terminated on first match.

• priority priority : Specifies a priority for the specified condition. priority must be unique and an integer from 1 to 2048.

• ecgi mcc mcc_num mnc mnc_num eci : Configures ECGI with values for MCC, MNC and ECI.

  • mcc mcc_num : MCC is a three digit number between 001 to 999. It is a string of size 3 to 3.

  • mnc mnc_num : MNC is a two/three digit number between 01 to 999. It is a string of size 2 to 3.

  • eci : ECI is a hexadecimal number between 0x1 to 0xfffffff. It is a string of size 1 to 7.

• This CLI command is configured in local-policy if operator wants to take specific action based on certain ECGI value received in ECGI-Change event notification by MME.

• virtual-apn : This keyword enables configuration of Gx-based Virtual APN Selection feature. By default, this feature is disabled.
• This keyword is license dependent. For more information, contact your Cisco account representative.

• Assuming that NetLoc feature is enabled on chassis and Access Network Information (ANI-45) Event trigger is installed, following behavior changes have been introduced:

  Table 5. Gx Interface Behavior Change Towards PCRF

  PCRF Gx Interface Interaction	Access Side Interaction	ULI & MS TZ Behavior Before 21.1 Release(Standard Gx-R8/Custom15 (AT&T))	ULI & MS TZ Behavior Change(Standard Gx-R8/Custom15 (AT&T))
  RAI AVP with '0 - ULI' is received in the charging rule install request.	Create Bearer Response is received with only New ULI parameter.	Create Bearer Response is received with only New ULI parameter.	No change in the behavior.
  RAI AVP with '0 - ULI' is received in the charging rule install request.	Create Bearer Response is received with No ULI parameter.	Old ULI parameter is sent towards the PCRF in the CCR-U message.	PLMN-id in 3GPP-SGSN-MCC-MNC AVP is sent towards the PCRF.
  RAI AVP with '0 - ULI' is received in the charging rule modify request.	Update Bearer Response is received with only New ULI parameter.	New ULI parameter is sent towards the PCRF in the CCR-U message.	No change in the behavior.
  RAI AVP with '0 - ULI' is received in the charging rule Modify request.	Update Bearer Response is received with No ULI parameter.	Old ULI parameter is sent towards the PCRF in the CCR-U message.	PLMN-id in 3GPP-SGSN-MCC-MNC AVP is sent towards the PCRF.
  RAI AVP with '0 - ULI' is received in the charging rule modify request.	Delete Bearer Response is received with only New ULI parameter and No MS TZ parameter.	New ULI and old MS TZ parameters are sent towards the PCRF in the CCR-U message.	Only New ULI is sent towards the PCRF in the CCR-U message.
  RAI AVP with '0 - ULI' is received in the charging rule Modify request.	Delete Bearer Response is received with No ULI parameter and No MS TZ parameter.	Old ULI and old MS TZ parameters are sent towards the PCRF in the CCR-U message.	PLMN-id in the 3GPP-SGSN-MCC-MNC AVP is sent towards the PCRF.
  RAI AVP with '1 -MSTZ' is received in the charging rule install request.	Create Bearer Response is received with only new MS TZ parameter.	New MS TZ parameter is sent towards the PCRF in the CCR-U message.	No change in the behavior.
  RAI AVP with '1 - MSTZ' is received in the charging rule install request.	Create Bearer Response is received with No MS TZ parameter.	Old MS TZ parameter is sent towards the PCRF in the CCR-U message.	No change in the behavior.
  RAI AVP with '1 -MSTZ' is received in the charging rule modify request.	Update Bearer Response is received with only New MS TZ parameter.	New MS TZ parameter is sent towards the PCRF in the CCR-U message.	No change in the behavior.
  RAI AVP with '1 -MSTZ' is received in the charging rule Modify request.	Update Bearer Response is received with No MS TZ parameter.	Old MS TZ parameter is sent towards the PCRF in the CCR-U message.	No change in the behavior.
  RAI AVP with '1 -MSTZ' is received in the charging rule modify request.	Delete Bearer Response is received with only New MS TZ parameter.	Old ULI and New MS TZ parameters are sent towards the PCRF in the CCR-U message.	Only New MS TZ is sent towards the PCRF in the CCR-U message.
  RAI AVP with '1 -MSTZ' is received in the charging rule Modify request.	Delete Bearer Response is received with No MS TZ parameter.	New ULI and old MS TZ parameters are sent towards the PCRF in the CCR-U message.	Only old MS TZ is sent towards the PCRF.
  Nothing is received.	Delete Session Request is received with New ULI and New MS TZ parameters.	New ULI and New MS TZ parameters are sent towards the PCRF in the CCR-T message.	No change in the behavior.
  Nothing is received.	Delete Session Request is received with New ULI and No MS TZ parameter.	New ULI and Old MS TZ parameters are sent towards the PCRF in the CCR-T message.	No change in the behavior.
  Nothing is received.	Delete Session Request is received with No ULI and No MS TZ parameter.	Old ULI and Old MS TZ parameters are sent towards the PCRF in the CCR-T message.	No change in the behavior.

  Important

  ULI and ULI timestamp is considered as paired. If the ULI timestamp is forwarded, it is forwarded and received with the ULI. If the ULI is received and the ULI timestamp is not received, then that P-GW does not forward the old timestamp.

• Inclusion of AVP support of NETLOC-ACCESS-NOT-SUPPORTED on Gx interface. This inclusion of AVP is based on the below conditions:

  • RAT type is other than E-UTRAN, UTRAN, WCDMA, GPRS, GERAN, and W-LAN
  • IP CAN type is other than 3GPP EPS, GPRS, and non 3GPP EPS
  • Re-Auth-Request is received with Required-Access-Info AVP.
  • NetLoc feature is enabled on the chassis.
  • Event-Trigger ACCESS_NETWORK_INFO_REPORT (45) is installed.

  Before Release 21.1 Behavior (Standard Gx-R8/Custom15(AT&T))	New Behavior(Standard Gx-R8/Custom15(AT&T))
  Earlier, if IP-CAN type or RAT type was not support NETLOC, P-GW(PCEF) ignored RAI received from the PCRF.	New AVP NetLoc-Access-Support has been added in the Re-Auth-Answer message in the R8-Gx-standard and the Custom15 Gx Dictionary.

• Table 6. Behavior Change Regarding LastUserLocationInformation AVP and LastMSTimeZone AVP

  P-GW CDR Behavior	Post 21.1 Release, Behavior in Custom 35/Custom 24/Custom 48 Dictionaries	Custom52 Dictionary (standard compliance new dictionary)/ Custom 35 Dictionary (Customer Specific)
  ULI is received in Delete Bearer Command/Delete Bearer Request /Delete Session Request.	ULI was not part of P-GW CDR generation.	ULI is recorded as LastUserLocationInformation AVP in the P-GW CDR generation. (AVP is not controlled using the CLI command.)
  MS TZ is received in the Delete Bearer Command/Delete Bearer Request /Delete Session Request.	MS TZ was not part of P-GW CDR generation.	MS TZ is recorded as LastMSTimeZone AVP in the P-GW CDR generation. CDR is released as Normal Release. MS TZ is not detected in this case as full trigger and does not release extra CDR with MS TZ changes cause. AVP is not controlled using the CLI command.
  S-GW CDR behavior	Post 21.1 Release behavior in Custom 35/Custom 24 Dictionary	Custom24 Dictionary (standard dictionary)/ Custom 35 Dictionary (AT&T)
  ULI is received in Delete Bearer Command/Delete Bearer Request /Delete Session Request.	ULI was not part of CDR generation.	ULI is Recorded as LastUserLocationInformation AVP in the S-GW CDR generation. The attribute is controlled using a CLI command.
  MS TZ is received in Delete Bearer Command/Delete Bearer Request /Delete Session Request.	MS TZ was not part of CDR generation.	MS TZ is Recorded as LastMSTimeZone AVP in S-GW CDR generation. The attribute is controlled using a CLI command. CDR is released as Normal Release. MS TZ is not detected in this case as full trigger and does not release extra CDR with MS TZ changes cause.

• Failed Create Bearer Response

• Failed Update Bearer Response

• Delete Session Request

• Delete Bearer Response

• Delete Bearer Command

 show ims-authorization sessions full all 
 
 CallId: 00004e29            Service Name:  ims-ggsn-auth 
   IMSI: 123456789012341 
   .... 
 
 Negotiated Supported Features: 
   3gpp-r8 
   mission-critical-qcis  
   .... 

• HSS-based P-CSCF Restoration for Trusted/Untrusted WLAN Access (S2a/S2b)

• PCRF-based P-CSCF Restoration for LTE (S5/S8) and Trusted/Untrusted WLAN Access (S2a/S2b)

  Important

  HSS-based P-CSCF Restoration was supported at P-GW for LTE (S5/S8) prior to StarOS release 21.0.

• HSS-based P-CSCF Restoration for WLAN:

  If the P-CSCF restoration mechanism is supported, gateway indicates the restoration support to AAA server through Feature-List AVP in the Authorization Authentication Request (AAR) message sent over S6b interface. The Feature-List AVP is part of the Supported-Features grouped AVP. The Bit 0 of the Feature-List AVP is used to indicate P-CSCF Restoration support for WLAN.

  During the P-CSCF Restoration, 3GPP AAA server, after having checked that the PGW supports the HSS-based P-CSCF restoration for WLAN, sends a P-CSCF restoration indication to the P-GW over S6b in a Re-authorization Request (RAR) command. A new Diameter AVP “RAR-Flags” is encoded in the RAR message with the Bit 1 set, would indicate to the gateway that the AAA server requests the execution of HSS-based P-CSCF restoration procedures for WLAN.

  The existing CLI command diameter authentication under AAA Group configuration is extended to encode P-CSCF Restoration feature as part of Supported-Features AVP in the AAR message.

  Important

  Supported-Features will be sent in every AAR message for RAT type WLAN. Feature negotiation is required in every AAR. ReAuth AAR will also do the feature renegotiation.

• PCRF-based P-CSCF Restoration:

  PCEF supporting P-CSCF restoration mechanism indicates the restoration support in CCR-I message through the Supported-Features AVP. The 24th Bit of the Supported-Feature-List AVP indicates whether this mechanism is supported or not.

  The existing CLI command diameter encode-supported-features in Policy Control configuration is extended to allow the negotiation of P-CSCF Restoration feature support with PCRF. A new Diameter AVP “PCSCF-Restoration-Indication” is introduced to indicate to PCEF that a P-CSCF Restoration is requested. This is achieved by setting AVP value to 0.

  Supported-Features AVP is negotiated in CCR-I of all access types (eHRPD, P-GW, GGSN); however, Restoration trigger, if received, is ignored in eHRPD and GGSN.

• encode-supported-features : Encodes Supported-Features AVP.

• pcscf-restoration-indication : Enables the P-CSCF Restoration Indication feature.

• default encode-supported-features : Configures the default setting, that is not to send the Supported-Features AVP in AAR message.

• no encode-supported-features : Disables the CLI command to not send the Supported-Features AVP.

• The pcscf-restoration-indication keyword is license dependent. For more information, contact your Cisco account representative.

• pcscf-restoration-ind : Enables the P-CSCF Restoration Indication feature. This keyword is license dependent. For more information, contact your Cisco account representative. By default, this feature is disabled.

• default encode-supported-features : The default configuration is to remove/reset the supported features.

• no encode-supported-features : Removes the previously configured supported features.

• Verify if the feature is enabled using show ims-authorization sessions full all and show aaa group all CLI commands. If not enabled, configure the required CLI commands both under Policy Control and AAA group configuration and check if it works.

• Execute monitor protocol command and check if the support for P-CSCF Restoration feature is negotiated in CCR-I and AAR messages. If not, enable the respective CLI commands for this feature to work.

• If the failure is still observed, obtain the following information and contact Cisco account representative for further analysis:

  • Monitor protocol log with options 74 (EGTPC) and 75 (App Specific Diameter –Gx/S6b) turned on

  • Logs with sessmgr, imsa, and diameter-auth enabled

  • Output of show session disconnect reason CLI command and the relevant statistics at service level

<<<<OUTBOUND  15:37:23:561 Eventid:92870(5) 
.... 
 [V] [M] Supported-Features:  
   [M] Vendor-Id: 10415  
   [V] Feature-List-ID: 1  
   [V] Feature-List: 1  
.... 

INBOUND>>>>>  15:37:23:562 Eventid:92871(5) 
.... 
 [V] [M] Supported-Features:  
   [M] Vendor-Id: 10415  
   [V] Feature-List-ID: 1  
   [V] Feature-List: 1  
.... 

INBOUND>>>>>  15:37:43:562 Eventid:92871(5) 
.... 
[M] Re-Auth-Request-Type: AUTHORIZE_ONLY (0) 
[V] RAR-Flags: 2  
.... 

<<<<OUTBOUND  13:52:06:117 Eventid:92820(5) 
.... 
 [V] [M] Supported-Features:  
   [M] Vendor-Id: 10415  
   [V] Feature-List-ID: 1  
   [V] Feature-List: 16777217   
.... 

INBOUND>>>>>  13:52:06:118 Eventid:92821(5) 
.... 
 [V] [M] Supported-Features:  
   [M] Vendor-Id: 10415  
   [V] Feature-List-ID: 1  
   [V] Feature-List: 16777216  
.... 

INBOUND>>>>>  13:52:26:119 Eventid:92821(5) 
.... 
[M] Re-Auth-Request-Type: AUTHORIZE_ONLY (0) 
[V] PCSCF-Restoration-Indication: 0  
.... 

• Recovery/ICSR behavior: Interim interval configuration used at the time of PDN creation is applicable for entire lifetime of PDN. Recovery/ICSR will not have any impact of existing PDN behavior with regard to Diameter interim interval.

• ICSR Upgrade/Downgrade behavior:

  • Existing session will be recovered based on RADIUS configuration present in old chassis.

  • New session behavior is as per configuration available on newly active chassis.

configure  
     context  context_name 
        aaa group  group_name 
            diameter accounting interim interval  interval_in_seconds 
            end  

• interval_in_seconds: Specifies the interim interval, and must be in the range of 50 through 40000000.

• If previously configured, use the no diameter accounting interim interval to disable the interim accounting messages on Rf interface.

• There is no default Diameter interim interval value.

• In case Diameter interim interval CLI is not configured, the P-GW retains the older behavior where Diameter accounting uses RADIUS interim interval configuration available in AAA server group configuration block.

• Bearer deactivation (Delete Bearer Response/Delete Bearer Command)

• Session deactivation (Delete Session Request)

• Bearer creation/modification failures (Create/Update Bearer Response with cause as FAILURE)