JP7431991B2 - 制御チャネルの監視なしのデータ受信 - Google Patents

Description

ユーザ機器（ＵＥ）は、ネットワーク（例えば、ロングタームエボリューション（ＬＴＥ）ネットワーク、５Ｇ新無線（ＮＲ）ネットワークなど）に接続することができる。ネットワークに接続されると、ＵＥは、ＵＥ上で実行中の様々なアプリケーションに関連するネットワークからのデータを受信することができる。場合によっては、このデータは、音声又はビデオリアルタイムＨＴＴＰトラフィックであり得る。実際、現在、４０％～５０％のセルラーデータトラフィックがこのタイプのトラフィックであると推定され、より多くのユーザがオーディオコンテンツ及びビデオコンテンツをモバイルデバイスにストリーミングするにつれて、数が経時的に増大すると推定される。

このトラフィックをサポートするために、ＵＥは、新しいデータの到着を予想してチャネルを維持するために電力を連続的に使用している。具体的には、ＵＥは、物理ダウンリンク制御チャネル（ＰＤＣＣＨ）を監視し、ＤＬトラフィックがネットワークによって送信されている時を判定しなければならない。ＤＲＸ（不連続受信）などの節電を試みるために開発されてきたいくつかの技法がある。しかし、これらの技法は、ストリーミング動作中のＵＥのバッテリ寿命を有意な量まで拡張していない。加えて、ＵＥがより大きな周波数範囲を監視しなければならないことになるため、５Ｇ ＮＲでは、これらの動作中に消費電力が大幅に増えることが予想される。

いくつかの例示的な実施形態によれば、方法は、ネットワークに接続されたユーザ機器（ＵＥ）によって実行される。方法は、ネットワークからデータを受信するアプリケーションを実行することと、ＵＥ支援情報をネットワークに伝送することであって、ＵＥ支援情報はアプリケーションのためにネットワークから受信されるデータのトラフィックパターンに対応していることと、無線リソース制御（ＲＲＣ）非アクティブ状態に入ることと、ＲＲＣ非アクティブ状態中にネットワークからデータを受信することと、を含む。

更なる例示的な実施形態は、送受信機及びプロセッサを有するユーザ機器（ＵＥ）を備える。送受信機は、ネットワークと通信するように構成されている。プロセッサは、ネットワークからデータを受信するアプリケーションを実行することと、ＵＥ支援情報をネットワークに伝送することであって、ＵＥ支援情報は、アプリケーションのためにネットワークから受信されるデータのトラフィックパターンに対応していることと、無線リソース制御（ＲＲＣ）非アクティブ状態に入ることと、ＲＲＣ非アクティブ状態中にネットワークからデータを受信することとを含む動作を実行するように構成されている。

更なる例示的な実施形態は、ＵＥ支援情報をネットワークに伝送するように構成された回路であって、ＵＥ支援情報は、アプリケーションのためにネットワークから受信されるデータのトラフィックパターンに対応している回路と、無線リソース制御（ＲＲＣ）非アクティブ状態に入るように構成された回路と、ＲＲＣ非アクティブ状態にある間にネットワークからデータを受信するように構成された回路と、を有する集積回路を含む。

様々な例示的な実施形態による例示的なネットワーク配置（network arrangement）を示す図である。 様々な例示的な実施形態による例示的なＵＥを示す。 データトラフィックパターンと、当該トラフィックパターンに使用される現在のＰＤＣＣＨ監視を示す。 様々な例示的な実施形態による、ＵＥがＲＲＣ非アクティブ状態でネットワークからＤＬトラフィックを受信することを可能にする第１の例示的なシグナリング図を示す。 様々な例示的な実施形態による、ＵＥがＲＲＣ非アクティブ状態でネットワークからＤＬトラフィックを受信することを可能にする第２の例示的なシグナリング図を示す。 様々な例示的な実施形態による、ＵＥがＲＲＣ非アクティブ状態でネットワークからＤＬトラフィックを受信することを可能にする第３の例示的なシグナリング図を示す。 様々な例示的な実施形態による、ＵＥがＲＲＣ非アクティブ状態でネットワークからＤＬトラフィックを受信することを可能にする第４の例示的なシグナリング図を示す。 様々な例示的な実施形態による、ＵＥがＲＲＣ非アクティブ状態でネットワークからＤＬトラフィックを受信することを可能にする第５の例示的なシグナリング図を示す。 様々な例示的な実施形態による、ＵＥがＲＲＣ非アクティブ状態でネットワークからＤＬトラフィックを受信することを可能にする第６の例示的なシグナリング図を示す。

例示的な実施形態は、以下の説明及び関係する添付の図面を参照して更に理解することができ、同様の要素は、同じ参照番号が付されている。例示的な実施形態は、物理ダウンリンク制御チャネル（ＰＤＣＣＨ）を監視する必要なしにネットワークからデータを受信することに関する。より具体的には、例示的な実施形態は、ＤＬデータを受信するときにＵＥをＲＲＣ非アクティブ状態のままにすることが可能になる。ＵＥはＲＲＣ非アクティブ状態のままになるため、ＵＥはＰＤＣＣＨを監視する必要はないので、監視に関連付けられた電力を節約する。

本明細書全体を通して、「ＤＬデータ」及び「ストリーミングデータ」という用語は、ネットワークからＵＥに送信されているデータを指すために交換可能的に使用される。例示的な実施形態は、オーディオ及び／又はビデオストリーミングデータに関して説明されているが、当業者であれば、例示的な実施形態が任意のタイプのデータのダウンリンク（ＤＬ）中に使用され得ることを理解するであろう。以下でより詳細に説明するように、例示的な実施形態は、ＤＬデータトラフィックパターンが概して予測可能であるときに使用され得る。

加えて、本明細書全体を通して、例示的な実施形態は、ダウンリンク（ＤＬ）データ、例えば、ネットワークからＵＥに送信されるデータを参照して説明される。しかし、当業者であれば、例示的な実施形態がアップリンク（ＵＬ）、例えば、ＵＥからネットワークに送信されるデータにも適用され得ることを理解するであろう。当業者であれば、例示的な実施形態をＵＬに実装するための変形を理解するであろう。

例示的な実施形態は、ＵＥに関して説明されている。しかし、ＵＥの使用は、単に例示目的で提供されているにすぎない。例示的な実施形態は、ネットワークと情報（例えば、制御情報）及び／又はデータをやりとりするためのハードウェア、ソフトウェア、及び／又はファームウェアで構成されている任意の電子コンポーネントと共に使用されてもよい。したがって、本明細書に記載されるＵＥは、任意の好適な電子デバイスを表すために使用される。

