JP2014507081A - 異なるネットワーク間を移動する場合におけるｉｐ継続の喪失を阻止すること - Google Patents

Abstract

本開示の態様は、ネットワーク間を移動する場合にＩＰ継続の喪失を阻止するための技術を提供する。ある態様は、一般に、ＩＰセッション中に第１のＲＡＴネットワークから第２のＲＡＴネットワークへの移動が試みられると第１のタイマを起動することと、第２のＲＡＴネットワークにおけるチャネルが正しく獲得された場合に第２のタイマを起動することと、を含む方法を提供する。態様によれば、第２のタイマが終了する前に、セッションが第２のネットワークにおいて正しくネゴシエートされ、第１のネットワークと第２のネットワークとが、ＩＰサービスのために共通のコア・ネットワークを共有するのであれば、デバイスは、ＩＰセッションのコンテキストを第２のＲＡＴネットワークへ転送しうる。

Description

関連出願に対する相互参照

本願は、２０１０年１２月１７日に出願された米国仮特許出願６１／４２４，５４４号の利益を主張する。この開示は、参照によって本明細書に明確に組み込まれている。

本開示のある態様は、一般に、無線通信に関し、さらに詳しくは、ＩＰサービスのために同じコア・ネットワークに接続されたラジオ・アクセス技術（ＲＡＴ）間をデバイスが移動する場合におけるインターネット・プロトコル（ＩＰ）継続の喪失を阻止することに関する。

無線通信システムは、例えば、音声、データ等のようなさまざまなタイプのコンテンツを提供するために広く開発されてきた。これらのシステムは、（例えば、帯域幅、送信電力等のような）利用可能なシステム・リソースを共有することにより、複数のユーザとの通信をサポートすることができる多元接続システムでありうる。このような多元接続システムの例は、符号分割多元接続（ＣＤＭＡ）システム、時分割多元接続（ＴＤＭＡ）システム、周波数分割多元接続（ＦＤＭＡ）システム、第３世代パートナシップ計画（３ＧＰＰ）ロング・ターム・イボリューション（ＬＴＥ）システム、および直交周波数分割多元接続（ＯＦＤＭＡ）システムを含む。

通常、無線多元接続通信システムは、複数の無線端末のための通信を同時にサポートしうる。端末はおのおのの、順方向リンクおよび逆方向リンクによる送信を介して、１または複数の基地局と通信する。順方向リンク（すなわちダウンリンク）は、基地局から端末への通信リンクを称し、逆方向リンク（すなわちアップリンク）は、端末から基地局への通信リンクを称する。順方向通信リンクおよび逆方向通信リンクは、単一入力単一出力システム、複数入力単一出力システム、あるいは複数入力複数出力（ＭＩＭＯ）システムによって確立されうる。

無線多元通信システムは、時分割デュプレクス（ＴＤＤ）システムおよび周波数デュプレクス（ＦＤＤ）システムをサポートしうる。ＴＤＤシステムでは、相互原理によって、逆方向リンク・チャネルから順方向リンク・チャネルを推定できるように、順方向リンク送信および逆方向リンク送信が、同じ周波数領域にある。これによって、アクセス・ポイントにおいて複数のアンテナが利用可能である場合、アクセス・ポイントは、順方向リンクで送信ビーム・フォーミング・ゲインを抽出できるようになる。

３ＧＰＰ ＬＴＥは、セルラ技術における主要な進歩を呈しており、グローバル移動体通信システム（ＧＳＭ（登録商標））およびユニバーサル・モバイル・テレコミュニケーション・システム（ＵＭＴＳ）の自然発展形として、セルラ第３世代（３Ｇ）サービスにおいて先行する次のステップである。ＬＴＥは、最大で毎秒７５メガビット（Ｍｂｐｓ）のアップリンク速度と、最大で３００Ｍｂｐｓのダウンリンク速度とを提供し、セルラ・ネットワークに対して多くの技術的な利点をもたらす。ＬＴＥは、高速なデータおよびメディア伝送のみならず、高いキャパシティの音声サポートに対するキャリア・ニーズを満足するように設計されている。帯域幅は、１．２５ＭＨｚから２０ＭＨｚまでスケール可能でありうる。これは、異なる帯域幅割当を有する異なるネットワーク・オペレータの要件に適合し、これによって、オペレータは、スペクトルに基づいて異なるサービスを提供することが可能となる。ＬＴＥはまた、３Ｇネットワークにおけるスペクトル効率を高め、もって、キャリアが、与えられた帯域幅で、より多くのデータ・サービスおよび音声サービスを提供することを可能にすることが期待されている。

ＬＴＥ規格の物理レイヤ（ＰＨＹ）は、エンハンスト基地局（ｅノードＢ）とモバイル・ユーザ機器（ＵＥ）との間でデータおよび制御情報の両方を伝送する非常に効率的な手段である。ＬＴＥ ＰＨＹは、セルラ・アプリケーションに新しい、先進技術を使用する。これらは、直交周波数分割多重（ＯＦＤＭ）および複数入力複数出力（ＭＩＭＯ）データ送信を含んでいる。さらに、ＬＴＥ ＰＨＹは、ダウンリンクにおいてＯＦＤＭＡを用い、アップリンクにおいてシングル・キャリア−周波数分割多元接続（ＳＣ−ＦＤＭＡ）を用いる。ＯＦＤＭＡによって、データは、指定された数のシンボル期間にわたって、サブキャリア毎ベースで、複数のユーザとの間で送られるようになる。

本開示の態様では、無線通信のための方法が提供される。この方法は一般に、インターネット・プロトコル（ＩＰ）セッション中、第１のラジオ・アクセス技術（ＲＡＴ）ネットワークから第２のＲＡＴネットワークへの移動が試みられると、第１のタイマを起動させることと、第２のＲＡＴネットワークにおいてチャネルが正しく獲得された場合、第２のタイマを起動させることと、第２のタイマが終了する前に、第２のＲＡＴネットワークにおいてセッションが正しくネゴシエートされ、第１のＲＡＴネットワークと第２のＲＡＴネットワークが、ＩＰサービスのために、共通のコア・ネットワークを共有しているのであれば、ＩＰセッションのコンテキストを、第２のＲＡＴネットワークへ転送することと、を含む。

本開示の態様では、無線通信のための装置が提供される。この装置は一般に、インターネット・プロトコル（ＩＰ）セッション中、第１のラジオ・アクセス技術（ＲＡＴ）ネットワークから第２のＲＡＴネットワークへの移動が試みられると、第１のタイマを起動させる手段と、第２のＲＡＴネットワークにおいてチャネルが正しく獲得された場合、第２のタイマを起動させる手段と、第２のタイマが終了する前に、第２のＲＡＴネットワークにおいてセッションが正しくネゴシエートされ、第１のＲＡＴネットワークと第２のＲＡＴネットワークが、ＩＰサービスのために共通のコア・ネットワークを共有しているのであれば、ＩＰセッションのコンテキストを、第２のＲＡＴネットワークへ転送する手段と、を含む。

本開示の態様では、無線通信のための装置が提供される。この装置は、一般に、少なくとも１つのプロセッサと、少なくとも１つのプロセッサに接続されたメモリとを含む。少なくとも１つのプロセッサは一般に、インターネット・プロトコル（ＩＰ）セッション中、第１のラジオ・アクセス技術（ＲＡＴ）ネットワークから第２のＲＡＴネットワークへの移動が試みられると、第１のタイマを起動させ、第２のＲＡＴネットワークにおいてチャネルが正しく獲得された場合、第２のタイマを起動させ、第２のタイマが終了する前に、第２のＲＡＴネットワークにおいてセッションが正しくネゴシエートされ、第１のＲＡＴネットワークと第２のＲＡＴネットワークが、ＩＰサービスのために、共通のコア・ネットワークを共有しているのであれば、ＩＰセッションのコンテキストを、第２のＲＡＴネットワークへ転送する、ように構成される。

本開示の態様では、無線通信のためのコンピュータ・プログラム製品が提供される。このコンピュータ・プログラム製品は、一般に、格納されたプログラム・コードを有する非一時的なコンピュータ読取可能な媒体を含む。このコードは一般に、インターネット・プロトコル（ＩＰ）セッション中、第１のラジオ・アクセス技術（ＲＡＴ）ネットワークから第２のＲＡＴネットワークへの移動が試みられると、第１のタイマを起動させることと、第２のＲＡＴネットワークにおいてチャネルが正しく獲得された場合、第２のタイマを起動させることと、第２のタイマが終了する前に、第２のＲＡＴネットワークにおいてセッションが正しくネゴシエートされ、第１のＲＡＴネットワークと第２のＲＡＴネットワークが、ＩＰサービスのために、共通のコア・ネットワークを共有しているのであれば、ＩＰセッションのコンテキストを、第２のＲＡＴネットワークへ転送することと、のために、１または複数のプロセッサによって実行可能である。

本開示の前述した特徴が、より詳細に理解される方式で、簡潔に要約された上記具体的な記載が、態様に対する参照によってなされている。そして、それらの幾つかは、添付図面で例示されている。しかしながら、この記載は、その他の等しく有効な態様に対しても当てはまるので、添付図面は、本開示のある典型的な態様のみを示していることや、本開示の範囲を限定するものとしては考慮されないことが注目されるべきである。
図１は、本開示のある態様にしたがう多元接続無線通信システムの例を例示する。 図２は、本開示の態様にしたがうアクセス・ポイントおよびユーザ端末のブロック図を例示する。 図３は、本開示のある態様にしたがう無線デバイスの例のブロック図を例示する。 図４は、本開示のある態様にしたがうネットワーク・アーキテクチャの例を例示する。 図５は、本開示のある態様にしたがうデバイス移動シナリオの例を例示する。 図６は、本開示のある態様にしたがうソフトウェア・アーキテクチャの例を例示する。 図７は、本開示のある態様にしたがうＩＰモビリティ管理のアプローチの例を例示する。 図８は、本開示のある態様にしたがうＩＰモビリティ管理のアプローチの例を例示する。 図９は、本開示のある態様にしたがうＩＰモビリティ管理のアプローチの例を例示する。 図１０は、本開示のある態様にしたがうＩＰモビリティ管理のアプローチの例を例示する。 図１１は、本開示のある態様にしたがう、ヒステリシス・タイマを用いたＩＰモビリティ管理のアプローチの例を例示する。 図１２は、本開示のある態様にしたがうＩＰモビリティ管理のアプローチの例を例示する。 図１３は、本開示のある態様にしたがってＩＰ継続を維持するための動作の例を例示する。

より詳細に後述するように、本開示の態様は、第１のＲＡＴネットワークと第２のＲＡＴネットワークがＩＰサービスのために共通のコア・ネットワークを共有する場合、デバイスが、第１のラジオ・アクセス技術（ＲＡＴ）から第２のＲＡＴへ移動する際にインターネット・プロトコル（ＩＰ）継続を維持するための技術を提供する。したがって、デバイスのＩＰモビリティ管理モジュールは、コア・ネットワークが可能なシナリオにおいてＩＰ継続を維持することを支援しうる。さらに、本明細書に記載された方法は、デバイスがある種のＩＰ接続を持たない時間を最小化し、不必要なトラフィック・チャネル設定を回避しうる。

