Cisco Service Control Application for Broadband Introduction to Policy Integration ソリューション ガイド、 リリース 3.6.x
目次
リアルタイムでのサブスクライバのプロビジョニングおよびモニタリング
Cisco Service Control Application for Broadband Introduction to Policy Integration ソリューション ガイド、リリース 3.6.x
ソリューションの概要
•
「レポート」
ここでは、Cisco SCA BB ソリューションを構成する論理コンポーネントを説明します。SCA BB ソリューションは、サービス プロバイダー向けにサービスを作成するためのプラットフォームとして使用できます。
図 1 および図 2 は、典型的なサービス プロバイダー環境に統合された SCA BB ソリューションのアーキテクチャ全体、および主なコンポーネントとそれらの相互関係を示します。最初の図は、Subscriber Manager コンポーネントを含む SCA BB ソリューションを示します。2 つ目の図は、SCE プラットフォームと直接統合された状態（SM なしの統合）を示します。ここでは、SM コンポーネントは含まれておらず、サード パーティ製ポリシー サーバが SCE プラットフォームと直接通信します。
図 1 Cisco SCA BB ソリューション システム（SM あり）
図 2 Cisco SCA BB ソリューション システム（SM 統合なし）
Cisco SCE プラットフォーム
Cisco SCE プラットフォームは、ソリューションの中核となる、ハードウェア アクセラレーション搭載のディープ パケット インスペクション デバイスです。サービス作成のシナリオでは、SCE プラットフォームがサブスクライバ IP データ パス上にインラインで配置されており、顧客のビジネス ロジックに合わせて、ディープ パケット インスペクションおよびアプリケーション/プロトコル認識を、サブスクライバ単位での関連ポリシーの実施と組み合わせて実現します。
このデバイスは、NMS（CLI、SNMP を使用）、およびサービス設定、サブスクライバ管理、マルチユニット設定に使用されるいくつかの独自ツールを介して設定、モニタされます。すべてのツールは、SCA BB Console アプリケーションに統合されています。プラットフォームは、サブスクライバを認識し（「リアルタイムでのサブスクライバの管理および制御」を参照）、サブスクライバ レベルのクォータの管理および課金など、使用量に基づいたサービスに使用できます。さらに、プラットフォームは、モニタおよび分析の目的で、ネットワーク使用状況のデータをさまざまな粒度で生成します。
SCE プラットフォームおよびこのプラットフォームの各種設定インターフェイスの詳細については、『 Cisco SCE 2000 Installation and Configuration Guide 』および『 Cisco SCE 2000 Quick Start Guide 』を参照してください。
ポリシーおよびサービスの設定
ポリシーおよびサービスの設定とは、特定のサブスクライバ トラフィックを制御するためのさまざまなポリシーに加え、トラフィックをグローバルに分析および制御する方法を定義する静的なシステム設定を指します。
顧客のビジネス ロジックに合わせたポリシー定義は、すべての配置での前提条件であり、ソリューションの他の側面を定義するコンテキストを提供します。
ポリシーおよびサービスの設定は、SCA BB Console または SCA BB Service Configuration API を使用して作成されます。サービス設定は、PQB と呼ばれる独自のファイル形式にコンパイルされます。これは、SCA BB Console または servconf コマンドライン ユーティリティを使用して SCE プラットフォームに適用できます。
（注） ポリシーの実施については、サブスクライバ トラフィックが SCE を介して通過する前に、ポリシーおよびサービスの設定を適用する必要があります。
サービス設定の詳細については、『 Cisco Service Control Application for Broadband User Guide 』および『 Cisco SCA BB Service Configuration API Programmer Guide 』を参照してください。
リアルタイムでのサブスクライバの管理および制御
動的な IP 環境または動的なポリシー環境におけるサブスクライバ対応ソリューションでは、サブスクライバの管理をリアルタイムで実行できる必要があります。ソリューションのこの特徴により、次に関連する機能を実現できます。
• 管理されたサブスクライバ エンティティへのネットワーク IP アドレスまたは他のネットワーク ID のマッピング
• 動的なポリシー管理のその他の特性の使用（セルフケア ポータルやターボ ボタンなど）
Cisco Service Control Subscriber Manager コンポーネントは、このサブスクライバに関連するほとんどの機能および API を提供します。
さらに、SCA BB ソリューションでは、SCE プラットフォームとの直接統合を使用することで、サブスクライバ管理を簡単に行うことができます。多くの場合これは、既存のアプリケーションを利用した方が良いサービス プロバイダー（完全なポリシー サーバまたは類似のシステムをすでに購入している場合など）にとって有益です。サービス プロバイダーは、Cisco Service Control Subscriber Manager コンポーネントを外すことで、すでに配置および管理しているネットワーク要素を減らし、その結果、全体の運用コストを最適化することもできます。
直接統合により、一般的には配置が簡素化されますが、SCE プラットフォームと通信するアプリケーションでは、Cisco Service Control Subscriber Manager で以前提供されていたいくつかの機能を実装する必要があります。たとえば、複数の SCE ユニットのサポート、冗長性方式をサポートすることによる高可用性への対処、さまざまなフェールオーバー事例への対応などです。
サブスクライバ管理の統合は、プッシュ モードとプル モードの 2 つの統合モードを使用して実現できます。これらのモードでは、サブスクライバのログインで、それぞれ異なるイベントのシーケンスを利用します。プッシュ モードでは、ポリシー サーバなどの外部エンティティがサブスクライバの作成または更新をトリガーし、サブスクライバがデータ トラフィックを送信する前に SCE に対して情報をプロビジョニングします。プル モードでは、SCE が、不明（匿名）な送信元に属するデータ トラフィックを受信するときにサブスクライバを識別します。次に、サブスクライバの ID を求める要求を送信することでポリシー サーバにクエリーを発行し、その結果、ログイン操作をトリガーします。ポリシー サーバは、必要なサブスクライバ情報を SCE に返します。
サブスクライバ管理とクォータ プロビジョニングの機能は、別個の 2 つのアプリケーションで実行されることがあり、この場合 SCE は両方と統合する必要があります。
詳細については、『 Cisco Service Control Management Suite Subscriber Manager User Guide 』、『 Cisco SCMS Subscriber Manager Java API Programmer Guide 』、『 Cisco SCMS Subscriber Manager C/C++ API Programmer Guide 』、および『 Cisco SCMS SCE Subscriber API Programmer Guide 』を参照してください。
レポート
Cisco SCA BB のレポート作成ソリューションでは、SCE デバイスによって分析されたネットワーク使用量のデータの生成、収集、および集約を行います。データは、数段階の細かさで取得でき、さまざまなシナリオ（ネットワーク分析、傾向の確認、後払い請求、オフライン監査など）用に調整できます。
Cisco SCA BB では、Collection Manager ソフトウェアを使用した Raw Data Record（RDR; 未加工データ レコード）の収集が可能です。RDR は、その種類および顧客の使用法に応じて、JDBC 準拠のデータベースに保存したり、ファイルに書き込むことができます。収集した情報を提示するには、レポート作成ツール（シスコ独自のツールまたは汎用ツール）を使用できます。SCA BB ソリューションには、SCA BB Console の一部としてレポーター アプリケーションが含まれています。
レポート作成機能は、Cisco SCA BB ソリューションのほとんどの実装で主要な機能となっています。ただし、サービス作成とは直接関係しないため、ここでは取り上げません。
レポート作成の詳細については、『 Cisco SCMS Collection Manager User Guide 』を参照してください。
サービス作成統合モデル
• 「サービス設定」
• 「リアルタイムでのサブスクライバのプロビジョニングおよびモニタリング」
サービス作成環境では、Cisco SCA BB は通常、Policy Server（PS; ポリシー サーバ）システム（プロバイダーの OSS の一部である可能性もあり）と統合されます。このシステムは、サブスクライバのポリシーをリアルタイムで管理し、サブスクライバの使用量（およびモニタ サブスクライバの使用量）のクォータをプロビジョニングし、ソリューションの課金を処理します。
このシステムは、サブスクライバ限定の内部システムにすることも、オープン システムにすることもできます。内部システムの場合、サブスクライバ向けのインターフェイスはありません（サブスクライバには、オフラインで購入済みの事前定義されたサービスレベルとクォータが割り当てられます）。オープン システムの場合、サブスクライバは、セルフ ケア ポータルを介して、（プロバイダーの定義に基づいて）使用量ポリシーとクォータを独自に購入し、プロビジョニングできます。
フル ソリューションは、ポリシー サーバの機能の性能に応じて変わります。Cisco SCA BB ソリューションは、フル ソリューションの範囲内で、ネットワークの実施とアカウンティング プラットフォームを提供します。
ソリューションとサブスクライバの動的ネットワーク マッピングを同期するには、ソリューションを、IP マッピング（DHCP、AAA など）を担当するプロバイダーのバックエンド システムと統合する必要があります。
ポリシー サーバ ベンダーまたは開発者と関係がある、ソリューションの主な側面は次のとおりです。
• リアルタイムでのサブスクライバ ポリシー プロファイル マッピング
サブスクライバ IP マッピングも要件の 1 つであり、多くの場合ポリシー サーバがサブスクライバ IP マッピングを担当します。ただし、これはサーバの必須機能ではありません。マッピングは、ポリシー サーバ自体ではなく、IP マッピングを担当するバックエンド システム（DHCP サーバなど）との統合や、すでに述べたように、RADIUS/DHCP トラフィックからデータを傍受することで実現される場合もあるからです。
SCA BB ソリューションでのレポート作成は、リアルタイム統合プロセスにはあまり関係しません。これは、RDR ベースのインターフェイスを介した後払いの課金方式が用意されている場合だけ関連します。レポート作成プレーンを介した統合の詳細については、『 Cisco SCMS Collection Manager User Guide 』（Cisco Collection Manager ソフトウェアを使用した統合の場合）、または RDR-Toolkit および『 Cisco Service Control Application for Broadband Reference Guide 』（RDR を使用した直接統合の場合）を参照してください。
サービス設定
サービス設定は静的であり、これによりさまざまなポリシー プロファイルが、サービス プロバイダーの顧客向けのプラン、製品、またはパッケージとして定義されます。サービス プロバイダーのポリシー定義に合わせてビジネス ロジックを定義することで、プロバイダーは、サブスクライバのサブスクリプション タイプに応じて、事前定義されたポリシーをサブスクライバに割り当てることができます。ポリシー プロファイルでは、次のことを定義します。
• サブスクライバに割り当てられるサービス単位での全体の QoS
• サブスクリプションに含まれる、許可および制限（ブロック）されたサービスの定義
• ポリシーの基盤となるクォータの構造（つまり、どのサービスがどのクォータから消費されるか、どのサービスが使用率の原因になっているかなど）、およびサブスクライバの使用量が許可されているクォータを超えた場合に適用される対応する定義
サービス設定は、『 Cisco Service Control Application for Broadband User Guide 』および『 Cisco SCA BB Service Configuration API Programmer Guide 』に詳しく説明されています。
リアルタイムでのサブスクライバのプロビジョニングおよびモニタリング
SCA BB ソリューションは、リアルタイムでのサブスクライバのプロビジョニングおよびモニタリングをサポートする API およびインターフェイスを多数備えています。
• Subscriber Manager API（SM-API）：SM コンポーネントを含む配置内の SCMS Subscriber Manager を更新、照会、および設定するために使用されます。
SM-API
SM-API は、直接統合ではなく SM を使用する配置内の SCA BB ソリューション全体にわたり、さまざまな管理の側面で使用されます。このような配置の場合、この API は、サブスクライバに適用するポリシーを定義するため、ポリシー サーバによって使用されます。ポリシーは、サービス設定で定義されたとおり、ポリシー プロファイル（パッケージ）ID によって識別されます。この API の使用法には、サブスクライバの静的な導入、セルフ プロビジョニング、ターボ ボタンの有効化などさまざまな事例があります。
SM-API は、クライアント API（非ブロッキング実装とブロッキング実装の両方）として用意されており、Java と C/C++（Windows、Sparc-Solaris プラットフォーム、および Red Hat Linux）で使用できます。
SM-API は、Cisco Service Control Management Suite Subscriber Manager スイートの一部として提供されています。詳細については、『 Cisco SCMS SM Java API Programmer's Guide 』および『 Cisco SCMS SM C/C++ API Programmer's Guide 』を参照してください。
SCE Subscriber API
SCE Subscriber API は、SM コンポーネントと関係せず SCE と直接統合するため、ポリシー サーバによって使用されます。この API では、次のような各種機能がサポートされます。
• ネットワーク ID アソシエーション：一意のサブスクライバ ID およびサブスクライバ ネットワーク ID と、サブスクライバに割り当てられたポリシー プロファイルまたはパッケージの関連付け
• ポリシー プロビジョニング：一意のサブスクライバ ID と、サブスクライバに割り当てられたポリシー プロファイルまたはパッケージの関連付け
ネットワーク ID アソシエーション
サブスクライバのマッピング API には、サブスクライバを作成するためのログイン操作、およびサブスクライバの属性の変更（サブスクライバがすでに存在する場合）を行う機能があります。この操作は、サブスクライバ ID および SCE への他の情報をプロビジョニングする必要が発生したときに、ポリシー サーバによって呼び出されます。これは、たとえば、サブスクライバがネットワークにログインしたことが通知されるとき、またはポリシー サーバがプル要求に応答するときに発生します。
ログイン操作には、次のようないくつかのパラメータが含まれます。
• サブスクライバ ID（OSS ID）：サブスクライバを一意に識別
• サブスクライバ ネットワーク ID：IP アドレス、IP 範囲、VLAN、およびトンネル ID の複数のインスタンスを表すことが可能
• （オプション）ポリシー プロファイル ID：ポリシー サーバによって割り当てられ、サービス設定フェーズで事前設定される、ポリシー プロファイルの ID
• （オプション）初期サービス クォータ：サブスクライバ用の初期サービス クォータ（ある場合）
ログイン操作は、サブスクライバ ネットワーク ID が変更されるとき（DHCP サーバが別の IP アドレスを割り当てるとき）、複数の IP アドレスとともにサブスクライバ用の IP アドレス インスタンスを追加するとき、またはサブスクライバの作成後にサブスクライバ ポリシーを変更するときに、サブスクライバ ネットワーク ID を更新（追加または設定）するために再使用できます。
ポリシー プロビジョニング
ポリシー プロファイルは、サブスクライバの初回作成時のログイン操作を使用してサブスクライバに割り当てたり、サブスクライバがアップグレードまたはダウングレードされて別のポリシーの実施が必要になったときに割り当てることができます。
（注） ポリシーはこのように、統合モード（プッシュ モードまたはプル モード）に関係なくプロビジョニングできます。
クォータ プロビジョニング
クォータ プロビジョニングのメカニズムは、特定のサービスを消費するためにサブスクライバにクォータを割り当て、あとでそれを管理するという機能に基づいています。SCE Subscriber API では、次のようなクォータ プロビジョニング イベントがサポートされます。
クォータは、サブスクライバのログイン時にプロビジョニングできます（「ネットワーク ID アソシエーション」を参照）。これは、たとえば、ポリシー サーバでもクォータ プロビジョニングがサポートされている場合に使用できます。ネットワーク オペレータのエコシステムに別個のクォータ プロビジョニング システムが含まれている場合、クォータは、ログイン操作後に個別に設定できます。
クォータは、サービス プロバイダーのビジネス ロジックに応じて、小さい単位でプロビジョニングされます。SCE 内にある特定のサービスまたはバケットの最新クォータが（サブスクライバによるサービスの消費が原因で）設定済みのしきい値を下回った場合、またはクォータが枯渇した場合、SCE は通知イベントをクォータ プロビジョニング システムに送信します。このイベントは、サブスクライバからのクォータ補充要求として解釈される場合があります。クォータ プロビジョニング システムは、クォータ設定または追加操作に応答する場合があります。
サブスクライバによるサービスの消費を反映したクォータの変更については、残りのクォータの値を示す定期通知またはオンデマンド通知を使用して報告を受けることができます。たとえば、ポータルを介してサブスクライバにクォータの現在のステータスを示すために使用できます。サブスクライバが自身のクォータに違反したときに通知を受けるオプションもあります。
残りのクォータは、サブスクライバのログアウト時にクォータ プロビジョニング システムに報告されます。サブスクライバがサービスに初めてアクセスする際（まだクォータが割り当てられていないとき）のユーザ エクスペリエンスを向上するため、SCA BB を使用して猶予期間を設定できます。この猶予期間中、サブスクライバは、最初のクォータ プロビジョニング ステージが完了するまでサービスにアクセスできます。
クォータ プロビジョニングの詳細については、『 Cisco Service Control Application for Broadband User Guide 』を参照してください。
SCE Subscriber API は現在、Java で実装されています。
SCE Subscriber API の詳細については、『 Cisco SCMS SCE Subscriber API Programmer Guide 』を参照してください。
サービス作成統合：例
ここでは、具体的な事例を示します。取り上げる事例は基本的なものですが、ビジネス ロジックの基礎を実装するためのさまざまなインターフェイスの使用法を示しています。実際の実装はより複雑で、ここで示す基礎をさらに大規模に混合して使用している場合があります。
• 「例 II：「自由に使用可能」な Turbo Button」
ビジネス使用事例
• General Internet Access：一般的なブロードバンド インターネット アクセス。
• Premium Content：ブロードバンド オペレータが「プレミアム コンテンツ」として宣伝している特定のコンテンツ サイトへのアクセス。
ユーザには、一般的なインターネット アクセス向けに月単位（月をまたいで計上されない）でクォータが割り当てられています。クォータが枯渇すると、トラフィックの速度はダイヤルアップ速度の 64 kbps に下がります。Premium Content へのアクセスは、月単位のクォータには計上されず、ダイヤルアップ速度に下がることもありません。
ステップ I：ポリシー設定
Premium Content サービスを定義するには、次の手順を実行します。
ステップ 1 図 4 に示す [Flavors Settings] ウィンドウを使用して、Premium Content サービス用のサーバ一覧を定義します。
簡単に示すため、ここではサーバ一覧に基づいて Premium Content サービスが定義されることを前提としています。
図 4 [Flavor Settings] ウィンドウ：[Flavors Editing] ダイアログ
ステップ 2 Premium Browsing サービスのサービスを、HTTP プロトコルと、ステップ 1 で定義した指定サーバの一覧を含む Premium Content フレーバに基づいて定義されるように変更します（図 5）。
図 5 [Service Configuration Editor] ウィンドウ：Premium Browsing サービス
この例で使用されるビジネス ロジックは、サブスクライバのトラフィックが General Internet Access と Premium Content に分割されるように指定します。General Internet Access は、1 つのバケットからクォータ制御されます（同じバケットからアップストリームとダウンストリームの両方で消費）。Premium Content トラフィックは、クォータ制御されません（代わりに後払い方式で課金）。
ステップ 1 図 6 に示すように、Premium Browsing サービスに「Free Premium Content」という新しいパッケージを追加します。
図 6 [Package Settings] ウィンドウ：[General] タブ
ステップ 2 図 7 に示すように、[Quota Management] タブを使用してクォータ管理を外部制御に設定します。
図 7 [Package Settings] ウィンドウ：[Quota Management] タブ
図 8 に示すように、パッケージが作成されます。
図 8 [Service Configuration Editor] ウィンドウ：Premium Browsing サービス
ステップ 3 図 9 に示すように、Premium Browsing サービスに新しいルールを追加します。
図 9 [Add New Rule to Package]：[General] タブ
Free Premium Content パッケージには、図 10 に示すように 2 つのサービス ルールが含まれるようになりました。
図 10 [Service Configuration Editor] ウィンドウ：Premium Browsing サービス
ステップ 4 [Edit Rule for Service] ダイアログボックスの [Usage Limits] タブを使用して、アップストリーム トラフィックとダウンストリーム トラフィックの両方でクォータをバケット番号 1 から消費するように、その他のすべてのサービス（Premium Browsing 以外）を定義します。
バケットは通常、アップストリーム ボリューム、ダウンストリーム ボリューム、およびセッションを管理するために使用できます。この例では、ボリューム ベースのクォータだけを扱います（図 11）。
図 11 [Edit Rule for Service] ウィンドウ：[Usage Limits] タブ
Premium Browsing サービスは、クォータ バケットとは関連付けられていないため、クォータ制限されません。ただし、このサービスを使用すると、SCE Subscriber API を使用したクォータ使用量に関する通知には反映されます。
月単位のクォータ パッケージの概要を図 12 に示します。
図 12 [Service Configuration Editor] ウィンドウ：Premium Browsing サービス
猶予期間を SCA BB で設定することで、初めてサービスにアクセスするサブスクライバのユーザ エクスペリエンスを向上できます。猶予期間により、サブスクライバは、最初のクォータ プロビジョニング ステージが完了するまでサービスにアクセスできます。猶予期間を設定すると、割り当てられているクォータ量とは関係なく、利用できる残高がなくても、サブスクライバがサービスを利用できてしまうため、比較的短く設定する必要があります。猶予期間は、サービスを利用するサブスクライバに対する、プロバイダーから見た信用度が反映されており、サブスクライバに残高があることを前提としています。この動作は完全に設定可能であり、プロバイダーのビジネス ロジックに応じて変わります。
ステップ 1 猶予期間を定義するには、[Advanced Service Configuration] ウィンドウ（図 13）を使用します。
図 13 [Advanced Service Configuration Options] ウィンドウ
Quota RDR は、SCE Subscriber API の一部である、クォータ通知のための内部トリガーです。クォータ機能を使用する際は、すべての RDR が有効であることを確認します。
残りのクォータ RDR の期間は、オペレータの希望に基づいて設定する必要があります。
RDR 生成のしきい値は、プロビジョニングされているクォータ チャンク サイズと、サービスによって使用される帯域幅の予想値に基づいて、オペレータが決定する必要があります。クォータのしきい値に関する通知の目的は、ポリシー サーバが、既存のクォータが枯渇する前に新しいクォータ チャンクをプロビジョニングできるようにし、その結果、サブスクライバの残高が残っている間はサービスが継続されるようにすることです。
このシステムは、RPC サーバを有効にし、RDR（SCE Subscriber API で通知に変換される）を内部 RDR リスナーに送信できるように設定する必要があります。設定は、次のコマンドを使用して SCE CLI で実行されます。
パッケージ BW コントローラを定義する必要があります。サブスクライバに割り当てられる帯域幅の合計は 1 Mbps に制限されます。
違反したサービス トラフィックを制限するために設計された「Depletion BWC」も定義する必要があります（アップストリームおよびダウンストリーム）。
ステップ 1 [Package Settings] ウィンドウ（図 14）を使用して、パッケージ BW コントローラと Depletion BWC を定義します。
図 14 [Package Settings] ウィンドウ：[Subscriber BW Controllers] タブ
すべてのサービスは、BW コントローラの合計の下にデフォルトで配置されます。
General-Internet-Access クォータが枯渇すると、このサービスはサブスクライバ BW コントローラにマップされ、最大 64 kbps までの消費が許可されます。サブスクライバには、クォータ枯渇が原因で帯域幅が削減されたことを通知する必要があります（サブスクライバ通知を使用）。
サブスクライバ通知機能を使用すると、ブラウジング セッションが定義済み Web ポータルにリダイレクトされた状態に、サブスクライバを自動的に移すことができます。クォータが枯渇したためにインターネット アクセス速度が低下したことが、Web ポータル ページからサブスクライバに通知されます。
ステップ 1 図 15 に示すように、適切な Web ページを設計します。
ステップ 2 [Subscriber Notifications Settings] ウィンドウ（図 16）を使用して、サブスクライバ通知を定義します。
図 16 [Subscriber Notification Settings] ウィンドウ
ステップ 3 宛先 URL により、サブスクライバはステップ 1 で作成した Web ポータル ページに誘導されます。
ステップ 4 違反時に実行する処理を選択します（図 17）。この処理では、General-Internet-Traffic Quota（バケット 1）から消費するすべてのサービスが、Depletion Bandwidth Controller にマップされます。サブスクライバ通知の有効化も選択する必要があります。
図 17 [Edit Rule for Service] ウィンドウ：[Breach Handling] タブ
（注） ここで取り上げる実装（SCA BB 違反処理動作）は、簡単なクォータ違反動作を実装する場合に便利です。さらに複雑な制御ロジックを実行するには、サブスクライバ パッケージを変更するトリガーとして、クォータ枯渇通知をポリシー サーバで使用します。これにより、クォータが枯渇したときにサブスクライバに実施する制御の本質上、ポリシー サーバが柔軟になります。
ステップ II：リアルタイム クォータ プロビジョニング プロセス
このビジネス使用事例でのリアルタイム クォータ プロビジョニング プロセスは、クォータの可用性に基づいて（Quota Below Threshold 通知および Quota Depleted 通知を使用）、要求時にサブスクライバにクォータを割り当てるサブスクライバ残高マネージャに基づいています。
このビジネス ロジックを実装するため、ポリシー サーバは、SCMS SCE Subscriber API を使用してクォータ要求を受け取り、これに合わせて Quota Update メソッドでクォータをプロビジョニングします。
• サブスクライバがクォータなしでログイン：ポリシー サーバは、SCE で生成される Quota Depleted イベントに応答して、サブスクライバの残高に基づいたクォータをプロビジョニングします。ポリシー サーバでサブスクライバのマッピングとクォータのプロビジョニングを両方とも処理する場合、クォータをログイン操作とともにプロビジョニングできます。LOGINREQUEST イベントや LOGINPULL-RESPONSE イベントなどの SCE Subscriber API イベントは最適化され、すべてのサブスクライバ情報は SCE に送信されます。単一のポリシー サーバが、クォータ プロビジョニングを含むサブスクライバ プロビジョニングのすべての部分を実行する場合は、ポリシー プロファイルおよびクォータの更新にこのようなイベントを使用することを推奨します。
• サブスクライバに割り当てられたクォータ チャンクが枯渇しそうな場合、ポリシー サーバは、SCE によって生成された Quota Below Threshold イベントに応答して、サブスクライバの残高に基づいたクォータをプロビジョニングします。
このような操作の使用法の詳細については、『 Cisco SCMS SCE Subscriber API Programmer Guide 』を参照してください。
ステップ III：Depletion イベント時の処理
Depletion イベントは、Quota Depleted 通知イベントを通じてポリシー サーバに発信されます。一部の定義済みロジックを実行するため、ポリシー サーバはこうした通知を受け取る必要があります。この例では、違反動作が SCA BB 内で実装されるため、ポリシー サーバに必要なのはイベントの詳細をログすることだけです。
サブスクライバのログアウト処理
サブスクライバがネットワークから意図的または暗黙的に（セッション失効などが原因で）ログアウトする際、サブスクライバのレコードは再びログインするまで SCE から削除されます。
このような場合、通知がトリガーされます。通知には、サブスクライバのバケットに残っているクォータ量が含まれます。この通知により、ポリシー サーバでは、残りのクォータをサブスクライバの残高に追加してクォータが失われないようにし、使用済みクォータの量を処理して収益の漏れを防止できます。
このイベントの流れを図 18 に示します。
ビジネス使用事例
このビジネス使用事例は、簡単なクォータ ベースのシナリオです。サブスクライバには、特定のアクセス速度を許可するポリシーを割り当てます。すべてのサービスに関する使用量は、単一のクォータ バケットから消費されます。
サブスクライバは、Web インターフェイスで「Turbo Button」を使用して、一定期間アクセス速度を上げることができます。
この期間の間、サブスクライバはクォータに関係なく高速アクセスが許可されます。期間が終了すると、サブスクライバには通常のアクセス プランと残りのクォータが再び割り当てられます。
概要
図 19 は、このビジネス使用事例の実装方法の概要を示しています。ステップバイステップの説明を読んだ後に、この項に戻ることを推奨します。
図 19 は、直接統合が使用された場合のイベントの流れを示しています。ポリシーのプロビジョニングは、SM 配置の SM API を使用してプロビジョニングすることもできます。
ステップ I：ポリシー設定
クォータ ベース パッケージは、前の例に似た手法で構築され、管理されます。このポリシーのクォータ関連部分の構築方法については、「ステップ II：リアルタイム クォータ プロビジョニング プロセス」を参照してください。
サブスクライバが「Turbo Button」を選択すると、このパッケージはサブスクライバにプロビジョニングされます（「ターボ」期間が終了するとプロビジョニングは解除されます）。このパッケージによりサブスクライバの合計アクセス速度が高められ、クォータによる課金がなくなります。このパッケージのすべてのサービスは「無制限クォータ」で定義する必要があります。
ステップ 1 [Package Settings] ウィンドウを使用して、パッケージ BW コントローラを定義します（図 20）。
図 20 [Package Settings] ウィンドウ：[Subscriber BW Controllers] タブ
「Turbo」パッケージの概要を図 21 に示します。
図 21 [Service Configuration Editor] ウィンドウ：Premium Browsing サービス：Turbo
ステップ II：リアルタイム プロビジョニング プロセス
ここでは、必要なビジネス ロジックをサポートするため、SCA BB Subscriber API、インターフェイス、ツールを使用してポリシー サーバで実装する必要のあるロジックに言及します。
この例のクォータ プロビジョニングは、前の使用事例と同じです。ただし、パッケージが変更されると、サブスクライバの残りのクォータを反映した、残存クォータ通知が SCE によって生成されます。
（注） パッケージの変更時、サブスクライバの残高は変更されません。つまり、「ターボ時間」が過ぎると、クォータ バケットは「ターボ時間」以前と同じ状態になります。
ベンダーはまず、Turbo Button の有効化のためにフロント エンドを構築する必要があります。この例では、サブスクライバが認証し、Turbo Button を使用してアクセス パッケージを一時的にアップグレードすることを選択できる Web ページを構築します。
ステップ 1 図 22 に示すように、サブスクライバをアクティブにするフロント エンドを構築します。
ステップ 2 Turbo Button の選択後、ポリシー サーバは、サブスクライバの「Turbo Button」パッケージを SCA BB ソリューションにプロビジョニングする必要があります（直接統合の場合は SCE Subscriber API、直接統合でない場合は SM-API によってこれを行います）。
ポリシー サーバでは、Turbo Button によって許可された高速の自由使用期間が過ぎたら、元のパッケージを復元する必要があります。
ステップ 1 ポリシー サーバで元のパッケージを復元します。直接統合の場合は SCE Subscriber API、直接統合でない場合は SM-API を使用してこれを実行します。
ステップ 2 ポリシー サーバは、必要に応じてクォータ（単数または複数）を再びプロビジョニングします。Turbo Button がアクティブな期間中は、クォータは変更されません。Turbo Button 期間の終了時、サブスクライバには同量のクォータがあります。Turbo Button 期間後にサブスクライバがサービスにアクセスすると、クォータは通常どおりに消費され始め、通常の方法で補充する必要があります。これは、Quota Below Threshold または Quota Depleted 通知によってトリガーされる SCE Subscriber API（set primitive）を使用して実行します。
詳細については、『 Cisco SCMS SCE Subscriber API Programmer Guide 』を参照してください。
マニュアルの入手方法およびテクニカル サポート
マニュアルの入手方法、テクニカル サポート、その他の有用な情報について、次の URL で、毎月更新される『 What's New in Cisco Product Documentation 』を参照してください。シスコの新規および改訂版の技術マニュアルの一覧も示されています。
http://www.cisco.com/en/US/docs/general/whatsnew/whatsnew.html
『 What's New in Cisco Product Documentation 』は RSS フィードとして購読できます。また、リーダー アプリケーションを使用してコンテンツがデスクトップに直接配信されるように設定することもできます。RSS フィードは無料のサービスです。シスコは現在、RSS バージョン 2.0 をサポートしています。
フィードバック