JP5851986B2

JP5851986B2 - Ｉｐマルチメディア・サブシステムにおいて使用するための方法及び装置

Info

Publication number: JP5851986B2
Application number: JP2012515364A
Authority: JP
Inventors: ヤンダール，
Original assignee: テレフオンアクチーボラゲットエルエムエリクソン（パブル）
Priority date: 2009-06-22
Filing date: 2009-06-22
Publication date: 2016-02-03
Anticipated expiration: 2029-06-22
Also published as: EP2446581A1; CA2764244A1; US9356788B2; US20120102211A1; JP2012531072A; CN102804685B; EP2446581B1; WO2010149203A1; CA2764244C; CN102804685A

Description

本発明は、ＩＰマルチメディア・サブシステムにおいて使用するための方法及び装置に関する。

ＩＰマルチメディア・サービスは、音声、ビデオ、メッセージング、データなどの動的な組み合わせを同一セッション中で提供する。基本アプリケーションの数及び組み合わせ可能なメディアの数の増加により、エンドユーザに提供されるサービスの数が増加し、個人間の通信エクスペリエンスが豊かになるであろう。これにより、所謂「組み合わせＩＰマルチメディア」サービスを含む、パーソナライズされた豊かな新世代のマルチメディア通信サービスがもたらされるであろう。

ＵＭＴＳ(Universal Mobile Telecommunications System)は、より高いデータレートと向上したサービスとを加入者に提供するように設計された、第３世代の無線システムである。ＵＭＴＳは、ＧＳＭ(Global System for Mobile Communications)の後継であり、ＧＳＭとＵＭＴＳとの間には汎用パケット無線サービス（ＧＰＲＳ）という重要な進化段階がある。ＧＰＲＳは、ＧＳＭコアネットワークにパケット交換を導入し、パケットデータネットワーク（ＰＤＮ）に対する直接のアクセスを可能にする。これにより、ＧＳＭコアネットワークを通じた、ＩＳＤＮの６４ｋｂｐｓの限界をはるかに超える高データレートのパケット交換伝送が可能になり、これは２Ｍｐｂｓに及ぶＵＭＴＳデータ伝送レートにとって必要なものである。ＵＭＴＳは、第３世代パートナーシップ・プロジェクト（３ＧＰＰ）によって標準化された。３ＧＰＰは、欧州電気通信標準化機構（ＥＴＳＩ）や電波産業会（ＡＲＩＢ）などの地域単位の標準化機構の集合体である。更なる詳細については、３ＧＰＰＴＳ２３．００２を参照されたい。

ＵＭＴＳアーキテクチャは、ＩＰマルチメディア・サブシステム（ＩＭＳ）として知られる、新しいＩＰマルチメディア・サービスと共に従来の電話をサポートするためのサブシステムを含む（３ＧＰＰＴＳ２２．２２８、ＴＳ２３．２２８、ＴＳ２４．２２９、ＴＳ２９．２２８、ＴＳ２９．２２９、ＴＳ２９．３２８、及びＴＳ２９．３２９のリリース５から７）。ＩＭＳは、標準化されたＩＭＳサービスイネーブラの使用を通じてエンドユーザの個人対個人の通信エクスペリエンスを豊かにするための、重要な特徴を提供する。ＩＭＳサービスイネーブラは、ＩＰベースのネットワークを介して、個人対コンテンツ（クライアント対サーバ）のサービスに加えて、新しい豊かな個人対個人（クライアント対クライアント）の通信サービスを促進する。ＩＭＳは、インターネットに加えてＰＳＴＮ／ＩＳＤＮ（公衆交換電話網／サービス総合デジタル網）の両方に接続可能である。

ＩＭＳは、ユーザ端末間（又はユーザ端末とアプリケーションサーバとの間）で呼又はセッションをセットアップして制御するために、セッション開始プロトコル（ＳＩＰ）を使用する。セッションのメディアコンポーネントを記述して交渉するために、ＳＩＰシグナリングによって搬送されるセッション記述プロトコル（ＳＤＰ）が使用される。ＳＩＰはユーザ対ユーザのプロトコルとして作成されたが、ＩＭＳは、オペレータ及びサービスプロバイダがサービスに対するユーザのアクセスを制御すると共にそれに応じてユーザに課金することを可能にする。３ＧＰＰは、ＩＭＳ内のコンポーネント間に加えてユーザ装置（ＵＥ）とＩＭＳとの間のシグナリングのためにＳＩＰを選択した。

