Gx Interface Support


Gx Interface Support
 
 
This chapter provides information on configuring Gx interface to support policy and charging control for subscribers in GPRS/UMTS networks.
The IMS service provides application support for transport of voice, video, and data independent of access support. Roaming IMS subscribers in GPRS/UMTS networks require apart from other functionality sufficient, uninterrupted, consistent, and seamless user experience during an application session. It is also important that a subscriber gets charged only for the resources consumed by the particular IMS application used.
It is recommended that before using the procedures in this chapter you select the configuration example that best meets your service model, and configure the required elements for that model as described in the Gateway GPRS Support Node Administration Guide or the IP Services Gateway Administration Guide.
Important: The IMS Authorization Service feature described in this chapter is only available if you have purchased and installed a Dynamic Policy Interface feature license on the chassis. If you have not previously purchased this enhanced feature, contact your sales representative for more information.
The following topics are covered in this chapter:
 
 
Rel. 6 Gx Interface
Important: The Rel 6. Gx functionality is supported on StarOS 8.0 and later.
This section describes the following topics:
 
 
Introduction
In GPRS/UMTS networks, the client functionality lies with the GGSN/IPSG, therefore in the IMS authorization scenario it is also called Access Gateway (AGW).
The provisioning of charging rules that are based on the dynamic analysis of flows used for the IMS session is carried out over the Gx interface. In 3GPP, Rel. 6 the Gx is an interface between Access Gateway functioning as Traffic Plane Function (TPF) and the Charging Rule Function (CRF). It is based on the Diameter base protocol (DIABASE) and the Diameter Credit Control Application (DCCA) standard. The GGSN/TPF acts as the client where as the CRF contains the Diameter server functionality.
The AGW is required to perform query, in reply to which the servers provision certain policy or rules that are enforced at the AGW for that particular subscriber session. The CRF analyzes the IP flow data, which in turn has been retrieved from the Session Description Protocol (SDP) data exchanged during IMS session establishment.
Important: In addition to standard Gx interface functionality, the Gx interface implemented here provides support of SBLP with additional AVPs in custom DPCA dictionaries. For more information on customer-specific support contact your local technical support representative. In view of required flow bandwidth and QoS, the system provides enhanced support for use of Service Based Local Policy (SBLP) to provision and control the resources used by the IMS subscriber. SBLP is based on the dynamic parameters such as the media/traffic flows for data transport, network conditions and static parameters, such as subscriber configuration and category. It also provides Flow-based Charging (FBC) mechanism to charge the subscriber dynamically based on content usage. With this additional functionality, the Cisco Systems Gateway can act as an Enhanced Policy Decision Function (E-PDF).
 
Licensing
This feature requires the following license to be installed on the chassis:
[ 600-00-7585 ] Dynamic Policy Interface — license for IMS Authorization Service feature
 
Supported Standards
The Rel 6. Gx interface support is based on the following standards and request for comments (RFCs):
 
In addition to the above RFCs and standards, IMS Authorization partially supports 3GPP TS 29.212 for Policy and Charging Control over Gx reference point functionality.
 
Supported Networks and Platforms
This feature is supported on all ASR 5000 Series Platforms with StarOS Release 8.0 or later running GGSN service for the core network services.
 
How it Works
This section describes the IMS authorization and dynamic policy support in GPRS/UMTS networks.
The following figure and table explain the IMS authorization process between a system and IMS components that is initiated by the MN.
In the case of GGSN, the DPCA is the Gx interface to the Control and Charging Rule Function (CRF). In this context CRF will act as Enhanced Policy Decision Function (E-PDF). The CRF may reside in Proxy-Call Session Control Function (P-CSCF) or on stand-alone system.
The interface between IMSA with CRF is the Gx interface, and between Session Manager and Online Charging Service (OCS) is the Gy interface.
Note that the IMS Authorization (IMSA) service and Diameter Policy Control Application (DPCA) are part of Session Manager on the system, and separated in the following figure for illustration purpose only.
 
Rel. 6 Gx IMS Authorization Call Flow
Rel. 6 Gx IMS Authorization Call flow Description
 