本開示のさまざまな態様は、添付図面を参照して以下により十分に記載される。しかしながら、本開示は、異なる多くの形態で具体化され、本開示を通じて示された如何なる具体的な構成または機能にも限定されるとは解釈されるべきではない。むしろ、これらの態様は、本開示が十分で完全であり、本開示の範囲を当業者に十分に伝達できるように提供される。本明細書における教示に基づいて、当業者は、本開示の範囲は、独立して実施されようが、あるいは、本開示の任意の他の態様と組み合わされようが、本明細書で示された開示の態様をカバーすることが意図されていることを認識すべきである。例えば、本明細書に記載された任意の数の態様を用いて装置が実現され、方法が実施されうる。さらに、本開示の範囲は、別の構成、機能、または、本明細書に記載された開示のさまざまな態様またはそれ以外の態様が追加された構成および機能を用いて実現される装置または方法をカバーすることが意図されている。本明細書で示された開示のあらゆる態様は、特許請求の範囲の１または複数の要素によって具体化されうる。

「典型的である」という単語は「例、事例、あるいは実例として役立つ」ことを意味するために本明細書で使用される。本明細書において「典型的」と記載されるいかなる態様も、他の態様よりも好適であるとか、有利であると必ずしも解釈される必要はない。

本明細書では、特定の態様が記載されているが、これら態様の多くの変形および置換が、本開示の範囲内にある。好適な態様のいくつかの利点および長所が述べられているが、本開示の範囲は、特定の利点、使用、および目的に限定されることは意図されていない。むしろ、本開示の態様は、このうちのいくつかが図面における例示によって、および、以下の好適な態様の記載によって例示されている異なる無線技術、システム構成、ネットワーク、および伝送プロトコルに広く適用可能であることが意図されている。詳細な記載および図面は、限定ではない開示の単なる例示であり、本開示の範囲は、特許請求の範囲およびその均等物によって定義される。

（典型的な無線通信システム）
本明細書に記載された技術は、例えば符号分割多元接続（ＣＤＭＡ）ネットワーク、時分割多元接続（ＴＤＭＡ）ネットワーク、周波数分割多元接続（ＦＤＭＡ）ネットワーク、直交周波数分割多元接続（ＯＦＤＭＡ）ネットワーク、シングル・キャリアＦＤＭＡ（ＳＣ−ＦＤＭＡ）ネットワーク等のような様々な無線通信ネットワークのために使用される。「ネットワーク」および「システム」という用語は、しばしば置換可能に使用される。ＣＤＭＡネットワークは、例えば、ユニバーサル地上ラジオ・アクセス（ＵＴＲＡ）、ＣＤＭＡ２０００等のようなラジオ技術を実現しうる。ＵＴＲＡは、広帯域ＣＤＭＡ（Ｗ−ＣＤＭＡ）および低チップ・レート（ＬＣＲ）を含む。ＣＤＭＡ２０００は、ＩＳ−２０００規格、ＩＳ−９５規格、およびＩＳ−８５６規格をカバーする。ＴＤＭＡネットワークは、例えばグローバル移動体通信システム（ＧＳＭ（登録商標））のようなラジオ技術を実現しうる。ＯＦＤＭＡネットワークは、例えば、イボルブドＵＴＲＡ（Ｅ−ＵＴＲＡ）、ＩＥＥＥ ８０２．１１、ＩＥＥＥ ８０２．１６、ＩＥＥＥ ８０２．２０、フラッシュ−ＯＦＤＭ（登録商標）等のようなラジオ技術を実現しうる。ＵＴＲＡ、Ｅ−ＵＴＲＡ、およびＧＳＭは、ユニバーサル・モバイル・テレコミュニケーション・システム（ＵＭＴＳ）の一部である。ロング・ターム・イボリューション（ＬＴＥ）は、Ｅ−ＵＴＲＡを使用するＵＭＴＳの最新のリリースである。ＵＴＲＡ、Ｅ−ＵＴＲＡ、ＧＳＭ、ＵＭＴＳ、およびＬＴＥは、「第３世代パートナシップ計画」（３ＧＰＰ）と命名された団体からの文書に記載されている。ＣＤＭＡ２０００は、「第３世代パートナシップ計画２」（３ＧＰＰ２）と命名された団体からの文書に記載されている。ＣＤＭＡ２０００は、「第３世代パートナシップ計画２」（３ＧＰＰ２）と命名された団体からの文書に記載されている。これらさまざまなラジオ技術および規格は、当該技術分野において知られている。明確化のために、これら技術のある態様は、以下において、ＬＴＥに関して記載されており、ＬＴＥ用語が以下の説明の多くで使用される。

アクセス・ポイント（“ＡＰ”）は、ノードＢ、ラジオ・ネットワーク・コントローラ（“ＲＮＣ”）、ｅノードＢ（“ｅＮＢ”）、基地局コントローラ（“ＢＳＣ”）、基地トランシーバ局（“ＢＴＳ”）、基地局（“ＢＳ”）、トランシーバ機能（“ＴＦ”）、ラジオ・ルータ、ラジオ・トランシーバ、基本サービス・セット（“ＢＳＳ”）、拡張サービス・セット（“ＥＳＳ”）、ラジオ基地局（“ＲＢＳ”）、または、その他いくつかの用語として知られているか、備えているか、または実現されうる。

例えば、アクセス端末（“ＡＴ”）は、アクセス端末、加入者局、加入者ユニット、移動局、遠隔局、遠隔端末、ユーザ端末、ユーザ・エージェント、ユーザ・デバイス、ユーザ機器（“ＵＥ”）、ユーザ局、またはその他いくつかの用語として知られているか、または、実現されうるか、または、備えうる。いくつかの実施において、アクセス端末は、セルラ電話、コードレス電話、セッション開始プロトコル（“ＳＩＰ”）電話、無線ローカル・ループ（“ＷＬＬ”）局、携帯情報端末（“ＰＤＡ”）、無線接続機能を有するハンドヘルド・デバイス、局（“ＳＴＡ”）、あるいは無線モデムに接続されたその他いくつかの適切な処理デバイスを備えうる。したがって、本明細書で教示された１または複数の態様は、電話（例えば、セルラ電話またはスマート・フォン）、コンピュータ（例えば、ラップトップ）、ポータブル通信デバイス、ポータブル・コンピューティング・デバイス（例えば、情報携帯端末）、エンタテイメント・デバイス（例えば、音楽またはビデオ・デバイス、または衛星ラジオ）、全地球測位システム・デバイス、あるいは無線媒体または有線媒体によって通信するように構成されたその他任意の適切なデバイスに組み入れられうる。いくつかの態様では、ノードは無線ノードである。このような無線ノードは、例えば、有線または無線による通信リンクによる（例えば、インターネットまたはセルラ・ネットワークのような広域ネットワークのような）ネットワークへの、または、ネットワークのための接続を提供しうる。

図１に示すように、本開示の１つの態様にしたがった多元接続無線通信システムが例示される。アクセス・ポイント１００（ＡＰ）は、１つのグループはアンテナ１０４，１０６を含み、別のグループはアンテナ１０８，１１０を含み、さらに別のグループはアンテナ１１２，１１４を含む複数のアンテナ・グループを含みうる。図１では、おのおののアンテナ・グループについて２本のアンテナしか示されていない。しかしながら、おのおののアンテナ・グループについて、２本より多いまたは少ないアンテナが利用されうる。アクセス端末１１６（ＡＴ）はアンテナ１１２，１１４と通信している。ここで、アンテナ１１２，１１４は、順方向リンク１２０でアクセス端末１１６へ情報を送信し、逆方向リンク１１８でアクセス端末１１６から情報を受信する。アクセス端末１２２（ＡＴ）はアンテナ１０６，１０８と通信している。ここで、アンテナ１０６，１０８は、順方向リンク１２６でアクセス端末１２２へ情報を送信し、逆方向リンク１２４でアクセス端末１２２から情報を受信する。ＦＤＤシステムでは、通信リンク１１８，１２０，１２４，１２６は、通信のために、異なる周波数を使用しうる。例えば、順方向リンク１２０は、逆方向リンク１１８によって使用されるものとは異なる周波数を使用しうる。

通信するように設計された領域および／またはアンテナのおのおののグループは、しばしば、アクセス・ポイントのセクタと称される。本開示の１つの態様では、おのおののアンテナ・グループは、アクセス・ポイント１００によってカバーされる領域のセクタ内のアクセス端末へ通信するように設計される。

順方向リンク１２０，１２６による通信では、アクセス・ポイント１００の送信アンテナは、別のアクセス端末１１６，１２４のための順方向リンクの信号対雑音比を改善するために、ビームフォーミングを利用しうる。さらに、有効範囲領域にわたってランダムに散在するアクセス端末へ送信するためにビームフォーミングを用いるアクセス・ポイントは、全てのアクセス端末へ単一のアンテナによって送信するアクセス・ポイントよりも、近隣のセル内のアクセス端末に対して少ない干渉しかもたらさない。

図２は、複数入力複数出力（ＭＩＭＯ）システム２００における（アクセス・ポイントとしても知られている）送信機システム２１０および（アクセス端末としても知られている）受信機システム２５０の態様のブロック図である。送信機システム２１０では、多くのデータ・ストリームのトラフィック・データが、データ・ソース２１２から送信（ＴＸ）データ・プロセッサ２１４に提供される。

本開示の１つの態様では、データ・ストリームはおのおのの、それぞれの送信アンテナを介して送信されうる。ＴＸデータ・プロセッサ２１４は、おのおののデータ・ストリームのトラフィック・データをフォーマットし、このデータ・ストリームのために選択された特定の符号化スキームに基づいて符号化し、インタリーブして、符号化されたデータを提供する。

おのおののデータ・ストリームの符号化されたデータは、ＯＦＤＭ技術を用いてパイロット・データと多重化されうる。パイロット・データは一般に、既知の手法で処理される既知のデータ・パターンであり、チャネル応答を推定するために受信機システムにおいて使用されうる。おのおののデータ・ストリームについて多重化されたパイロットおよび符号化されたデータは、データ・ストリームのために選択された特定の変調スキーム（例えば、ＢＰＳＫ、ＱＰＳＫ、Ｍ−ＰＳＫ、またはＭ−ＱＡＭ等）に基づいて変調（例えば、シンボル・マップ）され、変調シンボルが提供される。おのおののデータ・ストリームのデータ・レート、符号化、および変調は、プロセッサ２３０によって実行される命令群によって決定されうる。

すべてのデータ・ストリームの変調シンボルは、（例えば、ＯＦＤＭのための）変調シンボルを処理するＴＸ ＭＩＭＯプロセッサ２２０に提供される。ＴＸ ＭＩＭＯプロセッサ２２０はその後、Ｎ_Ｔ個の変調シンボル・ストリームを、Ｎ_Ｔ個の送信機（ＴＭＴＲ）２２２ａ乃至２２２ｔへ提供する。本開示のある態様では、ＴＸ ＭＩＭＯプロセッサ２２０は、データ・ストリームのシンボル、および、そのシンボルが送信されるアンテナへ、ビームフォーミング重みを適用する。

おのおのの送信機２２２は、１または複数のアナログ信号を提供するために、それぞれのシンボル・ストリームを受信して処理し、さらには、ＭＩＭＯチャネルを介した送信に適切な変調信号を提供するために、このアナログ信号を調整（例えば、増幅、フィルタ、およびアップコンバート）する。送信機２２２ａ乃至２２２ｔからのＮ_Ｔ個の変調信号は、その後、Ｎ_Ｔ個のアンテナ２２４ａ乃至２２４ｔからそれぞれ送信される。