ＵＭＴＳ通信ネットワーク及びそのようなネットワーク内の様々なコンポーネントの動作に関する具体的な詳細は、http://www.3gpp.orgから入手可能なＵＭＴＳの技術仕様に見出すことができる。ＵＭＴＳ内でのＳＩＰの使用に関する更なる詳細は、３ＧＰＰ技術仕様ＴＳ２４．２２８Ｖ５．８．０（２００４年３月）に見出すことができる。

添付図面の図１は、ＧＰＲＳ／ＰＳアクセスネットワークの場合にＩＭＳが移動体ネットワーク・アーキテクチャにどのように適合するかを概略的に示す（ＩＭＳは、もちろん、他のアクセスネットワーク上で動作することもできる）。呼セッション制御機能（ＣＳＣＦ）は、ＩＭＳ内でＳＩＰプロキシとして動作する。３ＧＰＰアーキテクチャは、３種類のＣＳＣＦを定義している。それは即ち、ＳＩＰ端末にとってのＩＭＳ内での最初のコンタクトポイントであるプロキシＣＳＣＦ（Ｐ−ＣＳＣＦ）、ユーザが加入しているサービスをユーザに対して提供するサービングＣＳＣＦ（Ｓ−ＣＳＣＦ）、及び、正しいＳ−ＣＳＣＦを特定してＳＩＰ端末からＰ−ＣＳＣＦ経由で受信した要求をそのＳ−ＣＳＣＦへ転送する役割を担うインテロゲーティングＣＳＣＦ（Ｉ−ＣＳＣＦ）である。

ユーザは、規定されたＳＩＰＲＥＧＩＳＴＥＲメソッドを使用してＩＭＳに登録する。登録プロセスの間は、Ｉ−ＣＳＣＦの責務は、Ｓ−ＣＳＣＦがまだ選択されていない場合にＳ−ＣＳＣＦを選択することである。Ｉ−ＣＳＣＦは、ホームネットワークのホーム加入者サーバ（ＨＳＳ）からＳ−ＣＳＣＦの要求される能力を受信し、受信した能力に基づいて適切なＳ−ＣＳＣＦを選択する。なお、Ｓ−ＣＳＣＦの割り当ては、ＩＭＳベースのサービスに対するユーザアクセスを制御する（そしてこれに課金する）ことに関する鍵となるものである。登録されたユーザが続いてセッション要求をＩＭＳへ送信すると、Ｐ−ＣＳＣＦは、登録プロセスの間にＳ−ＣＳＣＦから受信した情報に基づき、この要求を選択されたＳ−ＣＳＣＦへ転送することができる。

ＩＭＳサービスネットワーク内には、ＩＭＳサービス機能を実装するためにアプリケーションサーバ（ＡＳ）が提供される。アプリケーションサーバは、ＩＭＳシステム内のエンドユーザにサービスを提供するものであり、３ＧＰＰに規定されるＭｒインタフェースを介してエンドポイントとして接続することもできるし、３ＧＰＰに規定されるＩＳＣインタフェースを介してＳ−ＣＳＣＦによって「リンクイン」することもできる。

３ＧＰＰＴＳ３２．２４０及び３ＧＰＰＴＳ３２．２６０は、ＩＭＳの課金アーキテクチャ及び課金原理を規定しており、これにより、課金情報をいつ送信し、課金情報をいつ送信しないかを規定している。

何らかのサービス実行の文脈において、少なくとも１つの課金判定（又はトリガー）ポイントが存在しなければならず、その目的は、この特定のサービス又はセッションのために、勘定記録を生成すること（オフライン料金請求のため）、又は割当額／承認(quota/authorization)を要求すること（オンライン料金請求のため）である。オフライン料金請求は、後払い方式の料金請求スキームであり、これにより、ユーザによりサービスが消費された後で料金請求が実行される。例えば、ユーザは、前月からの請求対象項目を示す月毎の請求書を受け取るかもしれない。オンライン料金請求は、前払い方式の料金請求スキームであり、要求されたサービスに対するユーザアクセスを許可する前に、ネットワークエンティティが課金システムに問い合わせる（厳密に言えば、オンライン料金請求は後払いにも使用可能である。通常、これは前払いであるが、支出管理やサービス導入時の利用限度額設定などの役割を果たすためにも使用可能である）。