加えて、例示的な実施形態は、ＬＴＥ又は５Ｇ ＮＲネットワークであるネットワークを参照して説明される。しかし、例示的な実施形態は、ＬＴＥ及び／又は５Ｇ ＮＲネットワークについて本明細書に記載する動作の原理に従って、任意のネットワーク（セルラー又は非セルラ）で実装され得ることを理解されたい。

また、例示的な実施形態は、ＰＤＣＣＨに関しても説明されている。ＬＴＥ及び５Ｇ ＮＲでは、ＰＤＣＣＨは、ネットワークからＵＥにダウンリンク制御情報（ＤＣＩ）を搬送する。例えば、ＰＤＣＣＨは、いつ（時間）及びどこで（周波数）ＤＬトラフィックがＵＥに送信されているかを理解するための情報をＵＥに提供する。例示的な実施形態がＬＴＥ及び／又は５Ｇネットワークを参照して説明されているときに、ＰＤＣＣＨという用語が使用されることを理解されたい。他のタイプのネットワークは、異なる名称によって説明される同様の概念を有し得る。例示的な実施形態の文脈において、ＰＤＣＣＨの監視は、ＤＬデータに関して排除されているか、又は大幅に低減されている。

図１は、様々な例示的な実施形態による例示的なネットワーク配置１００を示す。例示的なネットワーク配置１００はＵＥ１１０を含む。当業者であれば、ＵＥ１１０が、ネットワークを介して通信するように構成された任意のタイプの電子コンポーネント、例えば、接続された車のコンポーネント、携帯電話、タブレットコンピュータ、スマートフォン、ファブレット、埋め込みデバイス、ウェアラブル、ＩｏＴ（Internet of Things）デバイスなどであってもよいことを理解するであろう。また、実際のネットワーク配置は、任意の数のユーザによって使用されている任意の数のＵＥを含み得ることを理解されたい。したがって、一つのＵＥ１１０の例は、単に例示目的で提供されているにすぎない。

ＵＥ１１０は、１つ以上のネットワークと直接通信することができる。ネットワーク構成１００の例では、ＵＥ１１０が無線通信し得るネットワークは、５Ｇ ＮＲ無線アクセスネットワーク（５Ｇ ＮＲ－ＲＡＮ）１２０、ＬＴＥ無線アクセスネットワーク（ＬＴＥ－ＲＡＮ）１２２及び無線ローカルアクセスネットワーク（ＷＬＡＮ）１２４である。ＵＥ１１０はまた、他のタイプのネットワークと通信してもよく、ＵＥ１１０はまた、有線接続を介してネットワークと通信してもよい。したがって、ＵＥ１１０は、５Ｇ ＮＲ－ＲＡＮ１２０と通信するために５Ｇ ＮＲチップセットを含んでもよく、ＬＴＥ－ＲＡＮ１２２と通信するためにＬＴＥチップセットを含んでもよく、及びＷＬＡＮ１２４と通信するためにＩＳＭチップセットを含んでもよい。

５Ｇ ＮＲ－ＲＡＮ１２０及びＬＴＥ－ＲＡＮ１２２は、セルラープロバイダ（例えば、Ｖｅｒｉｚｏｎ、ＡＴ＆Ｔ、Ｓｐｒｉｎｔ、Ｔ－Ｍｏｂｉｌｅなど）によって配備され得るセルラーネットワークの一部であってもよい。これらのネットワーク１２０、１２２は、例えば、適切なセルラーチップセットを備えるＵＥからトラフィックを送受信するように構成されているセル又は基地局（ＮｏｄｅＢ、ｅＮｏｄｅＢ、ＨｅＮＢ、ｅＮＢＳ、ｇＮＢ、ｇＮｏｄｅＢ、マクロセル、マイクロセル、スモールセル、フェムトセルなど）を含んでもよい。ＷＬＡＮ１２４は、任意のタイプの無線ローカルエリアネットワーク（ＷｉＦｉ、ホットスポット、ＩＥＥＥ ８０２．１１ｘネットワークなど）を含んでもよい。

ＵＥ１１０は、ｇＮＢ１２０Ａを介して５Ｇ ＮＲ－ＲＡＮに接続することができる。ｇＮＢ１２０Ａは、マッシブマイモ（multiple in multiple out、ＭＩＭＯ）機能を実行するために必要なハードウェア（例えば、アンテナアレイ）、ソフトウェア、及び／又はファームウェアで構成されてもよい。マッシブＭＩＭＯとは、複数のＵＥについて複数のビームを生成するように構成されている基地局を指し得る。単一のｇＮＢ１２０Ａへの言及は単に例示のためである。例示的な実施形態は、任意の適切な数のｇＮＢに適用されてもよい。ＵＥ１１０はまた、ｅＮＢ１２２Ａを介してＬＴＥ－ＲＡＮ１２２に接続することができる。

当業者であれば、ＵＥ１１０が５Ｇ ＮＲ－ＲＡＮ１２０及びＬＴＥ－ＲＡＮ１２２に接続するために、任意の関連付け手順が実行され得ることが理解されよう。例えば、上記のように、５Ｇ ＮＲ－ＲＡＮ１２０及びＬＴＥ－ＲＡＮ１２２は、ＵＥ１１０及び／又はそのユーザが（例えば、ＳＩＭカード上に記憶された）契約情報及び認証情報を有する特定のセルラープロバイダに関連付けられてもよい。５Ｇ ＮＲ－ＲＡＮ１２０の存在を検出すると、ＵＥ１１０は、５Ｇ ＮＲ－ＲＡＮ１２０と関連付けるために、対応する認証情報を伝送してもよい。より具体的には、ＵＥ１１０は、特定の基地局（例えば、５Ｇ ＮＲ－ＲＡＮ１２０のｇＮＢ１２０Ａ、ＬＴＥ－ＲＡＮ１２２のｅＮＢ１２２Ａ）に関連付けられてもよい。

ネットワーク１２０、１２２及び１２４に加えて、ネットワーク配置１００はまた、セルラーコアネットワーク１３０、インターネット１４０、ＩＰマルチメディアサブシステム（IP Multimedia Subsystem、ＩＭＳ）１５０、及びネットワークサービスバックボーン１６０を含む。セルラーコアネットワーク１３０は、セルラーネットワークの動作及びトラフィックを管理するコンポーネントからなる相互接続されたセットであると考えることができる。セルラーコアネットワーク１３０はまた、セルラーネットワークとインターネット１４０との間を流れるトラフィックを管理する。ＩＭＳ１５０は、一般に、ＩＰプロトコルを使用してマルチメディアサービスをＵＥ１１０に配信するためのアーキテクチャとして説明され得る。ＩＭＳ１５０は、セルラーコアネットワーク１３０及びインターネット１４０と通信し、マルチメディアサービスをＵＥ１１０に提供することができる。ネットワークサービスバックボーン１６０は、インターネット１４０及びセルラーコアネットワーク１３０と直接的又は間接的に通信する。ネットワークサービスバックボーン１６０は、一般に、様々なネットワークと通信するＵＥ１１０の機能を拡張するために使用され得るサービスの一式を実装するコンポーネント（例えば、サーバ、ネットワーク記憶装置（network storage arrangement）など）からなるセットとして説明され得る。

