JP2015524189A - Ｄｒｖｃｃ携帯端末のアクセス転送 - Google Patents

Abstract

ＤＲＶＣＣ携帯端末のアクセス転送パケット交換から回線交換方向における呼び出し段階のＩＰマルチメディアセッション（ＩＭＳ）のデュアル無線アクセス転送の方法である。本方法は、着信移動局（ＵＥ）に向けてＩＭＳメディアセッションを開始することと、セッションの呼び出し段階中に、ＵＥにおいて、パケット交換（ＰＳ）から回線交換（ＣＳ）アクセスへのＤＲＶＣＣ転送が必要であるとの判断を行うことを含む。本方法は、ＵＥからＰＳアクセスを介してサービス集中継続アプリケーションサーバ（ＳＣＣ−ＡＳ）へＳＩＰメッセージを送信し、ＳＣＣ−ＡＳにＤＲＶＣＣ転送を通知し、ＳＣＣ−ＡＳからＣＳアクセスにおいてＵＥをサービングする移動通信交換局（ＭＳＣ）へ向けてＳＩＰ ＩＮＶＩＴＥであって、ＵＥのアイデンティティが被呼者のアイデンティティとして含まれ、ＳＴＮが発呼者のアイデンティティとして含まれるＩＮＶＩＴＥを送信することによって、ＳＣＣ−ＡＳにおけるＳＩＰメッセージの受信に応答することを含む。本方法はさらに、ＭＳＣからＵＥへＣＳ設定メッセージを送信することによって、ＭＳＣにおける前記ＩＮＶＩＴＥの受信、又は関連ＣＳシグナリングの受信に応答することを含み、その結果ＭＳＣがＵＥからのＣＳ応答を待機する状態に置かれる。【選択図】図４

Description

本発明は、デュアル無線音声通信継続携帯端末を含む音声又はビデオ呼のパケット交換から回線交換への転送に関するものである。さらに具体的には、本発明は、着信呼び出し段階中の、着呼側でのデュアル無線音声通信継続携帯端末のハンドオーバに関するものである。

ＩＰマルチメディアサブシステム（ＩＭＳ）とは、ＩＰマルチメディアサービスをエンドユーザへ配信するための一本化され確立されたアーキテクチャである。エンドユーザによって使用されるアクセスネットワークを考慮した場合、ＩＭＳは大方依存性がない：アクセスネットワークは無線又は有線であってよい。ＩＭＳにおいては、エンドユーザがアクセスネットワークとアクセス技術間をシームレスに移ることができることにより、例えば、上記移動中に音声及びビデオ呼の継続が可能になることが重要である。

３ＧＰＰ ＴＳ ２３．２３７ ｖ１１．４．０には、携帯端末が単一無線インターフェースのみ利用可能である場合に、音声及びビデオ呼をＬＴＥパケット交換（ＰＳ）ドメインから従来技術の回線交換（ＣＳ）ドメインへ転送する、又は「ハンドオーバ」することが可能になるように、ロングタームエボリューション（ＬＴＥ）アーキテクチャに対して定義された機能性として単一無線音声通信継続（ＳＲＶＣＣ）が指定されている。上記転送は、例えば、パケット交換（ＰＳ）ＬＴＥ接続を介してユーザ端末によって呼が確立し、ＬＴＥ無線の品質低下により、呼を３Ｇ ＵＭＴＳ回線交換（ＣＳ）接続に転送することが必要になった時に、必要となりうる。図１は、（アクセス転送制御機能、ＡＴＣＦの拡張を使用した）ＳＲＶＣＣの基準アーキテクチャの概略図である。

ＳＲＶＣＣは、所定のＵＥのＰＳからＣＳへのハンドオーバが必要であるというネットワーク（ＬＴＥ）上の判断に依存する。ＵＥは、ＰＳアクセスを介して（すなわちＧｍインターフェースを介して）ＵＥへ送られた（ＳＩＰ）メッセージによってハンドオーバを実施するように指示され、この結果、ＰＳアクセスとの接続を切り、その代わりにＣＳアクセスに接続する。ＣＳネットワーク内のサービングＭＳＣはこれにより、ＵＥとＭＳＣとの間でＣＳ音声呼を確立するために、現在確立されているＣＳアクセスを介してＵＥへ設定信号を送り、その結果呼はＣＳアクセスへ転送される。呼呼び出し段階、すなわち、ＵＥはＩＮＶＩＴＥを受信しているがユーザが電話に応答する前の段階で、着信側においてハンドオーバが必要な時に、特別な場合が生じる。この特別な場合は、３ＧＰＰ ＴＳ ２３．２３７ ｖ１１．４．０の６．３．２．１．４ｃ項に考慮されている。

