JP2017147755A - 通信システムにおけるハンドオーバー要求の取り扱い - Google Patents

Abstract

【課題】通信システムにおけるハンドオーバー要求の取り扱いを改善する。
【解決手段】回路交換（ＣＳ）ベアラ予約は成功であるが、移動交換センター（ＭＳＣ）サーバーにより行われるパケット交換（ＰＳ）からＣＳへのボイスメディアスイッチングが失敗となる状態が生じ得る。ある実施形態は、そのような状態から回復するためのシステム、装置及び方法を提供する。例えば、方法は、ユーザ装置のセッション転送を開始するためのネットワークエレメントからの要求に応答してユーザ装置のセッション転送が可能であるかどうか決定し、及びセッション転送が可能でないと決定されたときに、転送が可能でないとの一般的指示又は特定の指示を要求側ネットワークエレメントに報告することを含む。
【選択図】図４

Description

本発明は、通信システムにおけるハンドオーバー要求の取り扱いに関する。

単一無線ボイスコール継続手順の間に、回路交換（circuit switched, ＣＳ）ベアラ予約は成功であるが、移動交換センター（mobile switching center, ＭＳＣ）サーバーにより行われるパケット交換（packet switched, ＰＳ）からＣＳへのボイスメディアスイッチングが失敗となる状態が生じ得る。

図１は、進化型ユニバーサル地上無線アクセスネットワーク（evolved universal terrestrial radio access network, Ｅ−ＵＴＲＡＮ）から、デュアル転送モード（dual transfer mode, ＤＴＭ）サポートのない移動通信用グローバルシステム（ＧＳＭ）ｅｄｇｅ無線アクセスネットワーク（global system for mobile communications (GSM) edge radio access network, ＧＥＲＡＮ）への全体的な単一無線ボイスコール継続（single radio voice call continuity, ＳＲＶＣＣ）手順を示している。この手順の説明は、参考としてここにそのまま援用するＴＳ２３．２１６ｖ１１．２．０に見られる。

図１に示すように、Ｓ１において、測定レポート（measurement reports）がユーザ装置（ＵＥ）からソースＥ−ＵＴＲＡＮへ送信される。次いで、Ｓ２において、ソースＥ−ＵＴＲＡＮは、ハンドオーバー（ＨＯ）の判断を行う。Ｓ３において、Ｅ−ＵＴＲＡＮは、ハンドオーバーが要求されたことを指示するメッセージをソース移動管理エンティティ（mobility management entity, ＭＭＥ）へ送信する。Ｓ４において、ソース移動管理エンティティは、ベアラ分割を遂行する。次いで、Ｓ５において、ソース移動管理エンティティは、パケット交換（ＰＳ）から回路交換（ＣＳ）が要求されることを指示するメッセージを移動交換センター（ＭＳＣ）サーバー／移動ゲートウェイ（ＭＧＷ）へ送信する。移動交換センターサーバー／ＭＧＷは、Ｓ６において、ハンドオーバーの準備が要求されることを指示するメッセージをターゲット移動交換センターへ送信する。Ｓ７において、ターゲット移動交換センター及びターゲットベースステーションサーバー（ＢＳＳ）がハンドオーバー要求及び確認（ＡＣＫ）を交換する。

次いで、Ｓ８において、移動交換センターサーバー／ＭＧＷは、ターゲット移動交換サンターからのハンドオーバー準備に関する応答を受け取る。Ｓ９において、移動交換センターサーバー／ＭＧＷは、ターゲット移動交換センターとの回路を確立する。次いで、Ｓ１０において、インターネットプロトコル（ＩＰ）マルチメディアサブシステム（ＩＭＳ）との通信によってセッション転送が開始される。Ｓ１１において、ＩＰマルチメディアサブシステムは、セッション転送を行い、そしてリモートエンドを更新する。次いで、Ｓ１２において、ＩＰマルチメディアサブシステムは、ＩＰマルチメディアサブシステムのアクセスレッグを解除する。

一方、Ｓ１３において、移動交換センターサーバー／ＭＧＷは、パケット交換から回路交換の応答をソース移動管理エンティティへ送信し、該エンティティは、次いで、Ｓ１４において、ソースＥ−ＵＴＲＡＮへハンドオーバーコマンドを送信する。Ｓ１５において、ソースＥ−ＵＴＲＡＮは、Ｅ−ＵＴＲＡＮからハンドオーバーするためのコマンドをユーザ装置へ送信する。次いで、Ｓ１６において、ユーザ装置は、ＧＥＲＡＮに同調する。これに続いて、Ｓ１６におけるハンドオーバー検出、Ｅ−ＵＴＲＡＮ側の停止（Ｓ１８、Ｓ１８ａ、Ｓ１８ｂ）、ハンドオーバー完了（Ｓ１９）、そして種々の解除、更新、及び再割り当てステップ（Ｓ２０−Ｓ２４）がある。

従来、Ｓ１０の結果は、Ｓ１３に何ら影響しない。回路交換無線ベアラ予約がＳ８において成功となるや否や、ＭＳＳは、Ｓ１３においてＰＳからＣＳの応答を返送する。これは、Ｓ１６において、長期進化（ＬＴＥ）から回路交換へ無線ハンドオーバー手順をトリガーする。

Ｓ１０及び／又はＳ１１においてＩＰマルチメディアサブシステムのセッション転送手順が失敗となる理由は、幾つかある。１つの理由は、ホーム加入者サーバー（ＨＳＳ）が移動管理エンティティにおけるＳＲ−ＶＣＣ（ＳＴＮ−ＳＲ）のセッション転送番号の更新に失敗することであり、或いは他の理由としては、移動管理エンティティにおける単一無線ボイスコール継続性のセッション転送番号が誤っていることである。ｅＳＲＶＣＣを伴うＲ１０において、単一無線ボイスコール継続性のセッション転送番号は、セッションの支えとなるアクセス転送コントロールファンクション（ＡＴＣＦ）を指す（サービング公衆地上移動ネットワーク（ＰＬＭＮ）において）。ＨＳＳは、単一無線ボイスコール継続性のセッション転送番号がアクセス転送コントロールファンクションを指すように移動管理エンティティを更新する。アクセス転送コントロールファンクションが変更され、例えば、ユーザ装置が新たな公衆地上移動ネットワークへローミングする場合には、ＨＳＳは、従来、単一無線ボイスコール継続性の新たなセッション転送番号で現在移動管理エンティティを更新する必要がある。移動管理エンティティへのＨＳＳ更新が失敗となる理由は、シグナリングリンクの混雑、悪いネットワーク構成、等の過渡的なネットワーク問題を含む。

図２は、アクセス転送コントロールファンクションを使用したｅＳＲＶＣＣのセッションイニシエーションプロトコル（ＳＩＰ）レベル態様を示す。図２に示すように、メディア経路が設定された後、Ｓ１において、ユーザ装置と、無線アクセスネットワーク（ＲＡＮ）と、ＭＭＥ／ＳＧＳＮと、３ＧＰＰ ＴＳ２３．２１６（参考としてここにそのまま援用される）に規定された移動交換センターとの間に相互作用がある間に、セッションイニシエーションプロトコルＩＮＶＩＴＥ（Ｓ２）がアクセス転送コントロールファンクションへ送信される。アクセス転送コントロールファンクションは、コンフィギュレーションメッセージをアクセス転送ゲートウェイ（ＡＴＧＷ）へ送信し（Ｓ３）、そしてメッセージの確認を受信する（Ｓ４）。アクセス転送コントロールファンクションは、セッションイニシエーションプロトコルＩＮＶＩＴＥへ応答を送信する（Ｓ５）。その後、新たなメディア経路が設定される。次いで、アクセス転送コントロールファンクションは、アクセス転送更新メッセージをサービス集中及び継続アプリケーションサーバー（ＳＣＣ−ＡＳ）／サービングコールセッションコントロールファンクション（Ｓ−ＣＳＣＦ）へ送信し（Ｓ６）、そしてセッション状態情報（ＳＳＩ）を含む応答を受信する（Ｓ７）。次いで、アクセス転送コントロールファンクションは、ＳＳＩを移動交換センターサーバーへ送信する（Ｓ８）。

