JP5798693B2 - リバース単一無線音声通話継続性における音声ベアラ選択装置及び方法 - Google Patents

Description

本出願は、一般に、リバース単一無線音声通話継続性において音声ベアラを選択するための装置及び方法に関する。

本技術分野に関連する先行技術は、例えば、３ＧＰＰの技術仕様書ＴＳ ２３．２１６（現バージョン１１．１．０）及びＴＲ ２３．８８５（現バージョン１．４．０）、並びにＧＳＭＡのｐｅｒｍａｎｅｎｔ ｒｅｆｅｒｅｎｃｅ ｄｏｃｕｍｅｎｔ（恒久的参照文書） ＩＲ．８８（現バージョン：４．０）及びＩＲ．９２（現バージョン：４．０）で確認することができる。

本明細書で用いる略語に関して、以下の意味が該当する。
２Ｇ：第２世代
３Ｇ：第３世代
３ＧＰＰ：第３世代パートナーシッププロジェクト
ＡＰＮ：アクセスポイント名
ＡＴＣＦ：アクセス転送制御機能
ＣＳ：回線交換
ＤＬ ダウンリンク
ＤＴＭ：二重伝送モード
ＥＤＧＥ：ＧＳＭ（登録商標）進化型高速データレート
ｅＮＢ：進化型ＮＢ
ＥＰＳ：進化型パケットシステム
Ｅ−ＵＴＲＡＮ：進化型ＵＴＲＡＮ
ＧＢＲ：保証ビットレート
ＧＥＲＡＮ：ＧＳＭ ＥＤＧＥ無線アクセスネットワーク
ＧＰＲＳ：汎用パケット無線サービス
ＧＳＭ：移動体通信用グローバルシステム
ＧＳＭＡ：ＧＳＭアソシエーション
ＨＯ：ハンドオーバ
ＨＳＰＡ：高速パケットアクセス
ＩＭＳ：ＩＰマルチメディアサブシステム
ＩＭＥＩ：国際移動体装置識別番号
ＩＭＳＩ：国際移動体加入者識別番号
ＩＰ：インターネットプロトコル
ＩＳＤＮ：サービス総合ディジタル網
ＬＴＥ：ロングタームエボリューション
ＬＴＥ−Ａ：ＬＴＥ−アドバンスト
ＭＢＲ：マルチビットレート
ＭＭＥ：モビリティ管理エンティティ
ＭＳＣ：移動通信交換局
ＭＳＩＳＤＮ：移動体加入者ＩＳＤＮ番号
ＮＢ：ノード Ｂ
ＰＣＣ：ポリシー及び課金制御
ＰＣＲＦ ポリシー及び課金ルール機能
Ｐ−ＣＳＣＦ：プロキシ呼状態制御機能
ＰＤＮ：パケットデータネットワーク
ＰＤＰ パケットデータプロトコル
Ｐ−ＧＷ：ＰＤＮゲートウェイ
ＰＳ：パケット交換
ＱＣＩ ＱｏＳクラス識別子
ＱｏＳ サービス品質
ＲＡＩ：ルーティングエリア識別子
ＲＡＮ 無線アクセスネットワーク
ＲＡＴ：無線アクセス技術
ＲＴＣＰ：ＲＴＰ制御プロトコル
ＲＴＰ リアルタイムプロトコル
ＳＧＳＮ サービングＧＰＲＳサポートノード
Ｓ−ＧＷ：サービングゲートウェイ
ＳＩＰ セッション開始プロトコル
ＳＲＶＣＣ：単一無線音声通話継続
ＴＦＴ トラフィックフローテンプレート
ＴＭＳＩ：一時的移動体加入者識別番号
ＵＥ ユーザ装置
ＵＬ アップリンク
ＵＴＲＡＮ ユニバーサル地上波無線アクセスネットワーク
ＶｏＩＰ：ボイス・オーバー・アイピー
ＸＣＡＰ：ＸＭＬコンフィギュレーションアクセスプロトコル
ＸＭＬ：拡張マークアップ言語

３ＧＰＰの仕様書リリース８において、Ｅ−ＵＴＲＡＮ／ＨＳＰＡからＵＴＲＡＮ／ＧＥＲＡＮ方向へのＳＲＶＣＣに対応するための仕様書が規定された。反対方向でのＳＲＶＣＣへの対応（リバースＳＲＶＣＣと呼ぶことができる）については、３ＧＰＰによって仕様書ＴＲ ２３．８８５で検討され、それに記載された代替形態の１つがリリース１１で標準化されるように推奨されている。

標準化作業のための解決手段の提案は、Ｐ−ＧＷ、ＰＣＣ、及びソースＳＧＳＮが影響を受けることを必要とせずに、音声メディアが、リバースＳＲＶＣＣ（「ｒＳＲＶＣＣ」）直後でＵＥがＱＣＩ１ベアラをセットアップする前に、デフォルトベアラを用いて送信されることを前提としている。

しかしながら、推奨される解決手段には、終結を必要とするいくつかの未解決分野がある。

例えば、推奨されるアクセス転送手順（仕様書ＴＲ ２３．８８５のバーション１．４．０のセクション６．３．３．７．５を参照）において、この文書は、図１及び図２（図１：アクセス転送準備代替形態５（Ａｃｃｅｓｓ Ｔｒａｎｓｆｅｒ Ｐｒｅｐａｒａｔｉｏｎ Ａｌｔｅｒｎａｔｉｖｅ ５）、非ＤＴＭケース、図２：アクセス転送準備代替形態５（Ａｃｃｅｓｓ Ｔｒａｎｓｆｅｒ Ｐｒｅｐａｒａｔｉｏｎ Ａｌｔｅｒｎａｔｉｖｅ ５）、ＤＴＭケース）による、非ＤＴＭケース及びＤＴＭケースのコールフローを示している。

それに基づいて、図１に示すケースのコールフローは、文書ＴＲ ２３．８８５で規定されるように以下のとおりである。

１．ＲＮＣ／ＢＳＣは、このＨＯがｒＳＲＶＣＣに関するものであるという指示を含む「ＨＯ ｒｅｑｕｉｒｅｄ（ＨＯが必要）」メッセージをＭＳＣサーバに送信する。ＭＳＣサーバがターゲットＭＳＣである場合、ＭＳＣサーバは「ＨＯ ｒｅｑｕｉｒｅｄ（ＨＯが必要）」メッセージをアンカーＭＳＣサーバに転送する。

２．ＭＳＣサーバは、「ＳＲＶＣＣ ＣＳ ｔｏ ＰＳ ＨＯ ｒｅｑｕｅｓｔ（ＣＳからＰＳへのＳＲＶＣＣ ＨＯ要求）」メッセージをターゲットＭＭＥに送信する。必要に応じて、ＵＥを識別するためのＩＭＳＩが提供される。

３．ＭＳＣサーバは、「Ａｃｃｅｓｓ Ｔｒａｎｓｆｅｒ Ｎｏｔｉｆｉｃａｔｉｏｎ（アクセス転送通知）」メッセージ、例えば、ＳＩＰ「ｒｅ−ＩＮＶＩＴＥ」又は「ＩＮＶＩＴＥ」メッセージをＡＴＣＦに送信して、ＡＴＣＦがＰＳへのメディアの転送を準備する必要があることをＡＴＣＦに通知する。ＡＴＣＦは、ＡＴＧＷ上でのメディアポートを割り当てる。ＡＴＣＦによって割り当てられたメディアポート及びコーデックが、応答メッセージでＭＳＣサーバに提供される。この段階は、段階２とは無関係である。ＡＴＣＦは、ＵＥから受信するポート／コーデックをＵＥのＩＭＳ登録時に取得することに留意されたい。ＡＴＣＦは、ＵＥによって行われるＩＭＳ登録及びＵＥの代わりにＭＳＣサーバによって行われる登録を、例えば、これら両方の登録で用いられるＣ−ＭＳＩＳＤＮ又はＩＭＥＩ派生のインスタンスｉｄに基づいて相関付けることができる。更に、Ａｃｃｅｓｓ Ｔｒａｎｓｆｅｒ Ｎｏｔｉｆｉｃａｔｉｏｎ（アクセス転送通知）メッセージは、例えば、「ＩＮＶＩＴＥ」又は他の適切なメッセージを用いて実行することができることを留意されたい。これは、今後の研究課題である。

