JP2010063116A - 特にｕｍｔｓネットワークにおける課金識別子の分配 - Google Patents

Abstract

【課題】３ＧＰＰ移動通信網を含むＩＭＳネットワーク内において、同じＳＩＰセッションに関連し、異なるドメインで発生する課金イベントのための、同じコンポネントレベルで課金相関を可能にするために、アクセスネットワーク課金識別子が送られ、ネットワーク要素間に課金識別子を分配する。
【解決手段】ユーザ機器とノード間に少なくとも１つのエンティティを有する通信システムを用いて、ユーザ機器の通信セッションをサポートする方法において、ａ）少なくとも１つのエンティティを介して、ユーザ機器とノード間のセッションを確立し、ｂ）セッションを保留状態に置き、ｃ）保留状態にある間に、セッション用リソースを予約し、ｄ）セッションを再開し、課金情報を分配する。
【選択図】図２

Description

本発明は通信ネットワークにおける課金（charging）に関し、排他的ではないが、特に、第３世代（ユニバーサル移動体通信システム（ＵＭＴＳ））ネットワークに関する。

通信システム（communication system）は、ユーザ端末、及び／又は、ネットワークエンティティ、及び、他の通信システムに関連するノードのような、２つ以上のエンティティ間の通信を可能にする。その通信は、例えば、声、電子メール（e-mail）、テキストメッセージ、データ、マルチメディア等を含む。

通信は、固定回線、及び／又は、無線通信インタフェースによって提供される。無線通信システムの特徴は、それらが無線通信システムのユーザのための移動性を提供することである。無線通信を提供する通信システムの例は、公衆地上回線移動体ネットワーク（ＰＬＭＮ：public land mobile network）である。固定回線システムの例は、公衆交換電話ネットワーク（ＰＳＴＮ：public switched telephone network）である。

通信システムは、システムの様々な要素がなぜ許可されるか、かつ、どう達成されるべきかを設定する所与の標準又は仕様に従って典型的に作動する。例えば、標準又は仕様は、ユーザ、又は、より正確にはユーザ機器が、回路交換サーバ（circuit switched server）又はパケット交換サーバ又はそれらの両方が備わるかどうかを定義する。コネクション（connection）のために使用されるべき通信プロトコル、及び／又は、パラメータも典型的に定義される。例えば、ユーザ機器と通信ネットワークの構成要素間で実装されるべき通信方法は、典型的に、所与の通信プロトコルに基づいている。他の言葉で言うと、通信が基づく特定の「ルール」の組は、ユーザ機器が、通信システムを介して通信することを可能にするために定義される必要がある。

第３世代（３Ｇ）通信システムの導入は、モバイルユーザ機器（ＵＥ）以外の機器と同様に、モバイルユーザ機器を介したインターネット上のサービスアクセスの可能性を著しく増加させるだろう。

コンピュータ（固定式、又は、移動式）、携帯電話、携帯情報端末（Personal Data Assistant）又はパーソナルデータオーガナイザ等のような様々なユーザ機器（ＵＥ）は、当業者に良く知られており、サービスを獲得するためにインターネットアクセスのために使用される。移動局（ＭＳ）として参照されるモバイルユーザ機器は、移動体電気通信ネットワークの基地局や他の局と、無線インタフェースを介しての通信を可能にする手段として定義される。

上述及びここで使用される用語「サービス」は、ユーザが望み、獲得し、又は提供されるいかなるサービス又は商品をも広くカバーするように理解されるだろう。その用語は、さらに、無料サービスの提供をカバーするように理解されるだろう。排他的にではなく、特に、用語「サービス」は、インターネット・プロトコル・マルチメディアＩＭサービス、会議、電話、賭博、リッチコール（rich call）、出席（presence）、電子商取引、メッセージング、例えば、インスタント・メッセージングを含むと理解される。

第３世代パートナーシップ・プロジェクト（３ＧＰＰ）は、ユニバーサル移動体通信システム（ＵＭＴＳ）コアネットワークのための参考アーキテクチャを規定しており、そのコアネットワークは、ユーザ機器ＵＥのユーザにこれらのサービスへのアクセスを提供する。このＵＭＴＳコアネットワークは、３つの主要な領域に分けられる。それらは、回路交換（Circuit Switched）ドメイン、パケット交換（Packet Switched）ドメイン、及び、インターネット・プロトコル・マルチメディア（ＩＭ）ドメインである。

これらの後者である、ＩＭドメインは、マルチメディアサービスが十分に管理されていることを確かめる。ＩＭドメインは、インターネット・エンジニアリング・タスクフォース（ＩＥＴＦ）によって開発されたセッション開始プロトコル（ＳＩＰ）をサポートする。

ＳＩＰは、トランザクションを送受信することと同様に、ユーザセッションを開始し、変更し、そして、終了するためのアプリケーションレイヤのシグナリングプロトコルである。例えば、セッションは、２方向電話、又は、他方向会議セッション、又は、ユーザとアプリケーションサーバ（ＡＳ）間接続である。これらのセッションの確立は、ユーザに上述のサービスを提供することを可能にする。ＳＩＰの基礎的な特徴の１つは、そのプロトコルは、アドレスに依存しない単一の場所を介して、被呼側（called party）（そしてそれは、アプリケーションサーバＡＳであり得る）又は別のユーザ機器に届く機能を提供することによって、モバイルＵＥを用いたユーザの個人的な移動性を可能にする。