受信機システム２５０では、送信された変調信号がＮ_Ｒ個のアンテナ２５２ａ乃至２５２ｒによって受信され、おのおののアンテナ２５２からの受信信号が、それぞれの受信機（ＲＣＶＲ）２５４ａ乃至２５４ｒへ提供されうる。受信機２５４はおのおの、それぞれの受信信号を調整（例えば、フィルタ、増幅、および、ダウンコンバート）し、調整された信号をデジタル化して、サンプルを得る。さらに、これらサンプルを処理して、対応する「受信」シンボル・ストリームを提供する。

ＲＸデータ・プロセッサ２６０は、Ｎ_Ｒ個の受信機２５４からＮ_Ｒ個のシンボル・ストリームを受信し、受信されたこれらシンボル・ストリームを、特定の受信機処理技術に基づいて処理して、Ｎ_Ｔ個の「検出された」シンボル・ストリームを提供する。ＲＸデータ・プロセッサ２６０は、その後、検出されたおのおののシンボル・ストリームを復調し、デインタリーブし、復号して、このデータ・ストリームのためのトラフィック・データを復元する。ＲＸデータ・プロセッサ２６０による処理は、送信機システム２１０におけるＴＸ ＭＩＭＯプロセッサ２２０およびＴＸデータ・プロセッサ２１４によって実行されるものと相補的である。

プロセッサ２７０は、上述したように、利用可能などの技術を利用するのかを定期的に決定する。さらに、プロセッサ２７０は、行列インデクス部およびランク値部を備えた逆方向リンク・メッセージを規定する。これら逆方向リンク・メッセージは、通信リンクおよび／または受信データ・ストリームに関するさまざまなタイプの情報を備えうる。逆方向リンク・メッセージはその後、多くのデータ・ストリームのトラフィック・データをデータ・ソース２３６から受け取るＴＸデータ・プロセッサ２３８によって処理され、変調器２８０によって変調され、送信機２５４ａ乃至２５４ｒによって調整され、基地局２１０へ送り戻される。

送信機システム２１０では、受信機システム２５０からの変調された信号が、アンテナ２２４によって受信され、受信機２２２によって調整され、復調器２４０によって復調され、ＲＸデータ・プロセッサ２４２によって処理されて、受信機システム２５０によって送信された逆方向リンク・メッセージが抽出される。さらに、プロセッサ２３０は、ビームフォーミング重みを決定するためにどのプリコーディング行列を使用するかを決定するために、この抽出されたメッセージを処理する。

図３は、図１の無線通信システム内で適用されうる無線デバイス３０２内で利用されうるさまざまな構成要素を例示する。無線デバイス３０２は、本明細書で説明されるさまざまな方法を実施するために構成され得るデバイスの例である。無線デバイス３０２は、図１からのアクセス・ポイント１００でありうるか、または、アクセス端末１１６，１２２のうちの何れかでありうる。

無線デバイス３０２は、無線デバイス３０２の動作を制御するプロセッサ３０４を含みうる。このプロセッサ３０４は、中央制御装置（ＣＰＵ）とも称されうる。読取専用メモリ（ＲＯＭ）とランダム・アクセス・メモリ（ＲＡＭ）との両方を含みうるメモリ３０６が、プロセッサ３０４に命令およびデータを提供する。メモリ３０６の一部は、不揮発性ランダム・アクセス・メモリ（ＮＶＲＡＭ）をも含みうる。プロセッサ３０４は、通常、メモリ３０６に格納されたプログラム命令に基づいて、論理演算および算術演算を実行する。本明細書で説明される方法を実施するために、メモリ３０６内の命令が実行可能とされうる。

無線デバイス３０２は、無線デバイス３０２と遠隔位置との間でのデータの送信および受信を可能にする送信機３１０および受信機３１２を含みうるハウジング３０８をも含みうる。送信機３１０および受信機３１２は、トランシーバ３１４に結合されうる。単一あるいは複数の送信アンテナ３１６が、ハウジング３０８に取り付けられ、トランシーバ３１４に電気的に接続されうる。無線デバイス３０２はまた、（図示しない）複数の送信機、複数の受信機、および複数のトランシーバを含みうる。

無線デバイス３０２は、トランシーバ３１４によって受信された信号を検出し、そのレベルを定量化する目的で使用される信号検出器３１８をも含むことができる。信号検出器３１８は、合計エネルギ、シンボル毎のサブキャリア毎のエネルギ、電力スペクトル密度、およびその他の信号のような信号を検出しうる。無線デバイス３０２は、信号を処理する際に使用されるデジタル信号プロセッサ（ＤＳＰ）３２０をも含みうる。

無線デバイス３０２のさまざまな構成要素が、データ・バスに加えて電力バス、制御信号バス、およびステータス信号バスを含むことができるバス・システム３２２によってともに結合されうる。

（移動中におけるＩＰ継続の喪失を阻止すること）
デバイスは、ＩＰサービスのために共通のコア・ネットワークを共有するネットワーク間を移動している場合、インターネット・プロトコル（ＩＰ）継続を維持しうる。ロング・ターム・イボリューション（ＬＴＥ）ラジオ・アクセス技術（ＲＡＴ）、およびイボルブド高レート・パケット・データ（ｅＨＲＰＤ）ラジオ・アクセス技術（ＲＡＴ）は、同じ３ＧＰＰイボルブド・パケット・コア（ＥＰＣ）ネットワークに接続される。したがって、ＩＰ継続は、デバイスが、ＬＴＥ有効通信範囲およびｅＨＲＰＤ有効通信範囲のエリア間を移動する場合に、データ・コールのために維持されうる。高レート・パケット・データ（ＨＲＰＤ）および１ｘ ＲＡＴは、３ＧＰＰ２コア・ネットワークに接続される。したがって、ＩＰ継続は、デバイスが、ＬＴＥ有効通信範囲およびＨＲＰＤ有効通信範囲または１ｘ有効通信範囲のエリア間で移動する場合に、維持されないことがありうる。

しかしながら、現在の規格によれば、デバイスは、データ・オプティマイズド（ＤＯ）またはＬＴＥチャネルを発見する前に、例えば１ｘネットワークのような別のＲＡＴネットワークにおいてチャネルを獲得した場合、ＬＴＥ有効通信範囲エリアとｅＨＲＰＤ有効通信範囲エリアとの間を移動する場合に、ＩＰ継続を喪失しうる。本開示の態様は、共通のコア・ネットワークを共有するＲＡＴ間をデバイスが移動する場合、ＩＰ継続の喪失を阻止する技術を提供する。

以下にさらに詳述されるが、デバイスにおけるモジュールは、ＬＴＥ有効通信範囲またはｅＨＲＰＤ有効通信範囲から１ｘ有効通信範囲に移動する場合、第１のタイマを起動しうる。ＬＴＥまたはｅＨＲＰＤにおけるＩＰインタフェースは、直ちにティア・ダウンされないかもしれない。

デバイスがＬＴＥ有効通信範囲からｅＨＲＰＤ有効通信範囲に移動し、ＤＯを獲得する前に１ｘを獲得した場合、デバイスは、システム判定モジュールが、ＥＶＤＯがサービス外（ＯＯＳ）であると宣言する前に、イボリューション・データ・オプティマイズド（ＥＶＤＯ）チャネルの１つのフル・スキャンを完了するのを待ちうる。ＥＶＤＯネットワークにおいてチャネルを正しく獲得する前に第１のタイマが終了した場合、ＩＰ継続は維持されない場合がありうる。しかしながら、第１のタイマが終了する前にＥＶＤＯチャネルが獲得された場合、第１のタイマが停止され、第２のタイマが起動されうる。

デバイスは、獲得されたＥＶＤＯチャネルが、ＬＴＥネットワークと共通の、ＩＰサービスのためのコア・ネットワークを共有するか否かを判定するために、ＥＶＤＯセッション・ネゴシエーションが、第２のタイマによって規定された時間内に終了するのを待ちうる。獲得されたチャネルが、例えばｅＨＲＰＤのような共通のコア・ネットワークを共有する場合、ＩＰ継続が維持され、ＩＰコンテキストが、ＬＴＥからｅＨＲＰＤへ転送されうる。獲得されたチャネルが、例えばＨＲＰＤのような共通のコア・ネットワークを共有しないか、あるいは、ＥＶＤＯネットワークにおける正しいネゴシエーションの前に第２のタイマが終了した場合、ＩＰ継続は維持されない場合がありうる。

デバイスがｅＨＲＰＤ有効通信範囲からＬＴＥ有効通信範囲へ移動し、ＬＴＥを獲得する前に１ｘを獲得した場合、デバイスは、システム判定モジュールが、ＬＴＥチャネルのスキャンを実行するのを待ちうる。ＬＴＥチャネルが発見されない場合、あるいは、ＬＴＥチャネルを発見する前に第１のタイマが終了した場合には、ＩＰ継続が維持されないことがありうる。しかしながら、第１のタイマが終了する前にＬＴＥチャネルが獲得された場合、第１のタイマが停止され、第２のタイマが起動されうる。第２のタイマが終了する前にＬＴＥ接続が完了した場合、
ＩＰ継続が維持されうる。

本開示の態様は、デバイスがＬＴＥ有効通信範囲とｅＨＲＰＤ有効通信範囲との間を移動し、ＥＶＤＯネットワークまたはＬＴＥネットワークを獲得する前に、例えば１ｘのような第３のＲＡＴネットワークにおいてチャネルを獲得した場合に、ＩＰ継続を維持する方法を提供する。より詳細に後述されるように、態様は、ＩＰ継続を維持することが可能ではないと宣言するのにさほど長い時間待たないことと、ＩＰ継続が喪失したことを時期尚早に宣言することと、の釣り合いを図る。

図４は、本開示の態様にしたがう、ネットワーク・アーキテクチャ４００の例を例示する。マルチ・モードＵＥ４０２のようなデバイスは、１または複数のＲＡＴと通信しうる。ＵＥ４０２は、例えば、ＬＴＥ ｅＮＢ４０４、ｅＨＲＰＤラジオ・アクセス・ネットワーク（ＲＡＮ）４０６、１ｘ ＢＳ ４０８、およびＥＶＤＯ ＲＡＮ ４１０と通信しうる。

ＬＴＥ ｅＮＢ４０４およびｅＨＲＰＤ ＲＡＮ４０６は、ＩＰサービスのために、ＥＰＣ（３ＧＰＰ）コア・ネットワークを使用する。サービス提供ゲートウェイ（ＳＧＷ）４１２、ＨＲＰＤサービス提供ゲートウェイ（ＨＳＧＷ）４１４、パケット・データ・ネットワーク・ゲートウェイ（ＰＤＮ−ＧＷ）４１６，４１８，４２０は、ＥＰＣの一部と考えられうる。ＬＴＥのためのＳＧＷ４１２と、ｅＨＲＰＤのためのＨＳＧＷ４１４とは、ＰＤＮ−ＧＷからＩＰアドレスを受信した後、ＩＰアドレスをＵＥ４０２へ割り当てうる。