４．ＭＭＥがＵＥコンテキストを有しない場合、ＭＭＥは、Ｐ−ＴＭＳＩ及びＲＡＩを用いて「Ｃｏｎｔｅｘｔ Ｒｅｑｕｅｓｔ（コンテキスト要求）」メッセージを送信して、以前のＳＧＳＮを発見する。

５．ＳＧＳＮは、すべてのＵＥコンテキストを含む「Ｃｏｎｔｅｘｔ Ｒｅｓｐｏｎｓｅ（コンテキスト応答）」メッセージで応答する。

６．ターゲットＭＭＥは、Ｅ−ＵＴＲＡＮでのリソースを割り当てる。

７．「ＳＲＶＣＣ ＣＳ ｔｏ ＰＳ ＨＯ ｒｅｓｐｏｎｓｅ（ＣＳからＰＳへのＳＲＶＣＣ ＨＯ応答）」メッセージが、ターゲットＭＭＥからＭＳＣサーバに返信される。

８．ＭＳＣサーバは、「ＨＯ ｒｅｑｕｉｒｅｄ Ａｃｋ（「ＨＯが必要」の肯定応答）」メッセージを、場合によってはターゲットＭＳＣを介して、ＲＡＮに送信し、ＲＡＮは、ＣＳからＰＳへのハンドオーバを指示する「ＨＯ ｃｏｍｍａｎｄ（ＨＯコマンド）」をＵＥに送信する。更に、ＭＳＣサーバは、このメッセージ内にＡＴＧＷのＩＰアドレス／ポート及び選択されたコーデックを含める。

９．メディアがＡＴＧＷにおいてアンカーされるＡＴＣＦの場合、ＭＳＣサーバは、「Ａｃｃｅｓｓ Ｔｒａｎｓｆｅｒ Ｐｒｅｐａｒａｔｉｏｎ Ｒｅｑｕｅｓｔ（アクセス転送準備要求）」メッセージ、例えば、ＳＩＰ「ｒｅ−ＩＮＶＩＴＥ」又は「ＰＲＡＣＫ」メッセージをＡＴＣＦに送信し、ＡＴＣＦ／ＡＴＧＷが、メディアパスを、ターゲットアクセスでのＵＥのＩＰアドレス／ポートに切り替えるようにトリガする。メディアがＡＴＧＷにおいてアンカーされないＡＴＣＦの場合、ＭＳＣサーバは、「Ａｃｃｅｓｓ Ｔｒａｎｓｆｅｒ Ｐｒｅｐａｒａｔｉｏｎ Ｒｅｑｕｅｓｔ（アクセス転送準備要求）」メッセージをＡＴＣＦに送信して、ＡＴＣＦ／ＡＴＧＷとＭＳＣサーバ／ＭＧＷとの間のメディアパスが確立される。

１０．ＵＥは、「Ｈａｎｄｏｖｅｒ ｃｏｎｆｉｒｍａｔｉｏｎ（ハンドオーバ確認）」メッセージをｅＮＢに送信する。

１１．ｅＮＢは、「Ｈａｎｄｏｖｅｒ Ｎｏｔｉｆｙ（ハンドオーバ通知）」メッセージをＭＭＥに送信する。

１２．ＭＭＥは、「Ｍｏｄｉｆｙ Ｂｅａｒｅｒ Ｒｅｑｕｅｓｔ（ベアラ変更要求）」メッセージをＳＧＷに送信し、このメッセージがＰＧＷに転送されて、ＰＳベアラコンテキストが更新される。

１３．ＭＭＥは、「Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ ｔｏ ｔｈｅ Ｃｏｎｔｅｘｔ Ｒｅｓｐｏｎｓｅ（コンテキスト応答への肯定応答）」メッセージをＳＧＳＮに送信する。

１４．音声メディアは直接的に開始される。ＲＡＴが変更され新規ベアラが確立されるよりも前の短期間、メディアはデフォルトベアラ上で送信される点に留意されたい。

１５．ＵＥは、仕様書ＴＲ ２３．８８５（バージョン１．４．０）の節６．３．３．８によるセッション継続手順をＡＴＣＦに向けて開始する。

１６．セッション継続手順の結果として、ベアラセットアップが実行される（Ｐ−ＣＳＣＦによって開始）。

１７．音声メディアが専用ベアラで送信される。

更に、図２に示すケースのコールフローは、文書ＴＲ ２３．８８５によって規定されるように、以下のとおりである。

段階１は、図１を参照しながら上述したのと同じである。

１ａ．ＤＴＭケースでは、ＵＥが既にＰＳドメイン内でアクティブであり、ＲＮＣ／ＢＳＣは更に、「Ｒｅｌｏｃａｔｉｏｎ Ｒｅｑｕｉｒｅｄ（リロケーションが必要）」メッセージをソースＳＧＳＮに送信する。

その後の段階２及び３は、図１に関連して上述した段階と同様である。

４．ソースＳＧＳＮは、「Ｒｅｌｏｃａｔｉｏｎ Ｒｅｑｕｅｓｔ（リロケーション要求）」メッセージをターゲットＭＭＥに送信する。

５．ターゲットＭＭＥは、Ｅ−ＵＴＲＡＮでのリソースを割り当てる。

６ａ．「ｒｅｌｏｃａｔｉｏｎ ｒｅｓｐｏｎｓｅ（リロケーション応答）」メッセージをソースＳＧＳＮに返信する。

６ｂ．ソースＳＧＳＮは、「ＨＯ Ｒｅｑｕｉｒｅｄ Ａｃｋ（「ＨＯが必要」の肯定応答）」メッセージをＲＡＮに送信する。

その後の段階７から１１は、図１に関連して上述した段階と同様である。

１２．ＭＭＥは、「Ｆｏｒｗａｒｄ ｒｅｌｏｃａｔｉｏｎ Ｃｏｍｐｌｅｔｅ（リロケーション転送完了）」メッセージを以前のＳＧＳＮに送信する。

１３．ＭＭＥは、「Ｍｏｄｉｆｙ Ｂｅａｒｅｒ Ｒｅｑｕｅｓｔ（ベアラ変更要求）」メッセージをＳＧＷに送信し、このメッセージがＰＧＷに転送されて、ＰＳベアラコンテキストが更新される。最後に、段階１４から１７は、この場合もやはり図１に関連して上述した段階と同様である。

上記を要約すると、結果的に、音声ベアラ交換に関して用いられる幾つかの高水準の原理は以下のとおりとすることができる。

１．ＵＥは、音声メディア用の２Ｇ又は３Ｇ ＣＳアクセスではＣＳベアラを使用し、ＵＥは更に、ＩＭＳ登録及びＳＩＰ／ＸＣＡＰシグナリングに使用されるＰＤＰコンテキストを有する。使用されるＰＤＰコンテキストは、ＩＭＳ ＡＰＮに関するプライマリＰＤＰコンテキストである（プライマリＰＤＰコンテキストはＴＦＴを有すことができない点に留意されたい）。

２．２Ｇ／３Ｇ ＣＳからＬＴＥへのＳＲＶＣＣが、ソース無線によってトリガされ、ＵＥがＬＴＥにハンドオーバされて（上記の段階１から１０）、ＣＳベアラが解放される。

３．ハンドオーバ後、音声はＬＴＥアクセスで継続し、ＩＭＳ ＡＰＮに関しては、ＩＭＳシグナリング及び音声メディアの両方に使用されるデフォルトベアラのみが存在する（上記の段階１４を参照）。

４．ネットワークは、ＩＭＳ音声セッションネゴシエーションに基づいて、ＱＣＩ１、ＧＢＲ／ＭＢＲ、及び音声メディアパケットフロー情報を含む専用ＥＰＳベアラを生成する（上記の段階１５から１６を参照）。

５．ＵＥは、アップリンク方向に関して確立された専用ベアラに音声メディアを与える。同様に、Ｐ−ＧＷが、ダウンリンクトラフィックをマッピングする（段階１６から１７）。

３ＧＰＰ ＴＳ ２３．２１６ ３ＧＰＰ ＴＲ ２３．８８５ ３ＧＰＰ ＴＳ ２３．２３７ ＧＳＭＡ ＩＲ．８８ ＧＳＭＡ ＩＲ．９２

本発明の目的は、リバース単一無線音声通話継続性において音声ベアラを選択するための装置及び方法を提供することである。