Configuring Rel. 6 Gx Interface
To configure Rel. 6 Gx interface functionality:
Step 1
Step 2
Step 3
Step 4
Step 5
Save your configuration as described in the Verifying and Saving Your Configuration chapter.
Important: Commands used in the configuration examples in this section provide base functionality to the extent that the most common or likely commands and/or keyword options are presented. In many cases, other optional commands and/or keyword options are available. Refer to the Command Line Interface Reference for complete information regarding all commands.
 
Configuring IMS Authorization Service at Context Level
Use the following example to configure IMS Authorization Service at context level for IMS subscribers in GPRS/UMTS networks:
configure
   context <context_name>
      ims-auth-service <ims_auth_service>
         p-cscf table { 1 | 2 } row-precedence <precedence_value> { address <ip_address> | ipv6-address <ipv6_address> }
         p-cscf discovery { table { 1 | 2 } [ algorithm { ip-address-modulus | msisdn-modulus | round-robin } ] | diameter-configured }
         policy-control
            diameter origin endpoint <endpoint_name>
            diameter dictionary <dictionary>
            failure-handling cc-request-type { any-request | initial-request | terminate-request | update-request } { diameter-result-code { any-error | <result_code> [ to <end_result_code> ] } } { continue | retry-and-terminate | terminate }
            diameter host-select row-precedence <precedence_value> table { 1 | 2 } host <host_name> [ realm <realm_name> ] [ secondary host <host_name> [ realm <realm_name> ] ]
            diameter host-select reselect subscriber-limit <subscriber_limit> time-interval <duration>
            diameter host-select table { 1 | 2 } algorithm { ip-address-modulus | msisdn-modulus | round-robin }
            end
Notes:
 
<context_name> must be the name of the context where you want to enable IMS Authorization Service.
<ims_auth_service> must be the name of the IMS Authorization Service to be configured for the Gx interface authentication.
qos-update-timeout <timeout_duration>
signaling-flag { deny | permit }
signaling-flow permit server-address <ip_address> [ server-port { <port_number> | range <start_number> to <end_number> } ] [ description <string> ]
traffic-policy general-pdp-context no-matching-gates direction { downlink | uplink } { forward | discard }
diameter host-select table { 1 | 2 } algorithm { ip-address-modulus | msisdn-modulus | round-robin }
 
Verifying IMS Authorization Service Configuration
To verify the IMS Authorization Service configuration:
Step 1
context <context_name>
Step 2
show ims-authorization service name <ims_auth_service>
 
Applying IMS Authorization Service to an APN
After configuring IMS Authorization service at the context-level, an APN within the same context must be configured to use the IMS Authorization service for an IMS subscriber.
 
Use the following example to apply IMS Authorization service functionality to a previously configured APN within the context configured in the Configuring IMS Authorization Service section.
configure
  context <context_name>
     apn <apn_name>
        ims-auth-service <ims_auth_service>
        end
Notes:
 
<context_name> must be the name of the context in which the IMS Authorization service was configured.
<ims_auth_service> must be the name of the IMS Authorization Service configured for IMS authentication in the context.
 
Verifying Subscriber Configuration
Verify the IMS Authorization Service configuration for subscriber(s) by entering the following command:
show subscribers ims-auth-service <ims_auth_service>
<ims_auth_service> must be the name of the IMS Authorization Service configured for IMS authentication.
 
Saving the Configuration
To save changes made to the system configuration, refer to the Verifying and Saving Your Configuration chapter.
 
Rel. 7 Gx Interface
Important: The Rel 7. Gx functionality is supported only on StarOS 8.1 and StarOS 9.0 and later.
This section describes the following topics:
 
 
Introduction
For IMS deployment in GPRS/UMTS networks the system uses Rel. 7 Gx interface for policy-based admission control support and flow-based charging. The Rel. 7 Gx interface supports enforcing policy control features like gating, bandwidth limiting, etc., and also supports flow-based charging. This is accomplished via dynamically provisioned Policy Control and Charging (PCC) rules. These PCC rules are used to identify Service Data Flows (SDF) and do charging. Other parameters associated with the rules are used to enforce policy control.
The PCC architecture allows operators to perform service-based QoS policy, and flow-based charging control. In the PCC architecture, this is accomplished mainly by the Policy and Charging Enforcement Function (PCEF)/Cisco Systems GGSN and the Policy and Charging Rules Function (PCRF).
In GPRS/UMTS networks, the client functionality lies with the GGSN, therefore in the IMS authorization scenario it is also called the Gateway. In the following figure, Gateway is the Cisco Systems GGSN, and the PCEF function is provided by Enhanced Charging Service (ECS). The Rel 7. Gx interface is implemented as a Diameter connection. The Gx messages mostly involve installing/modifying/removing dynamic rules and activating/deactivating predefined rules.
The Rel. 7 Gx reference point is located between the Gateway and the PCRF. This reference point is used for provisioning and removal of PCC rules from the PCRF to the Gateway, and the transmission of traffic plane events from the Gateway to the PCRF. The Gx reference point can be used for charging control, policy control, or both by applying AVPs relevant to the application. The following figure shows the reference points between various elements involved in the policy and charging architecture.
 