前述したように、ｅＨＲＰＤは、３ＧＰＰコア・ネットワークを使用し、ＨＲＰＤは、３ＧＰＰ２コア・ネットワークを使用する。これらのコア・ネットワークが異なっていても、ｅＨＲＰＤおよびＨＲＰＤは、３ＧＰＰ２ ＥＶＤＯ ＲＡＴと考えられうる。

あるＲＡＴから別のＲＡＴへデバイスが移動した場合、２つのＲＡＴが同じコア・ネットワークに接続されているのであれば、ＩＰ継続を維持することが可能でありうる。例えば、３ＧＰＰ２コア・ネットワークには、両方のＲＡＴが接続されているので、ＥＶＤＯ ＲＡＮ４１０と１ｘ ＢＳ４０８との間を移動するＵＥ４０２は、継続を維持しうる。

デバイスは、新たなＲＡＴにおいて同じＩＰアドレスを有しうるので、同じコア・ネットワークに接続されたＲＡＴ間の移動は、アプリケーションに透過的でありうる。ある場合には、移動中にデータを転送する際における僅かな遅れが、注目に値しうる。デバイスが、異なるコア・ネットワークに接続されたＲＡＴ間を移動する場合、ＩＰ継続を維持することは可能ではないかもしれない。この場合、新たなＲＡＴ内のデバイスに、異なるＩＰアドレスが割り当てられうる。

ＬＴＥとｅＨＲＰＤが、ＩＰサービスのために同じコア・ネットワークを使用していても、デバイスは、これら２つのＲＡＴ間を移動している場合、ＩＰ継続を喪失しうる。これは、例えば１ｘのように、（デバイス移動方向に依存して）ＥＶＤＯチャネルまたはＬＴＥチャネルが獲得される前にＬＴＥおよびｅＨＲＰＤと同じコア・ネットワークを共有しない、ＲＡＴにおけるチャネルをデバイスが獲得する場合に生じうる。

図５は、本開示のある態様にしたがうネットワーク構成およびデバイス移動シナリオ５００の例を例示する。シナリオ１およびシナリオ４は、ＵＥがＩＰ継続を維持しうる場合におけるＵＥの移動の例を例示する。前述したように、ＵＥは、ＩＰサービスのための共通のコア・ネットワークを共有するＲＡＴ間を移動する場合、ＩＰ継続を維持しうる。シナリオ１では、ＵＥが、ＬＴＥネットワークから１ｘ＋ＥＶＤＯ（ｅＨＲＰＤ）ネットワークへ移動し、シナリオ４では、ＵＥが、ＬＴＥネットワークからＥＶＤＯ（ｅＨＲＰＤ）ネットワークへ移動する。さらに詳しく後述されるように、本開示の態様は、デバイスがＬＴＥとｅＨＲＰＤとの間を移動する場合にＩＰ継続を維持するための方法を提供する。

シナリオ２，３，５は、ＩＰ継続が維持されないことがありうる場合におけるＵＥ移動の例を例示する。これらのシナリオでは、ＵＥは、ＬＴＥから、ＬＴＥネットワークと共通のコア・ネットワークを共有しないＲＡＴへ移動している。シナリオ２および５では、ＵＥは、ＬＴＥネットワークからＨＲＰＤネットワークへと移動している。シナリオ３では、ＵＥが、ＬＴＥネットワークから１ｘネットワークへと移動している。したがって、ＩＰ継続は、これらのシナリオ間では維持されないことがありうる。

図６は、本開示のある態様にしたがう、ソフトウェア・アーキテクチャ６００の例を例示する。シナリオ１では、ある状況において、ＩＰ継続が可能である場合であっても、ＩＰ継続が維持されない場合がありうる。

例えば、ＬＴＥからｅＨＲＰＤへ移動しているハイブリッド・モード１ｘ／ＥＶＤＯデバイスのようなデバイスは、同一場所にあるＥＶＤＯシステムを発見する前に、１ｘネットワークを獲得しうる。１ｘネットワークが獲得された時点において、ＩＰモビリティ管理６０２を担当するモジュールは、ＥＶＤＯネットワークがその後発見されうるか否かを認識しない場合がありうる。例えば、ＩＰモビリティ管理モジュール６０２は、シナリオ１とシナリオ３とを区別しない場合がありうる。したがって、ＩＰモビリティ管理モジュール６０２は、１ｘネットワークを獲得すると、ＬＴＥと１ｘとの間を移動している場合にＩＰ継続を維持することが可能ではないという前提の下、ＩＰインタフェースをローカルにティア・ダウンしうる。

デバイスが反対方向に移動する場合、同様の状況が存在しうる。ｅＨＲＰＤからＬＴＥへと移動しているデバイスのＩＰモビリティ管理モジュール６０２は、１ｘを喪失しＬＴＥネットワークを発見する前に、ＥＶＤＯが喪失したことを認識しうる。これは、ＤＯおよび１ｘのためのＯＯＳアルゴリズム、および／または、ＤＯおよび１ｘのためのスロット・サイクル・インデクスに依存しうる。ＤＯが喪失したものの１ｘが未だに存在する時点において、ＩＰモビリティ管理モジュール６０２は、ＬＴＥが直ちに発見されうるか否かを認識しない場合がありうる。したがって、ＩＰモビリティ管理モジュール６０２は、ｅＨＲＰＤから１ｘへのＩＰ継続を維持することが可能ではない場合がありうるという前提に基づいて、ＩＰインタフェースをティア・ダウンしうる。

シナリオ４および５では、ＥＶＤＯが獲得された時点において、ＩＰモビリティ管理モジュール６０２は、ＩＰ継続を維持することが可能であるか否かを認識しない場合がありうる。例えばＥＶＤＯレイヤ３においてＥＶＤＯセッションがネゴシエートされるまで、ＩＰモビリティ管理モジュール６０２は、このネットワークが、ＩＰ継続が維持されない場合がありうるＨＲＤＰであるか、あるいは、ＩＰ継続が維持されうる場合であるｅＨＲＰＤであるかを認識しない場合がありうる。したがって、本開示の態様は、コア・ネットワークが可能であるシナリオにおいてＩＰ継続を維持することと、ＩＰ継続無しでデバイスが残される時間を最小化することと、不必要なトラフィック・チャネル設定を回避することと、をデバイスが行うための方法を提供する。

図７は、本開示の態様にしたがうＩＰモビリティ管理７００のアプローチの例を例示する。７０８に例示するようにスペクトルの一端において、ＩＰモビリティ管理モジュール６０２は、デバイスが何れの方向であれＬＴＥとｅＨＲＰＤとの間を移動した場合に１ｘネットワークが獲得されたとの通知をシステム判定モジュール６０４から受信すると、ＩＰセッションのコンテキストをローカルにティア・ダウンしうる。

このアプローチによれば、ＩＰ継続は、シナリオ１，２，３において維持されないだろう。ＩＰモビリティ管理モジュールは、ＩＰコンテキストをローカルにティア・ダウンすることと、ＩＰ接続の喪失をアプリケーション６０６へ通知することとを行うために、ＬＴＥからｅＨＲＰＤへ移動している場合には、３ＧＰＰ−ＬＴＥインタフェースへ指示し、ｅＨＲＰＤからＬＴＥへ移動している場合には、３ＧＰＰ２−ｅＨＲＰＤインタフェースに指示しうる。

有利なことに、このアプローチによって、ＩＰモビリティ管理モジュールは、アプリケーションがＩＰ接続を要求している場合、新たな３ＧＰＰ−１ｘインタフェースを直ちに設定することが可能となる。例えば、シナリオ２および３では、７０４および７０６にそれぞれ例示されるように、ＩＰモビリティ管理モジュールは、１ｘを獲得した後、直ちに、新たなデータ接続を設定しうる。

しかしながら、このアプローチによれば、デバイスが、たとえ最終的にはＥＶＤＯネットワークを獲得することになるのであろうとも、ＩＰ継続が途絶されるだろう。シナリオ１では、７０２に例示されるように、デバイスが７１０においてＥＶＤＯを獲得し、７１２においてｅＨＲＰＤセッションをネゴシエートした場合であっても、ＩＰ継続が喪失され、デバイスのアプリケーションは、１ｘネットワークにおいて新たな接続を設定するだろう。

図８は、本開示の態様にしたがうＩＰモビリティ管理８００のためのアプローチの例を例示する。スペクトルの他端において、ＩＰモビリティ管理モジュール６０２は、ＩＰ継続が維持されないことが確実になるまで、ＩＰ継続の喪失を宣言するのを待ちうる。

デバイスがＬＴＥからｅＨＲＰＤへ移動した場合、ＩＰモビリティ管理モジュール６０２は、ＩＰ継続が維持されうるか否かを判定するためのＥＶＤＯセッション・ネゴシエーションが完了するまで待ちうる。獲得されたネットワークがｅＨＲＰＤである場合、ＩＰモビリティ管理モジュールは、３ＧＰＰ−ＬＴＥインタフェースに対してティア・ダウンするように命じ、新たな３ＧＰＰ２−ｅＨＲＰＤインタフェースを生成しうる。デバイスが、逆方向、すなわちｅＨＲＰＤからＬＴＥへ移動した場合、ＩＰモビリティ管理モジュール６０２は、ＬＴＥ接続が完了した後に、継続が維持されるか否かを認識しうる。

このアプローチによれば、８０８において、ＩＰモビリティ管理モジュール６０２は、１ｘネットワークが獲得されたことを示すインジケーションをシステム判定モジュール６０４から受信した場合、動作しない場合がありうる。有利なことに、デバイスがシナリオ１である場合、ＩＰ継続は、時期尚早の動作によって喪失されないことがありうる。８０２では、シナリオ１におけるデバイスが、１ｘが獲得されたことを示すインジケーションを受信し、８１０において、ＥＶＤＯを探索し、獲得しうる。８１２では、ＩＰモビリティ管理モジュールが、ｅＨＲＰＤセッションをネゴシエートし、ＩＰ継続を維持しうる。デバイスのアプリケーションは、ｅＨＲＰＤネットワークにおける以前のＩＰ接続を使用しうる。

しかしながら、このアプローチによれば、ｅＨＲＰＤネットワーク（または、ｅＨＲＰＤからＬＴＥに移動した場合ＬＴＥネットワーク）が獲得される前に、長い時間がかかりうる。この時間中、データがバッファされうるか、喪失されうる。シナリオ２は、８０４に例示されるように、ＬＴＥからＨＲＰＤへ移動するデバイスを示す。８０８では、デバイスは、１ｘネットワークを獲得しうる。１ｘを獲得した後、デバイスは、８１０において、ＥＶＤＯネットワークを探索し、獲得しうる。ＥＶＤＯセッション・ネゴシエーションが完了した後、デバイスは、獲得されたネットワークがＨＲＰＤである場合、ＩＰ継続の喪失を宣言しうる。８１４において、アプリケーションは、ＨＲＰＤネットワークにおける新たなデータ接続を設定しうる。

極端な場合、ＥＶＤＯセッション・ネゴシエーションが起こらず、デバイスは、データ接続無しとされうる。例えば、シナリオ３は、８０６に例示されるように、ＬＴＥネットワークから１ｘネットワークへ移動するデバイスを示す。８０８において、デバイスは、１ｘネットワークを獲得しうる。そして、８１６において、ＥＶＤＯネットワークを探索しうる。８１８において、デバイスは、ＤＯ ＯＯＳを宣言し、省電力モードに入りうる。８２０において、デバイスは、ＥＶＤＯネットワークを探索し続けうる。このシナリオでは、デバイスは、ＥＶＤＯネットワークを獲得することを無制限に待つ場合がありうる。これによって、アプリケーションは、データ接続がなくなる。