３ＧＰＰ ＴＳ ２３．２３７には、ＳＲＶＣＣと同類であるが、デュアル無線インターフェース、すなわち、並行して使用できる無線インターフェースを有する携帯端末に関係しているメカニズムとしてデュアル無線ＶＣＣ（ＤＲＶＣＣ）も指定されている。ＳＲＶＣＣと同様に、ＤＲＶＣＣも、通信確立後に、ＰＳからＣＳアクセスへの音声又はビデオ呼のハンドオーバを提供する。［ＳＲＶＣＣとは対照的に、ＤＲＶＣＣの場合、上記ハンドオーバを実施する判断は、ネットワーク内で行われる代わりにＵＥによって行われる。］しかしながら、ＤＲＶＣＣの仕様では、音声又はビデオ呼呼び出し段階において、ＰＳからＣＳへのハンドオーバを処理する手段が前もって提供されておらず、特に着信側の場合への対処がなされていない。

ＤＲＶＣＣについては、図２に呼び出し段階中に、発呼側において音声又はビデオ通信のＰＳからＣＳへのハンドオーバを処理する可能なメカニズムを示す。発信ユーザＵＥ−Ａは、ＩＮＶＩＴＥを着信ユーザ（図示せず）に向けて送信し、リンギング応答を受信する：このやり取りにはＰＳアクセスが使用される。この時点で、ＵＥ−ＡはＰＳアクセスの品質がこの通信に不適切であると判断し、ＣＳアクセスへ転送するために、ＤＲＶＣＣプロセスを開始する。ＵＥ−Ａは、ＣＳアクセスを介して設定要求を発信側のＭＳＣへ送信する。この要求には、セッション転送番号（ＳＴＮ）、ＳＣＣ ＡＳへの転送をルーティングするのに使用されるＵＥ上に静的に構成される番号が含まれる。ＭＳＣは次に、ＳＴＮが含まれるＩＮＶＩＴＥを（ＵＥ−Ａをサービングする）ＳＣＣ ＡＳへ送信する。［ＮＢ．［図２では、ＭＳＣは、ＩＭＳ側とＣＳシグナリング側との間の相互作用を提供することができる何らかの相互作用機能を備えることが想定される。］ＳＣＣ−ＡＳは、ＩＮＶＩＴＥ内に含有されるＳＴＮを使用して、要求がセッションをＰＳアクセスからＣＳアクセスへ転送する要求であることを検出し、シグナリング（例えば発呼者番号）の追加情報を使用して、転送要求を、前にＰＳアクセスを介して送られたＩＮＶＩＴＥと相互に関連付けする。ＩＮＶＩＴＥを送信した結果、ＭＳＣは応答が来ることを認識する。ＳＣＣ ＡＳから応答を受信すると、ＭＳＣは応答をＵＥ−Ａへ送信し、呼設定はＣＳアクセスを介して通常通り進行する。

図３は、呼呼び出し段階中に、着信側のＤＲＶＣＣを処理している時に生じうる問題を示している。この場合、最初ＰＳアクセスに接続された被呼者、ＵＥ−Ｂは、ＵＥ−ＡからＩＮＶＩＴＥを受信し、リンギング応答を送信する。この時点で、ＵＥ−ＢはＰＳアクセスの品質が音声着話に不適切であると判断し、ＣＳアクセスへ転送するために、ＤＲＶＣＣプロセスを開始する。ＵＥ−Ｂは次に、設定メッセージ（標準ＣＳシグナリング）をＭＳＣへ送信して転送を開始する。ＭＳＣは、ＩＮＶＩＴＥをＳＣＣ ＡＳに向けて送ることによって設定メッセージに反応する。［ＮＢ．［ＭＳＣは代替的にＣＳトランクシグナリング、例えばＩＳＵＰを使用することができ、この場合、トランクシグナリング設定メッセージはメディアゲートウェイコントローラを介してルーティングされる］。この時点で、ＭＳＣは遠隔端から、すなわちＳＣＣ−ＡＳからの応答を待機している。ユーザがＵＥ−Ｂで応答した場合、応答はＭＳＣへ送信され、この予期しない応答により、ＵＥ−ＢとＭＳＣに存在する状態の不一致が原因でＭＳＣにエラーが生じる。

ＭＳＣに新たな論理を導入することによってこの問題を解決することができるかもしれないが、これは実際には、すでに配備されたＭＳＣが大量であるために達成するのが困難である。解決策は、携帯端末とＳＣＣ−ＡＳにおいてのみ変更を伴うものであることが好ましい。一方では、端末ソフトウェアをアップグレードし展開することは比較的簡単であるが、他方では、比較的少数のＳＣＣ−ＡＳが展開されており、このＡＳをアップデートするのは比較的簡単なタスクである。

本発明の目的は、上述した問題を克服する、又は少なくとも軽減することである。これは、着信携帯端末が呼び出し段階において、ＰＳからＣＳへの転送が必要であることをＳＣＣ−ＡＳへ通知することを可能にすることによって達成可能である。ＳＣＣ−ＡＳは次に、ＭＳＣが確実に携帯端末から応答を受信する正しい状態に置かれるようにすることができる。