単一無線ボイスコール継続性のセッション転送番号の更新に失敗した場合には、単一無線ボイスコール継続性がもはや働かなくてもよいし働いてもよい。移動管理エンティティに記憶された単一無線ボイスコール継続性のセッション転送番号がサービス集中及び継続アプリケーションサーバー（ＳＣＣ−ＡＳ）（ホームＰＬＭＮ（Ｈ−ＰＬＭＮ）における）を指すものである場合には、単一無線ボイスコール継続性は、ｅＳＲＶＣＣ機能をもたずに、Ｒ８／９について定義されたように働き続ける。アクセス転送コントロールファンクションを指す単一無線ボイスコール継続性のセッション転送番号が以前の／古い訪問先ネットワークからのものである場合には、単一無線ボイスコール継続性もｅＳＲＶＣＣも働かない。単一無線ボイスコール継続性もｅＳＲＶＣＣも働かない理由は、ＭＳＳからのＩＮＶＩＴＥ（Ｓ２）が、そのようなシナリオでは、ユーザのための契約情報をもたないアクセス転送コントロールファンクションに向かって送信されるからである。その最終結果として、ユーザ装置は、ＭＳＳにおいて回路交換側へハンドオーバーされるが、ＩＮＶＩＴＥ（Ｓ２）により開始されたＩＰマルチメディアサブシステムから回路交換ドメインへのアクセス転送は成功しない。ＭＳＳは、従来、この点において回路交換コールを解除するだけであり、ユーザ装置は、ＬＴＥへ戻る。この種の実現不能な単一無線ボイスコール継続性は、このユーザ装置に対して生じ続ける。というのは、単一無線ボイスコール継続性のセッション転送が無効であるとのアイデアを移動管理エンティティがもたないからである。

従って、従来は、この状態を取り扱うための手段がない。

本発明の第１の態様によれば、ハンドオーバー要求を取り扱う方法において、
ハンドオーバー要求を受け取り、
ハンドオーバーを開始し、
転送失敗の通知を受け取り、及び
転送失敗の通知が受け取られる前、及び転送失敗の通知が受け取られた後の少なくとも一方に、ハンドオーバー要求に対してハンドオーバー失敗を指示する応答を伝送する、
ことを含む方法が提供される。

本発明の第２の態様によれば、ハンドオーバーを要求する方法において、
開始すべきハンドオーバーの要求を伝送し、
ハンドオーバー要求に対してハンドオーバーの失敗を指示する応答を受け取る、
ことを含み、その応答は、転送失敗の通知が受け取られる前、及び転送失敗の通知が受け取られた後の少なくとも一方に、伝送される、方法が提供される。

好ましくは、ハンドオーバー要求は、移動管理エンティティにより送られる。移動管理エンティティは、例えば、ＬＴＥネットワークでは、ＭＭＥである。これは、ＳＧＳＮでもよい。又、これは、ＭＭＥファンクション及びＳＧＳＮファンクションの両方を含むエンティティでもよい。移動管理エンティティは、ハンドオーバーを開始する。移動管理エンティティは、コアネットワークへ転送要求を伝送することによりこれを行う。コアネットワークは、コアネットワークサブシステムである。コアネットワークは、メディア配信エンティティである。メディア配信エンティティは、コール及び／又はマルチメディアのようなボイスメディアを配信することができる。それは、ＩＰマルチメディアサブシステムのようなコールコントロールプラットホームでもよい。

好ましくは、ハンドオーバー要求は、スイッチングエンティティにより受け取られる。スイッチングエンティティは、移動交換センター、例えば、ＭＳＳのような移動交換センターサーバーである。これは、移動ゲートウェイである。これは、スイッチングファンクション及びゲートウェイファンクションの両方を含むエンティティである。

好ましくは、転送失敗の通知は、コアネットワークにより送られる。その通知は、スイッチングエンティティに受け取られる。

好ましくは、応答は、スイッチングエンティティにより伝送される。その応答は、移動管理エンティティへ送られる。

好ましくは、転送失敗は、セッションのハンドオーバーの失敗である。セッションは、メディアセッションである。それは、ボイスメディアセッションである。それは、マルチメディアセッションである。それは、ある無線アクセステクノロジータイプから別の無線アクセステクノロジータイプへハンドオーバーされる。それは、ある無線リソースタイプに基づいて行われるセッションを別の無線リソースタイプへハンドオーバーする。例えば、それは、パケット交換セッションであるセッションを回路交換セッションであるセッションへハンドオーバーすることを含む。

要求は、無線リソース予約に対するものである。要求は、回路交換無線リソース予約に対するものでもよい。又、ＳＲＶＣＣに対するものでもよい。

セッションは、第１ユーザターミナルと第２ユーザターミナルとの間で行われる。

ハンドオーバーは、ユーザエンティティの１つがソースＲＡＮではなくターゲット無線アクセスネットワーク（ＲＡＮ）によるサービスを受けねばならないことを指示する測定レポートによりトリガーされる。ハンドオーバーの必要性は、ソースＲＡＮにおいて決定される。ソースＲＡＮは、移動管理エンティティへのハンドオーバーの必要性を指示する。これは、ソース移動管理エンティティであると考えられる。ソース移動管理エンティティは、ソーススイッチングエンティティへのハンドオーバーの必要性を指示する。これは、ＭＳＣサーバー及び／又はメディアゲートウェイである。ソーススイッチングエンティティは、スイッチングエンティティにハンドオーバー要求を伝送する。これは、ターゲットスイッチングエンティティと考えられる。このハンドオーバー要求を受け取るのに続いて、例えば、ターゲットスイッチングエンティティとターゲットＲＡＮとの間で無線アクセスネットワークとのベアラレベルハンドオーバーを開始する。ハンドオーバーの開始は、ターゲットＲＡＮとのベアラレベルハンドオーバーの確立に続く。本発明のある実施形態では、ソースＲＡＮからターゲットＲＡＮへのハンドオーバーは、ソースＲＡＴからターゲットＲＡＴへのハンドオーバーも意味する。

このように、本発明によれば、ハンドオーバーは、２つの態様を有することが考えられる。第１の態様では、ハンドオーバーが無線リソースレベルで生じ、そして第２の態様では、セッションが転送される。

ハンドオーバー要求に対する応答の伝送が、転送失敗の通知を受け取った後に行われるケースでは、ハンドオーバー要求に対する応答は、転送を実行できないことを示す否定応答（negative response）である。この否定応答は、スイッチングエンティティにより伝送される。これは、移動管理エンティティへ送られる。この否定応答は、拒絶の原因を含む。拒絶の原因は、セッション転送レッグ確立エラー（Session Transfer leg establishment error）である。

否定応答に続いて、転送失敗メッセージが送られる。これは、移動管理エンティティにより送られる。これは、アクセスネットワークのネットワークエレメントへ送られる。これは、ハンドオーバーを行う手順をスタートしたネットワークエレメントへ送られる。

拒絶の原因を送るのに続いて、ターゲットＲＡＴをクリアするオペレーションが行われる。これは、予約されたリソースがもはや必要でないためにそれを解除することをターゲットＲＡＮに通知することを含む。

セッションに対してセッションハンドオーバーが使用できないとの通知が生じることがある。この通知は、移動管理エンティティにより与えられる。これは、ＲＡＮへ送られる。又、これは、ソースＲＡＮへ送られてもよい。

