(57)【特許請求の範囲】
【請求項１】
無線ネットワークにおいて、長いＤＲＸ状態または短いＤＲＸ状態のいずれかにあるユーザー機器（ＵＥ）が、非連続性受信（ＤＲＸ）オペレーションを適用する工程、
データ伝送の送信または受信を含む、ＤＲＸ状態遷移をトリガする１つ以上のＤＲＸ状態遷移に係るトリガイベント、及び、ＤＲＸ状態遷移に係るタイマーの満了を検出する工程、
複数のトラフィック条件を検出する工程であって、前記トラフィック条件は、前記データ伝送または伝送のためにバッファリングされたデータが予め定められたしきい値を超えているかどうか、前記データ伝送が予め定義された論理チャネルのうちの１つまたは予め定義された論理チャネルグループのうちの１つのためのものであるかどうか、前記データ伝送が予め定義された特定のアップリンクまたはダウンリンク伝送であるかどうか、及び前記ＵＥまたは前記論理チャネルが非パワーセービング状態にあるかどうか、という条件を含む工程、及び
前記トラフィック条件に基づいて、前記ＤＲＸ状態遷移を禁止する工程
を含む方法。
【請求項２】
前記トラフィック条件の１つは、前記ＤＲＸ状態遷移を禁止するネットワークコマンドであり、
前記ネットワークコマンドは、ＵＥによるトラフィック条件情報に基づく
請求項１に記載の方法。
【請求項３】
前記ＤＲＸ状態は、前記長いＤＲＸ状態であり、
前記ＤＲＸ状態遷移を禁止する前記トラフィック条件の１つは、バックグラウンドトラフィックまたは低ＱｏＳトラフィックである、
請求項１に記載の方法。
【請求項４】
前記トラフィック条件同期メッセージは、前記ワイヤレスネットワークに、前記ＵＥのＤＲＸ状態、ＤＲＸパラメーターの更新、および／または前記ＵＥによって検出されるトラフィック条件を、示すためのものであることを特徴とする請求項１に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
関連出願の相互参照
本出願は、３５Ｕ．Ｓ．Ｃ．§１１９に基づく、２０１２年５月２日に出願された“ＵＥ Ｅｎｈａｎｃｅｍｅｎｔ ｆｏｒ Ｄｉｖｅｒｓｅ Ｄａｔａ Ａｐｐｌｉｃａｔｉｏｎ,”と題する米国特許仮出願第６１／６４１，７１４号の優先権を主張し、その内容は参照することにより本明細書に組み込まれる。
開示される実施形態は、概して移動通信ネットワークに関し、より詳細には、多様なデータの使用のためのＵＥの改善に関する。
【背景技術】
【０００２】
移動データは、携帯電話加入者および移動データトラフィックの両方から見て、驚異的な速さで増えている。移動データの急激な増加は、ネットワーク容量およびネットワーク効率の大幅な向上を必要とする。現在、既存の第３世代（３Ｇ）移動ネットワークはネットワークの輻輳問題に直面しており、このことは多くのマーケットにおいて、コールの失敗、より低いデータレートおよび遅い応答時間をもたらしている。データトラフィックの増加と同時に、ｉＰｈｏｎｅ、ＡｎｄｒｏｉｄフォンおよびＢｌａｃｋｂｅｒｒｙフォンユーザーのようなスマートフォン加入者の急速な取り込みは、事実上の常時接続（ａｌｗａｙｓ−ｏｎ）機能のサポートのために、移動ネットワークにさらなるプレッシャーをかけている。常時接続機能はいくつかの問題を引き起こす。第１に、キープアライブおよびステータスアップデートのように、常時接続機能の多くは、頻繁なトラフィックを生じさせる。第２に、それは、頻繁なコンテキスト確立および解除のために、ネットワークにおけるシグナリングを著しく増加させる。第３に、それは、ユーザー装置のバッテリー寿命に悪影響を与える。第４に、常時接続機能をサポートするためのオーバーヘッドが、そのデータペイロードに比して非常に大きい。
【０００３】
ロング・ターム・エボリューション（ＬＴＥ）は、 より高いデータレート、より低いレイテンシ、および改善されたシステム容量を提供する、改善されたユニバーサル・モバイル・テレコミュニケーション・システム（ＵＭＴＳ）である。ＬＴＥシステムにおいて、進化型地上無線アクセスネットワークは、ユーザー機器（ＵＥ）と呼ばれる複数の移動局と通信する、進化型ノードＢｓ（ｅＮＢｓ）と呼ばれる複数の基地局を含む。ＵＥは、ダウンリンクおよびアップリンクを介して基地局またはｅＮＢと通信することができる。ダウンリンク（ＤＬ）とは基地局からＵＥへの通信のことである。アップリング（ＵＬ）とはＵＥから基地局への通信のことである。ＬＴＥシステムは、当初から、常時接続のトラフィックを処理するのによく適応している。例えば、ＬＴＥシステムは、モビリティ管理エンティティ（ＭＭＥ）によって、接続モードにおけるより長いスリープモード、物理層制御チャネルにおける動的容量（ｄｙｎａｍｉｃ ｃａｐａｃｉｔｙ）、および拡大するコアネットワークのシグナリング容量におけるフレキシビリティをサポートする。
【０００４】
ＬＴＥシステムの改善にもかかわらず、それは依然として容量および効率の問題に直面している。例えば、移動ネットワークの操作者は常にデータトラフィックよりもリアルタイムの音声トラフィックを優先させる。回線交換音声トラフィックのためにネットワーク全域でリソースが蓄えられている。３ＧおよびＬＴＥネットワークのような新しい無線データネットワークも、ビデオ会議のような大量のデータトラフィックのためのサポートを最適化している。しかしながら、このような設計は、チャットのアプリケーション（ｃｈａｔｔｙ ａｐｐｌｉｃａｔｉｏｎｓ）およびキープアライブメッセージのような短く、低頻度のデータセッションのアプリケーションにはうまく機能しない。ニュース、天気、およびソーシャルネットワーキングのような多くの一般的なアプリケーションは、ネットワークに周期的に接続および切断をし、更新を行う。これらのアプリケーションは少量のユーザーデータを含むが、セッションを確立および中断（ｔｅａｒ ｄｏｗｎ）するのに依然として大量のシグナリングトラフィックを必要とする。ネットワークを介するスマートフォンアプリケーションの数の増加に伴って、 シグナリングオーバーヘッドがデータトラフィックを、より高くはないとしても、３０％から５０％上回っていると推測される。これらアプリケーションは、大きい制御オーバーヘッドおよびシグナリングロードを生じる。頻繁なバックグランドのトラフィックはバッテリー消費のために最適化されていないため、ＵＥのバッテリー寿命も大きな関心事となっている。さらに、ＵＥの長いスリープサイクルはＵＥのバッテリー寿命を延ばすのに役立つが、それはネットワーク制御のハンドオーバーにはさほどうまく機能しない。ＵＥが長いスリープサイクルにあるとき、それはモビリティ測定を実行しない。ネットワークでは結果的に、ＵＥのハンドオーバーの準備を効率的に補助するのに精度の低い測定がなされるようになる。
【０００５】
第１の問題点（ｉｓｓｕｅ）は、 非連続性（間欠）受信（ｄｉｓｃｏｎｔｉｎｕｏｕｓ ｒｅｃｅｐｔｉｏｎ, ＤＲＸ）または非連続性送信（ｄｉｓｃｏｎｔｉｎｕｏｕｓ ｔｒａｎｓｍｉｓｓｉｏｎ, ＤＴＸ）の遷移に関するものである。２Ｇおよび３Ｇでは、ＵＥはアイドル状態において非連続性受信（ＤＲＸ）を用い、バッテリー寿命を延長させる。ＬＴＥシステムは、接続状態にＤＲＸを導入した。接続状態における長いＤＲＸは、 バッテリー寿命を向上させるのに役立つと共に、ネットワークシグナリングオーバーヘッドを低減させる。しかしながら、現在のＬＴＥでは、接続状態のＤＲＸは、アップリンクにおいて何らトラフィックシェーピングの利益ももたらさない。トラフィックシェーピングは、接続状態のＤＲＸにおいてダウンリンクに利用可能であるが、それは厳格に定義されている。トラフィックシェーピングでは、トラフィックタイプまたはＵＥの状態に関するいかなる情報も考慮されない。このような設計は、接続モードの休止機能（ｄｏｒｍａｎｃｙ ｆｅａｔｕｒｅ）の利益を制限する。
【０００６】
第２の問題点は、ＵＥがアイドルモードに入る遷移に関するものである。ＬＴＥシステムにおける同様のネットワーク非効率の問題は、アイドル状態に遷移することに関連している。２つの無線リソース制御（ＲＲＣ）状態、つまりＲＲＣ ＩＤＬＥ状態およびＲＲＣ ＣＯＮＮＥＣＴＥＤ状態がある。現在のところ、ＲＲＣ ＣＯＮＮＥＣＴＥＤ状態からＲＲＣ ＩＤＬＥ状態への遷移はネットワークにより制御されている。ＲＲＣ ＩＤＬＥ状態へ遷移することの主な目的は、パワーセービングのためである。しかし、ＲＲＣ状態の遷移は、大きなシグナリングオーバーヘッドを生じさせる。さらに、頻繁なＲＲＣ状態の変化も、より多くのシステムリソースの使用を強いる可能性があり、ネットワークにおいてシグナリングオーバーヘッドが増加することになる。あるアプリケーションのトラフィックでは、現在のＲＲＣ状態遷移の設計は、パワーセービングおよび／またはシステム効率を相殺し得る。
【０００７】
第３の問題点は、ＵＥの測定レポートおよび無線リンク障害（ＲＬＦ）の検出に関するものである。現在のＬＴＥシステムにおける１つの問題は、ＵＥの測定および測定レポートのトリガが厳格な（ｒｉｇｉｄ）ことである。それらは、バックグラウンドトラフィック、パワーセービングまたは非パワーセービング状態のようなＵＥのトラフィックのタイプに適応していない。さらに、ＵＥは、Ｎ３１０／Ｎ３１１／Ｔ３１０の手順に基づく物理層の問題、ＭＡＣ層からのランダムアクセス問題の表示（ｉｎｄｉｃａｔｉｏｎ）、および最大再送数に達したという無線リンク制御（ＲＬＣ）層からの表示を基に、ＲＬＦが検出されると見なす。一旦、ＲＬＦが検出されると、ＵＥは、ＲＬＦ情報を収集すると共に保存し、かつＲＲＣ接続の確立を試みる。かかる試みが失敗する場合、ＵＥはＲＲＣ ＩＤＬＥ状態に戻る。よって、一旦ＵＥがＲＬＦが検出されるとみなすと、それはコストのかかる一連の手順を呼び出すであろう。現在のＲＬＦトリガでは、バックグラウンドトラフィック、パワーセービングまたは非パワーセービング状態のようなトラフィックタイプは考慮されない。このことは、早過ぎる時にＲＬＦを宣言するという結果となって、失敗したＲＲＣ再確立に続く非アクセス層（ｎｏｎ−ａｃｃｅｓｓ ｓｔｒａｔｕｍ, ＮＡＳ）の回復をトリガし得、それはさらなるコアネットワークのシグナリングを生じさせる。
【発明の概要】
【発明が解決しようとする課題】
【０００８】
移動通信ネットワークにおいては、上述したような問題の解決が求められている。
【課題を解決するための手段】
【０００９】
多様なデータの使用のためのユーザー機器の改善の方法が開示される。本発明の１実施形態では、無線ネットワークにおいて、長いＤＲＸ状態または短いＤＲＸ状態にあるＵＥが、非連続性受信（ＤＲＸ）および／または非連続性送信（ＤＴＸ）オペレーションを適用する。ＵＥが長いＤＲＸ状態にあるという表記（ｎｏｔａｔｉｏｎ）は、ＵＥが長いスリープ期間を有する長いＤＲＸサイクルを用いるということに相当し、ＵＥが短いＤＲＸ状態にあるという表記は、ＵＥが短いスリープ期間を有する短いＤＲＸサイクルを用いるということに相当する。ＵＥはデータ伝送（ｄａｔａ ｔｒａｎｓｍｉｓｓｉｏｎ）を送信または受信する。ＵＥは、１つまたはそれ以上の予め定義されたトラフィック条件を検出する。検出されたトラフィック条件に基づいて、ＵＥはＤＲＸ遷移を実行する。本発明の１実施形態において、１つまたはそれ以上の予め定義されたトラフィック条件が検出されると、ＵＥは、短いＤＲＸ状態に遷移する代わりに、長いＤＲＸ状態にとどまる。本発明の別の実施形態では、１つまたはそれ以上の予め定義されたトラフィック条件を検出すると、ＵＥは、短いＤＲＸにおける持続期間を延長する。本発明のさらに別の実施形態では、ネットワークのＤＲＸ遷移コマンドを受信すると、ＵＥは、トラフィック条件情報をネットワークに送信すると共にＤＲＸ遷移を実行し、このうち、ネットワークコマンドはトラフィック条件に基づくものである。
【００１０】
本発明の他の実施形態において、ＵＥはアイドルモードトリガ条件を設定する。ＵＥは、１つまたはそれ以上の予め定義されたトラフィック条件を検出する。トリガ条件が満たされると、ＵＥは、トラフィック条件に基づいてアイドルモード遷移アクションを実行し、アイドルモードに遷移する。本発明の１実施形態において、１つまたはそれ以上の予め定義されたトラフィック条件が検出されると、ＵＥはインアクティビティタイマー（ｉｎａｃｔｉｖｉｔｙ ｔｉｍｅｒ）を再起動する。本発明の別の実施形態では、ＵＥは、トラフィック条件に基づいて、アイドルモード補助情報をネットワークへ送信する。ネットワークはアイドルモードコマンドメッセージをＵＥへ送信する。ネットワークコマンドメッセージを受信すると、ＵＥはアイドル状態に入る。
【００１１】
本発明の他の実施形態において、ＵＥは、１つまたはそれ以上の予め定義されたトラフィック条件を検出する。ＵＥは、予め定義されたトラフィック条件に基づいて、ＲＬＦトリガパラメータを適応的に調整する。
【００１２】
他の実施形態および利点は、以下の詳細な説明において記載される。この概要は、本発明を定義することを意図するものではない。本発明は、特許請求の範囲によって定義される。
【図面の簡単な説明】
【００１３】
【図１】図１は、本発明の実施形態に従ったトップレベルフローチャートを概略的に示す図である。
【図２】図２は、本発明のいくつかの実施形態をサポートするＵＥの例示的ブロック図を示す図である。
【図３】図３は、本発明の実施形態に従った動的ＤＲＸ状態遷移の例示的ブロック図を概略的に示す図である。 
【図４Ａ】図４Ａは、ＵＥが、データ伝送を受信後に、検出されたトラフィック条件に基づいて長いＤＲＸ状態にとどまる場合の例示的手順を示す図である。
【図４Ｂ】図４Ｂは、ＵＥが、データ伝送を受信後に、検出されたトラフィック条件に基づいて短いＤＲＸ状態に遷移する場合の例示的手順を示す図である。
【図５】図５は、本発明の１実施形態に従った、長いＤＲＸ状態から短いＤＲＸ状態への動的遷移の例示的フローチャートである。
【図６Ａ】図６Ａは、トラフィック条件が禁止条件が存在しないことを示すときにデータ伝送後インアクティビティタイマーが延長される場合の例示的シナリオを示す図である。
【図６Ｂ】図６Ｂは、トラフィック条件が禁止条件が存在しないことを示すときにデータ伝送後短いＤＲＸサイクルタイマーが延長される場合の例示的シナリオを示す図である。
【図７】図７は、トラフィック条件に基づいてＵＥがＤＲＸインアクティビティタイマーおよび／または短いＤＲＸサイクルタイマーを動的に更新する例示的フローチャートである。
【図８】図８は、ＵＥがネットワークコマンドに基づいてＤＲＸ状態遷移を実行する、およびネットワークがＵＥから受信したトラフィック条件に基づいてＤＲＸコマンドを決定する場合の例示的フローチャートである。
【図９】図９は、本発明の実施形態に従った、ネットワークコマンドによる動的ＤＲＸ遷移の例示的フローチャートである。
【図１０】図１０は、ＵＥにより検出されたトラフィック条件に基づく動的ＤＲＸ遷移の例示的フローチャートである。
【図１１】図１１は、アイドル遷移補助データがＵＥからネットワークへ送信される場合のアイドルモード遷移の例示的フローチャートである。 
【図１２】図１２は、トラフィック条件に基づいてＵＥがインアクティビティタイマーを起動または再起動する場合の例示的フローチャートである。
【図１３】図１３は、トラフィック条件に基づいてインアクティビティタイマーが起動されない場合の例示的フローチャートである。
【図１４】図１４は、１つまたはそれ以上のトラフィック条件に基づいてＵＥがアイドル状態に遷移する場合の例示的フローチャートである。
【図１５】図１５は、ユーザープレーンアクティビティに基づいてＵＥが測定レポートを送信する場合の例示的フローチャートである。
【図１６】図１６は、検出されたトラフィック条件に基づいてＴＴＴタイマーが満了する前にＵＥが測定レポートをトリガする場合の例示的フローチャートである。
【図１７】図１７は、トラフィック条件に基づいてＵＥがＲＬＦをトリガする場合の例示的フローチャートである。
【発明を実施するための形態】
【００１４】
以下に、本発明のいくつかの実施形態が詳細に参照され、その例は添付の図面に示される。
【００１５】
図１は、本発明の実施形態に従ったトップレベルフローチャートを概略的に示している。無線ネットワークは、基地局ｅＮＢ１０２と接続するユーザー機器ＵＥ１０１を含む。１つの新規な態様によると、ＵＥ１０１は、１つまたはそれ以上のトラフィック条件に基づいて動的ＤＲＸ遷移アクションを実行する。ＵＬのトラフィックシェーピングを実行するためのソリューションを提供することが、本発明の目的である。さらに、本発明は、トラフィックタイプ、パワーセービングまたは非パワーセービング状態などのようなその他の要因に基づいて、ＵＥの休止（ｄｏｒｍａｎｃｙ）パラメータを動的に調整するためのソリューションを提供する。パワーセービングまたは非パワーセービングは、厳密にはそれぞれパワーセービング状態または非パワーセービング状態、で表され得る。ユーザーがインタラクティブモードにあるとき、ＵＥは通常、スクリーンがオンの非パワーセービング状態にあるであろう。ユーザーが非インタラクティブ状態にあるとき、ＵＥは、スクリーンがオフのパワーセービングモードに入るであろう。よって、 非インタラクティブ状態およびパワーセービングモード／状態という表記は同意義と見なされ、かつインタラクティブ状態および非パワーセービングモード／状態という表記は同意義と見なされる。ＵＥがかかるモードまたは状態にあるかどうかは、ＵＥからネットワークへ信号で伝えられ、ＵＥはパワーセービングを優先するかどうかを示す。休止アルゴリズムに追加のシナリオおよびパラメータを挿入することで、ＵＥは、何らユーザーのクオリティ・オブ・サービス（ＱｏＳ）の影響なしに、より長くスリープ状態にとどまることができる。それは、制御オーバーヘッドをさらに減らすことができると共に、ＵＥのスリープ効率を向上させる。図１の例では、ステップ１１１において、ＵＥ１０１はトラフィック条件を検出する。ステップ１１２においてＵＥ１０１はＤＲＸ状態に入る。ＤＲＸ状態は長いＤＲＸ状態または短いＤＲＸ状態であり得る。ステップ１２１において、ＵＥ１０１はトラフィック条件に基づいてＤＲＸ／ＤＴＸ遷移アクションを実行する。
【００１６】
本発明の別の新規な態様は、接続状態にあるＵＥのアイドル状態への遷移を含む。 状態遷移は、トラフィックタイプ、ＤＲＸ状態、パワーセービングまたは非パワーセービング状態、およびＵＥにより制御されて状態遷移を補助することのできるその他のパラメータの情報（ｋｎｏｗｌｅｄｇｅ）を適用することによって最適化される。本発明は、アイドルモード遷移のシグナリングを減らすことにより制御オーバーヘッドを減少させるための、およびアイドルモードへの早過ぎる遷移を回避するためのソリューションを提供する。図１の例では、ＵＥ１０１は、ステップ１１３において、トラフィック条件を検出する。ステップ１１４において、ＵＥ１０１はアイドルモード遷移を開始する。ステップ１２２において、ＵＥ１０１はトラフィック条件に基づいて、ＵＥのアイドルへの遷移アクション（ｔｒａｎｓｉｔｉｏｎ ｔｏ Ｉｄｌｅ ａｃｔｉｏｎｓ）を実行する。
【００１７】
本発明の別の新規な態様は、トラフィックタイプ、パワーセービングまたは非パワーセービング状態のような追加の情報を考慮することによりＲＬＦを検出するより動的な方法をＵＥに与える。この改善されたＲＬＦ手順により、ＵＥがより高いＱｏＳを必要とする場合にハンドオーバーのためのサーチの速いトリガは依然維持しながら、ＵＥは、ＱｏＳに影響が無いときに、ＲＬＦの宣言を遅らせることができる。図１の例では、ＵＥ１０１は、ステップ１１５において、トラフィック条件を検出する。ステップ１１６において、ＵＥ１０１はＲＬＦ遷移を実行する。ステップ１２３において、トラフィックレポートに基づき、ＵＥ１０１はＲＬＦアクションを実行する。
【００１８】
図２は、本発明のいくつかの実施形態をサポートするＵＥの例示的ブロック図を示している。ＵＥは、アンテナ２０１に接続され、アンテナ２０１からＲＦ信号を受信し、それらをベースバンド信号に変換し、そしてそれらをプロセッサ２１２に送信するＲＦ送受信機モジュール２１１を備える。ＲＦ送受信機２１１はまた、 プロセッサ２１２から受信したベースバンド信号も変換し、それらをＲＦ信号に変換し、そしてアンテナ２０１へ送出する。プロセッサ２１２は、受信したベースバンド信号を処理し、そして異なる機能モジュールを起動してＵＥ内の機能を実行させる。メモリ２１３はプログラム命令およびデータを格納して、ＵＥの動作を制御する。図２はさらに、本発明の実施形態を実現するＵＥ中の１０個の機能モジュール２２１から２２５を示している。機能モジュールは、ハードウェア、ファームウェア、ソフトウェア、またはこれら任意の組み合わせによって実施され得る。
【００１９】
トラフィック条件モジュール２２１はトラフィック条件を検出する。ＤＲＸ状態およびアイドル状態のような現在の休止−覚醒（起動）（ｄｏｒｍａｎｃｙ−ａｗａｋｅ）の決定では、異なるタイプのトラフィックまたはアクティビティは考慮されない。バックグラウンドトラフィックのようないくつかのトラフィックタイプはＱｏＳの要求がより低い。ＵＥ内に動作中の複数のアプリケーションがあることがあり、各々はわずかなバックグラウンドトラフィックを生じる。トラフィック検出モジュール２２１は、これらトラフィックを検出すると共に、条件に基づいて決定を行うことができる。トラフィック条件の別の例は、ＵＥがアクティブであるかどうかである。スクリーンがアクティブとなっている、アプリケーションウィンドウがユーザーに対し表示されている、または最近ユーザーによりアプリケーションへ入力があったといったような、ユーザーとＵＥにおける１つまたはそれ以上のアプリケーションとの間にあるインタラクション（ｉｎｔｅｒａｃｔｉｏｎ）があるとき、ＵＥはアクティブである。ＵＥがアクティブであるとき、データ伝送は恐らくあるであろう。よって、ＵＥは覚醒状態（起動状態）により長くとどまることを決定し得る。他の例は、論理チャネルのパワーセービングまたは非パワーセービング状態である。データを送信または受信しているアプリケーションによってＵＥがアクティブである場合、データ伝送の論理チャネルは、非パワーセービング状態にある。一方、ＵＥが非アクティブまたはパワーセービング状態にある場合、データ伝送は、遅延により耐性があるものと見なされ得る。故に、スクリーンがオフである、および、バックグラウンドデータ伝送がＱｏＳ要求の低いものであるなど、ＵＥが非パワーセービングモードにあるとき、ＵＥは、より優れたバッテリー性能を持てるように、より長くスリープモードにとどまることができる。トラフィック検出モジュール２２１は、ユーザープレーンアクティビティレベルのような他のＵＥの状況を検出することができ、さらに、ある事前設定された情報、ネットワーク命令、およびトラフィック条件の決定に際して動的に受信したその他の情報を入手することができる。
【００２０】
ＤＲＸ／ＤＴＸモジュール２２２はＤＲＸ／ＤＴＸ遷移アクションを処理する。 モジュール２２２は、トラフィック条件モジュール２２１からトラフィック条件を取り込むと共に、他のＤＲＸ／ＤＴＸ状態に遷移するかどうかについて決定する。トラフィック条件に基づいて、ＤＲＸ／ＤＴＸモジュール２２２は、短いＤＲＸサイクル時間およびＤＲＸインアクティビティタイマーのようなＤＲＸ／ＤＴＸパラメータを動的に変更／更新することもできる。ＵＥアイドル状態遷移モジュール２２３は、トラフィック条件モジュール２２１からトラフィック条件を取り込むと共に、接続状態からアイドル状態へ遷移するかどうかについて決定する。測定モジュール２２４は、トラフィック条件モジュール２２１からトラフィック条件を取り込むと共に、測定レポートをいつ送信するか、およびモビリティ測定をいつ行うかに関して動的に決定する。ＲＬＦモジュール２２５は、測定モジュール２２４から出力された測定レポートおよびトラフィック条件モジュール２２１からのトラフィック条件を取得する。ＲＬＦモジュール２２５は 、測定レポートおよびトラフィック条件に基づいて、ＲＬＦを宣言するかどうかを動的に決定する。
【００２１】
ＤＲＸ／ＤＴＸオペレーション
図３は、本発明の実施形態に従った動的ＤＲＸ状態遷移の例示的ブロック図を概略的に示している。ＵＥは、より長いスリープ時間を有する長いＤＲＸと、より短いスリープ時間を有する短いＤＲＸとの両方をサポートするよう構成されてい得る。長いＤＲＸ３０１は２つのサブ状態（sｕｂ−ｓｔａｔｅｓ）、つまり長いＤＲＸ３１１における覚醒状態と、長いＤＲＸ３１２におけるスリープ状態と、を有する。ＵＥが長いＤＲＸ３１１における覚醒状態にある間、ＵＥはデータ伝送を受信することができる。  ＵＥが長いＤＲＸ３１１における覚醒状態に入るとき、オン持続時間（ｏｎ−ｄｕｒａｔｉｏｎ）タイマーは動作している。通常、ステップ３２１において、オン持続時間タイマーが満了すると、ＵＥは、長いＤＲＸ３１１における覚醒状態から、長いＤＲＸ３１２におけるスリープ状態に変わる。長いＤＲＸ３１２におけるスリープ状態においては、ＵＥはデータ伝送を受信しない。長いＤＲＸサイクルタイマーが満了すると、ステップ３２２において、ＵＥは遷移し、長いＤＲＸ３１１における覚醒状態に戻る。同様に、短いＤＲＸ３０２は２つのサブ状態、つまり短いＤＲＸ３１３における覚醒状態と、短いＤＲＸ３１４におけるスリープ状態とを有する。ＵＥが短いＤＲＸ３１３における覚醒状態にある間、ＵＥはデータ伝送を受信することができる。ＵＥが短いＤＲＸ３１３における覚醒状態に入るとき、オン持続時間タイマーは動作している。通常、ステップ３２４において、オン持続時間タイマーが満了すると、ＵＥは、短いＤＲＸ３１３における覚醒状態から、短いＤＲＸ３１４におけるスリープ状態に変わる。短いＤＲＸ３１４におけるスリープ状態においては、ＵＥはデータ伝送を受信しない。短いＤＲＸサイクルタイマーが満了すると、ステップ３２３において、ＵＥは遷移し、短いＤＲＸ３１３における覚醒状態に戻る。 ステップ３２６において、短いＤＲＸ３１３における覚醒状態においてＵＥがデータ伝送を受信すると、ＵＥは短いＤＲＸ３１３における覚醒状態に引き続きとどまる。
【００２２】
ＵＥは長いＤＲＸ３０１から短いＤＲＸ３０２へ遷移することができ、その逆もまた同じである。ステップ３２５において、データ伝送が開始する。ステップ３２５におけるデータ伝送は、ＵＥをトリガして長いＤＲＸ３０１から短いＤＲＸ３０２へ遷移させる。一方、ＵＥが短いＤＲＸ３０２にあるとき、それは長いＤＲＸ３０１に遷移することができる。ステップ３３４において、短いＤＲＸサイクルタイマーが満了すると、ＵＥは短いＤＲＸ３０２から長いＤＲＸ３０１へ遷移する。あるいは、ステップ３３５において、長いＤＲＸ状態に移ることをＵＥに指示するネットワークコマンドをＵＥが受信すると、ＵＥは短いＤＲＸ３０２から長いＤＲＸ３０１へ遷移する。従来では、システムはデータトラフィックまたはトラフィック条件のタイプを区別しない。よって、ステップ３２５において、あらゆるタイプのデータ伝送が、長いＤＲＸ３０１から短いＤＲＸ３０２へ移るようＵＥをトリガする。本発明の１つの新規な態様において、ＵＥは、バックグラウンドトラフィック、パワーセービングまたは非パワーセービング状態、データトラフィック量、およびその他の条件のような、トラフィック条件を検出する。かかる条件に基づいて、ＵＥは長いＤＲＸ３０１にとどまるこ決定をし得る。例えば、ステップ３３１において、トラフィック条件が、少量のまたは低ＱｏＳデータ伝送を示すとき、ＵＥは、 短いＤＲＸ３０２へ遷移する代わりに、長いＤＲＸ３１１における覚醒状態にとどまる。同様に、ステップ３３２において、ＵＥは、それに長いＤＲＸ３０１にとどまるよう指示するネットワークコマンドを受信し得る。ＵＥは、該コマンドを受信すると、短いＤＲＸ３０２へ遷移する代わりに、長いＤＲＸ３１１における覚醒状態にとどまる。１つの好ましい実施形態において、ステップ３３２におけるネットワークコマンドは、ＵＥから送信されたトラフィック情報に基づくものである。本発明の別の好ましい実施形態では、ネットワークコマンドはＭＡＣ制御要素（ＣＥ）を用いる。あるいは、それはＲＲＣシグナリングにより伝送されてよい。ステップ３３３において、ＵＥは、パワーセービング状態においてデータ伝送が発生することを検出する。このトラフィック条件を検出すると、ＵＥは、短いＤＲＸ３０２へ遷移する代わりに、長いＤＲＸ３１１における覚醒状態にとどまる。ＵＥは、ＵＥの休止−覚醒オペレーションに影響を及ぼし、これによって現在のＤＲＸ状態遷移を動的に変更する他のトラフィック条件を考慮し得る。
【００２３】
図４Ａおよび４Ｂは、動的に調整された長いＤＲＸ状態から短いＤＲＸ状態へのＵＥの遷移の２つの例示的シナリオを示している。通常、ＵＥを短いＤＲＸに移らせるよりもむしろ、ＵＥを長いＤＲＸに保つことの方が、より長いスリープ状態のために、ＵＥのパワーセービングを高め得る。次の長いＤＲＸの伝送の機会まで後続の伝送がバッファリングされるであろう場合に、それはトラフィックシェーピングにより有益となるであろう。長いＤＲＸ状態にとどまることの主な問題は、例えば、ＵＥが高度にインタラクティブなモード（ｈｉｇｈｌｙ ｉｎｔｅｒａｃｔｉｖｅ ｍｏｄｅ）にあるときに、それがユーザー体験に悪影響を与える可能性があるということである。他のシナリオ、例えばバルクデータ伝送、高優先度／重要度のトラフィック、例えばシグナリング無線ベアラ（ＳＲＢ）伝送などは、短いＤＲＸを必要とするであろう。図４Ａおよび４Ｂは、トラフィック条件に基づいてＵＥが長いＤＲＸサイクルにとどまる、または短いＤＲＸサイクルに入る場合のシナリオを示している。
【００２４】
図４Ａは、ＵＥが、データ伝送を受信した後に、検出されたトラフィック条件に基づいて長いＤＲＸ状態にとどまる場合の例示的手順を示している。ＵＥは長いＤＲＸ状態に入る。長いＤＲＸサイクル４０１においては、オン持続時間中に受信されたデータ伝送はない。しかしながら、ＵＥは、トラフィック条件を監視する。長いＤＲＸサイクル４０２のオン持続時間の間、ステップ４１１においてＵＥは物理ダウンリンク制御チャネル（ＰＤＣＣＨ）伝送を受信する。データ伝送を受信すると、ステップ４１２においてＵＥはインアクティビティタイマーを起動する。従来では、タイマーが満了すると、ＵＥは短いＤＲＸ状態に入るであろう。本発明の１実施形態では、ステップ４１３において、ＵＥは、ＵＥまたはデータ伝送が用いていた論理チャネルが非インタラクティブ（ｎｏｎ−ｉｎｔｅｒａｃｔｉｖｅ）またはパワーセービングモードにあることを示すトラフィック条件を検出する。よって、ＵＥは長いＤＲＸ状態にとどまり、長いＤＲＸサイクル４０３に入る。他の検出されるトラフィック条件もまた、長いＤＲＸ状態にとどまるようＵＥに決定させることができる。かかるトラフィック条件の例は、バックグラウンドトラフィック条件、短くかつ非時間依存型のトラフィック、および少ないトラフィック量を含む。
【００２５】
図４Ｂは、ＵＥが、データ伝送を受信した後に、検出されたトラフィック条件に基づいて短いＤＲＸ状態に遷移する場合の例示的手順を示している。長いＤＲＸサイクル４２１において、オン持続時間中に受信されたデータ伝送はない。しかしながら、ＵＥはトラフィック条件を監視する。長いＤＲＸサイクル４２２のオン持続時間の間、ステップ４３１においてＵＥはＰＤＣＣＨ伝送を受信する。データ伝送を受信すると、ステップ４３２においてＵＥはインアクティビティタイマーを起動する。ステップ４３３において、ＵＥは、ＵＥまたはデータ伝送が用いていた論理チャネルのいずれかがインタラクティブまたは非パワーセービングモードにあることを検出する。よって、ＵＥは短いＤＲＸサイクルに遷移し、短いＤＲＸサイクル４２２に入る。短いＤＲＸサイクル４２２におけるオン持続時間の間、ＵＥはデータ伝送を受信しなかった。そして、ＵＥは短いＤＲＸサイクル４２３に入る。短いＤＲＸサイクル４２３におけるオン持続時間の間、ＵＥはデータ伝送を受信しなかった。短いＤＲＸサイクルタイマーが満了すると、ＵＥは長いＤＲＸサイクル４２４に入る。本発明の１実施形態では、データ伝送、および検出された以下のトラフィック条件のうちの少なくとも１つがある場合に、ＵＥは長いＤＲＸ状態から短いＤＲＸ状態に変わる。第１は、データ伝送または伝送のためにバッファリングされたデータが、予め定められたしきい値を超える場合である。本発明の１実施形態において、ＵＬ伝送では、長いＤＲＸから短いＤＲＸへの遷移は、バッファ状態報告（ＢＳＲ）中のバッファ状態レポートに関連し得る。第２の条件は、データ伝送が特定の論理チャネルまたは論理チャネルグループ用のものである場合である。本発明の１実施形態において、論理チャネルは、高優先度のチャネルまたはＳＲＢである。第３の条件は、データ伝送が特定のＵＬまたはＤＬ伝送である場合である。これは、応答が予期される場合に伝送がタイムクリティカルなシグナリング手順であるときの条件である。例えば、イベントトリガ型（ｅｖｅｎｔ ｔｒｉｇｇｅｒｅｄ）測定レポートが送られているとき、ＵＥはそれに応じたネットワーク無線リソース管理（ＲＲＭ）再構成またはハンドオーバーを予期するであろう。第４の条件は、ＵＥまたは論理チャネル／ベアラが非パワーセービングモードにある場合である。
【００２６】
図５は、本発明の１実施形態に従った、長いＤＲＸ状態から短いＤＲＸ状態への動的遷移の例示的フローチャートである。ＵＥ５０１は、無線ネットワークに接続しているｅＮＢ５０２と接続する。ステップ５１１において、ＵＥ５０１は長いＤＲＸ状態に入る。ステップ５１２において、ＵＥ５０２はトラフィック条件を検出する。例示的なトラフィック条件は前のセクションに挙げられている。他のトラフィック条件がＵＥ５０１によって検出可能であるということが、当業者により理解される。よりリアルタイムのデータ伝送、または大量の伝送が、短いＤＲＸ状態に遷移することの必要性を示すであろう一方で、より遅延に耐性のあるトラフィック条件は、長いＤＲＸ状態にとどまることの利点を示すであろう。ＵＥ５０１はこれらトラフィック条件を収集および更新し続ける。ステップ５２１において、データ伝送が検出される。ステップ５１３において、ＵＥ５０１はトラフィック条件情報を収集し、それらを比較する。ＵＥ５０１は、ステップ５１３において、特定のアルゴリズムを実行して、収集した各種トラフィック条件を評価し得る。かかるアルゴリズムは簡単な決定であり得る、または動的に設定され得る。ＵＥ５０１は、継続的に、または周期的に、またはある予め定義されたトリガイベントが起こるときに、すべての収集したトラフィック条件を評価することができる。トラフィック条件を決定すると、予め定義されたトラフィック条件のうちの少なくとも１つが満たされる場合に、ＵＥ５０１は、ステップ５１５において、短いＤＲＸ状態に遷移する。予め定義されたトラフィック条件の組は、予め設定される、および／または動的に更新されるものであってよい。ステップ５１３においてＵＥが予め定義されたトラフィック条件のいずれも検出しない、またはステップ５１３におけるトラフィック条件が遅延耐性トラフィックタイプを示す場合、ステップ５１４においてＵＥ５０１は長いＤＲＸ状態にとどまる。本発明の１実施形態では、ステップ５２２において、ＵＥ５０１はトラフィック条件同期メッセージをネットワークへ送信する。このメッセージは、ネットワークに、現在のＵＥのＤＲＸ状態、ＤＲＸパラメーターの更新および／またはＵＥ５０１によって検出されるその他の関連するトラフィック条件を示すためのものである。ネットワークは、それが受信するトラフィック条件からＵＥの状態を得ること、または明示的状態遷移情報を受信することによって、ＵＥ５０１と同期することができる。同期は、ＵＥ状態の変化もしくはトラフィック条件の変化のようなトリガイベントがあるときになされ得る、または周期的に更新され得る。同期スキームは、設定可能（ｃｏｎｆｉｇｕｒａｂｌｅ）でかつ動的に更新されるものであってよい。
【００２７】
動的ＤＲＸ遷移スキームの別の態様は、インアクティビティタイマーおよび／または短いＤＲＸサイクルタイマーを動的に調整または延長するというものである。図６Ａおよび６Ｂは、トラフィック条件に基づいてインアクティビティタイマーおよび短いＤＲＸサイクルタイマーが延長されるときの、２つの例示的シナリオを示している。２つの図は延長の１つの実施を示しているが、両タイマーは同時に延長可能であることが当業者により理解される。
【００２８】
図６Ａは、本発明の実施形態にしたがい、トラフィック条件が禁止条件が存在しないことを示すときにデータ伝送後インアクティビティタイマーが延長される場合の例示的シナリオを示している。ＵＥは長いＤＲＸサイクル６０１に入る。そのオン持続時間の間、データ伝送はない。次のオン持続時間に、ステップ６１１においてＵＥはＰＤＣＣＨデータ伝送を受信する。ステップ６１２において、ＵＥは、ＵＥまたはデータ伝送が用いていた論理チャネルがインタラクティブまたは非パワーセービングモードにあることを検出する。ＵＥはさらに、検出された禁止条件はないことを検出する。禁止条件は、予め設定された、または動的に更新されるものであってよい。第１の禁止条件は、データ伝送または伝送のためにバッファリングされたデータが予め定められたしきい値を下回る場合である。第２は、データ伝送が高優先度のチャネルまたはＳＲＢのような予め定義された論理チャネルまたは論理チャネルグループのうちの１つではないことである。第３のそれは、データ伝送がＵＬまたはＤＬにおける予め定義された特定の伝送のうちの１つではないことである。第４のそれは、ＵＥまたは６１１データ伝送が用いていた論理チャネルがパワーセービングモードにあることである。ＵＥが全ての条件を満たすと判断すると、ＵＥはステップ６１３においてインアクティビティタイマーを延長する。延長されたインアクティビティタイマーの満了を受けて、ＵＥは短いＤＲＸサイクル６０２に入り、次いで短いＤＲＸサイクル６０３に入る。ステップ６１４において、正規の（ｒｅｇｕｌａｒ）短いＤＲＸサイクルタイマーが満了する。ＵＥは長いＤＲＸサイクル６０４に入る。
【００２９】
図６Ｂは、本発明の実施形態に従って、トラフィック条件が禁止条件が存在しないことを示すときにデータ伝送後短いＤＲＸサイクルタイマーが延長される場合の例示的シナリオを示している。ＵＥは長いＤＲＸサイクル６２１に入る。そのオン持続時間の間、データ伝送はない。次のオン持続時間に、ステップ６３１においてＵＥはＰＤＣＣＨデータ伝送を受信する。ステップ６３３において、ＵＥはインアクティビティタイマーを起動する。インアクティビティタイマーの満了を受けて、ステップ６３２において、ＵＥは、ＵＥまたはデータ伝送が用いていた論理チャネルがインタラクティブまたは非パワーセービングモードにあることを検出する。ＵＥはさらに、検出された禁止条件はないことを検出する。禁止条件は、予め設定された、または動的に更新されたものであってよい。禁止イベントは上に定義したものと同じである。ＵＥが全ての条件を満たすと判断すると、ＵＥは短いＤＲＸサイクルタイマーを延長する。ＵＥは短いＤＲＸサイクル６２２に入り、次いで短いＤＲＸサイクル６２３に入る。短いＤＲＸサイクルタイマーが延長されるため、ＵＥは、短いＤＲＸサイクル６２４に入ることによって短いＤＲＸにより長くとどまる。ステップ６３４において、延長された短いＤＲＸサイクルタイマーが満了する。ＵＥは長いＤＲＸサイクル６２５に入る。
【００３０】
図７は、本発明の実施形態に従って、トラフィック条件に基づきＵＥがＤＲＸインアクティビティタイマーおよび／または短いＤＲＸサイクルタイマーを動的に更新する例示的フローチャートを示している。ＵＥ７０１はｅＮＢ７０２と接続し、それは無線ネットワークに接続している。ステップ７１１において、ＵＥ７０１はトラフィック条件を検出する。ステップ７２１において、ＵＥ７０１はデータ伝送を検出する。ステップ７１２において、ＵＥ７０１はトラフィック条件に基づいてアクションを決定する。例示的トラフィック条件は前のセクションに挙げられている。ＵＥ７０１が他のトラフィック条件を検出可能であるということは、当業者により理解される。ＵＥ７０１はこれらトラフィック条件を収集および更新し続ける。ステップ７１２において、ＵＥ７０１はトラフィック条件情報を収集し、それらを比較する。ＵＥ７０１は、ステップ７１２において、特定のアルゴリズムを実行して、収集した各種トラフィック条件を評価することができる。かかるアルゴリズムは簡単な決定である得る、または動的に設定され得る。トラフィック条件は、継続的に、または周期的に決定され得る、または決定が必要とされるときに決定され得る。トラフィック条件を決定すると、ＵＥ７０１は、ステップ７１３において、ＵＥが覚醒状態により長くとどまるようインアクティビティタイマーおよび／または短いＤＲＸサイクルタイマーを延長する。ステップ７１２においてＵＥ７０１が条件が満たされていないと判断する場合、ステップ７１４においてＵＥ７０１はインアクティビティタイマーまたは短いＤＲＸサイクルタイマーのいずれも延長しない。本発明の１実施形態では、ステップ７２２において、ＵＥ７０１はトラフィック条件同期メッセージをネットワークへ送信する。このメッセージは、ネットワークに、現在のＵＥのＤＲＸ状態、ＤＲＸパラメーターの更新および／またはＵＥ７０１によって検出されるその他の関連するトラフィック条件を示すためのものである。ネットワークは、それが受信するトラフィック条件からＵＥの状態を得ること、または明示的状態遷移情報を受信することによって、ＵＥ７０１と同期することができる。他の同期メッセージも採用され得る。同期は、ＵＥ状態の変化もしくはトラフィック条件の変化のようなトリガイベントがあるときになされ得る、または周期的に更新され得る。同期スキームは、設定可能でかつ動的に更新されるものであってよい。
【００３１】
上に示したように、トラフィック条件が検出される場合に、ＵＥのＤＲＸ状態および／またはＤＲＸパラメータを動的に調整することがＵＥにおいてなされ得る。かかる実施は追加のメッセージを含まず、かつ条件が既知である場合に決定はＵＥに固有である（ｌｏｃａｌ ｔｏ）。しかしながら、このようなスキームは、ＵＥとネットワーク間における同期外れのリスクを有する。上に示したように、ある種の同期が、潜在的な同期外れの問題を解決するために実行されなければならない。ＵＥの動的ＤＲＸ状態遷移を実施する別の方法は、 ネットワークコマンドによるものである。
【００３２】
図８は、本発明の実施形態に従った例示的フローチャートを示しており、ここで、ネットワークコマンドに基づいてＵＥがＤＲＸ状態遷移を実行し、このうちネットワークはＵＥから受信したトラフィック条件に基づいてＤＲＸコマンドを決定する。ＵＥ８０１はｅＮＢ８０２と接続し、それは無線ネットワークに接続している。ステップ８１１において、ＵＥ８０１はトラフィック条件を検出する。トラフィック条件は、ＵＥのパワーセービング／非パワーセービング状態、バックグラウンドトラフィックタイプ、ユーザープレーンアクティビティ、およびその他のトラフィックタイプ、トラフィック条件関連情報を含み得る。トラフィック条件は、予め設定されたものであってよい、または動的に更新されかつＵＥとネットワーク間で同期されるものであってよい。ステップ８２１において、ＵＥ８０１はこれらトラフィック条件をネットワークに送信する。トラフィック条件は、ＵＥ状態の変化もしくはトラフィック条件の変化のようなトリガイベントがあるときに送信され得る、または周期的に更新され得る。トラフィック条件は、遅延耐性、バックグラウンドトラフィック、パワーセービングまたは非パワーセービングデータのようなＵＬデータの特徴に関してネットワークに情報を提供することによるＵＬトラフィックのタギング（ｔａｇｇｉｎｇ）も含み得る。データのコンテキストを識別することによって、ネットワークは、ＵＥのＤＲＸ遷移に関してより良い決定をすることができる。ステップ８１２において、ＵＥ８０１からトラフィック条件を受信すると、ｅＮＢ８０２はＤＲＸコマンドを決定する。本発明の１実施形態では、決定は、ｅＮＢの代わりに、ネットワークにおいてなされる。本発明の他の実施形態では、決定は、他のネットワークエンティティによってなされ得る。ステップ８２２において、ネットワークはＵＥ８０１にＤＲＸコマンドを送信する。ネットワークのＤＲＸコマンドの例は、このデータ伝送の後に長いＤＲＸに移るもしくは長いＤＲＸにとどまる、このデータ伝送の後に予め定められたＤＲＸ設定を用いる、スリープ状態への遷移のために長いもしくは短いもしくは中間のインアクティビティタイマーを用いる、または短いＤＲＸから移行するために長い、短い、中間のインアクティビティタイマーを使用することを含む。本発明の１つの好ましい実施形態において、ＤＲＸコマンドは、例えばＭＡＣヘッダーなどにおいて、ＤＬデータ伝送と共に送信される。コマンドは、データ伝送後に、直接ＤＲＸオペレーションに適用され得る。シグナリングオーバーヘッドは最小になるであろう。本発明の別の好ましい実施形態において、あるＤＲＸアクション設定は予め設定されたものであり、かつコマンドは、それらの予め設定されたコマンドを指すであろう。ステップ８１３において、ネットワークＤＲＸコマンドを受信すると、ＵＥ８０１はそれに応じてＤＲＸ遷移アクションを実行する 。
【００３３】
従来では、ＤＲＸにおけるトラフィックシェーピングはＤＬのみに適用される。本発明のいくつかの好ましい実施形態では、ＵＥは、ＵＬに伝送の休止を適用する。ＵＥは、ＵＬにおいて、ある特定の機会（ｏｃｃａｓｉｏｎｓ） にのみ伝送することが許可される。ＵＬ伝送機会の期間は、最大スケジューリング要求期間より長く設定され得る。上記のようなＵＬ伝送機会の制限は、物理アップリンク制御チャネル（ＰＵＣＣＨ）およびＵＬにおける他の競合ベースの伝送に適用可能であり得る。ＵＬトラフィックシェーピングに関する１つの問題は、ＵＥとネットワークの同期外れの可能性である。ＵＥとネットワーク間の同期外れの問題を回避するため、通信の一方の側がコンテキスト識別を担当し、かつ他のトラフィック条件を検出する。かかる情報は、その後に他方の側にシグナリングされる。例えば、ＵＥは、ＭＡＣヘッダー中に情報要素（ＩＥ）を加えることによってＵＬデータにタグ付けすることができ、このデータが遅延耐性型／バックグラウンドトラフィックか、または非パワーセービングか、または対話型（ｃｏｎｖｅｒｓａｔｉｏｎａｌ）かをネットワークに知らせる。本発明の別の実施形態では、ＵＥは、ＵＬにおけるデータ伝送に情報を含めることによって、論理チャネルまたはＵＥの非パワーセービング／パワーセービング状態を報告する。本発明の別の実施形態では、ネットワークはかかる情報を要求することができ、かつＵＥは、トラフィック情報をネットワークに送信することによって応答し得る。
【００３４】
図９は、本発明の実施形態に従った、ネットワークコマンドによる動的ＤＲＸ遷移の例示的フローチャートである。ステップ９０１において、ＵＥは１つまたはそれ以上のトラフィック条件を検出する。ステップ９０２において、ＵＥはトラフィック条件情報をネットワークに送信する。ステップ９０３において、ＵＥは、トラフィック条件情報に基づくネットワークＤＲＸコマンドに従ってＤＲＸ遷移アクションを実行する。
【００３５】
図１０は、本発明の実施形態に従った、ＵＥにより検出されたトラフィック条件に基づく動的ＤＲＸ遷移の例示的フローチャートである。ステップ１００１において、長いＤＲＸ状態または短いＤＲＸ状態のいずれかにあるＵＥは、無線ネットワークにおいて不連続のＤＲＸまたはＤＴＸを適用する。ステップ１００２において、ＵＥは論理チャネルでデータ伝送を送信または受信する。ステップ１００３において、ＵＥは１つまたはそれ以上のトラフィック条件を検出する。ステップ１００４において、ＵＥはトラフィック条件に基づいてＤＲＸ遷移アクションを実行する。
【００３６】
アイドル−接続遷移（Ｉｄｌｅ−Ｃｏｎｎｅｃｔｅｄ Ｔｒａｎｓｉｔｉｏｎ）
トラフィック条件に基づいてＵＥのＤＲＸ状態遷移および／またはＤＲＸパラメーターを動的に調整することは、ユーザー体験への影響なしにＵＥのバッテリー寿命を向上させる。もう１つのコストのかかるオペレーションは、アイドル状態への遷移である。現在のシステムにおいて、アイドルモード遷移トリガはネットワーク内にあり、アイドルへの遷移をトリガするために明示的シグナリングが起動される。ＲＲＣ解除コマンドを受信するため、ＵＥ ＵＬを同期させるのに、相当量のオーバーヘッドがある。かかるオーバーヘッドは、アイドル遷移トリガが動的に適応可能であり、ＵＥにおけるトラフィック条件を考慮に入れる場合に、減少され得る。
【００３７】
図１１は、本発明の実施形態に従った、動的なＵＥの接続からアイドルへの遷移の例示的フローチャートを示しており、このうちアイドル遷移補助データがＵＥからネットワークへ送信される。ＵＥ１１０１はｅＮＢ１１０２と接続し、それは無線ネットワークに接続している。ステップ１１１１において、ＵＥ１１０１はトラフィック条件を検出する。本発明の１つの好ましい実施形態では、ステップ１１２１において、ＵＥ１１０１はＲＲＣ測定レポートを介してアイドル遷移補助データをネットワークに送信する。補助データは他のメッセージを介してネットワークに送信されてよい。補助データは通常、アクティブに進行している（ａｃｔｉｖｅｌｙ ｏｎｇｏｉｎｇ）トラフィックのトラフィックタイプ、例えばバックグラウンドまたは時間パターン特徴（ｔｉｍｅ ｐａｔｔｅｒｎ ｃｈａｒａｃｔｅｒｉｚａｔｉｏｎ）、ＵＥのパワーセービングまたは非パワーセービング状態、ＵＥの休止／覚醒状態、例えばＤＲＸ覚醒など、伝送または受信状態、および上の情報に関する最近の履歴の情報などを含む。ＵＥの移動速度のようなその他のトラフィック条件情報もまた、該報告に含まれ得る。アイドル遷移補助データは測定レポート伝送時に送信され得る、またはデータをネットワークへ伝送するときに伝送され得る。ステップ１１１２において、ｅＮＢ１１０２は、アイドル遷移補助データを受信すると、ＲＲＣ接続を解除するかどうかを決定する。該決定がネットワークにおける他のエンティティによってなされ得ることが、当業者により理解される。ステップ１１２２において、ネットワークは、受信したアイドル遷移補助データに基づいて、ＲＲＣ解除メッセージをＵＥ１１０１に送信する。ＲＲＣ解除メッセージを受信すると、ＵＥ１１０１はステップ１１１３においてアイドルに移る。
【００３８】
より効率的にＵＥをアイドル状態に移行させるためのもう１つの方法は、ユーザーのインタラクティビティーに依存した異なるアイドル遷移トリガーを適用することである。特に、ＵＥがパワーセービング状態にあるとき、ＵＥは、より遅くではなく、より早くアイドル状態に移る。ユーザーがパワーセービング状態にあるときは、ユーザーはさらなる遅延に気付かないであろうからである。ユーザーのインタラクティビティーは、非パワーセービング状態にあるＵＥとして検出されてよく、かつ伝送が予め定められたしきい値を超えることに基づくものであってよい。
【００３９】
図１２は、本発明の実施形態に従った例示的フローチャートを示しており、このうち、ＵＥはトラフィック条件に基づいてインアクティビティタイマーを起動または再起動する。ＵＥ１２０１はｅＮＢ１２０２と接続し、それは無線ネットワークに接続している。ステップ１２１１において、ＵＥ１２０１はインタラクティブ／非パワーセービング状態に入る。ステップ１２２１において、ＵＥ１２０１はデータ伝送を送信または受信する。ＵＥ１２０１は 、このステップにおいて、その非パワーセービング状態についてネットワークに通知してもよい。ステップ１２１２において、ＵＥ１２０１はインアクティビティタイマーを起動する。アイドル遷移タイマー値は長いものに設定される。アイドル遷移タイマー値は、予め定義されたトラフィック条件のグループのうちの少なくとも１つによって決まる。予め定義されたトラフィック条件は、予め設定された、または動的に更新されるものであってよい。第１のトラフィック条件は、タイマーを起動するデータ伝送のデータ量である。第２のトラフィック条件は、高優先度のチャネルのような、タイマーを起動する伝送のための論理チャネルまたはベアラのタイプである。第３のトラフィック条件は、タイマーを起動するデータ伝送が、ある予め定義された特定のＵＬまたはＤＬのいずれのためのものかということである。第４のトラフィック条件は、ＵＥまたはタイマーを起動するデータ伝送の論理チャネルがパワーセービングまたは非パワーセービング状態のいずれにあるかということである。本発明の１実施形態では、ステップ１２２２において、ＵＥ１２０１はトラフィック条件同期メッセージをネットワークに送信する。次に、ステップ１２１３において、ＵＥ１２０１は非インタラクティブ／パワーセービング状態に入る。ステップ１２２３において、 ＵＥ１２０１データ伝送を送信または受信する。 本発明の１実施形態において、ＵＥ１２０１は、パワーセービング状態についてｅＮＢ１２０２に通知することもできる。ステップ１２１４において、ＵＥ１２０１はインアクティビティタイマーを起動または再起動すると共に、タイマー値を短いものに設定する。本発明の１実施形態では、ステップ１２２４において、ＵＥ１２０１はトラフィック条件同期メッセージをｅＮＢ１２０２に送信する。ステップ１２２５において、インアクティビティタイマーが満了する。ステップ１２１６において、ＵＥ１２０１はアイドル状態に移る。
【００４０】
図１３は、トラフィック条件に基づいてインアクティビティタイマーが再起動されない場合の、本発明の実施形態に従った例示的フローチャートを示している。ＵＥ１３０１はｅＮＢ１３０２に接続され、それは無線ネットワークに接続されている。ステップ１３１１において、ＵＥ１３０１はトラフィック条件を検出する。ステップ１３２１において、ＵＥ１３０１はデータ伝送を送信または受信する。ＵＥ１３０１は、データ伝送を検出すると、データ伝送の量が予め定められたしきい値を上回っていること、データ伝送が特定の予め定義された論理チャネルまたは無線ベアラ用であること、データ伝送が予め定義された特定のアップリンクまたはダウンリンクシグナリング伝送であること、およびＵＥまたは論理チャネルが１つまたはそれ以上の任意のトラフィック条件に基づいて条件付きで非パワーセービング状態にあること、を含む任意の二次的な条件に基づいて、条件付でインアクティビティタイマーを起動／再起動するかどうかを決定する。ステップ１３１２において、ＵＥ１３０１は、ＵＥがより長く接続にとどまってコストのかかる不必要な状態遷移を回避し得るように、インアクティビティタイマーを起動または再起動する。ステップ１３２２において、ＵＥ１３０１はＳＲＢ伝送を受信する。ＳＲＢは制御プレーンアクティビティのためのものであるため、それは将来予測されるＵＥのアクティビティとは関係ない。故に、かかるアクティビティは無視されなければならない。ステップ１３１３において、ＵＥ１３０１は、それを再起動することなく、インアクティビティタイマーを継続させる。特定のイベントがアイドル状態へのＵＥの遷移においてファクターでない（ｎｏｎｅ−ｆａｃｔｏｒ）場合の状況を識別するために、他のトラフィック条件が、予め設定され、または動的に更新され得る。かかるイベントは、一旦設定されると、アイドル状態へのＵＥの移行（ｅｎｔｅｒｉｎｇ）を遅らせることなく、インアクティビティタイマーを動作させ続けることをＵＥに許す。ステップ１３１４において、ＵＥのインアクティビティタイマーが満了する。ステップ１３１５において、ＵＥ１３０１はアイドルに移る。
【００４１】
図１４は、１つまたはそれ以上のトラフィック条件に基づいてＵＥがアイドル状態に遷移する、本発明の実施形態による例示的フローチャートを示している。ステップ１４０１において、ＵＥは、無線ネットワークにおけるＵＥにより、ＵＥアイドルモードトリガ条件を設定する。ステップ１４０２において、ＵＥは１つまたはそれ以上の予め定義されたトラフィック条件を検出する。ステップ１４０３において、ＵＥは、トラフィック条件に基づいてＵＥアイドル遷移アクションを実行する。ステップ１４０４において、トリガ条件が満たされると、ＵＥはアイドルモードへ遷移する。
【００４２】
ＲＬＦおよび測定レポートのトリガ
ＵＥのトラフィック条件を考慮することによって、ＤＲＸ状態遷移およびアイドル状態遷移においてユーザー体験に影響を及ぼすことなく、ＵＥはより効率的となり得る。他の問題点は、モビリティ測定レポートおよび無線リンク障害のトリガに関するものである。モビリティ測定パフォーマンスは、ＤＲＸサイクルだけではなく、ユーザープレーンに基づいたものでなければならない。ユーザープレーンのアクティビティがより高くなると、ＵＥがよりアクティブになるために、ＵＥによってより多くの測定がなされなければならない。ＵＥがデータを送信もしくは受信していない、またはバックグラウンドトラフィックだけを送信もしくは受信しているとき、ＵＥは、ＵＥがＤＲＸサイクルにおいていつ覚醒（起動）するかを測定することができる。しかしながら、短いＤＲＸまたはインアクティビティタイマーが動作中であるときのように、データ伝送のためにＵＥがアクティブであるとき、ＵＥは追加のモビリティ測定もしなければならない。このことは、ユーザーがインタラクティブであり、かつＵＥをアクティブに使用しているときに、ＵＥのモビリティ測定パフォーマンスを向上する。このことは、コストのかかるバッテリー消費なしに、良好なエンドユーザーのＱｏＳを促進する。ＵＥがディープスリープ状態にあるとき、モビリティ測定パフォーマンスは低下するであろう。しかしながら、この場合、ユーザーはＵＥを使っていないため、それに気付かないだろう。
【００４３】
モビリティ測定に加え、ＵＥはＲＬＦの宣言にあたりＵＥのトラフィック条件を考慮しなければならない。その際に、ＵＥは早過ぎるＲＬＦを回避することができ、最終的に、失敗したＲＲＣ再確立に続くＮＡＳ回復を回避することができる。よってそれは、旧セルにより長くとどまることに対し、有益である。しかしながら、かかるアプローチはコンテキストセンシティブである必要があり、かつユーザーＱｏＳの影響がある場合には旧セルの長時間のサーチはなされるべきではない。例えば、ＵＥが非パワーセービング状態にある場合、ＵＥは最良のセルをサーチすると共に、再接続してＱｏＳを確保しなければならない。
【００４４】
図１５は、ユーザープレーンアクティビティに基づいてＵＥが測定レポートを送信する場合の、本発明に従った例示的フローチャートを示している。ＵＥ１５０１はｅＮＢ１５０２に接続され、それは無線ネットワークに接続されている。ステップ１５２１において、ＵＥ１５０１はＲＲＣ ＣＯＮＮＥＣＴＥＤ状態に入る。ステップ１５１１において、ＵＥ１５０１は非インタラクティブ／パワーセービング状態を検出する。ステップ１５２２において、イベント条件が満たされ、かつ測定レポートタイマー（ＴＴＴタイマー）が起動される。ステップ１５１２において、ＵＥ１５０１はユーザープレーンアクティビティを検出する。一旦ユーザープレーンアクティビティが検出されると、ＴＴＴタイマーが満了でなくても、ステップ１５２３においてＵＥ１５０１は測定レポートをｅＮＢ１５０２に送信する。ステップ１５１３において、ＵＥ１５０１は、ＲＬＦパラメーターを動的に更新するのに用いられ得るトラフィック条件を検出する。第１のトラフィック条件は、長いＤＲＸ非アクティブ状態、短いＤＲＸ非アクティブ状態およびＤＲＸアクティブ状態を含むＤＲＸ状態であり、ここでＤＲＸアクティブ状態とはデータ伝送が進行中であることを意味する。第２のトラフィック条件はパワーセービング／非パワーセービング状態である。第３のトラフィック条件は、測定レポート送達の成功である。他のトラフィック条件は、ネットワークによる設定または動的な更新に基づいて追跡され得る。予め定義されたトラフィック条件のうちの１つまたはそれ以上を検出すると、ＵＥ１５０１はＲＬＦパラメーターを動的に調整する。例えば、ＵＥ１５０１が非インタラクティブ／パワーセービング状態にあることを検出すると、ＲＬＦタイマーは、ＲＬＦを後に発生させるよう適応的に調整され得る。例えば、ＬＴＥ Ｎ３１０は増加し、ＬＴＥ Ｎ３１１は減少し、かつＬＴＥ Ｔ３１０は増加し得る。ステップ１５１４において、ＵＥ１５０１は無線の悪条件を検出する。ステップ１５２４において、ＵＥ１５０１はＴ３１０タイマーを起動する。しかしながら、Ｔ３１０の値は適応型（ａｄａｐｔｉｖｅ）Ｔ３１０タイマー値である。適応型タイマー値は、少なくとも部分的に、ＵＥ１５０１により検出されるトラフィック条件に基づくものである。ステップ１５２５において、ＵＥ１５０１は測定レポートを送信すると共に、Ｔ３１０Ａタイマーを起動する。しかしながら、Ｔ３１０Ａの値は適応型Ｔ３１０Ａタイマー値である。適応型タイマー値は、少なくとも部分的に、ＵＥ１５０１により検出されるトラフィック条件に基づくものである。Ｎ３１０およびＮ３１１のような他のＲＬＦパラメーターも、トラフィック条件に基づいて動的に更新され得る。適応型ＲＦＬパラメーターは、予め設定され、かつＵＥとネットワーク間で同期され得る。本発明の１実施形態において、ある同期メッセージがＵＥ１５０１からｅＮＢ１５０２に送信されて、トラフィック条件および他の状態の変化およびパラメーターの変化が同期される。
【００４５】
図１６は、検出されたトラフィック条件に基づいてＴＴＴタイマーが満了する前にＵＥが測定レポートをトリガする場合の、本発明の実施形態による例示的フローチャートを示している。ＵＥ１６０１はｅＮＢ１６０２に接続し、それは無線ネットワークに接続している。ステップ１６２１において、ＵＥ１６０１はＲＲＣ測定構成メッセージ（ｍｅａｓｕｒｅｍｅｎｔ ｃｏｎｆｉｇｕｒａｔｉｏｎ ｍｅｓｓａｇｅ）を受信する。ステップ１６１１において、ＵＥ１６０１はトラフィック条件を検出する。ステップ１６１２において、ＵＥ１６０１はアクティブ状態または短いＤＲＸ状態に入る。ステップ１６１３において、ＵＥ１６０１は、測定イベント移行条件（ｍｅａｓｕｒｅｍｅｎｔ ｃｏｎｆｉｇｕｒａｔｉｏｎ ｅｎｔｅｒｉｎｇ ｃｏｎｄｉｔｉｏｎ）が満たされ、かつＴＴＴフィルタリングがなされたと判断する。ステップ１６１４において、ＵＥ１６０１は非アクティブまたは長いＤＲＸ状態に遷移する。次に、ステップ１６２２において、ＵＥ１６０１はＲＲＣ測定レポートをｅＮＢ１６０２に送信する。測定レポートを受信すると、ステップ１６１５においてｅＮＢ１６０２はＲＲＣ再確立のため他のセルを準備する。ステップ１６１６において、ＵＥ１６０１は、ハンドオーバー測定レポートが送信される前に、ＲＬＦを宣言する。
【００４６】
図１７は、トラフィック条件に基づいてＵＥがＲＬＦをトリガする場合の、本発明の実施形態に従った例示的フローチャートである。ステップ１７０１において、ＵＥはＲＲＣ接続を確立する。ステップ１７０２において、ＵＥは１つまたはそれ以上の予め定義されたトラフィック条件を検出する。ステップ１７０３において、ＵＥはＲＲＣ接続の物理層の問題を検出する。ステップ１７０４において、ＵＥは、予め定義されたトラフィック条件に基づいて、無線リンク障害トリガパラメータ（ｒａｄｉｏ ｌｉｎｋ ｆａｉｌｕｒｅ ｔｒｉｇｇｅｒｉｎｇ ｐａｒａｍｅｔｅｒｓ）を適応的に調整する。
【００４７】
説明の目的で、特定の実施形態と関連して本発明が記載されているが、本発明はこれらに限定されない。したがって、特許請求の範囲に記載された本発明の範囲を逸脱することなく、これら記載された実施形態の各種変更、調節（ａｄａｐｔａｔｉｏｎ）、および各種特徴の組み合わせが実施可能である。
【符号の説明】
【００４８】
１０１  ＵＥ
１０２  ｅＮＢ
２０１  アンテナ
２１１  ＲＦ送受信機モジュール
２１２  プロセッサ
２１３  メモリ
５０１  ＵＥ
５０２  ｅＮＢ
７０１  ＵＥ
７０２  ｅＮＢ
８０１  ＵＥ
８０２  ｅＮＢ
１１０１  ＵＥ
１１０２  ｅＮＢ
１２０１  ＵＥ
１２０２  ｅＮＢ
１３０１  ＵＥ
１３０２  ｅＮＢ
１５０１  ＵＥ
１５０２  ｅＮＢ
１６０１  ＵＥ
１６０２  ｅＮＢ
【図１】
0006279551.tif 000002
【図２】
0006279551.tif 000003
【図３】
0006279551.tif 000004
【図４Ａ】
0006279551.tif 000005
【図４Ｂ】
0006279551.tif 000006
【図５】
0006279551.tif 000007
【図６Ａ】
0006279551.tif 000008
【図６Ｂ】
0006279551.tif 000009
【図７】
0006279551.tif 000010
【図８】
0006279551.tif 000011
【図９】
0006279551.tif 000012
【図１０】
0006279551.tif 000013
【図１１】
0006279551.tif 000014
【図１２】
0006279551.tif 000015
【図１３】
0006279551.tif 000016
【図１４】
0006279551.tif 000017
【図１５】
0006279551.tif 000018
【図１６】
0006279551.tif 000019
【図１７】
0006279551.tif 000020