(57)【特許請求の範囲】
【請求項１】
ユーザ機器（ＵＥ）のための回路交換フォールバック（ＣＳＦＢ）を促進するよう動作可能なモビリティ管理エンティティ（ＭＭＥ）であって、前記ＭＭＥは、１以上のプロセッサを備え、前記１以上のプロセッサは、
前記ＵＥから、前記ＵＥの最適化ＣＳＦＢ機能を規定する最適化ＣＳＦＢ機能インジケータを受信することと、
前記ＵＥに関連付けられた要求されるサービスタイプを受信することと、
前記ＵＥの前記最適化ＣＳＦＢ機能に基づいて、回路交換ネットワークへの前記ＵＥの単一無線音声通信継続（ＳＲＶＣＣ）ハンドオーバを開始することと、
Ｓ１アプリケーションプロトコル（Ｓ１−ＡＰ）要求メッセージを進化型ノードＢ（ｅＮＢ）に送信することであって、前記Ｓ１−ＡＰ要求メッセージは、前記最適化ＣＳＦＢ機能インジケータ及び前記ＵＥのための単一無線音声通信継続（ＳＲＶＣＣ）インジケータを含み、前記ＭＭＥは、前記要求されるサービスタイプに基づいて、前記ＳＲＶＣＣインジケータを選択する、送信することと、
前記ｅＮＢからハンドオーバ要求メッセージを受信することであって、前記回路交換ネットワークへの前記ＵＥの前記ＳＲＶＣＣハンドオーバが、前記最適化ＣＳＦＢ機能インジケータ及び前記ＳＲＶＣＣインジケータに部分的に基づいて、パケット交換ネットワークによってトリガされたときに、前記ｅＮＢは、前記ハンドオーバ要求メッセージを前記ＭＭＥに送信するよう構成されている、受信することと、
を行うよう構成されており、
前記ＳＲＶＣＣインジケータは、ＳＲＶＣＣ／ビデオＳＲＶＣＣ（ｖＳＲＶＣＣ）を開始するか否かについて前記ｅＮＢに通知し、前記ＳＲＶＣＣインジケータは、「０」のとき、ＳＲＶＣＣ／ｖＳＲＶＣＣもレガシーＣＳＦＢも予期されないことを前記ｅＮＢに示し、前記ＳＲＶＣＣインジケータは、「１」のとき、ＳＲＶＣＣが予期されることを前記ｅＮＢに示し、前記ＳＲＶＣＣインジケータは、「２」のとき、ｖＳＲＶＣＣが予期されることを前記ｅＮＢに示す、ＭＭＥ。
【請求項２】
前記１以上のプロセッサは、前記ＵＥから、アタッチ要求メッセージ又は追跡エリア更新（ＴＡＵ）要求メッセージを介して、前記最適化ＣＳＦＢ機能インジケータを受信すること、を行うよう更に構成されている、請求項１に記載のＭＭＥ。
【請求項３】
前記１以上のプロセッサは、前記ＵＥから、拡張サービス要求メッセージを介して、前記最適化ＣＳＦＢ機能インジケータを受信すること、を行うよう更に構成されている、請求項１に記載のＭＭＥ。
【請求項４】
前記１以上のプロセッサは、ホーム加入者サーバ（ＨＳＳ）から受信された位置更新確認応答メッセージに基づいて、前記最適化ＣＳＦＢ機能インジケータを特定することであって、前記位置更新確認応答メッセージは、前記ＵＥの前記最適化ＣＳＦＢ機能を示すＵＥ加入者プロファイルを含む、特定すること、を行うよう更に構成されている、請求項１に記載のＭＭＥ。
【請求項５】
前記１以上のプロセッサは、移動通信交換局（ＭＳＣ）から、ページング要求メッセージを介して、前記要求されるサービスタイプを受信すること、を行うよう更に構成されている、請求項１に記載のＭＭＥ。
【請求項６】
前記最適化ＣＳＦＢ機能インジケータは、前記ＵＥが、ＳＲＶＣＣベースのＣＳＦＢをサポートしていないことを示す「０」、又は、前記ＵＥが、ＳＲＶＣＣベースのＣＳＦＢをサポートしていることを示す「１」である、請求項１に記載のＭＭＥ。
【請求項７】
前記１以上のプロセッサは、モバイル発信（ＭＯ）呼について、前記ＵＥから拡張サービス要求メッセージを受信すること、を行うよう更に構成されている、請求項１に記載のＭＭＥ。
【請求項８】
前記１以上のプロセッサは、モバイル着信（ＭＴ）呼について、移動通信交換局（ＭＳＣ）からページング要求メッセージを受信すること、を行うよう更に構成されている、請求項１に記載のＭＭＥ。
【請求項９】
前記回路交換ネットワークは、ユニバーサル地上無線アクセスネットワーク（ＵＴＲＡＮ）、又は、移動通信用グローバルシステム（ＧＳＭ（登録商標））ＧＳＭ（登録商標）エボリューション用エンハンストデータレート無線アクセスネットワーク（ＧＥＲＡＮ）である、請求項１に記載のＭＭＥ。
【請求項１０】
前記要求されるサービスタイプは、音声、ビデオ、非構造付加サービスデータ（ＵＳＳＤ）、位置サービス（ＬＣＳ）、及び未知のもののうちの１つである、請求項１に記載のＭＭＥ。
【請求項１１】
前記１以上のプロセッサは、前記ＵＥに関連付けられたＱＣＩ＝１のベアラが存在しない場合、パケット交換から回路交換への（ＰＳ−ＣＳ）ハンドオーバ手順を開始すること、を行うよう更に構成されている、請求項１に記載のＭＭＥ。
【請求項１２】
前記１以上のプロセッサは、ＳＲＶＣＣの目的でＰＳからＣＳへの要求メッセージを移動通信交換局（ＭＳＣ）サーバに送信することによって、前記要求されるサービスタイプが音声又はビデオのためのものであるときには、ＰＳ−ＣＳハンドオーバ手順をトリガすることであって、前記ＰＳからＣＳへの要求メッセージは、前記最適化ＣＳＦＢ機能インジケータを含む、トリガすること、を行うよう更に構成されている、請求項１に記載のＭＭＥ。
【請求項１３】
ユーザ機器（ＵＥ）のための最適化回路交換フォールバック（ＣＳＦＢ）を促進するよう動作可能な進化型ノードＢ（ｅＮＢ）であって、前記ｅＮＢは、１以上のプロセッサを備え、前記１以上のプロセッサは、
前記ＵＥの最適化ＣＳＦＢ機能を規定する最適化ＣＳＦＢ機能インジケータを受信することと、
前記ＵＥのための単一無線音声通信継続（ＳＲＶＣＣ）インジケータを受信することと、
前記最適化ＣＳＦＢ機能インジケータ及び前記ＳＲＶＣＣインジケータに部分的に基づいて、回路交換ネットワークへの前記ＵＥのＳＲＶＣＣハンドオーバをトリガすることと、
前記ＳＲＶＣＣハンドオーバが、パケット交換ネットワークによってトリガされたときに、ハンドオーバ要求メッセージをモビリティ管理エンティティ（ＭＭＥ）に送信することと、
を行うよう構成されており、
前記ＳＲＶＣＣインジケータは、ＳＲＶＣＣ／ビデオＳＲＶＣＣ（ｖＳＲＶＣＣ）を開始するか否かについて前記ｅＮＢに通知し、前記ＳＲＶＣＣインジケータは、「０」のとき、ＳＲＶＣＣ／ｖＳＲＶＣＣもレガシーＣＳＦＢも予期されないことを前記ｅＮＢに示し、前記ＳＲＶＣＣインジケータは、「１」のとき、ＳＲＶＣＣが予期されることを前記ｅＮＢに示し、前記ＳＲＶＣＣインジケータは、「２」のとき、ｖＳＲＶＣＣが予期されることを前記ｅＮＢに示す、ｅＮＢ。
【請求項１４】
前記１以上のプロセッサは、前記ＵＥから、機能グループインジケータ（ＦＧＩ）を介して、前記最適化ＣＳＦＢ機能インジケータを受信すること、を行うよう更に構成されている、請求項１３に記載のｅＮＢ。
【請求項１５】
前記１以上のプロセッサは、前記ＵＥに関連付けられたＱＣＩ＝１のベアラが存在しない場合、前記回路交換ネットワークへの前記ＵＥの前記ＳＲＶＣＣハンドオーバをトリガすること、を行うよう更に構成されている、請求項１３に記載のｅＮＢ。
【請求項１６】
前記１以上のプロセッサは、前記ＭＭＥから、前記最適化ＣＳＦＢ機能インジケータを受信すること、を行うよう更に構成されている、請求項１３に記載のｅＮＢ。
【請求項１７】
前記回路交換ネットワークは、ユニバーサル地上無線アクセスネットワーク（ＵＴＲＡＮ）、又は、移動通信用グローバルシステム（ＧＳＭ（登録商標）））ＧＳＭ（登録商標）エボリューション用エンハンストデータレート無線アクセスネットワーク（ＧＥＲＡＮ）である、請求項１３に記載のｅＮＢ。
【発明の詳細な説明】
【背景技術】
【０００１】
無線移動体通信技術は、様々な規格及びプロトコルを使用して、ノード（例えば、伝送局）と無線デバイス（例えば、モバイルデバイス）との間でデータを伝送する。いくつかの無線デバイスは、ダウンリンク（ＤＬ）伝送において直交周波数分割多元接続（ＯＦＤＭＡ）を使用して通信し、アップリンク（ＵＬ）伝送において単一搬送波周波数分割多元接続（ＳＣ−ＦＤＭＡ）を使用して通信する。信号伝送のために直交周波数分割多重化（ＯＦＤＭ）を使用する規格及びプロトコルは、第３世代パートナーシッププロジェクト（３ＧＰＰ）ロングタームエボリューション（ＬＴＥ）、業界団体にはＷｉＭＡＸ（登録商標）（マイクロ波アクセスのための世界的相互運用性）として一般的に知られている電気電子技術者協会（ＩＥＥＥ）８０２．１６規格（例えば、８０２．１６ｅ、８０２．１６ｍ）、及び、業界団体にはＷｉＦｉ（登録商標）として一般的に知られているＩＥＥＥ８０２．１１規格を含む。
【０００２】
３ＧＰＰ無線アクセスネットワーク（ＲＡＮ）ＬＴＥシステムでは、ノードは、進化型ユニバーサル地上無線アクセスネットワーク（Ｅ−ＵＴＲＡＮ）ノードＢ（進化型ノードＢ、エンハンストノードＢ、ｅＮｏｄｅＢ、又はｅＮＢとしても一般的に表記される）と無線ネットワークコントローラ（ＲＮＣ）との組合せとすることができ、ユーザ機器（ＵＥ）として知られる無線デバイスと通信する。ダウンリンク（ＤＬ）伝送は、ノード（例えば、ｅＮｏｄｅＢ）から無線デバイス（例えば、ＵＥ）への通信とすることができ、アップリンク（ＵＬ）伝送は、無線デバイスからノードへの通信とすることができる。
【図面の簡単な説明】
【０００３】
本開示の特徴及び利点が、以下の詳細な説明を、添付の図面と併せて読むと明らかになるであろう。これらは共に、本開示の特徴を例として示す。以下では、図示される例示的な実施形態が参照される。本明細書では、特定の言い回しを用いて同実施形態を説明する。それでも、これによって本発明の範囲の限定が意図されるものではないことが理解されよう。
【図１】一例に従った、モバイル着信（ＭＴ）エンハンスト回路交換フォールバック（ｅＣＳＦＢ）手順を示す図。
【図２】一例に従った、モバイル発信（ＭＯ）エンハンスト回路交換フォールバック（ｅＣＳＦＢ）手順を示す図。
【図３】一例に従った、単一無線音声通信継続（ＳＲＶＣＣ）手順を含むエンハンスト回路交換フォールバック（ＣＳＦＢ）手順を示す図。
【図４】一例に従った、ユーザ機器（ＵＥ）のための回路交換フォールバック（ＣＳＦＢ）を促進するよう動作可能なモビリティ管理エンティティ（ＭＭＥ）の機能を示す図。
【図５】一例に従った、ユーザ機器（ＵＥ）のための回路交換フォールバック（ＣＳＦＢ）を促進するよう動作可能な進化型ノードＢ（ｅＮＢ）の機能を示す図。
【図６】一例に従った、ユーザ機器（ＵＥ）のための回路交換フォールバック（ＣＳＦＢ）を促進するための方法のフローチャート。
【図７】一例に従った無線デバイス（例えば、ＵＥ）の図。
【発明を実施するための形態】
【０００４】
本発明を開示及び説明する前に、本発明は、本明細書に開示される特定の構造、プロセスステップ、又は材料に限定されるものではなく、関連技術分野の当業者によって認識されるように、これらの均等の構成に拡張されることを理解されたい。また、本明細書において使用される用語は、特定の例を説明する目的のみで使用され、限定を意図していないことを理解されたい。異なる図面における同じ参照符号は同じ要素を表す。フローチャート及びプロセスにおいて提供される符号は、ステップ及び動作を明確に示すために提供され、必ずしも特定の順序又はシーケンスを示すわけではない。
【０００５】
（例示的な実施形態）
技術の実施形態の初期概要が以下に提供され、次に、特定の技術の実施形態が後に更に詳細に説明される。この初期概要は、読み手が技術をより迅速に理解するのを支援することを意図するものであり、技術の主要な特徴又は必要不可欠な特徴を特定することを意図するものでもなければ、特許請求される主題の範囲を限定することを意図するものでもない。
【０００６】
ユーザ機器（ＵＥ）のための回路交換フォールバック（ＣＳＦＢ）を促進するための技術が説明される。モビリティ管理エンティティ（ＭＭＥ）は、ＵＥから、ＵＥの最適化ＣＳＦＢ機能（optimized  CSFB  capability）を規定する最適化ＣＳＦＢ機能インジケータ（optimized  CSFB  capability  indicator）を受信することができる。ＭＭＥは、ＵＥから、アタッチ要求メッセージ、追跡エリア更新（ＴＡＵ）要求メッセージ、又は拡張サービス要求メッセージを介して、最適化ＣＳＦＢ機能インジケータを受信することができる。別の例において、ＭＭＥは、ホーム加入者サーバ（ＨＳＳ）から受信された位置更新確認応答メッセージに基づいて、最適化ＣＳＦＢ機能インジケータを特定することができる。位置更新確認応答メッセージは、ＵＥの最適化ＣＳＦＢ機能を示すＵＥ加入者プロファイルを含む。最適化ＣＳＦＢ機能インジケータは、ＵＥが、ＳＲＶＣＣベースのＣＳＦＢをサポートしていないことを示す「０」、又は、ＵＥが、ＳＲＶＣＣベースのＣＳＦＢをサポートしていることを示す「１」であり得る。更に、ＭＭＥは、ＵＥに関連付けられた要求されるサービスタイプを受信することができる。１つの例において、ＭＭＥは、移動通信交換局（ＭＳＣ）から、ページング要求メッセージを介して、要求されるサービスタイプを受信することができる。要求されるサービスタイプは、音声、ビデオ、非構造付加サービスデータ（ＵＳＳＤ）、位置サービス（ＬＣＳ）、及び未知のもののうちの１つであり得る。
【０００７】
ＭＭＥは、ＵＥの最適化ＣＳＦＢ機能に基づいて、回路交換ネットワークへのＵＥの単一無線音声通信継続（ＳＲＶＣＣ）ハンドオーバを開始することができる。ＭＭＥは、Ｓ１アプリケーションプロトコル（Ｓ１−ＡＰ）要求メッセージを進化型ノードＢ（ｅＮＢ）に送信することができ、ここで、Ｓ１−ＡＰ要求メッセージは、最適化ＣＳＦＢ機能インジケータ及びＵＥのための単一無線音声通信継続（ＳＲＶＣＣ）インジケータを含み、ＭＭＥは、要求されるサービスタイプに基づいて、ＳＲＶＣＣインジケータを選択する。ＳＲＶＣＣインジケータは、ＳＲＶＣＣ／ビデオＳＲＶＣＣ（ｖＳＲＶＣＣ）を開始するか否かについてｅＮＢに通知する。ＳＲＶＣＣインジケータは、「０」のとき、ＳＲＶＣＣ／ｖＳＲＶＣＣもレガシーＣＳＦＢも予期されないことをｅＮＢに示し、ＳＲＶＣＣインジケータは、「１」のとき、ＳＲＶＣＣが予期されることをｅＮＢに示し、ＳＲＶＣＣインジケータは、「２」のとき、ｖＳＲＶＣＣが予期されることをｅＮＢに示す。ＭＭＥは、ｅＮＢからハンドオーバ要求メッセージを受信することができ、ここで、回路交換ネットワークへのＵＥのＳＲＶＣＣハンドオーバが、最適化ＣＳＦＢ機能インジケータ及びＳＲＶＣＣインジケータに部分的に基づいて、パケット交換ネットワークによってトリガされたときに、ｅＮＢは、ハンドオーバ要求メッセージをＭＭＥに送信するよう構成されている。パケット交換から回路交換への（ＰＳ−ＣＳ）ハンドオーバ手順は、ＵＥに関連付けられたＱＣＩ＝１のべアラが存在しない場合であっても開始され得る。
【０００８】
回路交換フォールバック（ＣＳＦＢ）は、移動通信用グローバルシステム（ＧＳＭ（登録商標））又は別の回路交換ネットワークの使用を通じて、音声メッセージサービス及びショートメッセージサービス（ＳＭＳ）のサービスがＬＴＥデバイスに配信される技術である。すなわち、ＬＴＥデバイスが、パケット交換ネットワークから通信を受信できる場合であっても、ＬＴＥデバイスは、回路交換ネットワークにスイッチバック又はフォールバックする。一般に、パケット交換ネットワークの方が新しく、パケット交換ネットワークは、より古い回路交換ネットワークと比較して、向上した機能を提供することができる。パケット交換ネットワークは、パケットベースの全てインターネットプロトコル（ＩＰ）のネットワークである。パケットは、宛先アドレスに伝送され得、パケットは、受信されると、メッセージを形成するよう再組み立てされる。一方、回路交換ネットワークは、音声呼中に、専用ポイントツーポイント接続を使用する。ＬＴＥデバイスが、（パケット交換ネットワークではなく）回路交換ネットワーク内で移動しているとき、ＬＴＥデバイスは、回路交換ネットワーク（例えば、２Ｇネットワーク又は３Ｇネットワーク）にフォールバックすることによって、音声呼を完了することができる。ＬＴＥデバイスが、パケット交換ネットワークに戻ると、ＬＴＥデバイスは、パケット交換ネットワークをデフォルトとして使用することに復帰することができる。したがって、ＣＳＦＢは、より新しいパケット交換ネットワークが、ＬＴＥデバイスの現在位置において利用可能でないときに、旧式の回路交換ネットワークを利用する機能をＬＴＥデバイスに提供する。
【０００９】
単一無線音声通信継続（ＳＲＶＣＣ）は、パケットデータから回路交換データ音声呼へのハンドオーバを可能にする方式である。ＳＲＶＣＣは、ＬＴＥにおけるパケットドメイン呼が、ＧＳＭ（登録商標）、ユニバーサル移動体通信システム（ＵＭＴＳ）、又は符号分割多元接続（ＣＤＭＡ）等のレガシー回路交換音声システムにシームレスにハンドオーバされることを可能にする。すなわち、ＳＲＶＣＣは、ボイスオーバーＩＰ（ＶｏＩＰ）又はＩＰマルチメディアサブシステム（ＩＭＳ）ドメインからレガシーネットワーク（例えば、回路交換ネットワーク）に音声呼を移行させる機能を提供する。ネットワーク事業者は、ＳＲＶＣＣを利用して、サービス品質（ＱｏＳ）を維持しかつ緊急呼のために呼継続が許容可能であることを確保しながら、ハンドオーバを行う。
【００１０】
ＬＴＥネットワークからレガシーネットワーク（例えば、回路交換ネットワーク）へのハンドオーバは、モバイルデバイスがＬＴＥカバレッジエリア外に動くときに生じ得る。音声呼に関与しているＳＲＶＣＣ対応ＵＥが、ＬＴＥカバレッジエリアから離れるように動いているとこのＵＥが判定すると、このＵＥは、ＬＴＥネットワークに通知する。ＬＴＥネットワークは、音声呼がレガシーネットワークに移されるべきであることを決定する。ＬＴＥネットワークは、音声呼をパケットドメインから回路ドメインに切り替える必要性を、移動通信交換局（ＭＳＣ）サーバに通知し、レガシーネットワークへのＬＴＥ音声ベアラのハンドオーバを開始する。ＭＳＣサーバは、レガシーネットワークにおけるＵＥのためのベアラパスを確立し、ＵＥの音声呼がパケットドメインから回路ドメインに移されていることを、ＩＭＳコアに通知する。ＵＥがレガシーネットワークに達すると、ＵＥは、ＵＥの内部音声処理を、例えばＶｏＩＰから、レガシー回路音声に切り換え、音声呼が継続する。ＵＥが、ＬＴＥカバレッジエリアに再度達すると、音声呼は、同様にしてＬＴＥネットワークに復帰する。
【００１１】
３ＧＰＰ技術仕様（ＴＳ）２３．２１３セクション６．２．２において規定されているようなレガシービデオＳＲＶＣＣ（ｖＳＲＶＣＣ）手順において、ターゲット無線アクセスネットワーク（ＲＡＮ）におけるＵＥの音声呼又はビデオ呼のための無線リソース及びネットワークリソースは、ＭＳＣサーバがパケット交換（ＰＳ）から回路交換（ＣＳ）へのＳＲＶＣＣ要求メッセージを受信すると、割り当てられ得る。ＵＥが、Ｅ−ＵＴＲＡＮコマンドメッセージからのハンドオーバ（ＨＯ）を受信すると、ＵＥは、音声呼又はビデオ呼のための無線リソース及びネットワークリソースがターゲットＲＡＮにおいて予約されていることを認識する。したがって、ＵＥがターゲットＲＡＮに同調したときに、ＵＥは、ターゲットＲＡＮに関する無線リソース割り当て手順をスキップすることができ、これによって、ｖＳＲＶＣＣ中の時間及びリソースを節減することができる。
【００１２】
１つの以前のソリューションでは、Ｅ−ＵＴＲＡＮが、モビリティ管理エンティティ（ＭＭＥ）から、ＣＳＦＢインジケータを含むＳ１アプリケーションプロトコル（Ｓ１−ＡＰ）を受信すると、Ｅ−ＵＴＲＡＮは、ＵＥの進化型パケットシステム（ＥＰＳ）ベアラを解析して、ＱＣＩ＝１のベアラが存在するか否かを判定することができる。ＱＣＩ＝１のベアラが存在しない場合、Ｅ−ＵＴＲＡＮは、ＳＲＶＣＣ手順を開始しないのに対し、ＱＣＩ＝１のベアラが存在する場合、Ｅ−ＵＴＲＡＮは、ＳＲＶＣＣ手順を開始する。
【００１３】
別の以前のソリューションでは、ＣＳＦＢとＳＲＶＣＣとを組み合わせたエンハンストＣＳＦＢ手順又は最適化ＣＳＦＢ手順が導入されている。このソリューションでは、ＵＥのためのＱＣＩ＝１のＥＰＳベアラが全く存在しない。Ｅ−ＵＴＲＡＮが、ＭＭＥから（ＣＳＦＢインジケータを含む）Ｓ１−ＡＰメッセージを受信したときに、ＵＥがエンハンストＣＳＦＢをサポートしているか否かを認識していない場合、Ｅ−ＵＴＲＡＮは、ＳＲＶＣＣ手順を開始しない。しかしながら、以前のソリューションでは、ネットワーク要素（例えば、ＭＭＥ）は、ＵＥがエンハンストＣＳＦＢをサポートしているか又はレガシーＣＳＦＢのみをサポートしているかを認識していない。したがって、本技術は、ＵＥのエンハンストＣＳＦＢ機能についてネットワーク要素（例えば、ＭＭＥ及びｅＮＢ）に通知することを示す。
【００１４】
別の以前のソリューションでは、ｅＮＢのためのＱＣＩ＝１のベアラが存在しないため、ｅＮＢは、ターゲットＲＡＮへのハンドオーバ要求メッセージにおいて、音声呼のためのリソース割り当てを要求することができる。ｅＮＢは、デフォルトで、音声呼のためのリソース割り当てを要求することができる。すなわち、別の以前のソリューションにおけるエンハンストＣＳＦＢ手順は、ＳＲＶＣＣ手順が音声呼のためにのみ使用され、ビデオ呼、位置サービス（ＬＣＳ）、又は非構造付加サービスデータ（ＵＳＳＤ）等の他のサービスを考慮しないと仮定している。ＵＥが、ｖＳＲＶＣＣ（すなわち、音声呼ではなくビデオ呼）を要求する場合において、ＵＥが、ターゲットＲＡＮに同調したとき、音声呼のための割り当てられたＴＳ１１ベアラは、ビデオ呼のために使用することができない。すなわち、ＴＳ１１ベアラは、ＵＥのために割り当てられるが、いかなる形でも使用することができない。この場合、ＵＥは、リソース割り当てについて、ターゲットＲＡＮと同期することができるが、この更なるシグナリングにより、時間及び無線リソースが浪費される可能性がある。同様に、ＵＥが、ＬＣＳ又はＵＳＳＤを要求する場合、割り当てられるＴＳ１１ベアラは、これらの２つの種類のサービスに適合していない。結果として、これらの状況においてＴＳ１１ベアラをデフォルトで割り当てることは、ターゲットＲＡＮにおける無線リソースの浪費である。
【００１５】
以下で更に詳細に説明するように、エンハンストＣＳＦＢ手順又は最適化ＣＳＦＢ手順（すなわち、ＣＳＦＢとＳＲＶＣＣとの組合せ）中のターゲットＲＡＮへの誤ったリソース割り当てを減少させるために、ネットワーク要素（例えば、ＭＭＥ又はｅＮＢ）は、ＵＥに関する要求されるサービスタイプを判別することができる。要求されるサービスタイプは、音声、ビデオ、ＬＣＳ、又はＵＳＳＤを含み得る。１つの例において、ＵＥは、エンハンストＣＳＦＢ手順がＵＥによってサポートされている場合、要求されるサービスタイプをＵＥに直接通知することができる。ネットワーク要素が、エンハンストＣＳＦＢ手順をトリガする、ＵＥの要求されるタイプを特定すると、ネットワーク要素は、ターゲットＲＡＮに、正確なリソース割り当て（すなわち、ＵＥの要求されるサービスタイプに対応するリソース割り当て）を要求することができる。結果として、誤ったリソース割り当て（すなわち、ＵＥの要求されるタイプに適合しないリソース割り当て）を回避することができ、リソース割り当ては、ＵＥがターゲットＲＡＮに同調した後に再ネゴシエートされる必要がない。
【００１６】
モバイル着信（ＭＴ）回路交換フォールバック（ＣＳＦＢ）の場合、移動通信交換局（ＭＳＣ）は、着信データ又は着信呼から、正確なサービスタイプを特定することができ、ユーザ機器（ＵＥ）のために誤った回路交換（ＣＳ）ベアラを割り当てない。ＭＳＣからモビリティ管理エンティティ（ＭＭＥ）に通信されるページング要求メッセージに、正確なサービスタイプ（例えば、音声、ビデオ、ＵＳＳＤ、ＬＣＳ、又は未知のもの）を含めることができる。したがって、ＭＭＥは、ＭＳＣから受信されたページング要求メッセージに基づいて、ＣＳＦＢをトリガする正確なサービスタイプを判別することができる。以下で更に詳細に説明するように、ＭＭＥが正確なサービスタイプを判別すると、ＭＴ  ｅＣＳＦＢのための第１のソリューション又はＭＴ  ｅＣＳＦＢのための第２のソリューションのいずれかを実施することができる。
【００１７】
上記第１のソリューションにおいて、ＭＭＥは、ＭＳＣから、正確なサービスタイプを含むページング要求メッセージを受信した後、ＣＳＦＢインジケータを含むＳ１アプリケーションプロトコル（Ｓ１−ＡＰ）メッセージを、進化型ノードＢ（ｅＮＢ）に送信することができる。ＣＳＦＢインジケータは、ＵＥにＣＳＦＢが必要とされることを、ｅＮＢに通知することができる。ｅＮＢが、ＭＭＥから、ＣＳＦＢインジケータを含むＳ１−ＡＰメッセージを受信すると、ｅＮＢは、機能グループインジケータ（ＦＧＩ）におけるＵＥのＳＲＶＣＣ機能インジケーションに従って、音声のためのＳＲＶＣＣ手順を開始するか否かを決定することができる。ｅＮＢは、ＵＥから直接ＦＧＩを受信することができる。ＵＥがＳＲＶＣＣに対応している場合、ｅＮＢは、ハンドオーバ要求メッセージをＭＭＥに送信することによって、ＳＲＶＣＣ手順を開始することができる。ＭＭＥが、ｅＮＢから、ハンドオーバ要求メッセージを受信すると、要求されるサービスタイプが音声であれば、ＭＭＥ（ソースＭＭＥとも呼ばれる）は、パケット交換（ＰＳ）から回路交換（ＣＳ）へのＳＲＶＣＣ要求メッセージをＭＳＣに送信することによって、音声要求のための、ＰＳからＣＳへのハンドオーバ手順を開始することができる。ＰＳからＣＳへのＳＲＶＣＣ要求メッセージは、ＩＭＳＩ、ターゲットＩＤ、ＳＴＮ−ＳＲ、Ｃ−ＭＳＩＳＤＮ、ソースからターゲットへの透過コンテナ（source  to  target  transparent  container）、ＭＭコンテキスト、緊急インジケーション、及びＣＳＦＢインジケータを含み得る。ＭＳＣサーバは、ＳＲＶＣＣ手順に進み、シグナリングに加えて音声のためのリソースを準備することができる。要求されるサービスタイプがビデオであれば、ソースＭＭＥは、ＰＳからＣＳへのＳＲＶＣＣ要求メッセージをＭＳＣに送信することによって、要求されるビデオ呼のためのＰＳ−ＣＳハンドオーバ手順を開始することができる。ＰＳからＣＳへのＳＲＶＣＣ要求メッセージは、ＩＭＳＩ、ターゲットＩＤ、ＳＴＮ−ＳＲ、Ｃ−ＭＳＩＳＤＮ、ソースからターゲットへの透過コンテナ、ＭＭコンテキスト、ＣＳＦＢインジケータ、及びｖＳＲＶＣＣフラグを含み得る。ＭＳＣサーバは、ｖＳＲＶＣＣ手順に進み、シグナリングに加えてビデオのためのリソースを準備することができる。要求されるサービスタイプが音声又はビデオ以外であれば、ソースＭＭＥは、ＰＳからＣＳへのＳＲＶＣＣ要求メッセージをＭＳＣサーバに送信することができる。ＰＳからＣＳへのＳＲＶＣＣ要求メッセージは、ＩＭＳＩ、ターゲットＩＤ、ＳＴＮ−ＳＲ、Ｃ−ＭＳＩＳＤＮ、ソースからターゲットへの透過コンテナ、ＭＭコンテキスト、ＣＳＦＢインジケータ、及び非音声非ビデオ（non-voice-or-video）を含み得る。ＭＳＣサーバは、異常（abnormal）ＳＲＶＣＣ手順に進み、シグナリングリソースを準備することができる。
【００１８】
上記第２のソリューションにおいて、ＭＭＥは、ページング要求メッセージにおいて受信されたサービスタイプに従って、新たなＳＲＶＣＣインジケータを使用して、ＳＲＶＣＣ／ｖＳＲＶＣＣが開始されるべきか否かについてｅＮＢに通知することができる。非限定的な例として、新たなＳＲＶＣＣインジケータは、ＳＲＶＣＣ／ｖＳＲＶＣＣもレガシーＣＳＦＢも予期されないことを示す「０」、ＳＲＶＣＣが予期されることを示す「１」、又は、ｖＳＲＶＣＣが予期されることを示す「２」であり得る。ｅＮＢは、Ｓ１−ＡＰメッセージに含まれるこのＳＲＶＣＣインジケータに基づいて、特定のアクションを実行することができる。例えば、ＳＲＶＣＣが予期される場合、ｅＮＢは、３ＧＰＰ  ＴＳ２３．２１６に詳細に規定されているように、ＳＲＶＣＣ手順を開始することができる。ｖＳＲＶＣＣが予期される場合、ｅＮＢは、３ＧＰＰ  ＴＳ２３．２１６に詳細に規定されているように、ｖＳＲＶＣＣ手順を開始することができる。ＳＲＶＣＣ／ｖＳＲＶＣＣもレガシーＣＳＦＢも予期されない場合、ｅＮＢは、３ＧＰＰ  ＴＳ２３．２７２のセクション６．２、６．３、及び６．４に詳細に規定されているように、レガシーＣＳＦＢに進むことができる。ＭＭＥが、ｅＮＢから、ハンドオーバ要求メッセージを受信すると、要求されるサービスタイプが音声であれば、ソースＭＭＥは、ＰＳからＣＳへのＳＲＶＣＣ要求メッセージをＭＳＣサーバに送信することによって、音声要求のためのＰＳ−ＣＳハンドオーバ手順を開始することができる。ＰＳからＣＳへのＳＲＶＣＣ要求メッセージは、ＩＭＳＩ、ターゲットＩＤ、ＳＴＮ−ＳＲ、Ｃ−ＭＳＩＳＤＮ、ソースからターゲットへの透過コンテナ、ＭＭコンテキスト、緊急インジケーション、及びＣＳＦＢインジケータを含み得る。ＭＳＣサーバは、ＳＲＶＣＣ手順に進み、シグナリングに加えて音声のためのリソースを準備することができる。要求されるサービスタイプがビデオであれば、ソースＭＭＥは、ＰＳからＣＳへのＳＲＶＣＣ要求メッセージをＭＳＣサーバに送信することによって、要求されるビデオ呼のためのＰＳ−ＣＳハンドオーバ手順を開始することができる。ＰＳからＣＳへのＳＲＶＣＣ要求メッセージは、ＩＭＳＩ、ターゲットＩＤ、ＳＴＮ−ＳＲ、Ｃ−ＭＳＩＳＤＮ、ソースからターゲットへの透過コンテナ、ＭＭコンテキスト、ＣＳＦＢインジケータ、及びｖＳＲＶＣＣフラグを含み得る。ＭＳＣサーバは、ｖＳＲＶＣＣ手順に進み、シグナリングに加えてビデオのためのリソースを準備することができる。
【００１９】
図１は、例示的なモバイル着信（ＭＴ）エンハンスト回路交換フォールバック（ｅＣＳＦＢ）手順を示している。詳細には、図１は、上述した、ＭＴ  ｅＣＳＦＢのための第１のソリューション又はＭＴ  ｅＣＳＦＢのための第２のソリューションを示し得る。
【００２０】
ＭＴ  ｅＣＳＦＢのための第１のソリューションに関して、ステップ１ａにおいて、単一無線音声通信継続（ＳＲＶＣＣ）移動通信交換局（ＭＳＣ）１１０は、ＳＧインタフェースを介して、ページング要求メッセージをモビリティ管理エンティティ（ＭＭＥ）１０８に送信することができる。ページング要求メッセージは、音声、ビデオ、位置サービス（ＬＣＳ）、非構造付加サービスデータ（ＵＳＳＤ）、又は未知のもの等のサービスタイプを含み得る。ユーザ機器（ＵＥ）１０２が接続モードにある場合、ＭＭＥ１０８は、ＣＳページング通知メッセージをＵＥ１０２に送信することができる。ＵＥ１０２がアイドルモードにある場合、ＭＭＥ１０８は、ページングメッセージを各ｅＮｏｄｅＢ１０４に送信することができ、ｅＮｏｄｅＢ１０４は、ページングメッセージをＵＥ１０２に転送することができる。
【００２１】
ＵＥ１０２が「アイドル」モードにある場合、ＭＭＥ１０８は、ＵＥ１０２がアイドルモードにあったというインジケーションを含むＳＧサービス要求メッセージを、ＭＳＣ１１０に送信することができる。ＭＳＣ１１０が、ＳＧサービス要求メッセージを受信すると、ＭＳＣ１１０は、ＳＧインタフェースページングメッセージの再送信を停止することができる。
【００２２】
ＵＥ１０２が「接続」モードにある場合、ＭＭＥ１０８は、ＵＥ１０２が接続モードにあったというインジケーションを含むＳＧサービス要求メッセージを、ＭＳＣ１１０に送信することができる。ＭＳＣ１１０は、この接続モードインジケーションを使用して、ＵＥ１０２のための無応答タイマにおける呼転送を開始することができ、ＭＳＣ１１０は、ユーザアラートのインジケーションを発呼側に送信する必要がある。ＭＳＣ１１０が、ＳＧサービス要求メッセージを受信すると、ＭＳＣ１１０は、ＳＧインタフェースページングメッセージの再送信を停止することができる。
【００２３】
ステップ１ｂにおいて、ＵＥ１０２は、モバイル着信ＣＳフォールバック（ＣＳＦＢ）のために、拡張サービス要求メッセージをＭＭＥ１０８に送信することができる。拡張サービス要求メッセージは、無線リソース制御（ＲＲＣ）及びＳ１アプリケーションプロトコル（Ｓ１−ＡＰ）メッセージ内にカプセル化され得る。
【００２４】
ステップ１ｃにおいて、ＭＭＥ１０８は、ＣＳフォールバックインジケータを含むＳ１−ＡＰ要求メッセージを、ｅＮｏｄｅＢ１０４に送信することができる。ＣＳＦＢインジケータは、ＵＥ１０２にＣＳＦＢが必要とされることを、ｅＮｏｄｅＢ１０４に通知する。Ｓ１−ＡＰ要求メッセージは、正確なサービスタイプ（例えば、音声、ビデオ、ＵＳＳＤ、ＬＣＳ、未知のもの）を含み得る。
【００２５】
ステップ２ａにおいて、ｅＮｏｄｅＢ１０４は、パケット交換（ＰＳ）ハンドオーバが実行される対象のターゲットＵＴＲＡＮセル又はターゲット移動通信用グローバルシステム（ＧＳＭ（登録商標））ＧＳＭ（登録商標）エボリューション用エンハンストデータレート（ＥＤＧＥ）無線アクセスネットワーク（ＧＥＲＡＮ）セルを決定するために、任意的に、ＵＥ１０２に対して測定レポートを要求してもよい。
【００２６】
ステップ２ｂにおいて、ソースＥ−ＵＴＲＡＮは、ＵＥ測定レポート、ステップ１ｃにおけるＣＳフォールバックインジケータ、及びＵＥのＳＲＶＣＣ機能に基づいて、ＭＭＥ１０８にハンドオーバ要求メッセージを送信することによって、ＵＴＲＡＮ／ＧＥＲＡＮへのＳＲＶＣＣハンドオーバをトリガすることを決定することができる。
【００２７】
ＭＭＥ１０８が、ｅＮＢ１０４から、ハンドオーバ要求メッセージを受信すると、ステップ２ｃにおいて、要求されるサービスタイプが音声であれば、ソースＭＭＥ１０８は、パケット交換（ＰＳ）から回路交換（ＣＳ）へのＳＲＶＣＣ要求メッセージをＭＳＣサーバ１１０に送信することによって、音声要求のための、ＰＳからＣＳへのハンドオーバ手順を開始することができる。ＰＳからＣＳへのＳＲＶＣＣ要求メッセージは、国際移動体加入者識別番号（ＩＭＳＩ）、ターゲット識別子（ＩＤ）、ＳＲＶＣＣのためのセッション転送番号（ＳＴＮ−ＳＲ）、相関移動局統合サービスデジタルネットワーク番号（Ｃ−ＭＳＩＳＤＮ）、ソースからターゲットへの透過コンテナ、ＭＭコンテキスト、緊急インジケーション、及びＣＳＦＢインジケータを含み得る。要求されるサービスタイプがビデオであれば、ソースＭＭＥ１０８は、ＰＳからＣＳへのＳＲＶＣＣ要求メッセージをＭＳＣサーバ１１０に送信することによって、要求されるビデオ呼のためのＰＳ−ＣＳハンドオーバ手順を開始することができる。ＰＳからＣＳへのＳＲＶＣＣ要求メッセージは、ＩＭＳＩ、ターゲットＩＤ、ＳＴＮ−ＳＲ、Ｃ−ＭＳＩＳＤＮ、ソースからターゲットへの透過コンテナ、ＭＭコンテキスト、ＣＳＦＢインジケータ、及びｖＳＲＶＣＣフラグを含み得る。
【００２８】
要求されるサービスタイプが音声又はビデオ以外であれば、ソースＭＭＥ１０８は、ＰＳからＣＳへのＳＲＶＣＣ要求メッセージをＭＳＣサーバ１１０に送信することができる。ＰＳからＣＳへのＳＲＶＣＣ要求メッセージは、ＩＭＳＩ、ターゲットＩＤ、ＳＴＮ−ＳＲ、Ｃ−ＭＳＩＳＤＮ、ソースからターゲットへの透過コンテナ、ＭＭコンテキスト、ＣＳＦＢインジケータ、及び非音声非ビデオを含み得る。ＳＲＶＣＣ手順はＣＳＦＢに起因するものであり、ＱＣＩ＝１のベアラは存在しないため、ＭＭＥ１０８は、ＱＣＩ＝１のベアラを削除する必要がない。
【００２９】
ＭＳＣサーバ１１０が、ＰＳからＣＳへのＳＲＶＣＣ要求メッセージを受信すると、ステップ２ｄにおいて、ＭＳＣサーバ１１０は、ｅＣＳＦＢをトリガするサービスタイプを特定することができる。サービスタイプが音声であれば、ＭＳＣサーバ１１０は、ＳＲＶＣＣ手順に進み、音声のためのリソースを準備することができる。サービスタイプがビデオであれば、ＭＳＣサーバ１１０は、ｖＳＲＶＣＣ手順に進み、シグナリングに加えてビデオのためのリソースを準備することができる。サービスタイプが非音声非ビデオであれば、ＭＳＣサーバ１１０は、異常ＳＲＶＣＣ手順に進み、シグナリングリソースのみを準備することができる。ＳＲＶＣＣは、ＣＳＦＢに起因するため、ＳＲＶＣＣ  ＭＳＣ１１０は、ＩＭＳに対するセッション転送手順を開始せず、レガシーＣＳハンドオーバ準備をトリガするだけである。ＳＲＶＣＣ  ＭＳＣ１１０がターゲットＭＳＣ１１２でない場合、ＳＲＶＣＣ  ＭＳＣ１１０は、ターゲットＭＳＣ１１２にハンドオーバ準備要求メッセージを送信することによって、ＰＳ−ＣＳハンドオーバ要求を、ＣＳインターＭＳＣハンドオーバ要求（CS  inter  MSC  handover  request）と連係させることができる。
【００３０】
ステップ２ｅにおいて、ＭＳＣサーバ１１０は、ＰＳからＣＳへのＳＲＶＣＣ応答（ターゲットからソースへの透過コンテナ）メッセージを、ソースＭＭＥ１０８に送信することができる。
【００３１】
ステップ２ｆにおいて、ソースＭＭＥ１０８は、ハンドオーバコマンド（ターゲットからソースへの透過コンテナ）メッセージを、ソースＥ−ＵＴＲＡＮ（又は、ｅＮｏｄｅＢ１０４）に送信し、次いで、ＵＥ１０２に送信することができる。ハンドオーバコマンドメッセージは、音声コンポーネントに関する情報を含み得る。
【００３２】
ステップ２ｇにおいて、ＵＥ１０２は、再配置／ハンドオーバ完了メッセージを、基地局システム（ＢＳＳ）／無線ネットワークサブシステム（ＲＮＳ）１０６に送信することができる。
【００３３】
ステップ２ｈにおいて、ＢＳＳ／ＲＮＳ１０６は、再配置／ハンドオーバ完了メッセージを、ＳＲＶＣＣ  ＭＳＣ１１０に転送することができる。
【００３４】
ステップ３において、ＵＥ１０２は、ページング応答メッセージをＭＳＣ１１０に送信することができる。
【００３５】
ＵＥ１０２及びＭＭＥ１０８がそれぞれ、ＳＲＶＣＣ手順中にＣＳセキュリティコンテキストを生成しているため、ステップ４において、ＭＳＣ１１０は、認証手順をスキップすることができる。すなわち、ＭＳＣ１１０は、認証要求メッセージをＵＥ１０２に送信する必要がなく、ＵＥ１０２は、認証応答メッセージをＭＳＣ１１０に送信する必要がない。
【００３６】
ステップ２ｈにおいてＲＮＳ／ＢＳＳ１０６から再配置／ハンドオーバ完了メッセージを受信した後、ステップ５において、適用可能なＣＳ呼手順が継続する。３ＧＰＰ  ＴＳ２４．００８に詳細に記載されているように、ＵＥ１０２は、ＴＩ＝０を伴う、ＳＲＶＣＣのための呼インスタンスを生成することができる。この呼インスタンスは、ＳＲＶＣＣ  ＨＯ手順中の着信呼インスタンスに類似している、すなわち、この呼インスタンスは、ＴＩ＝０及びＴＩ  Ｆｌａｇ＝１を伴う。ＵＥ側での衝突を回避するために、ＭＳＣ１１０は、ＴＩ＝０及びＴＩ  Ｆｌａｇ＝０を伴うセットアップメッセージではなく、ＴＩ＝１及びＴＩ  Ｆｌａｇ＝０を伴うセットアップメッセージを送信することができる。
【００３７】
ステップ６において、ＵＥ１０２は、呼確認メッセージをＭＳＣ１１０に送信することができる。
【００３８】
ＣＳ無線アクセスベアラ（ＲＡＢ）が、ＳＲＶＣＣハンドオーバ準備手順中に、既に事前に割り当てられているので、ステップ７において、ＭＳＣ１１０は、ＣＳ  ＲＡＢ割り当て手順をスキップすることができる。すなわち、ＭＳＣ１１０は、ＢＳＳ／ＲＮＳ１０６に対してＲＡＢ割り当てを実行する必要がなく、ＢＳＳ／ＲＮＳ１０６は、ＵＥ１０２に対してＲＡＢセットアップを実行する必要がない。
【００３９】
ステップ８において、ＵＥ１０２は、アラートメッセージをＭＳＣ１１０に送信することができる。
【００４０】
ステップ９において、ＭＳＣ１１０は、接続解除メッセージ（ＴＩ＝０、ＴＩ  Ｆｌａｇ＝０）を送信して、ＳＲＶＣＣ手順中に生成されたダミー呼インスタンスを解放することができる。
【００４１】
ＭＴ  ｅＣＳＦＢのための第２のソリューションに関して、ステップ１ａにおいて、ＭＳＣ１１０は、ＳＧインタフェースを介して、ページング要求メッセージをＭＭＥ１０８に送信することができる。ページング要求メッセージは、サービスタイプ（例えば、音声、ビデオ、ＵＳＳＤ、ＬＣＳ、未知のもの）を含み得る。ＵＥ１０２が接続モードにある場合、ＭＭＥ１０８は、ＣＳページング通知メッセージをＵＥ１０２に送信することができる。ＵＥ１０２がアイドルモードにある場合、ＭＭＥ１０８は、ページングメッセージを各ｅＮｏｄｅＢ１０４に送信することができ、ｅＮｏｄｅＢ１０４は、ページングメッセージをＵＥ１０２に転送することができる。
【００４２】
ＵＥ１０２が「アイドル」モードにある場合、ＭＭＥ１０８は、ＵＥ１０２がアイドルモードにあったというインジケーションを含むＳＧサービス要求メッセージを、ＭＳＣ１１０に送信することができる。ＭＳＣ１１０が、ＳＧサービス要求メッセージを受信すると、ＭＳＣ１１０は、ＳＧインタフェースページングメッセージの再送信を停止することができる。
【００４３】
ＵＥ１０２が「接続」モードにある場合、ＭＭＥ１０８は、ＵＥ１０２が接続モードにあったというインジケーションを含むＳＧサービス要求メッセージを、ＭＳＣ１１０に送信することができる。ＭＳＣ１１０は、この接続モードインジケーションを使用して、ＵＥ１０２のための無応答タイマにおける呼転送を開始することができ、ＭＳＣ１１０は、ユーザアラートのインジケーションを発呼側に送信する必要がある。ＭＳＣ１１０が、ＳＧサービス要求メッセージを受信すると、ＭＳＣ１１０は、ＳＧインタフェースページングメッセージの再送信を停止することができる。
【００４４】
ステップ１ｂにおいて、ＵＥ１０２は、モバイル着信ＣＳフォールバック（ＣＳＦＢ）のために、拡張サービス要求メッセージをＭＭＥ１０８に送信することができる。拡張サービス要求メッセージは、無線リソース制御（ＲＲＣ）及びＳ１アプリケーションプロトコル（Ｓ１−ＡＰ）メッセージ内にカプセル化され得る。
【００４５】
ステップ１ｃにおいて、ＭＭＥ１０８は、ＣＳフォールバックインジケータを含むＳ１−ＡＰ要求メッセージを、ｅＮｏｄｅＢ１０４に送信することができる。
【００４６】
ＭＭＥ１０８は、ページング要求メッセージにおいて受信されたサービスタイプに従って、新たなＳＲＶＣＣインジケータを使用して、ＳＲＶＣＣ／ｖＳＲＶＣＣが開始されるべきか否かについてｅＮｏｄｅＢ１０４に通知することができる。非限定的な例として、新たなＳＲＶＣＣインジケータは、ＳＲＶＣＣ／ｖＳＲＶＣＣもレガシーＣＳＦＢも予期されないことを示す「０」、ＳＲＶＣＣが予期されることを示す「１」、又は、ｖＳＲＶＣＣが予期されることを示す「２」であり得る。ｅＮｏｄｅＢ１０４は、Ｓ１−ＡＰメッセージに含まれるこのＳＲＶＣＣインジケータに基づいて、特定のアクションを実行することができる。例えば、ＳＲＶＣＣが予期される場合、ｅＮｏｄｅＢ１０４は、３ＧＰＰ  ＴＳ２３．２１６に詳細に規定されているように、ＳＲＶＣＣ手順を開始することができる。ｖＳＲＶＣＣが予期される場合、ｅＮｏｄｅＢ１０４は、３ＧＰＰ  ＴＳ２３．２１６に詳細に規定されているように、ｖＳＲＶＣＣ手順を開始することができる。ＳＲＶＣＣ／ｖＳＲＶＣＣもレガシーＣＳＦＢも予期されない場合、ｅＮｏｄｅＢ１０４は、３ＧＰＰ  ＴＳ２３．２７２のセクション６．２、６．３、及び６．４に詳細に規定されているように、レガシーＣＳＦＢに進むことができる。
【００４７】
ステップ２ａにおいて、ｅＮｏｄｅＢ１０４は、パケット交換（ＰＳ）ハンドオーバが実行される対象のターゲットＧＥＲＡＮ／ＵＴＲＡＮセルを決定するために、任意的に、ＵＥ１０２に対して測定レポートを要求してもよい。
【００４８】
ステップ２ｂにおいて、ソースＥ−ＵＴＲＡＮ（又は、ｅＮｏｄｅＢ１０４）は、ＵＥ測定レポート、ステップ１ｃにおけるＣＳフォールバックインジケータ、及びＵＥのＳＲＶＣＣ機能に基づいて、ＭＭＥ１０８にハンドオーバ要求メッセージを送信することによって、ＵＴＲＡＮ／ＧＥＲＡＮへのＵＥ１０２のＳＲＶＣＣハンドオーバをトリガすることを決定することができる。
【００４９】
ＭＭＥ１０８が、ｅＮＢ１０４から、ハンドオーバ要求メッセージを受信すると、ステップ２ｃにおいて、要求されるサービスタイプが音声であれば、ソースＭＭＥ１０８は、ＰＳからＣＳへのＳＲＶＣＣ要求メッセージをＭＳＣサーバ１１０に送信することによって、音声要求のためのＰＳ−ＣＳハンドオーバ手順を開始することができる。ＰＳからＣＳへのＳＲＶＣＣ要求メッセージは、ＩＭＳＩ、ターゲットＩＤ、ＳＴＮ−ＳＲ、Ｃ−ＭＳＩＳＤＮ、ソースからターゲットへの透過コンテナ、ＭＭコンテキスト、緊急インジケーション、及びＣＳＦＢインジケータを含み得る。ＭＳＣサーバ１１０は、ＳＲＶＣＣ手順に進み、シグナリングに加えて音声のためのリソースを準備することができる。要求されるサービスタイプがビデオであれば、ソースＭＭＥ１０８は、ＰＳからＣＳへのＳＲＶＣＣ要求メッセージをＭＳＣサーバ１１０に送信することによって、要求されるビデオ呼のためのＰＳ−ＣＳハンドオーバ手順を開始することができる。ＰＳからＣＳへのＳＲＶＣＣ要求メッセージは、ＩＭＳＩ、ターゲットＩＤ、ＳＴＮ−ＳＲ、Ｃ−ＭＳＩＳＤＮ、ソースからターゲットへの透過コンテナ、ＭＭコンテキスト、ＣＳＦＢインジケータ、及びｖＳＲＶＣＣフラグを含み得る。次いで、ＭＳＣサーバ１１０は、ｖＳＲＶＣＣ手順に進み、シグナリングに加えてビデオのためのリソースを準備することができる。ＭＭＥ１０８は、ＱＣＩ＝１のベアラを削除する必要がない。なぜならば、ＳＲＶＣＣ手順はＣＳＦＢに起因し、ＱＣＩ＝１のベアラは存在しないためである。
【００５０】
ＭＳＣサーバ１１０が、ＰＳからＣＳへのＳＲＶＣＣ要求メッセージを受信すると、ステップ２ｄにおいて、ＭＳＣサーバ１１０は、ｅＣＳＦＢをトリガするサービスタイプを特定することができる。サービスタイプが音声であれば、ＭＳＣサーバ１１０は、ＳＲＶＣＣ手順に進み、音声のためのリソースを準備することができる。サービスタイプがビデオであれば、ＭＳＣサーバ１１０は、ｖＳＲＶＣＣ手順に進み、シグナリングに加えてビデオのためのリソースを準備することができる。ＳＲＶＣＣはＣＳＦＢに起因するため、ＳＲＶＣＣ  ＭＳＣ１１０は、ＩＭＳに対するセッション転送手順を開始せず、レガシーＣＳハンドオーバ準備をトリガするだけである。ＳＲＶＣＣ  ＭＳＣ１１０がターゲットＭＳＣ１１２でない場合、ＳＲＶＣＣ  ＭＳＣ１１０は、ターゲットＭＳＣ１１２にハンドオーバ準備要求メッセージを送信することによって、ＰＳ−ＣＳハンドオーバ要求を、ＣＳインターＭＳＣハンドオーバ要求と連係させることができる。
【００５１】
図１におけるステップ２ｅ〜ステップ９は、上記で提供したステップ２ｅ〜ステップ９の説明と同様である。
【００５２】
モバイル発信（ＭＯ）回路交換フォールバック（ＣＳＦＢ）の場合、以下で更に詳細に説明するように、モビリティ管理エンティティ（ＭＭＥ）が、拡張サービス要求メッセージにおいて、ユーザ機器（ＵＥ）からのＣＳＦＢをトリガする正確なサービスタイプを認識すると、ＭＯ  ｅＣＳＦＢのための第１のソリューション又はＭＯ  ｅＣＳＦＢのための第２のソリューションのいずれかを実施することができる。
【００５３】
上記第１のソリューションにおいて、ＭＭＥは、正確なサービスタイプを含む拡張サービス要求メッセージを受信した後、ＣＳＦＢインジケータを含むＳ１アプリケーションプロトコル（Ｓ１−ＡＰ）メッセージを、進化型ノードＢ（ｅＮＢ）に送信することができる。ｅＮＢが、ＣＳＦＢインジケータを含むＳ１−ＡＰメッセージを受信すると、ｅＮＢは、機能グループインジケータ（ＦＧＩ）におけるＵＥのＳＲＶＣＣ機能インジケーションに従って、音声のためのＳＲＶＣＣ手順を開始するか否かを決定することができる。ｅＮＢは、ＵＥから直接ＦＧＩを受信することができる。ＵＥがＳＲＶＣＣに対応している場合、ｅＮＢは、ＭＭＥにハンドオーバ要求メッセージを送信することによって、ＳＲＶＣＣ手順を開始することができる。ＭＭＥが、ｅＮＢから、ハンドオーバ要求メッセージを受信すると、要求されるサービスタイプが音声であれば、ソースＭＭＥは、パケット交換（ＰＳ）から回路交換（ＣＳ）へのＳＲＶＣＣ要求メッセージを移動通信交換局（ＭＳＣ）サーバに送信することによって、音声要求のための、ＰＳからＣＳへのハンドオーバ手順を開始することができる。ＰＳからＣＳへのＳＲＶＣＣ要求メッセージは、ＩＭＳＩ、ターゲットＩＤ、ＳＴＮ−ＳＲ、Ｃ−ＭＳＩＳＤＮ、ソースからターゲットへの透過コンテナ、ＭＭコンテキスト、緊急インジケーション、及びＣＳＦＢインジケータを含み得る。ＭＳＣサーバは、ＳＲＶＣＣ手順に進み、シグナリングに加えて音声のためのリソースを準備することができる。要求されるサービスタイプがビデオであれば、ソースＭＭＥは、ＰＳからＣＳへのＳＲＶＣＣ要求メッセージをＭＳＣサーバに送信することによって、要求されるビデオ呼のためのＰＳ−ＣＳハンドオーバ手順を開始することができる。ＰＳからＣＳへのＳＲＶＣＣ要求メッセージは、ＩＭＳＩ、ターゲットＩＤ、ＳＴＮ−ＳＲ、Ｃ−ＭＳＩＳＤＮ、ソースからターゲットへの透過コンテナ、ＭＭコンテキスト、ＣＳＦＢインジケータ、及びｖＳＲＶＣＣフラグを含み得る。ＭＳＣサーバは、ｖＳＲＶＣＣ手順に進み、シグナリングに加えてビデオのためのリソースを準備することができる。要求されるサービスタイプが音声又はビデオ以外であれば、ソースＭＭＥは、ＰＳからＣＳへのＳＲＶＣＣ要求メッセージをＭＳＣサーバに送信することができる。ＰＳからＣＳへのＳＲＶＣＣ要求メッセージは、ＩＭＳＩ、ターゲットＩＤ、ＳＴＮ−ＳＲ、Ｃ−ＭＳＩＳＤＮ、ソースからターゲットへの透過コンテナ、ＭＭコンテキスト、ＣＳＦＢインジケータ、及び非音声非ビデオを含み得る。ＭＳＣサーバは、異常ＳＲＶＣＣ手順に進み、シグナリングリソースのみを準備することができる。
【００５４】
上記第２のソリューションにおいて、ＭＭＥは、受信されたサービスタイプに従って、新たなＳＲＶＣＣインジケータを使用して、ＳＲＶＣＣ／ｖＳＲＶＣＣが開始されるべきか否かについてｅＮＢに通知することができる。非限定的な例として、新たなＳＲＶＣＣインジケータは、ＳＲＶＣＣ／ｖＳＲＶＣＣもレガシーＣＳＦＢも予期されないことを示す「０」、ＳＲＶＣＣが予期されることを示す「１」、又は、ｖＳＲＶＣＣが予期されることを示す「２」であり得る。ｅＮＢは、Ｓ１−ＡＰメッセージに含まれるこのＳＲＶＣＣインジケータに基づいて、特定のアクションを実行することができる。例えば、ＳＲＶＣＣが予期される場合、ｅＮＢは、３ＧＰＰ  ＴＳ２３．２１６に詳細に規定されているように、ＳＲＶＣＣ手順を開始することができる。ｖＳＲＶＣＣが予期される場合、ｅＮＢは、３ＧＰＰ  ＴＳ２３．２１６に詳細に規定されているように、ｖＳＲＶＣＣ手順を開始することができる。ＳＲＶＣＣ／ｖＳＲＶＣＣもレガシーＣＳＦＢも予期されない場合、ｅＮＢは、３ＧＰＰ  ＴＳ２３．２７２のセクション６．２、６．３、及び６．４に詳細に規定されているように、レガシーＣＳＦＢに進むことができる。ＭＭＥが、ｅＮＢから、ハンドオーバ要求メッセージを受信すると、要求されるサービスタイプが音声であれば、ソースＭＭＥは、ＰＳからＣＳへのＳＲＶＣＣ要求メッセージをＭＳＣサーバに送信することによって、音声要求のためのＰＳ−ＣＳハンドオーバ手順を開始することができる。ＰＳからＣＳへのＳＲＶＣＣ要求メッセージは、ＩＭＳＩ、ターゲットＩＤ、ＳＴＮ−ＳＲ、Ｃ−ＭＳＩＳＤＮ、ソースからターゲットへの透過コンテナ、ＭＭコンテキスト、緊急インジケーション、及びＣＳＦＢインジケータを含み得る。ＭＳＣサーバは、ＳＲＶＣＣ手順に進み、シグナリングに加えて音声のためのリソースを準備することができる。要求されるサービスタイプがビデオであれば、ソースＭＭＥは、ＰＳからＣＳへのＳＲＶＣＣ要求メッセージをＭＳＣサーバに送信することによって、要求されるビデオ呼のためのＰＳ−ＣＳハンドオーバ手順を開始することができる。ＰＳからＣＳへのＳＲＶＣＣ要求メッセージは、ＩＭＳＩ、ターゲットＩＤ、ＳＴＮ−ＳＲ、Ｃ−ＭＳＩＳＤＮ、ソースからターゲットへの透過コンテナ、ＭＭコンテキスト、ＣＳＦＢインジケータ、及びｖＳＲＶＣＣフラグを含み得る。ＭＳＣサーバは、ｖＳＲＶＣＣ手順に進み、シグナリングに加えてビデオのためのリソースを準備することができる。
【００５５】
モバイル発信（ＭＯ）ｅＣＳＦＢにおいて、ＵＥは、サービスタイプを含む拡張サービス要求メッセージを、ＭＭＥに送信することができる。ＭＭＥは、ＳＲＶＣＣインジケータを含むＳ１−ＡＰ要求メッセージを送信することができる。Ｓ１−ＡＰメッセージは、ＵＥがＵＴＲＡＮ／ＧＥＲＡＮに移されるべきであることを、ｅＮＢに示すことができる。ｅＮＢが、Ｓ１−ＡＰ要求メッセージを受信すると、ｅＮＢは、２つのアクションのうちの１つを実行することができる。ＵＥが、ＦＧＩにおけるＳＲＶＣＣ機能を示し、かつ、ＭＭＥからのＳＲＶＣＣインジケータが、レガシーＣＳＦＢを示すだけではない場合、ｅＮＢは、ｅＮＢのためのＱＣＩ＝１のベアラが存在しない場合であっても、ＳＲＶＣＣ／ｖＳＲＶＣＣ手順を開始することができる。ＵＥが、ＦＧＩにおけるＳＲＶＣＣ機能を示すが、ＭＭＥからのＳＲＶＣＣインジケータが、レガシーＣＳＦＢを示すだけである場合、ｅＮＢは、ＳＲＶＣＣ／ｖＳＲＶＣＣ手順を開始するのではなく、ＴＳ２３．２７２に規定されているように、レガシーＣＳＦＢ手順に進む。ＳＲＶＣＣの場合、ＣＳＦＢによりトリガされる手順のためのＱＣＩ＝１のベアラが存在しないため、ＭＭＥは、ＱＣＩ＝１のベアラを削除する必要がない。ｖＳＲＶＣＣの場合、ＣＳＦＢによりトリガされる手順のための、ＱＣＩ＝１のベアラ及びｖＳＲＶＣＣがマーキングされたＰＳベアラが存在しないため、ＭＭＥは、ＱＣＩ＝１のベアラ及びｖＳＲＶＣＣがマーキングされたＰＳベアラを削除する必要がない。
【００５６】
図２は、例示的なモバイル発信（ＭＯ）エンハンスト回路交換フォールバック（ｅＣＳＦＢ）手順を示している。詳細には、図２は、上述した、ＭＯ  ｅＣＳＦＢのための第１のソリューション又はＭＯ  ｅＣＳＦＢのための第２のソリューションを示し得る。
【００５７】
ＭＯ  ｅＣＳＦＢのための第１のソリューションに関して、ステップ１ａにおいて、ユーザ機器（ＵＥ）２０２は、モバイル発信ＣＳフォールバックのために、拡張サービス要求メッセージをモビリティ管理エンティティ（ＭＭＥ）２０８に送信することができる。拡張サービス要求メッセージは、音声、ビデオ、位置サービス（ＬＣＳ）、非構造付加サービスデータ（ＵＳＳＤ）、又は未知のもの等のサービスタイプを含み得る。
【００５８】
ステップ１ｂにおいて、ＭＭＥ２０８は、ＣＳフォールバックインジケータを含むＳ１−ＡＰ要求メッセージをｅＮｏｄｅＢ２０４に送信することができる。
【００５９】
ステップ２ａにおいて、ｅＮｏｄｅＢ２０４は、パケット交換（ＰＳ）ハンドオーバが実行される対象のターゲットＧＥＲＡＮ／ＵＴＲＡＮセルを決定するために、任意的に、ＵＥ２０２に対して測定レポートを要求してもよい。
【００６０】
ステップ２ｂにおいて、ソースＥ−ＵＴＲＡＮは、ＵＥ測定レポート、ステップ１ｂにおけるＣＳフォールバックインジケータ、及びＵＥのＳＲＶＣＣ機能に基づいて、ＭＭＥ２０８にハンドオーバ要求メッセージを送信することによって、ＵＴＲＡＮ／ＧＥＲＡＮへのＳＲＶＣＣハンドオーバをトリガすることを決定することができる。
【００６１】
ＭＭＥ２０８が、ｅＮＢ２０４から、ハンドオーバ要求メッセージを受信すると、ステップ２ｃにおいて、要求されるサービスタイプが音声であれば、ソースＭＭＥ２０８は、パケット交換（ＰＳ）から回路交換（ＣＳ）へのＳＲＶＣＣ要求メッセージをＭＳＣサーバ２１０に送信することによって、音声要求のための、ＰＳからＣＳへのハンドオーバ手順を開始することができる。ＰＳからＣＳへのＳＲＶＣＣ要求メッセージは、国際移動体加入者識別番号（ＩＭＳＩ）、ターゲット識別子（ＩＤ）、ＳＲＶＣＣのためのセッション転送番号（ＳＴＮ−ＳＲ）、相関移動局統合サービスデジタルネットワーク番号（Ｃ−ＭＳＩＳＤＮ）、ソースからターゲットへの透過コンテナ、ＭＭコンテキスト、緊急インジケーション、及びＣＳＦＢインジケータを含み得る。要求されるサービスタイプがビデオであれば、ソースＭＭＥ２０８は、ＰＳからＣＳへのＳＲＶＣＣ要求メッセージをＭＳＣサーバ２１０に送信することによって、要求されるビデオ呼のためのＰＳ−ＣＳハンドオーバ手順を開始することができる。ＰＳからＣＳへのＳＲＶＣＣ要求メッセージは、ＩＭＳＩ、ターゲットＩＤ、ＳＴＮ−ＳＲ、Ｃ−ＭＳＩＳＤＮ、ソースからターゲットへの透過コンテナ、ＭＭコンテキスト、ＣＳＦＢインジケータ、及びｖＳＲＶＣＣフラグを含み得る。要求されるサービスタイプが音声又はビデオ以外であれば、ソースＭＭＥ２０８は、ＰＳからＣＳへのＳＲＶＣＣ要求メッセージをＭＳＣサーバ２１０に送信することができる。ＰＳからＣＳへのＳＲＶＣＣ要求メッセージは、ＩＭＳＩ、ターゲットＩＤ、ＳＴＮ−ＳＲ、Ｃ−ＭＳＩＳＤＮ、ソースからターゲットへの透過コンテナ、ＭＭコンテキスト、ＣＳＦＢインジケータ、及び非音声非ビデオを含み得る。ＳＲＶＣＣ手順はＣＳＦＢに起因するものであり、ＱＣＩ＝１のベアラは存在しないため、ＭＭＥ２０８は、ＱＣＩ＝１のベアラを削除する必要がない。
【００６２】
ＭＳＣサーバ２１０が、ＰＳからＣＳへのＳＲＶＣＣ要求メッセージを受信すると、ステップ２ｄにおいて、ＭＳＣサーバ２１０は、ｅＣＳＦＢをトリガするサービスタイプを特定することができる。サービスタイプが音声であれば、ＭＳＣサーバ２１０は、ＳＲＶＣＣ手順に進み、音声のためのリソースを準備することができる。サービスタイプがビデオであれば、ＭＳＣサーバ２１０は、ｖＳＲＶＣＣ手順に進み、シグナリングに加えてビデオのためのリソースを準備することができる。サービスタイプが非音声非ビデオであれば、ＭＳＣサーバ２１０は、異常ＳＲＶＣＣ手順に進み、シグナリングリソースのみを準備することができる。ＳＲＶＣＣはＣＳＦＢに起因するため、ＳＲＶＣＣ  ＭＳＣ２１０は、ＩＭＳに対するセッション転送手順を開始せず、レガシーＣＳハンドオーバ準備をトリガするだけである。ＳＲＶＣＣ  ＭＳＣ２１０がターゲットＭＳＣ２１２でない場合、ＳＲＶＣＣ  ＭＳＣ２１０は、ターゲットＭＳＣ２１２にハンドオーバ準備要求メッセージを送信することによって、ＰＳ−ＣＳハンドオーバ要求を、ＣＳインターＭＳＣハンドオーバ要求と連係させることができる。
【００６３】
ステップ２ｅにおいて、ソースＭＭＥ２０８は、ハンドオーバコマンド（ターゲットからソースへの透過コンテナ）メッセージを、ソースＥ−ＵＴＲＡＮ（又は、ｅＮｏｄｅＢ２０４）に送信し、次いで、ＵＥ２０２に送信することができる。ハンドオーバコマンドメッセージは、音声コンポーネントに関する情報を含み得る。
【００６４】
ステップ２ｇにおいて、ＵＥ２０２は、再配置／ハンドオーバ完了メッセージを、基地局システム（ＢＳＳ）／無線ネットワークサブシステム（ＲＮＳ）２０６に送信することができる。
【００６５】
ステップ２ｈにおいて、ＢＳＳ／ＲＮＳ２０６は、再配置／ハンドオーバ完了メッセージをＳＲＶＣＣ  ＭＳＣ２１０に転送することができる。
【００６６】
ステップ３において、ＵＥ２０２は、ＣＭサービス要求メッセージをＭＳＣ２１０に送信することができる。
【００６７】
ＵＥ２０２及びＭＭＥ２０８がそれぞれ、ＳＲＶＣＣ手順中にＣＳセキュリティコンテキストを生成しているため、ステップ４において、ＭＳＣ２１０は、認証手順をスキップすることができる。すなわち、ＭＳＣ２１０は、認証要求メッセージをＵＥ２０２に送信する必要がなく、ＵＥ２０２は、認証応答メッセージをＭＳＣ２１０に送信する必要がない。
【００６８】
ステップ５において、ＵＥ２０２は、ＭＳＣ２１０から、ＣＭサービス受理メッセージを受信することができ、ＵＥ２０２は、その後、ＣＳ呼手順に進むことができる。
【００６９】
ステップ６において、ＵＥ２０２は、ＴＩ＝０及びＴＩ  Ｆｌａｇ＝０を伴うセットアップメッセージをＭＳＣ２１０に送信することによって、ＣＳ呼手順に進むことができる。３ＧＰＰ  ＴＳ２４．００８に詳細に記載されているように、ＵＥ２０２は、ＴＩ＝０を伴う、ＳＲＶＣＣのための呼インスタンスを生成することができる。この呼インスタンスは、ＳＲＶＣＣ  ＨＯ手順中の着信呼インスタンスに類似している、すなわち、この呼インスタンスは、ＴＩ＝０及びＴＩ  Ｆｌａｇ＝１を伴う。
【００７０】
ステップ７において、ＭＳＣ２１０は、呼設定受付メッセージをＵＥ２０２に送信することができる。
【００７１】
ＣＳ無線アクセスベアラ（ＲＡＢ）が、ＳＲＶＣＣハンドオーバ準備手順中に既に事前に割り当てられているため、ステップ８において、ＭＳＣ１１０は、ＣＳ  ＲＡＢ割り当て手順をスキップすることができる。すなわち、ＭＳＣ２１０は、ＢＳＳ／ＲＮＳ２０６に対してＲＡＢ割り当てを実行する必要がなく、ＢＳＳ／ＲＮＳ２０６は、ＵＥ２０２に対してＲＡＢセットアップを実行する必要がない。
【００７２】
ステップ９において、ＭＳＣ２１０は、アラートメッセージをＵＥ２０２に送信することができる。
【００７３】
ステップ１０において、ＭＳＣ２１０は、接続解除メッセージ（ＴＩ＝０、ＴＩ  Ｆｌａｇ＝０）を送信して、ＳＲＶＣＣ手順中に生成されたダミー呼インスタンスを解放することができる。
【００７４】
ＭＯ  ｅＣＳＦＢのための第２のソリューションに関して、ステップ１ａにおいて、ＵＥ２０２は、モバイル発信ＣＳフォールバックのために、拡張サービス要求メッセージをＭＭＥ２０８に送信することができる。拡張サービス要求メッセージは、正確なサービスタイプ（例えば、音声、ビデオ、ＵＳＳＤ、ＬＣＳ、未知のもの）を含み得る。
【００７５】
ステップ１ｂにおいて、ＭＭＥ２０８は、ＣＳフォールバックインジケータを含むＳ１−ＡＰ要求メッセージを、ｅＮｏｄｅＢ２０４に送信することができる。ＭＭＥ２０８は、受信されたサービスタイプに従って、新たなＳＲＶＣＣインジケータを使用して、ＳＲＶＣＣ／ｖＳＲＶＣＣが開始されるべきか否かについてｅＮｏｄｅＢ２０４に通知することができる。非限定的な例として、新たなＳＲＶＣＣインジケータは、ＳＲＶＣＣ／ｖＳＲＶＣＣもレガシーＣＳＦＢも予期されないことを示す「０」、ＳＲＶＣＣが予期されることを示す「１」、又は、ｖＳＲＶＣＣが予期されることを示す「２」であり得る。ｅＮｏｄｅＢ２０４は、Ｓ１−ＡＰメッセージに含まれるこのＳＲＶＣＣインジケータに基づいて、特定のアクションを実行することができる。例えば、ＳＲＶＣＣが予期される場合、ｅＮｏｄｅＢ２０４は、３ＧＰＰ  ＴＳ２３．２１６に詳細に規定されているように、ＳＲＶＣＣ手順を開始することができる。ｖＳＲＶＣＣが予期される場合、ｅＮｏｄｅＢ２０４は、３ＧＰＰ  ＴＳ２３．２１６に詳細に規定されているように、ｖＳＲＶＣＣ手順を開始することができる。ＳＲＶＣＣ／ｖＳＲＶＣＣもレガシーＣＳＦＢも予期されない場合、ｅＮｏｄｅＢ２０４は、３ＧＰＰ  ＴＳ２３．２７２のセクション６．２、６．３、及び６．４に詳細に規定されているように、レガシーＣＳＦＢに進むことができる。
【００７６】
ステップ２ａにおいて、ｅＮｏｄｅＢ２０４は、パケット交換（ＰＳ）ハンドオーバが実行される対象のターゲットＧＥＲＡＮ／ＵＴＲＡＮセルを決定するために、任意的に、ＵＥ２０２に対して測定レポートを要求してもよい。
【００７７】
ステップ２ｂにおいて、ソースＥ−ＵＴＲＡＮは、ＵＥ測定レポート、ステップ１ｂにおけるＣＳフォールバックインジケータ、及び機能グループインジケータ（ＦＧＩ）におけるＵＥのＳＲＶＣＣ機能に基づいて、ＭＭＥ２０８にハンドオーバ要求メッセージを送信することによって、ＵＴＲＡＮ／ＧＥＲＡＮへのＳＲＶＣＣハンドオーバ又はｖＳＲＶＣＣハンドオーバをトリガすることを決定することができる。
【００７８】
ＭＭＥ２０８が、ｅＮＢ２０４から、ハンドオーバ要求メッセージを受信すると、ステップ２ｃにおいて、要求されるサービスタイプが音声であれば、ソースＭＭＥ２０８は、パケット交換（ＰＳ）から回路交換（ＣＳ）へのＳＲＶＣＣ要求メッセージをＭＳＣサーバ２１０に送信することによって、音声要求のための、ＰＳからＣＳへのハンドオーバ手順を開始することができる。ＰＳからＣＳへのＳＲＶＣＣ要求メッセージは、国際移動体加入者識別番号（ＩＭＳＩ）、ターゲット識別子（ＩＤ）、ＳＲＶＣＣのためのセッション転送番号（ＳＴＮ−ＳＲ）、相関移動局統合サービスデジタルネットワーク番号（Ｃ−ＭＳＩＳＤＮ）、ソースからターゲットへの透過コンテナ、ＭＭコンテキスト、緊急インジケーション、及びＣＳＦＢインジケータを含み得る。要求されるサービスタイプがビデオであれば、ソースＭＭＥ２０８は、ＰＳからＣＳへのＳＲＶＣＣ要求メッセージをＭＳＣサーバ２１０に送信することによって、要求されるビデオ呼のためのＰＳ−ＣＳハンドオーバ手順を開始することができる。ＰＳからＣＳへのＳＲＶＣＣ要求メッセージは、ＩＭＳＩ、ターゲットＩＤ、ＳＴＮ−ＳＲ、Ｃ−ＭＳＩＳＤＮ、ソースからターゲットへの透過コンテナ、ＭＭコンテキスト、ＣＳＦＢインジケータ、及びｖＳＲＶＣＣフラグを含み得る。ＭＳＣサーバ２１０は、ｖＳＲＶＣＣ手順に進み、シグナリングに加えてビデオのためのリソースを準備することができる。ＭＭＥ２０８は、ＱＣＩ＝１のベアラを削除する必要がない。なぜならば、ＳＲＶＣＣ手順はＣＳＦＢに起因し、ＱＣＩ＝１のベアラは存在しないためである。
【００７９】
ＭＳＣサーバ２１０が、ＰＳからＣＳへのＳＲＶＣＣ要求メッセージを受信すると、ステップ２ｄにおいて、ＭＳＣサーバ２１０は、ｅＣＳＦＢをトリガするサービスタイプを特定することができる。サービスタイプが音声であれば、ＭＳＣサーバ２１０は、ＳＲＶＣＣ手順に進み、音声のためのリソースを準備することができる。サービスタイプがビデオであれば、ＭＳＣサーバ２１０は、ｖＳＲＶＣＣ手順に進み、シグナリングに加えてビデオのためのリソースを準備することができる。ＳＲＶＣＣはＣＳＦＢに起因するため、ＳＲＶＣＣ  ＭＳＣ２１０は、ＩＭＳに対するセッション転送手順を開始せず、レガシーＣＳハンドオーバ準備をトリガするだけである。ＳＲＶＣＣ  ＭＳＣ２１０がターゲットＭＳＣ２１２でない場合、ＳＲＶＣＣ  ＭＳＣ２１０は、ターゲットＭＳＣ２１２にハンドオーバ準備要求メッセージを送信することによって、ＰＳ−ＣＳハンドオーバ要求を、ＣＳインターＭＳＣハンドオーバ要求と連係させることができる。
【００８０】
図２におけるステップ２ｅ〜ステップ１０は、上記で提供したステップ２ｅ〜ステップ１０の説明と同様である。
【００８１】
図３は、単一無線音声通信継続（ＳＲＶＣＣ）手順を含む例示的なエンハンスト回路交換フォールバック（ＣＳＦＢ）手順を示している。すなわち、エンハンストＣＳＦＢ手順は、ＣＳＦＢをＳＲＶＣＣと組み合わせる。詳細には、図３は、ＵＥのエンハンストＣＳＦＢ機能が、ｅＮＢ及びＭＭＥ等の様々なネットワーク要素に通信されるいくつかの技術を示している。ＵＥが、エンハンストＣＳＦＢ機能をサポートしている場合、Ｅ−ＵＴＲＡＮは、ＭＭＥからＣＳフォールバックインジケータを含むＳ１−ＡＰメッセージを受信すると、ＳＲＶＣＣ手順を開始することができる。エンハンストＣＳＦＢ機能に関するＵＥのサポートのインジケーションは、Ｓ１−ＡＰメッセージに含められ得る。Ｓ１−ＡＰメッセージが、ＵＥがエンハンストＣＳＦＢ機能をサポートしていないことを示す場合、ｅＮＢは、ＳＲＶＣＣ手順を開始しない。エンハンストＣＳＦＢの場合、Ｅ−ＵＴＲＡＮ内のＵＥのためのＱＣＩ＝１のベアラが存在しない。例えば、第１の技術において、ＵＥのエンハンストＣＳＦＢ機能は、拡張サービス要求メッセージを介して、ネットワーク要素に通信される。第２の技術において、ＵＥのエンハンストＣＳＦＢ機能は、ＵＥの加入者プロファイルに基づいて判別される。第３の技術において、ＵＥのエンハンストＣＳＦＢ機能は、非アクセス層（ＮＡＳ）メッセージを介して、ネットワーク要素に通信される。第４の技術において、ＵＥのエンハンストＣＳＦＢ機能は、機能グループインジケータ（ＦＧＩ）を介して判別される。
【００８２】
図３を参照すると、上記第１の技術に関して、ステップ１において、移動通信交換局（ＭＳＣ）３１０又はビジタロケーションレジスタ（ＶＬＲ）は、ネットワークにより開始される回路交換（ＣＳ）手順のためのトリガを受信することができる。
【００８３】
ステップ１ａにおいて、ＭＳＣ３１０は、ＳＧインタフェースを介して、モビリティ管理エンティティ（ＭＭＥ）３０８にページング要求メッセージを送信することによって応答することができる。呼独立付加サービス（call  independent  supplementary  service）の場合、ページング要求メッセージは、ＳＳサービスＩＤを含み得る。ＭＭＥ３０８が、アタッチ手順、複合追跡エリア（ＴＡ）更新手順、又は位置エリア（ＬＡ）更新手順中に、「ＳＭＳのみ」のインジケーション（”SMS-only”  indication）をＵＥ３０２に返さなかった場合、ＭＭＥ３０８は、ページングメッセージをＵＥ３０２に送信することができる。
【００８４】
呼独立付加サービスの場合、ページング要求メッセージは、ＳＳサービスＩＤを含み得る。ＳＳサービスＩＤを使用して、付加サービスのタイプを、ＵＥに示すことができる。ＳＳサービスＩＤは、ＵＥ３０２がアクティブモードにあるとき、ページング要求メッセージに含められ得る。
【００８５】
ＭＭＥ３０８が、アタッチ手順、複合追跡エリア（ＴＡ）更新手順、又は位置エリア（ＬＡ）更新手順中に、「ＳＭＳのみ」のインジケーションをＵＥ３０２に返した場合、ＭＭＥ３０８は、ページングメッセージをＵＥ３０２に送信せず、ＭＭＥ３０８は、ＣＳページング拒否メッセージをＭＳＣ３１０に送信して、ＣＳページング手順を停止し、これによってＣＳＦＢ手順を停止する。
【００８６】
ＵＥ３０２が接続モードにある場合、ＭＭＥ３０８は、ＣＳページング通知メッセージをＵＥ３０２に送信することができる。ＵＥ３０２がアイドルモードにある場合、ＭＭＥ３０８は、ページングメッセージを各ｅＮｏｄｅＢ３０４に送信することができ、ｅＮｏｄｅＢ３０４は、ページングメッセージをＵＥ３０２に転送することができる。
【００８７】
ステップ１ｂにおいて、ＵＥ３０２は、モバイル着信ＣＳフォールバックのために、（拒否又は受理を伴う）拡張サービス要求メッセージをＭＭＥ３０８に送信することができる。拡張サービス要求メッセージは、無線リソース制御（ＲＲＣ）及びＳ１−ＡＰメッセージ内にカプセル化され得る。拡張サービス要求メッセージは、ＵＥがこの機能をサポートしている場合（すなわち、ＵＥがエンハンストＣＳＦＢをサポートしている場合）、エンハンストＣＳＦＢインジケータを含み得る。
【００８８】
ＭＭＥ３０８が、エンハンストＣＳＦＢインジケータを含む、モバイル着信ＣＳフォールバックのための（拒否を伴う）拡張サービス要求を受信すると、ステップ１ｃにおいて、ＭＭＥ３０８は、ページング拒否メッセージをＭＳＣ３１０に送信して、ＣＳページング手順を停止し、これによってＣＳＦＢ手順を停止することができる。
【００８９】
ステップ１ｄにおいて、ＭＭＥ３０８は、ＵＥ無線機能及びエンハンストＣＳフォールバックインジケータを含むＳ１−ＡＰ要求メッセージを、ｅＮｏｄｅＢ３０４に送信することができる。このＳ１−ＡＰ要求メッセージは、ＵＥ３０２がＵＴＲＡＮ／ＧＥＲＡＮに移されるべきであることを、ｅＮｏｄｅＢ３０４に示すことができる。
【００９０】
ステップ１ｅにおいて、ｅＮｏｄｅＢ３０４は、Ｓ１−ＡＰ応答メッセージを用いて応答することができる。
【００９１】
ステップ２において、３ＧＰＰ  ＴＳ２３．２７２に詳細に規定されているように、任意的な測定レポート及び要求ステップが実行されてもよい。これらのステップは、節７．３において、ＰＳハンドオーバがサポートされる事例について詳細に規定されており、節７．４において、ＰＳハンドオーバがサポートされない事例について詳細に規定されている。
【００９２】
ステップ３において、ソースＥ−ＵＴＲＡＮ（又は、ｅＮｏｄｅＢ３０４）は、ＵＥ測定レポート、エンハンストＣＳフォールバックインジケータ、及びステップ１ｄにおけるＵＥのＳＲＶＣＣ機能に基づいて、ＵＴＲＡＮ／ＧＥＲＡＮへのＵＥのＳＲＶＣＣハンドオーバをトリガすることを決定することができる。ＵＥ３０２がＳＲＶＣＣをサポートしていない場合、レガシーＣＳＦＢ手順が実行され得る。
【００９３】
Ｅ−ＵＴＲＡＮは、ＱＣＩ＝１のベアラが存在せず、かつ、ｖＳＲＶＣＣがマーキングされたビデオベアラが存在しない場合、ＣＳＦＢのためのＵＴＲＡＮ／ＧＥＲＡＮへのＳＲＶＣＣハンドオーバをトリガすることができる。ＭＭＥ３０８は、ＳＲＶＣＣがＣＳＦＢに起因するというＣＳＦＢインジケーションを含む、ＰＳからＣＳへのＳＲＶＣＣ要求メッセージを送信することができる。ＭＭＥ３０８は、他のＰＳベアラからのベアラ分離を実行する必要がない。ＭＭＥ３０８は、ＱＣＩ＝１のベアラ及びｖＳＲＶＣＣがマーキングされたビデオベアラを削除しない。なぜならば、ＳＲＶＣＣ手順はＣＳＦＢに起因し、ＱＣＩ＝１のベアラ及びｖＳＲＶＣＣがマーキングされたビデオベアラは存在しないためである。ＳＲＶＣＣはＣＳＦＢに起因するため、ＭＳＣ３１０は、セッション転送手順を開始せず、レガシーＣＳハンドオーバ準備をトリガするだけである。
【００９４】
ステップ３においてＲＮＳ／ＢＳＳ３０６から再配置／ハンドオーバ完了メッセージを受信した後、ステップ４において、ＣＳ手順は継続することができる。
【００９５】
図３を参照すると、上記第２の技術に関して、ＭＭＥ３０８は、ＵＥの加入者プロファイルに基づいて、ＵＥのエンハンストＣＳＦＢ機能を判別することができる。ＭＭＥ３０８は、ホーム加入者サーバ（ＨＳＳ）から加入者プロファイルを受信することができる。１つの例において、加入者プロファイルは、３ＧＰＰ  ＴＳ２３．４０１セクション５．３．２．１に詳細に規定されているように、位置更新確認応答メッセージに含められ得る。別の例において、ＵＥのエンハンストＣＳＦＢ機能は、アタッチ手順中に、ＭＭＥ３０８に提供され得る。
【００９６】
ステップ１において、ＭＳＣ３１０又はＶＬＲは、ネットワークにより開始される回路交換（ＣＳ）手順のためのトリガを受信することができる。
【００９７】
ステップ１ａにおいて、ＭＳＣ３１０は、ＳＧインタフェースを介してＭＭＥ３０８にページング要求メッセージを送信することによって応答することができる。
【００９８】
ステップ１ｂにおいて、ＵＥ３０２は、モバイル着信ＣＳフォールバックのために、（拒否又は受理を伴う）拡張サービス要求メッセージをＭＭＥ３０８に送信することができる。拡張サービス要求メッセージは、無線リソース制御（ＲＲＣ）及びＳ１−ＡＰメッセージ内にカプセル化され得る。
【００９９】
ＭＭＥ３０８が、モバイル着信ＣＳフォールバックのための（拒否を伴う）拡張サービス要求を受信すると、ステップ１ｃにおいて、ＭＭＥ３０８は、ページング拒否メッセージをＭＳＣ３１０に送信して、ＣＳページング手順を停止し、これによってＣＳＦＢ手順を停止することができる。
【０１００】
ステップ１ｄにおいて、ＭＭＥ３０８は、ＵＥ無線機能及びＵＥのためのエンハンストＣＳフォールバックインジケータを含むＳ１−ＡＰ要求メッセージを、ｅＮｏｄｅＢ３０４に送信することができる。前述したように、ＭＭＥ３０８は、ＨＳＳから受信されたＵＥの加入者プロファイルに基づいて、エンハンストＣＳフォールバックインジケータを前もって判別することができる。このＳ１−ＡＰ要求メッセージは、ＵＥ３０２がＵＴＲＡＮ／ＧＥＲＡＮに移されるべきであることを、ｅＮｏｄｅＢ３０４に示すことができる。
【０１０１】
ステップ１ｅにおいて、ｅＮｏｄｅＢ３０４は、Ｓ１−ＡＰ応答メッセージを用いて応答することができる。
【０１０２】
図３におけるステップ２、ステップ３、及びステップ４は、前述したとおりである。
【０１０３】
図３を参照すると、上記第３の技術に関して、ＭＭＥ３０８は、ＭＭＥ３０８において受信されたアタッチ要求メッセージ又は追跡エリア更新（ＴＡＵ）メッセージに基づいて、ＵＥのエンハンストＣＳＦＢ機能を判別することができる。すなわち、ＭＭＥ３０８は、アタッチ手順又はＴＡＵ手順中に、ＮＡＳメッセージにおいてＵＥネットワーク機能を受信することができ、ＵＥネットワーク機能は、ＵＥのエンハンストＣＳＦＢ機能を示すことができる。１つの例において、ＮＡＳメッセージは、ＵＥ３０２がエンハンストＣＳＦＢをサポートしていることを示す「１」、又は、ＵＥ３０２がエンハンストＣＳＦＢをサポートしていないことを示す「０」を含み得る。アタッチ手順は、３ＧＰＰ  ＴＳ２３．４０１セクション５．３．２．１において詳細に規定されており、追跡エリア更新（ＴＡＵ）手順は、３ＧＰＰ  ＴＳ２３．４０１セクション５．３．３．１において詳細に規定されている。
【０１０４】
ステップ１において、ＭＳＣ３１０又はＶＬＲは、ネットワークにより開始される回路交換（ＣＳ）手順のためのトリガを受信することができる。
【０１０５】
ステップ１ａにおいて、ＭＳＣ３１０は、ＳＧインタフェースを介してＭＭＥ３０８にページング要求メッセージを送信することによって応答することができる。
【０１０６】
ステップ１ｂにおいて、ＵＥ３０２は、モバイル着信ＣＳフォールバックのために、（拒否又は受理を伴う）拡張サービス要求メッセージをＭＭＥ３０８に送信することができる。拡張サービス要求メッセージは、無線リソース制御（ＲＲＣ）及びＳ１−ＡＰメッセージ内にカプセル化され得る。
【０１０７】
ＭＭＥ３０８が、モバイル着信ＣＳフォールバックのための（拒否を伴う）拡張サービス要求を受信すると、ステップ１ｃにおいて、ＭＭＥ３０８は、ページング拒否メッセージをＭＳＣ３１０に送信して、ＣＳページング手順を停止し、これによってＣＳＦＢ手順を停止することができる。
【０１０８】
ステップ１ｄにおいて、ＭＭＥ３０８は、ＵＥ無線機能及びＵＥのためのエンハンストＣＳフォールバックインジケータを含むＳ１−ＡＰ要求メッセージを、ｅＮｏｄｅＢ３０４に送信することができる。ＵＥネットワーク機能におけるエンハンストＣＳフォールバックインジケータが真に設定されている場合、エンハンストＣＳフォールバックインジケータが、Ｓ１−ＡＰ要求メッセージに含められ得る。前述したように、ＭＭＥ３０８は、アタッチ手順又はＴＡＵ手順中にＵＥ３０２から受信したＮＡＳメッセージに基づいて、エンハンストＣＳフォールバックインジケータを前もって判別することができる。このＳ１−ＡＰ要求メッセージは、ＵＥ３０２がＵＴＲＡＮ／ＧＥＲＡＮに移されるべきであることを、ｅＮｏｄｅＢ３０４に示すことができる。
【０１０９】
ステップ１ｅにおいて、ｅＮｏｄｅＢ３０４は、Ｓ１−ＡＰ応答メッセージを用いて応答することができる。
【０１１０】
図３におけるステップ２、ステップ３、及びステップ４は、前述したとおりである。
【０１１１】
図３を参照すると、上記第４の技術に関して、ｅＮｏｄｅＢ３０４は、ＵＥ３０２から受信された機能グループインジケータ（ＦＧＩ）に基づいて、ＵＥのエンハンストＣＳＦＢ機能を判別することができる。別の例において、ＵＥのエンハンストＣＳＦＢ機能は、ＵＥ３０２からｅＮｏｄｅＢ３０４に提供されるＵＥ無線アクセス機能パラメータに含められ得る。ｅＮｏｄｅＢ３０４は、ＵＥのエンハンストＣＳＦＢ機能を、ＭＭＥ３０８に提供することができる。機能グループインジケータ（ＦＧＩ）及びＵＥ−ＥＵＴＲＡ機能は、３ＧＰＰ  ＴＳ３６．３３１セクションＢ．１において詳細に規定されている。
【０１１２】
ステップ１において、ＭＳＣ３１０又はＶＬＲは、ネットワークにより開始される回路交換（ＣＳ）手順のためのトリガを受信することができる。
【０１１３】
ステップ１ａにおいて、ＭＳＣ３１０は、ＳＧインタフェースを介してＭＭＥ３０８にページング要求メッセージを送信することによって応答することができる。
【０１１４】
ステップ１ｂにおいて、ＵＥ３０２は、モバイル着信ＣＳフォールバックのために、（拒否又は受理を伴う）拡張サービス要求メッセージをＭＭＥ３０８に送信することができる。拡張サービス要求メッセージは、無線リソース制御（ＲＲＣ）及びＳ１−ＡＰメッセージ内にカプセル化され得る。
【０１１５】
ＭＭＥ３０８が、モバイル着信ＣＳフォールバックのための（拒否を伴う）拡張サービス要求を受信すると、ステップ１ｃにおいて、ＭＭＥ３０８は、ページング拒否メッセージをＭＳＣ３１０に送信して、ＣＳページング手順を停止し、これによってＣＳＦＢ手順を停止することができる。
【０１１６】
ステップ１ｄにおいて、ＭＭＥ３０８は、ＵＥ無線機能を含むＳ１−ＡＰ要求メッセージを、ｅＮｏｄｅＢ３０４に送信することができる。Ｓ１−ＡＰ要求メッセージは、ＵＥ３０２がＵＴＲＡＮ／ＧＥＲＡＮに移されるべきであることを、ｅＮｏｄｅＢ３０４に示すことができる。
【０１１７】
ステップ１ｅにおいて、ｅＮｏｄｅＢ３０４は、Ｓ１−ＡＰ応答メッセージを用いて応答することができる。
【０１１８】
ステップ２において、３ＧＰＰ  ＴＳ２３．２７２に詳細に規定されているように、任意的な測定レポート及び要求ステップが実行されてもよい。これらのステップは、節７．３において、ＰＳハンドオーバがサポートされる事例について詳細に規定されており、節７．４において、ＰＳハンドオーバがサポートされない事例について詳細に規定されている。
【０１１９】
ステップ３において、ソースＥ−ＵＴＲＡＮ（又は、ｅＮｏｄｅＢ３０４）は、ＵＥ測定レポート、エンハンストＣＳフォールバックインジケータ、及びステップ１ｄにおけるＵＥのＳＲＶＣＣ機能に基づいて、ＵＴＲＡＮ／ＧＥＲＡＮへのＵＥのＳＲＶＣＣハンドオーバをトリガすることを決定することができる。前述したように、ｅＮｏｄｅＢ３０４は、ＵＥ３０２から受信されたＦＧＩに基づいて、エンハンストＣＳフォールバックインジケータを判別することができる。すなわち、この場合、ｅＮｏｄｅＢ３０４は、ＭＭＥ３０８からではなく、ＵＥ３０２から、エンハンストＣＳフォールバックインジケータを受信することができる。
【０１２０】
Ｅ−ＵＴＲＡＮは、ＱＣＩ＝１のベアラが存在せず、かつ、ｖＳＲＶＣＣがマーキングされたビデオベアラが存在しない場合、ＣＳＦＢのためのＵＴＲＡＮ／ＧＥＲＡＮへのＳＲＶＣＣハンドオーバをトリガすることができる。ｅＮＢ３０４からＭＭＥ３０８に通信されるハンドオーバ要求メッセージは、エンハンストＣＳＦＢ機能に関するインジケータを含み得、ＭＭＥ３０８は、ＳＲＶＣＣがＣＳＦＢに起因するものであるとして、このインジケータを解釈する。ＭＭＥ３０８は、ＳＲＶＣＣがＣＳＦＢに起因するというＣＳＦＢインジケーションを含む、ＰＳからＣＳへのＳＲＶＣＣ要求メッセージを送信することができる。ＭＭＥ３０８は、他のＰＳベアラからのベアラ分離を実行する必要がない。ＭＭＥ３０８は、ＱＣＩ＝１のベアラ及びｖＳＲＶＣＣがマーキングされたビデオベアラを削除しない。なぜならば、ＳＲＶＣＣ手順はＣＳＦＢに起因し、ＱＣＩ＝１のベアラ及びｖＳＲＶＣＣがマーキングされたビデオベアラは存在しないためである。ＳＲＶＣＣはＣＳＦＢに起因するので、ＭＳＣ３１０は、セッション転送手順を開始せず、レガシーＣＳハンドオーバ準備をトリガするだけである。
【０１２１】
ステップ３においてＲＮＳ／ＢＳＳ３０６から再配置／ハンドオーバ完了メッセージを受信した後、ステップ４において、ＣＳ手順は継続することができる。
【０１２２】
図４のフローチャートに示されるように、別の例は、ユーザ機器（ＵＥ）のための回路交換フォールバック（ＣＳＦＢ）を促進するよう構成された１以上のプロセッサを備えるモビリティ管理エンティティ（ＭＭＥ）の機能４００を提供する。この機能は、方法として実施されてもよいし、マシン上の命令として実行されてもよい。後者の場合、命令は、少なくとも１つのコンピュータ読み取り可能な媒体又は１つの非一時的なマシン読み取り可能な記憶媒体に含まれる。ブロック４１０におけるように、１以上のプロセッサは、ＵＥから、ＵＥの最適化ＣＳＦＢ機能を規定する最適化ＣＳＦＢ機能インジケータを受信するよう構成され得る。ブロック４２０におけるように、１以上のプロセッサは、ＵＥに関連付けられた要求されるサービスタイプを受信するよう構成され得る。ブロック４３０におけるように、１以上のプロセッサは、ＵＥの最適化ＣＳＦＢ機能に基づいて、回路交換ネットワークへのＵＥの単一無線音声通信継続（ＳＲＶＣＣ）ハンドオーバを開始するよう構成され得る。ブロック４４０におけるように、１以上のプロセッサは、進化型ノードＢ（ｅＮＢ）にＳ１アプリケーションプロトコル（Ｓ１−ＡＰ）要求メッセージを送信するよう構成され得、ここで、Ｓ１−ＡＰ要求メッセージは、最適化ＣＳＦＢ機能インジケータ及びＵＥのための単一無線音声通信継続（ＳＲＶＣＣ）インジケータを含み、ＭＭＥは、要求されるサービスタイプに基づいて、ＳＲＶＣＣインジケータを選択する。ブロック４５０におけるように、１以上のプロセッサは、ｅＮＢからハンドオーバ要求メッセージを受信するよう構成され得、ここで、回路交換ネットワークへのＵＥのＳＲＶＣＣハンドオーバが、最適化ＣＳＦＢ機能インジケータ及びＳＲＶＣＣインジケータに部分的に基づいて、パケット交換ネットワークによってトリガされたときに、ｅＮＢは、ハンドオーバ要求メッセージをＭＭＥに送信するよう構成されている。
【０１２３】
１つの例において、１以上のプロセッサは、ＵＥから、アタッチ要求メッセージ又は追跡エリア更新（ＴＡＵ）要求メッセージを介して、最適化ＣＳＦＢ機能インジケータを受信するよう更に構成される。別の例において、１以上のプロセッサは、ＵＥから、拡張サービス要求メッセージを介して、最適化ＣＳＦＢ機能インジケータを受信するよう更に構成される。更に別の例において、１以上のプロセッサは、ホーム加入者サーバ（ＨＳＳ）から受信された位置更新確認応答メッセージに基づいて、最適化ＣＳＦＢ機能インジケータを特定するよう更に構成され、ここで、位置更新確認応答メッセージは、ＵＥの最適化ＣＳＦＢ機能を示すＵＥ加入者プロファイルを含む。
【０１２４】
１つの例において、１以上のプロセッサは、移動通信交換局（ＭＳＣ）から、ページング要求メッセージを介して、要求されるサービスタイプを受信するよう更に構成される。別の例において、最適化ＣＳＦＢ機能インジケータは、ＵＥが、ＳＲＶＣＣベースのＣＳＦＢをサポートしていないことを示す「０」、又は、ＵＥが、ＳＲＶＣＣベースのＣＳＦＢをサポートしていることを示す「１」である。更に別の例において、１以上のプロセッサは、モバイル発信（ＭＯ）呼について、ＵＥから拡張サービス要求メッセージを受信するよう更に構成される。更に、１以上のプロセッサは、モバイル着信（ＭＴ）呼について、移動通信交換局（ＭＳＣ）からページング要求メッセージを受信するよう更に構成される。
【０１２５】
１つの構成では、回路交換ネットワークは、ＵＴＲＡＮ又はＧＥＲＡＮである。別の構成では、要求されるサービスタイプは、音声、ビデオ、非構造付加サービスデータ（ＵＳＳＤ）、位置サービス（ＬＣＳ）、及び未知のもののうちの１つである。更に別の構成では、ＳＲＶＣＣインジケータは、ＳＲＶＣＣ／ビデオＳＲＶＣＣ（ｖＳＲＶＣＣ）を開始するか否かについてｅＮＢに通知する。ＳＲＶＣＣインジケータは、「０」のとき、ＳＲＶＣＣ／ｖＳＲＶＣＣもレガシーＣＳＦＢも予期されないことをｅＮＢに示し、ＳＲＶＣＣインジケータは、「１」のとき、ＳＲＶＣＣが予期されることをｅＮＢに示し、ＳＲＶＣＣインジケータは、「２」のとき、ｖＳＲＶＣＣが予期されることをｅＮＢに示す。
【０１２６】
１つの例において、１以上のプロセッサは、ＵＥに関連付けられたＱＣＩ＝１のベアラが存在しない場合、パケット交換から回路交換への（ＰＳ−ＣＳ）ハンドオーバ手順を開始するよう更に構成される。別の例において、１以上のプロセッサは、ＳＲＶＣＣの目的でＰＳからＣＳへの要求メッセージを移動通信交換局（ＭＳＣ）サーバに送信することによって、要求されるサービスタイプが音声又はビデオのためのものであるときには、ＰＳ−ＣＳハンドオーバ手順をトリガするよう更に構成される。ＰＳからＣＳへの要求メッセージは、最適化ＣＳＦＢ機能インジケータを含む。
【０１２７】
図５のフローチャートに示されるように、別の例は、ユーザ機器（ＵＥ）のための最適化回路交換フォールバック（ＣＳＦＢ）を促進するよう構成された１以上のプロセッサを備える進化型ノードＢ（ｅＮＢ）の機能５００を提供する。この機能は、方法として実施されてもよいし、マシン上の命令として実行されてもよい。後者の場合、命令は、少なくとも１つのコンピュータ読み取り可能な媒体又は１つの非一時的なマシン読み取り可能な記憶媒体に含まれる。ブロック５１０におけるように、１以上のプロセッサは、ＵＥの最適化ＣＳＦＢ機能を規定する最適化ＣＳＦＢ機能インジケータを受信するよう構成され得る。ブロック５２０におけるように、１以上のプロセッサは、ＵＥのための単一無線音声通信継続（ＳＲＶＣＣ）インジケータを受信するよう構成され得る。ブロック５３０におけるように、１以上のプロセッサは、最適化ＣＳＦＢ機能インジケータ及びＳＲＶＣＣインジケータに部分的に基づいて、回路交換ネットワークへのＵＥのＳＲＶＣＣハンドオーバをトリガするよう構成され得る。ブロック５４０におけるように、１以上のプロセッサは、ＳＲＶＣＣハンドオーバがパケット交換ネットワークによってトリガされたときに、モビリティ管理エンティティ（ＭＭＥ）にハンドオーバ要求メッセージを送信するよう構成され得る。
【０１２８】
１つの例において、１以上のプロセッサは、ＵＥから、機能グループインジケータ（ＦＧＩ）を介して、最適化ＣＳＦＢ機能インジケータを受信するよう更に構成される。別の例において、１以上のプロセッサは、ＵＥに関連付けられたＱＣＩ＝１のベアラが存在しない場合、回路交換ネットワークへのＵＥのＳＲＶＣＣハンドオーバをトリガするよう更に構成される。更に別の例において、１以上のプロセッサは、ＭＭＥから最適化ＣＳＦＢ機能インジケータを受信するよう更に構成される。
【０１２９】
１つの構成では、ＳＲＶＣＣインジケータは、ＳＲＶＣＣ／ビデオＳＲＶＣＣ（ｖＳＲＶＣＣ）を開始するか否かについてｅＮＢに通知する。ＳＲＶＣＣインジケータは、「０」のとき、ＳＲＶＣＣ／ｖＳＲＶＣＣもレガシーＣＳＦＢも予期されないことをｅＮＢに示し、ＳＲＶＣＣインジケータは、「１」のとき、ＳＲＶＣＣが予期されることをｅＮＢに示し、ＳＲＶＣＣインジケータは、「２」のとき、ｖＳＲＶＣＣが予期されることをｅＮＢに示す。別の構成では、回路交換ネットワークは、ＵＴＲＡＮ又はＧＥＲＡＮである。
【０１３０】
別の例は、図６のフローチャートに示されるように、最適化回路交換フォールバック（ＣＳＦＢ）を促進するための方法６００を提供する。本方法は、マシン上の命令として実行されてよく、命令は、少なくとも１つのコンピュータ読み取り可能な媒体又は１つの非一時的なマシン読み取り可能な記憶媒体に含まれる。ブロック６１０におけるように、本方法は、ユーザ機器（ＵＥ）から、最適化ＣＳＦＢ機能インジケータを、モビリティ管理エンティティ（ＭＭＥ）に送信する動作を含み得る。ブロック６２０におけるように、本方法は、ＵＥから、要求されるサービスタイプを、ＭＭＥに送信する動作を含み得、ここで、ＭＭＥは、最適化ＣＳＦＢ機能及び要求されるサービスタイプに部分的に基づいて、回路交換ネットワークへのＵＥの単一無線音声通信継続（ＳＲＶＣＣ）ハンドオーバを促進するよう構成されている。
【０１３１】
１つの例において、本方法は、ＵＥから、アタッチ要求メッセージ又は追跡エリア更新（ＴＡＵ）要求メッセージを介して、最適化ＣＳＦＢ機能インジケータを、ＭＭＥに送信する動作を含み得る。別の例において、本方法は、ＵＥから、拡張サービス要求メッセージを介して、最適化ＣＳＦＢ機能インジケータ及び要求されるサービスタイプのうちの少なくとも１つを、ＭＭＥに送信する動作を含み得る。更に別の例において、最適化ＣＳＦＢ機能インジケータは、ＵＥが、ＳＲＶＣＣベースのＣＳＦＢをサポートしていないことを示す「０」、又は、ＵＥが、ＳＲＶＣＣベースのＣＳＦＢをサポートしていることを示す「１」である。更に、要求されるサービスタイプは、音声、ビデオ、非構造付加サービスデータ（ＵＳＳＤ）、位置サービス（ＬＣＳ）、及び未知のもののうちの１つである。
【０１３２】
図７は、ユーザ機器（ＵＥ）、移動局（ＭＳ）、モバイル無線デバイス、モバイル通信デバイス、タブレット、ハンドセット、又は他のタイプの無線デバイス等の無線デバイスの例示図を提供している。無線デバイスは、基地局（ＢＳ）、進化型ノードＢ（ｅＮＢ）、ベースバンドユニット（ＢＢＵ）、リモート無線ヘッド（ＲＲＨ）、リモート無線機器（ＲＲＥ）、中継局（ＲＳ）、無線機器（ＲＥ）、リモート無線ユニット（ＲＲＵ）、中央処理モジュール（ＣＰＭ）、又は他のタイプの無線ワイドエリアネットワーク（ＷＷＡＮ）アクセスポイント等のノード又は伝送局と通信するよう構成された１以上のアンテナを含み得る。無線デバイスは、３ＧＰＰ  ＬＴＥ、ＷｉＭＡＸ（登録商標）、高速パケットアクセス（ＨＳＰＡ）、Ｂｌｕｅｔｏｏｔｈ（登録商標）、及びＷｉＦｉ（登録商標）を含む少なくとも１つの無線通信規格を使用して通信するよう構成され得る。無線デバイスは、無線通信規格ごとに別個のアンテナを使用して、又は、複数の無線通信規格についての共用アンテナを使用して、通信することができる。無線デバイスは、無線ローカルエリアネットワーク（ＷＬＡＮ）、無線パーソナルエリアネットワーク（ＷＰＡＮ）、及び／又はＷＷＡＮにおいて通信することができる。
【０１３３】
図７は、無線デバイスに関するオーディオ入力及びオーディオ出力のために使用することができるマイクロフォン及び１以上のスピーカの図も提供している。ディスプレイスクリーンは、液晶ディスプレイ（ＬＣＤ）スクリーンであってもよいし、有機発光ダイオード（ＯＬＥＤ）ディスプレイ等の他のタイプのディスプレイスクリーンであってもよい。ディスプレイスクリーンは、タッチスクリーンとして構成されてもよい。タッチスクリーンは、静電容量方式、抵抗方式、又は別のタイプのタッチスクリーン技術を使用することができる。アプリケーションプロセッサ及びグラフィックスプロセッサを内部メモリに接続して、処理機能及び表示機能を提供することができる。不揮発性メモリポートを使用して、データ入力／出力オプションをユーザに提供することもできる。不揮発性メモリポートを使用して、無線デバイスのメモリ機能を拡張することもできる。更なるユーザ入力を提供するために、キーボードが、無線デバイスと統合されてもよいし、無線デバイスに無線接続されてもよい。タッチスクリーンを使用して、仮想キーボードを提供することもできる。
【０１３４】
様々な技術、又はその所定の態様若しくは部分は、フロッピディスケット、コンパクトディスク読み取り専用メモリ（ＣＤ−ＲＯＭ）、ハードドライブ、非一時的なコンピュータ読み取り可能な記憶媒体、又は任意の他のマシン読み取り可能な記憶媒体等の有形の媒体に具現化されるプログラムコード（すなわち、命令）の形態を取ることができ、プログラムコードが、コンピュータ等のマシンにロードされ、マシンによって実行されると、マシンは、様々な技術を実施するための装置となる。回路は、ハードウェア、ファームウェア、プログラムコード、実行可能なコード、コンピュータ命令、及び／又はソフトウェアを含み得る。非一時的なコンピュータ読み取り可能な記憶媒体は、信号を含まないコンピュータ読み取り可能な記憶媒体とすることができる。プログラム可能なコンピュータ上でのプログラムコード実行の場合、コンピューティングデバイスは、プロセッサ、プロセッサによって読み取り可能な記憶媒体（揮発性メモリ、不揮発性メモリ、及び／又は記憶要素を含む）、少なくとも１つの入力デバイス、及び少なくとも１つの出力デバイスを含み得る。揮発性メモリ、不揮発性メモリ、及び／又は記憶要素は、ランダムアクセスメモリ（ＲＡＭ）、消去可能なプログラム可能な読み取り専用メモリ（ＥＰＲＯＭ）、フラッシュドライブ、光学ドライブ、磁気ハードドライブ、ソリッドステートドライブ、又は電子データを記憶するための他の媒体とすることができる。ノード及び無線デバイスは、トランシーバモジュール（すなわち、トランシーバ）、カウンタモジュール（すなわち、カウンタ）、処理モジュール（すなわち、プロセッサ）、及び／又はクロックモジュール（すなわち、クロック）若しくはタイマモジュール（すなわち、タイマ）も含み得る。本明細書に記載の様々な技術を実装又は利用することができる１以上のプログラムは、アプリケーションプログラミングインタフェース（ＡＰＩ）、再利用可能なコントロール等を使用することができる。そのようなプログラムは、コンピュータシステムと通信するように、高水準手続き型プログラミング言語又はオブジェクト指向プログラミング言語により実装され得る。しかしながら、１以上のプログラムは、必要に応じて、アセンブリ言語又はマシン言語により実装されてもよい。いずれの場合であっても、言語は、コンパイル型言語又はインタプリタ型言語であり得、ハードウェア実装と組み合わされ得る。
【０１３５】
本明細書において使用されるとき、プロセッサという用語は、汎用プロセッサ、ＶＬＳＩ、ＦＰＧＡ、又は他のタイプの専用プロセッサ等の専用プロセッサに加えて、無線通信を送信、受信、及び処理するためにトランシーバにおいて使用されるベースバンドプロセッサを含み得る。
【０１３６】
本明細書において記載されている機能ユニットの多くが、それらの実装の独立性をより具体的に強調するために、モジュールとして称されていることを理解されたい。例えば、モジュールは、カスタム超大規模集積（ＶＬＳＩ）回路若しくはゲートアレイ、ロジックチップ、トランジスタ等の既製の半導体、又は他のディスクリートコンポーネントを備えるハードウェア回路として実装することができる。モジュールは、フィールドプログラマブルゲートアレイ、プログラマブルアレイロジック、プログラマブルロジックデバイス等といったプログラム可能なハードウェアデバイスにより実装されてもよい。
【０１３７】
モジュールは、様々なタイプのプロセッサによって実行されるソフトウェアにより実装されてもよい。実行可能なコードの特定されるモジュールは、例えば、コンピュータ命令の１以上の物理ブロック又は論理ブロックを有することができ、これらは、例えば、オブジェクト、プロシージャ、又は関数として編成することができる。しかしながら、特定されるモジュールの実行ファイルは、物理的に一緒に配置される必要はなく、異なる位置に記憶される異なる命令を有することができる。これらは、論理的に結合されると、モジュールを含み、モジュールの上述の目的を達成する。
【０１３８】
実際に、実行可能なコードのモジュールは、単一の命令であっても多数の命令であってもよく、更には、いくつかの異なるコードセグメントにわたって、異なるプログラム間で、いくつかのメモリデバイスにわたって、分散されてもよい。同様に、動作データが、本明細書においてモジュール内に特定され示され、任意の適切な形態で具現化され、任意の適切なタイプのデータ構造内で編成され得る。動作データは、単一のデータセットとして収集されてもよいし、異なる記憶デバイスにわたることを含め、異なる位置にわたって分散されてもよいし、単に、システム又はネットワークにおける電子信号として、少なくとも部分的に存在してもよい。モジュールは、所望の機能を実行するよう動作可能なエージェントを含め、パッシブであってもアクティブであってもよい。
【０１３９】
本明細書を通じた「例」又は「例示」との言及は、その例に関連して記載される特定の特徴、構造、又は特性が、本発明の少なくとも１つの実施形態に含まれることを意味する。したがって、本明細書を通じた様々な箇所における「１つの例において」という語句又は「例示」という語の出現は、必ずしも、全てが同じ実施形態を指しているわけではない。
【０１４０】
本明細書で使用されるとき、複数のアイテム、構造的要素、組成的要素、及び／又は材料は、便宜上、共通リストに提示される場合がある。しかしながら、これらのリストは、リストの各要素が別々の固有の要素として個々に特定されるかのように解釈されるべきである。したがって、このようなリストの個々の要素は、反対のインジケーションなく共通グループに提示されているということのみに基づいて、同じリストの任意の他の要素の事実上の均等物として解釈されるべきではない。更に、本発明の様々な実施形態及び例は、本明細書において、それらの様々なコンポーネントの代替と共に言及される場合がある。そのような実施形態、例、及び代替は、互いの事実上の均等物として解釈されるべきではなく、本発明の別々の自立した表現として解釈されるべきであることを理解されたい。
【０１４１】
更に、記載される特徴、構造、又は特性は、１以上の実施形態において、任意の適切な形で組み合わされ得る。上記説明では、本発明の実施形態の完全な理解を提供するために、レイアウト、距離、ネットワークの例等の多数の具体的な詳細が提供されている。しかしながら、関連技術分野の当業者であれば、具体的な詳細のうちの１以上がなくても、又は、他の方法、コンポーネント、レイアウト等を使用して、本発明を実施できることが認識されよう。他の例では、本発明の態様を不明瞭にしないように、周知の構造、材料、又は動作は、詳細には図示又は記載されていない。
【０１４２】
上述の例は、１以上の特定の用途において、本発明の原理を説明するものであるが、発明力の発揮がなくとも、本発明の原理及びコンセプトから逸脱することなく、実施の形式、利用法、及び詳細について多くの変更を行うことができることが当業者には明らかであろう。したがって、特許請求の範囲によるものを除いて、本発明が限定されることは意図していない。
【図１】
0006388952.tif 000002
【図２】
0006388952.tif 000003
【図３】
0006388952.tif 000004
【図４】
0006388952.tif 000005
【図５】
0006388952.tif 000006
【図６】
0006388952.tif 000007
【図７】
0006388952.tif 000008