本発明の第１の態様によれば、ユーザ装置の移動体通信通話の回線交換移動体通信からパケット交換移動体通信へのハンドオーバに関して、移動体サービス交換エンティティによるハンドオーバ要求に応答して、移動体サービス交換エンティティへの応答を生成するハンドオーバ応答動作を実行するように構成されたハンドオーバ処理手段と、パケット交換移動体通信に関するリソースを割り当てるリソース割り当て動作を実行するように構成されたリソース割り当て手段と、リアルタイムプロトコル及びリアルタイムプロトコル制御プロトコルベースのパケットがパケット交換移動体通信ゲートウェイエンティティでデフォルトベアラとして設定されたベアラを通過することを一時的に許可するように、移動体通信通話のハンドオーバのターゲットとしてのパケット交換移動体通信ゲートウェイエンティティに命令するコマンド動作を実行し、リソース割り当て手段がリソース割り当て動作を実行した後でハンドオーバ処理手段がハンドオーバ応答動作を実行する前に、コマンド動作を実行するようにハンドオーバ処理手段及びリソース割り当て手段の動作を制御するように構成された制御手段と、を備えた装置によって目的が実現される。

第１の態様の変更形態によれば、本装置は、リバース単一無線音声通話継続性において音声ベアラを制御するのに好適とすることができる。

本発明の第２の態様によれば、ユーザ装置の移動体通信通話の回線交換移動体通信からパケット交換移動体通信へのハンドオーバに関して、移動体サービス交換エンティティによるハンドオーバ要求に応答して、移動体サービス交換エンティティへの応答を生成するハンドオーバ応答動作を実行するように構成されたハンドオーバプロセッサと、パケット交換移動体通信に関するリソースを割り当てるリソース割り当て動作を実行するように構成されたリソース割り当てプロセッサと、リアルタイムプロトコル及びリアルタイムプロトコル制御プロトコルベースのパケットがパケット交換移動体通信ゲートウェイエンティティでデフォルトベアラとして設定されたベアラを通過することを一時的に許可するように、移動体通信通話のハンドオーバのターゲットとしてのパケット交換移動体通信ゲートウェイエンティティに命令するコマンド動作を実行し、リソース割り当てプロセッサがリソース割り当て動作を実行した後でハンドオーバプロセッサがハンドオーバ応答動作を実行する前に、コマンド動作を実行するようにハンドオーバプロセッサ及びリソース割り当てプロセッサの動作を制御するように構成されたコントローラと、を備えた装置によって目的が達成される。

第２の態様の変更形態は、第１の態様の変更形態に対応することができる。

本発明の第３の態様によれば、第１又は第２の態様による装置を備えたシステム、及び移動体通信通話のハンドオーバのターゲットとしてのパケット交換移動体通信ゲートウェイエンティティによって、目的が達成される。

第３の態様の変更形態は、以下のとおりとすることができる。

第３の態様によるシステムは、リバース単一無線音声通話継続性において音声ベアラを制御するのに好適とすることができる。

パケット交換移動体通信ゲートウェイエンティティは、リアルタイムプロトコル及びリアルタイムプロトコル制御プロトコルベースのパケットが、パケット交換移動体通信ゲートウェイエンティティでデフォルトベアラとして設定されたベアラを通過することを一時的に許可するためのタイマをセットして、タイマの有効期限切れ後に許可を取り消すように構成することができる。

パケット交換移動体通信ゲートウェイエンティティは、移動体通信通話のハンドオーバ後の、音声メディアに関する専用ベアラのセットアップを認識した後に、一時的な通過許可を取り消すように構成することができる。

コマンド動作は、アップリンク及びダウンリンクのメディアアドレス及びポート番号の指示と、このような指示されたアップリンク及びダウンリンクのメディアアドレス及びポート番号によって識別される送信先を有するパケットトラフィックへの一時的な許可を限定することとを含むことができる。

本発明の第４の態様によれば、第１又は第２の態様、或いはこれらの変更形態による装置を備えた移動体管理エンティティによって、目的が達成される。

本発明の第５の態様によれば、ユーザ装置の移動体通信通話の回線交換移動体通信からパケット交換移動体通信へのハンドオーバに関して、移動体サービス交換エンティティによるハンドオーバ要求に応答して、移動体サービス交換エンティティへの応答を生成するハンドオーバ応答動作を実行する段階と、パケット交換移動体通信に関するリソースを割り当てるリソース割り当て動作を実行する段階と、リアルタイムプロトコル及びリアルタイムプロトコル制御プロトコルベースのパケットが、パケット交換移動体通信ゲートウェイエンティティでデフォルトベアラとして設定されたベアラを通過することを一時的に許可するように、移動体通信通話のハンドオーバのターゲットとしてのパケット交換移動体通信ゲートウェイエンティティに命令するコマンド動作を実行する段階と、を含み、リソース割り当て動作の後でハンドオーバ応答動作の前にコマンド動作を実行する方法によって、目的が達成される。

第５の態様の変更形態は、以下のとおりとすることができる。

第５の態様による方法は、リバース単一無線音声通話継続性において音声ベアラを制御するのに好適とすることができる。

方法は更に、リアルタイムプロトコル及びリアルタイムプロトコル制御プロトコルベースのパケットが、パケット交換移動体通信ゲートウェイエンティティでデフォルトベアラとして設定されたベアラを通過することを一時的に許可するためのタイマをセットする段階と、タイマの有効期限切れ後に許可を取り消す段階と、を含むことができる。

方法は更に、移動体通信通話のハンドオーバ後の、音声メディアに関する専用ベアラのセットアップを認識した後に、一時的な通過許可を取り消す段階を含むことができる。

コマンド動作を実行する段階は、アップリンク及びダウンリンクのメディアアドレス及びポート番号を指示する段階と、このような指示されたアップリンク及びダウンリンクのメディアアドレス及びポート番号によって識別される送信先を有するパケットトラフィックへの一時的な許可を限定する段階と、を含むことができる。

本発明の第６の態様によれば、プログラムがコンピュータ上で実行される際に、ユーザ装置の移動体通信通話の回線交換移動体通信からパケット交換移動体通信へのハンドオーバに関して、移動体サービス交換エンティティによるハンドオーバ要求に応答して、移動体サービス交換エンティティへの応答を生成するハンドオーバ応答動作を実行する段階と、パケット交換移動体通信に関するリソースを割り当てるリソース割り当て動作を実行する段階と、リアルタイムプロトコル及びリアルタイムプロトコル制御プロトコルベースのパケットが、パケット交換移動体通信ゲートウェイエンティティでデフォルトベアラとして設定されたベアラを通過することを一時的に許可するように、移動体通信通話のハンドオーバのターゲットとしてのパケット交換移動体通信ゲートウェイエンティティに命令するコマンド動作を実行する段階と、を実行し、コマンド動作は、リソース割り当て動作後でハンドオーバ応答動作前に実行されるように構成された、コンピュータ実行可能構成要素を含むコンピュータプログラム製品によって、目的が達成される。

第６の態様の変更形態は、以下のとおりとすることができる。

第６の態様によるコンピュータプログラム製品は、リバース単一無線音声通話継続性において音声ベアラを制御するのに好適とすることができる。

第６の態様によるコンピュータプログラム製品は、コンピュータ可読記憶媒体として実装することができる。

本発明の第７の態様によれば、ユーザ装置の移動体通信通話の回線交換移動体通信からパケット交換移動体通信へのハンドオーバに関して、無線アクセスネットワークコントローラエンティティによって要求されたハンドオーバ指示に応答して、移動体管理エンティティへの要求を生成するハンドオーバ要求動作を実行するように構成されたハンドオーバ処理手段と、アクセス転送ゲートウェイ上でのメディアポートを割り当てることによって、パケット交換移動体通信へのメディア転送の準備をするようにアクセス転送制御機能に通知する通知動作を実行し、通知されたアクセス転送制御機能から、割り当てられたメディアポートを取得する取得動作を実行するように構成されたアクセス転送処理手段と、要求されたハンドオーバ指示が無線アクセスネットワークコントローラエンティティから取得された後でハンドオーバ処理手段がハンドオーバ要求動作を実行する前に、アクセス転送処理手段が通知動作及び取得動作の両方を実行するように、ハンドオーバ処理手段及びアクセス転送処理手段の動作を制御し、割り当てられたメディアポートに関する情報を移動体管理エンティティへの要求内に含めるようにハンドオーバ処理手段を制御するように構成された制御手段と、を備えた装置によって目的が達成される。

第７の態様の変更形態によれば、本装置は、リバース単一無線音声通話継続性において音声ベアラを生成して制御するのに好適とすることができる。

