Cisco Service Control Management Suite Quota Manager User Guide, Release 3.6.x - Quota Management Scenarios [Cisco Service Control Subscriber Manager]

Table Of Contents

Quota Management Scenarios

Introduction

Quota Preservation Across Subscriber Sessions

Aggregation Period Changeover

Quota Breach

Maximizing Quota Accuracy

SM Startup Sequence

EM Agent Startup Sequence

Subscriber Login

Subscriber Logout

Quota-Status Notification

Quota Below Threshold Notification

Quota Depleted Notification

Quota Replenishment

Penalty Flows

SCE Removal from the Configuration

SM Fail-Over

SCE Fail-Over

Quota Management Scenarios

Revised: January 11, 2013, OL-21082-04

Introduction

This chapter describes a number of scenarios to better understand how the Quota Manager (QM) works and to understand the messages between the Subscriber Manager (SM) and the service control engine (SCE).

•Quota Preservation Across Subscriber Sessions

•Aggregation Period Changeover

•Quota Breach

•Maximizing Quota Accuracy

•SM Startup Sequence

•EM Agent Startup Sequence

•Subscriber Login

•Subscriber Logout

•Quota-Status Notification

•Quota Below Threshold Notification

•Quota Depleted Notification

•Quota Replenishment

•Penalty Flows

•SCE Removal from the Configuration

•SM Fail-Over

•SCE Fail-Over

Quota Preservation Across Subscriber Sessions

This section describes the means by which subscriber quota is preserved across sessions. Figure 2-1 shows this scenario.

Figure 2-1 Quota Preservation Across Subscriber Sessions

In this scenario:

1. The subscriber logs into the SM.

2. The SM performs a logon operation to the SCE, which responds with a quota state restore indication. This indication is a request by the SCE to the SM to find out how much quota the subscriber has remaining.

3. The SM queries the database, and then responds to the SCE with a quota set operation. This sets the amount of quota that is allocated to the subscriber based on the subscriber package and the associated quota profile.

4. During the subscriber session and while the subscriber is consuming quota, the SCE sends remaining quota indications. These are periodic and the frequency at which they are sent is defined when configuring the PQB with the Service Control Application for Broadband (SCA BB) console.

5. As the SM receives each remaining quota indication, the quota manager removes the required amount of quota from the subscriber buckets.

Note A high rate of remaining quota indications results in a higher accuracy for the subscriber quota value. However, it also increases the number of management messages on the network.

6. When the subscriber session is finished, the SM performs a logout operation on the SCE, which responds with a remaining quota indication. The SM uses the value contained in the indication to delete the quota consumed by the subscriber.

7. The quota value is written to the database to be stored until the next subscriber log in.

Note The quota is subtracted from the subscriber quota account only after the quota is consumed, not when it is provisioned. This ensures that in cases of SCE fail-over, the quota inaccuracy is calculated in favor of the subscriber.

Aggregation Period Changeover

Figure 2-2 shows the actions taken for each subscriber when a new aggregation period begins.

Figure 2-2 Aggregation Period Changeover

In Figure 2-2, the subscriber is logged in and consuming quota.

1. The top half of the figure shows the SCE generating the remaining quota indications and the SM removing the used quota from the subscriber buckets.

2. According to the package and the associated quota profile, a new aggregation period starts.

3. After the start of the new aggregation period, the SCE sends a remaining quota indication.

4. When the SM receives a remaining quota indication, it replenishes the subscriber buckets with the quota amounts defined by the quota profile.

Note Due to the configuration of the SCE, the first remaining quota indication may not occur immediately when the new aggregation period begins. This period of time is highlighted in blue in Figure 2-2. The quota consumed in this time period is consumed from the quota allocated to the previous aggregation period. The inaccuracy of the quota value is less than or equal to the quota dosage and is dependent on the rate of the remaining quota indications. This is a limitation of the application.

Note If the rate at which remaining quota indications are sent is high, the subscriber quota is replenished at a time in close proximity to the new aggregation period start time. However, this increases the number of management messages on the network.

Quota Breach

Figure 2-3 shows the actions taken in the event that a subscriber completely depletes his quota.

Figure 2-3 Quota Breach

In Figure 2-3, the subscriber is consuming data from the quota buckets and the SCE is generating remaining quota indications.

1. When the quota reaches a configurable threshold value, the SCE sends a quota threshold indication.

