ヘッダーをスキップ
Oracle® WebLogic Server SIP Container開発者ガイド
11g リリース1(11.1.1)
B61430-01
  目次へ移動
目次		 索引へ移動
索引
前
前 		 次
次		  

11 オフライン・チャージング用のDiameter RfインタフェースAPIの使用

この章では、アプリケーションで、Oracle WebLogic ServerのDiameterプロトコル実装に基づいてDiameter RfインタフェースAPIを使用する方法について説明します。内容は次のとおりです。

11.1 Rfインタフェースのサポートの概要

オフライン・チャージングは、定期的に支払いを行うネットワーク・サービスに使用します。たとえば、毎月支払いを行う必要がある音声コール・サブスクリプションをユーザーが利用する場合です。Rfプロトコルを使用することで、IMSチャージング・トリガー機能(CTF)からオフライン・イベントをチャージング・データ機能(CDF)へ発行することが可能になります。チャージング・イベントは、1回かぎりの(ワンタイム)イベントとすることも、セッション・ベースとすることもできます。

Oracle WebLogic Server SIP ContainerはDiameterオフライン・チャージング・アプリケーションを提供します。デプロイ済のアプリケーションは、このアプリケーションを利用してRfプロトコルに基づくチャージング・イベントを生成します。オフライン・チャージング・アプリケーションはDiameter基本プロトコル実装を使用し、Oracle WebLogic Server SIP Containerにデプロイ済のアプリケーションが、構成済のCDFのためにCTFとして機能することを可能にします。