本発明の第８の態様によれば、ユーザ装置の移動体通信通話の回線交換移動体通信からパケット交換移動体通信へのハンドオーバに関して、無線アクセスネットワークコントローラエンティティによって要求されたハンドオーバ指示に応答して、移動体管理エンティティへの要求を生成するハンドオーバ要求動作を実行するように構成されたハンドオーバプロセッサと、アクセス転送ゲートウェイ上でのメディアポートを割り当てることによって、パケット交換移動体通信へのメディア転送の準備をするようにアクセス転送制御機能に通知する通知動作を実行し、通知されたアクセス転送制御機能から、割り当てられたメディアポートを取得する取得動作を実行するように構成されたアクセス転送プロセッサと、要求されたハンドオーバ指示が無線アクセスネットワークコントローラエンティティから取得された後でハンドオーバプロセッサがハンドオーバ要求動作を実行する前に、アクセス転送プロセッサが通知動作及び取得動作の両方を実行するように、ハンドオーバプロセッサ及びアクセス転送プロセッサの動作を制御し、割り当てられたメディアポートに関する情報を移動体管理エンティティへの要求内に含めるようにハンドオーバプロセッサを制御するように構成されたコントローラと、を備えた装置によって目的が達成される。

第８の態様の変更形態は、第７の態様の変更形態に対応することができる。

本発明の第９の態様によれば、第７又は第８の態様による装置を備えたシステム、パケット交換移動体通信ゲートウェイエンティティ、及び移動体管理エンティティによって目的は達成され、移動体管理エンティティは、割り当てられたメディアポートに関する情報を用いて、パケット交換移動体通信ゲートウェイエンティティとの移動体通信通話のハンドオーバ後に、音声メディアに関する専用ベアラを生成するように構成される。

第９の態様による変更形態は、以下のとおりとすることができる。

第９の態様によるシステムは、リバース単一無線音声通話継続性において音声ベアラを生成して制御するのに好適とすることができる。

移動体管理エンティティは、専用ベアラに関するトラフィックフローテンプレートをユーザ装置に提供するように構成することができる。

本発明の第１０の態様によれば、第７又は第８の態様、或いはこれらの変更形態による装置を備える移動体サービス交換局によって、目的が達成される。

本発明の第１１の態様によれば、ユーザ装置の移動体通信通話の回線交換移動体通信からパケット交換移動体通信へのハンドオーバに関して、無線アクセスネットワークコントローラエンティティによって要求されたハンドオーバ指示に応答して、移動体管理エンティティへの要求を生成するハンドオーバ要求動作を実行する段階と、アクセス転送ゲートウェイ上でのメディアポートを割り当てることによって、パケット交換移動体通信へのメディア転送の準備をするようにアクセス転送制御機能に通知する通知動作を実行する段階と、通知されたアクセス転送制御機能から、割り当てられたメディアポートを取得する取得動作を実行する段階と、を含み、要求されたハンドオーバ指示が無線アクセスネットワークコントローラエンティティから取得された後でハンドオーバ要求動作が実行される前に通知動作及び取得動作の両方を実行し、割り当てられたメディアポートに関する情報を移動体管理エンティティへの要求内に含める方法によって、目的が達成される。

第１１の態様の変更形態は、以下のとおりとすることができる。

第１１の態様による方法は、リバース単一無線音声通話継続性において音声ベアラを生成して制御するのに好適とすることができる。

方法は更に、パケット交換移動体通信ゲートウェイエンティティとの移動体通信通話のハンドオーバ後に、割り当てられたメディアポートに関する情報を使用して、移動体管理エンティティを用いて音声メディアに関する専用ベアラを生成する段階を含むことができる。

方法は更に、移動体管理エンティティを用いて専用ベアラ用のトラフィックフローテンプレートをユーザ装置に提供する段階を含むことができる。

本発明の第１２の態様によれば、プログラムがコンピュータ上で実行される際に、ユーザ装置の移動体通信通話の回線交換移動体通信からパケット交換移動体通信へのハンドオーバに関して、無線アクセスネットワークコントローラエンティティによって要求されたハンドオーバ指示に応答して、移動体管理エンティティへの要求を生成するハンドオーバ要求動作を実行する段階と、アクセス転送ゲートウェイ上でのメディアポートを割り当てることによって、パケット交換移動体通信へのメディア転送の準備をするようにアクセス転送制御機能に通知する通知動作を実行する段階と、通知されたアクセス転送制御機能から、割り当てられたメディアポートを取得する取得動作を実行する段階と、を実行し、要求されたハンドオーバ指示が無線アクセスネットワークコントローラエンティティから取得された後でハンドオーバ要求動作が実行される前に、通知動作及び取得動作の両方が実行され、割り当てられたメディアポートに関する情報が、移動体管理エンティティへの要求内に含まれるように構成されたコンピュータ実行可能構成要素を含むコンピュータプログラム製品によって、目的が達成される。

第１２の態様の変更形態は、以下のとおりとすることができる。

第１２の態様によるコンピュータプログラム製品は、リバース単一無線音声通話継続性において音声ベアラを生成して制御するのに好適とすることができる。

第１２の態様によるコンピュータプログラム製品は、コンピュータ可読記憶媒体として実装することができる。

任意の上記の変更形態は、代替形態を除外すると明示的に記載されていない限り、単独で又はこれらの変更形態が言及するそれぞれの態様と組み合わせて適用できることを理解されたい。

上記及び他の目的、機能、詳細、及び利点は、添付の図面と併せて好適な実施形態の以下の詳細説明を説明することにより、より完全に明らかになるであろう。

非ＤＴＭケースの公知のアクセス転送準備の代替形態を示す。 ＤＴＭケースの公知のアクセス転送準備の代替形態を示す。 本発明の特定の実施形態による装置を示す。 本発明の別の特定の実施形態による装置を示す。 本発明の更に別の特定の実施形態による方法を示す。 本発明の更に別の特定の実施形態による方法を示す。 本発明の更に別の特定の実施形態による実施例を示す。 本発明の更に別の特定の実施形態による別の実施例を示す。

本発明の好適な実施形態と現在みなされているものに関して、以下に説明する。しかしながら、この説明は、単なる例示であり、説明する実施形態は、本発明がこれらの実施形態に限定されると解釈されるものではないことを理解されたい。

例えば、例示目的で、以下の例示的な幾つかの実施形態では、例えば、ＬＴＥ又はＬＴＥ−Ａｄｖａｎｃｅｄに基づくセルラー通信ネットワークにおけるリバース単一無線音声通話継続性、すなわちＣＳからＰＳへの通話継続における音声ベアラの選択について説明する。しかしながら、これらの例示的な実施形態は、これらの特定のタイプの無線通信システム間での使用に限定されるものではなく、更なる例示的な実施形態によれば、本発明は更に、ＣＳからＰＳへのハンドオーバの通話継続において音声ベアラを選択することが実施され最適化されるように構成された他のタイプの通信システム及びアクセスネットワークに適用することができる。したがって、本発明の特定の実施形態は、３ＧＰＰ ＬＴＥ及び３ＧＰＰ ＬＴＥ−Ａｄｖａｎｃｅｄなどの移動体無線通信システムに関する。より詳細には、本発明の特定の実施形態は、ＬＴＥ ＭＳＣ及びこれらの構成要素の、並びにＬＴＥ ＭＭＥ及びこれらの構成要素の、コンフィギュレーション又は同様のものに関連する。

しかしながら、上述のように、本発明は、ＭＳＣ及びＭＭＥに限定されず、本発明の他の実施形態は、交換ネットワークノード及びこれらの構成要素に関連する。

図３は、本発明の特定の実施形態による装置１の実施例の主要構成を示している。本発明の特定の実施形態による装置に関してこの実施例を実施するための１つの選択肢は、ＬＴＥによるＭＭＥ内の構成要素である。

具体的には、図３に示すように、装置１の実施例は、ユーザ装置の移動体通信通話の回線交換移動体通信からパケット交換移動体通信へのハンドオーバに関して、移動体サービス交換エンティティによるハンドオーバ要求に応答して、移動体サービス交換エンティティへの応答を生成するハンドオーバ応答動作を実行するように構成されたハンドオーバプロセッサ３２と、パケット交換移動体通信に関するリソースを割り当てるリソース割り当て動作を実行するように構成されたリソース割り当てプロセッサ３３と、リアルタイムプロトコル及びリアルタイムプロトコル制御プロトコルベースのパケットが、パケット交換移動体通信ゲートウェイエンティティでのデフォルトベアラとして設定されたベアラを通過することを一時的に許可するように、移動体通信通話のハンドオーバのターゲットとしてのパケット交換移動体通信ゲートウェイエンティティに命令するコマンド動作を実行し、リソース割り当てプロセッサ３３がリソース割り当て動作を実行した後でハンドオーバプロセッサ３２がハンドオーバ応答動作を実行する前に、コマンド動作を実行するようにハンドオーバプロセッサ３２及びリソース割り当てプロセッサ３３の動作を制御するように構成されたコントローラ３１と、を含む。