本発明の第１態様によれば、呼び出し段階における、パケット交換から回線交換方向へのＩＰマルチメディアセッション（ＩＭＳ）のデュアル無線アクセス転送の方法が提供されている。本方法は、着信移動局（ＵＥ）へ向けてＩＭＳメディアセッションを開始することと、セッション呼び出し段階の間に、ＵＥにおいてパケット交換（ＰＳ）から回線交換（ＣＳ）アクセスへのＤＲＶＣＣ転送が必要であるかの判断を行うこととを含む。本方法は、ＰＳアクセスを介してＵＥからサービス集中継続アプリケーションサーバ（ＳＣＣ−ＡＳ）へＳＩＰメッセージを送信することと、ＳＣＣ−ＡＳにＤＲＶＣＣ転送を通知することと、ＳＣＣ−ＡＳから、ＣＳアクセスにおいてＵＥをサービングする移動通信交換局（ＭＳＣ）に向けてＳＩＰ ＩＮＶＩＴＥであって、ＵＥのアイデンティティを被呼者のアイデンティティとして含み、ＳＴＮを発呼者のアイデンティティとして含むＩＮＶＩＴＥを送信することによって、ＳＣＣ−ＡＳにおけるＳＩＰメッセージの受信に応答することとを含む。本方法はさらに、ＣＳ設定メッセージをＭＳＣからＵＥへ送信することによって、ＭＳＣにおける前記ＩＮＶＩＴＥの受信、又は関連ＣＳシグナリングの受信に応答することを含み、するとすぐにＭＳＣは、ＵＥからのＣＳ応答を待機している状態に置かれる。

メディアゲートウェイ制御機能、ＭＧＣＦはＳＩＰ ＩＮＶＩＴＥを受信し、ＩＮＶＩＴＥを関連ＣＳシグナリングに変換して、この関連ＣＳシグナリングをＭＳＣへ送信することができる。

本発明の第２態様によれば、デュアル無線アクセス携帯端末（ＵＥ）が提供されている。端末は、呼び出し段階にあり、ＵＥが着信ＵＥであるＩＭＳセッションについて、パケット交換（ＰＳ）から回線交換（ＣＳ）アクセスへのＤＲＶＣＣ転送が必要であるかを判断するためのデュアル無線音声通話継続（ＤＲＶＣＣ）モジュールと、上記ＤＲＶＣＣ転送が必要であるとの判断に応答して、ＰＳアクセスを介してサービス集中継続アプリケーションサーバ（ＳＣＣ−ＡＳ）へＳＩＰメッセージを送信し、ＳＣＣ−ＡＳにＤＲＶＣＣ転送を通知するセッション転送イニシエータとを備える。

携帯端末は、ＣＳアクセスからＣＳ設定メッセージを受信し、ＣＳ設定メッセージ内に含まれるＳＴＮを識別し、ＳＴＮを使用してＣＳ設定メッセージを前記ＩＭＳセッションに関連付けし、ＣＳアクセスへＣＳ発呼が応答されたことを示し、その結果携帯端末がアクティブ状態に置かれるＣＳ接続を返すためのＣＳセッション確立モジュールを備えうる。

本発明の第３態様によれば、サービス集中継続アプリケーションサーバが提供されている。サーバは、ＰＳアクセスを介して携帯端末（ＵＥ）から、呼び出し段階のＩＭＳセッションにおいて、パケット交換（ＰＳ）から回線交換（ＣＳ）アクセスへのＤＲＶＣＣ転送が必要であることをＳＣＣ−ＡＳに通知するＳＩＰメッセージを受信するＳＩＰメッセージハンドラーと、前記ＳＩＰメッセージの受信に応答してＳＣＣ−ＡＳからＣＳアクセスにおいてＵＥをサービングする移動通信交換局（ＭＳＣ）に向けてＳＩＰ ＩＮＶＩＴＥであって、ＵＥのアイデンティティを被呼者のアイデンティティとして含み、ＳＴＮを発呼者のアイデンティティとして含むＩＮＶＩＴＥを送信するセッション転送コントローラとを備える。

（ＤＲＶＣＣにも適用可能な）ＳＲＶＣＣの基準アーキテクチャの概略図である。 転送されるＵＥが発信側である、呼び出し段階のＩＭＳセッションにおけるＰＳからＣＳへの良好なＤＲＶＣＣ転送に関連するフロー図である。 転送されるＵＥが着信側である、呼び出し段階のＩＭＳセッションにおけるＰＳからＣＳへの失敗したＤＲＶＣＣ転送に関連するフロー図である。 転送されるＵＥが着信側である、呼び出し段階のＩＭＳセッションにおけるＰＳからＣＳへの良好なＤＲＶＣＣ転送に関連するフロー図である。 図４のフローのさらなる詳細図である。 図４及び５のフローを実行するためのＵＥのアーキテクチャの概略図である。 図４及び５のフローを実行するためのＳＣＣ−ＡＳのアーキテクチャの概略図である。 呼び出し段階におけるＰＳからＣＳへのセッションのＤＲＶＣＣ転送を処理するための基本手順を示すフロー図である。 転送されるＵＥが発信側である、呼び出し段階のＩＭＳセッションにおけるＰＳからＣＳへの良好なＤＲＶＣＣ転送に関連するフロー図である。