ハンドオーバー要求に対する応答の伝送が、転送失敗の通知を受け取る前に行われるケースでは、ハンドオーバー要求に対する応答は、ハンドオーバーを実行できることを示す肯定応答である。この肯定応答に続いて、ハンドオーバーコマンドメッセージが送信される。これは、移動管理エンティティにより送られる。これは、アクセスネットワークのネットワークエレメントによるサービスを受ける移動ターミナルのようなユーザ装置へ送られる。ネットワークエレメントは、ハンドオーバーを実行する手順をスタートする。ハンドオーバーコマンドメッセージは、別のＲＡＴテクノロジーを使用してユーザ装置を切り換えさせる。これは、回路交換ＲＡＴである。

肯定メッセージは、首尾良い無線リソース予約を指示する。例えば、ターゲット無線リソースが首尾良く予約されたことを指示する。

転送失敗の通知を受け取るのに続いて、ハンドオーバー要求に対する付加的な応答が送られる。これは、転送を実行できないことを指示する否定応答である。否定応答は、実際に、応答メッセージを更新する更新メッセージであると考えられる。

拒絶の原因を受け取るのに続いて、コール解除インストラクションが与えられる。これは、スイッチングエンティティによって与えられる。これは、予約された無線接続及び／又は無線リソース、例えば、ＲＡＮ及びユーザ装置を無線レベルで接続するものをＲＡＮが解除するように命令する。そのインストラクションは、スイッチングエンティティにより与えられる。それは、ＲＡＮへ送られる。これは、転送完了メッセージが送られた後に行われる。

それ故、ハンドオーバーの要求に対する応答の伝送が、転送失敗の通知を受け取る前に行われるケースでは、肯定応答及び否定応答の両方が送られることが理解されよう。否定応答は、肯定応答により誤って指示された状態を正しく識別することができる。否定応答は、エラーの原因を含むハンドオーバー完了メッセージである。

否定応答は、スイッチングエンティティによって送られる。これは、移動管理エンティティへ送られる。否定応答は、拒絶の原因を含む。拒絶の原因は、セッション転送レッグ確立エラーである。

転送失敗の通知は、セッション転送手順の間に受け取られる。失敗は、無効のＳＴＮ−ＳＲ、一時的失敗、又は別の問題によるものである。無効のＳＴＮ−ＳＲは、永久的エラーの一例である。これは、４０４ユーザ見つからずの指示によって示される。

いずれの場合にも、ハンドオーバー要求に対する応答は、転送失敗の通知が受け取られる前、又は転送失敗の通知が受け取られた後のいずれかに送られるが、特定の場合には、ハンドオーバーを開始するメッセージの送信に続いて、ハンドオーバー要求に対する応答の伝送が転送失敗の通知を受け取る前後の両方に行われる可能性もある。この可能性は、実際に行われるシーケンスに基づいて、ハンドオーバー要求に対する応答が最初に送られるか、又は転送失敗の通知が最初に送られるときに、実現される。

否定応答に続いて、更なるハンドオーバーの試みを防止する１つ又は多数のステップがとられる。これは、特定のセッションに対する更なるハンドオーバーの試みを防止する。これは、特定のユーザ装置に対する更なるハンドオーバーの試みを防止する。又、これは、移動管理エンティティにおいて削除されるパラメータ又は値を含む。１つの実施形態において、これは、セッション転送番号である。これは、単一無線ボイスコール継続性に対して移動管理エンティティに記憶されている。他のセッションに対して更なるハンドオーバーの試みを防止することができる。これは、例えば、加入者データベースのような別のエンティティによって更新されるべきセッション転送番号に対して、失敗を生じた問題を解決するための矯正的アクションを取るまで適用される。そのアクションは、セッション転送動作の考えられる値を“ＮＯ”にセットすることを含む。その設定は、移動管理エンティティにおいて行われる。それとは別に又はそれに加えて、その設定は、ＲＡＮエンティティにおいて行われてもよい。

１つの実施形態において、転送失敗メッセージは、セッションに対する特定のハンドオーバータイプが可能でないことを示す情報エレメントを含む。この情報エレメントは、移動管理エンティティによりセットされる。これは、セッションのハンドオーバーが再びトリガーしないことを保証するためにＲＡＮエンティティに与えられる。別の可能性として、移動管理エンティティは、転送失敗メッセージを伝送した直後にコンテキスト変更要求メッセージをＲＡＮエンティティへ伝送して、特定のハンドオーバータイプが可能でないことを更新する。

本発明の第３の態様によれば、
ハンドオーバー要求を受け取る受信器と、
ハンドオーバーを開始するプロセッサと、
を備え、前記受信器は、転送失敗の通知を受け取り、更に、
転送失敗の通知が受け取られる前、及び転送失敗の通知が受け取られた後の少なくとも一方に、ハンドオーバー要求に対してハンドオーバー失敗を指示する応答を伝送する送信器を備えた、ハンドオーバー取り扱いネットワークエンティティが提供される。

本発明の第４の態様によれば、
開始すべきハンドオーバーの要求を伝送する送信器と、
そのハンドオーバー要求に対してハンドオーバーの失敗を指示する応答を受け取る受信器と、
を備え、前記応答は、転送失敗の通知が受け取られる前、及び転送失敗の通知が受け取られた後の少なくとも一方に、伝送される、ハンドオーバー要求ネットワークエンティティが提供される。

本発明の第５の態様によれば、ハンドオーバー要求ネットワークエンティティ及びハンドオーバー取り扱いネットワークエンティティを備えたシステムにおいて、そのハンドオーバー要求ネットワークエンティティは、
開始すべきハンドオーバーの要求を伝送する送信器と、
そのハンドオーバー要求に対してハンドオーバーの失敗を指示する応答を受け取る受信器と、
を備え、前記応答は、転送失敗の通知が受け取られる前、及び転送失敗の通知が受け取られた後の少なくとも一方に、伝送されるものであり、更に、そのハンドオーバー取り扱いネットワークエンティティは、
ハンドオーバー要求を受け取る受信器と、
ハンドオーバーを開始するプロセッサと、
を備え、前記受信器は、転送失敗の通知を受け取り、更に、
転送失敗の通知が受け取られる前、及び転送失敗の通知が受け取られた後の少なくとも一方に、ハンドオーバー要求に対してハンドオーバー失敗を指示する応答を伝送する送信器を備えた、システムが提供される。

本発明の第６の態様によれば、ハンドオーバー要求を取り扱う方法において、
ハンドオーバー要求を受け取り、
ハンドオーバーを開始し、
転送失敗の通知を受け取り、及び
転送失敗の通知が受け取られる前、及び転送失敗の通知が受け取られた後の少なくとも一方に、ハンドオーバー要求に対してハンドオーバー失敗を指示する応答を伝送する、
ことを含む方法が提供される。

本発明の第７の態様によれば、ハンドオーバー要求を取り扱うインストラクションをプロセッサが実行するのをコントロールするように構成されたコンピュータプログラム製品において、
ハンドオーバー要求を受け取り、
ハンドオーバーを開始し、
転送失敗の通知を受け取り、及び
転送失敗の通知が受け取られる前、及び転送失敗の通知が受け取られた後の少なくとも一方に、ハンドオーバー要求に対してハンドオーバー失敗を指示する応答を伝送する、
ことを含むコンピュータプログラム製品が提供される。

本発明の第８の態様によれば、ハンドオーバーを要求するインストラクションをプロセッサが実行するのをコントロールするように構成されたコンピュータプログラム製品において、
開始すべきハンドオーバーの要求を伝送し、
そのハンドオーバー要求に対してハンドオーバー失敗を指示する応答を受け取り、前記応答は、転送失敗の通知が受け取られる前及び転送失敗の通知が受け取られた後の少なくとも一方に伝送される、コンピュータプログラム製品が提供される。