図４は、本発明の特定の実施形態による装置２の実施例の主要構成を示している。本発明の特定の実施形態による装置に関してこの実施例を実施するための１つの選択肢は、ＬＴＥによるＭＳＣ内の構成要素である。

具体的には、図４に示すように、装置２の実施例は、ユーザ装置の移動体通信通話の回線交換移動体通信からパケット交換移動体通信へのハンドオーバに関して、無線アクセスネットワークコントローラエンティティによって要求されたハンドオーバ指示に応答して、移動体管理エンティティへの要求を生成するハンドオーバ要求動作を実行するように構成されたハンドオーバプロセッサ４２と、アクセス転送ゲートウェイ上でのメディアポートを割り当てることによって、パケット交換移動体通信へのメディア転送の準備をするようにアクセス転送制御機能に通知する通知動作を実行し、通知されたアクセス転送制御機能から、割り当てられたメディアポートを取得する取得動作を実行するように構成されたアクセス転送プロセッサ４３と、要求されたハンドオーバ指示が無線アクセスネットワークコントローラエンティティから取得された後でハンドオーバプロセッサ４２がハンドオーバ要求動作を実行する前に、アクセス転送プロセッサ４３が通知動作及び取得動作の両方を実行するように、ハンドオーバプロセッサ４２及びアクセス転送プロセッサ４３の動作を制御し、割り当てられたメディアポートに関する情報を移動体管理エンティティへの要求内に含めるようにハンドオーバプロセッサ４２を制御するように構成されたコントローラ４１と、を含む。

図５は、本発明の特定の実施形態による方法に関する実施例の主要フローチャートを示している。すなわち、図５に示すように、この方法は、ユーザ装置の移動体通信通話の回線交換移動体通信からパケット交換移動体通信へのハンドオーバに関して、移動体サービス交換エンティティによるハンドオーバ要求に応答して、移動体サービス交換エンティティへの応答を生成するハンドオーバ応答動作Ｓ５３を実行する段階と、パケット交換移動体通信に関するリソースを割り当てるリソース割り当て動作Ｓ５１を実行する段階と、リアルタイムプロトコル及びリアルタイムプロトコル制御プロトコルベースのパケットが、パケット交換移動体通信ゲートウェイエンティティでデフォルトベアラとして設定されたベアラを通過することを一時的に許可するように、移動体通信通話のハンドオーバのターゲットとしてのパケット交換移動体通信ゲートウェイエンティティに命令するコマンド動作Ｓ５２を実行する段階と、を含み、コマンド動作Ｓ５２は、リソース割り当て動作Ｓ５１の後でハンドオーバ応答動作Ｓ５３前に実行される。

本発明の特定の実施形態による方法の実施例を実施するための１つの選択肢は、上述のように、又は本明細書において以下で説明する実施形態から明らかになる変更例として、装置１を使用することである。

図６は、本発明の特定の実施形態による別の方法の実施例の主要フローチャートを示している。すなわち、図６に示すように、この方法は、ユーザ装置の移動体通信通話の回線交換移動体通信からパケット交換移動体通信へのハンドオーバに関して、無線アクセスネットワークコントローラエンティティによって要求されたハンドオーバ指示Ｓ６１に応答して、移動体管理エンティティへの要求を生成するハンドオーバ要求動作Ｓ６４を実行する段階と、アクセス転送ゲートウェイ上でのメディアポートを割り当てることによって、パケット交換移動体通信へのメディア転送の準備をするようにアクセス転送制御機能に通知する通知動作Ｓ６２を実行する段階と、通知されたアクセス転送制御機能から、割り当てられたメディアポートを取得する取得動作Ｓ６３を実行する段階と、を含み、要求されたハンドオーバ指示Ｓ６１が無線アクセスネットワークコントローラエンティティから取得された後でハンドオーバ要求動作Ｓ６４が実行される前に、通知動作Ｓ６２及び取得動作Ｓ６３の両方が実行され、割り当てられたメディアポートに関する情報が、移動体管理エンティティへの要求Ｓ６４内に含まれる。

本発明の特定の実施形態による別の方法の実施例を実施するための１つの選択肢は、上述のように、又は本明細書において以下で説明する実施形態から明らかになる変更例として、装置２を使用することである。

本発明の特定の実施形態を、本明細書で以下に更に詳細に説明する。本発明の特定の実施形態を示す実施例に言及する。しかしながら、実施例は単に例示目的で提供するものであり、本発明がこれらに限定されると理解すべきではないことに留意されたい。より正確に言えば、実施例の機能は、本明細書全体から理解されるように置き換えること及び組み合わせることができることを理解されたい。

上記で参照した仕様書ＴＲ ２３．８８５（バージョン１．４．０）では、デフォルトベアラを音声メディアに関して一時的に使用する方法については規定されていない。ＩＭＳ ＶｏＩＰに関して、ＩＭＳサービスのみに限定される公知のＩＭＳ ＡＰＮが使用され、これは、ＧＳＭＡのｐｅｒｍａｎｅｎｔ ｒｅｆｅｒｅｎｃｅ ｄｏｃｕｍｅｎｔのＩＲ．９２によって以下のように規定される。
「ＩＭＳアプリケーションは、ＰＲＤ ＩＲ．８８で規定されるようにＩＭＳの公知のＡＰＮを使用する必要があり、他の任意のアプリケーションはこのＡＰＮを使用してはならない。デフォルトベアラに関しては、標準化されたＱＣＩ値５を使用する必要がある。これは、ＩＭＳ ＳＩＰシグナリングに関して使用される。」

このことが意味することは、通常、ＰＤＮ−ＧＷがＩＭＳシグナリング（ＳＩＰ及びＸＣＡＰ）に関連するパケットのみを通過させることを許可し、他のタイプのパケットが遮断されるということである。この種類の遮断は、Ｐ−ＧＷにおいてポリシールールを導入することによって行い、場合によっては、ＴＦＴを用いてＵＥにシグナリングされる。

いずれのＴＦＴ情報もない場合、ＵＥは、他のタイプのＩＭＳ又は非ＩＭＳ関連のトラフィックを搬送するためにＱＣＩ−５（高プライオリティＱＣＩ）を不正利用する場合があり、ＰＤＮ−ＧＷがトラフィックを暗黙的にドロップする場合がある。したがって、ＰＤＮ−ＧＷが、ｒＳＲＶＣＣ手順中に音声メディアを一時的にＰＤＮ−ＧＷを通過させることを許可することを保証するための機構が必要とされる。３ＧＰＰは、現時点でこの課題を検討していない。第１の実施例によれば、解決手段は、ＭＭＥ指示に基づく一時的なＲＴＰフローを含む。この実施例は、以下を含む。

ａ．通常条件では、ＰＤＮ−ＧＷ（すなわち、ＰＣＥＦ）は、ＩＭＳシグナリングパケットのみが、ＵＥに向けて又はＵＥからＰＤＮに向けて送信されることを保証するように構成される。

ｂ．ｒＳＲＶＣＣ手順中、図１及び２の段階７よりも以前に（すなわち、肯定のリロケーション応答で２Ｇ／３Ｇに応答を返信する前に）、ＭＭＥは、ＰＤＮ−ＧＷに、ＲＴＰ及びＲＴＣＰパケットをデフォルトベアラ上で一時的に通過させるように指示する。Ｐ−ＧＷは、ローカルタイマを用いて、ＲＴＰ／ＲＴＣＰパケットが通過できる期間を制御することができる。ＭＭＥは更に、ＵＬ及びＤＬメディアのＩＰアドレス及び／又はポート番号をＰＤＮ−ＧＷに指示し、Ｐ−ＧＷが、この送信先に向かう／この送信先からの、これらのＲＴＰパケットのみを一時的に通過させることを許可する。代替的に、ＭＭＥは、Ｐ−ＧＷ内のローカルポリシーデータをトリガしてＲＴＰ／ＲＴＣＰを許可するための「ベアラ変更」（図１の段階１２又は図２の段階１３）で新規ＲＡＴを送信することができる。Ｐ−ＧＷは更に、ＰＣＲＦによるポリシーを要求することができる。ＰＳ−ＰＳ ＨＯの場合にも新規ＲＡＴが生じるので、この場合も、タイマが必要である。別の代替形態として、ＭＭＥは更に、ＲＴＰ／ＲＴＣＰを許可する及び許可しないようにＰＧＷに伝えるｒＳＲＶＣＣ指示を送信することができる（すなわち、タイマは不要）。