2. In cases in which the subscriber can be granted more quota, a quota set operation is performed. In Figure 2-3, no more quota is available for the subscriber.

3. The subscriber continues to consume quota until the quota buckets are empty. The SCE sends a quota breach indication when the quota buckets are empty. At the same time, the post-breach action, which was configured in the SCA BB Console, is applied to the subscriber.

4. After a new aggregation period starts, the subscriber is eligible for more quota. However, quota is replenished only after the quota manager receives the remaining quota indication.

5. After the quota is replenished, a quota set operation is performed and the subscriber can continue consuming quota.

Note Due to the configuration of the SCE, the first remaining quota indication may not occur immediately after the new aggregation period begins. This period of time is highlighted in blue in Figure 2-3. Because the subscriber is breached and the first remaining quota indication has not arrived, the subscriber is not able to consume quota. This is the only case in which quota inaccuracy is not in favor of the subscriber.

Maximizing Quota Accuracy

One of the most important aspects of the QM is accuracy of the quota levels for any subscriber. When you provision quota using an external server, a trade-off exists between quota accuracy and the number of network messages.

To maximize accuracy, configure the rate of the periodic remaining quota indication to a high value, and configure the size of the quota dosage to a small value. A configuration causes performance degradation due to the high number of messages being generated in the network.

Quota inaccuracies may occur during the changeover from one aggregation period to the next, or due to an SCE fail-over. The level of inaccuracy depends on the configuration of the following parameters:

•Rate of the periodic remaining quota indications

•Quota dosage value

During an aggregation period changeover, the following occurs until the first quota indication is received in the new aggregation period:

•Quota consumed by the subscriber is subtracted from the previous aggregation period.

•Quota dosage value limits the size of any quota error.

•The interval between the remaining quota indications limits the length of time during which consumed quota is subtracted from the previous aggregation period.

In cases of SCE fail-over, the following occurs between the last quota indication in the failed SCE and the first quota indication in the new, active SCE:

•Any quota consumed by the subscriber is not removed from the subscriber buckets.

•The quota dosage value limits the size of any quota error.

•The length of time during which quota is consumed is limited by the interval between the remaining quota indications.

In all cases of inaccuracy, the quota remaining is calculated in favor of the subscriber. The only exception is if the aggregation period changeover occurs when the subscriber quota is already breached.

SM Startup Sequence

During SM startup:

1. The Network Model notifies the QM with a list of new SCEs added to the configuration.

2. The QM creates a PPRC_SCESubsciberApi instance for each new SCE added to the configuration.

3. The QM creates a QuotaListenerImpl instance and registers it on the API instance for each new SCE added to the configuration.

4. The active SM connects to all the SCEs using the API instance. The standby SM does not connect.

5. The SM identifies if the QM configuration file was changed and performs a replenish quota operation for all subscribers based on the QM configuration file changes.

EM Agent Startup Sequence

During the EM agent startup:

1. The SCAS_BB MBean registers:

–The QuotaRdrListener on the RDR server MBean to manage the quota RDRs received from the SML.

–The QuotaOperationHandler on the SCESubscriberApiMBean to handle quota updates received from the SCE Subscriber API.

2. After the QuotaRdrListener and the QuotaOperationHandler are registered, SCESubscriberApiMBean waits for incoming PRPC connections from the QM.

Subscriber Login

At subscriber login:

1. The SM logs in the subscriber to the SCE.

2. The SML detects the login and generates quota-state-restore RDR for the subscriber.

3. The QuotaRdrListener receives the RDR and generates a PRPC quota-state-restore notification using the SCESubscriberApiMBean.

4. The QM receives the notification and it checks the existing quota for the subscriber on all buckets.

5. If quota is available for the subscriber, the QM invokes the quotaUpdate operation.

6. The SCESubscriberApiMBean manages the invocation and asks the QuotaOperationHandler to add the quota.

7. The QuotaOperationHandler updates the quota for the subscriber on the SCE (using quota-add operation).

Subscriber Logout

At subscriber logout:

1. The SM logs out the subscriber from the SCE.

2. As a result of the logout, the SML generates a remaining-quota Raw Data Record (RDR) (with reason 1)

3. The QuotaRdrListener receives the RDR and generates a quota-status Proprietary Remote Procedure Call (PRPC) notification using the SCESubscriberApiMBean.

4. The QM receives the notification and compares the current quota with the last reported quota of the SCE and then decrements the difference between the current quota and the last reported quota.

