Diameter アプリケーションの開発

オンライン チャージング用の Diameter Ro インタフェース アプリケーションの使用

以下の節では、アプリケーション開発時に Oracle Communications Converged Application Server の Diameter プロトコル実装に基づいて Diameter Rf インタフェース アプリケーションを使用する方法について説明します。

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

クレジット ベース チャージングとしても知られているオンライン チャージングは、プリペイド サービスの請求に使用されます。典型的なプリペイド サービスの例としては、音声またはビデオのために購入するテレホン カードがあります。Ro プロトコルを使用することで、チャージング トリガ機能 (CTF) からオンライン チャージング機能 (CDF) へチャージング イベントを発行することが可能になります。チャージング イベントは、即時、イベント ベース、セッション ベースのいずれかにすることができます。

Oracle Communications Converged Application Server は Diameter オンライン チャージング アプリケーションを提供します。デプロイ済みのアプリケーションは、このアプリケーションを利用して Ro プロトコルに基づくチャージング イベントを生成します。これにより、デプロイ済みのアプリケーションが、コンフィグレートされた OCF に対し CTF として機能することが可能になります。Diameter オンライン チャージング アプリケーションは、Rf と Sh の両方のアプリケーションをサポートする基本 Diameter プロトコルを使用します。

Diameter オンライン チャージング アプリケーションは、「IETF RFC 4006: Diameter クレジット管理アプリケーション」に基づいています。ただし、アプリケーションがサポートするのは、「3GPP TS 32.299: 通信管理、チャージング管理、Diameter チャージング アプリケーション」との整合性のために必要な RFC 4006 のサブセットのみです。具体的には、Oracle Communications Converged Application Server の Diameter オンライン チャージング アプリケーションはサービス固有の属性値ペア (AVP) を直接サポートすることはありませんが、提供される API が十分にフレキシブルなものであり、そのためにクレジット管理リクエストにカスタム サービス固有の AVP を含めることができます。

クレジット認証モデルについて

RFC 4006 は、以下のような 2 つの基本的なタイプのクレジット認証モデルを定義します。

ユニット予約方式でのクレジット認証では、イベント ベースまたはセッション ベースのいずれのチャージング イベントでも実行することができます。口座引き落とし方式でのクレジット認証では、即時チャージング イベントを使用します。どちらのモデルでも、CTF はエンド ユーザにサービスを配信する前に OCF からのクレジット認証を要求します。

以下の節では、各モデルについて詳しく説明します。

ユニット決定方式でのクレジット認証

RFC 4006は、ユニット予約方式でのイベント チャージング (ECUR) およびユニット予約方式でのセッション チャージング (SCUR) を定義します。これらのチャージング イベントは、どちらもセッション ベースであり、CTF と OCF 間における複数のトランザクションを必要とします。ECUR では、サービスを配信する前にまずユニット数を予約するための問い合わせを行い、その後、サービスの終了時点で実際に使用されたユニット数を OCF へ報告するための問い合わせを実行します。SCUR の場合には、CTF が 1 つまたは複数の中間問い合わせを行って実際にその時点で使用されているユニット数を報告し、必要に応じて追加のユニット数を予約することもできます。いずれの場合も、セッション状態は CTF および OCF の両方に保持されます。

ECUR と SCUR のどちらの場合も、オンライン チャージング クライアントは RFC 4006 に記載されている「CLIENT、SESSION BASED」状態マシンを実装します。

口座引き落とし方式でのクレジット認証

口座引き落としの場合は、即時イベント チャージング (IEC) が使用されます。IEC では、単一のトランザクションを作成し、クレジット認証の完了後に OCF が直ちにユーザの口座から一定の金額を引き落します。認証の受信後、CTF がサービスを配信します。このクレジット認証の形態は、1 回限りの (ワンタイム) イベントであり、セッション状態は保持されません。

IEC では、オンライン チャージング クライアントは、IETF RFC 4006 に記載されている「CLIENT、EVENT BASED」状態マシンを実装します。

ユニットの決定とレーティング

ユニットの決定は、サービスの配信に先立って割り当てることのできる、非貨幣的な単位ユニット数 (サービス ユニット、時間、イベントなど) の計算を参照します。ユニットのレーティングは、ユニット決定機能によって算出された非貨幣的なユニット数に基づいた価格決定を参照します。

ユニットの決定およびユニット レーティングは、OCF、CTF のいずれでも処理可能です。どちらで処理を行うかは、OCF に送信されるクレジット管理リクエスト内の AVP の選択を制御するクライアント アプリケーションによって決まります。

Ro アプリケーションのコンフィグレーション

RoApplication は、プロファイル データを管理するための Sh アプリケーションと似た Diameter アプリケーションとしてパッケージされています。Ro Diameter アプリケーションは、DOMAIN_ROOT/config/custom/diameter.xml に格納されている Diameter コンフィグレーション ファイルを編集するか、Diameter コンソール拡張を使用して、コンフィグレーションおよび有効化することができます。