ＳＩＰベースの通信システムに接続するユーザは、標準ＳＩＰメッセージに基づく通信システムの様々なエンティティと通信する。ＳＩＰは、Ｇ ローゼンバーグ等によるインターネット・エンジニアリング・タスクフォース（ＩＥＴＦ）プロトコル仕様「ＳＩＰ：セッション開始プロトコル（Session Initiation Protocol）」ＲＦＣ ３２６１、２００１年７月において定義される。この図書は、参照することにより組み込まれる。

ＩＥＴＦ ＲＦＣ ３２６１、ＳＩＰ：Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ、２００２年６月

第３世代標準の１つのバージョンは、「ｒｅｌｅａｓｅ ５」又は「ｒｅｌ５」である。これは、数ある中でも、ボイスオーバーＩＰ（voice over IP）のような全てのＩＰサービスのための基礎としてのＳＩＰ技術を使うために開発されたＩＰマルチメディアコアネットワークサブシステムを紹介する。ＳＩＰ標準は、ＳＩＰユーザエージェントクライアント（ＵＡＣ）とＳＩＰユーザエージェントサーバ（ＵＡＣ）間のメディアセッションを確立するために使用されるランデブープロトコルである。セッションを開くために、ＳＩＰは、ＳＤＰ（セッション記述プロトコル）を使い、そして、ＳＤＰは、リアルタイムサービス及び非リアルタイムサービスの両方に使用されるアプリケーションに依存して様々なセッションを確立することが可能である。ＳＩＰは、異なるタイプのセッションを確立するために使用される柔軟性のあるプロトコルである。例えば、幾つかのセッションは、満足すべきある前提条件（precondition）を要求する。他のセッションは、信頼できる一時的な応答を与える。他のセッションは、予約されたリソースの確認を要求する。ＳＤＰ申出（offer）／回答（answer）交換の様々な数を有することも可能である。

同じＳＩＰセッションに関連し、かつ、同じＳＩＰセッションのために異なるドメイン（即ちアクセスネットワーク及びＩＭサブシステム（ＩＭＳ）ネットワーク）で発生するイベントを課金するためのメディアコンポネントレベルでの課金相関（charging correlation）を可能にするために、特定のメディアフロー（例えば、ＧＰＲＳ（一般パケット無線サービス（General Packet Radio Service））における、アクセスＧＰＲＳ課金識別子及びＧＧＳＮ（ゲートウェイＧＰＲＳサポートノード）アドレス）は、ＩＭＳネットワークの中に送られ、分配される必要がある。このアクセス課金識別子は、Ｐ−ＣＳＣＦ（ＰＤＦ）（それぞれ、プロキシコールセッション制御機能（Proxy Call Session Control Function）及びポリシー決定機能（Policy Decision Function））に、Ｇｏインタフェースに介して送られ、ＳＩＰ「ＵＰＤＡＴＥ」メッセージの中のＩＭＳに分配される。３ＧＰＰ標準、「ｒｅｌｅａｓｅ ６」又は「ｒｅｌ６」のために用意された次バージョンと共に、幾つかのセッションセットアップシナリオにとって、ＵＰＤＡＴＥメッセージが全く送られないということがあり得る。これは、ネットワークが、この情報を必要とするネットワーク構成要素間に、課金識別子を分配できないという問題に帰着する。

Ｒｅｌｅａｓｅ ５用の現状の提案書では、更新（ＵＰＤＡＴＥ）要求は、ユーザ機器から、Ｐ−ＣＳＣＦへ送られる。ユーザ機器が、アップリンクとダウンリンク方向の両方のためのサービス予約の品質を終了するとき、レスポンス（response）内に前提条件の確認が要求される。起呼側（calling party）は、更新（ＵＰＤＡＴＥ）要求を、案内（ＩＮＶＩＴＥ）要求により確立される伝送経路（signalling path）を介して終端最終ポイントに送る。更新（ＵＰＤＡＴＥ）要求は、成功して確立された双方向性ＰＤＰコンテクストのために、サービス双方向性モードの成功した品質についての情報をＳＤＰの中に含める。そのＳＤＰは、送信及び受信モード両方のためのサービスリソース予約の品質が、終端ポイント側から成功したことを示す。

例えば、リリース６のためのプロポーザルと共に、セッションは単一のＳＩＰ ＩＮＶＩＴＥ／２００ ＯＫトランザクションによって確立されることがあり得る、または、セッションセットアップに含まれない終端が前提条件を利用せず、又は、予約リソースの確認を要求しない。これらのケース全てにおいて、ＵＰＤＡＴＥメッセージは、送られず、従って、課金識別子の分散は起こりえない。

本発明の実施例の目的は、上述の問題を解決することである。