好ましくは、コンピュータプログラム製品は、非一時的コンピュータ読み取り可能な媒体において実施される。

本発明を適切に理解するため、添付図面を参照して、本発明を以下に詳細に説明する。

Ｅ−ＵＴＲＡＮから、ＤＴＭサポートのないＧＥＲＡＮへの全体的な単一無線ボイスコール継続手順を示す。 アクセス転送コントロールファンクションを使用するｅＳＲＶＣＣのセッションイニシエーションプロトコルレベル態様を示す。 単一無線ボイスコール継続性回復方法の一実施形態を示す。 単一無線ボイスコール継続性回復方法の別の実施形態を示す。 パケット交換から回路交換へのハンドオーバーの要求に応答する前にセッション転送レッグ確立エラーから回復する一実施形態を示す。 パケット交換から回路交換へのハンドオーバーの要求に応答した後にセッション転送レッグ確立エラーから回復する一実施形態を示す。 ある実施形態による方法を示す。 ある実施形態による別の方法を示す。 ある実施形態による更に別の方法を示す。 ある実施形態によるシステムを示す。

第３世代パートナーシッププロジェクト（３ＧＰＰ）リリース８は、進化型ユニバーサル地上無線アクセスネットワーク（Ｅ−ＵＴＲＡＮ）／高速パケットアクセス（ＨＳＰＡ）からユニバーサル地上無線アクセスネットワーク（ＵＴＲＡＮ）／移動通信用グローバルシステム（ＧＳＭ）ｅｄｇｅ無線アクセスネットワークへの方向に単一無線ボイスコール継続性（ＳＲＶＣＣ）をサポートする。単一無線ボイスコール継続性をサポートするには、ターゲット無線アクセステクノロジー（ＲＡＴ）での回路交換（ＣＳ）ベアラ予約と、インターネットプロトコル（ＩＰ）マルチメディアサブシステム（ＩＭＳ）により遂行されるパケット交換（ＰＳ）から回路交換へのボイスメディアスイッチングとが要求される。このファンクションは、参考としてここにそのまま援用される３ＧＰＰ ＴＳ２３．２１６に記載されている。

３ＧＰＰリリース１０における改善型ＳＲＶＣＣ（ｅＳＲＶＣＣ）は、Ｅ−ＵＴＲＡＮ／ＨＳＰＡからＵＴＲＡＮ／ＧＥＲＡＮへのアクセス転送中に最適な遅延を許す。ｅＳＲＶＣＣのために、アクセス転送コントロールファンクション（ＡＴＣＦ）と称される機能的エンティティが生成されている。アクセス転送コントロールファンクションの機能は、参考としてここにそのまま援用される３ＧＰＰ ＴＳ２３．２３７に記載されている。

回路交換ベアラ予約は成功であるが、移動交換センターサーバーにより行われるパケット交換から回路交換へのボイスメディアスイッチングが失敗となるシナリオが生じ得る。ある実施形態は、そのようなシナリオから回復するシステム、装置及び方法を提供する。移動交換センターサーバーにより行われるパケット交換から回路交換へのボイスメディアスイッチングは、セッション転送要求の伝送を指し、例えば、セッションイニシエーションプロトコル（ＳＩＰ）ＩＮＶＩＴＥメッセージの伝送を指す。回復方法は、以下で検討するように、移動交換センターサーバー（ＭＳＳ）／移動管理エンティティ（ＭＭＥ）及び進化型ノードＢ（ｅＮｂ）システム間での付加的な情報交換を含む。従って、ある実施形態は、移動管理エンティティが単一無線ボイスコール継続性を検出し（例えば、Ｏ＆Ｍ）、そしてそれがこの状態において再発生するのを防止するための手段を提供する。

図３は、単一無線ボイスコール継続性回復方法の第１の代替的実施形態を示す。この実施形態において、システム及びプロトコルは、ＭＳＳが図１のＳ１０に対する応答（例えば、１ｘｘ又は２ｘｘ応答）としてＩＰマルチメディアサブシステムから肯定指示を得ない限り、ＭＳＳが図１のＳ１３において肯定のＰＳ−ＣＳ応答を返送しないことを保証する。ＭＳＳが、ユーザ装置にサービスしないアクセス転送コントロールファンクションへＩＮＶＩＴＥ（図１のＳ１０）を伝送する場合には、このアクセス転送コントロールファンクションは、ＭＳＳへの応答において否定指示を返送する（図３のＳ１０ａ）。この否定指示は、例えば、４０４ユーザ見つからず又は他の何らかのエラー指示である。

ユーザが未知であるケースに加えて、ＩＭＳのＡＴＣＦ／ＳＣＣ−ＡＳがなぜＩＮＶＩＴＥを拒絶するかについて他にも理由がある。例えば、ユーザは既知であるが、ユーザのための転送可能なセッションがない。このケースでは、ＭＳＳが、例えば、ユーザが未知であるケースと、ユーザは既知であるがユーザに関連した転送可能なセッションがないケースとを区別できるようにするために、異なる応答コードが使用される。この後者のシナリオは、競争条件のために生じる。例えば、ＳＲＶＣＣ ＵＳ／ＭＭＥがＳＲＶＣＣ手順をスタートするが、同時にリモートＵＥ（例えば、図２のＵＥ−２）がセッションを解除する。この状態は、例えば、４８０コードのようなコードにより指示される。

ＭＳＳがアクセス転送コントロールファンクションから否定応答を得る場合には、それは、移動管理エンティティへの「ＳＲＶＣＣ ＰＳ−ＣＳ応答」に「ＳＲＶＣＣ拒絶原因」を含む（図３のＳ１０ｂ）。拒絶原因は、移動管理エンティティに、この失敗は、「無効ＳＴＮ−ＳＲ」によって生じたものであり、他の何らかの理由、例えば、アクセス転送コントロールファンクションに到達できないこと、又はユーザは既知であるが転送可能なセッションがないケース、によって生じたものではないことを指示する。

移動管理エンティティは、この拒絶原因を得ると、ｅＮｂとのパケット交換−回路交換ＨＯ手順をキャンセルし、そしてｅＮＢに、このセッションに対して単一無線ボイスコール継続性を遂行すべきでないことを指示する（図３のＳ１０ｃ）。又、移動管理エンティティは、単一無線ボイスコール継続性のための記憶されたセッション転送番号を削除することもできる。従って、移動管理エンティティは、単一無線ボイスコール継続性のためのセッション転送番号がＨＳＳにより更新されるまで、新たな進化型パケットシステム（ＥＰＳ）セッションに対する将来の単一無線ボイスコール継続性呼び出しを防止する。又、移動管理エンティティは、問題解決を容易にするために単一無線ボイスコール継続性欠陥の原因を指示する内部アラームログを発生することもできる。更に、移動管理エンティティは、ＨＳＳに問合わせすることにより単一無線ボイスコール継続性のための記憶されたセッション転送番号をリフレッシュするよう試みる。

各単一無線ボイスコール継続性ハンドオーバーは、ＭＳＳがＩＰマルチメディアサブシステム応答（図３のＳ１０ａ）を待機する間に、それが、例えば、１ｘｘであるか又は４０４／否定応答であるか決定するためにある程度の遅延を有し、その後、移動管理エンティティへの回路交換ベアラＨＯ応答を再開することができる（図３のＳ１０ｂ）。エラー状態が稀に生じるだけである場合には、これは、エラー検出と遅延との間の著しいトレードオフを招く。しかしながら、このトレードオフは、減少することができる。