Quota-Status Notification

The SML periodically generates a remaining-quota RDR (reason 0):

1. The QuotaRdrListener receives the RDR and generates a quota-status PRPC notification using the SCESubscriberApiMBean.

2. The QM receives the notification, compares the current quota with the last reported quota of the SCE, and decrements the difference between the current quota and the last-reported quota.

3. If the current quota is negative, the QM checks to verify if more quota is available, and invokes quotaUpdate (PRPC invocation) if more quota is available.

4. The SCESubscriberApiMBean manages the invocation and asks the QuotaOperationHandler to add the quota.

5. The QuotaOperationHandler updates the quota for the subscriber (using quota-add operation).

Quota Below Threshold Notification

When the SML generates a quota-below-threshold RDR:

1. The QuotaRdrListener receives the RDR and generates a PRPC notification using the SCESubscriberApiMBean.

2. The QM receives the notification, compares the current quota with the last reported quota of the SCE and decrements the difference between the current quota and the last reported quota.

3. The QM then checks to verify if more quota is available, and invokes quotaUpdate (PRPC invocation) if additional quota is available.

4. The SCESubscriberApiMBean manages the invocation and asks the QuotaOperationHandler to add the quota.

5. The QuotaOperationHandler (of SCAS_BB MBean) updates the quota for the subscriber (using quota-add operation).

Quota Depleted Notification

When the SML generates quota-breach (quota-depleted) RDR:

1. The QuotaRdrListener receives the RDR and generates a PRPC notification using the SCESubscriberApiMBean.

2. The QM receives the notification, compares the current quota with the last reported quota of the SCE and decrements the difference between the current quota and the last reported quota.

3. The QM then checks to verify if more quota is available, and invokes quotaUpdate (PRPC invocation) if additional quota is available.

4. The SCESubscriberApiMBean manages the invocation and asks the QuotaOperationHandler to add the quota.

5. The QuotaOperationHandler updates the quota for the subscriber (using quota-add operation).

Quota Replenishment

Quota replenishment occurs in the following scenarios:

•A new aggregation period occurs when the number of the slice is equal to 1 (old quota model support).

•The first quota notification occurs in the life of a subscriber.

•When the QM is started. Because the last configuration is not saved, it is not known if the configuration was changed. The QM assumes the configuration changed and invokes a quota replenishment.

•If the customer configures the global flag recet_quota_on_profile_change and one of the following has occurred:

–The Quota Profile (packageID) of the subscriber is changed (through SM CLU or due to the move to the penalty package or out of the penalty package).

–The static configuration of the quota policies is modified, and a new configuration is loaded on the QM.

Limitations

If the Quota Manager is configured with a large number of quota profiles, typically more than 25, the Cisco Service Control Subscriber Manager may not persist all quota profiles in SM DB due to database limitations. This may lead to a quota replenishment while restarting or upgrading the Subscriber Manager.

Penalty Flows

The subscriber enters the penalty mode when the subscriber uses the entire quota before the window (aggregation period) ends and enters the configured penalty profile for their subscriber package. When such situation is identified:

•The subscriber is moved to the configured "penalty" package to the configured period of time.

•If configured, subscriber quota usage history prior the penalty is kept in the SM DB.

When penalty time passes, the QM checks subscriber's usage during the penalty and moves the subscriber to the post-penalty package according to the configuration. If the subscriber quota usage did not fit any post-penalty threshold, then the subscriber stays in penalty for another penalty period.

SCE Removal from the Configuration

When an SCE is removed from the configuration:

1. The NetworkModel notifies the QM that an SCE was removed from the configuration.

2. The QM unregisters the quota listener from the removed SCE and the QM disconnects from the removed SCE.

SM Fail-Over

When an SM fails:

1. The failed SM disconnects from each SCE without unregistering the quota listener.

2. The quota notifications accumulate on the each SCE internal buffer.

3. The standby SM connects to each SCE and the quota notifications are sent to the new active SM.

SCE Fail-Over

The QM stores the SCE that sent the last quota notification. When the QM receives a notification from a different SCE, it does not calculate the quota usage (it ignores the last SCE bucket sizes, which are not relevant), and updates the last SCE bucket sizes according to the notification. The quota that was consumed on the failed SCE since the last notification is not accounted for.

	Cisco Service Control Management Suite Quota Manager User Guide, Release 3.6.x
	Quota Management Scenarios