オフライン・チャージングの基本情報については、RFC 3588: Diameter Base Protocol(http://www.ietf.org/rfc/rfc3588.txt)を参照してください。Rfプロトコルの詳細は、3GPP TS 32.299(http://www.3gpp.org/ftp/Specs/html-info/32299.htm)を参照してください。

11.2 オフライン・チャージング・イベントについて

イベントとセッションに基づく両方のチャージングに関しては、CTFはRFC 3588で説明されているアカウンティング状態のマシンを実行します。サーバー(CDF)はRFC 3588で指定されているようにアカウンティング状態のマシン「SERVER、STATELESS ACCOUNTING」を実行します。

CDFへのオフライン・チャージング・イベントのレポーティングは、Diameterアカウンティング・リクエスト(ACR)メッセージを通じて管理されます。Rfは、表11-1に記載されているACRイベント・タイプをサポートします。

表11-1 Rf ACRイベント・タイプ

リクエスト 説明

START

アカウンティング・セッションの開始

INTERIM

アカウンティング・セッションの更新

STOP

アカウンティング・セッションの終了

EVENT

1回かぎりの(ワンタイム)アカウンティング・イベント

START、INTERIMおよびSTOPイベント・タイプは、セッション・ベース・アカウンティングに対し使用します。EVENTタイプは、イベント・ベース・アカウンティングに対し使用するか、セッションの確立が失敗したことを示すために使用します。

11.2.1 イベント・ベース・チャージング

イベント・ベースのチャージング・イベントは、ACR EVENTメッセージを通じて報告されます。例11-1は、基本的なメッセージ・フローです。

例11-1 イベント・ベースのチャージングのメッセージ・フロー

        CTF (WLSS)           CDF (Server)
            |                     |
            | --- ACR (EVENT) --> |
            |                     |
            |                (Process accounting request)
            |                     |
            | <-- ACA (EVENT) --- |
            |                     |

11.2.2 セッション・ベース・チャージング

セッション・ベース・チャージングでは、ACR START、INTERIMおよびSTOPリクエストを使用して、CDFの使用を報告します。セッション中、セッション・ライフサイクルによってはCTFが複数のACR INTERIMリクエストを報告する可能性があります。例11-2は、基本的なメッセージ・フローです。

例11-2 セッション・ベース・チャージングのメッセージ・フロー

        CTF (WLSS)             CDF (Server)
            |                       |
            | --- ACR (START) ----> |
            |                       |
            |                  (Open CDR)
            |                       |
            | <-- ACA (START) ----- |
            |                       |
           ...                     ...
            | --- ACR (INTERIM) --> |
            |                       |
            |                  (Update CDR)
            |                       |
            | <-- ACA (INTERIM) --- |
           ...                     ...
            | --- ACR (STOP) -----> |
            |                       |
            |                  (Close CDR)
            |                       |
            | <-- ACA (STOP) ------ |
            |                       |

ここでACA STARTは、Oracle WebLogic Server SIP Containerによるサービス・リクエストの受信時に送信されます。ACA INTERIMは通常、AIIタイマーの時間切れ時点で送信されます。ACA STOPは、Oracle WebLogic Server SIP Containerによるサービス終了のリクエスト時に発行されます。

11.3 Rfアプリケーションの構成

Rf APIは、プロファイル・データを管理するためのShアプリケーションと似たようなDiameterアプリケーションとしてパッケージされています。Rf Diameter APIは、DOMAIN_ROOT/config/custom/diameter.xmlに格納されているDiameter構成ファイルを編集するか、Diameterコンソール拡張を使用して、構成および有効化できます。また、CDFレルムとホストの構成はいずれも、Diameter Rfアプリケーションへのcdf.realmおよびcdf.host初期化パラメータを使用して指定できます。

例11-3は、CDFレルム「oracle.com」およびホスト「cdf.oracle.com:」でRfを有効化するdiameter.xmlから抜粋したサンプルです。

例11-3 サンプルRfアプリケーションの構成(diameter.xml)

  <application>
    <application-id>3</application-id>
    <accounting>true</accounting>
    <class-name>com.bea.wcp.diameter.charging.RfApplication</class-name>
    <param>
      <name>cdf.realm</name>
      <value>oracle.com</value>
    </param>
    <param>
      <name>cdf.host</name>
      <value>cdf.oracle.com</value>
    </param>
  </application>

RfApplicationはDiameter基本アカウンティング・メッセージを使用するため、DiameterアプリケーションIDは「3」で、ベンダーIDはありません。

11.4 オフライン・チャージングAPIの使用

Oracle WebLogic Server SIP Containerは、オフライン・チャージングAPIを提供します。このAPIにより、デプロイ済の任意のアプリケーションがCTFとして機能し、オフライン・チャージング・イベントを発行することが可能になります。このAPIは、イベント・ベースおよびセッション・ベースのどちらのチャージング・イベントもサポートします。

Com.bea.wcp.diameter.accountingパッケージ内のクラスにより、Diameterアカウンティング・メッセージおよびセッションについての全般的なサポートが提供されます。表11-2に、クラスの概要を示します。

表11-2 Diameterアカウンティング・クラス

クラス 説明

ACR

アカウンティング・リクエスト・メッセージ

ACA

アカウンティング応答メッセージ

ClientSession

クライアント・ベースのアカウンティング・セッション

RecordType

アカウンティング・レコード・タイプ定数

さらに、com.bea.wcp.diameter.chargingパッケージ内のクラスにより、特にRfアプリケーションがサポートされます。 表11-3に、クラスの概要を示します。

表11-3 Diameter Rfアプリケーション・サポート・クラス

チャージング 3GPPチャージング機能の共通定義

RfApplication

オフライン・チャージング・アプリケーション

RfSession

オフライン・チャージング・セッション

RfApplicationクラスを使用して、イベント・ベース・チャージングのACRリクエストを直接送信できます。アプリケーションには、ACRリクエストの送信前にリクエストを直接修正するオプションがあります。これは、リクエストに任意のカスタムAVPを追加するために必要なオプションです。

具体的に言うと、アプリケーションでは、CDFのためのサービス固有パラメータを運ぶService-Information AVPを設定する必要があります。ACRリクエストのService-Information AVPは、アプリケーション固有のチャージング・サービスをCTF (WLSS)からCDF(チャージング・サーバー)へ送信するために使用されます。これはグループ化されたAVPで、その値はアプリケーションとそのチャージング機能に応じて異なります。オフライン・チャージングAPIにより、アプリケーションで、リクエストの送信前にこの情報をリクエストに設定することが可能になります。

セッション・ベース・アカウンティングでは、RfApplicationクラスは、セッション・ベース・チャージング・イベント生成のための新しいアカウンティング・セッションを作成するためにも使用します。各アカウンティング・セッションは、RfSessionのインスタンスで表され、セッション用のアカウンティング状態のマシンをカプセル化します。

11.4.1 Rfアプリケーションへのアクセス

Rfアプリケーションがデプロイされると、Oracle WebLogic Server SIP Containerでデプロイされたアプリケーションは、Diameterノード(com.bea.wcp.diameter.Nodeクラス)からアプリケーションのインスタンスを取得できます。例11-4は、Diameter Nodeを取得してRfアプリケーションにアクセスするため使用するサンプル・サーブレット・コードを示しています。

例11-4 Rfアプリケーションへのアクセス

ServletContext sc = getServletConfig().getServletContext();
Node node = sc.getAttribute("com.bea.wcp.diameter.Node");
RfApplication rfApp = (RfApplication) node.getApplication(Charging.RF_APPLICATION_ID);

アプリケーションは、RfApplicationの単一インスタンスを安全に使用して、オフライン・チャージング・リクエストを複数のスレッド内で同時に発行できます。RfSessionの各インスタンスは、実際には、各呼出しに対し一意のセッションごとの状態を保持します。

11.4.2 セッション・ベース・チャージングの実装

セッション・ベース・チャージング・リクエストでは、アプリケーションは、最初にRfApplicationを使用してRfSessionのインスタンスを作成します。その後、セッション・オブジェクトを使用して1つまたは複数のチャージング・リクエストを作成できます。

最初のチャージング・リクエストはACR STARTリクエストである必要があり、その後、ゼロまたは1つ以上のACR INTERIMリクエストが続きます。セッションはACR STOPリクエストで終了します。対応するACA STOPメッセージを受信すると、RfApplicationが自動的にRfSessionを終了します。

例11-5は、新しいセッション・ベース・アカウンティング・セッションを開始するサンプル・コードです。

例11-5 セッション・ベースのアカウンティング・セッションの開始

  RfSession session = rfApp.createSession();
  sipRequest.getApplicationSession().setAttribute("RfSession", session);
  ACR acr = session.createACR(RecordType.START);
  acr.addAvp(Charging.SERVICE_INFORMATION, ...);
  ACA aca = acr.sendAndWait(1000);
  if (!aca.getResultCode().isSuccess()) {
    ... error ...
  }

例11-5では、呼出しの進捗にともなって追加のアカウンティング・リクエストの送信に使用できるように、RfSessionがSIPアプリケーション・セッション属性として格納されています。例11-6は、INTERIMリクエストをどのように送信するかを示します。

例11-6 INTERIMリクエストの送信

  RfSession session = (RfSession) req.getApplicationSession().getAttribute("RfSession");
  ACR acr = session.createACR(RecordType.INTERIM);
  ACA aca = acr.sendAndWait(1000);
  if (!aca.getResultCode().isSuccess()) {
    ... error ...
  }

呼出しの進行中に、アプリケーションが1つまたは複数のACR INTERIMリクエストを送信しようとする場合があります。ACR INTERIMリクエストの間隔は、通常、CDFにより送信されたACA STARTメッセージ内のAcct-Interim-Interval AVP値に基づきます。このため、アプリケーション・タイマーによって、リクエストされている間隔でACR INTERIMを送信する必要があります。INTERIMリクエストの詳細は、3GPP TS 32.299を参照してください。

11.4.2.1 セッション有効期限の指定

Rfアカウンティング・セッションの有効期限を示すために、Acct-Interim-Interval (AII)タイマー値が使用されます。この値は、ACR STARTがCDFに送られてアカウンティング・セッションが開始するときに指定されます。CDFは独自のAII値を返し、CTFはその値を使って、期限切れ時点でACR INTERIMメッセージを送信するタイマーをスタートさせます。このINTERIMメッセージによって、セッションがまだ使用中であることがCDFに伝えられます。この通知がない場合、CDFはセッションを自動的に終了します。

更新済のサービス情報データはACR INTERIMメッセージでCDFへ送信されるため、アプリケーションはこれらのメッセージを送信する責任があります。AII値に応じて期限切れになるServletTimerを作成することをお薦めします。このタイマーが期限切れになった時点で、アプリケーションは更新済のサービス情報データとともにACR INTERIMメッセージを送信する必要があります。

11.4.2.2 非同期リクエストの送信

通常、アプリケーションは同期sendAndWait()メソッドを使用します。ただし、待機時間が重要な場合は、非同期APIを使用できます。非同期APIでは、CDFから応答メッセージを受信する際、アプリケーション・サーブレットに対し非同期的に通知が行われます。非同期APIを使用するために、アプリケーションは、まずSessionListenerのインスタンスを登録して、セッションに配信されるメッセージを非同期的に受信するようにします(例11-7を参照)。

例11-7 SessionListenerの登録

  RfSession session = rfApp.createSession();
  session.setAttribute("SAS", sipReq.getApplicationSession());
  session.setListener(this);

属性は、SIPアプリケーション・セッション属性を格納するのと同じ方法で、RfSessionインスタンスに格納できます。上の例では、リスナー・コールバックに使用できるように、関連SIPアプリケーションはRfSessionとして格納されています。

CDFからDiameterリクエストまたは応答メッセージを受信すると、rcvMessage(Message msg)メソッドを呼び出すことでアプリケーション・サーブレットに通知が送られます。例11-8に示されているように、関連SIPアプリケーション・セッションがセッション属性として格納されていれば、RfSessionから取得できます。

例11-8 通知後のRfSessionの取得

  public void rcvMessage(Message msg) {
    if (msg.getCommand() != Command.ACA) {
      if (msg.isRequest()) {
        ((Request) msg).createAnswer(ResultCode.UNABLE_TO_COMPLY, "Unexpected request").send();
      }
      return;
    }
    ACA aca = (ACA) msg;
    RfSession session = (RfSession) aca.getSession();
    SipApplicationSession appSession = (SipApplicationSession) session.getAttribute("SAS");
    ...
  }

11.4.3 イベント・ベース・チャージングの実装

イベント・ベース・チャージングの場合、チャージング・リクエストは1回かぎりのイベントであり、対応するEVENT ACAメッセージの受信時点でセッションは自動で終了します。sendAndWait(long timeout)メソッドは、EVENTリクエストを同時に送信し、CDFからレスポンスを受信するまでスレッドをブロックするために使用できます。例11-9では、RfSessionを使用してイベント・ベースのチャージング・リクエストを送信する場合の例を示します。

例11-9 Rfsessionを使用したイベント・ベース・チャージング

  RfSession session = rfApp.createSession();
  ACR acr = session.createACR(RecordType.EVENT);
  acr.addAvp(Charging.SERVICE_INFORMATION, ...);
  ACA aca = acr.sendAndWait(1000);
  if (!aca.getResultCode().isSuccess()) {
    ... send error response ...
  }

便宜上、例11-10のように、RfApplicationを直接使用してイベント・ベース・チャージング・リクエストを送信することもできます。

例11-10 RfApplicationを使用したイベント・ベース・チャージング

  ACR acr = rfApp.createEventACR();
  acr.addAvp(Charging.SERVICE_INFORMATION, ...);
  ACA aca = acr.sendAndWait(1000);

RfApplicationは、内部的にACRリクエストに関連するRfSessionのインスタンスを作成します。そのため、このメソッドはセッションの明示的な作成と同等です。

セッション・ベースとイベント・ベース、どちらのアカウンティングの場合でも、RfSessionクラスは、セッションIDの作成および同一のアカウンティング・セッション内でのメッセージの並べ替えに使用されるAccounting-Record-Number AVPの更新を、自動で処理します。

上の例では、アプリケーションはCDFからの応答の受信を1000ミリ秒待ちます。その間に応答の受信がない場合は、Diameter中核機能からアプリケーションにUNABLE_TO_COMPLYエラー・レスポンスが配信され、リクエストが取り消されます。sendAndWait()を使ってタイムアウトを指定しない場合は、デフォルトのリクエスト・タイムアウト値である30秒が適用されます。このデフォルト値は、Diameterコンソール拡張を使用して構成できます。

11.4.4 アカウンティング・セッション状態の使用

オフライン・チャージングのアカウンティング・セッション状態はシリアライズ可能なので、SIPアプリケーション・セッション属性として格納できます。クライアントAPIは同期的であるため、いったんサーブレットが呼出し処理を終了したら、アカウンティング・セッションの状態を保持する必要はまったくありません。

イベント・ベースのチャージング・イベントでは、アカウンティング・セッション状態は内部的にのみ使用されるため、アプリケーションが保持する必要はありません。そのため、いったんACAレスポンスが受信された後は、アカウンティング・セッション状態は破棄されます。

  前
前 		 次
次
  目次へ移動
目次		 索引へ移動
索引