図４は、単一無線ボイスコール継続性回復方法の別の代替的実施形態を示す。この実施形態は、シリアル化を回避でき、即ち図３に示した実施形態で行われたように１つのステップが実行された後に別のステップが実行されることを回避できる。

図４に示すように、移動管理エンティティは、ＩＰマルチメディアサブシステム応答（図３のＳ１０ａ）がまだ到着しないときでも肯定応答（図３のＳ１０ｂに対応するＳ１０ｂ）を伝送することができる。これは、ユーザ装置が、ＩＰマルチメディアサブシステムの応答を待機せずに回路交換側へハンドオーバーするようにさせる。それ以外の振る舞いは、図３を参照して述べた通りである。

ＭＳＳがＳＲＶＣＣ ＰＳ−ＣＳ応答で移動管理エンティティに応答した後にＭＳＳが（図４のＳ１０ａにおいて）ＩＰマルチメディアサブシステムから４０４／否定応答を得ると、ＭＳＳは、ＳＲＶＣＣ ＰＳ−ＣＳ完了通知に「無効ＳＴＮ−ＳＲ」のエラー原因を含ませる（図４のＳ１０ｘ）。ユーザ装置は、Ｓ１０ａの遅い到着（図４では、図３に比して比較的遅い）のために回路交換側へハンドオーバーするが、ＳＲＶＣＣ ＰＳ−ＣＳ完了通知における指示は、ユーザ装置がＬＴＥへ戻るときに移動管理エンティティが更に別の単一無線ボイスコール継続性の呼び出しを回避するのを許すことができる。

従って、ある実施形態では、なぜ単一無線ボイスコール継続性が失敗となったかの明確な指示を移動管理エンティティに与えることができる。その結果、システムの動作が更に予想可能となり、同じ理由で繰り返される失敗を回避又は防止することができる。同様に、フォールバック手順も、もし適切であれば、更に追求することができる。フォールバック手順の一例は、ボイスのための回路交換フォールバック（ＣＳＦＢ）である。

前記実施形態は、ＩＰマルチメディアサブシステムのセッション転送失敗の原因を示すために「不良ＳＴＮ−ＳＲ」を使用例として提示した。ＩＰマルチメディアサブシステムのセッション転送は、他の理由でも失敗となる。従って、他の実施形態では、失敗の原因に関する付加的な指示を与えるか、又はより一般的な失敗の指示を与えることができる。例えば、ＭＳＳにより移動管理エンティティに指示される原因値（図３及び４のＳ１０ｂ及びＳ１０ｘ）は、「セッション転送レッグ確立エラー」のような一般的な仕方で形成される。

移動管理エンティティと、図３に示したソースｅＮｂとの間の相互作用は、種々の方法をもつことができる。１つの変形例として、ハンドオーバー失敗は、単一無線ボイスコール継続性が「可能でない」ことを指示するＳＲＶＣＣ動作可能情報エレメント（ＩＥ）を含む。このＩＥは、移動管理エンティティによりセットされる。ｅＮｂは、この新たな指示を使用して、このコールに対する単一無線ボイスコール継続性が再びトリガーしないことを保証する。別の可能性として、移動管理エンティティは、単一無線ボイスコール継続性の動作可能性情報エレメントを「可能でない」へ更新するためのハンドオーバー失敗メッセージを伝送した直後にＵＥコンテキスト変更要求メッセージをｅＮｂへ伝送することができる。

図５及び６は、移動交換センターが一般的なエラーコード「セッション転送レッグ確立エラー」をどのように使用し、及び移動管理エンティティが“ＮＯ”にセットされたＳＲＶＣＣ動作可能性ＩＥをハンドオーバー失敗メッセージにどのように含ませるかを示す。

より詳細には、図５は、パケット交換から回路交換へのハンドオーバー要求に応答する前にセッション転送レッグ確立エラーから回復する実施形態を示す。図５に示すように、ＳＲＶＣＣ手順は、ソースＥ−ＵＴＲＡＮによってスタートされ、そしてＭＭＥは、ＰＳ−ＣＳ要求をＭＳＣサーバーへ伝送する。ＭＳＣサーバーは、ターゲットＣＳ無線アクセステクノロジー（ＲＡＴ）からリソースを要求する。Ｓ１０は、図３と同様に、ＩＮＶＩＴＥを伴うセッション転送メッセージを与えるように遂行される。次いで、Ｓ１０ｄにおいて（図３のＳ１０と同様に）、失敗を、このケースでは一般的な失敗メッセージで報告することができる。Ｓ１０ｅにおいて（図３のＳ１０ｂと同様に）、この失敗は、ソースＭＭＥへ報告される。次いで、ＭＳＣサーバーは、ターゲットＣＳ無線アクセステクノロジーをクリアすることができる。Ｓ１０ｆにおいて（図３のＳ１０ｃと同様に）、ソースＭＭＥは、ハンドオーバー準備失敗を一般的な失敗メッセージでソースＥ−ＵＴＲＡＮへ信号する。次いで、ソースＥ−ＵＴＲＡＮは、このセッションに対して単一無線ボイスコール継続性手順がないことを決定する。その間に、ソースＭＭＥは、記憶されたＳＴＮ−ＳＲをクリアし、そしてＳＲＶＣＣ動作可能性を“ＮＯ”にセットする。これらの設定の一方又は両方が現在セッションに関して適用される。本発明の１つの実施形態において、クリアされたＳＴＮ−ＳＲ及び／又は“ＮＯ”設定は、特定のユーザ装置のその後の新たなセッションにも適用される。これは、ＭＭＥのローカルユーザ契約プロフィールに新たな値を記憶することにより行われる。

図６は、パケット交換から回路交換へのハンドオーバー要求に応答した後にセッション転送レッグ確立エラーから回復する実施形態を示す。図６に示すように、単一無線ボイスコール継続性手順は、図５に示すように開始され、そしてＳ１０は、図５と同様である。しかしながら、ＩＭＳが応答するのを待機せずに、ＭＳＣサーバーは、Ｓ１０ｂにおいて、肯定応答をソースＭＭＥに与え、次いで、ソースＭＭＥは、ハンドオーバーコマンドをＵＥに与えて、ＵＥを回路交換無線アクセス技術へスイッチさせる。

そうする間に、Ｓ１０ｄにおいて、ＩＭＳは、失敗を一般的な用語でＭＳＣサーバーへ報告する。次いで、ＭＳＣサーバーは、Ｓ１０ｙにおいて、一般的エラーを示すＰＳ−ＣＳ完了メッセージをソースＭＭＥに与える。次いで、ＭＳＣサーバーは、コールを解除する。その間に、ソースＭＭＥは、記憶されたＳＴＮ−ＳＲをクリアし、ＳＲＶＣＣ動作可能性を“ＮＯ”にセットする。上述したように、これらの設定の一方又は両方を現在セッションに関して適用することもできるし、又は特定のユーザ装置のその後の新たなセッションに関して適用することもできる。

図２から６は、方法として示されているが、それらの図は、ネットワークエンティティとユーザ装置との間の相互接続を示し、従って、ユーザ装置エンティティ、ＲＡＮエンティティ、移動管理エンティティ、スイッチングエンティティ、及びコアネットワークエンティティ（ＩＭＳ）を備えたシステムを表わすと考えられることが理解されよう。

図７は、ある実施形態による方法を示す。図７に示すように、７１０において、装置又はサブシステム（ＩＭＳのような）は、ユーザ装置のセッション転送を開始するためにネットワークエレメント（ＭＳＣサーバーのような）からの要求（７０５で受け取った）に応答してユーザ装置のセッション転送が可能であるかどうか決定することができる。この方法は、７２０において、セッション転送が可能でないと決定されたときに、転送が可能でないことを、一般的指示（７２４）又は特定指示（７２２）のいずれかを使用して、要求側ネットワークエレメントに報告することも含む。