本明細書において、呼び出し状態における呼のＤＲＶＣＣ転送を処理する手順が提案されており、着信側のＰＳからＣＳへの転送が想定される。この手順は、ＤＲＶＣＣ転送が必要であると着信ＵＥが判断した場合に、ＣＳアクセス内のＭＳＣを、着信ＵＥからの応答を待機する状態に置くことを含む。こうすると、ＭＳＣがＵＥから応答を受信した時に、ＭＳＣにおいてエラー状態は生じない。この手順では、ＭＳＣでの変更は必要ない。

着信ＵＥは、ＤＲＶＣＣ転送を開始すべきであることを示すメッセージをＳＣＣ ＡＳへ送信することができ、するとすぐにＳＣＣ ＡＳはＭＳＣへ向けてＩＮＶＩＴＥを送信する（これはＭＳＣへ向けての経路においてＣＳトランクシグナリングメッセージに変換することができる）。ＭＳＣは着信ＵＥへ設定要求を送信する。このプロセスにより、ＭＳＣは正しい状態に置かれる。

適切な通知をＳＣＣ ＡＳへ送信して、ＳＣＣ ＡＳにＭＳＣを正しい状態に置くようにすることができるユーザ端末が提案されている。

呼び出し状態にある着信ＵＥについて、ＤＲＶＣＣ転送が必要であるとの通知を受信し、そのＵＥに向けてＩＮＶＩＴＥを送信することによってＤＲＶＣＣ手順を開始することができるＳＣＣ ＡＳが提案されている。このＩＮＶＩＴＥにより、ＭＳＣは着信ＵＥからの応答を待機する状態に置かれる（ＩＮＶＩＴＥは、ＭＳＣへ送られる途上で関連のＣＳトランクシグナリングメッセージへ変換されうる）。

図４は、この方法に一致する、上述し、図３に示す問題への解決策を示す図である。図２のステップ４の代わりに、ＵＥは、Ｇｍインターフェースを介してＰＳからＣＳへのＤＲＶＣＣ転送を開始すべきであることを示すＳＩＰメッセージ、Ｓｔａｒｔ ＤＲＶＣＣをＳＣＣ ＡＳへ送信する。ＳＣＣ ＡＳは次にセッション転送手順を開始する。この解決策では、ＭＳＣへのいかなる変更も要さない。

ここで図５を参照する。図５は、ＰＳからＣＳ方向への、呼び出し状態のＩＭＳセッションのメディアのデュアル無線アクセス転送の情報フローをより詳細に示す図である。このフローでは、（ａ）ユーザが着信ＩＭＳセッションにおいてアクティブであること、そしてＳＩＰセッションが呼び出し状態にあること、及び（ｂ）他に進行中のセッションがなく、ＵＥがまだアクセスレグを介して応答していないことが要求される。図５を参照すると、下記のステップが識別されうる。
１〜４． 着信ＵＥ−ＢへのＳＩＰセッションの開始に標準手順が使用される。ＵＥ−Ｂはユーザに着呼音声又はビデオ呼セッションに注意喚起する。
５． ＵＥ−Ｂが、ＣＳへのアクセス転送が必要であると判断する。この時点でユーザがＣＳドメインにアタッチされていない場合、ＵＥ−ＢはＴＳ２３．２９２ ７．２．１項に指定されるＣＳアタッチを実施する。
６． 進行中のＳＩＰセッションにおいて、ＵＥ−Ｂは、ＰＳからＣＳへのセッション転送を開始する要求を含むＳＩＰメッセージ、Ｉｎｉｔ ＰＳ−ＣＳ ｔｒａｎｓｆｅｒをＳＣＣ ＡＳに向けて送信する。このＳＩＰメッセージは、例えば、（正しい）ＳＣＣ−ＡＳへメッセージがルーティングされるようにメッセージがＳＴＮを含むＳＩＰ ＩＮＦＯ又はＳＩＰ ＲＥＦＥＲであってよい。このメッセージは代替的に、ＩＮＶＩＴＥが後に送られる経路を介してメッセージがＳＣＣ−ＡＳへ自動的にルーティングバックされるＳＩＰ ４８８であってよく、ＳＴＮを含む必要はない。
７． ＳＩＰメッセージをＳＣＣ ＡＳへルーティングするために、Ｉ／Ｓ−ＣＳＣＦにおいて標準手順が使用される。
８． ＳＣＣ ＡＳは、ＣＳアクセスを介してＵＥ−ＢへＳＩＰ ＩＮＶＩＴＥを送信することによってセッション転送手順を開始する、すなわち、ユーザＢのアイデンティティはＣＳアクセス（すなわち、ＭＳＩＳＤＮ）を介したアドレス可能な被呼者のアイデンティティである。ＳＣＣ ＡＳは、ＵＥ−ＢがＩＮＶＩＴＥを進行中のセッションと相互関連させることができるように、ＳＴＮを発呼者のＩＤとして使用する。［ある場合には、ＵＥ−ＢのＭＳＩＳＤＮを使用してＵＥ−Ｂに呼を直接ルーティングすることができず、この場合は、ＣＳアクセスのＭＳＣを介してＵＥ−Ｂへ呼をルーティングするためにいわゆるＣＳブレイクアウト手順を使用することができることに留意すべきである。これは例えば、いわゆるプレフィックスルーティングを使用して、又はＣＳＲＮを使用して達成することができる（例：２３．２９２ 別添 Ｆ．３参照）。］
留意点：ＳＣＣ ＡＳは、Ｍｇ又はＩ２を介してセッションをＣＳアクセスへ方向づけすることができる（ＴＳ２３．２９２参照）。
９． ＩＮＶＩＴＥをＭＳＣサーバへルーティングするために、Ｉ／Ｓ−ＣＳＣＦにおいて標準手順が使用される。ＭＳＣサーバが改善されない場合、ＭＧＣＦを介してＣＳシグナリングが使用される（場合により、ＩＡＭメッセージがＭＧＣＦとＭＳＣとの間に送信され、これは次にＭＳＣによってＣＳ ＳＥＴＵＰに変換されてＵＥに向けて送信される）。
１０． ＭＳＣサーバはＣＳ ＳｅｔｕｐをＵＥ−Ｂへ送信する。ＵＥ−Ｂは、発呼者がそれ自体のＳＴＮを受信した時に、ＤＲＶＣＣ使用によるアクセス転送が要求されているかを判断する。
１０ａ． ＣＳ Ｓｅｔｕｐの送信において、ＭＳＣは自身をＵＥ−Ｂからの応答を受信する準備ができた状態に置く。これは標準のＭＳＣ動作である。
１０ｂ． ＣＳ Ｓｅｔｕｐの受信において、ＵＥ−Ｂは自身をユーザの応答を受信する準備ができた状態に置く。
１１． ユーザが応答する。
１２． ＵＥ−Ｂは標準手順を使用して、例えばＴＳ ２４．００８に記載されるようにＭＳＣサーバにＣＳ接続メッセージを送信する。
１２ａ． ＵＥ−Ｂがアクティブ状態に移る。
１２ｂ． ＭＳＣサーバがアクティブ状態に移る。
１３． ＭＳＣが８で開始されたＳＩＰセッションにおいて応答メッセージを送信する。
１４． 応答をＳＣＣ ＡＳへ送るために、Ｉ／Ｓ−ＣＳＣＦにおいて標準手順が使用される。
１５． ＳＣＣ ＡＳは対応するＳＩＰ要求を遠隔端に作成し、遠隔レグをアップデートする。