３ＧＰＰＴＳ３２．２６０及び３ＧＰＰＴＳ３２．２９９によれば、様々なＩＭＳノードが課金トリガー機能（ＣＴＦ）として働くことができる。特に、Ｓ−ＣＳＣＦ又はＡＳ（或いは、その両方）が、ほとんどのトラヒックイベント及び全てのサービス起動のためにＣＴＦとして働くことができる。課金トリガー機能は、サービス／イベントのための課金情報を生成し、その情報を課金制御システムへ送信するように構成される。そして、例えばユーザに対する料金請求時やオペレータ間の決済時に、この情報を利用することができる。

本願出願人は、現在規定されている状況に伴う以下の問題点を認識した。

上述の通り、多数の様々なＩＭＳノードが課金トリガー機能（ＣＴＦ）として働くことができるので、そして、そのような各ノードが各自の固有の機能を有するので、ＣＴＦが利用可能なデータは一般的にＣＴＦ毎に異なり、それゆえ、生成される課金情報もＣＴＦ毎に異なることになる。オペレータが使用する課金モデルによっては、サービス／イベントに関する正しい請求額設定(rating)を実行するためには、２以上のＣＴＦからの課金データを必要とする場合がある。

様々なＣＴＦからのデータを統合することは、時間及びリソースを要し、オフライン料金請求（Ｒｆインタフェース）の場合には可能であれば一般的には回避されるものである。リアルタイムでデータを統合することは、一般的には実行不可能であり、一般的にはオンラインデータ（Ｒｏインタフェース）の統合は排除される。

ユーザ課金のために同一又は類似の請求額決定が行われるものとすると、オンライン料金請求が使用されるかオフライン料金請求が使用されるかに関わらず、可能な限り統合が回避されるように課金モデルを構築すべきである。しかしながら、これは常に可能な訳ではなく、或いは、サービス及び料金体系の差別化の妨げとなるであろう。

本願出願人が上で特定し説明した問題に対処することが望ましい。

本発明の第１の態様によれば、ＩＰマルチメディア・サブシステム（ＩＭＳ）ノードにおいて使用する方法であって、前記ＩＭＳ内ではセッションを確立して管理するためにセッション制御プロトコルが使用され、前記方法は、前記ＩＭＳノードにおいて、前記ＩＭＳの課金制御システムにおいて課金目的で必要とされるノード固有の課金情報を搬送するセッション制御プロトコルメッセージを受信するステップと、前記受信したノード固有の課金情報、及び前記ＩＭＳノードに関する更なるノード固有の課金情報の両方を、前記受信したメッセージに応えて又はこれを転送するために送信されるセッション制御プロトコルメッセージの中に含めることで、複数の異なるノードに関するノード固有の課金情報を搬送するために少なくとも１つのセッション制御プロトコルメッセージが使用されるようにする、ステップと、を備え、前記更なるノード固有の課金情報は、続いて前記ＩＭＳノードが例えば削除又は更新のために当該情報又はその一部にアクセス可能なやり方で手配されることを特徴とする方法が提供される。

例えば、前記セッション制御プロトコルメッセージは、セッション開始プロトコルメッセージであってもよい。

前記方法は、前記ノード固有の課金情報を搬送するために、前記セッション制御プロトコルメッセージのプライベートヘッダ部を使用するステップを備えてもよい。前記プライベートヘッダは、P-Charging-Vectorヘッダであってもよい。（理解されるであろうこととして、前記ノード固有の課金情報は、P-Charging-Vectorヘッダ内にIMS Charging Identity値を生成したノード（のアドレスなど）を識別する情報を含まない。）

前記ノード固有の課金情報は、課金データを含み、更に、前記課金データの種類を示す情報と、前記ノードの名前又は識別子であって前記ノードに関連し前記ノードが受信するセッション制御プロトコルメッセージにより搬送される課金データを前記ノードが更新することを可能にするものと、前記課金データのバージョンを示す情報であって異なる課金情報を示すために異なるバージョンを示す情報が使用されるものと、のうちの少なくとも１つを含んでもよい。

本発明の第２の態様によれば、ＩＰマルチメディア・サブシステム（ＩＭＳ）ノードにおいて使用する装置であって、前記ＩＭＳ内ではセッションを確立して管理するためにセッション制御プロトコルが使用され、前記装置は、前記ＩＭＳの課金制御システムにおいて課金目的で必要とされるノード固有の課金情報を搬送するセッション制御プロトコルメッセージを受信する手段と、前記受信したノード固有の課金情報、及び前記ＩＭＳノードに関する更なるノード固有の課金情報の両方を、前記受信したメッセージに応えて又はこれを転送するために送信されるセッション制御プロトコルメッセージの中に含めることで、複数の異なるノードに関するノード固有の課金情報を搬送するために少なくとも１つのセッション制御プロトコルメッセージが使用されるようにする、手段と、を備え、前記更なるノード固有の課金情報は、続いて前記ＩＭＳノードが例えば削除又は更新のために当該情報又はその一部にアクセス可能なやり方で手配されることを特徴とする装置が提供される。

