(57)【特許請求の範囲】
【請求項１】
パケット交換ドメインから回線交換ドメインへビデオ会話をハンドオーバする方法であって、
ａ．前記パケット交換ドメイン内の基地局が、ユーザ端末から測定レポートを受信する時に、前記測定レポートおよびビデオ・ベアラの識別に従って、前記パケット交換ドメイン内の制御機器にハンドオーバ要求を送信するステップと、
ｂ．前記パケット交換ドメイン内の前記制御機器が、前記パケット交換ドメイン内の前記基地局から前記ハンドオーバ要求を受信する時に、前記ビデオ・ベアラの前記識別に従って前記ビデオ・ベアラを非ビデオ・ベアラから分離し、前記ハンドオーバがビデオ・ベアラに関するハンドオーバであることが示されるハンドオーバ要求を前記回線交換ドメイン内の制御機器に送信するステップと、
ｃ．前記回線交換ドメイン内の前記制御機器が、前記パケット交換ドメイン内の前記制御機器から前記ハンドオーバ要求を受信する時に、指定されたレートを有する通信リンクを予約することが示される再配置要求をターゲット無線ネットワーク制御装置に送信するステップと、
ｄ．前記ユーザ端末が、ターゲット・ネットワークにハンドオーバする時に、前記指定されたレートを有する前記通信リンク上で前記ビデオ会話のために要求される論理通信チャネルを確立するために前記回線交換ドメイン内の前記制御機器とネゴシエートするステップと
を含む方法。
【請求項２】
前記ステップｄは、
前記ユーザ端末が前記ターゲット無線ネットワーク制御装置にハンドオーバ完了メッセージを送信した後に、前記ユーザ端末が、前記指定されたレートを有する前記通信リンク上で前記ビデオ会話のために要求される論理通信チャネルを確立するために前記回線交換ドメイン内の前記制御機器とのそのネゴシエーションを開始するステップ
をさらに含むことを特徴とする、請求項１に記載の方法。
【請求項３】
前記ステップｄは、
前記回線交換ドメイン内の前記制御機器が前記ターゲット無線ネットワーク制御装置から前記ハンドオーバ完了メッセージを受信した後に、前記回線交換ドメイン内の前記制御機器が、前記指定されたレートを有する前記通信リンク上で前記ビデオ会話のために要求される論理通信チャネルを確立するために前記ユーザ端末とのそのネゴシエーションを開始するステップ
をさらに含むことを特徴とする、請求項１に記載の方法。
【請求項４】
前記パケット交換ドメイン内の前記制御機器は、ｍｏｂｉｌｉｔｙ  ｍａｎａｇｅｍｅｎｔ  ｅｎｔｉｔｙ  ＭＭＥであることを特徴とする、請求項１乃至３のいずれか１項に記載の方法。
【請求項５】
前記回線交換ドメイン内の前記制御機器は、ＭＳＣサーバまたはメディア・ゲートウェイＭＧＷであることを特徴とする、請求項１乃至３のいずれか１項に記載の方法。
【請求項６】
パケット交換ドメインから回線交換ドメインへビデオ会話をハンドオーバするための、前記パケット交換ドメイン内の基地局内の装置であって、
ユーザ端末から測定レポートを受信する第１受信手段と、
前記測定レポートおよびビデオ・ベアラの識別に従って前記ビデオ会話を前記回線交換ドメインにハンドオーバすると決定する決定手段と、
前記パケット交換ドメイン内の制御機器にハンドオーバ要求を送信する第１送信手段と
を含み、
前記パケット交換ドメイン内の前記制御機器から受信した指定されたレートを有する通信リンクに関するハンドオーバ・コマンドをユーザ端末に送信し、前記指定されたレートを有する前記通信リンク上で前記ビデオ会話のための要求される論理通信チャネルを確立するため、前記ユーザ端末に、前記回線交換ドメイン内の前記制御機器とネゴシエートさせる装置。
【請求項７】
パケット交換ドメイン内の制御機器内の、ビデオ会話を前記パケット交換ドメインから回線交換ドメインにハンドオーバする装置であって、
前記パケット交換ドメイン内の基地局からハンドオーバ要求を受信する第２受信手段と、
前記ビデオ・ベアラの前記識別に従って非ビデオ・ベアラから前記ビデオ・ベアラを分離する分離手段と、
前記ハンドオーバがビデオ・ベアラに関するハンドオーバであることが示されるハンドオーバ要求を前記回線交換ドメイン内の制御機器に送信する第２送信手段と
を含み、
前記パケット交換ドメインと前記回線交換ドメインとの指定されたレートを有する通信リンクが確立されると、指定されたレートを有する通信リンクに関するハンドオーバ・コマンドを、前記基地局を介してユーザ端末へと送信し、前記指定されたレートを有する前記通信リンク上で前記ビデオ会話のために要求される論理通信チャネルを確立するため、前記ユーザ端末に、前記回線交換ドメイン内の前記制御機器とネゴシエートさせる装置。
【請求項８】
前記パケット交換ドメイン内の前記制御機器は、ｍｏｂｉｌｉｔｙ  ｍａｎａｇｅｍｅｎｔ  ｅｎｔｉｔｙ  ＭＭＥであることを特徴とする、請求項７に記載の装置。
【請求項９】
回線交換ドメイン内の制御機器内の、ビデオ会話をパケット交換ドメインから回線交換ドメインにハンドオーバする装置であって、
前記パケット交換ドメイン内の制御機器からハンドオーバ要求を受信する第３受信手段と、
指定されたレートを有する通信リンクを予約することが示される再配置要求をターゲット無線ネットワーク制御装置に送信する第３送信手段と、
前記指定されたレートを有する前記通信リンク上で前記ビデオ会話のために要求される論理通信チャネルを確立するためにユーザ端末とネゴシエートするネゴシエーティング手段と
を含む装置。
【請求項１０】
前記回線交換ドメイン内の前記制御機器は、ＭＳＣサーバまたはメディア・ゲートウェイＭＧＷであることを特徴とする、請求項９に記載の装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信ネットワークに関し、具体的には、モバイル・ネットワーク内でパケット交換ドメインから回線交換ドメインへビデオ会話をハンドオーバする方法および装置に関する。
【背景技術】
【０００２】
我々は、現在、固定ネットワークとモバイル・ネットワークの急速な統合を経験しつつあり、そのような環境においてＩＭＳ（ＩＰ  Ｍｕｌｔｉｍｅｄｉａ  Ｓｕｂｓｙｔｅｍ）が登場している。ＩＭＳは、全世界のアクセス独立で標準規格ベースのＩＰ通信リンクおよびサービス制御のアーキテクチャであり、これは、一般的なインターネット・プロトコル・ベースの端末のユーザが異なるタイプのマルチメディア・サービスを使用することを可能にする。ＩＭＳシステムは、さまざまなアクセスの形を提供するだけではなく、回線交換ドメインとのインターワーキングをも提供する。パケット交換ドメイン内に配置されたマルチモード・モバイル端末について、その端末は、そのパケット交換ドメインによってカバーされるネットワークのエッジもしくは外に移動する時、またはそのパケット交換ドメインによって現在カバーされているネットワークが、その端末が回線交換ドメインによってカバーされるネットワーク内に位置する間に使用不能になる時に、会話品質を保証するためにパケット交換ドメインから回線交換ドメインに会話をハンドオーバすることができる。
【０００３】
３ＧＰＰ  ＴＳ  ２３．２１６は、ＩＭＳシステム内でアンカリングされる呼について、音声呼の連続性を維持するために、ＥＰＳ（Ｅｖｏｌｖｅｄ  Ｐａｃｋｅｔ  Ｓｙｓｔｅｍ）ＰＳ（パケット交換）アクセスとＵＴＲＡＮ／ＧＥＲＡＮ（Ｕｎｉｖｅｒｓａｌ  Ｔｅｒｒｅｓｔｒｉａｌ  Ｒａｄｉｏ  Ａｃｃｅｓｓ  Ｎｅｔｗｏｒｋ／ＧＳＭ（登録商標）  ＥＤＧＥ  Ｒａｄｉｏ  Ａｃｃｅｓｓ  Ｎｅｔｗｏｒｋ）ＣＳ（回線交換）アクセスとの間のＳＲＶＣＣ（Ｓｉｎｇｌｅ  Ｒａｄｉｏ  Ｖｏｉｃｅ  Ｃａｌｌ  Ｃｏｎｔｉｎｕｉｔｙ）解決策を指定する。そのような状況では、ＵＥ（ユーザ機器）は、所与の時にこの２つのアクセス・ネットワークのうちの１つだけを介してデータを送信しまたは受信することができる。
【０００４】
図１に、３ＧＰＰ  ＴＳ  ２３．２１６で指定されたＥ−ＵＴＲＡＮ（Ｅｖｏｌｖｅｄ  ＵＴＲＡＮ）からＵＴＲＡＮ／ＧＥＲＡＮへのＶｏＩＰ会話ハンドオーバのためのＳＲＶＣＣのネットワーク・アーキテクチャを示す。
【０００５】
図１に示されているように、ＵＥは、Ｅ−ＵＴＲＡＮおよびＳ−ＧＷ／ＰＤＮ  ＧＷを介してＩＭＳにアクセスする。Ｅ−ＵＴＲＡＮは、ＬＴＥ（Ｌｏｎｇ  Ｔｅｒｍ  Ｅｖｏｌｕｔｉｏｎ）としても知られ、無線アクセス・ネットワーク部分の責任を負う複数のＥ−Ｎｏｄｅ  Ｂを含む。ＥＰＳは、既存のＷＣＤＭＡシステムおよびＴＤ−ＳＣＤＭＡシステムのＮｏｄｅＢ、ＲＮＣ、およびＣＮの機能的統合によって、ｅＮｏｄｅＢおよびＥＰＣという２つのネットワーク要素として単純化される。ＥＰＣは、コア・ネットワークのシグナリングを扱う責任を有する制御ノードとして働くＭＭＥ（Ｍｏｂｉｌｉｔｙ  Ｍａｎａｇｅｍｅｎｔ  Ｅｎｔｉｔｙ）と、コア・ネットワークのデータを処理する責任を負うＳ−ＧＷ（Ｓｅｒｖｉｎｇ  ＧａｔｅＷａｙ）／ＰＤＮ−ＧＷ（Ｐａｃｋｅｔ  Ｄａｔａ  Ｎｅｔｗｏｒｋ  ＧａｔｅＷａｙ）とを含む。ここで、ネットワークへの非３ＧＰＰ無線アクセスは、ＰＤＮ−ＧＷを介してＥＰＣにアクセスすることができ、３ＧＰＰ無線アクセス・ネットワークは、Ｓ−ＧＷを介してＥＰＣにアクセスすることができる。
【０００６】
さらに、図１は、さらに、その仕様によって提案されるネットワーク要素の間のインターフェースを示す。たとえば、Ｅ−ＵＴＲＡＮおよびＥＰＣは、Ｓ１（Ｉｕに似た）インターフェースを介して接続され、その間のＥ−ＵＴＲＡＮは、Ｘ２（Ｉｕｒに似た）インターフェース（図示せず）を介して接続することができ、ＵＥおよびＥ−ＵＴＲＡＮは、ＬＴＥ−Ｕｕインターフェースを介して接続される。
【０００７】
図１に示された環境では、ＵＥは、Ｅ−ＵＴＲＡＮのカバレージのエッジまたはそのカバレージ・エリアの外に位置する時に、ＵＴＲＡＮ／ＧＥＲＡＮによって提供される回線交換ドメインにハンドオーバすると判断することができる。ＵＴＲＡＮ／ＧＥＲＡＮでは、ＵＥは、基地局およびＭＳＣ（Ｍｏｂｉｌｅ  Ｓｗｉｔｃｈ  Ｃｅｎｔｅｒ）サーバを介してＩＭＳネットワークにアクセスする。
【０００８】
ここで、ＵＴＲＡＮは、ＵＭＴＳ用の比較的新しいアクセス・ネットワークであり、ＵＭＴＳのより重要なアクセスの形になったが、ＮｏｄｅＢ、（Ｎｏｄｅ  Ｂ）、ＲＮＣ（無線ネットワーク制御装置）、ＣＮ（コア・ネットワーク）などを含むことができ、ここで、１つのＲＮＣおよび１つまたは複数のＮｏｄｅＢが、１つのＲＮＳ（Ｒａｄｉｏ  Ｎｅｔｗｏｒｋ  Ｓｕｂｓｙｔｅｍ）を構成し、３ＧＰＰによって指定され、維持されるＧＭＳの主要部分であるＧＥＲＡＮは、やはりＵＭＴＳ／ＧＳＭ（登録商標）ネットワーク内に含まれ、基地局ＢＳおよび基地局制御装置ＢＳＣのインターフェース（たとえば、Ａｔｅｒインターフェース、Ａｂｉｓインターフェース、Ａインターフェースなど）を含む。モバイル・オペレータのネットワークは、一般に、ＵＭＴＳ／ＧＳＭ（登録商標）ネットワーク内でＵＴＲＡＮと組み合わされる複数のＧＥＲＡＮからなる。
【０００９】
図１の他のネットワーク要素およびネットワーク要素または類似物の間の通信の形に関する詳細な情報については、ＴＳ  ２３．２１６に関して参照を行うことができる。
【００１０】
図２に、３ＧＰＰ  ＴＳ  ２３．２１６で指定されたＥ−ＵＴＲＡＮからＵＴＲＡＮ／ＧＥＲＡＮへのＳＲＶＣＣハンドオーバの呼の流れ図を示す。音声会話のハンドオーバを完了するために、音声呼は、前もって、ＳＣＣ  ＡＳ（Ｓｅｒｖｉｃｅ  Ｃｅｎｔｒａｌｉｚａｔｉｏｎ  ａｎｄ  Ｃｏｎｔｉｎｕｉｔｙ  Ａｐｐｌｉｃａｔｉｏｎ  Ｓｅｒｖｅｒ）など、ＩＭＳ内でアンカリングされる必要がある。図２のステップは、次のように説明される。
【００１１】
ステップ１  ローカルＵＥは、現在の無線ネットワークの信号が検出後によくないことを見つけ、測定レポートをＥ−ＵＴＲＡＮに送信する。
【００１２】
ステップ２  ＵＥの測定レポートに基づいて、ソースＥ−ＵＴＲＡＮ（具体的には、その中のｅＮｏｄｅＢ）は、ＵＴＲＡＮへのハンドオーバのＳＲＶＣＣ手順をトリガすると判断する。
【００１３】
ステップ３  ソースＥ−ＵＴＲＡＮは、Ｈａｎｄｏｖｅｒ  ＲｅｑｕｉｒｅメッセージをソースＭＭＥに送信する。このメッセージ内のＳＲＶＣＣ  ＨＯパラメータは、ハンドオーバのターゲット・ドメインがＣＳドメインであることを示す。
【００１４】
ステップ４  オーディオ・ベアラのＱＣＩ（ＱｏＳ  Ｃｌａｓｓ  Ｉｄｅｎｔｉｔｙ）およびＳＲＶＣＣ  ＨＯパラメータに基づいて、ソースＭＭＥは、オーディオ・ベアラを非オーディオ・ベアラから分離し、オーディオ・ベアラのみのＭＳＣサーバへのＰＳからＣＳへのハンドオーバ手順を開始する。
【００１５】
ステップ５  ソースＭＭＥは、ＳＲＶＣＣ  ＰＳ  ｔｏ  ＣＳ  ＲｅｑｕｅｓｔメッセージをＭＳＣサーバに送信する。
【００１６】
ステップ６  ＭＳＣサーバがターゲットＭＳＣと異なる時には、このＭＳＣサーバは、Ｐｒｅｐａｒｅ  Ｈａｎｄｏｖｅｒ  ＲｅｑｕｅｓｔメッセージをターゲットＭＳＣに送信する。
【００１７】
ステップ７  ターゲットＭＳＣは、ＣＳドメインの再配置された関連するリソースの割当を要求するＲｅｌｏｃａｔｉｏｎ  ＲｅｑｕｅｓｔメッセージをターゲットＲＮＳに送信する。ターゲットＲＮＳは、対応する応答メッセージを与える。
【００１８】
ステップ８  ＭＳＣサーバがターゲットＭＳＣと異なる時には、ターゲットＭＳＣは、Ｐｒｅｐａｒｅ  Ｈａｎｄｏｖｅｒ  ＲｅｓｐｏｎｓｅメッセージをこのＭＳＣサーバに送信する。
【００１９】
ステップ９  ターゲットＭＳＣとＭＧＷとの間の回線接続が確立される。
【００２０】
ステップ１０  ＭＳＣサーバは、セッション・ハンドオーバ手順をトリガし、ＩＮＶＩＴＥメッセージをＩＭＳに送信する。
【００２１】
ステップ１１  ターゲットＣＳアクセス・レグを使用するＳＤＰは、リモートＵＥを更新する（すなわち、ローカルＵＥとのＶｏＩＰセッションの確立の対応部分）。この時に、ＶｏＩＰ会話のダウンリンクは、ＣＳドメインにハンドオーバされる。
【００２２】
ステップ１２  ＥＰＣ  ＰＳアクセス・レグが、３ＧＰＰ  ＴＳ  ２３．２３７に従って解放される。
【００２３】
ステップ１３  ＭＳＣサーバは、ＳＲＶＣＣ  ＰＳ  ｔｏ  ＣＳ  ＲｅｓｐｏｎｓｅメッセージをソースＭＭＥに送信する。
【００２４】
ステップ１４  ソースＭＭＥは、Ｈａｎｄｏｖｅｒ  ＣｏｍｍａｎｄメッセージをソースＥ−ＵＴＲＡＮに送信する。
【００２５】
ステップ１５  ソースＥ−ＵＴＲＡＮは、Ｈａｎｄｏｖｅｒ  ｆｒｏｍ  Ｅ−ＵＴＲＡＮ  ＣｏｍｍａｎｄメッセージをＵＥに送信する。
【００２６】
ステップ１６  ＵＥは、ターゲットＵＴＲＡＮセルにハンドオーバする。
【００２７】
ステップ１７  ターゲットＲＮＳは、ＵＥのアタッチメントを検出する。ＵＥは、ターゲットＲＮＳ（具体的には、その中のＲＮＣ）を介してターゲットＭＳＣにＨａｎｄｏｖｅｒ  Ｃｏｍｐｌｅｔｅメッセージを送信する。ターゲットＭＳＣがＭＳＣサーバと同一ではない時には、ターゲットＭＳＣは、ＳＥＳ（Ｈａｎｄｏｖｅｒ  Ｃｏｍｐｌｅｔｅ）メッセージをＭＳＣサーバに送信する。
【００２８】
ステップ１８  ターゲットＲＮＳは、Ｒｅｌｏｃａｔｉｏｎ  ＣｏｍｐｌｅｔｅメッセージをターゲットＭＳＣに送信する。
【００２９】
ステップ１９  ターゲットＭＳＣおよびＭＳＣサーバが同一ではない時には、ターゲットＭＳＣは、ＳＥＳ（Ｈａｎｄｏｖｅｒ  Ｃｏｍｐｌｅｔｅ）メッセージをＭＳＣサーバに送信する。
【００３０】
ステップ２０  ３ＧＰＰ  ＴＳ  ２３．００９に従って、ターゲットＭＳＣは、ＭＳＣサーバとターゲットＭＳＣとの間の回線リンクが確立されたことを示すＡＮＳＷＥＲメッセージをＭＳＣサーバに送信する。
【００３１】
ステップ２１  ＭＳＣサーバは、ＳＲＶＣＣ  ＰＳ  ｔｏ  ＣＳ  Ｃｏｍｐｌｅｔｅ  ＮｏｔｉｆｉｃａｔｉｏｎメッセージをソースＭＭＥに送信し、したがって、ソースＭＭＥはこのメッセージに応答する。
【００３２】
ステップ２２  必要な場合には、ＭＳＣサーバは、ＭＡＰ  Ｕｐｄａｔｅ  ＬｏｃａｔｉｏｎメッセージをＨＳＳ／ＨＬＲに送信することができる。ＭＳＣサーバは、回線ドメイン付加価値サービス情報を得るためにこのステップを実行する。
【００３３】
しかし、３ＧＰＰ  ＴＳ  ２３．２１６で指定されるＳＲＶＣＣ解決策は、オーディオ・サービスのみに関し、ビデオ・サービスの連続性を維持するためのＰＳドメインからＣＳドメインへのビデオ・サービスのハンドオーバに関する解決策を与えない。
【００３４】
３ＧＰＰ  ＴＳ  ２３．２３７は、オーディオ・サービスとビデオ・サービスとの両方についてＰＳドメインからＣＳドメインへのハンドオーバの解決策を指定するが、この解決策は、Ｄｕａｌ  Ｒａｄｉｏ  ＵＥすなわち２タイプのアクセス・ネットワークを介して同時にデータの受信および送信が可能なＵＥのみをサポートし、Ｓｉｎｇｌｅ  Ｒａｄｉｏ  ＵＥをサポートしない、すなわち、ある瞬間に２タイプのアクセス・ネットワークのうちの１つだけを介してデータを送信しまたは受信することだけができるＵＥをサポートしない。
【００３５】
ますます競争的になる遠隔通信産業で、サービスは、より多様で人に優しくなりつつあり、Ｓｉｎｇｌｅ  Ｒａｄｉｏをサポートするビデオ会話連続性を提供できることへの要求が、徐々に高まっているが、この要求は、明らかに、さまざまな既存の解決策によって満たすことはできない。
【先行技術文献】
【非特許文献】
【００３６】
【非特許文献１】３ＧＰＰ  ＴＳ  ２３．２１６
【非特許文献２】３ＧＰＰ  ＴＳ  ２３．２３７
【非特許文献３】３ＧＰＰ  ＴＳ  ２３．００９
【発明の概要】
【発明が解決しようとする課題】
【００３７】
従来技術の上記の欠陥に対処するために、ビデオ会話をハンドオーバする方法および装置を提案する。
【課題を解決するための手段】
【００３８】
本発明の第１の態様によれば、パケット交換ドメインから回線交換ドメインへビデオ会話をハンドオーバする方法であって、ａ）パケット交換ドメイン内の基地局が、ユーザ端末から測定レポートを受信する時に、測定レポートおよびビデオ・ベアラの識別に従って、パケット交換ドメイン内の制御機器にハンドオーバ要求を送信するステップと、ｂ）パケット交換ドメイン内の制御機器が、パケット交換ドメイン内の基地局からハンドオーバ要求を受信する時に、ビデオ・ベアラの識別に従ってビデオ・ベアラを非ビデオ・ベアラから分離し、ハンドオーバがビデオ・ベアラに関するハンドオーバであることが示されるハンドオーバ要求を回線交換ドメイン内の制御機器に送信するステップと、ｃ）回線交換ドメイン内の制御機器が、パケット交換ドメイン内の制御機器からハンドオーバ要求を受信する時に、指定されたレートを有する通信リンクを予約することが示される再配置要求をターゲット無線ネットワーク制御装置に送信するステップと、ｄ）ユーザ端末が、ターゲット・ネットワークにハンドオーバする時に、指定されたレートを有する通信リンク上でビデオ会話のために要求される論理通信チャネルを確立するために回線交換ドメイン内の制御機器とネゴシエートするステップとを含む方法が提供される。
【００３９】
好ましくは、ステップｄ）は、ユーザ端末がターゲット無線ネットワーク制御装置にハンドオーバ完了メッセージを送信する時に、ユーザ端末が、指定されたレートを有する通信リンク上でビデオ会話のために要求される論理通信チャネルを確立するために回線交換ドメイン内の制御機器とのそのネゴシエーションを開始するステップをさらに含む。
【００４０】
好ましくは、ステップｄ）は、回線交換ドメイン内の制御機器がターゲット無線ネットワーク制御装置からハンドオーバ完了メッセージを受信する時に、回線交換ドメイン内の制御機器が、指定されたレートを有する通信リンク上でビデオ会話のために要求される論理通信チャネルを確立するためにユーザ端末とのそのネゴシエーションを開始するステップをさらに含む。
【００４１】
本発明の第２の態様によれば、基地局内の、パケット交換ドメインから回線交換ドメインへビデオ会話をハンドオーバする装置であって、ユーザ端末から測定レポートを受信する第１受信手段と、測定レポートおよびビデオ・ベアラの識別に従ってビデオ会話を回線交換ドメインにハンドオーバすると決定する決定手段と、パケット交換ドメイン内の制御機器にハンドオーバ要求を送信する第１送信手段とを含む装置が提供される。
【００４２】
本発明の第３の態様によれば、パケット交換ドメイン内の制御機器内の、ビデオ会話をパケット交換ドメインから回線交換ドメインにハンドオーバする装置であって、パケット交換ドメイン内の基地局からハンドオーバ要求を受信する第２受信手段と、ビデオ・ベアラの識別に従って非ビデオ・ベアラからビデオ・ベアラを分離する分離手段と、ハンドオーバがビデオ・ベアラに関するハンドオーバであることが示されるハンドオーバ要求を回線交換ドメイン内の制御機器に送信する第２送信手段とを含む装置が提供される。
【００４３】
本発明の第４の態様によれば、回線交換ドメイン内の制御機器内の、ビデオ会話をパケット交換ドメインから回線交換ドメインにハンドオーバする装置であって、パケット交換ドメイン内の制御機器からハンドオーバ要求を受信する第３受信手段と、指定されたレートを有する通信リンクを予約することが示される再配置要求をターゲット無線ネットワーク制御装置に送信する第３送信手段と、指定されたレートを有する通信リンク上でビデオ会話のために要求される論理通信チャネルを確立するためにユーザ端末とネゴシエートするネゴシエーティング手段とを含む装置が提供される。
【００４４】
本発明の方法および装置を用いると、モバイル・ネットワーク内でのＰＳドメインからＣＳドメインへのビデオ会話のハンドオーバを完了することができ、その連続性が維持され、これによって、ユーザにサービス多様化を与えることができる。
【００４５】
本発明の他の特徴、目的、および利益は、図面と共に非限定的な実施形態の次の詳細な説明を読むことによってより明白になる。
【図面の簡単な説明】
【００４６】
【図１】３ＧＰＰ  ＴＳ  ２３．２１６で指定されたＳＲＶＣＣのネットワーク・アーキテクチャを示す図である。
【図２】従来技術でのＥ−ＵＴＲＡＮからターゲットＵＴＲＡＮにハンドオーバされるＳＲＶＣＣの会話フローを示す概略図である。
【図３】本発明の実施形態による、Ｅ−ＵＴＲＡＮからターゲットＵＴＲＡＮにビデオ会話をハンドオーバするコール・フローを示す概略図である。
【図４】本発明の実施形態による、基地局内でビデオ会話をＥ−ＵＴＲＡＮからターゲットＵＴＲＡＮにハンドオーバする装置を示す図である。
【図５】本発明の実施形態による、ＭＭＥ内でビデオ会話をＥ−ＵＴＲＡＮからターゲットＵＴＲＡＮにハンドオーバする装置を示す図である。
【図６】本発明の実施形態による、ＭＳＣサーバ内でビデオ会話をＥ−ＵＴＲＡＮからターゲットＵＴＲＡＮにハンドオーバする装置を示す図である。
【発明を実施するための形態】
【００４７】
上の分析から、３ＧＰＰ  ＴＳ  ２３．２１６仕様によって提案されるＳＲＶＣＣ解決策が、オーディオ会話にはあてはまるがビデオ会話にはあてはまらないことがわかる。本発明は、同一のネットワーク・アーキテクチャを利用することと、ビデオ会話の特性に従って対応する変更を行うこととによって、３ＧＰＰ  ＴＳ  ２３．２１６の解決策を基礎とするＰＳドメインからＣＳドメインへビデオ会話をハンドオーバする方法を提案する。
【００４８】
ビデオ会話をサポートするために、ＵＥとＭＳＣサーバとの両方が、３Ｇー３２４Ｍの能力を有しなければならないことに留意されたい。３Ｇ−３２４Ｍは、モバイル・ネットワークの回線交換ドメイン上でビデオ会話サービスをサポートする、モバイル・ネットワーク内のプロトコル・クラスタ（ｐｒｏｔｏｃｏｌ  ｃｌｕｓｔｅｒ）である。
【００４９】
本発明の基本的な発想は、ビデオ会話が現在位置するパケット交換ドメインによってカバーされるネットワークの信号がよくないか使用不能になる時に、ソースＭＭＥおよびｅＮｏｄｅＢがビデオ会話の存在を検出する限り、ビデオ・ベアラに関する回線交換ドメインへのハンドオーバの手順が開始され、ハンドオーバ要求がＭＳＣサーバに送信されることである。回線交換ドメイン内の制御機器は、上記のハンドオーバ要求を受信した後に、ターゲット無線ネットワークへのリソースを要求し、ビデオ・ベアラに必要な通信リンクの割当を要求する。さらに、ローカルＵＥおよびＭＳＣサーバ／ＭＧＷは、ローカルＵＥがターゲット・ネットワークにハンドオーバした（この時に、ＵＥとＭＳＣサーバ／ＭＧＷとの間のビデオ・ベアラのために要求される通信リンクが既に確立されている）後に、ビデオ会話のための論理通信チャネルを確立するためにネゴシエーションを開始する。ネゴシエーションが成功した後に、ＭＳＣサーバ／ＭＧＷとＵＥとの間のビデオ電話サービスの伝送用の論理通信チャネルが確立される。この形で、ローカルＵＥは、ＭＧＷを介するリモートＵＥとのビデオ会話を継続することができる。
【００５０】
図３に、本発明の実施形態による、ＰＳドメインからＣＳドメインへビデオ会話をハンドオーバするコール・フロー・チャートを示す。このプロセスを、図２との比較によって下で詳細に説明する。
【００５１】
ステップ１  図２のステップ１と同一である。
【００５２】
ステップ２  図２のステップ２とはわずかに異なる。ソースＥ−ＵＴＲＡＮ（具体的には、その中のｅＮｏｄｅＢ）は、ＵＥの測定レポートおよびビデオ・ベアラの識別（ＱＣＩ＝２または７）に従って、ＵＴＲＡＮへのハンドオーバ手順をトリガすると判断する。すなわち、ソースＥ−ＵＴＲＡＮがハンドオーバ手順をトリガすることは、ビデオ・ベアラの識別に基づき、ビデオ・ベアラの識別がある限り、ハンドオーバ手順は、オーディオ・ベアラがあるかどうかにかかわりなくトリガされる。
【００５３】
ステップ３  図２のステップ３と同一である。
【００５４】
ステップ４  図２のステップ４とはわずかに異なる。ビデオ・ベアラのＱＣＩおよびＳＲＶＣＣ  ＨＯパラメータに基づいて、ソースＭＭＥは、ビデオ・ベアラを非ビデオ・ベアラから分離し、ビデオ・ベアラに関するＭＳＣサーバへのＰＳからＣＳへのハンドオーバ手順を開始する。
【００５５】
ステップ５  このステップは、図２のステップ５とはわずかに異なる。図２のパラメータのほかに、ソースＭＭＥによってＭＳＣサーバに送信されるＳＲＶＣＣ  ＰＳ  ｔｏ  ＣＳ  Ｒｅｑｕｅｓｔメッセージは、このハンドオーバがビデオ・ベアラに関することをも示さなければならず、たとえば、このハンドオーバがビデオ・ハンドオーバであることを、たとえばＳＲＶＣＣ  ＰＳ  ｔｏ  ＣＳ  Ｒｅｑｕｅｓｔメッセージ内のＰｒｉｖａｔｅ  ｅｘｔｅｎｓｉｏｎパラメータのＰｒｏｐｒｉｅｔａｒｙ値を特定の値（１０進数の１００など）としてセットすることによってＭＳＣサーバに示す。
【００５６】
ステップ６  このステップは、図２のステップ６とはわずかに異なる。ＭＳＣサーバによってターゲットＭＳＣに送信されるＰｒｅｐａｒｅ  Ｈａｎｄｏｖｅｒ  Ｒｅｑｕｅｓｔメッセージは、このハンドオーバがビデオ・ベアラに関することを示さなければならず、たとえば、このハンドオーバがビデオ・ハンドオーバであることを、たとえばＰｒｅｐａｒｅ  Ｈａｎｄｏｖｅｒ  Ｒｅｑｕｅｓｔメッセージ内のＲａｄｉｏ  Ｒｅｓｏｕｒｃｅ  Ｉｎｆｏｒｍａｔｉｏｎパラメータのｓｐｅｅｃｈ／ｄａｔａ  ｉｎｄｉｃａｔｏｒパラメータを特定の値（２進数の１１１０など）としてセットすることによってターゲットＭＳＣに示す。
【００５７】
ステップ７  図２のステップ７とはわずかに異なる。ターゲットＭＳによってターゲットＲＮＣに送信されるＲｅｌｏｃａｔｉｏｎ  Ｒｅｑｕｅｓｔメッセージは、ビデオ会話用に必要な６４ｋｂｐｓ（ｂｐｓ、ビット毎秒）通信リンクがビデオ会話に割り当てられなければならないことを示さなければならない。このステップは、主に、一方ではターゲットＲＮＣからターゲットＭＳＣへの通信リンクを確立するため、他方ではターゲットＲＮＣからＵＥへの間の通信リンクのためにターゲットＲＮＣの側でリソースを準備するために、ターゲットＲＮＣが対応するリソースを割り当てるためのものであるが、ターゲットＲＮＣとＵＥとの間の通信リンクは、ステップ１７の完全な実行までは、まだ確立されていない。具体的には、Ｒｅｌｏｃａｔｉｏｎ  Ｒｅｑｕｅｓｔメッセージ内の「ＲＡＢｓ  Ｔｏ  Ｂｅ  Ｓｅｔｕｐ  Ｌｉｓｔ」パラメータのリスト内の「ＲＡＢｓ  Ｔｏ  Ｂｅ  Ｓｅｔｕｐ  Ｉｔｅｍ  ＩＥｓ」内の「ＲＡＢ  Ｐａｒａｍｅｔｅｒｓ」パラメータに含まれる「Ｇｕａｒａｎｔｅｅｄ  Ｂｉｔ  Ｒａｔｅ」パラメータに６４ｋがセットされる。
【００５８】
ステップ８からステップ１５まで  図２のステップ８からステップ１５までと同一である。
【００５９】
ステップ１６  図２のステップ１６と同一である。ステップ７で、ローカルＵＥがＵＴＲＡＮターゲット・セルにハンドオーバする前に、ターゲットＲＮＣが、ビデオ会話用に４６ｋｂｐｓ通信リンクを割り当てたことに留意されたい。
【００６０】
ステップ１７からステップ２０まで  図２のステップ１７からステップ２０までと同一である。
【００６１】
ステップ２１  図２と比較して、このステップは、本発明によって新たに追加されたステップである。フローはここで進行し、ＵＥとＭＳＣサーバとの間のビデオ会話用の６４ｋｂｐｓ物理通信リンクは、既に確立されている。このステップでは、ＵＥとＭＳＣサーバとの間のエンドツーエンド・ネゴシエーションが行われ、このネゴシエーションでは、ＵＥおよびＭＧＷによって使用されるコーデック・フォーマットおよび類似物を含む、ビデオ会話用の６４ｋｂｐｓ通信リンク上で論理通信チャネルをどのように確立すべきかが議論される。ネゴシエートされるプロトコルを、３Ｇ−３２４Ｍプロトコル・クラスタ内のＨ．２４５プロトコルとすることができる。本明細書では詳細に説明されない、機能ネゴシエーション手順、マスタ−スレーブ決定手順、オープン論理通信チャネル手順、オープン多重化手順を含む特定のネゴシエーション手順を、Ｈ．２４５仕様に見出すことができる。
【００６２】
ステップ２１の実行に関する２つの機会がある可能性がある。一方は、ＭＳＣサーバがステップ２０またはステップ１８の後にＵＥとのネゴシエーションを開始することであり、ここで、ＭＳＣサーバがターゲットＭＳＣと同一である時には、ステップ１８は、ＭＳＣサーバが、ターゲット無線ネットワークにハンドオーバするＵＥのハンドオーバの完了を示すＲｅｌｏｃａｔｉｏｎ  ＣｏｍｐｌｅｔｅメッセージをターゲットＭＳＣから受信することである。ＭＳＣサーバがターゲットＭＳＣと同一ではない時には、ステップ２０を、ターゲットＭＳＣを介するターゲット無線ネットワークへのＵＥのハンドオーバを示すハンドオーバ完了メッセージをＭＳＣサーバがターゲットＲＮＣから受信する時と考えることもできる。他方の機会は、ＵＥがステップ１７の後にＭＳＣサーバとのネゴシエーションを開始することであり、ここで、ステップ１７は、ＵＥが、ターゲット無線ネットワークにハンドオーバするＵＥのハンドオーバの完了を示すＨａｎｄｏｖｅｒ  ＣｏｍｐｌｅｔｅメッセージをターゲットＲＮＳに送信することである。
【００６３】
ステップ２２からステップ２３まで  図２のステップ２１からステップ２２までと同一である。
【００６４】
本発明によって提案されるＰＳドメインからＣＳドメインにビデオ会話をハンドオーバする方法が、次の点で３ＧＰＰ  ＴＳ  ２３．２１６によって与えられる既存のＳＲＶＣＣ解決策と異なることがわかる。
Ａ）ｅＮｏｄｅＢがＵＥから測定レポートを受信する時に、ｅＮｏｄｅＢは、測定レポートおよびたとえばＱＣＩによるビデオ・ベアラの識別に従ってビデオ・ベアラを判定し、Ｈａｎｄｏｖｅｒ  Ｒｅｑｕｉｒｅメッセージなどのハンドオーバ要求をソースＭＭＥに送信する。すなわち、図３に示されたステップ２および３。
Ｂ）ソースＭＭＥがｅＮｏｄｅＢからハンドオーバ要求を受信する時に、ソースＭＭＥは、ビデオ・ベアラの識別に従って非ビデオ・ベアラからビデオ・ベアラを分離し、ＰＳ  ｔｏ  ＣＳ  Ｒｅｑｕｅｓｔメッセージなど、ハンドオーバがビデオ・ベアラに関するハンドオーバであることが示されるハンドオーバ要求をＭＳＣサーバに送信する。すなわち、図３に示されたステップ４および５。
Ｃ）ＭＳＣサーバがソースＭＭＥからハンドオーバ要求を受信する時に、ＭＳＣサーバは、Ｒｅｌｏｃａｔｉｏｎ  Ｒｅｑｕｅｓｔメッセージなど、ビデオ会話用の６４ｋｂｐｓ通信リンクを予約することが示される再配置要求をターゲットＲＮＣに送信する。ＭＳＣサーバがターゲットＭＳＣとは異なる状況では、ＭＳＣサーバは、図３のステップ６および７に示されているように、ターゲットＭＳＣを介してターゲットＲＮＣに再配置要求を送信する。ＭＳＣサーバがターゲットＭＳＣと同一である場合には、ＭＳＣサーバは、図３のステップ７に示されているように、ターゲットＲＮＣに直接に再配置要求を送信する。
Ｄ）ＵＥがターゲットＵＴＲＡＮにハンドオーバした後に、ＵＥは、確立された６４ｋｂｐｓ通信リンク上でビデオ会話用の論理通信チャネルをどのようにして確立すべきかを議論するためにＭＳＣサーバとネゴシエートする。ネゴシエーションのプロトコルを、Ｈ．２４５プロトコルとすることができる。すなわち、図３に示されたステップ２１。そのようなネゴシエーションを、ＵＥによって開始することができ、あるいは、これをＭＳＣサーバによって開始することもできる。ＵＥによって開始される場合には、ネゴシエーションは、ＵＥがハンドオーバ完了メッセージ（ここで言及されるハンドオーバは、ＵＥがターゲット無線ネットワークにハンドオーバするハンドオーバを指す）をターゲットＲＮＣに送信した後に開始される、すなわち、ステップ２１は、図３に示されているようにステップ１７の後に実行される。ＭＳＣサーバによって開始される場合に、ネゴシエーションは、ＭＳＣサーバがハンドオーバ完了メッセージ（ここで言及されるハンドオーバは、ＵＥがターゲット無線ネットワークにハンドオーバするハンドオーバを指す）をターゲットＲＮＣから受信した後に開始され、ＭＳＣサーバとターゲットＭＳＣとが同一である場合には、ネゴシエーションは、ＭＳＣサーバがハンドオーバ完了メッセージ（ここで言及されるハンドオーバは、ＵＥがターゲット無線ネットワークにハンドオーバするハンドオーバを指す）をターゲットＲＮＣから直接に受信した後に開始され、すなわち、ステップ２１は、図３に示されているようにステップ１８の後に実行され、ＭＳＣサーバとターゲットＭＳＣとが同一ではない場合には、ネゴシエーションは、ＭＳＣサーバがハンドオーバ完了メッセージ（ここで言及されるハンドオーバは、ＵＥがターゲット無線ネットワークにハンドオーバするハンドオーバを指す）をターゲットＲＮＣからターゲットＭＳＣを介して受信した後に開始され、すなわち、ステップ２１は、図３に示されているようにステップ２０の後に実行される。
【００６５】
図４に、本発明の実施形態による、基地局内でビデオ会話をＥ−ＵＴＲＡＮからターゲットＵＴＲＡＮにハンドオーバする装置を示す。ここで、第１受信手段４０１は、ＵＥから測定レポートを受信し、その後、決定手段４０２は、測定レポートおよびビデオ・ベアラのＱＣＩに従って現在のビデオ会話をＣＳドメインにハンドオーバすると決定し、その後、第１送信手段４０３は、図３のステップ３に示されたＨａｎｄｏｖｅｒ  Ｒｅｑｕｉｒｅｄメッセージなどのハンドオーバ要求をソースＭＭＥに送信するためにトリガされる。
【００６６】
図５に、本発明の実施形態による、ＭＭＥ内でビデオ会話をＥ−ＵＴＲＡＮからターゲットＵＴＲＡＮにハンドオーバする装置を示す。ここで、第２受信手段５０１は、ｅＮｏｄｅＢからハンドオーバ要求を受信し、その後、分離手段５０２は、ビデオ・ベアラのＱＣＩに従って非ビデオ・ベアラ（１つまたは複数）からビデオ・ベアラを分離し、その後、第２送信手段５０３は、ハンドオーバがビデオ・ベアラに関するハンドオーバであることが示される、図３のステップ５に示されたＰＳ  ｔｏ  ＣＳ  Ｒｅｑｕｅｓｔメッセージなどのハンドオーバ要求をＭＳＣサーバに送信する。
【００６７】
図６に、本発明の実施形態による、ＭＳＣサーバ内でビデオ会話をＥ−ＵＴＲＡＮからターゲットＵＴＲＡＮにハンドオーバする装置を示す。ここで、第３受信手段６０１は、ソースＭＭＥからハンドオーバ要求を受信し、その後、第３送信手段６０３は、図３のステップ７に示されたＲｅｌｏｃａｔｉｏｎ  Ｒｅｑｕｅｓｔメッセージなどの、リソースの割当を要求する再配置要求をターゲットＲＮＣに送信し、ここで、ビデオ会話用に必ず予約される６４ｋｂｐｓ通信リンクが示され、その後、ＵＥとネゴシエートするネゴシエーティング手段６０２は、６４ｋｂｐｓ通信リンク上でビデオ会話のために要求される論理通信チャネルをどのように確立するのかを議論する。
【００６８】
本発明の基本的な発想が、ＭＭＥ、ＭＳＣサーバ、ＭＧＷ、その他などのエンティティの使用と共に３ＧＰＰ  ＴＳ  ２３．２１６のアプリケーション環境で説明されるが、本発明の応用は、これに限定されない。たとえば、本発明を、３ＧＰＰ  ＴＳ  ２３．２３７、２３．２９２などに適用することもできる。実際に、パケット交換ドメイン内のすべてのエンティティは、ＶｏＩＰ呼に対する対応する管理／制御を提供できる限り、上記のＭＭＥとして働くことができ、回線交換ドメイン内のすべてのエンティティは、媒体を管理し／扱うＭＧＷ、ＭＳＣサーバ、または類似物など、ＶｏＩＰ呼に対する対応する管理／制御を提供できる限り、回線交換ドメイン内の対応する制御ユニットとして働くことができる。ユーザによって行われる呼をアンカリングできるすべてのエンティティは、上記のＳＣＣ  ＡＳとして働くことができる。
【００６９】
本発明の実施形態を、上で説明した。本発明が、上の特定の実施形態に限定されるのではなく、当業者が、添付の特許請求の範囲の中でさまざまな変更または修正を行うことができることに留意されたい。
【図１】
0005620505.tif 000002
【図２】
0005620505.tif 000003
【図３】
0005620505.tif 000004
【図４】
0005620505.tif 000005
【図５】
0005620505.tif 000006
【図６】
0005620505.tif 000007