上述した手順においては、ステップ６及び８を実行するために新たな機能がＵＥ及びＳＣＣ−ＡＳに導入される。具体的には、新たな機能がＵＥに導入され、これによりＵＥがＳＣＣ−ＡＳに向けて転送を識別するＳＩＰメッセージを送信する。ＳＣＣ−ＡＳに新たな機能が導入され、これによりＳＣＣ−ＡＳがＵＥ（及びＭＳＣ）に向けてＳＩＰ ＩＮＶＩＴＥを送信することによってこのＳＩＰメッセージの受信に反応する。他のステップは、すでに標準化された機能を使用して達成される。まさに、この手順の主な利点は、ＭＳＣ又は他の何らかの中間ノードを修正する必要がないということである。

ＵＥを考慮すると、図６は、ＩＭＳセッションの呼び出し段階においてＰＳからＣＳへのＤＲＶＣＣ転送を処理するために改善されたＤＲＶＣＣ携帯端末（ＵＥ）の特定のコンポーネントを概略的に示す図である。当然ながら、ＵＥがプロセッサ、メモリ等を含む様々なソフトウェア及びハードウェアのコンポーネントを使用して実行される特定の標準機能を含む。ＵＥは、例えばディスプレイ、キーパッド、スピーカー、マイクロホン等を備えるユーザインターフェース１を備える。ユーザインターフェースにより、ユーザがＵＥとやり取りをすることが可能になる。具体的には、インターフェースにより、ユーザが着信音声又は着信ビデオ呼に注意喚起され、上記呼に応答することが可能になる。ＵＥはまた、音声及びビデオ呼を含むＩＭＳセッションを確立し制御する役割を果たすＳＩＰ／ＩＭＳクライアント２も備える。

ＣＳアクセスコントローラ３は、ＳＩＰ／ＩＭＳクライアント２によってＣＳアクセスコントローラ３に提供される制御信号に基づいてＣＳのアタッチ及びデタッチを行う役割を担っている。ＣＳアクセスコントローラは、制御シグナリングをＣＳアクセス及びＳＩＰ／ＩＭＳクライアント間でも伝達する。ＰＳアクセスコントローラ４も同様に、ＰＳのアタッチ及びデタッチを行い、ＰＣアクセス及びＳＩＰ／ＩＭＳクライアント間で制御シグナリングを伝達する役割を果たす。ＣＳアクセスコントローラ３及びＰＳアクセスコントローラ４は、それぞれの無線インターフェース５、６を介してＣＳ及びＰＳアクセスネットワークと通信する。