ｃ．ｒＳＲＶＣＣの後、ＵＥは、図面の段階１４に示すように、デフォルトベアラを一時的に用いて音声メディアを送信して、段階１６から１７でＱＣＩ−１に切り替える。ＰＤＮ−ＧＷは、ローカルタイマの有効期限切れ又はＱＣＩ−１の確立に基づいて、デフォルトベアラ経由でのＲＴＰを制限する。

第１の実施例は、仕様書ＴＲ ２３．８８５（バージョン１．４．０）によって現在用いられている原理に従い、この場合、ＵＥがＥ−ＵＴＲＡＮに接続した後にＱＣＩ−１ベアラが生成される。この実施例は更に、仕様書ＴＲ ２３．８８５（バージョン１．４．０）には欠落している「ＱＣＩ−５経由の一時的なユーザプレーン通過」問題にいかに対処するかについての機構を提供する。

第２の実施例によれば、解決手段は、ＭＭＥによるｒＳＲＶＣＣ中のＱＣＵ−１生成を含む。この実施例は、以下を含む。

図１及び２の段階２及び３の順序を入れ替える。これにより、ＭＳＣサーバがＡＴＣＦからＵＬメディアＩＰ／ポートを取得できるようになり、ＵＥが、ＣＳからＰＳへのＨＯ要求をＭＭＥに向けて開始する前にＬＴＥ側に音声メディアを送信するために、このＵＬメディアＩＰ／ポートを使用する。ＭＳＣサーバは、ＵＥがＬＴＥ側でのメディアを受信するために使用されるＤＬ ＩＰアドレス及びポート番号を、本明細書では詳細に規定していない何らかのＮＡＳ手順に基づいて既に認識している。新規の段階３において、ＭＳＣサーバは、ＭＭＥのためにこのＤＬ／ＵＬ ＩＰ／ポート情報を含める。その後、ＭＭＥはこの情報を用いて、ＰＤＮ−ＧＷとのＱＣＩ−１ベアラを生成することができ、このＱＣＩ−１に関するＴＦＴは、「ＣＳ ｔｏ ＰＳ ＨＯ ｒｅｓｐｏｎｓｅ（ＣＳからＰＳへのＨＯ応答）」（図１及び２の段階７）を介してＵＥに返送することができる。ＭＭＥは更に、ベアラ変更手順を用いてｅＮＢ情報をＳ−ＧＷに示して、図１及び２の段階６後にｅＮＢ情報を示すことができる点に留意されたい。図１及び２の段階１４において、ＵＥは、専用音声ベアラ（ＱＣＩ−１）上で音声メディアを送信し、メディアをデフォルトからＱＣＩ−１に入れ替える必要がない。

第２の実施例は、デフォルトベアラに対して特別な制限を課すことはない。ＵＥは、ｒＳＲＶＣＣの直後に、音声に関してＱＣＩ−１ベアラを使用することができ、より良好なユーザエクスペリエンスを提供することができる。第２の実施例は更に、図１及び図２の段階８ａのＣＳからＰＳへのＨＯコマンド中に、ＭＳＣサーバがＵＬメディアのＩＰ／ポート情報をＵＥに加えることを必要としておらず、これは通常は、ＭＳＣ又はソース側の機能ではない。

第２の実施例は更に、ＰＳ音声メディア（ＱＣＩ−１）に対応する無線リソースが確保されていない場合には（すなわち、輻輳中）、ターゲットＮｂ／ｅＮｂがこのハンドオーバを拒否できるようにする。この指示により、ソース側は、ＣＳ音声通話を維持して、後の時間に又は別のターゲットセルに対してハンドオーバを再試行することができる。この種類の実施例は、ターゲット側が、ハンドオーバ要求をソース側に対して許可する前に、必要な無線及びコアのリソースを確保するという典型的なハンドオーバ原理を維持する。

以下、第２の実施例を、図７及び８を参照することによって更に詳細に説明する。

図７は、第２の実施例による、ＤＴＭに対応しないＧＥＲＡＮ／ＵＴＲＡＮからＥ−ＵＴＲＡＮへのＳＲＶＣＣに関するコールフローを示している。

１．ＢＳＣ／ＲＮＣは、このＨＯがｒＳＲＶＣＣに関するものであるという通知を含む「ＨＯ ｒｅｑｕｉｒｅｄ（ＨＯが必要）」メッセージをＭＳＣサーバに送信する。ＭＳＣサーバがターゲットＭＳＣである場合、ＭＳＣサーバは「ＨＯ ｒｅｑｕｉｒｅｄ（ＨＯが必要）」メッセージをアンカーＭＳＣサーバに転送する。

２．ＭＳＣサーバは、「Ａｃｃｅｓｓ Ｔｒａｎｓｆｅｒ Ｎｏｔｉｆｉｃａｔｉｏｎ（アクセス転送通知）」メッセージ、例えば、ＳＩＰ「ｒｅ−ＩＮＶＩＴＥ」又は「ＩＮＶＩＴＥ」メッセージをＡＴＣＦに送信して、ＡＴＣＦがＰＳへのメディア転送の準備をする必要があることをＡＴＣＦに通知する。ＡＴＣＦは、ＡＴＧＷ上でのメディアポートを割り当てる。ＵＬ方向に関してＡＴＣＦによって割り当てられたメディアＩＰ／ポート及びコーデックが、応答メッセージ内でＭＳＣサーバに提供される。

３．ＭＳＣサーバは、ＳＲＶＣＣ「ＣＳ ｔｏ ＰＳ ＨＯ ｒｅｑｕｅｓｔ（ＣＳからＰＳへのＨＯ要求）」メッセージをターゲットＭＭＥに送信する。このメッセージは、ＰＳベアラに関する音声メディア（すなわち、ＡＴＧＷのメディアＩＰ／ポート及びＵＥのポート及びコーデック）を含む。必要に応じて、ＵＥを識別するためのＩＭＳＩが提供される。

４．ＭＭＥがＵＥコンテキストを有しない場合、ＭＭＥは、Ｐ−ＴＭＳＩ及びＲＡＩを用いて「Ｃｏｎｔｅｘｔ Ｒｅｑｕｅｓｔ（コンテキスト要求）」メッセージを送信して、以前のＳＧＳＮを発見する。

５．ＳＧＳＮは、すべてのＵＥコンテキストを含む「Ｃｏｎｔｅｘｔ Ｒｅｓｐｏｎｓｅ（コンテキスト応答）」メッセージで応答する。

６．ＭＭＥは、「Ｃｒｅａｔｅ Ｓｅｓｓｉｏｎ Ｒｅｑｕｅｓｔ（セッション生成要求）」メッセージで、ＡＴＧＷ及びＵＥのコーデック及びＩＰ／ポート情報によりＱＣＩ−１ベアラを生成する。

７．「Ｃｒｅａｔｅ Ｓｅｓｓｉｏｎ Ｒｅｓｐｏｎｓｅ（セッション生成応答）」メッセージは、ＱＣＩ−１に関するＴＦＴを含む。

８．ターゲットＭＭＥは、Ｅ−ＵＴＲＡＮでのリソースを割り当てる。

９．ＱＣＩ−１を含むＴＦＴを包含するＳＲＶＣＣ「ＣＳ ｔｏ ＰＳ ＨＯ ｒｅｓｐｏｎｓｅ（ＣＳからＰＳへのＨＯ応答）」メッセージが、ターゲットＭＭＥからＭＳＣサーバに返信される。

１０．ＭＳＣサーバは、「ＨＯ ｒｅｑｕｉｒｅｄ Ａｃｋ（「ＨＯが必要」の肯定応答）」メッセージを、場合によってはターゲットＭＳＣを介してＲＡＮに送信し、ＲＡＮは、ＣＳからＰＳへのハンドオーバを指示する「ＨＯ ｃｏｍｍａｎｄ（ＨＯコマンド）」メッセージをＵＥに送信する。

