Application Assurance — Usage Monitoring and Policy Control via Diameter Gx Protocol
This chapter provides information about the diameter (Gx) control feature.
Topics in this chapter include:
Applicability
This chapter was initially based on SR OS Release 13.0.R1, but the Diameter Base configuration in the current edition is based on SR OS Release 19.10.R1.
Overview
The Gx reference point is defined in the Policy and Charging Control (PCC) architecture within the 3rd Generation Partnership Project (3GPP) standardization body. The Gx reference point is used for policy and charging control. The PCC architecture is defined in the 23.203 3GPP technical specification, while the Gx functionality is defined in the 29.212 3GPP technical specification. The SR OS implementation of Gx supports both Release 11 and Release 12 of the specification. Gx is an application of the Diameter Base Protocol (RFC 6733).
As shown in Gx reference point, Gx is placed between a policy server Policy and Charging Rule Function (PCRF) and a traffic forwarding node Policy and Charging Enforcement Function (PCEF) that enforces rules set by the policy server.
Although the Gx reference point is defined within the 3GPP standardization body, its applicability has also spread to wire-line operations to achieve mobile–fixed convergence gains by streamlining policy management functions into a single Gx based infrastructure, see Convergence.
Gx support on SR OS is applicable to Enhanced Subscriber Management (ESM) functions, including the Application Assurance (AA) functions. The focus of this chapter is on the AA aspects of Gx.
The SR OS based Gx interface offers the following functionalities:
ESM subscriber-based policy decision providing
QoS attributes
charging attributes
subscriber identification
Usage management
usage reporting from PCEF to PCRF
Note that Gx does not provide subscriber authentication or subscriber IP address assignment.
Policy assignment use case
The SR OS accepts the following policy information from PCRF using Gx:
Subscriber profile strings and SLA profile strings.
Subscriber-QoS-overrides.
Application profile strings.
Application subscriber options (ASOs) related to AA.
Gx operates at subscriber host level and creates an ‟IP-CAN Session” (IP Connectivity Access Network) for every subscriber host. However, as AA operates at the subscriber level, AA related policies apply to all the hosts belonging to that subscriber.
This chapter covers AA related functionalities, namely: application profile and ASO assignments and override. These functionalities are defined in either:
Application Detection and Control (ADC) rules—per 3GPP Release 11— or
Policy and Charging Control (PCC) rules—per 3GPP Release 12—.
Application Profile Alc-AA-Profile-Name Attribute-Value-Pair (AVP)
RADIUS equivalent is Alc-App-Prof-Str Vendor-Specific-Attribute (VSA)
ASO overrides Alc-AA-Service-Options AVP
RADIUS equivalent is Alc-AA-App-Service-Options VSA
Details of the ADC rules and related Nokia defined AVPs defined for use by AA are shown in ADC rules and related Nokia-defined AVPs defined for use by AA.
The ADC-Rule-Install is at the root level of the GX message.
As for 3GPP Release 12, the details of the PCC rules and related Nokia-defined AVPs defined for use by AA are shown in PCC rules and related Nokia-defined AVPs defined for use by AA.
The PCC-Rule-Install, as in the case of ADC-Rule-Install, is at the root level of the GX message.
An example of the AVPs to install the application profile ‟gold_level” using 3GPP Release 11 (/ADC rules) is shown in PCC rules and related Nokia-defined AVPs defined for use by AA.
An example of the AVPs to install the ‟gold_level” application profile using 3GPP Release 12 (/PCC rules) is shown in Capture of the ADC rule assignment of the ‟gold_level” appProfile.
ADC-Rule-Names and PCC-Rule-Names have to start with aa-functions when they contain an Alc-AA-Functions AVP.
The assignment of the gold_level appProfile is shown in another format in Capture of the ADC rule assignment of the ‟gold_level” appProfile.
Application profiles and ASO overrides can be changed on-the-fly with a Re-Authentication-Request (RAR) message according to these rules:
If an Application profile is present in the Gx message it is applied first. Then ASO AVPs are applied when present (in the Gx message). In other words:
If a RAR message only contains the same application profile and no ASO overrides, then all previous ASO overrides are removed.
When a RAR message contains the same application profile and new ASO overrides, then the new ASO overrides are applied, and the previous ASO overrides are removed.
When a RAR message contains a new application profile, all previous ASO overrides are removed and replaced with the ASOs in the RAR if present.
When a RAR message does not contain an application profile but only ASO overrides, then the new ASO overrides are added to the existing ASO overrides.
Note that a single Gx ADC (or PCC) rule cannot contain both AA subscriber policies (appProfile/ASO) and AA Usage monitoring (as outlined later). These have to be in separate ADC (or PCC) rules.
Usage management/monitoring use-case
The AA-ISA can monitor application usage at the subscriber level and report back to the PCRF whenever the usage exceeds the threshold(s) set by the PCRF when receiving requests from the PCRF over the Gx interface.
Usage monitoring can be used by operators to report to PCRF when:
The AA-ISA detects the start of a subscriber application by setting the usage threshold to a very low value.
A pre-set usage volume per subscriber application is exceeded.
AA can monitor subscriber’s traffic for any defined:
Application
Application group, and/or
Charging group
The AA-ISA reports the accumulated usage when:
A usage threshold is reached.
The PCRF explicitly disables the usage monitoring.
The PCRF requests a report.
The ADC (or PCC) rule associated with the monitoring instance is removed or deactivated.
A session is terminated.
An AA defined application, application group and/or charging group is automatically allowed to be referenced by an ADC (or PCC) rule for the purpose of usage monitoring only if:
{It is already selected for either XML or RADIUS per subscriber accounting
OR
It is explicitly enabled by the operator for per subscriber statistics collection}
AND
Usage monitoring is enabled for the given AA group:partition
Call flow diagram illustrates the different messaging/call flows involved in application level usage monitoring. Details of the different supported AVPs used in these messages are illustrated later.
The AA-ISA/PCEF supports Usage-Thresholds AVPs that refer to the thresholds (in bytes) at which point an event needs to be sent back to the PCRF, (see PCC rule example of AVPs to install the application profile ‟gold_level”).
Time based thresholds are not supported.
AA supports the ‟grant-service-unit” AVP using the following possible values (AVP):
CC-Input-Octets AVP (code 412): from subscriber total byte count threshold.
CC-Output-Octet AVP (code 414): to subscriber total byte count threshold.
CC-Total-octets AVP (code 421): threshold of aggregate traffic (input and output byte counters).
As shown in Call flow diagram, (T=7), AA sends a Credit Control Request (CCR_ message) with a "USAGE_REPORT" Event-Trigger AVP to the PCRF when the usage counter reaches the configured usage monitoring threshold for a given subscriber (and given application group). AA counters are reset (to zero) when the monitoring threshold is reached (and an event is sent back to the PCRF). The counter(s) however does not stop counting newly arriving traffic. AA counters only include ‟admitted” packets. Any packets that were discarded by AA due to, for example, policing actions are not counted for usage-monitoring purposes.
The TDF-Application-Identifier AVP (within the ADC or PCC rule) refers to an AA Charging group, an AA application group or to an AA application. TDF-Application-Identifiers (for example, charging-groups) have to be manually entered at the PCRF to match the AA charging groups defined in the AA. If the TDF-Application-Identifier refers to a name that is used for both a charging group and an application (or an application group), AA monitors the charging group. In other words, the AA charging group has a higher precedence than the AA application group.
Gx usage monitoring AVP summary
For 3GPP Release 11 (using ADC rules), the following AVPs are used for AA-Usage monitoring:
ADC-Rule-Install ::= < AVP Header: 1092 >
*[ ADC-Rule-Definition ]
*[ ADC-Rule-Name ]
ADC-Rule-Definition ::= < AVP Header: 1094 >
{ ADC-Rule-Name }
[ TDF-Application-Identifier ]; AA app/app-grp/chrg-grp
[ Monitoring-Key ];
Usage-Monitoring-Information::= < AVP Header: 1067 >
[ Monitoring-Key ]
0,2[ Granted-Service-Unit ]
Granted-Service-Unit ::= < AVP Header: 431 >
[ CC-Total-Octets ]
[ CC-Input-Octets ]
[ CC-Output-Octets ]
0,2[ Used-Service-Unit ]
Used-Service-Unit ::= < AVP Header: 446 >
[ CC-Total-Octets ] ;
[ CC-Input-Octets ]
[ CC-Output-Octets ]
[ Usage-Monitoring-Level ]
; ADC_RULE_LEVEL (2)
[ Usage-Monitoring-Report ]
; immidiate report -- USAGE_MONITORING_REPORT_REQUIRED (0)
[ Usage-Monitoring-Support ]
; to disable : USAGE_MONITORING_DISABLED (0)
For 3GPP Release 12 (using PCC rules), the following AVPs are used for AA-Usage monitoring:
Charging-Rule-Install ::= < AVP Header: 1001 >
*[ Charging-Rule-Definition ]
*[ Charging-Rule-Name ]
Charging-Rule-Definition ::= < AVP Header: 1003 >
{ Charging-Rule-Name } ;/ starts with ‟UM-AA:”
[ TDF-Application-Identifier ]; AA app/app-grp/chrg-grp
[ Monitoring-Key ];
Usage-Monitoring-Information::= < AVP Header: 1067 >
[ Monitoring-Key ]
0,2[ Granted-Service-Unit ]
Granted-Service-Unit ::= < AVP Header: 431 >
[ CC-Total-Octets ]
[ CC-Input-Octets ]
[ CC-Output-Octets ]
0,2[ Used-Service-Unit ]
Used-Service-Unit ::= < AVP Header: 446 >
[ CC-Total-Octets ] ;
[ CC-Input-Octets ]
[ CC-Output-Octets ]
[ Usage-Monitoring-Level ]
; PCC_RULE_LEVEL (1)
[ Usage-Monitoring-Report ]
; immidiate report -- USAGE_MONITORING_REPORT_REQUIRED (0)
[ Usage-Monitoring-Support ]
; to disable : USAGE_MONITORING_DISABLED (0)
Configuration
This configuration example highlights the commands illustrating how Gx can be used to:
Override AppProfile and ASO characteristics.
Set and retrieve AA level usage monitoring metrics.
While the configuration associated with setting up the Gx interface toward the PCRF is shown for the sake of completeness, that aspect of the configuration is not explored in detail, and only a 3GPP Release 11 model is shown Similarly, the Gx policies and usage monitoring associated with ESM host policies (non-AA aspects) are out of the scope of this chapter.
The configuration on the 7750 node is the same, independent of whether the PCRF supports 3GPP Release 11 (ADC) or Release 12(PCC) to provide AA policy control function.
The BNG is set up with at least one IOM and one MS-ISA MDA configured as ISA-AA.
configure
card 1
card-type iom3-xp
mda 1
mda-type m20-1gb-xp-sfp
no shutdown
exit
mda 2
mda-type isa-aa
no shutdown
exit
no shutdown
exit
card 3
card-type iom3-xp
mda 1
mda-type isa-aa
no shutdown
exit
mda 2
mda-type isa-aa
no shutdown
exit
no shutdown
exit
The configurations in this example are broken down into four main steps:
Configuring the Gx interface (high-level)
Configuring AA application profiles and ASOs (high-level)
Configuring AA applications filters (high-level)
Configuring AA usage-monitoring
The focus of this configuration example is on Step 4, and the updated show routines related to AA ESM subscriber state are shown at the end of Step 2.
Configuring the Gx interface (high-level).
These commands bring up the Gx diameter control channel between the Gx Controller(/Server), also known as PCRF, and the PCEF(/BNG).
configure aaa diameter node "bng-gx.realm-1.com" create description "Authentication and Policy Management" source-address 192.0.2.2 peer index 1 "dra-1.realm-1.com" create address 10.1.0.10 no shutdown exit exit exit exit exitThe diameter node ‟bng-gx.realm-1.com” is then referenced under subscriber management.
configure subscriber-mgmt diameter-application-policy "diamAppPlcy" create application gx diameter-node "bng-gx.realm-1.com" destination-realm "realm-1.com" exit exitThen the created subscriber management policy ‟diamAppPlcy” is applied to the subscriber interface.
configure service customer 1 create description "Default customer" exit ies 1 customer 1 vpn 1 create description "Default Ies description for service id 1" subscriber-interface "ies-1-172.16.0.0" create address 172.16.0.0/12 group-interface "grp-1-35782656-1" create dhcp server 172.16.200.200 trusted lease-populate 2000 gi-address 172.16.0.0 no shutdown exit diameter-application-policy "diamAppPlcy" sap 1/1/4:1 create description "sap-grp-1" sub-sla-mgmt def-sub-profile "sub_prof" def-sla-profile "sla_prof" def-app-profile "app_prof_1" sub-ident-policy "sub_ident_A_1" multi-sub-sap 2 no shutdown exit exit exit exit service-name "ACG Ies 1" no shutdown exitNow verify the configuration and connectivity towards the PCRF by running the following command:
# show aaa diameter-node "bng-gx.realm-1.com" peers =============================================================================== Peers =============================================================================== Host identity Status Default Preference Active ------------------------------------------------------------------------------- dra-1.realm-1.com I-Open No 50 Yes ------------------------------------------------------------------------------- No. of peers: 1 ===============================================================================The Peer-State-Machine State (PSM), as per RFC 6733, has the value I-OPEN indicating that the peer is operational. The ‟I-” stands for Initiator state, in this case the BNG is the initiator.
A detailed look into the traffic statistics between the PCEF and the PCRF (Gx controller) can be viewed using a show statistics command (see below). These statistics provide a breakdown of the messages exchanged:
# show aaa diameter-node "bng-gx.realm-1.com" peer "dra-1.realm-1.com" statistics =============================================================================== Peer "dra-1.realm-1.com" =============================================================================== Message Sent Received ------------------------------------------------------------------------------- Capabilities-Exchange-Request 7 0 Capabilities-Exchange-Answer 0 7 Disconnect-Peer-Request 0 0 Disconnect-Peer-Answer 0 0 Device-Watchdog-Request 1217 778 Device-Watchdog-Answer 778 1217 Application message request 0 0 Application message answer 0 0 Last cleared time: N/A =============================================================================== # show subscriber-mgmt diameter-application-policy "diamAppPlcy" statistics =============================================================================== Diameter node statistics for policy "diamAppPlcy" =============================================================================== Message Requests Answers ------------------------------------------------------------------------------- Initial Credit-Control 2 2 Update Credit-Control 14 14 Termination Credit-Control 1 1 Re-Auth 2 2 Abort-Session 0 0 ------------------------------------------------------------------------------- Request message transmission failur* 0 Request message retransmissions 0 Result code Sent Received ------------------------------------------------------------------------------- (1xxx) Informational 0 0 (2xxx) Success 0 14 (3xxx) Protocol Errors 0 0 (4xxx) Transient Failures 0 0 (5xxx) Permanent Failures 0 0 =============================================================================== * indicates that the corresponding row element may have been truncated.Configuring AA application profiles and ASOs (high-level)
To illustrate the use of application profiles and ASO overrides using Gx RAR messages, four ASOs and 2 appProfiles are defined, as follows.
‟app_prof_1” is the default app-profile used when a subscriber is created on AA.
configure application-assurance group 129:34883 create policy begin app-service-options characteristic "permitDNS" persist-id 1 create value "no" value "yes" default-value "yes" exit characteristic "permitRDP" persist-id 2 create value "no" value "yes" default-value "yes" exit characteristic "permitHTTP" persist-id 3 create value "no" value "yes" default-value "yes" exit exit app-profile "app_prof_1" create description "Application Profile Id app_prof_1" divert exit app-profile "app_prof_2" create description "Application Profile Id app_prof_2" divert exitConfiguring AA applications filters (high-level)
First create the application group, as follows.
configure isa application-assurance-group 129 create primary 3/2 backup 1/2 partitions divert-fc be no shutdown exitThen create the partition and associated charging groups, application groups, applications, etc.
configure application-assurance group 129:34883 create policy begin charging-group "0_rated" create export-id 1 exit charging-group "default_charge_group" create export-id 255 exit default-charging-group "default_charge_group" app-group "Other" create export-id 8 exit app-group "Peer to Peer" create export-id 3 exit app-group "Remote Connectivity" create export-id 4 exit app-group "Unknown" charging-group "0_rated" export-id 1 exit app-group "Web" create export-id 10 exit application "DNS" create description "default-description for application DNS" app-group "Other" export-id 12 exit application "BitTorrent" create app-group "Peer to Peer" export-id 3 exit application "HTTP" create description "default-description for application HTTP" app-group "Web" export-id 26 exit application "RDP" create description "default-description for application RDP" app-group "Remote Connectivity" export-id 61 exit application "Unknown" charging-group "0_rated" export-id 1 exit exit commit exit exit exitExample app-filter definitions defining HTTP, DNS, Bittorrent and RDP applications are as follows.
configure application-assurance group 129:34883 policy begin app-filter entry 6 create description "default-description for AppFilter entry 6" protocol eq "rdp" ip-protocol-num eq tcp application "RDP" no shutdown exit entry 9 create description "default-description for AppFilter entry 9" protocol eq "dns" ip-protocol-num eq udp server-port eq range 53 55 application "DNS" no shutdown exit entry 20 create description "default-description for AppFilter entry 20" protocol eq "bittorrent" ip-protocol-num eq tcp application "BitTorrent" no shutdown exit entry 38 create description "default-description for AppFilter entry 38" protocol eq "http" ip-protocol-num eq tcp server-port gt 8738 application "HTTP" no shutdown exit exit commit exit exit exitNote:The focus of this example is on the definition of app-filters and/or AQPs. These are listed above (and below) for illustration purposes. The ‟sample” AQP configurations and app-filters shown here should not be used in a real-life configuration. Their configuration should follow the information in Application Assurance — Application Identification and User-Defined Applications.
Example AQP configurations for blocking DNS, RDP and HTTP traffic are as follows.
configure application-assurance group 129:34883 policy begin app-qos-policy entry 2 create match application eq "DNS" characteristic "permitDNS" eq "no" exit action drop exit no shutdown exit entry 3 create match application eq "HTTP" characteristic "permitHTTP" eq "no" ip-protocol-num neq 0 exit action drop exit no shutdown exit entry 4 create match application eq "RDP" app-group eq "Remote Connectivity" characteristic "permitRDP" eq "no" ip-protocol-num neq udp exit action drop exit no shutdown exit exit commit exit exit exitWhen an ESM subscriber is created, it is associated with the default AA app-profile, as seen using the show command below.
*A:BNG-1>show>app-assure>group# aa-sub esm "sub_172.16.0.2" summary =============================================================================== Application-Assurance Subscriber Summary (realtime) =============================================================================== AA-Subscriber : sub_172.16.0.2 (esm) ISA assigned : 3/2 App-Profile : app_prof_1 App-Profile divert : Yes Capacity cost : 1 Aarp Instance Id : N/A HTTP URL Parameters : (Not Specified) Last HTTP Notified Time : N/A ------------------------------------------------------------------------------- Traffic Octets Packets Flows ------------------------------------------------------------------------------- From subscriber: Admitted 0 0 0 Denied 0 0 0 Active flows 0 To subscriber: Admitted 0 0 0 Denied 0 0 0 Active flows 0 Flow counts: Terminated 0 Short duration 0 Med duration 0 Long duration 0 Total flow duration : 0 seconds ------------------------------------------------------------------------------- Top App-Groups Octets Packets Flows ------------------------------------------------------------------------------- None ------------------------------------------------------------------------------- Application Service Options (ASO) ------------------------------------------------------------------------------- Characteristic Value Derived from ------------------------------------------------------------------------------- permitDNS yes default permitRDP yes default permitHTTP yes default =============================================================================== *A:BNG-1>show>app-assure>group#After the PCRF sends out AppProfile and ASO override AVPs, using either PCC or ADC rules, in RAR messages (as shown below) it can be seen that the new parameters (new profile and new values for permitDNS and permitHTTP ASOs) are updated for that ESM subscriber.
Figure 12. PCRF AVPs override call flow diagram 
Figure 13. RAR containing ASOs and AppProfile override AVPs example 
*A:BNG-1>show>app-assure>group# aa-sub esm "sub_172.16.0.2" summary =============================================================================== Application-Assurance Subscriber Summary (realtime) =============================================================================== AA-Subscriber : sub_172.16.0.2 (esm) ISA assigned : 3/2 App-Profile : app_prof_2 App-Profile divert : Yes Capacity cost : 1 Aarp Instance Id : N/A HTTP URL Parameters : (Not Specified) Last HTTP Notified Time : N/A ------------------------------------------------------------------------------- Traffic Octets Packets Flows ------------------------------------------------------------------------------- From subscriber: Admitted 0 0 0 Denied 0 0 0 Active flows 0 To subscriber: Admitted 0 0 0 Denied 0 0 0 Active flows 0 Flow counts: Terminated 0 Short duration 0 Med duration 0 Long duration 0 Total flow duration : 0 seconds ------------------------------------------------------------------------------- Top App-Groups Octets Packets Flows ------------------------------------------------------------------------------- None ------------------------------------------------------------------------------- Application Service Options (ASO) ------------------------------------------------------------------------------- Characteristic Value Derived from ------------------------------------------------------------------------------- permitDNS no dyn-override permitRDP yes default permitHTTP no dyn-override ===============================================================================Configuring AA usage monitoring
Once the applications, application groups and/or charging groups are defined and configured (see previous steps), the operator needs:
to enable the collection of per-subscriber statistics so they can be used for Gx based usage-monitoring. This step is not needed for any app/appgrp or charging group that is already enabled for per-subscriber statistics. In other words, if XML or RADIUS accounting is enabled for a given app/appgrp or charging group, then Gx usage-monitoring is also automatically enabled.
to enable usage-monitoring for the given AA group:partition.
configure application-assurance group 129:34883 statistics aa-sub usage-monitoring app-group "Unknown" export-using accounting-policy radius-accounting-policy charging-group "0_rated" export-using accounting-policy radius-accounting-policy charging-group "default_charge_group" export-using accounting-policy radius-accounting-policy application "BitTorrent" no-export exit
In the preceding example:
The usage-monitoring command is used to enable Gx usage monitoring for the specified AA partition.
The aa-group and charging-group commands specify which charging groups and AA groups are selected for export. In this case 0-rated, Unknown, and default_charge_group are selected for RADIUS accounting and they automatically qualify for Gx-usage monitoring.
The BitTorrent application however needs to be explicitly configured as ‟no-export” as it needs to be enabled for Gx-usage monitoring.
The operator can display the number of usage monitoring rules for a given subscriber. This is shown below after the ESM subscriber is created, but before any ADC rules are installed for usage-monitoring by PCRF, so AA reports that no rules apply (‟0”).
*A:BNG-1>show>app-assure>group# aa-sub esm "alcatel_A_1" usage-monitor status
===============================================================================
Application-Assurance Subscriber "alcatel_A_1" (esm)
Usage Monitor Status
===============================================================================
Type Name Oper Status
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
No. of rules: 0
===============================================================================
*A:BNG-1>show>app-assure>group#
The PCRF then sends a RAR message with a usage monitoring ADC or PCC rule for the BitTorrent application to set the usage thresholds for BitTorrent for the ESM subscriber ‟alcatel_A_1” to (in bytes):
Input (from sub) 1378168
Output (to sub) 1381148
Total traffic (up and down) 18446744073709551614
This is then reflected on the AA-ISA:
*A:BNG-1>show>app-assure>group# aa-sub esm "alcatel_A_1" usage-monitor status
===============================================================================
Application-Assurance Subscriber "alcatel_A_1" (esm)
Usage Monitor Status
===============================================================================
Type Name Oper Status
-------------------------------------------------------------------------------
application BitTorrent active
-------------------------------------------------------------------------------
No. of rules: 1
===============================================================================
*A:BNG-1>show>app-assure>group#
Note the ‟active” oper status is set since there is at least one usage monitoring threshold associated with this application.
Given that there is no traffic flowing yet to or from the subscriber the counters currently are ‟0”:
*A:BNG-1>show>app-assure>group# aa-sub esm "alcatel_A_1" usage-monitor count
===============================================================================
Application-Assurance Subscriber "alcatel_A_1" (esm)
Usage Monitor Credit Statistics
===============================================================================
Application: "BitTorrent"
Direction Status Granted Used % Used
-------------------------------------------------------------------------------
to sub valid 1378168 0 0%
from sub valid 1381148 0 0%
both valid 18446744073709551614 0 0%
===============================================================================
*A:BNG-1>show>app-assure>group#
The status is set to ‟valid” since a threshold (or Grant) is received.
When, at a later stage, traffic starts flowing again usage-monitor subscriber statistics are updated as shown below.
*A:BNG-1>show>app-assure>group# aa-sub esm "alcatel_A_1" usage-monitor count
===============================================================================
Application-Assurance Subscriber "alcatel_A_1" (esm)
Usage Monitor Credit Statistics
===============================================================================
Application: "BitTorrent"
Direction Status Granted Used % Used
-------------------------------------------------------------------------------
to sub valid 1378168 137816 10%
from sub valid 1381148 13781 1%
both valid 18446744073709551614 151597 5%
===============================================================================
*A:BNG-1>show>app-assure>group#
The PCRF can also at the same time set ADC or PCC rules for other applications (such as the 0_rated and the default_charging_group charging groups).
In the following case, the PCRF installs an ADC usage monitoring rule for:
Charging group: ‟0-rated”, but without usage thresholds
Charging group: ‟default_charge_group”, and sets only a threshold for ‟to sub” traffic.
This results in having a usage policy for the ‟0-rated” charging group installed but this is not active since there are no grants associated with it:
*A:BNG-1>show>app-assure>group# aa-sub esm "alcatel_A_1" usage-monitor status
===============================================================================
Application-Assurance Subscriber "alcatel_A_1" (esm)
Usage Monitor Status
===============================================================================
Type Name Oper Status
-------------------------------------------------------------------------------
application BitTorrent active
charging-group 0_rated inactive
charging-group default_charge_group active
-------------------------------------------------------------------------------
No. of rules: 3
===============================================================================
*A:BNG-1>show>app-assure>group#
Note that the ‟inactive” status for the ‟0-rated” charging group is due to no grants being received.
Moreover, detailed counters show:
*A:BNG-1>show>app-assure>group# aa-sub esm "alcatel_A_1" usage-monitor count
===============================================================================
Application-Assurance Subscriber "alcatel_A_1" (esm)
Usage Monitor Credit Statistics
===============================================================================
Application: "BitTorrent"
Direction Status Granted Used % Used
-------------------------------------------------------------------------------
to sub valid 1378168 137816 10%
from sub valid 1381148 13781 1%
both valid 18446744073709551614 151597 5%
-------------------------------------------------------------------------------
Charging-Group: "0_rated"
Direction Status Granted Used % Used
-------------------------------------------------------------------------------
to sub invalid n/a 0 n/a
from sub invalid n/a 0 n/a
both invalid n/a 0 n/a
-------------------------------------------------------------------------------
Charging-Group: "default_charge_group"
Direction Status Granted Used % Used
-------------------------------------------------------------------------------
to sub valid 1000000 1378084 100%
from sub invalid n/a 1574 n/a
both invalid n/a 1379658 n/a
===============================================================================
*A:BNG-1>show>app-assure>group#
Again, the ‟invalid” status above reflects the fact that no grants have been received.
Conclusion
The introduction of the diameter (/Gx) control feature on the SR-series BNG enables operators to consolidate policy management systems used in wire-line and wireless environments into a single system. This provides an increase in operational efficiency as mobile and fixed networks convergence gains more traction.
This example illustrates how policy control and usage monitoring of the SR-series BNG Application Assurance services can be achieved over standard 3GPP Diameter Gx protocol.