ＳＩＰ／ＩＭＳクライアント２、及び特定の既知の標準機能をさらに考慮すると、これにより、呼び出し段階のＩＭＳセッションについて、パケット交換（ＰＳ）から回線交換（ＣＳ）アクセスへのＤＲＶＣＣ転送が必要かを判断するように適合されたＤＲＶＣＣモジュール７が実装される。クライアント２はさらに、ＤＲＶＣＣモジュール７に連結されたセッション転送イニシエータ８を備える。ＤＲＶＣＣモジュールが、呼び出し段階のＩＭＳセッションをＰＳからＣＳアクセスへ転送するべきであると判断したら、ＤＲＶＣＣモジュールは、これをセッション転送イニシエータ８に示す。セッション転送イニシエータ８は、ＰＳアクセスを介して、つまりＰＳアクセスコントローラ４及び関連の無線インターフェース６を介してＳＩＰメッセージをサービス集中継続アプリケーションサーバ（ＳＣＣ−ＡＳ）へ送信し、ＳＣＣ−ＡＳにＤＲＶＣＣ転送を通知することによって応答し、ＵＥのセッション転送番号（ＳＴＮ）を任意に含む。

ＳＣＣ−ＡＳをここで考慮すると、これは図７に概略的に示されている。ＳＣＣ−ＡＳはＩＳＣインターフェース１０を備え、ＩＳＣインターフェース１０により、例えばＩＭＳサブスクライバセッションに関連するＩ−ＣＳＣＦ又はＳ−ＣＳＣＦを用いた、ＳＣＣ−ＡＳのＳＩＰメッセージの送受信が可能になる。ＳＣＣ−ＡＳはさらに、携帯端末（ＵＥ）からＰＳアクセスを介して、呼び出し段階のＩＭＳセッションについて、パケット交換（ＰＳ）から回線交換（ＣＳ）アクセスへのＤＲＶＣＣ転送が必要であることをＳＣＣ−ＡＳへ通知するＳＩＰメッセージを受信するＳＩＰメッセージハンドラー１１を備える。すでに留意事項として記載したが、このＳＩＰメッセージは任意に、ＵＥのセッション転送番号（ＳＴＮ）を含む。ＳＣＣ−ＡＳは、ＳＩＰメッセージハンドラー１１に連結され、前記ＳＩＰメッセージの受信に応答して、ＳＣＣ−ＡＳから、ＣＳアクセスにおいてＵＥをサービングする携帯通信交換局（ＭＳＣ）に向けてＳＩＰ ＩＮＶＩＴＥを送信するセッション転送コントローラ１２を備える。このセッション転送コントローラ１２はＩＮＶＩＴＥに、ＵＥのアイデンティティを被呼者のアイデンティティとして含み、ＳＴＮを発呼者のアイデンティティとして含むように構成される。

図８は、上述した転送手順を一般用語で示すフロー図である。ステップＳ１において、着信移動局（ＵＥ）に向けてＩＭＳメディアセッションが開始される。次に、ステップＳ２において、セッション呼び出し段階中に、ＵＥにおいてパケット交換（ＰＳ）から回線交換（ＣＳ）アクセスへのＤＲＶＣＣ転送が必要であるとの判断が行われる。ステップＳ３において、着信ＵＥは、ＰＳアクセスを介してサービス集中継続アプリケーションサーバ（ＳＣＣ−ＡＳ）へＳＩＰメッセージを送り、ＳＣＣ−ＡＳにＤＲＶＣＣ転送を通知し、ＵＥのセッション転送番号（ＳＴＮ）を任意に含める。

ステップＳ４において、ＳＣＣ−ＡＳはＳＩＰメッセージを受信し、ＳＣＣ−ＡＳからＣＳアクセスでＵＥをサービングしている移動通信交換局（ＭＳＣ）に向けてＵＥのアイデンティティが被呼者のアイデンティティとして含まれ、ＳＴＮが発呼者のアイデンティティとして含まれるＳＩＰ ＩＮＶＩＴＥを送信することによって応答する。ステップＳ５において、ＭＳＣはＩＮＶＩＴＥ、又はＭＧＣＦによって伝達されるＣＳシグナリングを受信し、ＣＳ設定メッセージをＵＥへ送信することによって応答する。ステップＳ６において、ＭＳＣはＵＥからＣＳ応答を待機している状態に置かれる。

