(57)【要約】【課題】発呼者が不成功であったセッションに対して課金されてしまうといった従来技術に係る課題を解決すること。【解決手段】本発明に係る通信方法は、発呼者と着呼者との間に少なくとも１つのエンティティを介してセッションを設定するように試みるステップと、前記着呼者、前記発呼者及び前記少なくとも１つのエンティティのうちの少なくとも１つから確認応答が受け取られた後に、セッションを設定する前記試みが失敗したかどうかを決定するステップと、前記発呼者及び前記着呼者のうちの少なくとも一方が前記セッションに対して課金されるのを防止するステップと、を含むことを特徴とする。【選択図】図２
2008289203.tif 000002
【特許請求の範囲】
【請求項１】
少なくとも１つのエンティティにおいてセッションの設定を確認する応答を受信する段階と、
前記受信する段階の後に、前記セッションの設定が失敗したかどうかを決定する段階と、
前記セッションの設定が失敗したと決定された場合に発呼者及び着呼者のうちの少なくとも一方が前記セッションに対して課金されることを防止する段階と、
を含むことを特徴とする方法。
【請求項２】
前記発呼者及び前記着呼者が、セッション開始プロトコルに従って動作するように構成される、請求項１に記載の方法。
【請求項３】
前記セッションの設定を確認する応答が２００ＯＫメッセージにより構成される、請求項２に記載の方法。
【請求項４】
前記少なくとも１つのエンティティが呼状態制御ファンクションエンティティである、請求項１から請求項３のいずれかに記載の方法。
【請求項５】
前記着呼者がサービング呼状態制御ファンクションに接続される、請求項４に記載の方法。
【請求項６】
前記決定する段階が時間を設定することを含み、
前記発呼者からの確認が受信されなかったと決定された場合に、前記セッションの設定が失敗したと決定される、請求項１から請求項５のいずれかに記載の方法。
【請求項７】
前記決定する段階は、前記エンティティのうちの少なくとも１つが、前記少なくとも１つのエンティティが失敗したことを決定する、ことを含む、請求項１から請求項６のいずれかに記載の方法。
【請求項８】
前記少なくとも１つのエンティティが失敗したと決定された場合にセッションの設定を終了する、ことを含む、請求項７に記載の方法。
【請求項９】
前記セッションの設定が、別の少なくとも１つのエンティティに送信されたＢＹＥメッセージにより終了させられる、請求項８に記載の方法。
【請求項１０】
前記セッションの設定が、前記発呼者に送信されたエラー応答により終了させられる、請求項８に記載の方法。
【請求項１１】
前記セッションの設定が失敗したと決定された場合にセッションの設定を終了する、ことを含む、請求項１から請求項１０のいずれかに記載の方法。
【請求項１２】
前記セッションの設定が少なくとも１つのＢＹＥメッセージにより終了させられる、請求項１１に記載の方法。
【請求項１３】
前記決定する段階が時間を設定することを含み、
次のうちの少なくとも一方が発生した場合、すなわち、
前記発呼者からの確認が前記時間内に受信されなかったと決定されること、及び、少なくとも１つのエンティティの失敗が決定されたこと、のうちの少なくとも一方が発生した場合に、前記セッションの設定が失敗したと決定される、請求項１から請求項１２のいずれかに記載の方法。
【請求項１４】
前記発呼者からの確認が受信されなかった場合には前記時間が経過したときに、又は、前記エンティティの失敗が決定されたときに、前記セッションの設定を終了する、ことを含む、請求項１３に記載の方法。
【請求項１５】
前記決定する段階が前記少なくとも１つのエンティティのうちの少なくとも１つにより実行される、請求項１から請求項１４のいずれかに記載の方法。
【請求項１６】
前記防止する段階が、課金エンティティにメッセージを送信することを含む、請求項１から請求項１５のいずれかに記載の方法。
【請求項１７】
前記メッセージが、前記セッションの設定の失敗の原因に関する情報を含む、請求項１６に記載の方法。
【請求項１８】
前記防止する段階が課金情報をキャンセルさせる、請求項１から請求項１７に記載の方法。
【請求項１９】
前記防止する段階が課金情報を課金目的に関して無視させる、請求項１から請求項１８に記載の方法。
【請求項２０】
少なくとも１つのエンティティが課金の役目を果たす、請求項１から請求項１９のいずれかに記載の方法。
【請求項２１】
セッションの設定を確認する応答を受信するように構成された受信器と、
前記セッションの設定を確認する応答が受信された後、前記セッションの設定が失敗した場合に発呼者及び着呼者のうちの少なくとも一方が該セッションに対して課金されることを防止するように構成されたプロセッサと、
を具備することを特徴とする装置。
【請求項２２】
前記セッションの設定を確認する応答が前記着呼者から受信される、請求項２１に記載の装置。
【請求項２３】
前記発呼者及び前記着呼者のうちの少なくとも一方が課金されることを防止するために課金エンティティにメッセージを送信するように構成された送信器をさらに具備する、請求項２１又は請求項２２に記載の装置。
【請求項２４】
前記メッセージがセッションの設定が失敗したという指示を含む、請求項２３に記載の装置。
【請求項２５】
前記メッセージがセッションの設定の失敗の原因に関する指示を含む、請求項２３又は請求項２４に記載の装置。
【請求項２６】
セッション開始プロトコルを用いるように構成された、請求項２１から請求項２５のいずれかに記載の装置。
【請求項２７】
前記セッションの設定を確認する応答が２００ＯＫメッセージである、請求項２６に記載の装置。
【請求項２８】
呼状態制御ファンクションを含む、請求項２１から請求項２７のいずれかに記載の装置。
【請求項２９】
エンティティにおいてセッションの招待を確認するメッセージを受信する段階と、
前記受信の後に、前記セッションの設定が失敗したかどうかを決定する段階と、
前記セッションの設定が失敗したと決定された場合に、発呼者及び着呼者のうちの少なくとも一方が該セッションに対して課金されることを防止する段階と、
を含むことを特徴とする方法。
【請求項３０】
前記防止する段階が、前記発呼者及び前記着呼者のうちの少なくとも一方が前記セッションに対して課金されるべきでないということを示す更なるメッセージを送信することを含む、請求項２９に記載の方法。
【請求項３１】
前記更なるメッセージを送信することが、課金エンティティにメッセージを送信することを含む、請求項３０に記載の方法。
【請求項３２】
前記セッションの設定が失敗したかどうかを決定する段階が、確認メッセージが所定の時間内に受信されたかどうかを決定することを含む、請求項２９から請求項３１のいずれかに記載の方法。
【請求項３３】
前記セッションの設定が失敗したかどうかを決定する段階が、セッションの設定が失敗したことを示すメッセージを受信することを含む、請求項２９から請求項３１のいずれかに記載の方法。
【請求項３４】
セッションの招待を確認するメッセージを受信するように構成された受信器と、
前記セッションの設定が失敗したかどうかを決定するように構成され、前記セッションが失敗したと決定された場合に発呼者及び着呼者のうちの少なくとも一方が前記セッションに対して課金されることを防止するように構成された、プロセッサと、
を含むことを特徴とする装置。
【請求項３５】
呼状態制御ファンクションを含む、請求項３４に記載の装置。
【請求項３６】
前記発呼者及び前記着呼者のうちの少なくとも一方が前記セッションに対して課金されるべきでないということを示す更なるメッセージを送信するように構成された送信器をさらに具備する、請求項３４又は請求項３５に記載の装置。
【請求項３７】
前記送信器が課金エンティティにメッセージを送信するように構成される、請求項３６に記載の装置。
【請求項３８】
前記プロセッサは、前記受信器が所定の時間内に確認メッセージを受信したかどうかに基づいて前記セッションの設定が失敗したことを決定するように構成される、請求項３４から請求項３７のいずれかに記載の装置。
【請求項３９】
前記プロセッサは、前記受信器がセッションの設定が失敗したということを示すメッセージを受信したがどうかに基づいて前記セッションの設定が失敗したがどうかを決定するように構成される、請求項３４から請求項３７のいずれかに記載の装置。
【請求項４０】
セッションに対する招待メッセージを確認する確認メッセージをエンティティにおいて受信する段階と、
前記セッションに対応する最初のアカウントメッセージを送信する段階と、
前記セッションの設定が失敗したかどうかを決定する段階と、
前記セッションの設定が失敗した場合に、発呼者及び着呼者のうちの少なくとも一方が前記セッションに対して課金されるべきでないということを示す２番目のアカウントメッセージを送信する段階と、
を含むことを特徴とする方法。
【請求項４１】
セッションに対する招待メッセージを確認する確認メッセージを受信するように構成された受信器と、
前記セッションに対応する最初のアカウントメッセージを送信するように構成された送信器と、
前記セッションの設定が失敗したかどうかを決定するように構成されたプロセッサと、
を具備し、
前記プロセッサが前記セッションの設定が失敗したと決定した場合に、前記送信器は、発呼者及び着呼者のうちの少なくとも一方が前記セッションに対して課金されるべきでないということを示す２番目のアカウントメッセージを送信するように構成される、ことを特徴とする装置。
【請求項４２】
セッションの設定を確認する応答を少なくとも１つのエンティティにおいて受信する段階と、
前記受信する段階の後に、前記セッションの設定が失敗したかどうかを決定する段階と、
前記セッションの設定が失敗したと決定された場合に、発呼者及び着呼者のうちの少なくとも一方が前記セッションに対して課金されることを防止する段階と、
を含む方法を備えたことを特徴とするコンピュータプログラム製品。
【請求項４３】
セッションの招待を確認する着呼者からのメッセージをエンティティにおいて受信する段階と、
前記受信する段階の後に、前記セッションの設定が失敗したかどうかを決定する段階と、
前記セッションの設定が失敗したと決定された場合に、発呼者及び着呼者のうちの少なくとも一方が前記セッションに対して課金されることを防止する段階と、
を含む方法を備えたことを特徴とするコンピュータプログラム製品。
【請求項４４】
セッションに対する招待メッセージを確認する着呼者からの確認メッセージをエンティティにおいて受信する段階と、
前記セッションに対応する最初のアカウントメッセージを送信する段階と、
前記セッションの設定が失敗したかどうかを決定する段階と、
前記セッションの設定が失敗した場合に、発呼者及び着呼者のうちの少なくとも一方が前記セッションに対して課金されるべきでないということを示す２番目のアカウントメッセージを送信する段階と、
を含む方法を備えたことを特徴とするコンピュータプログラム製品。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信方法に係り、特に、ＳＩＰメッセージを使用するＩＰマルチメディアネットワークにおける通信方法に係るが、これに限定されない。また、本発明は、通信システムにも係る。
【背景技術】
【０００２】
通信システムとは、システムに関連したユーザ装置及び／又は他のノードのような２つ以上のエンティティ間で通信を行えるようにするファシリティである。通信は、例えば、音声、データ、マルチメディア、等々の通信を含む。
【０００３】
ユーザ端末又は他のノードに対してワイヤレス通信を与える通信システムが知られている。ワイヤレスシステムの一例が、公衆地上移動ネットワーク（ＰＬＭＮ）である。ＰＬＭＮは、通常、ベーストランシーバステーション（ＢＴＳ）又は同様のアクセスエンティティが、それらエンティティ間のワイヤレスインターフェイスを経て移動ステーション（ＭＳ）のようなユーザ装置（ＵＥ）にサービスするようなセルラーシステムである。通信に必要とされる装置の動作は、１つ又は多数の制御エンティティにより制御することができる。種々の制御エンティティは、相互接続されてもよい。セルラーネットワークを他のネットワーク、例えば、別のセルラーシステム、又は公衆交換電話ネットワーク（ＰＳＴＮ）及び／又は他の通信ネットワーク、例えば、ＩＰ（インターネットプロトコル）及び／又は他のパケット交換データネットワークに接続するために、１つ以上のゲートウェイノードを設けることもできる。ユーザ装置と、通信ネットワークの要素との間の通信は、セッション開始プロトコル（ＳＩＰ）のような適当な通信プロトコルに基づいて行うことができる。
【０００４】
通信システムは、通常、システムの種々の要素が何を行うことが許され且つそれをどのように達成すべきかを規定する所定の規格又は仕様書に基づいて動作する。例えば、この規格又は仕様書は、ユーザ、より詳細にはユーザ装置又は端末に、回路交換サービス及び／又はパケット交換サービスが提供されるかどうか定義することができる。また、接続に使用しなければならない通信プロトコル及び／又は通信パラメータが定義されてもよい。換言すれば、システムによって通信を行えるようにするために、通信の基礎となる特定の１組の「ルール」を定義することが必要である。
【０００５】
通信システムは、通常、別々の機能を有する。システムのユーザにサービスを提供するのに加えて、通信システムは、ネットワーク管理及び構成のような機能も提供する。現在の第３世代（３Ｇ）マルチメディアネットワークアーキテクチャーでは、移動ユーザのための異なる通信サービスの提供を取り扱うために種々のサービスが利用される。これらサービスの１つは、例えば、第３世代パートナーシッププロジェクト３ＧＰＰ仕様書に定義されたいわゆるＩＰマルチメディアサービス（ＩＭＳ）である。他の機能の中でも、これらのサービスは、コール状態制御機能（ＣＳＣＦ）を与える。コール状態制御機能エンティティは、サービス側コール状態制御（Ｓ−ＣＳＣＦ）、プロキシーコール状態制御（Ｐ−ＣＳＣＦ）、及び質問側コール状態制御（Ｉ−ＣＳＣＦ）のような機能を与えることができる。また、制御機能は、ホーム加入者サーバ（ＨＳＳ）及び、種々のアプリケーションサーバのようなエンティティによって与えられてもよい。ＨＳＳは、通常、ユーザ（加入者）のプロフィールを永久的に記憶するためのものである。
【０００６】
通信システムからのサービスを要求できるようにするためには、ユーザは、Ｓ−ＣＳＣＦのようなサービス側制御エンティティにおいてシステムに登録される必要がある。ユーザは、通信システムのアクセスエンティティを経て登録されてもよい。サービス側制御エンティティに加えて、ユーザは、Ｐ−ＣＳＣＦのようなプロキシー制御エンティティに関連付けることも必要である。プロキシーエンティティは、ユーザがローミングするエリアに指定される。より一般的なケースとして、ユーザが任意の形式のアクセスネットワークを経てネットワークにアクセスするときには、アクセスネットワークが、例えば、帯域巾管理のために、そのネットワークの観点から、アクセスされたサービスを制御するためのプロキシー制御エンティティを割り当てると仮定することができる。
【０００７】
ここで使用する「セッション」という語は、ユーザが行う通信、例えばコール、データ（例えば、ウェブブラウジング）、又はマルチメディア通信、等々を指すことが明らかであろう。
【０００８】
ＳＰＩを使用するＩＭＮ（ＩＭネットワーク）では、被呼者に対してＳ−ＣＳＣＦにより２００ＯＫメッセージが処理されるときに課金がスタートする。しかしながら、これは次のような問題を有する。２００ＯＫメッセージは、発呼者によって受信されないことがある。これは、例えば、次のホップのＣＳＣＦがフェイルしたり、発呼者のユーザ装置がカバレージから出たり、等々のためである。このようなケースでは、セッションの設定が失敗となり、課金されてはならない。しかしながら、現在の規格化の提案では、これを問題として認めておらず、実際に、現在の提案では、発呼者が、不成功であったセッションに対して課金されてしまう。
【０００９】
より詳細には、現在の規格化の提案は、２００ＯＫメッセージが被呼者のＳ−ＣＳＣＦにより処理されるときに、課金記録が作成される（即ち、課金が行われる）として定義している。セッションの設定が失敗した場合には、課金情報をキャンセルするメカニズムがない。
【発明の開示】
【発明が解決しようとする課題】
【００１０】
上述した問題は、第３世代（３Ｇ）通信システムにおけるＩＭＳに関連したものであるが、他のシステムにも同様の欠点が関連しており、したがって、前記説明はこれらの例に限定されないことが明らかであろう。
【００１１】
本発明の実施形態の目的は、上述した問題の１つ以上に対処することである。
【課題を解決するための手段】
【００１２】
本発明の１つの態様によれば、発呼者と被呼者との間に少なくとも１つのエンティティを経てセッションを設定するように試みるステップと、前記被呼者、前記発呼者及び前記少なくとも１つのエンティティの少なくとも１つから確認応答が受け取られた後に、セッションを設定する前記試みが失敗したかどうか決定するステップと、前記発呼者及び前記被呼者の少なくとも一方が前記セッションに対して課金されるのを防止するステップとを備えた通信方法が提供される。
【００１３】
本発明の第２の態様によれば、発呼者と、被呼者と、前記発呼者と前記被呼者との間の少なくとも１つのエンティティとを備え、この少なくとも１つのエンティティは課金の役割を果たすもので、且つ確認応答が受け取られた後、発呼者と被呼者との間にセッションを設定する試みが失敗した場合に、発呼者と被呼者との少なくとも一方が前記セッションに対して課金されるのを防止するように構成された通信システムが提供される。
【００１４】
本発明の第３の態様によれば、発呼者及び被呼者を備えた通信システムに使用するためのエンティティにおいて、このエンティティは、前記発呼者と被呼者との間に配置され、且つ前記エンティティは、確認応答が受け取られた後に、発呼者と被呼者との間にセッションを設定する試みが失敗した場合に、発呼者と被呼者との少なくとも一方が前記セッションに対して課金されるのを防止するように構成されたエンティティが提供される。
【００１５】
本発明の第４の態様によれば、発呼者及び被呼者を備えた通信システムに使用するためのエンティティにおいて、このエンティティは、前記発呼者と被呼者との間に配置され、且つ前記エンティティは、課金を行う役割を果たすものであって、確認応答が受け取られた後に、発呼者と被呼者との間にセッションを設定する試みが失敗した場合に、発呼者と被呼者との少なくとも一方が前記セッションに対して課金されるのを防止するように構成されたエンティティが提供される。
【００１６】
本発明の実施形態は、ＳＩＰを使用するＩＭＳシステムにおいて、２００ＯＫメッセージがＳ−ＣＳＣＦで処理された後に生じるセッション失敗のケースを検出するように構成される。本発明の実施形態は、２００ＯＫメッセージがＳ−ＣＳＣＦで処理された後にセッションの失敗が生じたと決定された場合に課金情報に関して確実にアクションを取れるように構成される。本発明の好ましい実施形態において、２００ＯＫメッセージが処理された後にセッション設定が失敗したときに、セッションの開始者は課金されない。
【発明を実施するための最良の形態】
【００１７】
本発明、及び本発明をいかに実施するかを良く理解するために、添付図面を参照して本発明を以下に詳細に説明する。
３Ｇパートナーシッププロジェクト（３ＧＰＰ）は、ユーザ装置ＵＥのユーザにこれらサービスへのアクセスを与える「ユニバーサル移動テレコミュニケーションシステム（ＵＭＴＳ）」コアネットワークのための基準アーキテクチャーを定義する。このＵＭＴＳコアネットワークは、３つの主たるドメインに分割される。それらは、回路交換ドメインと、パケット交換ドメインと、インターネットプロトコルマルチメディア（ＩＭ）ドメインとである。これらの後者、即ちＩＭドメインは、マルチメディアサービスが充分に管理されるよう確保する。ＩＭドメインは、インターネットエンジニアリングタスクフォース（ＩＥＴＦ）によって開発されたセッションイニシエーションプロトコル（ＳＩＰ）をサポートする。
【００１８】
現在の第3世代（３Ｇ）マルチメディアネットワークアーキテクチャーでは、セッションに関連した異なる機能を取り扱うために種々のサービスが利用されると仮定する。アクセスの独立性を達成すると共に、インターネットにわたりワイヤレス端末との滑らかな相互作用を維持するために、ＩＥＴＦ（インターネットエンジニアリングタスクフォース）となるべく規定されたインターネット規格に適合するための試みとして、３Ｇシステムインターネットプロトコル（ＩＰ）マルチメディアサブシステム（ＩＭＳ）が開発された。それ故、指定のインターフェイスは、ＩＥＴＦプロトコル、例えば、セッションイニシエーションプロトコル（ＳＩＰ）が選択された場合に、ＩＥＴＦ規格にできるだけ合致する。
【００１９】
ＩＭＮは、移動ネットワークのオペレータが、インターネットアプリケーション、サービス及びプロトコルに基づき且つそれに対して構築された加入者マルチメディアサービスをオファーすることができるようにする。本発明の実施形態は、ユニバーサル移動テレコミュニケーションシステム（ＵＭＴＳ）３Ｇシステム及びセッションイニシエーションプロトコル（ＳＩＰ）に関連して説明する。
【００２０】
関心のある者は、３ＧＰＰ（第３世代パートナーシッププロジェクト）仕様書ＴＳ２３．２２８からＩＭＮの詳細な説明を得ることができる。
【００２１】
図１は、部分インターネットプロトコル（ＩＰ）マルチメディアネットワークアーキテクチャーを示す。移動ステーション（ＭＳ）１０は、移動電話又はラップトップコンピュータで、無線アクセスのための無線モデム又はファックスを有するものである。ＭＳという語は、ここでは、移動ユーザ装置（ＵＥ）の一例として使用される。これは、無線インターフェイス（Ｕm）を経てユニバーサル移動テレコミュニケーションシステム（ＵＭＴＳ）無線アクセスネットワーク（ＵＴＲＡＮ）１１と通信する。このＵＴＲＡＮは、ネットワークエレメントノードＢ８を備え、これは、メッセージを送信及び受信するための装置を構成し、更に、暗号化装置を含んでもよい。これは、良く知られたように、無線ネットワークコントローラー（ＲＮＣ）６と通信する。
【００２２】
ＲＮＣは、サービス側汎用パケット無線サービスＧＰＲＳサポートノード（ＳＧＳＮ）で構成されるコアネットワークノード１２へシグナリングするための無線チャンネルを設定する。このシグナリングは、Ｉuインターフェイスにわたって生じる。ＳＧＳＮは、ネットワークアクセスノードを構成し、移動管理機能を与える。ノード１２は、接続管理、移動管理及び認証アクティビティを実行することのできるスイッチングノードである。コアネットワークノード１２は、Ｇnインターフェイスを経てゲートウェイＧＰＲＳサポートノード（ＧＧＳＮ）１４に接続される。このＧＧＳＮは、Ｇiインターフェイスを経、インターネット及びインターネットサービスプロバイダー（ＩＳＰ）のようなＩＰパケットデータネットワークを経て、サービスエリア１６へのアクセスを与える。
【００２３】
コール状態制御ファンクション（ＣＳＣＦ）１８は、ＵＥがサービスエリア１６からＩＭＳサービスを得るところのセッションをサポートし且つ制御する。更に、ＣＳＣＦは、上述したように、プロキシー、質問及びサービングＣＳＣＦで構成される。ＣＳＣＦは、ユーザのサービスにより使用されるベアラを変更し、追加し、又は消去するための融通性を与える。他の機能の中でも、ＣＳＣＦ１８は、コールファンクションを制御し、したがって、コール設定、変更及び終了を実行すると共に、アドレスの取り扱いを実行する。ＣＳＣＦは、ＣXインターフェイスを経てホーム加入者サーバ（ＨＳＳ）２０にアクセスする。ＨＳＳは、特定のユーザに関するデータを含むマスターサーバである。これは、コールサービスをいかに実行すべきかを識別することのできる特定のユーザに関するデータ、認証及び許可情報を含む。ＨＳＳは、ローカル（訪問先）ネットワークによってサービスされるＵＥの位置からある距離にあるＵＥユーザのホームネットワークに配置される。ＨＳＳは、Ｇr及びＧcインターフェイスを経てＳＧＳＮ及びＧＧＳＮに各々接続される。
【００２４】
インターネットへのアクセスを与えると共に、ユーザに他のＩＭサービスを与えるために、インターネットにわたり電話サービスを提供する上で助けとなるプロトコルが開発された。セッションイニシエーションプロトコル（ＳＩＰ）は、１つ以上の当事者とのセッションの形成、変更及び終了を制御するために開発されたこのような１つのプロトコルである。コールセッションは、インターネット又は他のＩＰネットワーク電話コール、会議、又は他のマルチメディアアクティビティを含むことができる。
【００２５】
ＳＩＰは、ユーザセッションを開始し、変更し及び終了するためのアプリケーションレイヤーシグナリングプロトコルである。セッションとは、例えば、両方向電話コール又は多方向会議セッションでよい。これらセッションが確立されると、ユーザに、上述したサービスを提供することができる。ＳＩＰの基本的特徴の１つは、単一位置独立アドレスを経て被呼者に到達する能力を与えることにより、移動ＵＥを使用するユーザの個人的移動をプロトコルにより行えるようにすることである。
【００２６】
ＳＩＰのアドレッシングは、ユニフォームリソースロケーター（ＵＲＬ）を使用する独特のアドレスによりユーザを識別する一般的なインターネット規定に従う。２人のユーザ間のＳＩＰシグナリングは、一連の要求及び応答より成る。ＳＩＰトランザクションは、２つの当事者、即ち要求を送信するユーザエージェントクライアント（ＵＡＣ）と、その要求への返答で応答するユーザエージェントサーバ（ＵＡＳ）とを有する。クライアント及びサーバは、ＳＩＰユーザエージェントを構成する。これに加えて、ＳＩＰは、多数のコールに関連したシグナリングを取り扱うネットワーク装置であるＳＩＰネットワークサーバを備えている。
【００２７】
この技術で良く知られているように、ＳＩＰ招待は、通常、２つのメッセージを含む。これらより多くのメッセージがあってもよく、実際に、３ＧＰＰでは、より多くのメッセージが使用されることを理解されたい。簡単化のために、これについてはここでは説明しない。２つのメッセージは、発呼者により開始されるＩＮＶＩＴＥ（招待）と、被呼者からの２００ＯＫメッセージとである。この後者のメッセージは、通常、発呼者により確認され、その後、両当事者が、シグナリング中に送信及び受信されたパラメータに基づいて通信を行うことができる。発呼者及び被呼者の両方は、ＢＹＥメッセージを実行することによりセッションを終わらせることができる。確立されたセッションの間に、参加者が更に別のＩＮＶＩＴＥメッセージを発生するか、又は、他の何らかのＳＩＰメッセージを使用することにより、パラメータの新たなセットを選択することができる。
【００２８】
また、ＳＩＰは登録も行い、これにより、ユーザに到達し／コンタクトすることができる。ＳＩＰのクライアントは、ＲＥＧＩＳＴＥＲ（登録）メッセージを使用してそれら自身を通信システムに登録し、この要求は、ＳＩＰネットワークにおいて「レジストラー（Registrar）」と称されるＳＩＰサーバに向けられる。
【００２９】
ＳＩＰネットワークは、通信システムの他の要素に含まれるか又は個別の要素を構成するプロキシー及び他のサーバノードを含む。
以下の説明において、ＳＩＰメッセージは、大文字で書かれる。
【００３０】
発呼者１００と被呼者１０２との間の第１シグナリング筋書きを示す図２について説明する。図２には、発呼者と、被呼者と、２つのＣＳＣＦエンティティとが示されている。実際には、発呼者と被呼者との間に他のエンティティがあってもよいが、明瞭化のためにこれらを省略する。
【００３１】
ステップＳ１において、発呼者１００は、ＩＮＶＩＴＥメッセージを第１のＣＳＣＦ１０４へ送信する。第１のＣＳＣＦ１０４は、このＩＮＶＩＴＥメッセージを、ステップＳ２において第２のＣＳＣＦ１０６へ送信する。ステップＳ３において、第２のＣＳＣＦ１０６は、このＩＮＶＩＴＥメッセージを被呼者１０２へ送信する。
【００３２】
ステップＳ４において、被呼者１０２は、２００ＯＫメッセージを第２のＣＳＣＦ１０６へ送信する。ステップＳ５において、第２のＣＳＣＦ１０６は、２００ＯＫメッセージを第１のＣＳＣＦ１０４へ送信するように構成される。ステップＳ６において、第２のＣＳＣＦは、タイマーをセットする。第２のＣＳＣＦ１０６は、このタイマーによりセットされた時間Ｈ内にある条件が満足されたかどうか決定するように構成される。この実施形態では、この条件は、被呼者からのＡＣＫメッセージの受信である。
【００３３】
首尾良いセッション設定における次のステップは、ステップＳ７であり、ここでは、２００ＯＫメッセージが第１のＣＳＣＦ１０４から発呼者へ送信されねばならない。しかしながら、この場合、第１のＣＳＣＦ及び発呼者１００からの２００ＯＫメッセージが失われる。この信号は、例えば、エアインターフェイスにおいて失われることがある。
【００３４】
被呼者は、ＡＣＫメッセージを受信しないので、２００ＯＫを再送信する。ＡＣＫメッセージが被呼者１０２によって受信されない場合には、被呼者は、時間Ｈが経過した後にＢＹＥ要求を発生する。非ＡＣＫメッセージが第２のＣＳＣＦにより受信されるか、又はＡＣＫメッセージを受信しない状態で時間Ｈが経過したときには、セッションが成功しなかったとみなされる。したがって、ステップＳ８は、時間Ｈ内に発呼者１００からのＡＣＫ信号を待機する。時間Ｈ内にＡＣＫメッセージがない場合には、ステップＳ９が行われる。第２のＣＳＣＦ１０６は、課金情報に、セッションが成功しなかったという指示をマークし、この情報を課金ノード、例えば、ＣＣＦ（課金収集機能）へ送信する。この情報は、セッションがなぜ成功しなかったかという理由を含んでもよい。本発明のこの実施形態では、第２のＣＳＣＦは、課金情報が、課金ノードへ送られるまでバッファされる場所である。
【００３５】
発呼者１００と被呼者との間の第２のシグナリング筋書きを示す図３について説明する。前記の例と同様に、発呼者１００と被呼者１０２との間のシグナリングは、第１及び第２のＣＳＣＦ１０４及び１０６を各々経て発生するものとして示されている。前記の図と同様に、被呼者と発呼者との間の他のエンティティは、明瞭化のために省略されている。
【００３６】
ステップＳ'１、Ｓ'２、Ｓ'３、Ｓ'４、Ｓ'５及びＳ'６は、図２のステップＳ１、Ｓ２、Ｓ３、Ｓ４、Ｓ５及びＳ６と各々同じであり、したがって、これは、再度詳細に説明しない。
【００３７】
図３の例は、ＣＳＣＦの１つが２００ＯＫメッセージを処理する間に内部欠陥を経験する場合を示している。この例では、ステップＳ'７において、第１のＣＳＣＦ１０４にエラーが発生する。このような内部欠陥が第１のＣＳＣＦによって経験されると、再送信を待機するか、又は過酷な又は重大なエラーの場合に被呼者に向かってＢＹＥ要求を送信することによりセッション設定を終了するよう決定してもよい。これは、ステップＳ'７において、第２のＣＳＣＦ１０６へＢＹＥ要求を送信することを含む。また、第１のＣＳＣＦは、ステップＳ'９において、発呼者１００へ５ｘｘエラー応答を送信してもよい。これらの５ｘｘ応答は、サーバ自体にエラーが生じたときに与えられる欠陥応答である。これは、参考としてここに取り上げるＩＥＴＦ（インターネットエンジニアリングタスクフォース）仕様ＲＦＣ３２６１に定義されている。この解決策は、コール経路にある他のＣＳＣＦが、バッファされた課金情報をマークすると共に、タイマーＨが時間切れする前に、セッションに割り当てられているリソースをキャンセルする上で助けとなる。ステップＳ'１０では、第２のＣＳＣＦ１０６が、最終的なアカウント要求を、セッション失敗の原因に関する指示、即ちセッション設定においてＡＣＫメッセージが欠落しているという指示と共に課金ノードへ送信する。ステップＳ'１１では、第２のＣＳＣＦ１０６は、ステップＳ'１０の前又は後に被呼者１０２へＢＹＥ要求を送信するように構成される。
【００３８】
第１のＣＳＣＦが何も行わず、即ちＢＹＥ要求も５ｘｘエラーメッセージも送信せず、且つ２００ＯＫメッセージの再送信を待機する場合には、図２を参照して説明したのと同様の状態になる。
【００３９】
本発明の一実施形態では、時間Ｈの値は、６４Ｔ１に等しく、これは、現在の３ＧＰＰ規格では１２８秒に等しい。
【００４０】
第１のＣＳＣＦは、プロキシーＣＳＣＦでよく、第２のＣＳＣＦは、サービス側ＣＳＣＦでよい。
【００４１】
図２及び３に示す例では、エラーが発呼者に伴うものか、又は発呼者が通信するＣＳＣＦに伴うものであると仮定する。本発明の実施形態は、被呼者のユーザ装置又はそのサービス側ＣＳＣＦ、或いは実際には、発呼者と被呼者との間の経路にある何らかの要素に伴う問題がある場合にも等しく使用できることが明らかであろう。
【００４２】
したがって、本発明の実施形態は、次のステップを与えることができる。
１．Ｓ−ＣＳＣＦ（即ち、第２のＣＳＣＦ１０６）は、ＩＮＶＩＴＥメッセージに対応する２００ＯＫメッセージを処理するときに、初期アカウント要求をＣＣＦに送信する。これは、ステップＳ６及びＳ'６に対応する。ＣＣＦは、ＣＤＲ（課金データ記録）を条件に応じてオープンし、この条件は、発呼者からＡＣＫメッセージを受信することである。この２００ＯＫメッセージは、Ｐ−ＣＳＣＦ（Ｓ−ＣＳＣＦ後の次のホップで、例えば、第１のＣＳＣＦ１０４に対応する）が、２００ＯＫを処理するときに失敗となり、ユーザ装置がカバレージから外れ、等々の種々の理由で、発呼ユーザの装置に到達しないことがある。
２．ＡＣＫメッセージが時間Ｈ（ＲＦＣ３２６１で定義された）内に受信されない場合には、Ｓ−ＣＳＣＦは、セッションの設定を不成功であるとみなし、セッション試みの不成功を指示する最終的なアカウント要求をＣＣＦに送信しなければならない（図２のステップＳ９及び図３のステップＳ'１０に対応する）。
３．ＣＤＲはキャンセルされるか、又はセッション設定の不成功を指示するようにマークされる。厳密な振舞いをＣＣＦにおいて構成できねばならない。
４．２００ＯＫメッセージの処理がＣＳＣＦの１つにおいて失敗した場合には（例えば、内部処理の失敗のために）、そのＣＳＣＦは、２００ＯＫメッセージを発生したユーザ装置に向かってＢＹＥ要求を送信すると共に、２００ＯＫを待機しているユーザ装置に向かって５ｘｘエラー応答を送信しなければならない（これは、図３を参照して説明する）。この手順は、セッション設定の経路にある他のプロキシーが、セッション設定が失敗したことを迅速に分かるようにし、したがって、セッション設定の不成功を指示する最終的なアカウント要求を送信する上で助けとなる（それらが初期アカウント要求を既に送信している場合）。このようにして、ＣＳＣＦは、ＣＤＲをキャンセルするためにタイマーＨの時間切れを待機する必要がない。
【００４３】
ＴＳ３２．２２５  Ｖ５．０．０、第３世代パートナーシッププロジェクト；技術仕様グループサービス及びシステムアスペクト；通信管理；課金管理について参照すれば、参考としてここに取り上げるＩＰマルチメディアサブシステム（ＩＭＳ）（リリース５）についての課金データの説明は、次のようなＡＣＲアカウント要求値、即ちスタート、中間及びストップをもつダイアメーター(Diameter)アカウント要求を指定する。オフライン課金機能は、種々のＳＩＰ方法又はＩＳＵＰメッセージを受信した際にアカウント情報をレポートするＩＭＳネットワークノードに基づいている。というのは、アカウント当該情報のほとんどがこれらのメッセージに含まれているからである。このレポートは、ＩＭＳノードからＣＣＦ（課金制御ファンクション）へダイアメーターアカウント要求（ＡＣＲ）「スタート、中間、ストップ及び事象」を送信することにより達成される。したがって、ダイアメータークライアントは、成功したＳＩＰセッションに関連した手順において、ＡＣＲスタート、中間及びストップを使用する。これは、不成功のＳＩＰセッション及びセッション非関連手順に対してＡＣＲ事象を使用する。ＣＤＲ（課金データ記録）は、提供されたサービスに対して加入者に課金する目的でネットワーク要素により発生された記録である。これは、ユーザ、セッション及びネットワーク要素を識別するフィールドと、加入者のセッションをサポートするのに使用されたネットワークリソース及びサービスについての情報とを含む。ＡＣＲ値は、既にスタートしているＣＤＲをキャンセル／マークするのに十分ではない。したがって、本発明の実施形態は、「原因ＡＶＰ」値、即ち最終アカウント要求（ＡＣＲストップ）がＩＭＳノードからＣＣＦへなぜ送られたかを指示する情報を与える。１つの「原因ＡＶＰ（属性値対）」は、上述したように「セッション設定不成功」である。現在ＡＣＲ値及びトリガーＳＩＰメッセージのテーブルを以下に示す。本発明の実施形態は、セッション設定が失敗したことを指示するために新たな原因ＡＶＰ値を与える。
【００４４】
【表１】
2008289203.tif 000003
【００４５】
本発明の好ましい実施形態では、サービス側ＣＳＣＦに２００ＯＫメッセージが受信されたために最初に設定された課金情報は、セッションの設定が不成功の場合にキャンセル／無視されるか又はマークされねばならない。後者のケースでは、課金情報を統計学的な目的で使用できるが、課金には使用できない。
【００４６】
また、本発明は、他の通信システム及びプロトコルにも適用できる。他のシステムは、例えば、公衆インターネット及びケーブルネットワークを含むが、これらに限定されない。他のＳＩＰ方法も通信に使用できる。本発明の実施形態では、確認応答が、２００ＯＫメッセージの形態であった。しかしながら、本発明の実施形態では、他の形式の確認メッセージを使用できることが明らかであろう。例えば、他の２ｘｘ応答を使用してもよいし、又は実際には他の適当な形態のメッセージを使用してもよい。
【００４７】
以上、移動ステーションのようなユーザ装置に関連して本発明の実施形態を説明したが、本発明は他の適当な形式のユーザにも適用できることが明らかである。コンピュータ（固定又はポータブル）、移動電話、パーソナルデータアシスタント又はオーガナイザ、等々の種々のユーザ装置（ＵＥ）も当業者に知られており、これらを使用して、インターネットにアクセスして、サービスを得たりセッションを確立したりすることができる。
【図面の簡単な説明】
【００４８】
【図１】本発明を実施することのできるシステムを示す図である。
【図２】発呼者と被呼者との間の第１のシグナリング筋書きを示す図である。
【図３】発呼者と被呼者との間の第２のシグナリング筋書きを示す図である。
【図１】
2008289203.tif 000004
【図２】
2008289203.tif 000005
【図３】
2008289203.tif 000006