アプリケーションの init パラメータである ocs.host が、OCF のホスト ID を指定します。この場合、OCF ホストは、グローバル Diameter コンフィグレーションの一部としてピア テーブル内にコンフィグレーションされている必要があります。もう 1 つの方法として、init パラメータ ocs.realm を使用して、レルム ベース ルーティングを使用する 1 つまたは複数の OCF ホストを指定することもできます。この場合、対応するレルム定義がグローバル Diameter コンフィグレーション内にも指定されている必要があります。

コード リスト 4-1 は、Ro を「myocs.oracle.com」という OCF ホスト名で有効化する diameter.xml から抜粋したサンプルです。

  <application>

    <application-id>4</application-id>

    <class-name>com.bea.wcp.diameter.charging.RoApplication</class-name>

    <param>

      <name>ocs.host</name>

      <value>myocs.oracle.com</value>

    </param>

  </application>

RoApplication は Diameter クレジット管理アプリケーションに基づいているため、Diameter アプリケーション ID は 4 になります。

オンライン チャージング API の概要

Oracle Communications Converged Application Server は、オンライン チャージング API を提供します。この API により、デプロイ済みの任意のアプリケーションが CTF として機能し、Ro プロトコルを介して OCS に対しオンライン チャージング イベントを発行することが可能になります。すべてのオンライン チャージング リクエストは、Diameter クレジット管理リクエスト (CCR) メッセージを使用します。使用されたチャージングのタイプは、CC-Request-Type AVP で示されます。チャージング API において、CC-Request-Type は com.bea.wcp.diameter.cc パッケージで、RequestType クラスによって表されます。表 4-1 は異なるクレジット認可モデルに関連付けられたリクエスト タイプを示します。

ECUR および SCUR では、サービスの配信前にユニットを予約し、サービスの完了時点でコミットします。ユニットの予約は INITIAL_REQUEST で行われ、TERMINATION_REQUEST でコミットされます。SCUR の場合には、UPDATE_REQUEST でユニットを更新することもできます。

基本 Diameter パッケージ com.bea.wcp.diameter には、Ro で使用される再認証リクエストをサポートするクラスが含まれています。com.bea.wcp.diameter.ccパッケージには Ro アプリケーションなど、クレジットコントロール アプリケーションをサポートするクラスが含まれています。com.bea.wcp.diameter.charging は Ro クレジット アプリケーションを直接サポートします。表 4-2 は、Ro クレジット コントロールのクラスの概略を表しています。

Ro アプリケーションのアクセス

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

private RoApplication roApp;

void init(ServletConfig conf) {

    ServletContext ctx = conf.getServletContext();

    Node node = (Node) ctx.getParameter("com.bea.wcp.diameter.Node");

    roApp = node.getApplication(Charging.RO_APPLICATION_ID);

  }

このコード例では、RoApplication をインスタンス変数としてサーブレットで使用できるようにします。RoApplication のインスタンスは、複数の同時スレッドで使用する場合に安全です。

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

RoApplication を使用して、セッション ベース クレジット認証のための新しいセッションを作成することができます。RoSession クラスは、クレジット管理タイプが ECUR (ユニット予約方式でのイベント ベース チャージング) か SCUR (ユニット予約方式でのセッション ベース チャージング) かに応じて、適切な状態マシンを実装します。また、RoSession クラスはシリアライズ可能なため、SIP セッション属性として格納することができます。このため、セッションを終了したり、クレジット認証を更新する必要がある場合に、セッションを復元することができます。

コード リスト 4-3 の例では、イベント ベース チャージングの新しい RoSession を作成し、CCR リクエストを送信して最初の問い合わせを開始します。サービスの終了後、後で終了できるように RoSession インスタンスを保存します。

RoSession クラスはセッション ID の作成を自動で処理することに注意してください。アプリケーションでセッション ID を設定する必要はありません。

RoSession session = roApp.createSession();

CCR ccr = session.createCCR(RequestType.INITIAL);

CCA cca = ccr.sendAndWait();

sipAppSession.setAttribute("RoSession", session);

...

再認証リクエスト メッセージの処理

OCS が再認証リクエスト (RAR) を CTF に発行して、クレジット再認証を開始させることがあります。このタイプのリクエストを処理するために、アプリケーションはセッション リスナを登録することができます。RAR を受信すると、Diameter サブシステムは RoSession オブジェクトに対応するアプリケーション上のセッション リスナを呼び出します。RFC 4006 の 5.5 節に記載されているように、アプリケーションは適切な RAA メッセージで OCS に応答し、値 UPDATE_REQUEST を設定した CC-Request-Type AVP とともに CCR を送信して CTF に対するクレジット再認証を開始させる必要があります。