本発明の第１の実施形態によれば、ユーザ機器とそのユーザ機器がセッションを確立するために配置されるノード間に少なくとも１つのエンティティを有する通信システムを用いて、そのユーザ機器の通信セッションをサポートする方法において、
ａ）少なくとも１つのエンティティを介して、ユーザ機器とノード間のセッションを確立するステップと、
ｂ）セッションを保留状態に置くステップと、
ｃ）セッションが保留状態にある間に、そのセッション用のリソースを予約するステップと、
ｄ）セッションを再開し、及び、課金情報を分配するステップと、を有する方法が提供される。

本発明の第２の実施形態によれば、ユーザ機器とそのユーザ機器がセッションを確立するために配置されるノード間に少なくとも１つのエンティティを有する通信システムを用いて、そのユーザ機器の通信セッションをサポートする方法において、
ａ）ユーザ機器と少なくとも１つのエンティティを介した前記ノード間の既存のセッションを修正するステップと、
ｂ）セッションを保留状態に置くステップと、
ｃ）セッションが保留状態の間に、修正セッション用のリソースを予約するステップと、
ｄ）セッションを再開し、課金情報を分配するステップと、を有する方法が提供される。

本発明の別な実施形態によれば、ユーザ機器の通信セッションをサポートする通信システムにおいて、ユーザ機器とそのユーザ機器がセッションを確立するために配置されるノードとの間に少なくとも１つのエンティティを有し、かつ、ユーザ機器と少なくとも１つのエンティティを介した前記ノードとの間にセッションを確立するように配置され、そのノードの少なくとも１つとユーザ機器は、セッションを保留状態に置くように配置され、及び、セッションが保留状態の間にセッション用のリソースを予約するように配置され、及び、セッションを開始するように配置され、かつ、少なくとも１つのエンティティは、課金情報を分配するように配置される通信システムが提供される。

別な実施形態によれば、ユーザ機器の通信セッションをサポートする通信システムにおいて、ユーザ機器とユーザ機器がセッションを確立するように配置されるノードとの間に少なくとも１つのエンティティを有し、かつ、ユーザ機器と少なくとも１つのエンティティを介したノードとの間のセッションを修正するように配置され、ノードの少なくとも１つとユーザ機器は、セッションを保留状態に置くように配置され、及び、セッションが保留状態の間に修正セッション用のリソースを予約するように配置され、及び、セッションを再開するように配置され、かつ、少なくとも１つのエンティティは、課金情報を分配するように配置される通信システムが提供される。

本発明の実施例が実行される概念的システムを示す図である。 本発明の第１の実施例における信号フローを示す図である。 本発明の第２の実施例における信号フローを示す図である。

本発明のより良い理解のために、及び、同じものがどのように実行に移されるかに関して、関連する図について申し述べられる。

本明細書において、ＳＩＰメッセージは、大文字で示される。
本発明の実施例は、特に、端末器、即ち、ユーザ機器自身が通信目的のためにＳＩＰの使い方を決定するユーザ機器、を許可する３ＧＰＰのリリース６バージョンに適用可能である。本発明の実施例は、３ＧＰＰ標準の他バージョン又は実際には他のいかなる標準にも適用され得ることを十分に理解されるべきである。

本発明の実施例は、既存のＳＩＰ仕様で作動する機構を、前提条件無しで、又は、更新（ＵＰＤＡＴＥ）のみが既にセットアップしたセッションを修正するように使用されるシナリオで、課金相関機構の適切な作動を確実にするために定義するように取り決められる。他の言葉で言うと、更新（ＵＰＤＡＴＥ）要求が、ダイアログ（dialog）が確かめられる前のセッションセットアップ段階で使用されない場合（即ち、そのリクエストに対して受け取られる最終レスポンス）、本発明の実施例が使用される。

本発明の実施例が実施されるシステムを概念的に示す図１について述べる。本システムは、ユーザ機器２を備える。ユーザ機器２は、適切な形式を採ることができ、例えば、携帯電話、携帯情報端末（ＰＤＡ）、携帯用コンピュータ、ラップトップコンピュータ、固定コンピュータ、又は、他の適当な装置のような、移動又は固定エンティティになり得る。ユーザ機器２は、無線接続を介して第１無線アクセスネットワーク（ＲＡＮ）４ａとの通信のために配置される。この無線接続は、いかなる適当な周波数であってよく、例えば、ラジオ周波数のようなものである。

第１無線アクセスネットワーク４ａは、一般に、基地局エンティティ（ノードＢとして時々言及される）から成る。本明細書の目的のため、基地局という用語が使用され、いかなる適切なエンティティをもカバーすることを意味する。無線アクセスネットワーク４は、制御要素も有する。標準に依存して、制御要素は、ＵＭＴＳシステムのケースでは、無線ネットワークコントローラ（ＲＮＣ）として言及され、又は、ＧＳＭシステムのケースでは、基地局コントローラ（ＢＳＣ）として言及される。コントローラという用語は、いかなるそのような制御エンティティをカバーすることを意味する。幾つかの配置において、制御機能は、基地局機能から分かれて提供され、ただ１つの制御エンティティは、多くの基地局を制御する。本発明の他の実施例においては、各基地局は、制御機能部分を組み込んでも良い。

無線アクセスネットワークは、コアネットワーク６と通信するように配置される。図１で図解されるコアネットワーク６は、パケット交換コアネットワーク（Packet Switched Core Network）である。第１の無線アクセスネットワーク４は、ＧＲＰＳ（一般パケット無線サービス）の機能をサポートするノードＳＧＳＮ１０に接続される。ＳＧＳＮ１０は、パケット交換トランザクションを切り替えるために使用される。