ここでは主に、着信側で生じるＤＲＶＣＣの場合に焦点を当てる（図３及び４）。しかしながら、発信側においてもＤＲＶＣＣを考慮することが有用でありうる。図９は、発信側の場合を考慮した、ＰＳからＣＳへのＤＲＶＣＣ転送の情報フローの一例を示す図である（呼び出し段階における発信音声又はビデオ呼、ＩＭＳセッション）。このフローでは、ユーザが着信ＩＭＳセッションにおいてアクティブであり、ＳＩＰセッションが呼び出し状態にあり、他に進行中のセッションがなく、ＵＥはアクセスレグを介してまだ応答していないことが要求される。図９は、具体的に下記のステップを示す。
１−４． ＵＥ−Ａの代わりに標準手順を使用してＳＩＰセッションが開始される。ＵＥ−Ａは着信音声又はビデオ呼セッションにおいてユーザの注意を喚起している。
５． ＵＥ−Ａは、ＰＳからＣＳへのアクセス転送の必要を判断する。ユーザがこの時点でＣＳアクセスにアタッチされていない場合、ＵＥ−ＡはＴＳ２３．２９２、７．２．１項に指定されるようにＣＳアタッチを実施する。
６． ＵＥ−Ａは、ＴＳ２４．００８に従ってＳＴＮに送られるＣＳ設定メッセージを送信することによってデュアル無線アクセス転送手順を開始する。
７． ＭＳＣサーバは呼を６で受信したＳＴＮに向けてルーティングする。ＭＳＣが改善されない場合、ＳＣシグナリングが使用され、ＭＧＣＦを通して呼設定メッセージがルーティングされる。
８． ＩＮＶＩＴＥをＳＣＣ ＡＳへルーティングするために、Ｉ／Ｓ−ＣＳＣＦにおいて標準手順が使用される。
９． ＳＣＣ ＡＳはＳＴＮを使用して、デュアル無線ＶＣＣを使用するアクセス転送が要求されているかを判断する。ＳＣＣ ＡＳはＨＳＳからＣ−ＭＳＩＳＤＮを読み出すことができる。ＳＣＣ ＡＳは正確なアンカーセッションを識別する。ＳＣＣ ＡＳは、（現在の３ＧＰＰの提案を参照して）６．３．１．５項に指定される遠隔レグアップデート手順を使用して、メディア記述及び他の情報と共に遠隔レグをアップデートすることによって、ＵＥ−Ａの双方向音声又は双方向音声と同期ビデオを用いて最近加えられたアクティブセッションのアクセス転送を進める。
留意点１ 最初のＳＤＰネゴシエーションは、（ｖ）ＳＲＶＣＣをトリガする前に完了しているため、ＳＣＣ ＡＳは遠隔レグをアップデートすることができると想定される。
１０． ＳＣＣ ＡＳはＵＥ−Ａに向けてリンギングメッセージを送信する。
１１． Ｓ−ＣＳＣＦはリンギングメッセージをＭＳＣサーバへ送る。
１２． ＭＳＣサーバは、ＴＳ２４．００８［２４］に従ってＵＥ−ＡへＣＳ呼び出しメッセージを送信する。
１２ａ． ＭＳＣは呼び出し状態へ移る（ＴＳ２４．００８参照）。
１２ｂ． ＵＥ−Ａは呼び出し状態へ移り、エンドユーザに対して同じ呼び出し音が鳴るようにする。
１３． 遠隔端が呼に応答する。
１４． ＳＣＣ ＡＳはＭＳＣに向けて応答メッセージを送信する。
１５． 応答メッセージをＭＳＣへルーティングするために、Ｓ−ＣＳＣＦにおいて標準手順が使用される。
１６． ＭＳＣは標準手順を使用して、ＴＳ２４．００８に記載されるように、ＵＥ−ＡへＣＳ接続メッセージを送信する。
１６ａ． ＭＳＣはアクティブ状態に移る。
１６ｂ． ＵＥ−Ａはアクティブ状態に移る。

ＣＳからＰＳへのアクセス転送の場合をここで考察する。ＣＳからＰＳ − デュアル無線、呼び出し段階の着信音声呼、この手順は、既存の「早期対話段階における着呼のフルメディア転送を用いたＰＳ−ＰＳアクセス転送」（６．３．２．２．３）にしたがって処理され、ステップ１〜４が下記のように修正される。ＭＳＣサーバは、ＴＳ２３．２９２にしたがってＩＭＳ集中型のＣＳセッションをＵＥに向けて開始している。ＵＥはユーザからの応答を待機する。ユーザが応答する前に、ＵＥはＰＳへ移ることを決定する。手順は６．３．２．２．３のステップ５を踏む。ＩＰ−ＣＡＮ２は新たなＰＳレグを表す。ＵＥは転送に静的に構成されたＳＴＩを使用する。

ここで、ＣＳからＰＳへのアクセス転送の場合を考察する。ＣＳからＰＳ−デュアル無線、呼び出し段階の発信音声呼、この手順は、６．３．２．２．４の手順「早期対話段階における発呼のフルメディア転送を用いたＰＳ−ＰＳアクセス転送」にしたがって処理され、ステップ１〜４が下記のように修正される。ＵＥは、ＴＳ２３．２９２にしたがってＩＭＳ集中型のＣＳセッションを開始している。ＵＥは遠隔端からの応答を待機する。遠隔端が応答する前に、ＵＥはＰＳへ移ることを決定する。手順は６．３．２．２．３のステップ５を踏む。ＩＰ−ＣＡＮ２は新たなＰＳレグを表す。ＵＥは転送に静的に構成されたＳＴＩを使用する。