図９および図１０は、アプリケーション６０６がデータの送信を試みるまでＩＰモビリティ管理モジュール６０２が動作しない本開示の態様にしたがう、ＩＰモビリティ管理のためのアプローチ９００，１０００の例を例示する。図９は、アプリケーションがデータを後に送信することを試みるシナリオを例示し、図１０は、アプリケーションがデータを早期に送信することを試みるシナリオを例示する。

ＬＴＥからｅＨＲＰＤへ移動している間、デバイスのＬＴＥスタックは、デバイスが１ｘネットワークを獲得した場合に、データを送信しない場合がありうる。したがって、ＬＴＥスタックは、デバイスがもはやＬＴＥネットワークにないことをＩＰモビリティ管理モジュールへ通知しうる。ＩＰモビリティ管理モジュールはその後、移動シナリオに依存して、３ＧＰＰ−ＬＴＥインタフェースに対して、ローカルにティア・ダウンすることと、ｅＨＲＰＤ、ＨＲＰＤ、または１ｘインタフェースの何れかでありうる新たな３ＧＰＰ２インタフェースを設定するよう切り換えるように指示しうる。ＩＰモビリティ管理モジュールは、ｅＨＲＰＤからＬＴＥへ移動している場合、同様のアプローチを使用しうる。

例えば、デバイスが、ネットワーク間を断続的に矢継ぎ早に行き来する場合、このアプローチは、ＩＰコンテキストの不必要なティア・ダウンを回避しうる。アプリケーションがデータの送信を試みる場合にのみ、正しいインタフェースが設定されるだろう。したがって、可能な場合、ＩＰ継続が維持されうる。あるいは、ＩＰ接続が喪失されており再設定する必要があることが、アプリケーションに通知されうる。しかしながら、このアプローチは、遅れと、潜在的なデータ喪失とを引き起こしうる。

９０２では、ＬＴＥからｅＨＲＰＤへ移動するデバイスを示す、シナリオ１が例示されている。デバイスは、９０８において、１ｘネットワークを獲得し、９１０において、ＥＶＤＯネットワークを探索して獲得しうる。ＥＶＤＯセッション・ネゴシエーションの完了後、デバイスは、獲得されたＥＶＤＯネットワークがｅＨＲＰＤネットワークであると、９１２において判定しうる。したがって、デバイスは、ｅＨＲＰＤネットワークにおいてＩＰ継続を維持しうる。９１４では、デバイスのアプリケーションが、ｅＨＲＰＤでデータを送信しうる。このシナリオでは、ＩＰ継続が維持されうる。なぜなら、このアプリケーションは、デバイスがｅＨＲＰＤセッションを獲得した後、データを送信することを試みるからである。

９０４では、ＬＴＥからＨＲＰＤへ移動するデバイスを示すシナリオ２が例示される。デバイスは、９０８において、１ｘネットワークを獲得し、９１０において、ＥＶＤＯネットワークを探索し獲得しうる。ＥＶＤＯセッション・ネゴシエーションの完了後、デバイスは、９１６において、獲得されたＥＶＤＯネットワークがＨＲＰＤネットワークであると判定しうる。９１８では、アプリケーションが、データを送信することを試み、ＩＰ接続が喪失したことが通知されうる。ＬＴＥスタックがデータを送信しない場合がありうるので、ＩＰモビリティ管理モジュールは、その後、３ＧＰＰ−ＬＴＥインタフェースをティア・ダウンし、３ＧＰＰ２−ＨＲＰＤインタフェースを設定するように切り換わりうる。９２０では、アプリケーションは、ＨＲＰＤネットワークでデータを再送信することを試みうる。

９０６では、ＬＴＥから１ｘへ移動するデバイスを示すシナリオ３が例示される。９０８では、デバイスが、１ｘネットワークを獲得しうる。デバイスは、ＥＶＤＯネットワークを探索しうる。９２２では、デバイスは、ＤＯ ＯＯＳを宣言し、省電力モードに入りうる。アプリケーションは、９２４において、データを送信することを試み、ＩＰ接続が喪失したことを通知されうる。ＩＰモビリティ管理モジュールはその後、新たな３ＧＰＰ２−１ｘインタフェースを設定するように切り換わりうる。９２６において、アプリケーションは、１ｘネットワークでデータを再送信することを試みうる。

次に図１０に示すように、１００８において、デバイスが１ｘネットワークを獲得しうる。１０１０において、アプリケーションは、データを送信することを試みうる。２つのＲＡＴは、ＩＰサービスのために同じコア・ネットワークを共有しないので、データが喪失され、アプリケーションは、ＩＰ接続が喪失したことを通知されうる。アプリケーションがデータを送信することを試みた後、ＩＰモビリティ管理モジュールは、３ＧＰＰ−ＬＴＥインタフェースに対して、ティア・ダウンされるように指示し、移動シナリオに依存して、ｅＨＲＰＤ、ＨＲＰＤ、または１ｘでありうる新たな３ＧＰＰ２インタフェースを設定するように切り換わりうる。

１００２では、デバイスがＬＴＥからｅＨＲＰＤへ移動する場合、アプリケーションがデータを早期に送信することを試みることを示すシナリオ１が例示される。１００４では、デバイスがＬＴＥからＨＲＰＤへ移動する場合、アプリケーションがデータを早期に送信することを試みることを示すシナリオ２が例示される。１００６では、デバイスがＬＴＥから１ｘへ移動する場合、アプリケーションがデータを早期に送信することを試みることを示すシナリオ３が例示される。これらのシナリオの各々では、１０１０において、アプリケーションが、データの送信を試み、ＩＰ継続が喪失したとの通知を受信した後、ＩＰモビリティ管理モジュールが、３ＧＰＰ−ＬＴＥインタフェースに対して、ティア・ダウンするように指示しうる。１０１２では、アプリケーションは、獲得した１ｘネットワークにおいて確立された接続を用いて、データを再送信しうる。

ＩＰモビリティ管理のための別のアプローチによれば、ＩＰモビリティ管理モジュール６０２は、ネットワークが変更されたとの通知を、システム判定モジュール６０４から受信すると常に、トラフィック接続の設定を試みうる。

デバイスがＬＴＥからｅＨＲＰＤの方向に移動する場合、トラフィック・チャネルは、１ｘ、ＨＲＰＤ、またはｅＨＲＰＤで確立されうる。トラフィック・チャネルが確実に認識された後、デバイスは、トラフィック接続がｅＨＲＰＤであれば、ＩＰコンテキストを転送する動作を講じうる。あるいは、トラフィック接続が、１ｘまたはＨＲＰＤである場合、デバイスは、３ＧＰＰ−ＬＴＥインタフェースをローカルにティア・ダウンし、デバイスがＩＰ接続を喪失したことをアプリケーションに通知しうる。デバイスが１ｘを獲得し、ＥＶＤＯを探索している場合にこれが生じた場合、直近に獲得された、同一場所にあるＥＶＤＯチャネルにおいて開始が試みられうる。デバイスがｅＨＲＰＤからＬＴＥの方向に移動する場合に、同様のアプローチが使用されうる。

このアプローチによれば、デバイスは、シナリオ１−５のおのおのにおいて、適切な動作を講じうる。例えば、デバイスがシナリオ１にある場合、時期尚早の動作によってＩＰ継続が喪失されない場合がありうる。しかしながら、デバイスがシナリオ３にある場合、トラフィック・チャネルは、デバイスが１ｘネットワークにあることを特定するのみのために、１ｘネットワークを不必要に設定しうる。デバイスは、ＩＰ継続を維持しない場合がありうるので、１ｘネットワークへのトラフィック接続は、ティア・ダウンされる必要はないだろう。

図１１は、本開示の態様にしたがう、ＩＰモビリティ管理１１００へのアプローチの例を例示する。ＩＰモビリティ管理モジュール６０２は、１１０８において、１ｘネットワークが獲得されたとの通知をシステム判定モジュール６０４から受信すると、ヒステリシス・タイマを起動しうる。ＩＰモビリティ管理モジュールは、ヒステリシス・タイマが終了するまで動作しないことがありうる。

デバイスがＬＴＥからｅＨＲＰＤのＬＴＥの方向に移動している場合、ヒステリシス・タイマが終了し、ＥＶＤＯが獲得され、ｅＨＲＰＤネットワークであると判定されると、３ＧＰＰ２−ｅＨＲＰＤインタフェースが生成され、ＩＰコンテキストが３ＧＰＰ−ＬＴＥインタフェースから転送されうる。これが成功すると、３ＧＰＰ−ＬＴＥインタフェースが、ローカルにティア・ダウンされうる。デバイスが、ｅＨＲＰＤからＬＴＥへと、逆方向に移動する場合、同様のアプローチが使用されうる。

１１０２では、シナリオ１が例示されている。ここでは、デバイスがＥＶＤＯネットワークを獲得し、ヒステリシス・タイマが終了する前にｅＨＲＰＤセッションをネゴシエートする。１１１０では、ヒステリシス・タイマが終了し、デバイスは、ｅＨＲＰＤにおけるＩＰ継続を維持し、ＩＰコンテキストを転送しうる。

１１０４では、シナリオ２が例示されている。ここでは、デバイスが、ＥＶＤＯネットワークを獲得し、ヒステリシス・タイマが終了する前に、ＨＲＰＤセッションをネゴシエートする。１１１２では、ヒステリシス・タイマが終了し、デバイスは、ＩＰ継続が喪失したと宣言しうる。アプリケーションは、その後、ＨＲＰＤで新たなデータ接続を設定しうる。

１１０６では、シナリオ３が例示される。ここでは、デバイスが、ＬＴＥから１ｘへと移動する。１１１４では、ヒステリシス・タイマが終了し、デバイスはまだＥＶＤＯネットワークを獲得していない。したがって、デバイスは、ＩＰ継続が喪失したことを宣言しうる。アプリケーションは、その後、１ｘネットワークで新たなデータ接続を設定しうる。

このアプローチは、デバイスがシナリオ１にある場合、有利でありうる。なぜなら、時期尚早の動作によってＩＰ継続が喪失されないだろうからである。さらに、このアプローチは、デバイスがＬＴＥエリアと３ＧＰＰ２エリアとの間を迅速に移動するシナリオにおいて有利でありうる。なぜなら、ＩＰモビリティ管理モジュールは、ヒステリシス・タイマが終了するまで、動作しないであろうからである。ヒステリシス・タイマが終了するまで如何なる動作も講じられないだろうから、このアプローチは遅れをもたらしうる。例えば、ｅＨＲＰＤセッションがネゴシエートされている場合、デバイスは、ＩＰコンテキストを転送することを、タイマが終了するまで待ちうる。

したがって、本開示の態様は、ＩＰ継続の時期尚早の喪失、トラフィック・チャネルの不必要な生成、および、デバイス移動中におけるデータの喪失、を回避するための方法を提供する。態様によれば、ＩＰモビリティ管理モジュールは、１ｘネットワークが獲得されたことがシステム判定モジュールによって通知された場合に直ちに動作しない場合がありうる。