ＳＧＳＮ１０は、第１及び第２ゲートウェイＧＰＲＳサポートノードＧＧＳＮ１２ａ及びｂに接続される。これらはコアネットワーク６が外部パケット交換ネットワークに接続されるポイントで切り替えられる。入ってくる、及び、出て行くパケット交換コネクションは、ＧＧＳＮを通り抜ける。図１に示される配置において、ＧＧＳＮｓ１２ａ及びｂは、ＩＭ（ＩＰマルチメディア）サブシステム１４に接続されるものとして示される。各ＧＧＳＮ１２は、Ｐ−ＣＳＣＦ １６ａとｂ（プロキシ・コール・セッション制御機能）それぞれに接続される。各Ｐ−ＣＳＣＦ １６ａとｂは、ＰＤＦ（ポリシー決定機能）を有する。ＰＤＦは、ＩＰマルチメディアサブシステムのサービスベースローカルポリシー（ＳＢＬＰ）アーキテクチャ部分である。ポリシー決定機能は、ＩＰベアラ（bearer）レイヤでのサービスベースのローカルポリシを実施するＩＰ機構を使う論理的なポリシー決定要素である。ＰＤＦは、ポリシールールを用いてＳＢＬＰに関する決定を行い、そして、ＩＰポリシー実施ポイント（ＰＥＰである）ＧＧＳＮに対してこれらの決定を通信する。図１に示される配置において、ＰＤＦ１８ａとｂは、各々、各Ｐ−ＣＳＣＦの論理的なエンティティであるものとして示される。しかし、本発明の代替実施例においては、ＰＤＦは、分割したエンティティになり、又は、他のいかなる適切なエンティティの中に組み込まれる。

Ｐ−ＣＳＣＦ１６ａとｂは、問合せ（interrogating）(Ｉ)−ＣＳＣＦ２２に接続される。Ｉ−ＣＳＣＦ２２は、エンドユーザのための実行（serving）−ＣＳＣＦ（Ｓ）２４、即ち、被呼側（called party）を決定するように配置される。

図１は、さらに、ＩＭネットワークの中のアプリケーションサーバＡＳ２３を示す。ＧＣＩＤは、本発明の幾つかの実施例においては、ＡＳに分配される。

さらに図１に、第３世代標準に従って作動し、例えば、ＳＩＰプロトコルを使用するユーザ３０が示される。ユーザ３０は、ユーザエージェントクライアントに、ＩＭサブシステム１４を介してサービスを獲得することを可能にするＳＩＰプロキシ３２に接続される。ＳＩＰプロキシ３２は、Ｓ−ＣＳＣＦ２４に接続される。ＳＩＰプロキシは、ＩＳＰコアの部分である。ユーザは、ＰＣ、ソフトフォン（softphone）等のようなユーザ機器になり得る。

本発明の実施例においては、コアネットワーク６と、ＩＭＳシステム１４は、ＣＧＦ（課金ゲートウェイ機能）４０に接続され、ＣＧＦは、課金収集機能を含む。ＣＣＦは、代替的に、分割したエンティティであっても良い。ＣＧＦ４０は、請求書作成システム（ＢＳ：billing system）４２に接続される。請求書作成システムは、オペレータのネットワークの一部である。同様にＣＧＦ、及び／又は、請求書作成システムは、（アクセス及びＩＭＳ）ネットワークで発生させられる共通課金識別子を使って、ユーザがどれくらい所与のセッションのために請求されるかを決定する課金情報を相互に関係付ける。本発明の代替実施例においては、他の如何なる適切な請求書作成機構が使用されることを、十分に考慮すべきである。

図１に、さらに、第２ＲＡＮ４ｂに接続される第２のユーザ機器２６が示される。これは、説明目的のためであり、かつ、実際には、各ＲＡＮは、相対的に多数のユーザ機器と通信するように配置されることを十分に考慮すべきである。

図１に、さらに、ＰＣ又は、他の適切なアクセス技術と一致した別のアクセスネットワーク４４を介した第２Ｐ−ＣＳＣＦ １８ｂに接続するように配置されるようなものが示される。

本発明の実施例では、２つの例で示される電話機であるＳＩＰユーザエージェントクライアントＵＡＣは、ユーザ機器２であり、かつ、ユーザ機器３０であろう。例で示される電話機であるＳＩＰユーザエージェントサーバＵＡＳは、ユーザ機器２６及びユーザ機器２である。例示目的で示され、かつ、いかなる端末及び機器が、被呼側（called party）及び起呼側（calling party）になってもいいことを十分に考慮すべきである。

本発明の実施例においては、ＧＣＩＤ（ＧＰＲＳ課金識別子）は、ＧＧＳＮからＰＤＦ機能に送られる。ＰＤＦ機能がＰ−ＣＳＣＦから分かれるならば、ＧＣＩＤは、Ｐ−ＣＳＣＦにも送られる。そのメッセージは、Ｇｏインタフェース、即ちＧＧＳＮとＰ−ＣＳＣＦ間のインタフェース上を、ＣＯＰＳ（コモンオープンポリシーサービス）メッセージを用いて送られる。ＣＯＰＳは、Ｇｏインタフェース用に使用されるプロトコルである。ＧＣＩＤは、ＳＩＰシグナリング（signalling）で、Ｓ−ＣＳＣＦのような他のＩＭＳ機能、アプリケーションサーバ、及び、Ｉ−ＣＳＣＦへ分配される。