ＵＥ１１０は、複数の異なる動作状態のうちの１つにあるように構成され得る。１つの動作状態はＲＲＣアイドル状態として特徴付けられてもよく、別の動作状態はＲＲＣ非アクティブ状態として特徴付けられてもよく、また別の動作状態はＲＲＣ接続状態として特徴付けられてもよい。ＲＲＣは、無線リソース制御（ＲＲＣ）プロトコルを指す。当業者であれば、ＵＥ１１０がＲＲＣ接続状態にある場合に、ＵＥ１１０並びに５Ｇ ＮＲ－ＲＡＮ１２０及び／又はＬＴＥ－ＲＡＮ１２２が、情報及び／又はデータをやりとりするように構成され得ることを理解するであろう。情報及び／又はデータのやりとりは、ＵＥ１１０がネットワーク接続を介して利用可能な機能を実行することを可能にし得る。さらに、当業者であれば、ＵＥ１１０がＲＲＣアイドル状態にある場合に、ＵＥ１１０が一般に、ネットワークによりデータをやりとりせずに、無線リソースがネットワーク内のＵＥ１１０に割り当てられていないことを理解するであろう。ＲＲＣ非アクティブ状態では、ＵＥ１１０は、シグナリング及び電力消費を最小限に抑えながらＲＲＣ接続を維持する。しかし、ＵＥ１１０がＲＲＣアイドル状態又はＲＲＣ非アクティブ状態にある場合には、ＵＥ１１０は、ネットワークによって伝送される情報及び／又はデータを監視することができる。本明細書全体を通して、これらの用語は、一般に、ＵＥ１１０が任意のネットワークに接続された時の状態、また、ＲＲＣアイドル、ＲＲＣ接続、及びＲＲＣ非アクティブ状態について上述した特性を呈する状態を説明するために使用されている。以下でより詳細に説明するように、例示的な実施形態は、ＵＥ１１０がＲＲＣ非アクティブ状態にあるときにＤＬトラフィックを受信することを可能にし得る。

図２は、様々な例示的な実施形態による例示的なＵＥ１１０を示す。図１のネットワーク配置１００に関して、ＵＥ１１０について説明する。ＵＥ１１０は、プロセッサ２０５、メモリ配置（memory arrangement）２１０、表示デバイス２１５、入力／出力（Input/Output、Ｉ／Ｏ）デバイス２２０、送受信機２２５、及び他のコンポーネント２３０を含み得る。他のコンポーネント２３０は、例えば、ＳＩＭカード、埋込型ＳＩＭ（ｅＳＩＭ）、オーディオ入力デバイス、オーディオ出力デバイス、電源、データ取得デバイス、ＵＥ１１０を他の電子デバイスに電気的に接続するためのポートなどを含み得る。

プロセッサ２０５は、ＵＥ１１０の複数のエンジンを実行するように構成され得る。例えば、エンジンは、ＤＬトラフィックエンジン２３５を含み得る。ＤＬトラフィックエンジン２３５は、ネットワークとＤＬトラフィックをコーディネート（coordinate）するために使用され得、ＵＥ１１０をＲＲＣ非アクティブ状態のままにさせ、ＰＤＣＣＨを監視せずにＤＬトラフィックを受信することを可能にする。ＵＥ１１０と、ＲＲＣ非アクティブ状態中にＵＥ１１０がＤＬトラフィックを受信することを容易にするネットワーク（５Ｇ ＮＲ－ＲＡＮ１２０又はＬＴＥ－ＲＡＮ１２２）との間の様々な例示的なシグナリングを説明するために、複数のシグナリング図が以下に提供される。シグナリングの一部として、ＵＥ支援情報をネットワークに提供し、ＵＥ１１０（例えば、ＤＬトラフィックエンジン２３５）は、ＵＥ１１０がＲＲＣ非アクティブ状態でＤＬデータを受信できるように、ダウンロード用のＤＬデータをフォーマット化する際にネットワークを支援することができる。シグナリング図を説明するにあたって、ＵＥ支援情報を、以下でより詳細に説明する。

プロセッサ２０５によって実行されるアプリケーション（例えばプログラム）である上記のエンジンはそれぞれ、例示に過ぎない。エンジンに関連付けられた機能はまた、ＵＥ１１０の別個の内蔵コンポーネントとして表されてもよいし、又はＵＥ１１０に結合されたモジュラーコンポーネント、例えば、ファームウェアを有する集積回路若しくは有さない集積回路であってもよい。例えば、集積回路は、信号を受信するための入力回路と、信号及び他の情報を処理するための処理回路と、を含み得る。エンジンはまた、１つのアプリケーション又は別個のアプリケーションとして具現化されてもよい。加えて、いくつかのＵＥにおいて、プロセッサ２０５について説明されている機能は、ベースバンドプロセッサ及びアプリケーションプロセッサなどの２つ以上のプロセッサ間で分割されている。例示的な実施形態は、ＵＥのこれらの構成又は他の構成のうちのいずれかで実装されてもよい。

メモリ配置２１０は、ＵＥ１１０によって実行される動作に関するデータを記憶するように構成されたハードウェアコンポーネントであってもよい。表示デバイス２１５は、データをユーザに示すように構成されたハードウェアコンポーネントであってもよく、Ｉ／Ｏデバイス２２０は、ユーザが入力を行うことを可能にするハードウェアコンポーネントであってもよい。表示デバイス２１５及びＩ／Ｏデバイス２２０は、別個のコンポーネントであってもよく、又はタッチスクリーンのように一緒に一体化されてもよい。送受信機２２５は、５Ｇ ＮＲ－ＲＡＮ１２０、ＷＬＡＮ１２２などとの接続を確立するように構成されたハードウェアコンポーネントであってもよい。したがって、送受信機２２５は、様々な異なる周波数又はチャネル（例えば、連続周波数のセット）で動作することができる。

図３は、データトラフィックパターン３００及び、当該トラフィックパターンに使用される現在のＰＤＣＣＨ監視３４０の例を示す。上記のように、このデータトラフィックパターンは、ＵＥ１１０にストリーミングされているオーディオデータ及び／又はビデオデータの例である。しかし、上記のように、例示的な実施形態は、このタイプのデータに限定されない。図３の上部グラフ３００は、グラフ３００の領域３１０に示すように、バッファリング目的で最初に大きなダウンロードがあることを示している。次いで、データは、無線状態に基づいた所定のパターンでダウンロードされる。このトラフィックパターンは典型的には、短時間のデータバーストであり、その後、何らデータが伝送されない時間が伴う。データバーストは様々な特性を有し得る。例えば、第１のセットのデータバースト３２０は、最長持続時間データバーストである。データバースト３３０は、データ量に関しては、ピークデータバーストである。データバーストの残りは、持続時間及びデータの量に関して変化する。