図１２は、本開示の態様にしたがう、ＩＰモビリティ管理１２００のためのアプローチの例を例示する。１２０８において１ｘが獲得されたとの通知がなされると、第１のヒステリシス・タイマが起動されうる。ＩＰモビリティ管理モジュールは、ＬＴＥチャネルからｅＨＲＰＤチャネルまたはＬＴＥチャネルに移動している場合、ｅＨＲＰＤからＬＴＥへ移動している場合、システム判定モジュールがＥＶＯＤチャネルのフル・スキャンを完了したとの別の通知を待ちうる。この時間中、デバイスは、データをバッファしうる。バッファがフルになると、デバイスは、アプリケーションがこれ以上データを送信しないように、フロー制御を使用しうる。

態様によれば、ＩＰモビリティ管理モジュールは、これら３つのイベントの早期において動作しうる。第１のタイマが終了した場合、システム判定モジュールから、（ＬＴＥからｅＨＲＰＤへの移動の場合）ＥＶＤＯが獲得されたとの通知を受信したか、または（ｅＨＲＰＤからＬＴＥへの移動の場合）ＬＴＥが獲得されたとの通知を受信した場合、あるいは、（ＬＴＥからｅＨＲＰＤへのデバイス移動の場合）連続したＥＶＤＯチャネル探索が実行され尽くしたか、または（ｅＨＲＰＤからＬＴＥへのデバイス移動の場合）ＬＴＥチャネル探索が実行され尽くした場合。

第１のタイマが終了した場合、または、（方向に依存して、ＥＶＤＯまたはＬＴＥのような）チャネル探索が実行され尽くしたとの通知をＩＰモビリティ管理モジュールが受信した場合、デバイスは、ＩＰ継続が維持されない場合がありうると仮定しうる。デバイスは、デバイスの移動方向に依存して、３ＧＰＰ−ＬＴＥインタフェースまたは３ＧＰＰ２−ｅＨＲＰＤインタフェースをローカルにティア・ダウンしうる。

ＬＴＥからｅＨＲＰＤへのデバイス移動の場合、ＥＶＤＯが獲得されたとの通知を、ＩＰモビリティ管理モジュールが、システム判定モジュールから受信すると、ＩＰモビリティ管理モジュールは、第１のタイマを停止し、第２のタイマを起動しうる。この時、ＩＰモビリティ管理モジュールは、さらなる動作を講じる前に、第２のタイマが終了するのを待つか、または、ＥＶＤＯセッション・ネゴシエーションが終了するのを待ちうる。

１２０２および１２０４に例示されるように、態様によれば、デバイスが１ｘネットワークを獲得する１２０８において第１のタイマが起動されうる。ＥＶＤＯネットワークが獲得されると、１２１０において、第１のタイマが停止され、第２のタイマが起動されうる。ＩＰモビリティ管理モジュールは、この時間中に、ＥＶＤＯセッション・ネゴシエーションが完了するのを待ちうる。

１２０２では、ＬＴＥからｅＨＲＰＤへ移動しているデバイスを示すシナリオ１が例示される。第２のタイマが終了する前にＥＶＤＯセッション・ネゴシエーションが終了し、獲得されたネットワークがｅＨＲＰＤである場合、ＩＰモビリティ管理モジュールは、１２１２において、第２のタイマを停止しうる。ＩＰモビリティ管理モジュールは、３ＧＰＰ２−ｅＨＲＤＰインタフェースを生成し、ＬＴＥからコンテキストを転送し、ＩＰ継続を維持し、デバイスのアプリケーションからのデータのフロー制御を上げる。

デバイスがｅＨＲＰＤからＬＴＥへと移動する場合、同様のアプローチが使用されうる。例えば、デバイスが、ＬＴＥネットワークを獲得する前に１ｘネットワークを獲得した場合、第１のタイマが起動されうる。この時、アプリケーションからのデータがバッファされうる。ＬＴＥが獲得されたとの通知を、ＩＰモビリティ管理モジュールがシステム判定モジュールから受信した場合、ＩＰモビリティ管理モジュールは、第１のタイマを停止し、第２のタイマを起動しうる。ＩＰモビリティ管理モジュールは、さらなる動作を講じる前に、第２のタイマが終了するか、ＬＴＥ接続が完了するかを待ちうる。ＬＴＥ接続が、第２のタイマの終了前に完了した場合、ＩＰモビリティ管理モジュールは、３ＧＰＰ−ＬＴＥインタフェースを生成しうる。ＩＰモビリティ管理モジュールは、ｅＨＲＰＤからＬＴＥへコンテキストを転送し、ＩＰ継続を維持しうる。この時、アプリケーションからのデータのフロー制御が上げられうる。

１２０４では、ＬＴＥからＨＲＰＤへ移動しているデバイスを示すシナリオ２が例示される。ＥＶＤＯセッション・ネゴシエーションが完了した後、獲得されたネットワークがＨＲＰＤであれば、ＩＰモビリティ管理モジュールは、１２１４において、第２のタイマを停止させうる。ＩＰ継続が維持されない場合がありうるので、ＩＰモビリティ管理モジュールは、ＩＰ継続が喪失したことをアプリケーションに通知し、３ＧＰＰ−ＬＴＥインタフェースをローカルにティア・ダウンしうる。アプリケーションは、ＨＲＰＤネットワークを使用して、新たなデータ接続を設定しうる。

１２０６では、ＬＴＥから１ｘへ移動するデバイスを示すシナリオ３が例示される。前述したように、デバイスが１ｘネットワークを獲得した場合、１２０８において、第１のタイマが起動されうる。１２１６では、ＩＰモビリティ管理モジュールは、ＥＶＤＯチャネル探索（あるいは、デバイスがｅＨＲＰＤから１ｘへ移動している場合には、ＬＴＥチャネル探索）が実行され尽くしたとの通知を受信しうる。ＩＰモビリティ管理モジュールは、１２１６において、第１のタイマを停止し、ＩＰ継続の喪失を宣言しうる。アプリケーションは、１ｘネットワークにおいて、新たなデータ接続を設定しうる。デバイスはまた、（デバイスがｅＨＲＰＤからＬＴＥへ移動している場合）ＥＶＤＯチャネルを正しく獲得する前に、または、（デバイスがＬＴＥからＨＲＰＤへ移動している場合）ＬＴＥチャネルを正しく獲得する前に、第１のタイマが終了した場合にも、ＩＰ継続の喪失を宣言しうる。

このアプローチは、時期尚早の動作と、ＩＰ継続の喪失とを回避する。例えば、デバイスがＬＴＥからｅＨＲＰＤへ移動して、ＥＶＤＯを獲得する前に１ｘを獲得した場合、ＩＰ継続が維持されうる。同様に、デバイスがｅＨＲＰＤからＬＴＥへ移動した場合、デバイスが、ＬＴＥよりも前に１ｘを獲得した場合、ＩＰ継続が維持されうる。さらに、デバイスがＬＴＥエリアと３ＧＰＰ２エリアとの間を矢継ぎ早に移動する場合、態様は、時期尚早の動作を回避する。態様によれば、データはデバイス移動中に喪失されないかもしれず、アプリケーションは、ＩＰ接続を確立する遅れをほとんど受けない。

図１３は、本開示の態様にしたがって、例えばＩＰモビリティ管理モジュールのようなデバイスにおけるモジュールによって実行されうる動作１３００の例を例示する。

１３０２では、ＩＰセッション中に、第１のＲＡＴネットワークから第２のＲＡＴネットワークへの移動が試みられると、モジュールは、第１のタイマを起動しうる。態様によれば、第１のＲＡＴネットワークと第２のＲＡＴネットワークとのうちの少なくとも１つは、ロング・ターム・イボリューション（ＬＴＥ）ネットワークであり、第１のＲＡＴネットワークと第２のＲＡＴネットワークとのうちの少なくとも１つは、イボルブド高レート・パケット・データ（ｅＨＲＰＤ）ネットワークでありうる。

態様によれば、第１のＲＡＴは、ＬＴＥネットワークを備え、第２のＲＡＴは、イボリューション・データ・オプティマイズド（ＥＶＤＯ）ネットワークを備えうる。ＥＶＤＯネットワークは、ｅＨＲＰＤネットワーク、または、高レート・パケット・データ（ＨＲＰＤ）ネットワークのうちの少なくとも１つを備えうる。

態様によれば、第１のＲＡＴは、ＥＶＤＯネットワークを備え、第２のＲＡＴは、ＬＴＥネットワークを備えうる。ＥＶＤＯネットワークは、ｅＨＲＰＤネットワークを備えうる。

１３０４では、第２のＲＡＴネットワークにおいてチャネルが正しく獲得された場合、モジュールは、第２のタイマを起動しうる。１３０６では、第２のタイマが終了する前に第２のＲＡＴネットワークにおいてセッションが正しくネゴシエートされ、かつ、第１のＲＡＴネットワークと第２のＲＡＴネットワークとがＩＰサービスのための共通のコア・ネットワークを共有する場合、モジュールは、ＩＰセッションのコンテキストを、第２のＲＡＴネットワークへ転送しうる。いくつかの態様では、ＩＰモビリティ管理モジュールは、ＩＰセッションのコンテキストを第２のＲＡＴへ転送する前に、ＩＰセッションでのデータ転送を却下しうる。

態様によれば、ＩＰモビリティ管理モジュールは、第１のタイマが終了する前に、第３のＲＡＴネットワークにおいてチャネルを獲得しうる。第３のＲＡＴネットワークは、１ｘネットワークでありうる。ＩＰモビリティ管理モジュールは、第３のＲＡＴにおいてチャネルを獲得することに続いて、第２のＲＡＴネットワークにおいてチャネルを求めてスキャンし続けうる。

前述されたように、ＩＰモビリティ管理モジュールは、ＩＰ継続の喪失を宣言しうる。例えば、第１のＲＡＴネットワークと第２のＲＡＴネットワークとが、ＩＰサービスのために共通のコア・ネットワークを共有しない場合、ＩＰ継続の喪失を宣言しうる。第２のＲＡＴネットワークにおいてチャネルを正しく獲得する前に第１のタイマが終了した場合、ＩＰモビリティ管理モジュールは、ＩＰ継続の喪失を宣言しうる。

本明細書に示された態様は、第１のＲＡＴネットワークと第２のＲＡＴネットワークとが、ＩＰサービスのために共通のコア・ネットワークを共有する場合、デバイスが、第１のＲＡＴネットワークから第２のＲＡＴネットワークへ移動している場合にＩＰ継続を維持するための方法を提供する。デバイスが、ＩＰサービスのために共通のコア・ネットワークを共有するＲＡＴ間を移動しており、所望のＲＡＴにおいてチャネルを獲得する前に、第３のＲＡＴにおいてチャネルを獲得した場合に、ＩＰ継続が維持されうる。したがって、態様は、デバイスが、ある種のＩＰ接続のない時間を最小化し、不必要なトラフィック・チャネル設定を回避しうる。さらに、データは、デバイス移動中に喪失されず、アプリケーションは、ＩＰ接続を確立する際に、遅れをほとんど感じない。

限定する訳ではなく、さまざまな技術が使用されうるネットワークの具体例として、これらさまざまな技術が、ＬＴＥネットワークを参照して説明されている。しかしながら、当業者であれば、これら技術は、無線ネットワークのさまざまなタイプにおいて、より一般的に適用されうることを認識するだろう。