１１．ＡＴＧＷでメディアがアンカーされるＡＴＣＦの場合、ＭＳＣサーバは、「Ａｃｃｅｓｓ Ｔｒａｎｓｆｅｒ Ｐｒｅｐａｒａｔｉｏｎ Ｒｅｑｕｅｓｔ（アクセス転送準備要求）」メッセージ、例えば、ＳＩＰ「ｒｅ−ＩＮＶＩＴＥ」又は「ＰＲＡＣＫ」メッセージをＡＴＣＦに送信して、ＡＴＣＦ／ＡＴＧＷが、メディアパスを、ターゲットアクセスでのＵＥのＩＰアドレス／ポートに切り替えるようにトリガする。ＡＴＧＷでメディアがアンカーされないＡＴＣＦの場合、ＭＳＣサーバは、「Ａｃｃｅｓｓ Ｔｒａｎｓｆｅｒ Ｐｒｅｐａｒａｔｉｏｎ Ｒｅｑｕｅｓｔ（アクセス転送準備要求）」メッセージをＡＴＣＦに送信して、ＡＴＣＦ／ＡＴＧＷとＭＳＣサーバ／ＭＧＷとの間のメディアパスが確立されることになる。

１２．ＵＥは、「Ｈａｎｄｏｖｅｒ ｃｏｎｆｉｒｍａｔｉｏｎ（ハンドオーバ確認）」メッセージをｅＮＢに送信する。

１３．ｅＮＢは、「Ｈａｎｄｏｖｅｒ Ｎｏｔｉｆｙ（ハンドオーバ通知）」メッセージをＭＭＥに送信する。

１４−１５．ＭＭＥは、「Ｍｏｄｉｆｙ Ｂｅａｒｅｒ Ｒｅｑｕｅｓｔ（ベアラ変更要求）」メッセージをＳＧＷに送信し、このメッセージがＰＧＷに転送されて、ＰＳベアラコンテキストが更新され、その後、これが応答される。

１６．音声メディアがＱＣＩ−１で直接的に開始される。

１７．ＵＥは、例えば３ＧＰＰの仕様書ＴＳ ２３．２３７によるセッション継続手順をＡＴＣＦに向けて開始する。

図８は、非音声成分の処理を含む、ＤＴＭ ＨＯに対応するＧＥＲＡＮ／ＵＴＲＡＮからＥ−ＵＴＲＡＮへのＳＲＶＣＣに関するコールフローを示している。

１．ＢＳＣ／ＲＮＣは、このＨＯがｒＳＲＶＣＣに関するものであるという通知を含む「ＨＯ ｒｅｑｕｉｒｅｄ（ＨＯが必要）」メッセージをＭＳＣサーバに送信する。ＭＳＣサーバがターゲットＭＳＣである場合、ＭＳＣサーバは「ＨＯ ｒｅｑｕｉｒｅｄ（ＨＯが必要）」メッセージをアンカーＭＳＣサーバに転送する。

１ａ．ＤＴＭケースでは、ＵＥが既にＰＳドメイン内でアクティブであり、ＢＳＣ／ＲＮＣは更に、「Ｒｅｌｏｃａｔｉｏｎ Ｒｅｑｕｉｒｅｄ（リロケーションが必要）」メッセージをソースＳＧＳＮに送信する。

２．ＭＳＣサーバは、「Ａｃｃｅｓｓ Ｔｒａｎｓｆｅｒ Ｎｏｔｉｆｉｃａｔｉｏｎ（アクセス転送通知）」メッセージをＡＴＣＦに送信して、ＡＴＣＦがＰＳへのメディア転送の準備をする必要があることをＡＴＣＦに通知する。ＡＴＣＦは、ＡＴＧＷでのＤＬメディアポートを割り当てる。ＡＴＣＦによって割り当てられたメディアＩＰ／ポート及びコーデックが、応答メッセージでＭＳＣサーバに提供される。

３．ＭＳＣサーバは、ＳＲＶＣＣ「ＣＳ ｔｏ ＰＳ ＨＯ ｒｅｑｕｅｓｔ（ＣＳからＰＳへのＨＯ要求）」メッセージをターゲットＭＭＥに送信する。必要に応じて、ＵＥを識別するためのＩＭＳＩが提供される。

４．ソースＳＧＳＮは、「Ｒｅｌｏｃａｔｉｏｎ Ｒｅｑｕｅｓｔ（リロケーション要求）」メッセージをターゲットＭＭＥに送信する。

５．ＭＭＥは、「Ｃｒｅａｔｅ Ｓｅｓｓｉｏｎ Ｒｅｑｕｅｓｔ（セッション生成要求）」メッセージで、ＡＴＧＷ及びＵＥのコーデック及びＩＰ／ポート情報によりＱＣＩ−１ベアラを生成する。

６．「Ｃｒｅａｔｅ Ｓｅｓｓｉｏｎ Ｒｅｓｐｏｎｓｅ（セッション生成応答）」メッセージは、ＱＣＩ−１に関するＴＦＴを含む。

７．ターゲットＭＭＥは、Ｅ−ＵＴＲＡＮでのリソースを割り当てる。

８ａ．「ｒｅｌｏｃａｔｉｏｎ ｒｅｓｐｏｎｓｅ（リロケーション応答）」メッセージがソースＳＧＳＮに返信される。

８ｂ．ソースＳＧＳＮは、「ＨＯ Ｒｅｑｕｉｒｅｄ Ａｃｋ（「ＨＯが必要」の肯定応答）」メッセージをＲＡＮに送信する。

９．ＱＣＩ−１ベアラに関するＴＦＴを含むＳＲＶＣＣ「ＣＳ ｔｏ ＰＳ ＨＯ ｒｅｓｐｏｎｓｅ（ＣＳからＰＳへのＨＯ応答）」メッセージがターゲットＭＭＥからＭＳＣサーバに返信される。

１０．ＭＳＣサーバは、「ＨＯ ｒｅｑｕｉｒｅｄ Ａｃｋ（「ＨＯが必要」の肯定応答）」メッセージを、場合によってはターゲットＭＳＣを介してＲＡＮに送信し、ＲＡＮは、ＣＳからＰＳへのハンドオーバを指示する「ＨＯ ｃｏｍｍａｎｄ（ＨＯコマンド）」メッセージをＵＥに送信する。

１１．ＡＴＧＷでメディアがアンカーされるＡＴＣＦの場合、ＭＳＣサーバは、「Ａｃｃｅｓｓ Ｔｒａｎｓｆｅｒ Ｐｒｅｐａｒａｔｉｏｎ Ｒｅｑｕｅｓｔ（アクセス転送準備要求）」メッセージ、例えば、ＳＩＰ「ｒｅ−ＩＮＶＩＴＥ」又は「ＰＲＡＣＫ」メッセージをＡＴＣＦに送信して、ＡＴＣＦ／ＡＴＧＷが、メディアパスを、ターゲットアクセスでのＵＥのＩＰアドレス／ポートに切り替えるようにトリガする。ＡＴＧＷでメディアがアンカーされないＡＴＣＦの場合、ＭＳＣサーバは、「Ａｃｃｅｓｓ Ｔｒａｎｓｆｅｒ Ｐｒｅｐａｒａｔｉｏｎ Ｒｅｑｕｅｓｔ（アクセス転送準備要求）」メッセージをＡＴＣＦに送信して、ＡＴＣＦ／ＡＴＧＷとＭＳＣサーバ／ＭＧＷとの間のメディアパスが確立されることになる。

１２．ＵＥは、「Ｈａｎｄｏｖｅｒ ｃｏｎｆｉｒｍａｔｉｏｎ（ハンドオーバ確認）」メッセージをｅＮＢに送信する。

１３．ｅＮＢは、「Ｈａｎｄｏｖｅｒ Ｎｏｔｉｆｙ（ハンドオーバ通知）」メッセージをＭＭＥに送信する。

１４．ＭＭＥは、「Ｆｏｒｗａｒｄ ｒｅｌｏｃａｔｉｏｎ Ｃｏｍｐｌｅｔｅ（リロケーション転送完了）」メッセージを以前のＳＧＳＮに送信する。

１５．ＭＭＥは、「Ｍｏｄｉｆｙ Ｂｅａｒｅｒ Ｒｅｑｕｅｓｔ（ベアラ変更要求）」メッセージをＳＧＷに送信して、このメッセージがＰＧＷに転送されて、ＰＳベアラコンテキストが更新される。

１６．音声メディアが、ＱＣＩ−１でのＴＦＴを用いて直接的に開始される。