下部グラフ３４０は、ＲＲＣ接続状態中にデータをダウンロードする従来の方法でのＰＤＣＣＨの監視を示す。この下部グラフ３４０から分かるように、ＤＲＸが使用されても、ＵＥ１１０はＰＤＣＣＨを絶えず監視しているので、大量の電力を使用する。対照的に、例示的な実施形態は、ＤＬデータを受信する際に、ＵＥ１１０がＰＤＣＣＨを監視する必要性を最小限に抑える。例えば、ＵＥ１１０がＲＲＣ非アクティブ状態にあるとき（ＵＥ１１０がＤＬデータを受信しているか、又はＤＬデータを受信していないかにかかわらず）、ＵＥ１１０は、ＰＤＣＣＨを監視していない。ＰＤＣＣＨを監視する時間を短縮することにより、ＵＥ１１０は、この監視に関連付けられた電力消費を低減させている。

図４は、様々な例示的な実施形態による、ＵＥ１１０がＲＲＣ非アクティブ状態でネットワーク４０５からＤＬトラフィックを受信することを可能にする第１の例示的なシグナリング図４００を示す。図４のシグナリング図４００では、ネットワーク４０５は、５Ｇ ＮＲ－ＲＡＮ１２０又はＬＴＥ－ＲＡＮ１２２のいずれかであると考えることができ、また、ＵＥ１１０は、ｇＮＢ１２０Ａ又はｅＮＢ１２２Ａのうち１つに接続され得る。図４を参照して説明された例示的な実施形態では、ＵＥ支援情報は、ネットワーク４０５とＵＥ１１０との間で実行されるランダムアクセスチャネル（ＲＡＣＨ）手順中にネットワーク４０５に提供される。

ＵＥ１１０は、最初はＲＲＣ非アクティブ状態４１０にあると考えることができる。以下で説明するように、ＵＥ１１０は、この状態にあるときにＤＬトラフィックを受信することができる。ネットワーク４０５は、ページ４２０をＵＥ１１０に送信する。ページ４１０は、指定されたアクション、例えば、ネットワーク４０５は、ＵＥ１１０に対する音声呼び出しを行った、ＵＥ１１０はスケジューリング要求（ＳＲ）をネットワーク４０５に送信したこと等に応答して送信され得、又は所定のスケジュールされた時間に送信され得る。ネットワーク４０５は、ＵＥ１１０がＲＲＣ非アクティブ状態にあるときにＤＬデータが送信されていることを理解するために、ネットワーク４０５は、ＵＥ１１０に、ＲＲＣ接続状態に入るように定期的に要求して、ＲＲＣ非アクティブ状態中にＤＬデータを配信するためのパラメータ（例えば、ＵＥ支援情報）が正しいことを保証にすることができる。ＵＥ支援情報及びＵＥ支援情報をネットワーク４０５に提供する方法は、以下でより詳細に論じる。

ページ４１０に応答して、ＵＥ１１０は、ＲＡＣＨ要求４３０をネットワーク４０５に送信する。ＲＡＣＨ要求４３０は、ＵＥ１１０からの要求であり、ネットワーク４０５とのＲＲＣ接続状態を確立する。当業者であれば、通常ＲＡＣＨ要求４３０で提供される情報を理解するであろう。しかし、ＲＡＣＨ要求４３０で通常提供される情報に加えて、ＵＥ１１０がＲＲＣ非アクティブ状態に遷移したときにネットワーク４０５がデータをＵＥ１１０に継続してストリーミングすることを可能にするために、追加情報をネットワーク４０５に提供することができる。この追加情報は、本明細書全体を通してＵＥ支援情報と称される。ＵＥ支援情報は、ＤＬデータのためのトラフィックパターンの特性を説明するデータのセットである。上記のように、例示的な実施形態は、ＵＥ１１０がＲＲＣ非アクティブ状態にあるときにＤＬデータを伝送するネットワーク４０５を対象とする。これらの伝送が成功するためには、ネットワーク４０５は、ＵＥ１１０が期待するＤＬデータの伝送方法でＤＬデータを伝送するべきである。ＵＥ１１０は、ＵＥ１１０上で実行されている特定のアプリケーションのトラフィックパターン、例えば、図３のグラフ３００に示されるストリーミングアプリケーションのための例示的なトラフィックパターンを理解するであろう。次いで、ＵＥ１１０は、既知のトラフィックパターンに対応するＵＥ支援情報をネットワーク４０５に提供することができ、ネットワーク４０５はＵＥ支援情報に従ってＤＬデータを配信することができる。アプリケーションのトラフィックパターンを判定する例示的な方法は、以下でより詳細に説明される。

ＵＥ支援情報は、例えば、ＲＡＣＨ要求４３０に含まれる媒体アクセス制御（ＭＡＣ）制御要素（ＣＥ）に含まれ得る。ＵＥ支援情報は、最小許可サイズ、最小許可周波数及び最小許可持続時間を含み得る。これらのパラメータは単なる例示であり、ＤＬデータの送信に関する情報をネットワーク４０５に提供するために、ＵＥ支援情報にも含まれる他のタイプの情報が存在し得ることを理解されたい。図３を参照して上述したように、ＤＬトラフィックパターンは、一般に、ＵＥ１１０によって既知であり得る。したがって、ＵＥ１１０は、ＵＥ支援情報をネットワーク４０５に提供することができ、ＵＥ１１０がＲＲＣ非アクティブ状態にあるときにＤＬデータを受信することを可能にするようにネットワークがＤＬデータ伝送をフォーマットすることができる。

ＵＥ支援情報をより詳細に論じる前に、トラフィックパターンは様々な方法で判定され得ることに留意されたい。第１の例では、ＵＥ１１０は、特定のアプリケーション（例えば、ビデオストリーミングサービス）についての経験を有し、アプリケーションの以前の使用に基づいて発生するであろうトラフィックパターンを理解することができる。第２の例では、ＵＥ１１０は、アプリケーションの現在の使用のためのトラフィックパターンを判定する時間に、アプリケーションに通常の方法で（例えば、ＰＤＣＣＨを監視することを含むＲＲＣ接続状態を使用して）データをストリーミングすることを可能にすることができ、現在のトラフィックパターンが判定された後に、ＵＥ１１０は、例示的な実施形態を使用するように切り替えることができる。第３の例では、アプリケーションを、アプリケーションタイプにグループ化することができ（例えば、ビデオストリーミングアプリケーションは第１のタイプであってもよく、オーディオストリーミングアプリケーション（ポッドキャスト、音楽ストリーミング）は第２のタイプであってもよい、など）、また、ＵＥ１１０は、各アプリケーションタイプのトラフィックパターンを理解することができる。したがって、アプリケーションが起動されるときに、ＵＥ１１０は、関連したアプリケーションタイプと、当該アプリケーションタイプに関連付けられたトラフィックパターンを理解することができる。第４の例では、ＵＥ１１０は、現在実行されているアプリケーションのトラフィックパターンをクラウドソーシングすることができる。さらに、現在の無線接続の質、ネットワークのタイプなどの他の要因も、アプリケーションのトラフィックパターンに影響を及ぼし得る。