前述した方法のさまざまな動作は、対応する機能を実行することが可能な任意の適切な手段によって実行されうる。これら手段は、限定される訳ではないが、回路、特定用途向け集積回路（ＡＳＩＣ）、またはプロセッサを含むさまざまなハードウェア構成要素および／またはソフトウェア構成要素および／またはモジュールを含みうる。

本明細書で使用される場合、用語「決定すること（determining）」は、さまざまな動作を含む。例えば、「決定すること」は、計算、コンピューティング、処理、導出、調査、ルックアップ（例えば、テーブル、データベース、または他のデータ構造内のルックアップ）、確認等を行うことを含みうる。また、「決定すること」は、受信（例えば、情報の受信）、アクセス（例えば、メモリ内のデータへのアクセス）等を行うことを含みうる。また、「決定すること」は、解決、選択、選定、確立等を行うことを含みうる。

本明細書に記載されるように、アイテムのリストのうちの「少なくとも１つ」と称する文言は、単数を含むこれらアイテムのうちの任意の組み合わせを称する。

例として、「ａ、ｂ、またはｃのうちの少なくとも１つ」は、ａ、ｂ、ｃ、ａ−ｂ、ａ−ｃ、ｂ−ｃ、およびａ−ｂ−ｃをカバーすることが意図されている。

前述した方法のさまざまな動作は、例えばさまざまなハードウェア構成要素および／またはソフトウェア構成要素、回路、および／または、モジュール（単数または複数）のように、動作を実行することが可能な任意の適切な手段によって実行されうる。通常、図面に例示される何れの動作も、これら動作を実行することが可能な対応する機能的手段によって実行されうる。

本開示に関連して説明されたさまざまな例示的な論理ブロック、モジュール、および回路を、汎用プロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールド・プログラマブル・ゲートアレイ信号（ＦＰＧＡ）もしくはその他のプログラマブル論理デバイス（ＰＬＤ）、ディスクリート・ゲートもしくはトランジスタ・ロジック、ディスクリート・ハードウェア構成要素、または本明細書で説明される機能を実行するように設計されたその任意の組み合わせを用いて実施または実行することができる。汎用プロセッサは、マイクロプロセッサでありうるが、代替案では、プロセッサは、任意の市販のプロセッサ、コントローラ、マイクロコントローラ、またはステート・マシンでありうる。プロセッサは、例えばＤＳＰとマイクロ・プロセッサとの組み合わせ、複数のマイクロ・プロセッサ、ＤＳＰコアと連携する１または複数のマイクロ・プロセッサ、またはその他任意のこのような構成であるコンピューティング・デバイスの組み合わせとして実現されうる。

本開示に関連して説明された方法またはアルゴリズムのステップを、ハードウェアで直接的に、プロセッサによって実行されるソフトウェア・モジュールによって、またはこの２つの組合せによって実施することができる。ソフトウェア・モジュールは、当該技術分野において周知のすべての形式の記憶媒体に常駐しうる。使用されうる記憶媒体のいくつかの例は、ランダム・アクセス・メモリ（ＲＡＭ）、読取専用メモリ（ＲＯＭ）、フラッシュメモリ、ＥＰＲＯＭメモリ、ＥＥＰＲＯＭメモリ、レジスタ、ハードディスク、リムーバブル・ディスク、ＣＤ−ＲＯＭなどを含む。ソフトウェア・モジュールは、単一の命令または複数の命令を備えることができ、複数の異なるコード・セグメント上で、異なるプログラムの間で、および複数の記憶媒体にわたって分散されうる。記憶媒体は、プロセッサが記憶媒体から情報を読み取り、記憶媒体に情報を書き込めるように、プロセッサに結合されうる。あるいは、この記憶媒体は、プロセッサに統合されうる。

本明細書で開示された方法は、説明された方法を達成するための１または複数のステップまたは動作を備える。方法ステップおよび／または動作は、特許請求の範囲のスコープから逸脱せずに相互に置換されうる。言い換えると、ステップまたは動作の特定の順序が指定されていない限り、特定のステップおよび／または動作の順序および／または使用は、特許請求の範囲のスコープから逸脱せずに変更されうる。

記載された機能は、ハードウェア、ソフトウェア、ファームウェア、またはこれら任意の組み合わせによって実現されうる。ソフトウェアで実現される場合、これら機能は、コンピュータ読取可能な媒体に、１または複数の命令群として格納される。記憶媒体は、コンピュータによってアクセスされうる利用可能な任意の媒体である。例として、限定することなく、このようなコンピュータ読取可能な媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、ＣＤ−ＲＯＭまたはその他の光ディスク記憶装置、磁気ディスク記憶装置またはその他の磁気記憶デバイス、あるいは、所望のプログラム・コード手段を命令群またはデータ構造の形式で搬送または格納するために使用され、しかも、コンピュータによってアクセスされうるその他任意の媒体を備えうる。本明細書で使用されるようなディスク（ｄｉｓｋおよびｄｉｓｃ）は、コンパクト・ディスク（ｄｉｓｃ）（ＣＤ）、レーザ・ディスク（ｄｉｓｃ）、光ディスク（ｄｉｓｃ）、デジタル多用途ディスク（ｄｉｓｃ）（ＤＶＤ）、フロッピー（登録商標）ディスク（ｄｉｓｋ）、およびＢｌｕ−ｒａｙ（登録商標）ディスク（ｄｉｓｃ）を含んでいる。ここで、ｄｉｓｋは通常、データを磁気的に再生する一方、ｄｉｓｃは、レーザを用いてデータを光学的に再生する。

したがって、ある態様は、本明細書に記載された動作を実行するためのコンピュータ・プログラム製品を備えうる。例えば、このようなコンピュータ・プログラム製品は、格納された（および／または符号化された）命令群を有するコンピュータ読取可能な媒体を備える。これら命令群は、本明細書において記載された動作を実行するために、１または複数のプロセッサによって実行されることが可能である。ある態様の場合、コンピュータ・プログラム製品は、パッケージング・マテリアルを含みうる。

ソフトウェアまたは命令群は、送信媒体を介しても送信される。例えば、同軸ケーブル、光ファイバ・ケーブル、ツイスト・ペア、デジタル加入者線（ＤＳＬ）、あるいは、例えば赤外線、無線およびマイクロ波のような無線技術を使用して、ウェブサイト、サーバ、あるいはその他の遠隔ソースからソフトウェアが送信される場合、同軸ケーブル、光ファイバ・ケーブル、ツイスト・ペア、ＤＳＬ、あるいは、例えば赤外線、無線およびマイクロ波のような無線技術が、媒体の定義に含まれる。

さらに、本明細書で説明された方法および技法を実行するためのモジュールおよび／または他の適切な手段を、適宜、ユーザ端末および／または基地局によってダウンロードし、かつ／または他の形式で入手することができることを了解されたい。例えば、このようなデバイスは、本明細書で説明した方法を実行するための手段の転送を容易にするためにサーバに結合されうる。代替案では、本明細書に記載されたさまざまな方法は、記憶手段（例えば、ＲＡＭ、ＲＯＭ、コンパクト・ディスク（ＣＤ）またはフロッピー・ディスクなどの物理記憶媒体など）を介して提供され、ユーザ端末および／または基地局は、記憶手段をデバイスに結合するか提供するときにさまざまな方法を取得しうる。さらに、本明細書で説明された方法および技法をデバイスに提供するために、その他任意の適切な技法が利用されうる。

特許請求の範囲は、前述した正確な構成および構成要素に限定されないことを理解されたい。さまざまな修正、変更、および変形が、特許請求の範囲の範囲から逸脱せずに、前述した方法および装置の構成、動作、および詳細において実施されうる。

前述したものは、本開示の態様に向けられているが、これら開示のその他およびさらなる態様が、本願の基本的な範囲から逸脱することなく考案され、この範囲は、以下に示す特許請求の範囲によって決定される。

Claims (44)

1. 無線通信のための方法であって、
   インターネット・プロトコル（ＩＰ）セッション中、第１のラジオ・アクセス技術（ＲＡＴ）ネットワークから第２のＲＡＴネットワークへの移動が試みられると、第１のタイマを起動させることと、
   前記第２のＲＡＴネットワークにおいてチャネルが正しく獲得された場合、第２のタイマを起動させることと、
   前記第２のタイマが終了する前に、前記第２のＲＡＴネットワークにおいてセッションが正しくネゴシエートされ、前記第１のＲＡＴネットワークと前記第２のＲＡＴネットワークが、ＩＰサービスのために共通のコア・ネットワークを共有しているのであれば、前記ＩＰセッションのコンテキストを、前記第２のＲＡＴネットワークへ転送することと、
   を備える方法。
2. 前記第１のタイマが終了する前に、第３のＲＡＴネットワークにおいてチャネルを獲得することと、
   前記第３のＲＡＴネットワークにおいてチャネルを獲得した後、前記第２のＲＡＴネットワークにおいてチャネルを求めてスキャンを続けることと、
   をさらに備える請求項１に記載の方法。
3. 前記第３のＲＡＴネットワークは、１ｘネットワークを備え、
   前記第２のＲＡＴネットワークは、イボリューション・データ・オプティマイズド（ＥＶＤＯ）ネットワークを備え、
   前記第１のＲＡＴネットワークは、ロング・ターム・イボリューション（ＬＴＥ）ネットワークを備える、請求項２に記載の方法。
4. 前記ＥＶＤＯネットワークは、イボルブド高レート・パケット・データ（ｅＨＲＰＤ）ネットワークおよび高レート・パケット・データ（ＨＲＰＤ）ネットワークのうちの少なくとも１つを備える、請求項３に記載の方法。
5. 前記第３のＲＡＴネットワークは、１ｘネットワークを備え、
   前記第２のＲＡＴネットワークは、ロング・ターム・イボリューション（ＬＴＥ）ネットワークを備え、
   前記第１のＲＡＴネットワークは、イボリューション・データ・オプティマイズド（ＥＶＤＯ）ネットワークを備える、請求項２に記載の方法。
6. 前記ＥＶＤＯネットワークは、イボルブド高レート・パケット・データ（ｅＨＲＰＤ）ネットワークを備える、請求項５に記載の方法。
7. 前記第１のＲＡＴネットワークと前記第２のＲＡＴネットワークとが、ＩＰサービスのために共通のコア・ネットワークを共有しない場合、ＩＰ継続の喪失を宣言すること、をさらに備える請求項１に記載の方法。
8. 前記第２のＲＡＴネットワークにおいてチャネルを正しく獲得する前に前記第１のタイマが終了した場合、ＩＰ継続の喪失を宣言すること、をさらに備える請求項１に記載の方法。
9. 前記第１のＲＡＴネットワークと前記第２のＲＡＴネットワークとのうちの少なくとも１つは、ロング・ターム・イボリューション（ＬＴＥ）ネットワークを備える、請求項１に記載の方法。
10. 前記第１のＲＡＴネットワークと前記第２のＲＡＴネットワークとのうちの少なくとも１つは、イボルブド高レート・パケット・データ（ｅＨＲＰＤ）ネットワークを備える、請求項１に記載の方法。
11. 前記ＩＰセッションのコンテキストを前記第２のＲＡＴネットワークへ転送する前に、前記ＩＰセッションでのデータ転送を却下すること、をさらに備える請求項１に記載の方法。
12. 無線通信のための装置であって、
    インターネット・プロトコル（ＩＰ）セッション中、第１のラジオ・アクセス技術（ＲＡＴ）ネットワークから第２のＲＡＴネットワークへの移動が試みられると、第１のタイマを起動させる手段と、
    前記第２のＲＡＴネットワークにおいてチャネルが正しく獲得された場合、第２のタイマを起動させる手段と、
    前記第２のタイマが終了する前に、前記第２のＲＡＴネットワークにおいてセッションが正しくネゴシエートされ、前記第１のＲＡＴネットワークと前記第２のＲＡＴネットワークが、ＩＰサービスのために共通のコア・ネットワークを共有しているのであれば、前記ＩＰセッションのコンテキストを、前記第２のＲＡＴネットワークへ転送する手段と、
    を備える装置。