ＧＣＩＤは、ＧＰＲＳ ＰＤＰコンテキスト（context）のために、ＧＧＳＮによって発生させられる。ＧＣＩＤとＰＤＰコンテキスト間の関係は１対１である。ＧＰＲＳはＩＭＳにアクセスするために使用される場合、ＧＣＩＤは、アクセス部分とＩＭＳ課金識別子であるＩＭＳ部分から構成される課金相関ベクトルのアクセス部分として、ＧＧＳＮアドレスと共に使用される。課金ベクトルは、この後より詳細に、述べられる。

本発明の実施例は、ＧＰＲＳ以外のアクセス技術に使用されることを十分に考慮すべきである。本発明の実施例は、ＰＤＦ機能やＧｏインタフェースが使用されるところ、即ち、ＳＢＬＰが少なくとも課金相関のために使用されるところで特に適応可能である。

端末、即ち、ユーザ機器が前提条件、又は、１００ ＲＥＬ（ＳＩＰ前提条件）を使用しないならば、その結果、ＧＣＩＤを分配することはできない。このシナリオでは、端末は、最初のＳＤＰ（セッション記述プロトコル）申出（Offer）／返答（Answer）交換中に、セッションを保留状態にする。セッション用にリソースを予約した後に、端末は、それから、Ｐ−ＣＳＣＦから他のＩＭＳ機能へＧＣＩＤを分配できるｒｅ−ＩＮＶＩＴＥでセッションを再開する。ＧＣＩＤは、この後より詳細に述べられるＰ−課金−ベクトル（P-charging-vector）に含められる。特に、Ｐ−ＣＳＣＦは、先に保留状態にされたメディアを再開させるｒｅ−ＩＮＶＩＴＥ要求におけるＰ−課金−ベクトルヘッダの中に、ＧＣＩＤ情報を加える。

代替において、端末がメディアコンポネントを加え、又は、先に使用されたコーデックを変更することによって、既存のセッションを修正する場合、ＩＭＳの中でＳ−ＣＳＣＦ又は他の機能にＧＣＩＤを運ぶ機会が無い。従って、このケース及び本発明の実施例において、いったんリソースがうまく予約されたら、端末は新しいメディアを保留状態に置き、そして、ｒｅ−ＩＮＶＩＴＥメッセージでメディアを再開させる。ｒｅ−ＩＮＶＩＴＥメッセージは、このようにして、ＩＭＳネットワークの中でＧＣＩＤを分配する。

本発明の実施例は、Ｇｏインタフェースが少なくとも課金相関のために実施される限り、使用されるいかなるアクセスネットワークとでもＩＭＳネットワーク内で使用される。

本発明の第１実施例の中で使用されるシグナリングを示す図２を参照する。図１で示されるものと同じ要素は、同じ参照番号を用いて参照される。幾つかの要素、例えば、実際に存在するＩ−ＣＳＣＦは、明確性のために省かれる。本発明のこの実施例は、起呼側（calling party）が第３世代ではない例を示す。

ステップＳ１では、ＵＡＣ又はユーザ機器３０は、ＩＮＶＩＴＥメッセージを非３ＧＰＰ ＳＩＰプロキシ３２に送る。ステップＳ２では、ＳＩＰプロキシ３２は、ＩＮＶＩＴＥメッセージをＳ−ＣＳＣＦ２４に送る。ステップＳ３では、Ｓ−ＣＳＣＦ２４は、ＩＮＶＩＴＥメッセージを第１のＰ−ＣＳＣＦ１６ａに送り、さらに詳細には、それらのＰＤＦ機能に送るために行う。ステップＳ４では、第１のＰ−ＣＳＣＦ１６ａは、ＩＮＶＩＴＥメッセージをユーザエージェントサーバ又はユーザ機器２に転送する。ステップＳ５では、ユーザエージェントサーバ２は、メディアストリームを非アクティブにする。

ステップＳ６では、ユーザエージェントサーバ２は、第１のＰ−ＣＳＣＦ１６ａに、２００ ＯＫ ｍｅｓｓａｇｅというメッセージを送り、そしてそれは、セッションが非アクティブ（inactive）であるＳＤＰを示す。ステップＳ７では、このメッセージは、第１のＰ−ＣＳＣＦ１６ａによって、Ｓ−ＣＳＣＦ２４に送られる。ステップＳ８では、そのメッセージは、Ｓ−ＣＳＣＦ２４によってＳＩＰプロキシ３２に送られる。ステップＳ９では、そのメッセージは、ＳＩＰプロキシ３２によって、ユーザエージェントクライアント３０に送られる。