上述した方法の実施形態に関連して、セッションのハンドオーバーが失敗となった場合に、セッションは、ソースＲＡＴをサポートできると仮定すれば、ソースＲＡＴにおいて実行され続けることが理解される。より詳細には、これは、ＭＳＳが、それが予約／設定したＣＳ無線リソースを解除し、そしてユーザ装置がＰＳ ＲＡＴを使用し続けるか又はそこに戻ることを意味する。

図８は、ある実施形態による別の方法を示す。図８に示すように、方法（例えば、ＭＳＳにより遂行される）は、８１０において、インターネットプロトコルマルチメディアサブシステムからユーザ装置のセッション転送を要求することを含む。又、この方法は、８２０において、インターネットプロトコルマルチメディアサブシステムからセッション転送が可能であるとの肯定又は否定確認を待機することも含む。又、この方法は、８２５において、インターネットプロトコルマルチメディアサブシステムから実際の応答を待機する間に肯定応答をソース移動管理エンティティへ報告することも含む。更に、この方法は、否定確認が受け取られたときに転送が可能でないとの一般的指示又は特定の指示のいずれかを移動管理エンティティへ報告することも含む（８３０又は８３５）。より詳細には、ハンドオーバーが進行しなかった場合には、報告は、８３０において、否定のＰＳ−ＣＳ応答を報告することを含む。それとは別に、ハンドオーバーが既に進行している場合には、報告は、８３５において、ＰＳ−ＣＳ完了を報告することを含む。

図９は、ある実施形態による更に別の方法を示す。図９に示すように、方法（例えば、ＭＭＥにより遂行される）は、９０５において、単一無線ボイスコール継続性が完了したか又はエラーのために開始できないとの指示を受け取ることを含む。又、この方法は、９１０において、単一無線ボイスコール継続性のための記憶されたセッション転送番号をクリアすることも含む。更に、この方法は、９２０において、エラーの指示と共にハンドオーバー準備失敗をソースＥ−ＵＴＲＡＮへ報告することも含む。エラーは、９０５及び９２０において一般的に又は特別に識別される。又、この方法は、９１５において、ＳＲＶＣＣ動作可能性を“ＮＯ”にセットすることも含む。

図１０は、ある実施形態によるシステムを示す。規範的な実施形態において、システムは、３つの装置又はサブシステム、即ちＭＭＥ１０１０、ＭＳＣサーバー１０２０、及びＩＭＳ１０３０を備えている。これら装置１０１０、１０２０及び１０３０の各々には、少なくとも１つのプロセッサ（各々１０１４、１０２４及び１０３４）、コンピュータプログラムインストラクション又はコードを含む少なくとも１つのメモリ（各々１０１５、１０２５及び１０３５）、トランシーバ（各々１０１６、１０２６及び１０３６）並びにアンテナ（各々１０１７、１０２７及び１０３７）が装備される。

各トランシーバ１０１６、１０２６及び／又は１０３６は、送信器、受信器、送信器・受信器の両方、又は送信及び受信の両方に構成されたユニットである。トランシーバ１０１６、１０２６及び／又は１０３６は、指向性アンテナ又はマイクロ波リンクを含む１つ以上の各アンテナ１０１７、１０２７及び／又は１０３７に結合される。ＭＭＥ１０１０、ＭＳＣサーバー１０２０及びＩＭＳ１０３０にアンテナを装備することは、要件ではない。むしろ、例えば、ＭＭＥ１０１０、ＭＳＣサーバー１０２０及びＩＭＳ１０３０は、全て、光ファイバネットワークのようなネットワークを経て有線通信のみを行うように構成されてもよい。

少なくとも１つのプロセッサ１０１４、１０２４、及び／又は１０３４の各々は、中央処理ユニット（ＣＰＵ）又は特定用途向け集積回路（ＡＳＩＣ）のような計算又はデータ処理装置によって様々に実施される。少なくとも１つのプロセッサ１０１４、１０２４、及び／又は１０３４は、１つ又は複数のコントローラで具現化することもできる。

少なくとも１つのメモリ１０１５、１０２５及び／又は１０３５の各々は、非一時的なコンピュータ読み取り可能なメディアのような適当な記憶装置である。少なくとも１つのメモリ１０１５、１０２５及び／又は１０３５には、例えば、ハードディスクドライブ（ＨＤＤ）又はランダムアクセスメモリ（ＲＡＭ）が使用される。少なくとも１つのメモリ１０１５、１０２５及び／又は１０３５は、それに対応する少なくとも１つのプロセッサ１０１４、１０２４、及び／又は１０３４と同じチップにあってもよいし、或いはそれに対応する少なくとも１つのプロセッサ１０１４、１０２４、及び／又は１０３４から分離されてもよい。

コンピュータプログラムインストラクションは、適当な形態のコンピュータプログラムコードである。例えば、コンピュータプログラムインストラクションは、コンパイル型又は解釈型のコンピュータプログラムである。

少なくとも１つのメモリ１０１５、１０２５及び／又は１０３５、並びにコンピュータプログラムインストラクションの各々は、それに対応する少なくとも１つのプロセッサ１０１４、１０２４、及び／又は１０３４と共に、ハードウェア装置（例えば、指向性無線イネーブル装置１０１０、又はレガシー装置１０２０及び／又は１０３０に、上述したプロセスのようなプロセスを遂行させるように構成される。

従って、ある実施形態では、非一時的なコンピュータ読み取り可能なメディアは、ハードウェアで実行されたときに、ここに述べるプロセスの１つのようなプロセスを遂行するコンピュータインストラクションでエンコードされる。或いは又、本発明のある実施形態は、完全にハードウェアで遂行されてもよい。

又、システムの装置は、付加的なコンポーネントも含む。例えば、ＭＭＥ１０１０、ＭＳＣサーバー１０２０、及びＩＭＳ１０３０の各々は、それに対応するプロセッサ１０１４、１０２４、及び／又は１０３４、並びにそれに対応するメモリ１０１５、１０２５及び／又は１０３５に作動的に接続されたユーザインターフェイスを含む。そのユーザインターフェイスは、液晶ディスプレイ（ＬＣＤ）又は有機エレクトロルミネセントディスプレイ（ＯＥＬＤ）、及びスピーカ又はオーディオ出力のようなディスプレイを含む。触覚フィードバックシステムのような触感出力も含まれる。ユーザインターフェイスは、ユーザ入力を受け取るためのタッチスクリーンを有する。又、ユーザ入力は、キーパッド、キーボード、マイクロホン、ジョイスティック、マウス、トラックボール、又は他の入力装置によっても与えられる。しかしながら、そのような付加的なコンポーネントを設けることは、要件ではない。例えば、ＭＭＥ１０１０、ＭＳＣサーバー１０２０、及びＩＭＳ１０３０の各々は、ラックマウントコンピュータとして具現化される。ＭＭＥ１０１０、ＭＳＣサーバー１０２０、及びＩＭＳ１０３０は、個別のボックスとして示されているが、それら装置は、あるケースでは、同じ物理的エンクロージャー内に配置されてもよい。

当業者であれば、上述した本発明は、異なる順序のステップ、及び／又はここに開示したものとは異なる構成のハードウェアエレメントでも実施できることが理解されよう。それ故、本発明は、これらの好ましい実施形態に基づいて説明されたが、当業者であれば、本発明の精神及び範囲内に留まりつつも、変更や修正や代替構造が明らかであろう。

ある実施形態によれば、方法（ＩＭＳ）は、ユーザ装置のセッション転送を開始するためのネットワークエレメントからの要求に応答してユーザ装置のセッション転送が可能であるかどうか決定することを含む。又、この方法は、セッション転送が可能でないと決定されたときに、転送が可能でないとの一般的指示又は特定の指示を要求側ネットワークエレメントに報告することも含む。