１７．ＵＥは、３ＧＰＰの仕様書ＴＳ ２３．２３７によるセッション継続手順をＡＴＣＦに向けて開始する。

上述のように、本発明の特定の実施形態は、ＬＴＥ／ＬＴＥ−ＡｄｖａｎｃｅｄによるようなＭＳＣ及びＭＭＥ装置を含むが、これらに限定されるものではない。

このように、上記の説明によれば、本発明の例示的な実施形態は、例えば、ＭＳＣ又はＭＭＥ或いはこれらの構成要素のようなネットワーク要素の観点から、これらを実装する装置と、これらを制御及び／又は動作させるための方法と、これらを制御及び／又は動作させるコンピュータプログラムと、このようなコンピュータプログラムを保持しコンピュータプログラム製品を構成する媒体と、を提供することは明らかである。

例えば、リバース単一無線音声通話継続性において音声ベアラを選択することができる装置、方法、及びコンピュータプログラム製品を上記に説明した。

上述のブロック、装置、システム、技術、又は方法のいずれかの実施例は、非限定的な例として、例えば、デジタルシグナルプロセッサ、命令セット、ファームウェア、専用回路又はアプリケーションロジック、汎用ハードウェア又はコントローラ又は他のコンピューティングデバイス、或いはこれらの組み合わせに関連して、ハードウェア、ソフトウェアとしての実施例を含む。ソフトウェア、アプリケーションロジック、又は命令セットは、種々の従来型の利用可能なコンピュータ可読媒体（命令実行システムと関連して、命令を含むこと、格納すること、伝達すること、伝搬すること、又は伝送することができる任意のものと理解される）のいずれか１つに保持することができる。更に、プロセッサに言及すると、このようなプロセッサは、最も広範な意味で理解され、例えば、メモリ（例えば、ＲＯＭ、ＣＤ−ＲＯＭ、その他）を追加的に含むこと又は含まないことができ、説明した機能を実行するようにプログラムされたコンピュータプロセッサ、特定用途向け集積回路（ＡＳＩＣ）、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）、及び／又は他のハードウェア構成要素を含むことができることを理解されたい。

必要に応じて、本明細書で説明する種々の機能を異なる順序で及び／又は互いに同時に実行することができる。更に、必要に応じて、上述の機能の１又はそれ以上は、選択的とすること、又は組み合わせることができる。

本発明の種々の態様を独立請求項に記載しているが、本発明の他の態様は、特許請求の範囲内に明示的に記載された組み合わせだけでなく、説明した実施形態及び／又は従属請求項による機能と独立請求項の機能との他の組み合わせを含むことができる。

本発明の好ましい実施形態と現在みなされているものを上記に説明した。しかしながら、当業者であれば明らかなように、これらは単に例示目的で示すものであり、本発明がこれらの実施形態に限定されることを意図していない。より正確に言えば、特許請求の範囲の思想及び範囲内に含まれるすべての変更例及び修正例が含まれることを意図している。

Claims (12)

1. ユーザ装置の移動体通信通話の回線交換移動体通信からパケット交換移動体通信へのハンドオーバに関して、移動体サービス交換エンティティによるハンドオーバ要求に応答して、前記移動体サービス交換エンティティへの応答を生成するハンドオーバ応答動作を実行するように構成されたハンドオーバ処理手段と、
   前記パケット交換移動体通信に関するリソースを割り当てるリソース割り当て動作を実行するように構成されたリソース割り当て手段と、
   リアルタイムプロトコル及びリアルタイムプロトコル制御プロトコルベースのパケットが、パケット交換移動体通信ゲートウェイエンティティでデフォルトベアラとして設定されたベアラを通過することを一時的に許可するように、前記移動体通信通話のハンドオーバのターゲットとしての前記パケット交換移動体通信ゲートウェイエンティティに命令するコマンド動作を実行し、前記リソース割り当て手段が前記リソース割り当て動作を実行した後で前記ハンドオーバ処理手段が前記ハンドオーバ応答動作を実行する前に、前記コマンド動作を実行するように前記ハンドオーバ処理手段及び前記リソース割り当て手段の動作を制御するように構成された制御手段と、
   を備える装置。
2. 請求項１に記載の前記装置と、
   前記移動体通信通話のハンドオーバのターゲットとしての前記パケット交換移動体通信ゲートウェイエンティティと、
   を備えるシステム。
3. 前記パケット交換移動体通信ゲートウェイエンティティは、リアルタイムプロトコル及びリアルタイムプロトコル制御プロトコルベースのパケットが、前記パケット交換移動体通信ゲートウェイエンティティでデフォルトベアラとして設定されたベアラを通過することを一時的に許可するためのタイマをセットして、前記タイマの有効期限切れ後に前記許可を取り消すように構成された、請求項２に記載のシステム。
4. 前記パケット交換移動体通信ゲートウェイエンティティは、前記移動体通信通話のハンドオーバ後の、音声メディアに関する専用ベアラのセットアップを認識した後に、前記一時的な通過許可を取り消すように構成された、請求項２に記載のシステム。
5. 前記コマンド動作は、アップリンク及びダウンリンクのメディアアドレス及びポート番号の指示と、このような指示されたアップリンク及びダウンリンクのメディアアドレス及びポート番号によって識別される送信先を有するパケットトラフィックへの前記一時的許可を限定することとを含む、請求項２から４のいずれか１項に記載のシステム。
6. 請求項１に記載の前記装置を備える、移動体管理エンティティ。
7. ユーザ装置の移動体通信通話の回線交換移動体通信からパケット交換移動体通信へのハンドオーバに関して、移動体サービス交換エンティティによるハンドオーバ要求に応答して、前記移動体サービス交換エンティティへの応答を生成するハンドオーバ応答動作を実行する段階と、
   前記パケット交換移動体通信に関するリソースを割り当てるリソース割り当て動作を実行する段階と、
   リアルタイムプロトコル及びリアルタイムプロトコル制御プロトコルベースのパケットが、パケット交換移動体通信ゲートウェイエンティティでデフォルトベアラとして設定されたベアラを通過することを一時的に許可するように、前記移動体通信通話のハンドオーバのターゲットとしての前記パケット交換移動体通信ゲートウェイエンティティに命令するコマンド動作を実行する段階と、
   を含む方法であって、
   前記コマンド動作は、前記リソース割り当て動作の後で前記ハンドオーバ応答動作の前に実行されることを特徴とする方法。
8. リアルタイムプロトコル及びリアルタイムプロトコル制御プロトコルベースのパケットが、前記パケット交換移動体通信ゲートウェイエンティティでデフォルトベアラとして設定されたベアラを通過することを一時的に許可するためのタイマをセットする段階と、
   前記タイマの有効期限切れ後に前記許可を取り消す段階と、
   を更に含む、請求項７に記載の方法。
9. 前記移動体通信通話のハンドオーバ後の、音声メディアに関する専用ベアラのセットアップを認識した後に、前記一時的な通過許可を取り消す段階を更に含む、請求項７に記載の方法。
10. 前記コマンド動作を実行する段階は、アップリンク及びダウンリンクのメディアアドレス及びポート番号を指示する段階と、このような指示されたアップリンク及びダウンリンクのメディアアドレス及びポート番号によって識別される送信先を有するパケットトラフィックへの前記一時的許可を限定する段階と、
    を含む、請求項７から９のいずれか１項に記載の方法。
11. コンピュータに、
    ユーザ装置の移動体通信通話の回線交換移動体通信からパケット交換移動体通信へのハンドオーバに関して、移動体サービス交換エンティティによるハンドオーバ要求に応答して、前記移動体サービス交換エンティティへの応答を生成するハンドオーバ応答動作を実行する段階と、
    前記パケット交換移動体通信に関するリソースを割り当てるリソース割り当て動作を実行する段階と、
    リアルタイムプロトコル及びリアルタイムプロトコル制御プロトコルベースのパケットが、パケット交換移動体通信ゲートウェイエンティティでデフォルトベアラとして設定されたベアラを通過することを一時的に許可するように、前記移動体通信通話のハンドオーバのターゲットとしての前記パケット交換移動体通信ゲートウェイエンティティに命令するコマンド動作を実行する段階と、
    を実行させ、
    前記コマンド動作は、前記リソース割り当て動作の後で前記ハンドオーバ応答動作の前に実行されることを特徴とするコンピュータプログラム。
12. 請求項１１に記載のコンピュータプログラムを記録したコンピュータ可読記憶媒体。

Images