したがって、ＵＥ１１０がトラフィックパターンを認識すると、ＵＥ１１０は、例えば、ＲＡＣＨ要求４３０のＭＡＣ ＣＥを介して、ＵＥ支援情報をネットワーク４０５に提供することができる。また上記のように、ＵＥ支援情報は、最小許可サイズ、最小許可周波数及び最小許可持続時間を含み得る。これらのパラメータが提供され、ＵＥ１１０がデータをリスニングして受信するように、ＲＲＣ非アクティブ状態にあるときに、ネットワーク４０５がストリーミングデータをＵＥ１１０に送信することを可能にする。最小許可サイズは提供され、ネットワーク４０５がストリーミングデータをＵＥ１１０に提供するために必要な許可の最小サイズを理解する。例えば、グラフ３００に示す例示的なトラフィックパターンが現在のトラフィックパターンであると考えたとすれば、ＵＥ１１０は、図３に示す最大のデータのバーストを収容するように最小許可サイズをデータバースト３３０として設定することができる。最小許可周波数は、データバーストのそれぞれの間の時間に基づくことがある。最小許可持続時間は、データバーストの最長持続時間に基づくことがある。例えば、図３に示すように、データバースト３２０は、これらのバーストがデータに関して最大バーストではないとしても、ピーク持続時間を有する。

ＲＡＣＨ要求４３０に応答して、ネットワーク４０５は、ＵＥ１１０がデータをネットワークに伝送するアップリンク（ＵＬ）許可を含むＲＡＣＨ応答４４０を提供することができる。ＲＡＣＨ応答４４０を受信すると、ＵＥ１１０は、ＲＡＣＨ応答４４０で提供されるＵＬ許可（複数可）を使用して、データ４５０をネットワーク４０５に送信することができる。ネットワーク４０５は、ＨＡＲＱ ＡＣＫ４６０を提供して、ネットワーク４０５がデータ４５０を受信していることを示すことができる。データ４５０及びＨＡＲＱ ＡＣＫ４６０は、ＵＥ１１０がＲＲＣ接続状態にある間に、データ及びＨＡＲＱ ＡＣＫの複数のやりとりが存在し得るため、破線で示されている。ＵＬデータ４５０が送信及び肯定応答された後、ＵＥ１１０は、ＲＲＣ非アクティブ状態４７０に遷移することができる。

しかし、ＵＥ１１０はＲＲＣ非アクティブ状態４７０にある間に、ネットワーク４０５は、ＲＡＣＨ要求４３０でネットワークに提供された情報に基づいて、ＤＬデータ（例えば、ストリーミングデータ）をＵＥ１１０に継続して伝送することができる。上記のように、ＲＲＣ非アクティブ状態では、ＵＥ１１０は、ＲＲＣ接続状態又はＲＲＣアイドル状態の場合よりも、より受動的な方法でネットワーク４０５を監視し続けることができる。この監視は、ＰＤＣＣＨを監視せずにデータチャネルを監視することを含み得る。ＵＥ１１０は、（例えば、ＲＡＣＨ要求４３０で）ＵＥ支援情報をネットワーク４０５に提供しているため、ＵＥ１１０は、ストリーミングデータのデータバーストがいつネットワーク４０５によって送信されるかを理解するであろう。したがって、このようにして、ＵＥ１１０は、ＰＤＣＣＨを絶えず監視することによって電力を無駄にする必要なく、ＲＲＣ非アクティブ状態でＤＬデータを受信することができる。

加えて、上記の例示的な実施形態は、単一のストリーミングアプリケーションを実行するＵＥ１１０を参照して説明されてきたが、ＵＥ１１０は、他のアプリケーションを同時に動作させていることがあることを理解されたい。例えば、ＵＥ１１０は、ストリーミングアプリケーションと同時にアクティブである電子メールアプリケーション、ナビゲーションアプリケーションなどを有することがある。これらの他のアプリケーションはまた、フォアグラウンドデータ又はバックグラウンドデータを含むＤＬデータも受信することができる。ＵＥ１１０は、これらの他の実行アプリケーションをストリーミングアプリケーションと提携させる（align）ことができるので、これらのアプリケーションのＤＬデータもＲＲＣ非アクティブ状態中に受信される。ＵＥ１１０は、これらの他のアプリケーションを説明するためのＭＡＣ ＣＥで提供されるＵＥ支援情報を変更できること（例えば、最小許可サイズの変更など）を理解されたい。

また、例示的な実施形態は、ＤＬデータを受信する際にＵＥ１１０をＲＲＣ非アクティブ状態のままにする必要がないことも理解されたい。例えば、実行アプリケーションのうちの１つ以上がＤＬデータのＲＲＣ接続状態を必要とするため、ＵＥ１１０がＲＲＣ接続状態に遷移してＤＬデータを受信するシナリオが存在し得る。

加えて、ＵＥ１１０はまた、ストリーミングアプリケーションが実行中にもＵＥ支援情報を変更することができる。例えば、無線状態は、ストリーミングアプリケーションが実行中にも経時的に変化する場合があり、これによりトラフィックパターンは変更し得る。ＵＥ１１０は、この変更されたトラフィックパターンを判定し、次に利用可能なＲＡＣＨ要求中に更新された追加のデータをネットワーク４０５に送信して、ネットワーク４０５がＤＬデータを配信する方法を変更することができる。したがって、ストリーミングアプリケーションが開始されると、ＤＬデータを配信する方法は静的である必要はない。

図５は、様々な例示的な実施形態による、ＵＥ１１０がＲＲＣ非アクティブ状態でネットワーク５０５からＤＬトラフィックを受信することを可能にする第２の例示的なシグナリング図５００を示す。この場合も、ネットワーク４０５は、５Ｇ ＮＲ－ＲＡＮ１２０又はＬＴＥ－ＲＡＮ１２２のいずれかであると考えることができ、ＵＥ１１０は、ｇＮＢ１２０Ａ又はｅＮＢ１２２Ａのうちの１つに接続され得る。シグナリング図５００は、ネットワーク４０５とＵＥ１１０との間で実行されるＲＡＣＨ手順中に、ＵＥ支援情報がネットワーク４０５に提供されるという点で、シグナリング図４００と同様である。ＲＲＣ非アクティブ状態５１０、ページ５２０、及びＲＡＣＨ要求５３０のためのシグナリングは、シグナリング図４００内の対応する信号と同様である。ＲＡＣＨ要求５３０は、ＵＥ１１０のＲＲＣ非アクティブ状態中に、ネットワーク５０５がＤＬデータを提供するために使用することになるＵＥ支援情報を含むであろう。