ステップＳ１０では、ユーザエージェントクライアント３０は、ユーザエージェントクライアント３０がメッセージを受信した確認ＡＣＫを送る。この確認は、非アクティブセッションを示すＳＤＰを含める。これは、ＳＩＰプロキシ３２に送られる。ステップＳ１１では、ＳＩＰプロキシ３２は、そのメッセージをＳ−ＣＳＣＦ２４に転送する。ステップＳ１２では、このメッセージは、次に、Ｓ−ＣＳＣＦ２４により第１のＰ−ＣＳＣＦ１６ａに転送される。ステップＳ１３では、第１のＰ−ＣＳＣＦ１６ａによって転送されたメッセージは、ユーザエージェントサーバ２に転送される。ステップＳ１４では、最初のＧＧＳＮと連結したユーザエージェントサーバ２は、リソースを予約する。ステップＳ１５では、いったんリソースが予約されたら、メディアストリームは、ユーザエージェントサーバ２によってアクティブに設定される。ステップＳ１５は、ステップＳ１６と同時に行うことができる。ステップＳ１６では、Ｇｏインタフェース（Ｉ／Ｆ）を介してＧＧＳＮ １２ａとＰ−ＣＳＣＦ １６ａ間のインタラクション（interaction）かある。このステップでは、ＩＣＩＤ（ＩＭＳ課金識別子）とＧＣＩＤ情報が交換される。ＧＣＩＤがメディアコンポネントレベル相関のために使用される間に、ＩＣＩＤは、セッションレベル相関のために使用される。ＧＣＩＤは、セッション／メディアが同じＰＤＰコンテキスト（３ＧＰＰ Ｒｅｌ ５）で多重化されないと仮定する特定のメディアコンポネントに関連するアクセス課金情報を識別する。

ステップＳ１７では、ユーザエージェントサーバ２７は、ｒｅ−ＩＮＶＩＴＥメッセージをアクティブセッション（即ち、メディア属性は、ｓｅｎｄｒｅｃｖに設定される。ａ＝ｓｅｎｄｒｅｃｖは、セッションの中でアクティブである必要がある全てのメディア用）情報と共に送る。このメッセージは、第１のＰ−ＣＳＣＦ１６ａによって、Ｓ−ＣＳＣＦ２４に転送される。しかし、第１のＰ−ＣＳＣＦ１６ａは、さらに、Ｐ−課金−ベクトル（P-charging-vector）をＧＣＩＤ情報と共に含める。ステップＳ１９では、Ｓ−ＣＳＣＦ２４は、ＩＮＶＩＴＥメッセージを（Ｐ−課金−ベクトルと共に、又は、無しで）転送する。ステップＳ２０では、メッセージは、ＳＩＰプロキシ３２からＵＡＣ３０へ送られる。

本発明の第２の実施例を示す図３を参照する。これは、前提条件無しで、３ＧＰＰユーザエージェント間に確立されたセッション例のシグナルフローを説明する。ユーザ機器２である、第１の３ＧＰＰユーザエージェントクライアントがある。これは、最初のＧＧＳＮ１２ａと、ＰＤＦ機能と共に第１のＰ−ＣＳＣＦ１６ａに関係する。ユーザアプリケーションエージェントサーバ又はユーザ機器２６は、第２ＧＧＳＮ１２ｂと第２Ｐ−ＣＳＣＦ１６ｂに関係する。しかし、本発明の幾つかの実施例においては、１つ以上のＳ−ＣＳＣＦが提供され、実際は、明確性のために他のエンティティは、省略される。

ステップＴ１では、ユーザエージェントクライアント２は、メディアストリームを非アクティブ（inactive）に設定する。ステップＴ２では、ユーザエージェントクライアント２は、Ｐ−ＣＳＣＦ１６ａに対して非アクティブであるメディアストリームを示すＳＤＰと共にＩＮＶＩＴＥメッセージを送る。ステップＴ３では、第１のＰ−ＣＳＣＦ１６ａは、Ｓ−ＣＳＣＦ２４にメッセージを転送する。ステップＴ４では、Ｓ−ＣＳＣＦ２４は、第２のＰ−ＣＳＣＦ１６ｂにメッセージを転送し、次に、ステップＴ５で、ユーザエージェントサーバ２６にそのメッセージを転送する。

ステップＴ６では、ユーザエージェントサーバ２６は、２００ ＯＫ 確認（acknowledgement）を、第２Ｐ−ＣＳＣＦ１６ｂへの非アクティブセッションを示すＳＤＰと共に送る。ステップＴ７では、メッセージは、第２Ｐ−ＣＳＣＦ１６ｂによって、Ｓ−ＣＳＣＦ２４に転送され、それは、次に、ステップＴ８で、そのメッセージを第１Ｐ−ＣＳＣＦ１６ａに転送する。ステップＴ９で、第１Ｐ−ＣＳＣＦ１６ａは、ユーザエージェントクライアント２にそのメッセージを転送する。

ステップＴ１０では、ユーザエージェントクライアント２は、第１Ｐ−ＣＳＣＦ１６ａに、確認メッセージＡＣＫを送る。ステップＴ１１では、この確認（acknowledgement）は、第１Ｐ−ＣＳＣＦ１６ａによって、Ｓ−ＣＳＣＦ２４に転送され、そして、ステップＴ１２で、Ｓ−ＣＳＣＦ２４によって、第２Ｐ−ＣＳＣＦ１６ｂに転送される。ステップＴ１３では、確認は、第２Ｐ−ＣＳＣＦ１６ｂによって、ユーザエージェントサーバ２６に転送される。