当業者は、本発明の範囲から逸脱することなく、上述の実施形態に様々な変更を行うことができることを理解するだろう。

Claims (7)

1. パケット交換から回線交換方向への呼び出し段階におけるＩＰマルチメディアセッション（ＩＭＳ）のデュアル無線アクセス転送の方法であって、
   着信移動局（ＵＥ）に向けてＩＭＳメディアセッションを開始することと、
   セッションの呼び出し段階中に、前記ＵＥにおいて、パケット交換（ＰＳ）から回線交換（ＣＳ）アクセスへのＤＲＶＣＣ転送が必要であるとの判断を行うことと、
   前記ＰＳアクセスを介して前記ＵＥからサービス集中継続アプリケーションサーバ（ＳＣＣ−ＡＳ）へ前記ＤＲＶＣＣ転送を前記ＳＣＣ−ＡＳへ通知するＳＩＰメッセージを送信することと、
   前記ＳＣＣ−ＡＳから前記ＣＳアクセスにおいて前記ＵＥをサービングしている移動通信交換局（ＭＳＣ）に向けてＳＩＰ ＩＮＶＩＴＥであって、前記ＵＥのアイデンティティを被呼者のアイデンティティとして含み、ＳＴＮを発呼者のアイデンティティとして含むＩＮＶＩＴＥを送信することによって、前記ＳＣＣ−ＡＳにおける前記ＳＩＰメッセージの受信に応答することと、
   前記ＭＳＣから前記ＵＥへＣＳ設定メッセージを送信することによって、前記ＭＳＣにおける前記ＩＮＶＩＴＥの受信、又は関連ＣＳシグナリングの受信に応答することであって、その結果前記ＭＳＣが前記ＵＥからのＣＳ応答を待機する状態に置かれる、応答することと
   を含む方法。
2. 前記ＳＩＰ ＩＮＶＩＴＥがメディアゲートウェイ制御機能（ＭＧＣＦ）によって受信され、前記ＭＧＣＦは前記ＩＮＶＩＴＥを前記関連ＣＳシグナリングに変換し、前記関連ＣＳシグナリングを前記ＭＳＣへ送信する、請求項１に記載の方法。
3. デュアル無線アクセス携帯端末（ＵＥ）であって、
   呼び出し段階であり、ＵＥが着信ＵＥであるＩＭＳセッションにおいて、パケット交換（ＰＳ）から回線交換（ＣＳ）アクセスへのＤＲＶＣＣ転送が必要であるかを判断するためのデュアル無線音声通信継続（ＤＲＶＣＣ）モジュールと、
   上記ＤＲＶＣＣ転送が必要であるとの判断に応答して、ＰＳアクセスを介してサービス集中継続アプリケーションサーバ（ＳＣＣ−ＡＳ）へ前記ＳＣＣ−ＡＳに前記ＤＲＶＣＣ転送を通知するＳＩＰメッセージを送信するためのセッション転送イニシエータと
   を備える携帯端末。
4. 前記ＳＩＰメッセージがＳＩＰ ＩＮＦＯ、ＳＩＰ ４８８、又はＳＩＰ Ｒｅｆｅｒのうちの一つである、請求項３に記載の携帯端末。
5. 前記ＣＳアクセスからＣＳ設定メッセージを受信し、前記ＣＳ設定メッセージ内に含まれたＳＴＮを識別し、前記ＳＴＮを使用して前記ＣＳ設定メッセージと前記ＩＭＳセッションとを相互に関連付けして、前記ＣＳアクセスへ前記ＣＳ発呼が応答されたことを示し、その結果前記携帯端末がアクティブ状態に置かれるＣＳ接続を返すためのＣＳセッション確立モジュールを備える、請求項３又は４に記載の携帯端末。
6. サービス集中継続アプリケーションサーバであって、
   ＰＳアクセスを介して携帯端末（ＵＥ）から、呼び出し段階のＩＭＳセッションにおいて、パケット交換（ＰＳ）から回線交換（ＣＳ）アクセスへのＤＲＶＣＣ転送が必要であることを前記ＳＣＣ−ＡＳに通知するＳＩＰメッセージを受信するためのＳＩＰメッセージハンドラーと、
   前記ＳＩＰメッセージの受信に応答して、前記ＳＣＣ−ＡＳから、前記ＣＳアクセスにおいて前記ＵＥをサービングする移動通信交換局（ＭＳＣ）に向けてＳＩＰ ＩＮＶＩＴＥであって、前記ＵＥのアイデンティティを被呼者のアイデンティティとして含み、ＳＴＮを発呼者のアイデンティティとして含むＩＮＶＩＴＥを送信するためのセッション転送コントローラと
   を備えるサービス集中継続アプリケーションサーバ。
7. 前記ＳＩＰメッセージが、ＳＩＰ ＩＮＦＯ、ＳＩＰ ４８８、又はＳＩＰ Ｒｅｆｅｒのうちの一つである、請求項６に記載のサービス集中継続アプリケーションサーバ。

Images