セッション リスナは、SessionListener インタフェースを実装し、シリアライズ可能である必要があります。または、SipServlet のインスタンスである必要があります。サーブレットは以下のようにリスナを登録できます。

  RoSession session = roApp.createSession();

  session.addListener(new SessionListener() {

    public void rcvMessage(Message msg) {

      System.out.println("Got message: id = " msg.getSession().getId());

    }

  });

コード リスト 4-4 は、再認証リクエストを処理する rcvMessage() コードのサンプルを示しています。

  RoSession session = roApp.createSession();

  session.addListener(new SessionListener() {

  public void rcvMessage(Message msg) {

    if (req.getCommand() != Command.RE_AUTH_REQUEST) return;

    RoSession session = (RoSession) req.getSession();

    Answer ans = req.createAnswer();

    ans.setResultCode(ResultCode.LIMITED_SUCCESS); // Per RFC 4006 5.5

    ans.send();

    CCR ccr = session.createCCR(Ro.UPDATE_REQUEST);

    //   リクエストされたクレジット再認証に応じて CCR AVP を設定

    ccr.send();

    CCA cca = (CCA) ccr.waitForAnswer();

  }

コード リスト 4-4 では、再認証リクエストを受信すると、アプリケーションは結果コード DIAMETER_LIMITED_SUCCESS とともに RAA を送信し、OCS に対して処理を完了するには追加の CCR リクエストが必要であることを知らせます。その後 CCR が送信され、クレジット再認証が開始されます。

クレジット管理リクエスト メッセージの送信

CCR クラスは Diameter クレジット管理リクエスト メッセージを表し、クレジット管理リクエストを OCF に送信するために使用できます。ECUR (ユニット予約方式でのイベント ベース チャージング) と SCUR (ユニット予約方式でのセッション ベース チャージング) のどちらの場合でも、新しい CCR リクエストの作成には RoSession のインスタンスを使用します。RoApplication を直接使用して IEC に CCR メッセージを作成することもできます。コード リスト 4-5 は、CCR の作成と送信の方法を示しています。

  CCR ccr = session.createCCR(RequestType.INITIAL);

  ccr.setServiceContextId("sample_id");

  CCA cca = ccr.sendAndWait();

CCR リクエストを作成した後は、どのようなアプリケーション固有またはサービス固有の AVP も設定できます。これらの AVP は、addAvp() メソッドを使用してリクエストを送信する前に必要になります。セッションの各新規リクエストに同じ AVP をいくつか含める必要があるため、これらの AVP をセッション自体に設定することもできます。コード リスト 4-6 は、以下を設定するサンプルを示しています。

また、カスタム AVP を CCR リクエストに直接追加します。

  session.setSubscriptionId(...);

  session.setServiceIdentifier(...);

  CCR ccr = session.createCCR(RequestType.INITIAL);

  ccr.setRequestedServiceUnit(...);

  ccr.addAvp(CUSTOM_MESSAGE, "This is a test");

  ccr.send();

この例では、セッションの各新規リクエストに、同じ Subscription-Id と Service-Identifier を追加しています。また、送信前に、メッセージに対しカスタム AVP 「Custom-Message」を追加しています。

障害の処理

アプリケーションでは、OCF から送られる CCA エラー応答内の Result-Code AVP を調べることで障害の原因を検出し、適切な対処を行うことができます。使用不可のピアや無効なルート指定といったローカルで発生したエラーの場合は、リクエスト送信のメソッドが呼び出され、障害の内容を示す詳細メッセージとともに IOException が送出されます。

また、アプリケーションでは、Diameter タイマー Tx 値を使用して、どの時点で OCF がクレジット認証リクエストへの応答に失敗したかを突き止めることができます。タイマー Tx のデフォルト値は 10 秒ですが、RoApplication コンフィグレーション内の tx.timer init パラメータを使用してオーバーライドすることができます。タイマー Tx は、CCR が OCF に送信られた時点でスタートします。また、対応する CCA の受信後にタイマーはリセットされます。

対応する CCA の受信前に Tx が期限切れになった場合は、waitForAnswer への呼び出しが直ちに null を返し、リクエストがタイムアウトしたことを示します。そのため、アプリケーションは、リクエストの Credit-Control-Failure-Handling (CCFH) AVP の値に従って適切なアクションを取ることができます。詳細については、RFC 4006 のセクション 5.7 「Failure Procedures」を参照してください。

コード リスト 4-7 では、CCA の受信前にタイマー Tx が期限切れになった場合、クレジット管理セッションは終了します。その後に Diameter サブシステムが CCA を受信すると、セッションはもう存在しないためメッセージは無視されます。

  CCR ccr = session.createCCR(RequestType.INITIAL);

  ccr.setCreditControlFailureHandling(RequestType.TERMINATION);

  ccr.send();

  CCA cca = ccr.waitForAnswer();

  if (cca == null) {

    session.terminate();

  }