ステップＴ１４では、リソース予約は、ユーザエージェントサーバ２６と第２ＧＧＳＮ１２ｂとの間で実行される。ステップＴ１６は、ステップＴ１４と同時に行われても良く、リソースは、ユーザエージェントクライアント２と第１ＧＧＳＮ１２ａとの間で予約される。ステップＴ１５では、ＩＣＩＤとＧＣＩＤを含むＧｏインタフェース上に第２ＧＧＳＮ１２ｂと第２Ｐ−ＣＳＣＦ１６ｂ間のインタラクションがある。これは、図２に関連して述べられる。ステップＴ１７は、ステップＴ１５に類似するが、第１ＧＧＳＮ１２ａと第１Ｐ−ＣＳＣＦ１６ａ間にある。ステップＴ１５とＴ１７は、同時に行われても良い。ステップＴ１８では、ユーザエージェントクライアント２は、メディアストリームをアクティブに設定する。

ステップＴ１９では、ユーザエージェントクライアント２は、それから、ＩＮＶＩＴＥメッセージをアクティブメディアストリーム（即ち、メディア属性は、ｓｅｎｄｒｅｃｖに設定される。ａ＝ｓｅｎｄｒｅｃｖは、セッションの中でアクティブである必要がある全てのメディア用）情報を示すＳＤＰと共に、第１Ｐ−ＣＳＣＦ１６ａに送る。

ステップＴ２０では、Ｐ−ＣＳＣＦ１６ａは、ＧＣＩＤを含むＰ−課金−ベクトルを加える。ステップＴ２１では、ＩＮＶＩＴＥメッセージは、Ｓ−ＣＳＣＦ２４によって、第２Ｐ−ＣＳＣＦ１６ｂに転送され、それは、次に、ステップＴ２２で、ユーザエージェントサーバ２６に転送される。ユーザエージェントサーバ２６は、確認メッセージ２００ ＯＫをａ＝ｓｅｎｒｅｃｖ情報を含めるＳＤＰと共に送る。ステップＴ２４では、第２Ｐ−ＣＳＣＦ１６ｂは、Ｐ−課金−ベクトル（P-charging-vector）に従ってメッセージをＧＣＩＤ情報と共にＳ−ＣＳＣＦ２４に送る。ステップＴ２５では、Ｓ−ＣＳＣＦ２４は、Ｐ−課金−ベクトル無しでメッセージを、第１Ｐ−ＣＳＣＦ１６ａに転送し、次に、ステップＴ２６で、ユーザエージェントクライアント２にそのメッセージを転送する。

第１実施例で示される配置への１つの代替的な修正において、最初のＩＮＶＩＴＥメッセージ（ステップＳ１からＳ４）は、ａ＝ｓｅｎｄｒｃｖと共にＳＤＰを、第２実施例のステップＴ１〜Ｔ５として、含める。同様に、ステップＳ１０〜Ｓ１３は、ＳＤＰ情報を含めない第２実施例のＴ１０〜Ｔ１３ステップで示されるものと同じ形式を有するシナリオで修正される。反対に、ステップＴ１〜Ｔ５は、ＩＮＶＩＴＥメッセージが第１実施例のＳ１〜Ｓ４ステップとしてＳＤＰ情報を含めないように修正される。同様に、ステップＴ１０〜Ｔ１３で送られる確認メッセージは、ＳＤＰメディアストリーム非アクティブ情報を有する。

以下の表は、Ｐ−課金−ベクトルをより詳細に示す。これは、３ＧＰＰ仕様、番号ＴＳ２４．２２９及びＴＳ２４．２２８で定義され、それは、言及によりここに組み込まれる。

Ｐ−課金−ベクトルヘッダフィールドは、ＩＥＴＦのＲＦＣ３４５５で説明されるフィールドを有し、ＲＦＣ３４５５は、言及によりここに組み込まれる。

アクセスネットワーク課金情報パラメータは、Ｐ−課金−ベクトルヘッダの現状の課金パラメータ要素からの一般的なパラメータの発生である。アクセスネットワーク課金情報パラメータは、異なるアクセスネットワーク用の代替定義を含める。この例では、ＧＰＲＳは、ＧＰＲＳ−課金−パラメータで示されるように、サポートされたアクセスネットワークである。本発明の他の実施例では、他のアクセスネットワークがサポートされる。ＧＰＲＳのために、追跡すべき次のようなコンポネントがある；ＧＧＳＮアドレス及び１以上のＰＤＰコンテキスト（ＰＤＰ−情報パラメータ）、関連するＧＰＲＳ課金識別子（ＧＣＩＤパラメータ）、メディア許可トークン（又は、トークンパラメータ）及び、ＳＩＰシグナリングからＳＤＰ内の関係するｍ−ラインを識別する１以上のフロー識別子（フロー−ｉｄパラメータ）。これらのパラメータは、ＧＧＳＮから、Ｐ−ＣＳＣＦ（ＰＤＦ）へＧｏインタフェース上を転送される。