しかし、この例では、ＵＥ１１０はＲＡＣＨ応答５４０を受信しない。当業者であれば、例えば、無線チャネルの劣化、干渉、ネットワーク５０５が元のＲＡＣＨ要求５３０などを受信していないなどのような、ＵＥ１１０がＲＡＣＨ応答５４０を受信しない様々な理由があり得ることを理解するであろう。図５の例では、ＵＥ１１０は、ＲＡＣＨ要求５５０をネットワーク５０５に再伝送する。この再伝送は、例えば、ＵＥ支援情報とともにＭＡＣ ＣＥを含む、元のＲＡＣＨ要求５３０と同じ情報を含むであろう。次いで、ＵＥ１１０はＲＡＣＨ応答５６０を受信でき、シグナリングは図４を参照して上述したのと同じ方法で継続する。この場合も、ネットワーク５０５がＵＥ１１０からＵＥ支援情報を受信しているため、ネットワーク５０５は、ＲＲＣ非アクティブ状態５９０中にＤＬデータを伝送することができる。

図６は、様々な例示的な実施形態による、ＵＥ１１０がＲＲＣ非アクティブ状態でネットワーク６０５からＤＬトラフィックを受信することを可能にする第３の例示的なシグナリング図６００を示す。この場合も、ネットワーク６０５は、５Ｇ ＮＲ－ＲＡＮ１２０又はＬＴＥ－ＲＡＮ１２２のいずれかであると考えることができ、ＵＥ１１０は、ｇＮＢ１２０Ａ又はｅＮＢ１２２Ａのうちの１つに接続され得る。図６を参照して説明される例示的な実施形態では、ＵＥ支援情報は、ＵＥ１１０がネットワーク６０５とＲＲＣ接続状態にあるときにネットワーク６０５に提供される。

図６では、ＵＥ１１０は最初に、ネットワーク６０５とＲＲＣ接続状態にあると考えることができる。ＲＲＣ接続状態中は、ＵＥ１１０は、ネットワーク６０５とデータをやりとりすることができる。このデータのやりとりの一部として、ＵＥ１１０は、ＵＥ支援情報メッセージ６１０でＵＥ支援情報をネットワーク６０５に提供することができる。しかし、ＵＥ１１０は、ネットワーク６０５とのＲＲＣ接続状態中にやりとりされる任意のメッセージの一部として、ＵＥ支援情報を提供することができることを理解されたい。ＵＥ支援情報は、シグナリング図４００を参照して上述したものと同じであってもよいが、例えば、図４のＲＡＣＨ手順中とは対照的に、ＲＲＣ接続状態中の様々な時間に配信される。

次いで、ＵＥ１１０は、ＲＲＣ非アクティブ状態６２０に遷移することができる。ＲＲＣ非アクティブ状態中に、ネットワーク６０５は、以前のＲＲＣ接続状態中に提供されるＵＥ支援情報に基づいて、ＤＬデータをＵＥ１１０に伝送することができる。後になって、ＵＥ１１０は、ネットワーク６０５と更に情報をやりとりするために、ＲＲＣ接続状態に入ることを望む場合がある。ＲＲＣ接続状態に入るために、ＵＥ１１０は、ＲＡＣＨ要求６３０をネットワーク６０５に伝送する。ＵＥ支援情報は、最後のＲＲＣ接続状態中に事前に伝送されていたため、ＲＡＣＨ要求６３０は、シグナリング図４００で行われたようにＵＥ支援情報を含まなくてもよい。

ネットワーク６０５は、ＵＥ１１０に対してアップリンクグラント（複数可）を含むＲＡＣＨ応答６４０を伝送し、ＵＥ１１０はＲＲＣ接続状態に入る。ＲＲＣ接続状態中に、ＵＥ１１０は、データ６５０をネットワーク６０５に伝送し、ＨＡＲＱ ＡＣＫ６６０を受信して、データ６５０がネットワーク６０５によって受信されたことを確認する。データ６５０の伝送が完了すると、ＵＥ１１０は、ＲＲＣ非アクティブ状態６７０に遷移する。この場合も、このＲＲＣ非アクティブ状態６７０の間は、ＵＥ１１０は、ＵＥ支援情報に従ってネットワーク６０５からＤＬデータの受信を継続することができる。

本実施例では、ＵＥ１１０は、（例えば、データ６５０に関連付けられた）最新のＲＲＣ接続状態中の追加ＵＥ支援情報を送信しなかったことを理解されたい。したがって、ネットワーク６０５は、ＵＥ支援情報メッセージ６１０で受信したＵＥ支援情報に従ってＤＬデータを送信し続ける。しかし、ＵＥ１１０は、（例えば、データのやりとり６５０に対応する）最新のＲＲＣ接続状態中の追加ＵＥ支援情報メッセージを送信して、ＵＥ支援情報を変更することができる。したがって、ネットワーク６０５がＲＲＣ非アクティブ状態６７０中にＤＬデータを伝送する場合、ネットワーク６０５は、新たに受信したＵＥ支援情報に従ってＤＬデータを送信することができる。

図７は、様々な例示的な実施形態による、ＵＥ１１０がＲＲＣ非アクティブ状態でネットワーク７０５からＤＬトラフィックを受信することを可能にする第４の例示的なシグナリング図７００を示す。この場合も、ネットワーク７０５は、５Ｇ ＮＲ－ＲＡＮ１２０又はＬＴＥ－ＲＡＮ１２２のいずれかであると考えることができ、ＵＥ１１０は、ｇＮＢ１２０Ａ又はｅＮＢ１２２Ａのうちの１つに接続され得る。シグナリング図７００は、ＵＥ１１０がネットワーク７０５とＲＲＣ接続状態にあるときに、ＵＥ支援情報がネットワーク７０５に提供されるという点でシグナリング図６００と同様である。

図７では、ＵＥ１１０は最初は、ネットワーク７０５とＲＲＣ接続状態にあると考えることができる。ＲＲＣ接続状態の間は、ＵＥ１１０は、ネットワーク７０５とデータをやりとりすることができる。このデータのやりとりの一部として、ＵＥ１１０は、ＵＥ支援情報メッセージ７１０でＵＥ支援情報をネットワーク７０５に提供することができる。次いで、ＵＥ１１０は、ＲＲＣ非アクティブ状態７２０に遷移することができる。ＲＲＣ非アクティブ状態の間、ネットワーク７０５は、以前のＲＲＣ接続状態中に提供されるＵＥ支援情報に基づいて、ＤＬデータをＵＥ１１０に伝送することができる。後になって、ＵＥ１１０は、ネットワーク７０５と更に情報をやりとりするために、ＲＲＣ接続状態に入ることを望む場合がある。ＲＲＣ接続状態に入るためには、ＵＥ１１０は、ＲＡＣＨ要求７３０をネットワーク７０５に伝送することになる。ＵＥ支援情報は、最後のＲＲＣ接続状態中に事前に伝送されていたため、ＲＡＣＨ要求７３０は、ＵＥ支援情報を含まなくてもよい。