PCC Logical Architecture
Within the Gateway, the IMSA and DPCA modules handle the Gx protocol related functions (at the SessMgr) and the policy enforcement and charging happens at ECS. The Gy protocol related functions are handled within the DCCA module (at the ECS). The following figure shows the interaction between components within the Gateway.
 
PCC Architecture within Cisco PCEF
 
Supported Networks and Platforms
This feature is supported on all ASR 5000 Series Platforms with StarOS Release 8.1 and later running GGSN service for the core network services.
 
Licensing
This feature requires the following licenses to be installed on the chassis:
 
[ 600-00-7585 ] Dynamic Policy Interface — for IMS Authorization Service feature
[ 600-00-7574 ] Enhanced Charging Bundle 2 1k Sessions — for ECS functionality
 
Supported Standards
The Rel 7. Gx interface support is based on the following standards and RFCs:
 
 
Terminology and Definitions
 
Policy Control
The process whereby the PCRF indicates to the PCEF how to control the IP-CAN bearer.
Policy control comprises the following functions:
 
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.
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).
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.
Important: In this release, QoS Resource Reservation is not supported.
Supported Features:
 
Important: In this release, coordination of authorized QoS scopes in mixed mode (BCM = UE_NW) is not supported.
 
 
If the installation/activation of one or more new PCC rules (i.e., rules which 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 shall send the PCRF a new CCR command and include a Charging-Rule-Report AVP. The PCEF shall include the Rule-Failure-Code AVP within the Charging-Rule-Report AVP and shall set the PCC-Rule-Status to INACTIVE.
 
Charging Control
Charging Control is the process of associating packets belonging to a SDF to a charging key, and applying online charging and/or offline charging, as appropriate. Flow-based charging handles differentiated charging of the bearer usage based on real time analysis of the SDFs. In order to allow for charging control, the information in the PCC rule identifies the SDF and specifies the parameters for charging control. The PCC rule information may depend on subscription data.
In the case of online charging, it is possible to apply an online charging action upon PCEF events (e.g. re-authorization upon QoS change).
It is possible to indicate to the PCEF that interactions with the charging systems are not required for a PCC rule, i.e. to perform neither accounting nor credit control for this SDF, and then no offline charging information is generated.
Supported Features:
 
Important: In this release, provisioning of primary or secondary charging collection function name (Offline Charging Server (OFCS) addresses) over Gx is not supported.
Important: In this release, PCEF does not send the default online and offline charging method in the Credit Control Request - Initial (CCR(I)).
 
Charging Correlation
For the purpose of charging correlation between SDF level and application level (e.g. IMS) as well as on-line charging support at the application level, applicable charging identifiers and IP-CAN type identifiers are passed from the PCRF to the AF, if such identifiers are available.
For IMS bearer charging, the IP Multimedia Core Network (IM CN) subsystem and the Packet Switched (PS) domain entities are required to generate correlated charging data.
In order to achieve this, the Gateway provides the GGSN Charging Identifier (GCID) associated with the PDP context along with its address to the PCRF. The PCRF in turn sends the IMS Charging Identifier (ICID), which is provided by the P-CSCF, to the Gateway. The Gateway generates the charging records including the GCID as well as the ICID if received from PCRF, so that the correlation of charging data can be done with the billing system.
PCRF also provides the flow identifier, which uniquely identifies an IP flow in an IMS session.
 
Policy and Charging Control (PCC) Rules
A PCC rule enables the detection of an SDF and provides parameters for policy control and/or charging control. The purpose of the PCC rule is to:
 
The PCEF selects a PCC rule for each packet received by evaluating received packets against SDF filters of PCC rules in the order of precedence of the PCC rules. When a packet matches a SDF filter, the packet matching process for that packet is completed, and the PCC rule for that filter is applied.
There are two types of PCC rules:
 
Important: A third kind of rule, the static PCC rule can be preconfigured in the chassis by the operators. Static PCC rules are not explicitly known in the PCRF, and are not under control of the PCRF. Static PCC rules are bound to general purpose bearer with no Gx control.
A PCC rule consists of:
 
Important: In this release, configuring the Metering Method and Reporting Level for dynamic PCC rules is not supported.
PCC rules also include Application Function (AF) record information for enabling charging correlation between the application and bearer layer if the AF has provided this information via the Rx interface. For IMS, this includes the IMS Charging Identifier (ICID) and flow identifiers.
 
PCC Procedures over Gx Reference Point
 
Request for PCC rules
The PCEF, via the Gx reference point, requests for PCC rules in the following instances:
 
PCC rules can also be requested as a consequence of a failure in the PCC rule installation/activation or enforcement without requiring an event trigger.
 
Provisioning of PCC rules
The PCRF indicates, via the Rel. 7 Gx reference point, the PCC rules to be applied at the PCEF. This may be using one of the following procedures:
 
For each request from the PCEF or upon unsolicited provision the PCRF provisions zero or more PCC rules. The PCRF may perform an operation on a single PCC rule by one of the following means:
 
Selecting a PCC Rule for Uplink IP Packets
If PCC is enabled, the PCEF selects the applicable PCC rule for each received uplink IP packet within an IP CAN bearer by evaluating the packet against uplink SDF filters of PCRF-provided or predefined active PCC rules of this IP CAN bearer in the order of the precedence of the PCC rules.
Important: When a PCRF-provided PCC rule and a predefined PCC rule have the same precedence, the uplink SDF filters of the PCRF-provided PCC rule is applied first.
When a packet matches a SDF filter, the packet matching process for that packet is completed, and the PCC rule for that filter is applied. Uplink IP packets which do not match any PCC rule of the corresponding IP CAN bearer are discarded.
 
Selecting a PCC Rule and IP CAN Bearer for Downlink IP Packets
If PCC is enabled, the PCEF selects a PCC rule for each received downlink IP packet within an IP CAN session by evaluating the packet against downlink SDF filters of PCRF-provided or predefined active PCC rules of all IP CAN bearers of the IP CAN session in the order of the precedence of the PCC rules.
Important: When a PCRF-provided PCC rule and a predefined PCC rule have the same precedence, the downlink SDF filters of the PCRF-provided PCC rule are applied first.
When a packet matches a SDF filter, the packet matching process for that packet is completed, and the PCC rule for that filter is applied. The Downlink IP Packet is transported within the IP CAN bearer where the selected PCC rule is mapped. Downlink IP packets that do not match any PCC rule of the IP CAN session are discarded.
The following procedures are also supported:
 
The PCEF applies IP CAN specific procedures to terminate the IP CAN session. For GPRS, the GGSN send a PDP context deactivation request with the teardown indicator set to indicate that the termination of the entire IP-CAN session is requested. Furthermore, the PCEF applies the “Indication of IP CAN Session Termination” procedure.
 
Volume Reporting Over Gx
This section describes the Volume Reporting over Gx feature.
 
License Requirement
The Volume Reporting over Gx feature is license dependant, requiring the following license:
[ 600-00-7822 ] Charging Over Gx
 
Supported Standards
The Volume Reporting over Gx feature is based on the following standard:
3GPP TS 29.212 V9.1.0 (2009-12): 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Policy and Charging Control over Gx reference point (Release 9).
 
Feature Overview
The Volume Reporting over Gx feature provides PCRF the capability to make real-time decisions based on the data usage by subscribers.
Important: Volume reporting over Gx is applicable only for volume quota.
Important: Only total data usage reporting is supported. Uplink/Downlink level reporting is not supported in this release.
Important: The PCEF only reports the accumulated usage since the last report for usage monitoring and not from the beginning.
Important: If the usage threshold is set to zero (infinite threshold), no further threshold events will be generated by PCEF, but monitoring of usage will continue and be reported at the end of the session.
Important: Usage reporting on Bearer termination is not supported.
The following steps explain how Volume Reporting over Gx works:
 
1.
2.
3.
4.
5.
6.
 
Usage Monitoring
Important: In this release, the Usage-Monitoring-Informtion AVP is expected to be present without a new threshold to disable the usage monitoring after usage reporting when the threshold is breached. If no Usage-Monitoring-Informtion AVP is present in the CCA-U, the monitoring will continue with the old threshold value and the reporting happens when the threshold is breached again.
 
Usage monitoring is supported for both predefined rules and dynamic rule definitions.
 
Usage Reporting
Usage at subscriber/flow level is reported to PCRF under the following conditions:
 
For session-level reporting, the actual usage volume is compared with the usage volume threshold.
For rule-level reporting the rule that hits the data traffic is used to find out if the monitoring key is associated with it, and based on the monitoring key the data usage is checked. 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 the PCRF. The Usage-Monitoring-Information AVP is sent in this CCR with the “Used-Service-Unit” set to the amount of data usage by subscriber.
If PCRF does not provide a new usage threshold in the usage monitoring information as a result of CCR from PCEF when the usage threshold is reached, the usage monitoring is stopped at PCEF and no usage status is reported.
If the non-standard volume reporting flag is set, the usage monitoring will be stopped once the threshold is breached, else the monitoring will continue. There will be no further usage reporting until the CCA is received.
Important: PCRF Requested Usage Reporting is not supported in this release.
Once the usage is reported, the usage counter is reset to zero. The PCEF continues to track data usage from the zero value 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 usage monitoring does not continue in the PCEF for that IP CAN session.
For information on how to configure the Volume Reporting over Gx feature, see the Configuring Volume Reporting over Gx section.
 
How R7 Gx Works
This section describes how dynamic policy and charging control for subscribers works with Rel. 7 Gx interface support in GPRS/UMTS networks.
The following figure and table explain the IMSA process between a system and IMS components that is initiated by the UE.
In this example, the Diameter Policy Control Application (DPCA) is the Gx interface to the PCRF. The interface between IMSA with PCRF is the Gx interface, and the interface between Session Manager (SessMgr) and Online Charging Service (OCS) is the Gy interface. Note that the IMSA service and DPCA are part of SessMgr on the system and separated in the figure for illustration purpose only.
Rel. 7 Gx IMS Authorization Call Flow
Rel. 7 Gx IMS Authorization Call flow Description
 
Configuring Rel. 7 Gx Interface
To configure Rel. 7 Gx interface functionality, the IMS Authorization service must be configured at the context level, and then the APN configured to use the IMS Authorization service.
To configure Rel. 7 Gx interface functionality:
Step 1
Step 2
Step 3
Step 4
Step 5
Optional: Configure the Volume Reporting over Gx feature as described in the Configuring Volume Reporting over Gx section.
Step 6
Save your configuration as described in the Verifying and Saving Your Configuration chapter.
Important: Commands used in the configuration examples in this section provide base functionality to the extent that the most common or likely commands and/or keyword options are presented. In many cases, other optional commands and/or keyword options are available. Refer to the Command Line Interface Reference for complete information regarding all commands.
 
Configuring IMS Authorization Service at Context Level
Use the following example to configure IMS Authorization service at context level for IMS subscribers in GPRS/UMTS networks:
configure
   context <context_name>
      ims-auth-service <ims_auth_service>
         p-cscf discovery table { 1 | 2 } algorithm { ip-address-modulus | msisdn-modulus | round-robin }
         p-cscf table { 1 | 2 } row-precedence <precedence_value> { address <ip_address> | ipv6-address <ipv6_address> } [ secondary { address <ip_address> | ipv6-address <ipv6_address> } ]
         policy-control
            diameter origin endpoint <endpoint_name>
            diameter dictionary <dictionary>
            diameter request-timeout <timeout>
            diameter host-select table { { { 1 | 2 } algorithm { ip-address-modulus | msisdn-modulus | round-robin } } | prefix-table { 1 | 2 } }
            diameter host-select row-precedence <precedence_value> table { { { 1 | 2 } host <host_name> [ realm <realm_id> ] [ secondary host <host_name> [ realm <realm_id> ] ] } | { prefix-table { 1 | 2 } msisdn-prefix-from <msisdn_prefix_from> msisdn-prefix-to <msisdn_prefix_to> host <host_name> [ realm <realm_id> ] [ secondary host <sec_host_name> [ realm <sec_realm_id> ] algorithm { active-standby | round-robin } ] } } [ -noconfirm ]
            diameter host-select reselect subscriber-limit <subscriber_limit> time-interval <duration>
            failure-handling cc-request-type { any-request | initial-request | terminate-request | update-request } { diameter-result-code { any-error | <result_code> [ to <end_result_code> ] } } { continue | retry-and-terminate | terminate }
            end
Notes:
 
<context_name> must be the name of the context where you want to enable IMS Authorization service.
<ims_auth_service> must be the name of the IMS Authorization service to be configured for Rel. 7 Gx interface authentication.
To enable the Gx interface to connect to a specific PCRF for a range of subscribers configure msisdn-prefix-from <msisdn_prefix_from> and msisdn-prefix-to <msisdn_prefix_to> with the starting and ending MSISDNs respectively.
To enable the Gx interface to connect to a specific PCRF for a specific subscriber, configure both msisdn-prefix-from <msisdn_prefix_from> and msisdn-prefix-to <msisdn_prefix_to> with the same MSISDN.
In StarOS 8.1 and later releases, per MSISDN prefix range table a maximum of 128 rows can be added. In StarOS 8.0 and earlier releases, a maximum of 100 rows can be added.
The MSISDN ranges must not overlap between rows.
qos-update-timeout <timeout_duration>
Option: To configure signalling restrictions, in the IMS Authorization Service Configuration Mode, enter the following commands:
signaling-flag { deny | permit }
signaling-flow permit server-address <ip_address> [ server-port { <port_number> | range <start_number> to <end_number> } ] [ description <STRING> ]
Option: To configure action on packets that do not match any policy gates in the general purpose PDP context, in the IMS Authorization Service Configuration Mode, enter the following command:
traffic-policy general-pdp-context no-matching-gates direction { downlink | uplink } { forward | discard }
To configure the GGSN/PCEF to use a pre-defined rule when the Gx fails, set the failure-handling cc-request-type CLI to continue. Policies available/in use will continue to be used and there will be no further interaction with the PCRF.
 
Verifying the Configuration
To verify the IMS Authorization service configuration:
Step 1
context <context_name>
Step 2
show ims-authorization service name <ims_auth_service>
 
Applying IMS Authorization Service to an APN
After configuring IMS Authorization service at the context-level, an APN within the same context must be configured to use the IMS Authorization service for an IMS subscriber.
 
Use the following example to apply IMS Authorization service functionality to a previously configured APN within the context configured in the Configuring Rel. 7 Gx Interface section.
configure
   context <context_name>
      apn <apn_name>
         ims-auth-service <ims_auth_service>
         active-charging rulebase <rulebase_name>
         end
Notes:
 
<context_name> must be the name of the context in which the IMS Authorization service was configured.
<ims_auth_service> must be the name of the IMS Authorization service configured for IMS authentication in the context.
policy-control charging-rule-base-name active-charging-group-of-ruledefs
 
Verifying Subscriber Configuration
Verify the IMS Authorization service configuration for subscriber(s) by entering the following command:
show subscribers ims-auth-service <ims_auth_service>
<ims_auth_service> must be the name of the IMS Authorization service configured for IMS authentication.
 
Configuring Volume Reporting over Gx
This section describes the configuration required to enable Volume Reporting over Gx.
To enable Volume Reporting over Gx, use the following configuration:
configure
  active-charging service <ecs_service_name>
     rulebase <rulebase_name>
        action priority <priority> dynamic-only ruledef <ruledef_name> charging-action <charging_action_name> monitoring-key <monitoring_key>
        end
Notes:
 
 
Saving the Configuration
To save changes to the configuration, refer to the Verifying and Saving Your Configuration chapter.
 
Gathering Statistics
This section explains how to gather Rel. 7 Gx statistics and configuration information.
In the following table, the first column lists what statistics to gather, and the second column lists the action to perform.
Gathering Rel. 7 Gx Statistics and Information
 

Cisco Systems Inc.
Tel: 408-526-4000
Fax: 408-527-0883