本発明の第３の態様によれば、本発明の第１の態様に従う方法を実行するように装置を制御するプログラム、又は、装置にロードされた場合にその装置を本発明の第２の態様に従う装置にするプログラムが提供される。前記プログラムは、搬送媒体上で搬送されてもよい。前記搬送媒体は、記憶媒体であってもよい。前記搬送媒体は、伝送媒体であってもよい。

本発明の第４の態様によれば、本発明の第３の態様に従うプログラムによってプログラムされた装置が提供される。

本発明の第５の態様によれば、本発明の第３の態様に従うプログラムを含んだ記憶媒体が提供される。

本発明の実施形態は、先行技術に関する上述した問題に対処するという技術的利点を提供する。技術的利点は、以下でより詳細に提示される。

図１は、先に論じたものであるが、３Ｇ移動体通信システムに対するＩＰマルチメディア・サブシステムの統合を概略的に示す。図２は、本発明の実施形態に従う動作を示すメッセージ交換図である。図３は、図２のＭＧＣＦのパーツを示す概略ブロック図である。図４は、図２のＣＳＣＦのパーツを示す概略ブロック図である。図５は、図２のＡＳのパーツを示す概略ブロック図である。図６は、図２のＩＢＣＦのパーツを示す概略ブロック図である。図７は、図２の課金制御システムのパーツを示す概略ブロック図である。図８は、本発明を実装するスキームの概略図である。

本発明の実施形態は、単一のＣＴＦが自身のサービスのためのみならず他のノードからのデータも含む課金データを生成することを可能にするために、ＩＭＳノード間で課金関連データを送信し処理するための、汎用メカニズムを提供することを目的としている。これにより、課金制御システムが課金データを統合する必要性を無くすか少なくとも減らすことができるであろう。

本発明の実施形態によれば、ＩＭＳシステム内の何らかのノードが、課金制御システムが行う課金決定に関係するデータを搬送するためにＳＩＰシグナリングを使用することができ、そのような各ノードは、自身の課金データをＳＩＰシグナリングに追加する。このデータのための可能なコンテナの１つは、プライベートヘッダであり、これは例えば、ＲＦＣ３４５５「Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3rd-Generation Partnership Project (3GPP)」に規定されるＰＣＶ(P-Charging-Vector)ヘッダであり、その用法及び拡張は３ＧＰＰＴＳ２４．２２９「IP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3」に規定されているが、他の方法によっても実現可能である。

この点に関して、また、背景として、P-Charging-Vectorヘッダは、ＲＦＣ３４５５において、複数のネットワークエンティティがアクセス及びサービスを提供するに際して関与するようになるという結果をもたらす分散アーキテクチャを３ＧＰＰが有しているという問題に対処するように規定されている。P-Charging-Vectorヘッダは、同一セッションに関係している様々なエンティティから生成された課金記録を相関させる方法として提供される。P-Charging-Vectorによって搬送される相関情報には、グローバルに一意の課金識別子であるＩＣＩＤ(IMS Charging Identity)値が含まれ、これは、課金記録の相関を可能にすることにより、続く料金請求を単純化する。ＩＣＩＤとは別に、P-Charging-Vectorヘッダは、ＩＣＩＤ値を生成したＳＩＰプロキシのアドレスと、ＩＯＩ(Inter Operator Identifier)とを含む。ＩＯＩ識別子は、発信元ネットワーク及び着信先ネットワークの両方を識別する。プロキシは、P-Charging-Vectorヘッダがまだ存在しない場合に、最初の要求又は最初の応答の中にP-Charging-Vectorヘッダを含めることができる。ＲＦＣ３４５５によれば、要求又は応答の中には、ヘッダのインスタンスが１つしか存在してはならない。P-Charging-Vectorヘッダを含まない要求をプロキシが受信すると、プロキシは、プロキシにおいて入手可能なパラメータと共にP-Charging-Vectorヘッダを挿入してもよい。

