Cisco SCA BB Introduction to Policy Integration ソリューション ガイド Release 3.1
偏向のない言語
この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
翻訳について
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
- Updated:
- 2017年6月14日
章のタイトル： サービス作成統合—定期クォータ ベー ス サービス
サービス作成統合--定期クォータ ベース サービス
この章では、定期的なクォータ ベースでのサービス統合の使用事例について説明します。
•
「概要」
• 「ポリシー設定」
ビジネス使用事例
• 一般インターネット アクセス ― 一般的なブロードバンド インターネット アクセス。
• プレミアム コンテンツ ― ブロードバンド オペレータが「プレミアム コンテンツ」としてマーケティングしている特定コンテンツ サイトへのアクセス。
ユーザには、一般インターネット アクセスの月次クォータ（翌月繰越なし）があります。クォータが枯渇した場合、トラフィック レートはダイヤルアップ レートの 64 kbps に下げられます。プレミアム コンテンツへのアクセスは月次クォータの一部としてカウントされず、ダイヤルアップ レートに下げられません。
概要
次の図は、このビジネス使用事例の実装の概要を示しています。手順ごとの説明を読んだ後でこのセクションに戻ることを推奨します。
ポリシー設定
• 「リアルタイム クォータ プロビジョニング プロセスの構築」
リアルタイム クォータ プロビジョニング プロセスの構築
このビジネス使用事例のリアルタイム クォータ プロビジョニング プロセスは、クォータの可用性に基づいて（クォータ下限しきい値およびクォータ枯渇通知によって）要求時にサブスクライバにクォータを割り当てるサブスクライバ残高マネージャに基づきます。
このビジネス ロジックを実装するには、ポリシー サーバで SCMS SCE Subscriber API を使用してクォータ要求を受信し、クォータ更新方式で相応にクォータをプロビジョニングします。
• サブスクライバがクォータなしでログイン ― ポリシー サーバが、SCE によって生成されたクォータ枯渇イベントに対応して、サブスクライバの残高に基づいてクォータをプロビジョニングします。ポリシー サーバがサブスクライバ マッピングとクォータ プロビジョニングの両方を処理する場合、クォータはログイン操作とともにプロビジョニングされます。ログイン要求イベントやログイン プル応答イベントのような SCE Subscriber API イベントは最適化され、すべてのサブスクライバ情報は SCE に送信されます。単一ポリシー サーバがクォータ プロビジョニングを含むサブスクライバ プロビジョニングのすべての部分を実行する場合は、ポリシー プロファイルおよびクォータの更新にこのようなイベントを使用してください。
• サブスクライバに割り当てたクォータ チャンクが枯渇しようとしている ― ポリシー サーバは、SCE によって生成されたクォータ下限しきい値イベントに応答して、サブスクライバの残高に基づいてクォータをプロビジョニングします。
このような操作の使用方法の詳細については、『 Cisco SCMS SCE Subscriber API Programmer Guide 』を参照してください。
枯渇イベント時の処理
枯渇イベントは、クォータ枯渇通知イベントによってポリシー サーバに発信されます。ポリシー サーバは、このような通知を受信しないと、定義済みロジックを実行できません。この例では違反動作を SCA BB 内で実装しているので、ポリシー サーバではイベント詳細をログする必要しかありません。
サブスクライバの処理事例
サブスクライバが意図的にまたは暗黙的に（セッションの失効のためなど）ネットワークからログアウトすると、サブスクライバのレコードは再びログインするまで SCE から削除されます。
このような場合は通知がトリガーされます。この通知には、サブスクライバのバケットに残っているクォータ量が含まれます。ポリシー サーバでは、この通知により、残存クォータをサブスクライバの残高に追加してクォータが失われないようにしたり、使用済みクォータの量を処理して収益の漏れを防止したりすることができます。
プレミアム コンテンツ サービスの定義
ステップ 1 [Flavors Settings] ダイアログ ボックスを使用し、プレミアム コンテンツ サービスのサーバのリストを定義します。
ここでは単純にするため、プレミアム コンテンツ サービスがサーバのリストに基づいて定義されることを想定します。
図3-3 [Flavor Settings] ダイアログ ボックス
ステップ 2 Premium Browsing サービスのサービスを修正します。
HTTP プロトコルに基づくことなどの Premium Browsing サービスのサービス、およびステップ 1 で定義した指定サーバのリストを含む PremiumContent フレーバーを修正します。
クォータへのサービスの割り当て
この例で使用するビジネス ロジックでは、一般インターネット アクセスとプレミアム コンテンツの間でサブスクライバのトラフィックが区分されることを指定します。一般 インターネット アクセスは、1 つのバケットからクォータで制御されます（アップストリームおよびダウンストリームの両方が同一バケットから消費します）。プレミアム コンテンツ トラフィックはクォータで制御されません（別納課金です）。
手順
1. Free Premium Content という新しいパッケージを Premium Browsing サービスに追加します。
2. [Quota Management] タブを使用し、クォータ管理を外部制御に設定します。
3. 新しい規則を Premium Browsing サービスに追加します。
4. [Service] ダイアログボックスの [Edit Rule] と [Usage Limits] タブを使用して、他のサービスを定義します。
詳細な手順
ステップ 1 Free Premium Content という新しいパッケージを Premium Browsing サービスに追加します。
図3-5 Free Premium Content サービスを追加
ステップ 2 [Quota Management] タブを使用し、クォータ管理を外部制御に設定します。
図3-6 [Quota Management] を [External] に設定
図3-7 Free Premium Content パッケージ
ステップ 3 新しい規則を Premium Browsing サービスに追加します。
図3-8 規則を [Premium Browsing] サービスに追加
Free Premium Content パッケージに 2 つのサービス規則が含まれます。
図3-9 Free Premium Content パッケージ サービスの規則
ステップ 4 [Service] ダイアログボックスの [Edit Rule] と [Usage Limits] タブを使用して、他のサービスを定義します。
アップストリーム トラフィックおよびダウンストリーム トラフィックの両方でバケット番号 1 からクォータを消費するように、PremiumBrowsing を除くすべてのサービスを定義します。
一般的には、アップストリーム ボリューム、ダウンストリーム ボリューム、セッションの管理にバケットを使用できます。この例ではボリューム ベース クォータのみに対処します。
図3-10 [Edit Rule for Service] ダイアログボックス
Premium Browsing サービスはクォータ バケットと関連していないので、クォータで制限されません。このサービスの利用は、SCE Subscriber API を使用してクォータ使用量通知に反映されます。
猶予期間の定義
サービスを初めて利用するサブスクライバの使用感を改善するには、猶予期間を SCA BB で設定できます。猶予期中は、初期クォータ プロビジョニング ステージが完了するまで、サブスクライバがサービスを利用できます。サブスクライバは猶予期間によって、利用可能残高がない場合でも割り当てクォータ量に関係なくサービスを利用できるので、猶予期間は比較的短く設定する必要があります。猶予期間には、残高があることを想定してサブスクライバにサービスを認めるプロバイダーの意思が反映されます。この動作は完全に設定可能であり、プロバイダーのビジネス ロジックによって決まります。
ステップ 1 [Advanced Service Configuration] ダイアログ ボックスを使用し、猶予期間を定義します。
図3-12 [Advanced Service Configuration Options] ダイアログボックス
クォータ RDR 設定の定義
クォータ RDR は、SCE Subscriber API の一部であるクォータ通知の内部トリガーです。クォータ機能を使用する場合は、すべての RDR が有効になっていることを確認してください。
残存クォータ RDR の期間は、オペレータのプリファレンスに基づいて設定する必要があります。
オペレータは、プロビジョニングされるクォータ チャンクのサイズおよびサービスによって消費されると予想される帯域幅に基づいて、RDR 生成のしきい値を判断する必要があります。クォータしきい値通知の目的は、既存クォータが枯渇する前にポリシー サーバが新しいクォータ チャンクをプロビジョニングし、サブスクライバのアカウント残高がプラスである間にサービスを継続できるようにすることです。
システムは、RPC サーバを有効にして、内部 RDR リスナーに RDR（SCE Subscriber API が通知に変換）を送信するように設定する必要があります。
ステップ 1 内部 RDR リスナーへ RDR を送信するように、RPC サーバを設定します。
コントロール スキームの定義
パッケージ BW コントローラの定義
パッケージ BW コントローラを定義する必要があります。サブスクライバに割り当てられる合計帯域幅を 1 Mbps に制限します。
違反サービス トラフィックを制限するために設計された "Depletion BWC" も定義する必要があります（アップストリームおよびダウンストリーム）。
ステップ 1 [Package Settings] ダイアログ ボックスを使用し、パッケージ BW コントローラおよび Depletion BWC を定義します。
図3-13 BW コントローラおよび Depletion BWC の定義
すべてのサービスは、合計 BW コントローラの下にデフォルトで配置されます。
枯渇処理の定義
一般インターネット アクセス クォータが枯渇すると、このサービスはサブスクライバ BW コントローラにマッピングされ、64 kbps までの消費が許可されます。サブスクライバには、クォータが枯渇したために帯域幅が削減されたことをサブスクライバ通知によって通知する必要があります。
サブスクライバ通知機能を使用すると、ブラウジング セッションが定義済み Web ポータルにリダイレクトされた状態にサブスクライバを自動的に移すことができます。サブスクライバは、クォータが枯渇したためにインターネット アクセス速度が低下したことを Web ポータル ページによって通知されます。
（注） ここで説明する実装（SCA BB 違反処理動作の使用）は、簡単なクォータ違反動作を実装する場合に便利です。さらに複雑な制御ロジックを実装する場合は、サブスクライバ パッケージを変更するトリガーとして、クォータ枯渇通知をポリシー サーバで使用できます。これにより、クォータが枯渇したときにサブスクライバに実施する制御の本質上、ポリシー サーバが柔軟になります。
図3-14 Quota Depletion Notification Web ページ
ステップ 2 [Subscriber Notification Settings] ダイアログ ボックスを使用し、サブスクライバ通知を定義します。
図3-15 [Subscriber Notification Settings] ダイアログボックス
宛先 URL では、ステップ 1 で作成した Web ポータル ページにサブスクライバが誘導されます。
この処理では、一般インターネット トラフィック クォータ（バケット 1）から消費するすべてのサービスが Depletion Bandwidth Controller にマッピングされます。サブスクライバ通知の有効化も選択する必要があります。
図3-16 [Setting Breach Handling] 規則
フィードバック