ある実施形態において、装置は、少なくとも１つのプロセッサと、コンピュータプログラムコードを含む少なくとも１つのメモリとを備えている。少なくとも１つのメモリ及びコンピュータプログラムコードは、少なくとも１つのプロセッサとで、装置が、少なくとも、ユーザ装置のセッション転送を開始するためのネットワークエレメントからの要求に応答してユーザ装置のセッション転送が可能であるかどうか決定するようにさせるよう構成される。又、少なくとも１つのメモリ及びコンピュータプログラムコードは、少なくとも１つのプロセッサとで、装置が、少なくとも、セッション転送が可能でないと決定されたときに、転送が可能でないとの一般的指示又は特定の指示を要求側ネットワークエレメントに報告するようにさせるようにも構成される。

ある実施形態によれば、装置は、ユーザ装置のセッション転送を開始するためのネットワークエレメントからの要求に応答してユーザ装置のセッション転送が可能であるかどうか決定するための決定手段を備えている。又、装置は、セッション転送が可能でないと決定されたときに、転送が可能でないとの一般的指示又は特定の指示を要求側ネットワークエレメントに報告するための報告手段も備えている。

コンピュータ読み取り可能なメディア（非一時的メディアのような）は、ある実施形態では、ハードウェアで実行されたときにプロセスを遂行するインストラクションでエンコードされる。プロセスは、ユーザ装置のセッション転送を開始するためのネットワークエレメントからの要求に応答してユーザ装置のセッション転送が可能であるかどうか決定することを含む。又、プロセスは、セッション転送が可能でないと決定されたときに、転送が可能でないとの一般的指示又は特定の指示を要求側ネットワークエレメントに報告することも含む。

ある実施形態によれば、方法は、インターネットプロトコルマルチメディアサブシステムからユーザ装置のセッション転送を要求し、インターネットプロトコルマルチメディアサブシステムからセッション転送が可能であるとの肯定又は否定確認を待機し、否定確認が受け取られたときに転送が可能でないとの一般的指示又は特定の指示を移動管理エンティティへ報告することを含む。又、この方法は、インターネットプロトコルマルチメディアサブシステムから実際の応答を待機する間にソース移動管理エンティティに肯定応答を報告することも含む。その報告は、否定のＰＳ−ＣＳ応答を報告することも含む。或いは又、報告は、ＰＳ−ＣＳ完了を報告することを含んでもよい。

ある実施形態において、装置は、少なくとも１つのプロセッサと、コンピュータプログラムコードを含む少なくとも１つのメモリとを備えている。少なくとも１つのメモリ及びコンピュータプログラムコードは、少なくとも１つのプロセッサとで、装置が、少なくとも、インターネットプロトコルマルチメディアサブシステムからユーザ装置のセッション転送を要求するようにさせるよう構成される。又、少なくとも１つのメモリ及びコンピュータプログラムコードは、少なくとも１つのプロセッサとで、装置が、少なくとも、インターネットプロトコルマルチメディアサブシステムからセッション転送が可能であるとの肯定又は否定確認を待機するようにさせるよう構成される。更に、少なくとも１つのメモリ及びコンピュータプログラムコードは、少なくとも１つのプロセッサとで、装置が、少なくとも、否定確認が受け取られたときに転送が可能でないとの一般的指示又は特定の指示を移動管理エンティティへ報告するようにさせるよう構成される。又、少なくとも１つのメモリ及びコンピュータプログラムコードは、少なくとも１つのプロセッサとで、装置が、少なくとも、インターネットプロトコルマルチメディアサブシステムから実際の応答を待機する間にソース移動管理エンティティに肯定応答を報告するようにさせるよう構成される。その報告は、否定のＰＳ−ＣＳ応答を報告することも含む。或いは又、報告は、ＰＳ−ＣＳ完了を報告することを含んでもよい。

ある実施形態によれば、装置は、インターネットプロトコルマルチメディアサブシステムからユーザ装置のセッション転送を要求するための要求手段を備えている。又、装置は、インターネットプロトコルマルチメディアサブシステムからセッション転送が可能であるとの肯定又は否定確認を待機するための待機手段も備えている。更に、装置は、否定確認が受け取られたときに転送が可能でないとの一般的指示又は特定の指示を移動管理エンティティへ報告するための報告手段も備えている。この報告手段は、インターネットプロトコルマルチメディアサブシステムから実際の応答を待機する間にソース移動管理エンティティに肯定応答を報告する。その報告は、否定のＰＳ−ＣＳ応答を報告することを含む。或いは又、報告は、ＰＳ−ＣＳ完了を報告することを含んでもよい。

コンピュータ読み取り可能なメディア（非一時的メディアのような）は、ある実施形態では、ハードウェアで実行されたときにプロセスを遂行するインストラクションでエンコードされる。プロセスは、インターネットプロトコルマルチメディアサブシステムからユーザ装置のセッション転送を要求することを含む。又、プロセスは、インターネットプロトコルマルチメディアサブシステムからセッション転送が可能であるとの肯定又は否定確認を待機することも含む。更に、プロセスは、否定確認が受け取られたときに転送が可能でないとの一般的指示又は特定の指示を移動管理エンティティへ報告することも含む。又、プロセスは、インターネットプロトコルマルチメディアサブシステムから実際の応答を待機する間にソース移動管理エンティティに肯定応答を報告することも含む。その報告は、否定のＰＳ−ＣＳ応答を報告することも含む。或いは又、報告は、ＰＳ−ＣＳ完了を報告することを含んでもよい。

ある実施形態によれば、方法は、単一無線ボイスコール継続性が完了であるか又はエラーのためにスタートできないとの指示を受け取ると、単一無線ボイスコール継続性のための記憶されたセッション転送番号をクリアすることを含む。又、この方法は、エラーの指示と共にハンドオーバー準備失敗をソースＥ−ＵＴＲＡＮへ報告することも含む。エラーは、一般的に又は特別に識別することができる。又、この方法は、ＳＲＶＣＣ動作可能性を“ＮＯ”にセットすることも含む。

ある実施形態において、装置は、少なくとも１つのプロセッサと、コンピュータプログラムコードを含む少なくとも１つのメモリとを備えている。少なくとも１つのメモリ及びコンピュータプログラムコードは、少なくとも１つのプロセッサとで、装置が、少なくとも、単一無線ボイスコール継続性が完了であるか又はエラーのためにスタートできないとの指示を受け取ると、単一無線ボイスコール継続性のための記憶されたセッション転送番号をクリアするようにさせるよう構成される。又、少なくとも１つのメモリ及びコンピュータプログラムコードは、少なくとも１つのプロセッサとで、装置が、少なくとも、エラーの指示と共にハンドオーバー準備失敗をソースＥ−ＵＴＲＡＮへ報告するようにさせるよう構成される。エラーは、一般的に又は特別に識別することができる。又、少なくとも１つのメモリ及びコンピュータプログラムコードは、少なくとも１つのプロセッサとで、装置が、少なくとも、ＳＲＶＣＣ動作可能性を“ＮＯ”にセットするようにさせるよう構成される。

ある実施形態によれば、装置は、単一無線ボイスコール継続性が完了であるか又はエラーのためにスタートできないとの指示を受け取ると、単一無線ボイスコール継続性のための記憶されたセッション転送番号をクリアするためのクリア手段を備えている。又、装置は、エラーの指示と共にハンドオーバー準備失敗をソースＥ−ＵＴＲＡＮへ報告するための報告手段も備えている。エラーは、一般的に又は特別に識別することができる。又、この装置は、ＳＲＶＣＣ動作可能性を“ＮＯ”にセットするためのセット手段も備えている。