本名発明の実施例は、オンライン課金又はオフライン課金に使用されることを考慮すべきである。

上述の記述が本発明の実施例を実証する一方、付け加えられた請求項で定義される本発明の範囲を離れることなく、開示された解決がなされる様々な変形及び修正があることをここに留意すべきである。

Claims (20)

1. ユーザ機器と該ユーザ機器がセッションを確立するために配置されるノード間に少なくとも１つのエンティティを有する通信システムを用いて、該ユーザ機器の通信セッションをサポートする方法において、
   ａ）前記少なくとも１つのエンティティを介して、前記ユーザ機器と前記ノード間のセッションを確立するステップと、
   ｂ）前記セッションを保留状態に置くステップと、
   ｃ）前記セッションが保留状態にある間に、前記セッション用のリソースを予約するステップと、
   ｄ）前記セッションを再開し、及び、課金情報を分配するステップと、を有する方法。
2. 前記課金情報が前記セッションの確立中に提供されるかどうかを決定し、そして、提供されない場合に限り、それから、前記ステップｂ）〜ｄ）が実行されることを決定するステップを有する請求項１に記載の方法。
3. ユーザ機器と該ユーザ機器がセッションを確立するために配置されるノード間に少なくとも１つのエンティティを有する通信システムを用いて、該ユーザ機器の通信セッションをサポートする方法において、
   ａ）前記ユーザ機器と前記少なくとも１つのエンティティを介した前記ノード間の既存のセッションを修正するステップと、
   ｂ）前記セッションを保留状態に置くステップと、
   ｃ）前記セッションが保留状態の間に、前記修正セッション用のリソースを予約するステップと、
   ｄ）前記セッションを再開し、課金情報を分配するステップと、を有する方法。
4. 課金情報が前記セッションの修正中に提供されるかどうかを決定し、そして、提供されない場合に限り、それから、前記ステップｂ）〜ｄ）が実行されることを決定するステップを有する請求項３に記載の方法。
5. ＳＩＰが前記セッション用に使用される請求項１〜４のいずれか一項に記載の方法。
6. 前記通信システムの少なくとも部分は、ＵＭＴＳ標準に従って作動する請求項１〜５のいずれか一項に記載の方法。
7. 前記課金情報は、課金識別子を有する請求項１〜６のいずれか一項に記載の方法。
8. 前記課金識別子は、ＧＣＩＤ及び／又はＩＣＤを有する請求項７に記載の方法。
9. 前記課金情報は、課金ベクトル内に与えられる請求項１〜８のいずれか一項に記載の方法。
10. 前記課金ベクトルは、Ｐ−課金−ベクトルである請求項９に記載の方法。
11. 前記少なくとも１つのエンティティは、ＧＧＳＮを有する請求項１〜１０のいずれか一項に記載の方法。
12. 前記少なくとも１つのエンティティは、Ｐ−ＣＳＣＦを有する請求項１〜１１のいずれか一項に記載の方法。
13. 前記少なくとも１つのエンティティは、ＰＤＦ機能を有する請求項１〜１２のいずれか一項に記載の方法。
14. 前記ＧＧＳＮから前記Ｐ−ＣＳＣＦ及び／又はＰＤＦへの前記課金情報を送るステップを有する請求項１１〜１３のいずれか一項に記載の方法。
15. 前記課金情報は、ＣＯＰＳメッセージ内で前記ＧＧＳＮから前記Ｐ−ＣＳＣＦ及び／又はＰＤＦへ送られる請求項１４に記載の方法。
16. 前記ノードは、ユーザエージェントサーバを有する請求項１〜１５のいずれか一項に記載の方法。
17. 前記課金情報は、ＩＮＶＩＴＥメッセージの中で送られる請求項１〜１６のいずれか一項に記載の方法。
18. 前記ノードは、ユーザ機器を有する請求項１〜１７のいずれか一項に記載の方法。
19. ユーザ機器の通信セッションをサポートする通信システムにおいて、
    前記ユーザ機器と前記ユーザ機器がセッションを確立するために配置されるノードとの間に少なくとも１つのエンティティを有し、かつ、前記ユーザ機器と前記少なくとも１つのエンティティを介した前記ノードとの間にセッションを確立するように配置され、
    前記ノードの少なくとも１つと前記ユーザ機器は、前記セッションを保留状態に置くように配置され、及び、前記セッションが保留状態の間に前記セッション用のリソースを予約するように配置され、及び、前記セッションを開始するように配置され、かつ、
    少なくとも１つのエンティティは、課金情報を分配するように配置される通信システム。
20. ユーザ機器の通信セッションをサポートする通信システムにおいて、
    前記ユーザ機器と前記ユーザ機器がセッションを確立するように配置されるノードとの間に少なくとも１つのエンティティを有し、かつ、前記ユーザ機器と前記少なくとも１つのエンティティを介した前記ノードとの間のセッションを修正するように配置され、
    前記ノードの少なくとも１つと前記ユーザ機器は、前記セッションを保留状態に置くように配置され、及び、前記セッションが保留状態の間に前記修正セッション用のリソースを予約するように配置され、及び、前記セッションを再開するように配置され、かつ、
    少なくとも１つのエンティティは、課金情報を分配するように配置される通信システム。

Images