本発明の実施形態では、様々なＩＭＳノードにより、追加的なノード固有の課金データ（単なる相関情報ではなく）がＳＩＰ要求及びその応答（セッションに関連するものも関連しないものも）に追加される。ノードによって追加される追加的な（ノード固有の）課金データは、構造的な方法で追加可能であり、こうして、ノードが、必要であれば例えば同一セッション中で自身のデータを後で削除又は更新するために、ＳＩＰシグナリング中の自身のデータを発見することができる。追加的な課金データは、課金制御システムの更なるアクションを単純化するために、課金制御システムによっても識別可能である。このことは、例えばノード名、バージョン番号、データ名、及び値などを追加的な課金データの中に、又はこれに関連付けて含めることにより、実現可能である。

一般的な意味で、また、図８の概略図を参照して、ＩＭＳの課金制御システムＣにおいて課金の目的で必要とされるノード固有の課金情報を搬送するためにＳＩＰメッセージＭ（或いは、ＩＭＳ内でセッションを確立して管理するためのセッション制御プロトコルとしてＳＩＰが使用されていない場合は、他のそのようなセッション制御プロトコルメッセージ）を使用するものとして、本発明を実装する方法を見ることができる。図８はＩＭＳノードＡからＩＭＳノードＢへ送信されるＳＩＰメッセージＭを示しており、ＳＩＰメッセージＭはその後課金制御システムＣへと送信されるノード固有の課金情報を搬送しているが、ＳＩＰメッセージＭによって搬送されるノード固有の課金情報は、ノードＡ以外のノードに関係していてもよい。

本発明の実施形態の目的で、ＲＦＣ２２３４の通常の拡張バッカス・ナウア記法（ＡＢＮＳ）シンタックスを用いると、ＰＣＶヘッダの拡張が次のように見えるであろう。

additional-charging-info = (charging-info / generic-param)
charging-info = “charging-info” EQUAL node [SEMI host] SEMI version *(SEMI ims-charging-info) *(SEMI extension-param)
node = “P-CSCF” / “S-CSCF” / “I-CSCF” / “E-CSCF” / “MRFC” / “MGCF” / “AS” / “IBCF” / token
version = 1*DIGIT
ims-charging-info = data-type EQUAL gen-value
data-type = gen-value

Accounting-Request（Ｒｆ）又はCredit-Control-Request（Ｒｏ）を送信する際に、ＣＴＦは、専用の属性値ペア（ＡＶＰ）の中でこの追加的な課金データを送信することができる。このことは、ノード毎に１つのインスタンスを使用することにより実行可能である。即ち、或るノードによって追加される全てのデータは、全く同一のＡＶＰの中で送信される。これは例えば、*[Additional-Charging-Data]である。

追加的な課金データは、一般的に、ＩＭＳシステム内でのみ価値がある。これが意味することは、このデータは、ＩＭＳシステムから離れる際に削除されてもよく、また、ＩＭＳシステムに入る際に受信された場合は削除されてもよいということである。即ち、このデータは、３ＧＰＰＴＳ２４．２２９「IP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3」に従うP-Charging-Function-Addressesヘッダとよく似たように処理可能である。

課金制御へ報告される追加的な課金データの完全性は、ＩＭＳシステムの振る舞いに依存する。プロキシノードの標準的な振る舞いは、受信したものを転送することであるが、他の種類のノードはこれとは違う風に振舞うことができる。それらは例えば、未知のデータであることを理由にトランザクションを拒否してもよいし、データを破棄してもよいし、或いはデータをそのまま転送してもよい。追加的な課金データの処理を定義する必要がある。例えば、それが転送されるかどうか、エッジノードにおいてそれが要求から応答にコピーされるかどうか、或いは、ＣＴＦが課金制御システムへ全データを送信できるようにするために各ＣＴＦが受信したものをＳＩＰ要求及びＳＩＰ応答の両方の中に格納する必要があるかどうか、に関することである。

ここで、図２乃至図７を参照して、本発明を実装する方法及び装置に関するより詳細な説明を行う。図２は、ＰＳＴＮＵＥ１、メディアゲートウェイ制御機能（ＭＧＣＦ）２、ＣＳＣＦ３、ＡＳ４、ＩＢＣＦ(Interconnection Border Control Function)５、及び課金制御システム６というＩＭＳエンティティが関与するシグナリングシーケンスを示す。ＡＳ４は、ＵＥ１に提供されるサービスのためのＣＴＦとして働き、（ＣＴＦとして働く）ＡＳ４は、課金制御システム６と通信する。また、図２には、別のＳＩＰネットワークからのＵＥ７も示されている。