Cisco Service Control Management Suite Quota Manager User Guide, Release 3.6.x Preface Quota Management Overview Quota Management Scenarios Configuring the Quota Manager Using the Quota Manager Command-Line Utility	Download this chapter Quota Management Scenarios Download the complete book Cisco Service Control Management Suite Quota Manager User Guide, Release 3.6.x (PDF - 870 KB) Feedback Table Of Contents Quota Management Scenarios Introduction Quota Preservation Across Subscriber Sessions Aggregation Period Changeover Quota Breach Maximizing Quota Accuracy SM Startup Sequence EM Agent Startup Sequence Subscriber Login Subscriber Logout Quota-Status Notification Quota Below Threshold Notification Quota Depleted Notification Quota Replenishment Penalty Flows SCE Removal from the Configuration SM Fail-Over SCE Fail-Over Quota Management Scenarios Revised: January 11, 2013, OL-21082-04 Introduction This chapter describes a number of scenarios to better understand how the Quota Manager (QM) works and to understand the messages between the Subscriber Manager (SM) and the service control engine (SCE). •Quota Preservation Across Subscriber Sessions •Aggregation Period Changeover •Quota Breach •Maximizing Quota Accuracy •SM Startup Sequence •EM Agent Startup Sequence •Subscriber Login •Subscriber Logout •Quota-Status Notification •Quota Below Threshold Notification •Quota Depleted Notification •Quota Replenishment •Penalty Flows •SCE Removal from the Configuration •SM Fail-Over •SCE Fail-Over Quota Preservation Across Subscriber Sessions This section describes the means by which subscriber quota is preserved across sessions. Figure 2-1 shows this scenario. Figure 2-1 Quota Preservation Across Subscriber Sessions In this scenario: 1. The subscriber logs into the SM. 2. The SM performs a logon operation to the SCE, which responds with a quota state restore indication. This indication is a request by the SCE to the SM to find out how much quota the subscriber has remaining. 3. The SM queries the database, and then responds to the SCE with a quota set operation. This sets the amount of quota that is allocated to the subscriber based on the subscriber package and the associated quota profile. 4. During the subscriber session and while the subscriber is consuming quota, the SCE sends remaining quota indications. These are periodic and the frequency at which they are sent is defined when configuring the PQB with the Service Control Application for Broadband (SCA BB) console. 5. As the SM receives each remaining quota indication, the quota manager removes the required amount of quota from the subscriber buckets. Note A high rate of remaining quota indications results in a higher accuracy for the subscriber quota value. However, it also increases the number of management messages on the network. 6. When the subscriber session is finished, the SM performs a logout operation on the SCE, which responds with a remaining quota indication. The SM uses the value contained in the indication to delete the quota consumed by the subscriber. 7. The quota value is written to the database to be stored until the next subscriber log in. Note The quota is subtracted from the subscriber quota account only after the quota is consumed, not when it is provisioned. This ensures that in cases of SCE fail-over, the quota inaccuracy is calculated in favor of the subscriber. Aggregation Period Changeover Figure 2-2 shows the actions taken for each subscriber when a new aggregation period begins. Figure 2-2 Aggregation Period Changeover In Figure 2-2, the subscriber is logged in and consuming quota. 1. The top half of the figure shows the SCE generating the remaining quota indications and the SM removing the used quota from the subscriber buckets. 2. According to the package and the associated quota profile, a new aggregation period starts. 3. After the start of the new aggregation period, the SCE sends a remaining quota indication. 4. When the SM receives a remaining quota indication, it replenishes the subscriber buckets with the quota amounts defined by the quota profile. Note Due to the configuration of the SCE, the first remaining quota indication may not occur immediately when the new aggregation period begins. This period of time is highlighted in blue in Figure 2-2. The quota consumed in this time period is consumed from the quota allocated to the previous aggregation period. The inaccuracy of the quota value is less than or equal to the quota dosage and is dependent on the rate of the remaining quota indications. This is a limitation of the application. Note If the rate at which remaining quota indications are sent is high, the subscriber quota is replenished at a time in close proximity to the new aggregation period start time. However, this increases the number of management messages on the network. Quota Breach Figure 2-3 shows the actions taken in the event that a subscriber completely depletes his quota. Figure 2-3 Quota Breach In Figure 2-3, the subscriber is consuming data from the quota buckets and the SCE is generating remaining quota indications. 1. When the quota reaches a configurable threshold value, the SCE sends a quota threshold indication. 2. In cases in which the subscriber can be granted more quota, a quota set operation is performed. In Figure 2-3, no more quota is available for the subscriber. 3. The subscriber continues to consume quota until the quota buckets are empty. The SCE sends a quota breach indication when the quota buckets are empty. At the same time, the post-breach action, which was configured in the SCA BB Console, is applied to the subscriber. 4. After a new aggregation period starts, the subscriber is eligible for more quota. However, quota is replenished only after the quota manager receives the remaining quota indication. 5. After the quota is replenished, a quota set operation is performed and the subscriber can continue consuming quota. Note Due to the configuration of the SCE, the first remaining quota indication may not occur immediately after the new aggregation period begins. This period of time is highlighted in blue in Figure 2-3. Because the subscriber is breached and the first remaining quota indication has not arrived, the subscriber is not able to consume quota. This is the only case in which quota inaccuracy is not in favor of the subscriber. Maximizing Quota Accuracy One of the most important aspects of the QM is accuracy of the quota levels for any subscriber. When you provision quota using an external server, a trade-off exists between quota accuracy and the number of network messages. To maximize accuracy, configure the rate of the periodic remaining quota indication to a high value, and configure the size of the quota dosage to a small value. A configuration causes performance degradation due to the high number of messages being generated in the network. Quota inaccuracies may occur during the changeover from one aggregation period to the next, or due to an SCE fail-over. The level of inaccuracy depends on the configuration of the following parameters: •Rate of the periodic remaining quota indications •Quota dosage value During an aggregation period changeover, the following occurs until the first quota indication is received in the new aggregation period: •Quota consumed by the subscriber is subtracted from the previous aggregation period. •Quota dosage value limits the size of any quota error. •The interval between the remaining quota indications limits the length of time during which consumed quota is subtracted from the previous aggregation period. In cases of SCE fail-over, the following occurs between the last quota indication in the failed SCE and the first quota indication in the new, active SCE: •Any quota consumed by the subscriber is not removed from the subscriber buckets. •The quota dosage value limits the size of any quota error. •The length of time during which quota is consumed is limited by the interval between the remaining quota indications. In all cases of inaccuracy, the quota remaining is calculated in favor of the subscriber. The only exception is if the aggregation period changeover occurs when the subscriber quota is already breached. SM Startup Sequence During SM startup: 1. The Network Model notifies the QM with a list of new SCEs added to the configuration. 2. The QM creates a PPRC_SCESubsciberApi instance for each new SCE added to the configuration. 3. The QM creates a QuotaListenerImpl instance and registers it on the API instance for each new SCE added to the configuration. 4. The active SM connects to all the SCEs using the API instance. The standby SM does not connect. 5. The SM identifies if the QM configuration file was changed and performs a replenish quota operation for all subscribers based on the QM configuration file changes. EM Agent Startup Sequence During the EM agent startup: 1. The SCAS_BB MBean registers: –The QuotaRdrListener on the RDR server MBean to manage the quota RDRs received from the SML. –The QuotaOperationHandler on the SCESubscriberApiMBean to handle quota updates received from the SCE Subscriber API. 2. After the QuotaRdrListener and the QuotaOperationHandler are registered, SCESubscriberApiMBean waits for incoming PRPC connections from the QM. Subscriber Login At subscriber login: 1. The SM logs in the subscriber to the SCE. 2. The SML detects the login and generates quota-state-restore RDR for the subscriber. 3. The QuotaRdrListener receives the RDR and generates a PRPC quota-state-restore notification using the SCESubscriberApiMBean. 4. The QM receives the notification and it checks the existing quota for the subscriber on all buckets. 5. If quota is available for the subscriber, the QM invokes the quotaUpdate operation. 6. The SCESubscriberApiMBean manages the invocation and asks the QuotaOperationHandler to add the quota. 7. The QuotaOperationHandler updates the quota for the subscriber on the SCE (using quota-add operation). Subscriber Logout At subscriber logout: 1. The SM logs out the subscriber from the SCE. 2. As a result of the logout, the SML generates a remaining-quota Raw Data Record (RDR) (with reason 1) 3. The QuotaRdrListener receives the RDR and generates a quota-status Proprietary Remote Procedure Call (PRPC) notification using the SCESubscriberApiMBean. 4. The QM receives the notification and compares the current quota with the last reported quota of the SCE and then decrements the difference between the current quota and the last reported quota. Quota-Status Notification The SML periodically generates a remaining-quota RDR (reason 0): 1. The QuotaRdrListener receives the RDR and generates a quota-status PRPC notification using the SCESubscriberApiMBean. 2. The QM receives the notification, compares the current quota with the last reported quota of the SCE, and decrements the difference between the current quota and the last-reported quota. 3. If the current quota is negative, the QM checks to verify if more quota is available, and invokes quotaUpdate (PRPC invocation) if more quota is available. 4. The SCESubscriberApiMBean manages the invocation and asks the QuotaOperationHandler to add the quota. 5. The QuotaOperationHandler updates the quota for the subscriber (using quota-add operation). Quota Below Threshold Notification When the SML generates a quota-below-threshold RDR: 1. The QuotaRdrListener receives the RDR and generates a PRPC notification using the SCESubscriberApiMBean. 2. The QM receives the notification, compares the current quota with the last reported quota of the SCE and decrements the difference between the current quota and the last reported quota. 3. The QM then checks to verify if more quota is available, and invokes quotaUpdate (PRPC invocation) if additional quota is available. 4. The SCESubscriberApiMBean manages the invocation and asks the QuotaOperationHandler to add the quota. 5. The QuotaOperationHandler (of SCAS_BB MBean) updates the quota for the subscriber (using quota-add operation). Quota Depleted Notification When the SML generates quota-breach (quota-depleted) RDR: 1. The QuotaRdrListener receives the RDR and generates a PRPC notification using the SCESubscriberApiMBean. 2. The QM receives the notification, compares the current quota with the last reported quota of the SCE and decrements the difference between the current quota and the last reported quota. 3. The QM then checks to verify if more quota is available, and invokes quotaUpdate (PRPC invocation) if additional quota is available. 4. The SCESubscriberApiMBean manages the invocation and asks the QuotaOperationHandler to add the quota. 5. The QuotaOperationHandler updates the quota for the subscriber (using quota-add operation). Quota Replenishment Quota replenishment occurs in the following scenarios: •A new aggregation period occurs when the number of the slice is equal to 1 (old quota model support). •The first quota notification occurs in the life of a subscriber. •When the QM is started. Because the last configuration is not saved, it is not known if the configuration was changed. The QM assumes the configuration changed and invokes a quota replenishment. •If the customer configures the global flag recet_quota_on_profile_change and one of the following has occurred: –The Quota Profile (packageID) of the subscriber is changed (through SM CLU or due to the move to the penalty package or out of the penalty package). –The static configuration of the quota policies is modified, and a new configuration is loaded on the QM. Limitations If the Quota Manager is configured with a large number of quota profiles, typically more than 25, the Cisco Service Control Subscriber Manager may not persist all quota profiles in SM DB due to database limitations. This may lead to a quota replenishment while restarting or upgrading the Subscriber Manager. Penalty Flows The subscriber enters the penalty mode when the subscriber uses the entire quota before the window (aggregation period) ends and enters the configured penalty profile for their subscriber package. When such situation is identified: •The subscriber is moved to the configured "penalty" package to the configured period of time. •If configured, subscriber quota usage history prior the penalty is kept in the SM DB. When penalty time passes, the QM checks subscriber's usage during the penalty and moves the subscriber to the post-penalty package according to the configuration. If the subscriber quota usage did not fit any post-penalty threshold, then the subscriber stays in penalty for another penalty period. SCE Removal from the Configuration When an SCE is removed from the configuration: 1. The NetworkModel notifies the QM that an SCE was removed from the configuration. 2. The QM unregisters the quota listener from the removed SCE and the QM disconnects from the removed SCE. SM Fail-Over When an SM fails: 1. The failed SM disconnects from each SCE without unregistering the quota listener. 2. The quota notifications accumulate on the each SCE internal buffer. 3. The standby SM connects to each SCE and the quota notifications are sent to the new active SM. SCE Fail-Over The QM stores the SCE that sent the last quota notification. When the QM receives a notification from a different SCE, it does not calculate the quota usage (it ignores the last SCE bucket sizes, which are not relevant), and updates the last SCE bucket sizes according to the notification. The quota that was consumed on the failed SCE since the last notification is not accounted for.
	Terms & Conditions \| Privacy Statement \| Cookie Policy \| Trademarks