しかし、この例では、ＵＥ１１０はＲＡＣＨ応答７４０を受信しない。図７の例では、ＵＥ１１０は、ＲＡＣＨ要求７５０をネットワーク７０５に再伝送する。次いで、ＵＥ１１０は、ＲＡＣＨ応答７６０を受信でき、シグナリングは図６を参照して上述したのと同じ方法で継続する。この場合も、ネットワーク７０５は、以前のＲＲＣ接続状態中にＵＥ１１０からＵＥ支援情報（例えば、ＵＥ支援情報メッセージ７１０）を受信しているため、ネットワーク７０５は、ＲＲＣ非アクティブ状態７９０中にＤＬデータを伝送することができる。

図８は、様々な例示的な実施形態による、ＵＥ１１０がＲＲＣ非アクティブ状態でネットワーク８０５からＤＬトラフィックを受信することを可能にする第５の例示的なシグナリング図８００を示す。この場合も、ネットワーク８０５は、５Ｇ ＮＲ－ＲＡＮ１２０又はＬＴＥ－ＲＡＮ１２２のいずれかであると考えることができ、ＵＥ１１０は、ｇＮＢ１２０Ａ又はｅＮＢ１２２Ａのうちの１つに接続され得る。シグナリング図８００は、ＵＥ支援情報がネットワーク４０５とＵＥ１１０との間で実行されるＲＡＣＨ手順中にネットワーク８０５に提供されるという点でシグナリング図４００と同様である。８１０～８６０のシグナリングは、シグナリング図４００内の対応する信号４１０～４６０と同様であり、再び説明しない。

上記のように、データ８５０及びＨＡＲＱ ＡＣＫ８６０は、ＵＥ１１０とネットワーク８０５との間の複数のやりとりメッセージを含み得る。ＨＡＲＱ ＡＣＫ８６０が送信されるたびに、トラッキングエリアコード（ＴＡＣ）が、ＨＡＲＱ ＡＣＫに含まれ得る。ＵＥ１１０はまた、時間アライメントタイマ（Ｔｉｍｅ Ａｌｉｇｎｍｅｎｔ Ｔｉｍｅｒ：ＴＡＴ）を含み得る。ＴＡＴは、ＴＡＣを受信するたびにリセットされる。ＴＡＴが満了するときに、ＵＥ１１０は、ＴＡＴの長さについてネットワーク８０５からメッセージを受信しておらず、ＵＥ１１０は、現在ネットワーク８０５と同期していないと想定する。シグナリング図８００は、ＵＥ１１０が更なるタイマ８７０を実装できることを示し、その時間は、ＵＥ１１０とネットワーク８０５との間で取り決められ得る。ＵＥ１１０がネットワーク８０５と同期していない場合（同期外れ）８８０であっても、ネットワーク８０５は、依然としてＵＥ１１０にデータを送信することができる。すなわち、ＵＥ１１０は、タイマ８７０がアクティブである時間中、ＵＥ１１０が同期していない（同期外れ）場合８８０であっても、ＲＲＣ接続状態のままなので、ＵＥ１１０はネットワーク８０５から追加のデータを受信できる。例えば、ＵＥ１１０は、この時間中にＰＤＣＣＨを監視し、ネットワーク８０５から追加のＤＬデータに関する情報を受信することができる。タイマ８７０が満了すると、ＵＥ１１０は、ＲＲＣ非アクティブ状態８９０に遷移し、上記のようにＤＬデータの受信を継続することができる。

図９は、様々な例示的な実施形態による、ＵＥ１１０がＲＲＣ非アクティブ状態でネットワーク９０５からＤＬトラフィックを受信することを可能にする第６の例示的なシグナリング図９００を示す。この場合も、ネットワーク９０５は、５Ｇ ＮＲ－ＲＡＮ１２０又はＬＴＥ－ＲＡＮ１２２のいずれかであると考えることができ、ＵＥ１１０は、ｇＮＢ１２０Ａ又はｅＮＢ１２２Ａのうちの１つに接続され得る。シグナリング図９００は、ＵＥ１１０がネットワーク９０５とＲＲＣ接続状態にあるときに、ＵＥ支援情報がネットワーク８０５に提供され、ネットワーク９０５に提供されるという点で、シグナリング図６００と同様である。９１０～９６０のシグナリングは、シグナリング図６００の対応する信号６１０～６６０と同様であり、再び説明しない。

シグナリング図８００と同様に、シグナリング図９００は、ＵＥ１１０が更なるタイマ９７０を実装することもできることを示し、その時間はＵＥ１１０とネットワーク９０５との間で、ＵＥ１１０がネットワーク９０５と同期していない（同期外れ）９８０ときに開始されることに取り決められ得る。上記のように、ＵＥ１１０は、タイマ９７０がアクティブである時間中にＵＥ１１０が同期していない（同期外れ）９８０場合であっても、ＲＲＣ接続状態のままなので、ＵＥ１１０はネットワーク９０５から追加のデータを受信でき、例えば、ＵＥ１１０は、この時間中にＰＤＣＣＨを監視し、ネットワーク９０５から追加のＤＬデータに関する情報を受信することができる。タイマ９７０が満了すると、ＵＥ１１０はＲＲＣ非アクティブ状態９９０に遷移し、上記のようにＤＬデータの受信を継続することができる。

シグナリング図４００～９００は、ＵＥがＲＲＣ非アクティブ状態にあるときに、ネットワークがＵＥにＤＬデータを伝送することを可能にするために、ＵＥ及びネットワークによって使用され得る様々なシグナリングを示す。ＵＥがＲＲＣ非アクティブ状態でデータを受信するとき、ＵＥは、ＰＤＣＣＨを監視する必要がなく、このことは、ＵＥは、従来の方法と同様にＰＤＣＣＨの絶えず続く監視に関連するエネルギーを消費する必要がないことを意味する。