図３乃至図７は、ＭＧＣＦ２、ＣＳＣＦ３、ＡＳ４、ＩＢＣＦ５、及び課金制御システム６にそれぞれが関係する概略ブロック図である。ＭＧＣＦ２、ＣＳＣＦ３、ＡＳ４、及びＩＢＣＦ５の各々は、ＳＩＰメッセージ処理部１２を有する。ＭＧＣＦ２、ＡＳ４、ＩＢＣＦ５、及び課金制御システム６の各々は、追加的課金情報処理部１４を有する。ＡＳ４は、ＣＴＦ部１６を有する。ＩＢＣＦ５は、格納部１８を有する。

図２のシグナリング図を参照すると、ステップＳ１で、ＩＡＭ(Initial Address Message)がＵＥ１からＭＧＣＦ２へ送信される。ステップＳ３で、ＭＧＣＦ２のＳＩＰメッセージ処理部は、ＳＩＰＩＮＶＩＴＥを生成してＣＳＣＦ３へ送信する。しかしながら、ＳＩＰＩＮＶＩＴＥメッセージを送信することに先立ち、ステップＳ２で、ＭＧＣＦ２のＳＩＰメッセージ処理部１２は、ＭＧＣＦ２の追加的課金情報処理部１４と協力して、ＭＧＣＦ２に関する何らかの追加的課金情報をＳＩＰＩＮＶＩＴＥメッセージに挿入する。この追加的課金情報は、最終的には課金制御システム６によって必要とされるものであってここへ送信され、この例では、ＰＣＶヘッダを用いてＳＩＰＩＮＶＩＴＥメッセージに挿入されて搬送される。

ステップＳ３で送信されるＳＩＰＩＮＶＩＴＥメッセージは、ＣＳＣＦ３のＳＩＰメッセージ処理部１２によって受信され、これはステップＳ４で任意の追加的課金情報（この例では、ＭＧＣＦ２に関する追加的課金情報のみ）を含んだ状態でＡＳ４へ転送される。この例では、ＣＳＣＦ３自体が何らかの追加的課金情報を挿入する必要は無い。やはり明らかなこととして、ＣＳＣＦ３がＰＣＶヘッダの内容を何らかの形で処理する必要は無いし、ＰＣＶヘッダが課金情報を含むということを知る必要すら無い。ＣＳＣＦ３はステップＳ４でＰＣＶヘッダを分析せずに転送するだけである。

ステップＳ５で、ＡＳ４のＳＩＰメッセージ処理部１２は、ＰＣＶヘッダの中に任意の追加的課金情報を含んだ状態でＳＩＰＩＮＶＩＴＥメッセージをＣＳＣＦ３へ返送するが、ここでもまた、ＰＣＶヘッダが課金情報を含むということを知ることは実際に全く必要無い。ステップＳ６で、ＣＳＣＦ３のＳＩＰメッセージ処理部１２は、ここでもまた存在するかもしれない任意の追加的課金情報（この例では、ＭＧＣＦ２に関する追加的課金情報）を含んだ状態で、ＳＩＰＩＮＶＩＴＥメッセージをＩＢＣＦ５へ転送する。

ＩＢＣＦ５のＳＩＰメッセージ処理部１２は、ＩＢＣＦ５の追加的課金情報処理部１４と協力してＰＣＶヘッダの内容（即ち、追加的課金情報）を抽出し、その内容を格納部１８に格納すべく手配する。ＳＩＰＩＮＶＩＴＥメッセージは別のＳＩＰネットワークにいるＵＥ７へ転送されるので、追加的課金情報は格納部１８の中に置かれる。それゆえステップＳ８で、ＩＢＣＦ５はＳＩＰＩＮＶＩＴＥメッセージをＵＥ７へ転送し、そしてステップＳ９で、ＵＥ７はＳＩＰ２００ＯＫメッセージを用いて応答する。ＳＩＰ２００ＯＫメッセージは、ＩＢＣＦ５のＳＩＰメッセージ処理部１２によって受信され処理される。

ステップＳ１１で、ＳＩＰ２００ＯＫメッセージはＣＳＣＦ３へ転送されるが、転送前に、ステップＳ１０で、以前に格納されたＰＣＶヘッダの内容が格納部１８から取得され、ＩＢＣＦ５に特に関係する更なる課金情報（これはＩＢＣＦ５の追加的課金情報処理部１４によって作成される）と共にＳＩＰ２００ＯＫメッセージのＰＣＶヘッダに挿入される。

