The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
The Gy interface is used for reporting and charging. In SCA BB, support of the Gy interface is divided into two components. The two components reside on the control plane and the data plane, as shown in Figure 1-1.
Figure 1-1 Gy Interface Adapter
– Handles the failure handling of Diameter Credit-Control Application (DCCA) level errors and timeout messages according to the Credit-Control-Failure-Handling AVP
SM-API Adapter (Control Plane)
– Supports time, events, and volume (total or inbound and outbound limitations)
– Counts the consumed quota (pre-tariff and post-tariff change, if needed)
– Supports quota validity time, threshold, and quota holding time (QHT)
The SCA BB supports three operational and integration quota management models that allow gradual investment and trade-off between complexity of integration/deployment and range of functionality:
The Gy quota model enables the Gy interface adapter to be used for the external quota management. The Gy quota model is based on session charging with central unit determination. An external OCS (for example, bucket type and post-breach action) controls the configuration of the quota buckets. In the Gy quota model, two subscribers from the same package can use different buckets, with different sizes and post-breach actions. In the Gy quota model, service association to buckets is completed using the SCA BB console. For additional configuration information using the SCA BB console, see the “Gy Interface Failover Support” section.
In the Gy type of quota management:
The Gy quota model supports the following quota types (with the related AVPs):
Note the following about the correspondence between buckets types, quota types, and AVPs:
– An exception to this point is the UPSTREAM_DOWNSTREAM bucket type. This type accounts for the volume usage on the Downstream (CC-Output) and the Upstream (CC-Input) separately.
To use this bucket type, the server should grant the client CC-Input GSU on a certain MSCC carrying the bucket ID and an additional separate grant of CC-Output GSU on a separate MSCC carrying the same bucket ID.
The quota time consumed is the service usage duration with either no idle time or minimum idle time. The quota time consumed is the quota consumption time (QCT). When the quota is granted, a QCT can be assigned. If QCT is not assigned, a default value per service is used.
By default, the quota usage sampling frequency is set to 30 seconds and the sampling is completed once for every 32 packets assuming nontrivial activity. If the trivial activity exceeds the sampling time, the system charges per sampling unit. For example, in case of trivial activity of two minutes, the charging is 30 seconds.
When upstream-downstream volume is used, the debit is completed separately per upstream and downstream.
For additional Gy quota information, see the following sections:
The SCE defines time-based quota buckets and accounts for subscriber usage in seconds. The up and down volume and number of sessions are not critical in time-based quota management. The subscriber usage is accumulated as long as the subscriber has at least one active session. The server can specify a QCT for each bucket. The specified QCT is the maximum idle time that is accounted as quota usage. As shown in Figure 1-2, when the idle period is less than the consumption time, it is counted as subscriber usage, but when the idle period is greater than consumption time, it is not accounted for.
Figure 1-2 Quota Consumption Time
If the server fails to provide a consumption time, the SCE uses the default consumption time.
The supported quota timers are the Quota Validity Time and the Quota Holding Time.
The server defines the quota validity time for each bucket. The time is measured in seconds. Quota validity time is the duration for which the SCE (or the subscriber) can use the quota as shown in Figure 1-3.
Figure 1-3 Quota Validity Time
If the server does not provide a quota validity time, the default validity time is used. The default validity time is defined per bucket per package in the GUI.
After the quota validity time expires, the SCE sends a Quota Status RDR and invalidates the bucket quota. It is the responsibility of the server to update the bucket quota and the action again. If the server does not respond, the bucket state is changed to error and an error action is applied to all the associated flows.
If the quota validity time expires, the Quota Status RDR is sent even if the server has specified Final Unit Indication.
The server defines quota holding time, in seconds, for each bucket. Quota holding time indicates the duration for which the SCE can hold quota without any usage. The SCE resets the timer each time it detects subscriber activity on a flow that is associated with the bucket as shown in Figure 1-4.
If the server does not provide a quota holding time, the default holding time is used. The default quota holding time is defined per bucket per package in the GUI.
After the quota holding timer expires, the SCE sends a Quota Status RDR and invalidates the bucket quota. The server is responsible to update the bucket quota and action again. If the server does not respond, the bucket state is changed to error and an error action is applied to all the associated flows.
If the quota holding timer expires, the Quota Status RDR is sent even if the server has specified Final Unit Indication.
A quota request is sent upon an attempt to use a service with no quota available, unless the service already received an indication that the quota is not available. For example, a quota request was sent, and the reply was “no quota available”.
If the service is marked to request quota upon login, quota requests are sent even before any attempt to use the service is executed. Quota requested upon login is configured per service package. The default is not to request quota upon login.
The quota count is started before the first grant. The only exceptions are short flows, which end before the quota is granted.
When a quota request occurs upon threshold, the quota is counted even after the quota request is sent. After the quota is granted, the already consumed quota is treated as consumed and subtracted from the granted quota.
If an external server is used to trigger a quota request, a quota reauthorization request should be used.
When the quota requires reauthorization, a debit request for the measured consumed quota (if it exists) is sent, asking for new quota. The response overrides the existing quota.
A reauthorization request is sent for the following events:
The validity time and QHT may be provided with the quota grant. If the validity time and QHT are not specified, a default value is used. The default value is configured per bucket or package.
The quota threshold and breach actions are defined per quota. If quota threshold and breach are not specified, default values configured per service or package are used.
The supported quota threshold and breach actions are:
The actions may also include sending a predefined notification. The notification is predefined on the quota management table.
Pretariff time change and post-tariff time change are reported in the quota debit request. The tariff change time is given per quota and is measured in number of seconds since 1.1.1900 (32 bits).
Figure 1-5 illustrates the Gy quota threshold call flow. The quota used report is reset only after the SCE receives the CCA-U message.
Figure 1-5 Gy Quota Threshold Call Flow
This section contains the information and instructions to configure and monitor the Gy support configuration and the Gy quota configuration.
You can map a specified PS Information AVP (3GPP-Charging-Characteristics) into a specified realm. Use the following CLI command:
diameter Gy subscriber-attribute-mapping attribute-name 3GPP-Charging-Characteristics attribute-value <attribute-value> realm-id <realm-id>
The realm selection is completed based on the subscriber RADIUS property 3GPP-charging-characteristics and the global mapping of potential realm values. If there is no mapping (or a mismatch), the first realm in the realm table is selected.
Note The Gx and Gy interfaces support 3GPP-charging-characteristics and it is assigned to a subscriber upon login via the Gx interface.
Table 1-1 lists the CLI commands used to configure and monitor the Gy interface and Table 1-2 lists the CLI commands used to monitor the quota engine.
|
|
---|---|
[no] diameter Gy1 |
|
diameter Gy subscriber-attribute-mapping attribute-name 3GPP-charging-characteristics attribute-value <attribute-value> realm-id <realm-id> |
Map the specified PS Information AVP (3GPP-Charging-Characteristics) into the specified realm. |
1.Upon disabling Gy, all the sessions are closed, and unreported quota is reported. New sessions do not open. When the Gy interface is on (again), new sessions are opened for all the subscribers. |
To configure Gy support using the CLI, see the “Gy Interface CLI Commands” section.
In the SCA BB GUI, you can create quota profiles that define the limits and action of each bucket and assign specific services to the bucket. You must attach the quota profile to a package and define a quota rule for the package for the relevant service.
Note For more information on configuring and managing quotas, see the Cisco Service Control Application for Broadband User Guide.
To configure a Gy quota profile, complete the following steps. The steps are described in detail in the referenced sections.
Step 1 Select Gy as the External Quota Type (Configuring the External Quota Type).
Step 2 Create the Gy Quota Profile (Adding a Quota Profile)
Step 3 Edit the buckets and assign services to the profile (Editing a Quota Profile).
Step 4 Assign the profile to the appropriate package (Attaching the Quota Profile to a Package).
Step 5 Configure a rule for the package defining the action of the bucket for the relevant service in that package (Defining a Rule Using the Quota Profile).
To access the Quota Profile Editor, choose Service Configuration > Configuration > Policies > Quota Settings
Figure 1-6 Accessing the Quota Profile Editor
The external quota type options are displayed in the upper part of the Quota Profile Editor, as shown in Figure 1-7. The default quota type is Gy.
Figure 1-7 Quota Profile Editor Screen
Changing the external quota type may result in the loss of the existing user-defined quota profile data. Therefore, if you change the quota type after creating any quota profiles, the system issues a warning and asks for confirmation, as shown in Figure 1-8.
Figure 1-8 Warning from Quota Editor Message
You can configure the general quota settings from the General Settings tab of the Quota Profile Editor, as shown in Figure 1-9.
Figure 1-9 Quota Profile Editor - General Settings Tab
Step 1 Click New in the Profile Edit tab.
Step 2 Enter the profile name (or you can simply accept the default name suggested by the system) and select the profile type:
Figure 1-10 Adding a Quota Profile
After creating a quota profile, you can configure each bucket separately. For Gy quota profiles, you can configure the following for each bucket:
– Whether to request quota on login
Note You cannot edit the default profile.
To configure a quota profile, complete the following steps:
Step 1 Click the profile name in the left pane.
The profile name and the individual buckets appear in the right pane.
Figure 1-11 Quota Profile Editor - Quota Profile Edit Tab
Step 2 Double-click the desired bucket to edit it.
The Quota Bucket Editor opens.
Figure 1-12 Quota Bucket Editor - Bucket Tab
– To attach services to the bucket for all time frames, use the Service tab (see Figure 1-13). Drag the service name and drop it under Attached services.
The services on the left pane are organized according to the service tree.
If you drag a service, all its subservices in the tree are dragged as well.
Figure 1-13 Quota Bucket Editor - Service Tab
– To attach different services depending on the timeframe, use the Timeframe tab (see Figure 1-14). Drag the service name and drop it under Attached service s on the desired Time Frame tab.
Figure 1-14 Quota Bucket Editor - Timeframe Tab
You must attach the quota profile to the appropriate package.
To attach the quota profile to a package:
Step 1 Right-click the package in the Policies tab of the Service Configuration window to access the Package Settings screen.
Step 3 Click the Quota Management tab.
Step 4 Select the desired profile from the Select Quota Profile drop-down list (see Figure 1-15).
Figure 1-15 Package Settings – Quota Management Tab
You must add a rule to the package that defines the action when the bucket exceeds its quota.
Step 1 Click the Add icon in the right pane in the Policies tab of the Service Configuration window to add a rule.
Step 2 In the General tab, select the service attached to the bucket in the quota profile (see Figure 1-16).
Figure 1-16 Add New Rule – General Tab
The bucket associated with this service in the quota profile is displayed in the Usage Limits tab as shown in Figure 1-17.
Figure 1-17 Add New Rule – Usage Limits Tab
Step 3 Configure the Control and Breach Handling parameters.
Note For more information on configuring rules, see the Cisco Service Control Application for Broadband User Guide.
The charging ID mapping table allows you to map the SCA BB parameters of package and bucket to the Gy interface parameters of service and rating group. This mapping ensures that a specified bucket from a specified package would always be output by the Gy interface as a particular service and rating group.
– If the mapping table is not empty, and there is a corresponding entry in the table, the translation is done to the configured numbers.
– If the mapping table is not empty, but there is no corresponding entry in the table, an appropriate error counter is increased.
Table 1-3 lists the CLI commands used to configure and monitor the charging ID mapping table.
Example for mapping the first three buckets in package-id 5 to service-id 1 and rating-groups 10-12:
The Gy interface failure support in fault situations is governed by the value of two AVPs:
The default values of these two attributes can be configured locally in the SCE. The default CCFH value is TERMINATE and the default CCSF value is “Failover not Supported”. The OCS can override the default values by sending the two AVPs in a CCA message.
When the Gy interface receives a Result-Code 4xxx, it retransmits the message to the original server.
If the CCSF and CCFH AVPs are carried by a CCA message, the AVP values are applied only to the session they are communicated on.
The Gy interface implements its failover decision based on whether a failover is needed or not. The Gy interface uses the peer table and failover mode to decide which destination each message should be sent to. For each Gy CCR message, the Gy interface checks the peer table and failover mode for the correct destination information.
For additional details of the Gy interface failover support, see the “Diameter Load Balancing and High Availability Schemes” section, the “High Availability for the Gx Interface” section, and the following sections:
Usually the diameter layer detects any transport failure within the diameter server; but for prepaid services, the subscriber expects an answer from the network in a reasonable time. Therefore, a Tx timer is used by the DCCA client to supervise the communication with the server. When the Tx time expires, the DCCA client takes action based on the current value of CCFH for the CC-session-id.
The Tx timer is restarted for each initial CCR message and for each updated CCR message. Because multiple concurrent update CCR messages are possible, if one update CCR message is pending, a subsequent update CCR message restarts the Tx timer. When answers to all pending update CCR messages are received, the Tx timer is stopped. Figure 1-18 illustrates the Tx timer behavior.
The forwarder makes forwarding decisions based on CCSF value as passed to it from the Gy interface. If the value is FAILOVER_NOT_SUPPORTED, a CC session is never moved to an alternate server. If the value is FAILOVER_SUPPORTED, the forwarder attempts to move the session to an alternate server if the Gy interface asks for an alternate server.
The following events trigger the forwarder to make a forwarding decision:
Table 1-4 lists the actions on the session for each value of CCFH.
The following are the fault conditions in which CCFH is used to determine the action on the session:
The CCFH value is used both for session-level errors and bucket-level errors.
Bucket-level errors such as DIAMETER_CREDIT_LIMIT_REACHED do not cause failover but the credit control server instructs the Cisco SCE not to send any requests for quota.
The Gy interface communicates to the forwarder when a failover is required for a server per session. The client then expects to receive an alternate server. The alternate server may be the currently assigned server, depending on the configured forwarder scheme.
The Gy interface communicates to the forwarder and requests an alternate server in the following situations:
– The following Result-Code AVP values appear in the CCA:
– Receipt of a CCA with protocol error
– Receipt of a failed CCA; for example, CCA with a permanent failure notification
When the initial CCR message is sent on a CC-session, the Tx timer is started and the CC-session is pending awaiting a CCA message. When the Tx timer expires before the initial CCA message is received, the action on the session context is determined by the CCFH.
When an update CCR message is sent on a CC_session, the Tx timer is started and the CC-session state is pending awaiting a CCA message. When the Tx timer expires before the initial CCA message is received, the action on the session context is determined by the CCFH.
The Gy interface supports session-based credit control when the first interrogation is executed after the authorization or authentication process.
In Table 1-5 and Table 1-6 , the “failure to send” event means that the Gy interface is unable to communicate with the desired destination or, if failover procedure is supported, with a defined alternative destination (for example, the request timed out and the answer message is not received). This can be due to the peer being down or due to a physical link failure in the path to or from the OCS.
The 'Temporary error' event means that the Gy interface received a protocol error notification (DIAMETER_TOO_BUSY, DIAMETER_UNABLE_TO_DELIVER, or DIAMETER_LOOP_DETECTED) in the Result-Code AVP of the Credit-Control-Answer command. The protocol error notification can be received in answer to the retransmitted request to a defined alternative destination, if failover is supported.
The 'Failed answer' event means that the Gy interface received a nontransient failure (permanent failure) notification in the CCA command. The permanent failure notification may ultimately be received in answer to the retransmitted request to a defined alternative destination, if failover is supported.
The Tx timer, which is used to control the waiting time in the Gy interface in the Pending state, is stopped upon exit of the Pending state. The stopping of the Tx timer is omitted in the state machine when the new state is Idle, because moving to Idle state indicates the clearing of the session and all the variables associated to it.
In Table 1-5 and Table 1-6 , the failover to a secondary server upon “Temporary error” or “Failure to send” is not described. Moving an ongoing credit-control message stream to an alternate server is, however, possible if the CC-Session-Failover AVP is set to FAILOVER_SUPPORTED.
Figure 1-19 depicts the Gy client behavior upon CCA error or timeout error scenarios.
Figure 1-19 Gy Client Behavior Upon CCA Error or Timeout Error
Figure 1-20 depicts the Gy client behavior upon severe failure situation.
Figure 1-20 Gy Client Behavior Upon Severe Failure
Upon cascade failover, the secondary box has no sessions in the session database.
Each quota status update that does not have a session on the secondary box creates a new session context and is sent an updated CCR.
Sessions that are left open on the OCS are closed by aging or by identifying a new session with the same subscription ID.