上記の例示的な実施形態は、任意の好適なハードウェア構成若しくはソフトウェア構成又はこれらの組み合わせにおいて実装されてもよいことが、当業者には理解されよう。例示的実施形態を実現するための例示的なハードウェアプラットフォームとして、例えば、互換性のあるオペレーティングシステムを有するＩｎｔｅｌ（登録商標）ｘ８６をベースとしたプラットフォーム、Ｗｉｎｄｏｗｓ ＯＳ、Ｍａｃプラットフォーム及びＭＡＣ ＯＳ、ｉＯＳ、Ａｎｄｒｏｉｄ（登録商標）等のオペレーティングシステムを有するモバイルデバイスを挙げることができる。別の実施例においては、上記の方法の例示的実施形態は、コンパイルされると、プロセッサ又はマイクロプロセッサにおいて実行することができる非一時的コンピュータ可読記憶媒体に記憶されたコード行を含むプログラムとして実行することができる。

本出願は、それぞれが様々な組み合わせにおいて異なる特徴を有する様々な実施形態を記載するが、一実施形態の特徴のうちのいずれかは、具体的に否認されない方法で、又は開示された実施形態のデバイスの動作若しくは記載された機能と機能的若しくは論理的に矛盾しない方法で、他の実施形態の特徴と組み合わされてもよいことが、当業者には理解されよう。

個人特定可能な情報の使用は、ユーザのプライバシーを維持するための業界又は政府の要件を満たす又は超えると一般に認識されているプライバシーポリシー及びプラクティスに従うべきであることに十分に理解されたい。特に、個人特定可能な情報データは、意図されない又は許可されていないアクセス又は使用のリスクを最小限に抑えるように管理及び取り扱いされるべきであり、許可された使用の性質はユーザに明確に示されるべきである。

様々な修正形態が、本開示の精神又は範囲から逸脱することなく本開示においてなされてもよいことが当業者には明らかである。したがって、本開示は、添付の特許請求の範囲及びそれらの均等物の範囲内で、本開示の修正形態及び変形形態を網羅することが意図されている。

Claims (17)

1. ネットワークに接続されたユーザ機器（ＵＥ）において、
   前記ネットワークからデータを受信するアプリケーションを実行することと、
   ＵＥ支援情報を前記ネットワークに伝送することであって、前記ＵＥ支援情報は、前記アプリケーションのために前記ネットワークから受信する前記データのトラフィックパターンに対応していることと、
   無線リソース制御（ＲＲＣ）非アクティブ状態に入ることと、
   物理ダウンリンク制御チャネル（ＰＤＣＣＨ）を監視することなく前記ＲＲＣ非アクティブ状態中に前記ネットワークから前記データを受信することと、
   を含む、方法。
2. 前記ＵＥ支援情報は、ランダムアクセスチャネル（ＲＡＣＨ）要求内で伝送される、請求項１に記載の方法。
3. 前記ＵＥが前記ネットワークとのＲＲＣ接続状態にあるときに、前記ＵＥ支援情報は伝送される、請求項１に記載の方法。
4. 前記アプリケーションに関連付けられた前記トラフィックパターンを判定することを更に含む、請求項１に記載の方法。
5. 前記アプリケーションはストリーミングアプリケーションである、請求項１に記載の方法。
6. 第２のアプリケーションを実行することと、
   前記ＵＥが前記ＲＲＣ非アクティブ状態にあるときに、前記第２のアプリケーションのための入力データ伝送を前記アプリケーションのための前記データの受信とアラインすることと、
   を更に含む、請求項１に記載の方法。
7. 前記ＵＥが前記ネットワークと同期していないことを判定することと、
   前記ＵＥが前記ネットワークと同期していないときにタイマを開始することであって、前記ＵＥは前記タイマの長さの間、ＲＲＣ接続状態のままにすることと、
   前記ネットワークからのダウンリンクデータ伝送のために前記タイマの前記長さの間に制御チャネルを監視することと、
   前記タイマが満了するときに前記ＲＲＣ非アクティブ状態に遷移することと、
   を更に含む、請求項１に記載の方法。
8. ネットワークと通信するように構成された送受信機と、
   動作を実行するように構成されたプロセッサとを備え、前記動作は、
   前記ネットワークからデータを受信するアプリケーションを実行することと、
   ＵＥ支援情報を前記ネットワークに伝送することであって、前記ＵＥ支援情報は、前記アプリケーションのために前記ネットワークから受信する前記データのトラフィックパターンに対応していることと、
   無線リソース制御（ＲＲＣ）非アクティブ状態に入ることと、
   物理ダウンリンク制御チャネル（ＰＤＣＣＨ）を監視することなく前記ＲＲＣ非アクティブ状態中に前記ネットワークから前記データを受信することと、
   を含む、ユーザ機器（ＵＥ）。
9. 前記ＵＥ支援情報は、ランダムアクセスチャネル（ＲＡＣＨ）要求内で伝送される、請求項８に記載のＵＥ。
10. 前記ＵＥが前記ネットワークとのＲＲＣ接続状態にあるときに、前記ＵＥ支援情報は伝送される、請求項８に記載のＵＥ。
11. 前記動作は、前記アプリケーションに関連付けられた前記トラフィックパターンを判定することを更に含む、請求項８に記載のＵＥ。
12. 前記プロセッサは、アプリケーションプロセッサとベースバンドプロセッサを含み、前記アプリケーションプロセッサは前記アプリケーションを実行する、請求項８に記載のＵＥ。
13. 前記動作は、
    第２のアプリケーションを実行することと、
    前記ＵＥが前記ＲＲＣ非アクティブ状態にあるときに、前記第２のアプリケーションの入力データ伝送を前記アプリケーションのための前記データの受信とアラインすることと、を更に含む、請求項８に記載のＵＥ。
14. 前記動作は、
    前記ＵＥが前記ネットワークと同期していないことを判定することと、
    前記ＵＥが前記ネットワークと同期していないときにタイマを開始することであって、前記ＵＥは前記タイマの長さの間、ＲＲＣ接続状態のままにすることと、
    前記ネットワークからのダウンリンクデータ伝送のために前記タイマの前記長さの間に制御チャネルを監視することと、
    前記タイマが満了するときに前記ＲＲＣ非アクティブ状態に遷移することと、
    を更に含む、請求項８に記載のＵＥ。
15. ＵＥ支援情報をネットワークに伝送するように構成された回路であって、前記ＵＥ支援情報は、アプリケーションのために前記ネットワークから受信するデータのトラフィックパターンに対応している回路と、
    無線リソース制御（ＲＲＣ）非アクティブ状態に入るように構成された回路と、
    物理ダウンリンク制御チャネル（ＰＤＣＣＨ）を監視することなく前記ＲＲＣ非アクティブ状態中に前記ネットワークから前記データを受信するように構成された回路と、
    を備える、集積回路。
16. 前記ＵＥ支援情報は、ランダムアクセスチャネル（ＲＡＣＨ）要求内で伝送される、請求項１５に記載の集積回路。
17. 前記ＵＥ支援情報は、前記ネットワークとのＲＲＣ接続状態の間に伝送される、請求項１５に記載の集積回路。