ステップＳ１２で、ＳＩＰ２００ＯＫメッセージは、ＣＳＣＦ３のＳＩＰメッセージ処理部１２によって、任意の追加的課金情報と共にＡＳ４へ転送される。この時点で、ＳＩＰメッセージはＭＧＣＦ２及びＩＢＣＦ５の両方に関する追加的課金情報を搬送している。

ステップＳ１３で、ＡＳ４の追加的課金情報処理部１４は、ＳＩＰ２００ＯＫメッセージによって搬送される追加的課金情報を抽出し、ＡＳ４のＣＴＦ部１６は、ＡＣＲ課金メッセージを生成して課金制御システム６へ送信する。ＡＣＲメッセージは、ＳＩＰメッセージによってＡＳ４へ搬送されたＭＧＣＦ固有の課金情報及びＩＢＣＦ固有の課金情報を含む。課金制御システム６は、この情報を課金の目的で使用する。

ステップＳ１４で、ＡＳ４のＳＩＰメッセージ処理部１２は、任意の追加的課金情報を含んだ状態でＳＩＰ２００ＯＫメッセージをＣＳＣＦ３へ転送する。ＣＳＣＦ３は次に、ステップＳ１５で、ここでもまた任意の追加的課金情報を含んだ状態でＳＩＰ２００ＯＫメッセージをＭＧＣＦ２へ転送する。

最後に、ＭＧＣＦ２は、ステップＳ１６で、ＡＣＭメッセージによりＵＥ１に応答する。

上述した課金モデルは、正しい請求額決定のために、発信元ネットワーク及び着信先ネットワークに関する情報を使用する。そしてそれゆえ、エッジノード２及び５の両方からのデータが使用される。本発明の実施形態に従うスキームが無いと、エッジノード２及び５の両方が課金データを課金制御システム６へ送信することを余儀なくされるであろうし、すると課金制御システム６は、正しい請求額を適用できるようにするために３つのソースからの課金データを相関させ統合することを余儀なくされるであろう。上述した本発明の実施形態では、エッジノード２及び５は追加的課金情報をＰＣＶヘッダの中に提供している。ＣＴＦが（要求及び応答からのデータを格納する必要無く）全てのデータを１箇所で見つけることができるようにするために、エッジノード２及び５は要求からのデータを応答にコピーし、バック・ツー・バック・ユーザエージェント（Ｂ２ＢＵＡ）として働くＡＳ４は、或るコールレグ(call leg)からのデータを別のコールレグにコピーする。

本発明の実施形態を使用すると、課金データを統合する必要性を減少させることが可能になり、ことによるとその必要性を取り除くことが可能になる。また、２以上のノードからのデータに基づいてリアルタイム（オンライン）で請求額決定を行うことも可能になる。特定の属性値ペア（ＡＶＰ）を利用することができなかったり作成することができなかったりする場合に柔軟なやり方でデータを課金制御システムへ送信するメカニズムが提供される。本発明の実施形態によれば、ＣＴＦは、自分が何を送信するのかを厳密に知る必要無しに、データを課金制御システムへ送信することができる。また、ノード固有の課金データを失わずに、様々なベンダからのノードを混合することも可能である。本発明の実施形態はまた、影響を受けるノードをできる限り少なくしつつ、市場適応や暫定処置(temporary solutions)も可能にする。本発明の実施形態は、例えノードが置き換えられたとしても、ＩＭＳ上で一貫した課金モデルを展開することを可能にする。統合の必要性を減少させることにより、主としてＲｆインタフェース上の課金トラヒックの量も減少させることができる。本発明の実施形態は、不要な課金情報の送信を回避することにより、課金トラヒックを全体レベルで減少させることを可能にする。更に、本発明の実施形態は、オンラインの課金モデル及びオフラインの課金モデルの両方に適用可能である。

理解されるであろうこととして、本発明を実装する方法が、課金情報を課金制御システムへ送信するための何らかの既存のメカニズム（例えば、Ｄｉａｍｅｔｅｒを使用すること）を完全に置き換えるように使用されることを、意図している訳ではない。むしろ、本発明を実装する方法は、何らかの既存の方法に加えて使用することができる。例えば、大量の課金データが送信されようとする場合に、既知のＤｉａｍｅｔｅｒインタフェースを使用する従来の方法でノードがこのデータを課金制御システムへ送信することがより適切であると考えられることもあるかもしれない。一方で、このことは、何らかの状況下で本発明を実装する方法が排他的に使用されることを妨げるものではない。