コンピュータ読み取り可能なメディア（非一時的メディアのような）は、ある実施形態では、ハードウェアで実行されたときにプロセスを遂行するインストラクションでエンコードされる。プロセスは、単一無線ボイスコール継続性が完了であるか又はエラーのためにスタートできないとの指示を受け取ると、単一無線ボイスコール継続性のための記憶されたセッション転送番号をクリアすることを含む。又、このプロセスは、エラーの指示と共にハンドオーバー準備失敗をソースＥ−ＵＴＲＡＮへ報告することも含む。エラーは、一般的に又は特別に識別することができる。又、このプロセスは、ＳＲＶＣＣ動作可能性を“ＮＯ”にセットすることも含む。

１０１０：ＭＭＥ
１０２０：ＭＳＣサーバー
１０３０：ＩＭＳ
１０１４、１０２４、１０３４：プロセッサ
１０１５、１０２５、１０３５：メモリ
１０１６、１０２６、１０３６：トランシーバ
１０１７、１０２７、１０３７：アンテナ

Claims (23)

1. ハンドオーバー要求を取り扱う方法において、
   ハンドオーバー要求を受け取り、
   ハンドオーバーを開始し、
   転送失敗の通知を受け取り、及び
   転送失敗の通知が受け取られる前、及び転送失敗の通知が受け取られた後の少なくとも一方に、ハンドオーバー要求に対してハンドオーバー失敗を指示する応答を伝送する、
   ことを含む方法。
2. ハンドオーバーを要求する方法において、
   開始すべきハンドオーバーの要求を伝送し、
   前記ハンドオーバー要求に対してハンドオーバーの失敗を指示する応答を受け取る、
   ことを含み、前記応答は、転送失敗の通知が受け取られる前、及び転送失敗の通知が受け取られた後の少なくとも一方に、伝送される、方法。
3. 前記ハンドオーバー要求に対する応答は、否定応答である、請求項１又は２に記載の方法。
4. 前記転送失敗は、セッションハンドオーバーの失敗である、請求項１から３のいずれかに記載の方法。
5. 前記要求は、１つの無線アクセステクノロジータイプから別の無線アクセステクノロジータイプへのセッションハンドオーバーに対するものである、請求項４に記載の方法。
6. 前記要求は、１つの無線リソースタイプから別の無線リソースタイプへのセッションハンドオーバーに対するものであり、これは、パケット交換セッションであるセッションを、回路交換セッションであるセッションへハンドオーバーすることを含む、請求項４又は５に記載の方法。
7. 前記ハンドオーバーは、ハンドオーバーが無線リソースレベルで生じる第１の態様と、セッションを転送すべき第２の態様とを有する、請求項１から６のいずれかに記載の方法。
8. ハンドオーバー要求に対する応答の伝送が、転送失敗通知を受け取る前に行われる場合には、ハンドオーバー要求に対する応答は、そのハンドオーバーを実行できることを指示する肯定応答である、請求項１から７のいずれかに記載の方法。
9. 転送失敗通知を受け取るのに続いて、ハンドオーバー要求に対する付加的な応答を伝送する、請求項８に記載の方法。
10. 前記付加的な応答は、転送を実行できないことを指示する否定応答である、請求項９に記載の方法。
11. 前記否定応答は、前記肯定応答により誤って指示された状態を正しく定義する、請求項１０に記載の方法。
12. 前記否定応答は、拒絶原因を含む、請求項３から１１のいずれかに記載の方法。
13. 前記否定応答に続いて、更なるハンドオーバーの試みを防止するために少なくとも１つのステップが実行される、請求項３から１２のいずれかに記載の方法。
14. 前記否定応答に続いて、特定セッションに対する更なるハンドオーバーの試みを防止するために少なくとも１つのステップが実行される、請求項３から１３のいずれかに記載の方法。
15. 前記否定応答に続いて、他のセッションに対する更なるハンドオーバーの試みを防止するために少なくとも１つのステップが実行される、請求項３から１４のいずれかに記載の方法。
16. 前記更なるハンドオーバーの試みの防止は、失敗を生じた問題を解消するための矯正的アクションが実行されるまで適用される、請求項１３から１５のいずれかに記載の方法。
17. 更なるハンドオーバーの試みを防止するために実行される前記少なくとも１つのステップは、記憶されたパラメータをクリアすること、及びセッション転送動作可能性の値を“ＮＯ”にセットすることの少なくとも一方である、請求項１３から１６のいずれかに記載の方法。
18. ハンドオーバー要求を受け取る受信器と、
    ハンドオーバーを開始するプロセッサと、
    を備え、前記受信器は、転送失敗の通知を受け取り、更に、
    転送失敗の通知が受け取られる前、及び転送失敗の通知が受け取られた後の少なくとも一方に、ハンドオーバー要求に対してハンドオーバー失敗を指示する応答を伝送する送信器を備えた、ハンドオーバー取り扱いネットワークエンティティ。
19. 開始すべきハンドオーバーの要求を伝送する送信器と、
    前記ハンドオーバー要求に対してハンドオーバーの失敗を指示する応答を受け取る受信器と、
    を備え、前記応答は、転送失敗の通知が受け取られる前及び転送失敗の通知が受け取られた後の少なくとも一方に伝送される、ハンドオーバー要求ネットワークエンティティ。
20. ハンドオーバー要求ネットワークエンティティ及びハンドオーバー取り扱いネットワークエンティティを備えたシステムにおいて、前記ハンドオーバー要求ネットワークエンティティは、
    開始すべきハンドオーバーの要求を伝送する送信器と、
    前記ハンドオーバー要求に対してハンドオーバーの失敗を指示する応答を受け取る受信器と、
    を備え、前記応答は、転送失敗の通知が受け取られる前、及び転送失敗の通知が受け取られた後の少なくとも一方に、伝送されるものであり、更に、前記ハンドオーバー取り扱いネットワークエンティティは、
    ハンドオーバー要求を受け取る受信器と、
    ハンドオーバーを開始するプロセッサと、
    を備え、前記受信器は、転送失敗の通知を受け取るものであり、更に、
    転送失敗の通知が受け取られる前、及び転送失敗の通知が受け取られた後の少なくとも一方に、ハンドオーバー要求に対してハンドオーバー失敗を指示する応答を伝送する送信器を備えた、システム。
21. ハンドオーバー要求を取り扱う方法において、
    ハンドオーバー要求を受け取り、
    ハンドオーバーを開始し、
    転送失敗の通知を受け取り、及び
    転送失敗の通知が受け取られる前、及び転送失敗の通知が受け取られた後の少なくとも一方に、ハンドオーバー要求に対してハンドオーバー失敗を指示する応答を伝送する、
    ことを含む方法。
22. ハンドオーバー要求を取り扱うインストラクションをプロセッサが実行するのをコントロールするように構成されたコンピュータプログラムにおいて、
    ハンドオーバー要求を受け取り、
    ハンドオーバーを開始し、
    転送失敗の通知を受け取り、及び
    転送失敗の通知が受け取られる前、及び転送失敗の通知が受け取られた後の少なくとも一方に、ハンドオーバー要求に対してハンドオーバー失敗を指示する応答を伝送する、
    ことを含むコンピュータプログラム
23. ハンドオーバーを要求するインストラクションをプロセッサが実行するのをコントロールするように構成されたコンピュータプログラムにおいて、
    開始すべきハンドオーバーの要求を伝送し、
    前記ハンドオーバー要求に対してハンドオーバー失敗を指示する応答を受け取り、前記応答は、転送失敗の通知が受け取られる前及び転送失敗の通知が受け取られた後の少なくとも一方に伝送される、コンピュータプログラム。

Images