13. 前記第１のタイマが終了する前に、第３のＲＡＴネットワークにおいてチャネルを獲得する手段と、
    前記第３のＲＡＴネットワークにおいてチャネルを獲得した後、前記第２のＲＡＴネットワークにおいてチャネルを求めてスキャンを続ける手段と、
    をさらに備える請求項１２に記載の装置。
14. 前記第３のＲＡＴネットワークは、１ｘネットワークを備え、
    前記第２のＲＡＴネットワークは、イボリューション・データ・オプティマイズド（ＥＶＤＯ）ネットワークを備え、
    前記第１のＲＡＴネットワークは、ロング・ターム・イボリューション（ＬＴＥ）ネットワークを備える、請求項１３に記載の装置。
15. 前記ＥＶＤＯネットワークは、イボルブド高レート・パケット・データ（ｅＨＲＰＤ）ネットワークおよび高レート・パケット・データ（ＨＲＰＤ）ネットワークのうちの少なくとも１つを備える、請求項１４に記載の装置。
16. 前記第３のＲＡＴネットワークは、１ｘネットワークを備え、
    前記第２のＲＡＴネットワークは、ロング・ターム・イボリューション（ＬＴＥ）ネットワークを備え、
    前記第１のＲＡＴネットワークは、イボリューション・データ・オプティマイズド（ＥＶＤＯ）ネットワークを備える、請求項１３に記載の装置。
17. 前記ＥＶＤＯネットワークは、イボルブド高レート・パケット・データ（ｅＨＲＰＤ）ネットワークを備える、請求項１６に記載の装置。
18. 前記第１のＲＡＴネットワークと前記第２のＲＡＴネットワークとが、ＩＰサービスのために共通のコア・ネットワークを共有しない場合、ＩＰ継続の喪失を宣言する手段、さらに備える請求項１２に記載の装置。
19. 前記第２のＲＡＴネットワークにおいてチャネルを正しく獲得する前に前記第１のタイマが終了した場合、ＩＰ継続の喪失を宣言する手段、をさらに備える請求項１２に記載の装置。
20. 前記第１のＲＡＴネットワークと前記第２のＲＡＴネットワークとのうちの少なくとも１つは、ロング・ターム・イボリューション（ＬＴＥ）ネットワークを備える、請求項１２に記載の装置。
21. 前記第１のＲＡＴネットワークと前記第２のＲＡＴネットワークとのうちの少なくとも１つは、イボルブド高レート・パケット・データ（ｅＨＲＰＤ）ネットワークを備える、請求項１２に記載の装置。
22. 前記ＩＰセッションのコンテキストを前記第２のＲＡＴネットワークへ転送する前に、前記ＩＰセッションでのデータ転送を却下する手段、をさらに備える請求項１２に記載の装置。
23. 無線通信のための装置であって、
    インターネット・プロトコル（ＩＰ）セッション中、第１のラジオ・アクセス技術（ＲＡＴ）ネットワークから第２のＲＡＴネットワークへの移動が試みられると、第１のタイマを起動させ、
    前記第２のＲＡＴネットワークにおいてチャネルが正しく獲得された場合、第２のタイマを起動させ、
    前記第２のタイマが終了する前に、前記第２のＲＡＴネットワークにおいてセッションが正しくネゴシエートされ、前記第１のＲＡＴネットワークと前記第２のＲＡＴネットワークが、ＩＰサービスのために共通のコア・ネットワークを共有しているのであれば、前記ＩＰセッションのコンテキストを、前記第２のＲＡＴネットワークへ転送する、
    ように構成された少なくとも１つのプロセッサと、
    前記少なくとも１つのプロセッサに接続されたメモリと、
    を備える装置。
24. 前記少なくとも１つのプロセッサはさらに、
    前記第１のタイマが終了する前に、第３のＲＡＴネットワークにおいてチャネルを獲得し、
    前記第３のＲＡＴネットワークにおいてチャネルを獲得した後、前記第２のＲＡＴネットワークにおいてチャネルを求めてスキャンを続ける
    ように構成された、請求項２３に記載の装置。
25. 前記第３のＲＡＴネットワークは、１ｘネットワークを備え、
    前記第２のＲＡＴネットワークは、イボリューション・データ・オプティマイズド（ＥＶＤＯ）ネットワークを備え、
    前記第１のＲＡＴネットワークは、ロング・ターム・イボリューション（ＬＴＥ）ネットワークを備える、請求項２４に記載の装置。
26. 前記ＥＶＤＯネットワークは、イボルブド高レート・パケット・データ（ｅＨＲＰＤ）ネットワークおよび高レート・パケット・データ（ＨＲＰＤ）ネットワークのうちの少なくとも１つを備える、請求項２５に記載の装置。
27. 前記第３のＲＡＴネットワークは、１ｘネットワークを備え、
    前記第２のＲＡＴネットワークは、ロング・ターム・イボリューション（ＬＴＥ）ネットワークを備え、
    前記第１のＲＡＴネットワークは、イボリューション・データ・オプティマイズド（ＥＶＤＯ）ネットワークを備える、請求項２４に記載の装置。
28. 前記ＥＶＤＯネットワークは、イボルブド高レート・パケット・データ（ｅＨＲＰＤ）ネットワークを備える、請求項２７に記載の装置。
29. 前記少なくとも１つのプロセッサはさらに、前記第１のＲＡＴネットワークと前記第２のＲＡＴネットワークとが、ＩＰサービスのために共通のコア・ネットワークを共有しない場合、ＩＰ継続の喪失を宣言するように構成された、請求項２３に記載の装置。
30. 前記少なくとも１つのプロセッサはさらに、前記第２のＲＡＴネットワークにおいてチャネルを正しく獲得する前に前記第１のタイマが終了した場合、ＩＰ継続の喪失を宣言するように構成された、請求項２３に記載の装置。
31. 前記第１のＲＡＴネットワークと前記第２のＲＡＴネットワークとのうちの少なくとも１つは、ロング・ターム・イボリューション（ＬＴＥ）ネットワークを備える、請求項２３に記載の装置。
32. 前記第１のＲＡＴネットワークと前記第２のＲＡＴネットワークとのうちの少なくとも１つは、イボルブド高レート・パケット・データ（ｅＨＲＰＤ）ネットワークを備える、請求項２３に記載の装置。
33. 前記少なくとも１つのプロセッサはさらに、前記ＩＰセッションのコンテキストを前記第２のＲＡＴネットワークへ転送する前に、前記ＩＰセッションでのデータ転送を却下するように構成された、請求項２３に記載の装置。
34. 無線通信のためのコンピュータ・プログラム製品であって、
    前記コンピュータ・プログラム製品は、格納されたプログラム・コードを有する非一時的なコンピュータ読取可能な媒体を備え、
    前記コードは、
    インターネット・プロトコル（ＩＰ）セッション中、第１のラジオ・アクセス技術（ＲＡＴ）ネットワークから第２のＲＡＴネットワークへの移動が試みられると、第１のタイマを起動させることと、
    前記第２のＲＡＴネットワークにおいてチャネルが正しく獲得された場合、第２のタイマを起動させることと、
    前記第２のタイマが終了する前に、前記第２のネットワークにおいてセッションが正しくネゴシエートされ、前記第１のＲＡＴネットワークと前記第２のＲＡＴネットワークが、ＩＰサービスのために共通のコア・ネットワークを共有しているのであれば、前記ＩＰセッションのコンテキストを、前記第２のＲＡＴネットワークへ転送することと、
    のために１または複数のプロセッサによって実行可能である、コンピュータ・プログラム製品。
35. 前記第１のタイマが終了する前に、第３のＲＡＴネットワークにおいてチャネルを獲得するためのコードと、
    前記第３のＲＡＴネットワークにおいてチャネルを獲得した後、前記第２のＲＡＴネットワークにおいてチャネルを求めてスキャンを続けるためのコードと、
    をさらに備える、請求項３４に記載のコンピュータ・プログラム製品。
36. 前記第３のＲＡＴネットワークは、１ｘネットワークを備え、
    前記第２のＲＡＴネットワークは、イボリューション・データ・オプティマイズド（ＥＶＤＯ）ネットワークを備え、
    前記第１のＲＡＴネットワークは、ロング・ターム・イボリューション（ＬＴＥ）ネットワークを備える、請求項３５に記載のコンピュータ・プログラム製品。
37. 前記ＥＶＤＯネットワークは、イボルブド高レート・パケット・データ（ｅＨＲＰＤ）ネットワークおよび高レート・パケット・データ（ＨＲＰＤ）ネットワークのうちの少なくとも１つを備える、請求項３６に記載のコンピュータ・プログラム製品。
38. 前記第３のＲＡＴネットワークは、１ｘネットワークを備え、
    前記第２のＲＡＴネットワークは、ロング・ターム・イボリューション（ＬＴＥ）ネットワークを備え、
    前記第１のＲＡＴネットワークは、イボリューション・データ・オプティマイズド（ＥＶＤＯ）ネットワークを備える、請求項３５に記載のコンピュータ・プログラム製品。
39. 前記ＥＶＤＯネットワークは、イボルブド高レート・パケット・データ（ｅＨＲＰＤ）ネットワークを備える、請求項３８に記載のコンピュータ・プログラム製品。
40. 前記第１のＲＡＴネットワークと前記第２のＲＡＴネットワークとが、ＩＰサービスのために共通のコア・ネットワークを共有しない場合、ＩＰ継続の喪失を宣言するためのコード、をさらに備える請求項３４に記載のコンピュータ・プログラム製品。
41. 前記第２のＲＡＴネットワークにおいてチャネルを正しく獲得する前に前記第１のタイマが終了した場合、ＩＰ継続の喪失を宣言するためのコード、をさらに備える請求項３４に記載のコンピュータ・プログラム製品。
42. 前記第１のＲＡＴネットワークと前記第２のＲＡＴネットワークとのうちの少なくとも１つは、ロング・ターム・イボリューション（ＬＴＥ）ネットワークを備える、請求項３４に記載のコンピュータ・プログラム製品。
43. 前記第１のＲＡＴネットワークと前記第２のＲＡＴネットワークとのうちの少なくとも１つは、イボルブド高レート・パケット・データ（ｅＨＲＰＤ）ネットワークを備える、請求項３４に記載のコンピュータ・プログラム製品。
44. 前記ＩＰセッションのコンテキストを前記第２のＲＡＴネットワークへ転送する前に、前記ＩＰセッションでのデータ転送を却下するためのコード、をさらに備える請求項３４に記載のコンピュータ・プログラム製品。

Images