やはり理解されるであろうこととして、１以上の上述したコンポーネントの動作は、デバイス又は装置の上で動作するプログラムによって制御することができる。そのような動作プログラムは、コンピュータ可読媒体又はクラウドに格納されてもよいし、例えば、インターネットのウェブサイトから提供されるダウンロード可能なデータ信号のような信号の中に入れられてもよい。装置クレームは、動作プログラムそれ自体をカバーするものとして、又は、キャリア上のレコードとして、信号として、或いは他の任意の形式のものとして、解釈されるものである。

やはり当業者によって理解されるであろうこととして、添付の請求項によって規定される本発明の範囲から逸脱すること無しに、上述した実施形態に対して様々な修正を加えることができる。

Claims

ＩＰマルチメディア・サブシステム（ＩＭＳ）ノードにおいて使用する方法であって、前記ＩＭＳ内ではセッションを確立して管理するためにセッション制御プロトコルが使用され、前記方法は、前記ＩＭＳノードにおいて、
前記ＩＭＳの課金制御システムにおいて課金目的で必要とされるノード固有の課金情報を搬送するセッション制御プロトコルメッセージを受信するステップと、
前記受信したノード固有の課金情報、及び前記ＩＭＳノードに関する更なるノード固有の課金情報の両方を、前記受信したメッセージに応えて又はこれを転送するために送信されるセッション制御プロトコルメッセージの中に含めることで、複数の異なるノードに関するノード固有の課金情報を搬送するために少なくとも１つのセッション制御プロトコルメッセージが使用されるようにする、ステップと、
を備え、
前記更なるノード固有の課金情報は、続いて前記ＩＭＳノードが例えば削除又は更新のために当該情報又はその一部にアクセス可能なやり方で構成される
ことを特徴とする方法。
前記セッション制御プロトコルメッセージは、セッション開始プロトコルメッセージである
ことを特徴とする請求項１に記載の方法。
前記ノード固有の課金情報を搬送するために、前記セッション制御プロトコルメッセージのプライベートヘッダ部を使用するステップ
を備えることを特徴とする請求項１又は２に記載の方法。
前記プライベートヘッダは、P-Charging-Vectorヘッダである
ことを特徴とする請求項３に記載の方法。
前記ノード固有の課金情報は、課金データを含み、更に、前記課金データの種類を示す情報と、前記ノードの名前又は識別子であって前記ノードに関連し前記ノードが受信するセッション制御プロトコルメッセージにより搬送される課金データを前記ノードが更新することを可能にするものと、前記課金データのバージョンを示す情報であって異なる課金情報を示すために異なるバージョンを示す情報が使用されるものと、のうちの少なくとも１つを含む
ことを特徴とする請求項１乃至４のいずれか１項に記載の方法。
前記セッション制御プロトコルメッセージは、前記ＩＭＳ内のノード間で前記ノード固有の課金情報を搬送するために使用される
ことを特徴とする請求項１乃至５のいずれか１項に記載の方法。
前記ノード固有の課金情報は、単なる相関情報以外の情報を含む
ことを特徴とする請求項１乃至６のいずれか１項に記載の方法。
前記セッション制御プロトコルメッセージは、要求メッセージ及びその応答を含む
ことを特徴とする請求項１乃至７のいずれか１項に記載の方法。
前記セッション制御プロトコルメッセージは、セッションに関係するメッセージ及びセッションに関係しないメッセージの両方を含む
ことを特徴とする請求項１乃至８のいずれか１項に記載の方法。
ＩＰマルチメディア・サブシステム（ＩＭＳ）ノードにおいて使用する装置であって、前記ＩＭＳ内ではセッションを確立して管理するためにセッション制御プロトコルが使用され、前記装置は、
前記ＩＭＳの課金制御システムにおいて課金目的で必要とされるノード固有の課金情報を搬送するセッション制御プロトコルメッセージを受信する手段と、
前記受信したノード固有の課金情報、及び前記ＩＭＳノードに関する更なるノード固有の課金情報の両方を、前記受信したメッセージに応えて又はこれを転送するために送信されるセッション制御プロトコルメッセージの中に含めることで、複数の異なるノードに関するノード固有の課金情報を搬送するために少なくとも１つのセッション制御プロトコルメッセージが使用されるようにする、手段と、
を備え、
前記更なるノード固有の課金情報は、続いて前記ＩＭＳノードが例えば削除又は更新のために当該情報又はその一部にアクセス可能なやり方で構成される
ことを特徴とする装置。
請求項１乃至９のいずれか１項に記載の方法を実行するように装置を制御するプログラム。
請求項１１に記載のプログラムを記憶した記憶媒体。