JP2019537321A

JP2019537321A - 間欠受信

Info

Publication number: JP2019537321A
Application number: JP2019518527A
Authority: JP
Inventors: ラーシュノルド，; リキャルドユーン，; スヴァンテアルナス，; リントラン，; アンデシュバーリグレーン，
Original assignee: Sony Mobile Communications Inc
Current assignee: Sony Corp
Priority date: 2016-10-07
Filing date: 2017-10-06
Publication date: 2019-12-19
Anticipated expiration: 2037-10-06
Also published as: EP3524017B1; US20190297663A1; JP6982715B2; KR20190060767A; US11013055B2; CN109792690A; WO2018065565A1; CN109792690B; EP3524017A1; KR102249229B1

Abstract

端末のインターフェースが、スケジュール（２００）に従って、少なくとも１つのアクティブ状態（２８３）とスリープ状態（２８１）との間で切り替える。少なくとも１つのアクティブ状態（２８３）の一時的な延長（２０９）を示すアップリンク制御データが送信される。【選択図】図８

Description

本発明は、一般に、ネットワークに接続可能な端末のインターフェースの、少なくとも１つのアクティブ状態とスリープ状態と間の切替えに関する。本発明は、詳細には、少なくとも１つのアクティブ状態の一時的な延長（ｐｒｏｌｏｎｇａｔｉｏｎ）を示すアップリンク制御データを送信することに関する。

ネットワークに接続可能である端末の電力消費を低減するために、いわゆる間欠受信（ＤＲＸ：ＤｉｓｃｏｎｔｉｎｕｏｕｓＲｅｃｅｐｔｉｏｎ）が知られている。たとえば、第３世代パートナーシッププロジェクト（３ＧＰＰ）ロングタームエボリューション（ＬＴＥ）プロトコルによれば、ＤＲＸは、無線リソース制御（ＲＲＣ）接続モードについて３ＧＰＰ技術仕様（ＴＳ）３６．３２１（リリース１３．０．０）、セクション５．７に記載されているように実装され、ＲＲＣアイドルモードについて３ＧＰＰＴＳ３６．３０４、セクション７．１に記載されているように実装され得る。

接続モードについての３ＧＰＰＬＴＥＤＲＸ（接続ＤＲＸ）によれば、端末は、ＤＲＸサイクルのオン時間の間に、ダウンリンク（ＤＬ）ペイロードデータを受信する準備ができている。ＲＲＣ接続は、オン時間の初めに確立され、オン時間の終わりに解放される。アイドルモードについての３ＧＰＰＬＴＥＤＲＸ（アイドルＤＲＸ）によれば、端末は、ＤＲＸサイクルのオン時間の間に、ネットワークページングを受信する準備ができている。ＲＲＣ接続は、オン時間の間に確立されず、端末がネットワークによって実際にページングされる場合に、要求に応じて確立されるにすぎない。ＲＲＣ接続とＲＲＣアイドルの両方において、ＵＥは、ネットワークに登録され得る。

しかしながら、そのような技法は、いくつかの制限および欠点に直面する。たとえば、同等に静的なＤＲＸサイクルを実装することは、増加されたレイテンシを生じることがあることが観測されている。時々、ＤＬペイロードデータが、ＤＲＸサイクルのオン時間の満了の前に、端末に適時に配信されないことがある。その場合、ＤＲＸサイクルの次の反復のオン時間が、ＤＬペイロードデータを配信するための機会の新しいウィンドウを開く前に、同等に長い時間が経過することがある。特に、そのような参照実装は、ＤＲＸサイクルのサイクル長の寸法決定に関していくつかの制約を課する。たとえば、ＤＲＸサイクルのサイクル長は、端末の電力消費をさらに低減する試みにおいて、増加され、レイテンシはさらに増加し得る。

それゆえ、スケジュールに従って、少なくとも１つのアクティブ状態とスリープ状態との間で切り替える高度な技法が必要である。特に、上記で特定された制限および欠点のうちの少なくともいくつかを克服または緩和するそのような技法が必要である。

この必要は、独立請求項の特徴によって満たされる。従属請求項は、実施形態を規定する。

一例によれば、端末がインターフェースを含む。インターフェースは、ワイヤレスリンク上でネットワークと通信するように設定される。端末は、少なくとも１つのプロセッサをさらに含む。少なくとも１つのプロセッサは、スケジュールに従って、少なくとも１つのアクティブ状態とスリープ状態との間で切り替えるようにインターフェースを制御するように設定される。少なくとも１つのプロセッサは、ネットワークにアップリンク（ＵＬ）制御データを送信するようにさらに設定される。ＵＬ制御データは、少なくとも１つのアクティブ状態の一時的な延長を示す。

一例によれば、方法が、スケジュールに従って、少なくとも１つのアクティブ状態とスリープ状態との間で切り替えるように端末のインターフェースを制御することを含む。方法は、ネットワークにＵＬ制御データを送信することをさらに含む。ＵＬ制御データは、少なくとも１つのアクティブ状態の一時的な延長を示す。

一例によれば、コンピュータプログラム製品が、少なくとも１つのプロセッサによって実行され得るプログラムコードを含む。プログラムコードを実行することは、少なくとも１つのプロセッサに方法を実施させる。方法は、スケジュールに従って、少なくとも１つのアクティブ状態とスリープ状態との間で切り替えるように端末のインターフェースを制御することを含む。方法は、ネットワークにＵＬ制御データを送信することをさらに含む。ＵＬ制御データは、少なくとも１つのアクティブ状態の一時的な延長を示す。

一例によれば、コンピュータプログラムが、少なくとも１つのプロセッサによって実行され得るプログラムコードを含む。プログラムコードを実行することは、少なくとも１つのプロセッサに方法を実施させる。方法は、スケジュールに従って、少なくとも１つのアクティブ状態とスリープ状態との間で切り替えるように端末のインターフェースを制御することを含む。方法は、ネットワークにＵＬ制御データを送信することをさらに含む。ＵＬ制御データは、少なくとも１つのアクティブ状態の一時的な延長を示す。

一例によれば、ネットワークのネットワークノードが、少なくとも１つのプロセッサを含む。少なくとも１つのプロセッサは、端末からＵＬ制御データを受信するように設定される。ＵＬ制御データは、スケジュールの少なくとも１つのアクティブ状態の一時的な延長を示す。スケジュールは、少なくとも１つのアクティブ状態とスリープ状態との間で端末のインターフェースを切り替えるためのものである。たとえば、ネットワークノードは基地局であり得る。

一例によれば、方法が、端末からＵＬ制御データを受信することを含む。ＵＬ制御データは、スケジュールの少なくとも１つのアクティブ状態の一時的な延長を示す。スケジュールは、少なくとも１つのアクティブ状態とスリープ状態との間で端末のインターフェースを切り替えるためのものである。

一例によれば、コンピュータプログラム製品が、少なくとも１つのプロセッサによって実行され得るプログラムコードを含む。プログラムコードを実行することは、少なくとも１つのプロセッサに方法を実施させる。方法は、端末からＵＬ制御データを受信することを含む。ＵＬ制御データは、スケジュールの少なくとも１つのアクティブ状態の一時的な延長を示す。スケジュールは、少なくとも１つのアクティブ状態とスリープ状態との間で端末のインターフェースを切り替えるためのものである。

一例によれば、システムが、少なくとも１つのプロセッサを有する基地局を含む。システムは、基地局などのネットワークノードと通信するように設定されたインターフェースを有する端末をさらに含む。端末は、少なくとも１つのプロセッサをさらに有する。端末の少なくとも１つのプロセッサは、スケジュールに従って、少なくとも１つのアクティブ状態とスリープ状態との間で切り替えるように端末のインターフェースを制御するように設定される。端末およびネットワークノードは、少なくとも１つのアクティブ状態の一時的な延長を示すＵＬ制御データを通信するようにさらに設定される。

上述の特徴およびこれから以下で説明される特徴は、本発明の範囲から逸脱することなく、示されるそれぞれの組合せにおいてだけでなく、他の組合せにおいてまたは独立しても使用され得ることを理解されたい。上述の態様および実施形態の特徴は、他の実施形態では互いと組み合わせられ得る。

様々な例による、基地局を含むセルラーネットワークを概略的に例示する図であり、図１では、ネットワークに接続可能な端末をさらに例示した。様々な例による、端末を概略的に例示する図である。様々な例による、方法のフローチャートである。様々な例による、基地局を概略的に例示する図である。様々な例による、方法のフローチャートである。様々な例による、アクティブ状態とスリープ状態との間で端末のインターフェースを切り替えるための反復的なスケジュールを概略的に例示する図である。様々な例による、接続状態、アイドル状態、およびスリープ状態を例示する状態図である。様々な例による、アクティブ状態とスリープ状態との間で端末のインターフェースを切り替えるための反復的なスケジュールを概略的に例示する図である。様々な例による、アクティブ状態とスリープ状態との間で端末のインターフェースを切り替えるための反復的なスケジュールを概略的に例示する図である。様々な例による、アクティブ状態とスリープ状態との間で端末のインターフェースを切り替えるための反復的なスケジュールを概略的に例示する図である。様々な例による、アクティブ状態とスリープ状態との間で端末のインターフェースを切り替えるための反復的なスケジュールを概略的に例示する図である。様々な例による、アクティブ状態とスリープ状態との間で端末のインターフェースを切り替えるための反復的なスケジュールを概略的に例示する図である。様々な例による、ネゴシエートされた反復的なスケジュールからの一時的な逸脱を示すＵＬ制御データの通信を概略的に例示するシグナリング図である。様々な例による、ネゴシエートされた反復的なスケジュールからの一時的な逸脱を示すＵＬ制御データの通信を概略的に例示するシグナリング図である。様々な例による、ネゴシエートされた反復的なスケジュールからの一時的な逸脱を示すＵＬ制御データの通信を概略的に例示するシグナリング図である。様々な例による、ネゴシエートされた反復的なスケジュールからの一時的な逸脱を示すＵＬ制御データの通信を概略的に例示するシグナリング図である。

以下では、添付の図面を参照しながら本発明の実施形態が詳細に説明される。実施形態の以下の説明は、限定的な意味にとられるべきではないことを理解されたい。本発明の範囲は、以下で説明される実施形態によってまたは図面によって限定されるものではなく、これらは、例示的なものにすぎないものととられる。

図面は、概略表現であると見なされるべきであり、図面に例示されている要素は、必ずしも一定の縮尺で示されているとは限らない。むしろ、様々な要素は、それらの機能および一般的目的が当業者に明らかになるように表される。図面に示されるかまたは本明細書で説明される機能ブロック、デバイス、構成要素、または他の物理または機能ユニットとの間の接続または結合は、間接的接続または結合によっても実装され得る。また、ワイヤレス接続を介して構成要素間の結合が確立され得る。機能ブロックは、ハードウェア、ファームウェア、ソフトウェア、またはそれらの組合せで実装され得る。

以下で、端末のインターフェースの少なくとも１つのアクティブ状態とスリープ状態との間で切り替える技法が説明される。時々、少なくとも１つのアクティブ状態とスリープ状態との間で切り替えるそのような技法は、ＤＲＸと呼ばれる。単に、時々インターフェースのアクティブ状態をアクティブ化することによって、端末の電力消費が低減され得る。

切替えは、スケジュールに従って実装され得る。たとえば、スケジュールは、端末とネットワークとの間でネゴシエートされ得る。スケジュールのそのようなネゴシエーションは、ＵＬ制御シグナリングおよび／またはＤＬ制御シグナリングを伴い得る。時々、ネゴシエーションは、端末とネットワークとの間でワイヤレスリンク上でデータ接続を確立するためのアタッチプロシージャの一部として行われ得る。他の例では、スケジュールは、たとえば、確定された規格などに従ってあらかじめ定義されることも可能であろう。

スケジュールは、反復的であり得、すなわち、異なる状態間の切替えの反復を定義し得る。たとえば、スケジュールは、時間領域において反復的であり得る。いくつかの例では、反復的なスケジュールが後続の反復についての周期性を実装することが可能である。反復的なスケジュールは、厳密に周期的ではないが、反復ごとに一定の変動を示すことも可能である。スケジュールの反復は、時間領域において定義されることを必要とされず、反復がイベント領域において定義されることも可能であろう。たとえば、スケジュールの異なる反復がイベントトリガ型であり得る。イベントの一例は、ＵＬデータを送信する必要である。イベントのさらなる例は、端末のユーザアクティビティまたはモビリティである。いくつかの例では、反復は、時間領域およびイベント領域において定義され得る。

スケジュールは、少なくとも１つのアクティブ状態とスリープ状態との間で切り替えるためのタイミングを示し得る。これは、ネットワークが、その場合、端末が到達可能である時間に気づき得るので、端末へのＤＬデータ送信を可能にし得る。

たとえば、スケジュール、たとえば、各反復についてのスケジュールは、インターフェースの１つまたは複数のアクティブ状態がその間にアクティブ化される、一定のオン時間を含み得る。オン時間の間に、１つまたは複数のアクティブ状態のうちの異なるアクティブ状態の間で切り替えることが可能であり得る。さらに、各反復は、インターフェースのスリープ状態がその間にアクティブ化される、オフ時間を含み得る。

インターフェースは、スリープ状態において動作するとき、完全にまたはほとんど電源切断され得る。時々、スリープ状態は、ドーマント状態または電力セーフ状態とも呼ばれる。たとえば、スリープ状態の間に、インターフェースのアナログフロントエンドが無効にされ得る。これは、アナログ増幅器、アナログデジタル変換器のうちの１つまたは複数を電源切断することを含み得る。たとえば、スリープ状態の間に、電源電圧がアナログ増幅器および／またはアナログデジタル変換器に与えられないことがある。概して、スリープ状態の間に、インターフェースは、ワイヤレスリンク上でＤＬデータを受信するのに不適当であり得る。端末は、スリープ状態において位置更新を送らないことがある。したがって、概して、スリープ状態において、端末にＤＬデータを送ることが可能でないことがある。スリープ状態の間に、端末がネットワークのそれぞれのリポジトリに登録されたままであることが可能である。このすべては、スリープ状態における端末の低電力消費を可能にする。

様々なアクティブ状態が考えられる。例は、接続状態を含む。接続状態において、端末とネットワークとの間の進行中のデータ接続が維持され得る。たとえば、データ接続は、国際標準化機構（ＩＳＯ）ＩＴＵ−ＴＸ．２００（０７／１９９４）文書に従って、開放型システム間相互接続（ＯＳＩ）モデルのネットワークレイヤ上に実装され得る。たとえば、データ接続は、ＵＬペイロードチャネルおよび／またはＤＬペイロードチャネル上のデータを識別するためのベアラを含み得る。端末は、接続状態においてネットワークに頻度が高い位置更新を送信し得る。たとえば、端末が現在キャンピングするサービングセルが、ネットワークに適時に所与の瞬間において知られ得る。接続状態において、端末のインターフェースは、完全に電源投入され得る。３ＧＰＰＬＴＥフレームワークでは、一例は、ＲＲＣ接続状態である。一般に、接続状態は、端末の著しい電力消費に関連する。

アクティブ状態のさらなる例は、アイドル状態を含む。たとえば、アイドル状態は、接続状態とスリープ状態との混合であり得る。これのために、時々、アイドル状態は、非接続接続状態（ｄｉｓｃｏｎｎｅｃｔｅｄｃｏｎｎｅｃｔｅｄｓｔａｔｅ）とも呼ばれる。アイドル状態において、端末とネットワークとの間の進行中のデータ接続を維持することを必要とされないことがある。たとえば、アイドル状態では、接続状態とは異なり、端末が接続可能であるセルラーネットワークの特定のサービングセルは、ネットワークに知られていないことがある。端末は、たとえば、トラッキングエリアを変更するときなど、頻度が低い位置更新を送信することも送信しないこともある。たとえば、アイドル状態において、ネットワークが端末をページングすること、すなわち、端末にＤＬページングを送ることが可能であり得る。しかしながら、ＤＬペイロードデータを直接送ることが可能でないことがある。ＤＬページングは、端末を接続状態に遷移するようにトリガし得る。これは、ワイヤレスリンクのペイロードチャネルを確立するためのアタッチプロシージャを実施することを伴い得る。たとえば、アイドル状態において、端末のインターフェースのアナログフロントエンドが、完全に電源切断されないが、概して機能的であることがある。しかしながら、制限された復調／復号機能などを含み得る、デジタルフロントエンド中のいくつかの機能が無効にされ得る。３ＧＰＰＬＴＥフレームワークにおけるアイドル状態の一例は、ＲＲＣアイドル状態である。アイドル状態の一例は、Ｒ１４について３ＧＰＰにおいて議論されているＲＲＣ接続非アクティブ状態である。

たとえば、スケジュールは、スリープ状態と組み合わせて１つまたは複数のアクティブ状態を実装し得る。

様々な例によれば、スケジュールから一時的に逸脱するための技法が提供される。言い換えれば、スケジュールからの一時的な例外を実装することを可能にする様々な例による技法が提供される。たとえば、スケジュールからのそのような一時的な逸脱は、１つまたは複数の反復のオン時間を増加または減少させることを含み得る。たとえば、スケジュールからのそのような一時的な逸脱は、スケジュールの１つまたは複数の反復のオフ時間を増加または減少させることを含み得る。たとえば、スケジュールからのそのような一時的な逸脱は、スケジュールの１つまたは複数の反復のうちの反復の持続時間を増加または減少させることを含み得る。したがって、一時的な逸脱を設定するための様々な可能性が存在する。たとえば、そのような一時的な延長は、オン時間を定義する少なくとも１つのアクティブ状態の延長に対応し得る。それにより、端末および／またはネットワークの一時的な必要に従ってスケジュールを動的に調整することが可能である。

様々な例によれば、端末は、スケジュールからのそのような逸脱をトリガし得る。次いで、端末は、ネットワークに、端末によって想定されるスケジュールからの一時的な逸脱を示すアップリンク制御データを送信し得る。それにより、ネットワークは、それに応じて、ＤＬデータを送信するための機会の任意の追加のウィンドウを利用するように、または一時的な逸脱により失敗すると見なされるＤＬ送信試みを回避するように通知され得る。

たとえば、一時的な逸脱は、オン時間の延長として、すなわち、少なくとも１つのアクティブ状態の延長として実装されることが可能であり得る。これは、ＤＬペイロードデータなど、ＤＬデータを受信するための機会の追加のウィンドウを開き得る。

端末によって実行されるサービスがＤＬペイロードデータを予想しているシナリオを考慮することができる。このＤＬペイロードデータは、ネットワーク主導型／端末終了トラフィックであり得る。たとえば、ＤＬペイロードデータは、サービスのＵＬペイロードデータの送信によってトリガされ得る。サービスに関連するラウンドトリップレイテンシ、たとえば、端末からネットワークを介して、サービスをホストするサーバへの、および戻って、ネットワークを介して端末への通信のために定義されたレイテンシにより、ＤＬペイロードデータは、オン時間の満了の後に端末に到着し得る。その場合、インターフェースは、すでにスリープ状態に入っており、その時間においてネットワークによって到達可能でないので、端末によって実行されるサービスは、ＤＬペイロードデータを受信しないことになる。次のオン時間までの継続時間が大きい場合、これは、サーバとのデバイス通信にとっての困難を課し得る。そのようなシナリオは、端末が、インターネットサーバにＵＬペイロードデータを送信しているときに発生し得、ここで、インターネットサーバは、オン時間よりも長い遅延で端末への応答を与える。そのようなシナリオが発生し得る他の例は、端末が、いくつかの構成設定の更新のためにサービスをホストするサーバをポーリングすることを含む。シナリオが発生し得るまたさらなる例は、端末が、ファームウェア更新のためにサービスをホストするサーバをポーリングすることを含む。

本明細書で説明される技法に基づいて、ＤＬペイロードデータはオン時間の満了の後におよびオフ時間の間に、すなわち、インターフェースがスリープ状態にすでに切り替わった時点において到着する、そのようなシナリオを予期することが可能であり得る。次いで、本明細書で説明される様々な例によれば、端末がネットワークにＵＬ制御データを送信することが可能であり得、ＵＬ制御データは、スケジュールからの一時的な逸脱を示す。たとえば、少なくとも１つのアクティブ状態が延長される場合、機会のウィンドウが、予想されるＤＬペイロードデータを受信するために開いていることがある。

図１は、ネットワーク１００に関する態様を例示する。図１は、ネットワーク１００のアーキテクチャに関する態様を例示する。図１の例によるネットワーク１００は、３ＧＰＰＬＴＥアーキテクチャを実装する。３ＧＰＰＬＴＥによれば、ワイヤレスリンク１０１は、ＲＡＮ１１４において定義される。ワイヤレスリンク１０１は、発展型ノードＢ（ｅＮＢ）１１２の形態の基地局と１つまたは複数のＵＥ１３０との間で定義される。ワイヤレスリンク１０１は、ペイロードチャネルおよび／または制御チャネルなど、１つまたは複数のチャネルを実装し得る。

さらに、ネットワーク１００はコアネットワーク１１３を含む。コアネットワーク１１３はＲＡＮ１１４と通信している。コアネットワーク１１３は、制御レイヤとデータレイヤとを含む。制御レイヤは、ホーム加入者サーバ（ＨＳＳ）１１５、モバイル管理エンティティ（ＭＭＥ）１１６、ならびにポリシーおよび課金ルール機能（ＰＣＲＦ）１１９など、制御ノードを含む。データレイヤは、サービングゲートウェイ（ＳＧＷ）１１７およびパケットデータネットワークゲートウェイ（ＰＧＷ）１１８など、ゲートウェイノードを含む。

データ接続１６０が、ＲＡＮ１１４を介してＵＥ１３０−１とコアネットワーク１１３のデータレイヤとの間に、およびアクセスポイント１２１のほうへ確立される。たとえば、アクセスポイント１２１を介してインターネットまたは別のパケットデータネットワークとの接続が確立され得る。パケットデータネットワークまたはインターネットのサーバが、データ接続１６０を介してペイロードデータが通信されるサービスをホストし得る。データ接続１６０は、専用ベアラまたはデフォルトベアラなど、１つまたは複数のベアラを含み得る。データ接続１６０は、ＲＲＣレイヤ上で定義され得る。したがって、データ接続１６０を確立することは、ＯＳＩネットワークレイヤ制御シグナリングを含み得る。データ接続１６０によって、リソースが、物理アップリンク共有チャネル（ＰＵＳＣＨ）および／または物理ダウンリンク共有チャネル（ＰＤＳＣＨ）など、ペイロードチャネル上に割り振られ得る。

コアネットワーク１１３のネットワークノード１１５〜１１９、１２１の一般的機能および目的は、当技術分野でよく知られており、したがって、このコンテキストにおいて詳細な説明が必要とされない。

３ＧＰＰＬＴＥフレームワークにおけるネットワーク１００の例示は、例示的な目的のためのものにすぎない。同様の技法が、モバイル通信用グローバルシステム（ＧＳＭ）、広帯域符号分割多重（ＷＣＤＭＡ）、汎用パケット無線サービス（ＧＰＲＳ）、ＧＳＭ進化型高速データレート（ＥＤＧＥ）、拡張ＧＰＲＳ（ＥＧＰＲＳ）、ユニバーサルモバイルテレコミュニケーションズシステム（ＵＭＴＳ）、および高速パケットアクセス（ＨＳＰＡ）など、様々な種類の３ＧＰＰ指定アーキテクチャに容易に適用され得る。たとえば、本明細書で説明される技法は、３ＧＰＰｅＮＢ−ＩｏＴまたはＭＴＣシステムあるいは３ＧＰＰ新無線（ＮＲ）システムに適用され得る。たとえば、３ＧＰＰＲＰ−１６１３２１およびＲＰ−１６１３２４を参照されたい。さらに、それぞれの技法は、Ｂｌｕｅｔｏｏｔｈ、衛星ネットワーク、ＩＥＥＥ８０２．１１ｘＷｉ−Ｆｉ技術など、様々な種類の非３ＧＰＰ指定ネットワークに容易に適用され得る。

図２は、端末１３０に関する態様を例示する。端末１３０は、プロセッサ１３０１、たとえば、マルチコアプロセッサを含む。端末１３０は、メモリ１３０２、たとえば、不揮発性メモリをさらに含む。端末１３０は、インターフェース１３０３をさらに含む。

インターフェース１３０３は、デジタルフロントエンドおよび／またはアナログフロントエンドを含み得る。アナログフロントエンドは、１つまたは複数のアンテナに接続可能であり得る。たとえば、インターフェース１３０３は、１つまたは複数のアンテナポートを含み得る。たとえば、アナログフロントエンドは、変調および符号化された信号を受信するための低雑音増幅器およびアナログデジタル変換器など、増幅器を含み得る。アナログフロントエンドは、送信のためのデジタルアナログ変換器を含み得る。たとえば、デジタルフロントエンドは、データを受信したとき、復調、復号、デインターリービング、チェックサムの計算など、タスクを実施するように設定され得る。たとえば、デジタルフロントエンドは、ＯＳＩモデルに従って下位レベル機能を実装し得る。一般に、復調および復号などのタスクが、かなりのエネルギー消費にも関連する。

インターフェース１３０３は、異なる動作状態に従って動作し得る。これらの状態は、インターフェース１３０３が、ワイヤレスリンク１０１上で送信された一部または全部のＤＬデータおよび／または信号を受信することが可能である、１つまたは複数のアクティブ状態を含み得る。たとえば、アクティブ状態では、増幅器および／またはアナログデジタル変換器は、少なくとも時々および／または少なくとも部分的に電源電圧を与えられ得る。これらの状態は、インターフェース１３０３が、ワイヤレスリンク１０１上で送信されたＤＬデータを受信するのに不適当である、スリープ状態をさらに含み得る。一般に、少なくとも１つのアクティブ状態のうちの１つに従って動作するインターフェース１３０３と比較した場合に、スリープ状態に従ってインターフェース１３０３が動作する場合、端末１３０の電力消費が低減される。

メモリ１３０２は、プロセッサ１３０１によって実行され得る制御命令を記憶し得る。制御命令を実行することは、プロセッサ１３０１に電力節約の技法を実施させることができ、これらは、スケジュールに従って、少なくとも１つのアクティブ状態とスリープ状態との間で切り替えるようにインターフェース１３０３を制御することを含み得る。

図３は、様々な例による、方法のフローチャートである。たとえば、図３による方法は、端末１３０のプロセッサ１３０１によって実行され得る。

最初に、ブロック６００１において、端末のインターフェースが、少なくとも１つのアクティブ状態とスリープ状態との間で切り替えるように制御される。いくつかの例では、これは、スケジュールに従って発生し得る。概して、スケジュールは、ネットワークに知られていることがある。これは、スケジュールをネゴシエートすることによって発生し得る。スケジュールは、確定されたルールに従って定義されることも可能であろう。スケジュールは周期的であり得る。スケジュールは、イベントトリガ型挙動を定義することも可能である。たとえば、スケジュールは、ＵＬペイロードデータの送信の後のオン持続時間を定義することができる。ここで、オン持続時間をトリガするイベントは、ＵＬデータを送信する必要であろう。スケジュールは、端末とネットワークとの間でネゴシエートされ得る。たとえば、図３による方法は、ブロック６００１より前に、端末とネットワークとの間でスケジュールをネゴシエートすることをさらに含み得る。

ブロック６００１によるそのような切替えは、ＤＲＸサイクルを実装し得る。いくつかの例では、３ＧＰＰＬＴＥフレームワークに従って、ブロック６００１において切替えを実装するためのスケジュールは、３ＧＰＰＬＴＥフレームワークに従って接続ＤＲＸおよび／またはアイドルＤＲＸを実装し得る。しかしながら、本明細書で説明されるいくつかの例は、３ＧＰＰＬＴＥＤＲＸをしのぐか、または代替実装形態を提供し得る。いくつかの例では、ブロック６００１による切替えは、イベントトリガ型であり得る。たとえば、オン持続時間は、ＵＬデータを送信する必要に応答してアクティブ化され得る。

次に、ブロック６００２において、ＵＬ制御データがネットワークに送信される。ＵＬ制御データは、スケジュールからの一時的な逸脱を示す。図３の例では、これは、少なくとも１つのアクティブ状態の一時的な延長として実装される。たとえば、上記の例では、ＵＬデータを送信する必要に応答して、拡張されたオン持続時間が示され得る。

たとえば、ＵＬ制御データは、専用制御メッセージ、たとえば、ＲＲＣレイヤ制御メッセージ中に含まれ得る。さらなる例では、ＵＬ制御データが、他の目的を果たす制御メッセージ、たとえば、データ接続またはペイロードチャネルを確立するためのアタッチプロシージャの間に通信される制御メッセージ上にピギーバックされることが可能である。

スケジュールからの一時的な逸脱は、オン時間の延長に対応し得る。したがって、一時的な逸脱は、端末のインターフェースの少なくとも１つのアクティブ状態の延長に対応し得る。延長の持続時間は、ＵＬ制御データによっても示されることが可能であり、持続時間は、代替的にネットワーク定義され得る。

方法は、ＵＬ制御データを送信することおよびブロック６００２に応答して、スケジュールからの一時的な逸脱を実装することをさらに含み得る。時々、一時的な逸脱は、ＵＬ制御データを送信した後にネットワークの確認応答に応じて選択的に実装され得る。

確認応答は、明示的確認応答または暗黙的確認応答であり得る。確認応答は、肯定応答（ＰＡＣＫ）または否定応答（ＮＡＣＫ）であり得る。たとえば、ネットワークがスケジュールからの一時的な逸脱を否定応答した場合、一時的な逸脱の実装が抑圧され得る。たとえば、ネットワークがスケジュールからの一時的な逸脱を肯定応答した場合、一時的な逸脱の実装が実行され得る。確認応答を含むそれぞれのＤＬ制御データは、随意に、逸脱の持続時間、たとえば、オン時間の延長の持続時間をも含み得る。

図４は、ｅＮＢ１１２に関する態様を例示する。ｅＮＢ１１２は、プロセッサ１１２１、たとえば、マルチコアプロセッサを含む。ｅＮＢ１１２は、メモリ１１２２、たとえば、不揮発性メモリをさらに含む。ｅＮＢ１１２は、インターフェース１１２３をさらに含む。インターフェース１１２３は、デジタルフロントエンドおよび／またはアナログフロントエンドを含み得る。アナログフロントエンドは、１つまたは複数のアンテナに接続可能であり得る。たとえば、インターフェース１１２３は、１つまたは複数のアンテナポートを含み得る。たとえば、アナログフロントエンドは、ワイヤレスリンク１０１上で、変調および符号化された信号を受信するための低雑音増幅器およびアナログデジタル変換器など、増幅器を含み得る。

メモリ１１２２は、プロセッサ１１２１によって実行され得る制御命令を記憶し得る。制御命令を実行することは、プロセッサ１１２１に、ｅＮＢ１１２に接続可能な端末１３０における電力節約の技法を実施させることができる。そのような技法は、端末１３０において少なくとも１つのアクティブ状態とスリープ状態との間で切り替えるためのスケジュールに従ってその端末との通信を同期させることを含み得る。スケジュールは、端末とネゴシエートされ得る。

図５は、様々な例による、方法のフローチャートである。たとえば、図５による方法は、端末の電力節約の技法を実施するためにプロセッサ１１２１によって実行され得る。

最初に、ブロック６０１１において、端末において、少なくとも１つのアクティブ状態とスリープ状態との間で切り替えるためのスケジュールがネゴシエートされる。ブロック６０１１は、端末におよび／または端末から制御データを送信および／または受信することを含み得る。ブロック６０１１は、一方向または二方向ネゴシエーションであり得る。ブロック６０１１は随意である。たとえば、スケジュールをネゴシエートする代わりに、スケジュールは、固定してあらかじめ定義され得る。

次に、ブロック６０１２において、ＵＬ制御データが端末から受信される。ＵＬ制御データは、スケジュールからの一時的な逸脱を示す。図５の例では、一時的な逸脱は、この場合も、少なくとも１つのアクティブ状態の延長として実装される。

方法は、スケジュールからの一時的な逸脱に従って、ＤＬペイロードデータおよび／またはＤＬ制御データの送信を実装することをさらに含み得る。

たとえば、図５の方法は、図３の方法に相互に関係し得る。

図６は、反復的なスケジュール２００に関する態様を概略的に例示する。図６では、説明の目的で、スケジュール２００の３つの反復２３１〜２３３が例示されている。しかしながら、スケジュール２００は、より多数の反復２３１〜２３３またはより少数の反復２３１〜２３３を含み得る。

各反復２３１〜２３３は、図６の例によれば、オン時間２０１と、オフ時間２４０とを含む。たとえば、反復２３１において、オン時間２０１の持続時間２１１は、オフ時間２４０の持続時間２１２よりも短い。持続時間２１１、２１２は、合計すると反復２３１全体の持続時間２１３になる。図６の例では反復２３１〜２３３の周期性が実装されるが、他の例では、異なる反復が異なる持続時間を有し得る。

オン時間２０１において、端末１３０のインターフェース１３０３は、接続状態２８３において動作する。オフ時間２４０において、端末１３０のインターフェース１３０３は、スリープ状態２８１において動作する。オン時間２０１の間に接続状態２８３において動作するとき、インターフェース１３０３は、データ接続１６０上でＤＬデータを受信する準備ができている。これは、図６の例における反復２３２に関して例示され、ここで、ＤＬペイロードデータ２６１は、ネットワーク１００によっておよびスケジュール２００に従って送信され、すなわち、ＤＬペイロードデータ２６１は、インターフェース１３０３が接続状態２８３において動作するとき、オン時間２０１の間に端末１３０に到着する。

図６の例では、ＤＬペイロードデータ２６１の受信が非アクティビティタイマー２１５をトリガする。非アクティビティタイマー２１５は、ＵＬペイロードデータ２６１の送信によってもトリガされ得る。また、オン時間２０１の間の他のアクティビティが、非アクティビティタイマー２１５をトリガし得る。非アクティビティタイマー２１５は、（図６中の破線によって例示されている）オン時間２０１の延長２０７を実装する。これは、あらかじめ定義された挙動であるので、スケジュール２００に従うものである。延長２０７は、非アクティビティタイマー２１５が満了していない間、さらなるＤＬペイロードデータを受信するための機会の追加のウィンドウを開く。非アクティビティタイマー２１５は、スケジュール２００の一部であり、したがって、ネットワーク１００は、非アクティビティタイマー２１５により、ＤＬペイロードデータを送信するための機会の別のウィンドウが開かれることに気づいている。

以上のことから諒解されるように、スケジュール２００は、完全に決定論的挙動を規定することが必要とされない。たとえば、スケジュール２００は、異なる状態間で切り替えることおよび／またはタイマーを使用することおよび／またはオン時間２０１とオフ時間２４０とをアクティブ化することを行うためのルールのセットを定義し得る。しかしながら、これらのルールは、データの受信および／または送信など、いくつかの変動するものを考慮に入れることができる。したがって、状況に応じて、端末１３０の挙動がアプリオリに完全には定義されないことがある。

本明細書で説明される様々な例によれば、スケジュール定義された値と比較した場合、非アクティビティタイマー２１５の値を、たとえば、より大きい値またはより小さい値に再設定するように、スケジュール２００からの一時的な逸脱を実装することが可能であり得る。たとえば、ＵＬペイロードデータ２５１を送信することに応答して、非アクティビティタイマー２１５が次いでトリガされ得る。非アクティビティタイマー２１５のために固定値を使用する代わりに、再設定された値がサービスの必要に従ってフレキシブルに調整され得る。

図７は、端末１３０のインターフェース１３０３が動作することができる様々な状態２８１〜２８３に関する態様を概略的に例示する。

図７の例では、スリープ状態２８１は、インターフェース１３０３のドーマント状態に対応する。ここで、端末１３０は、ネットワーク１００から完全には切断されないが、依然として登録されている。位置更新は、端末１３０からネットワーク１００に送信されない。したがって、ネットワーク１００は、端末１３０の位置に気づいていない。さらに、インターフェース１３０３の１つまたは複数の構成要素が電源切断され得、したがって、インターフェース１３０３は、ＤＬデータを受信することが可能でない。データ接続１６０は確立されていないことがある。時々、３ＧＰＰＬＴＥでは、スリープ状態２８１は電力節約モードとも呼ばれる。３ＧＰＰＴＳ２３．４０１Ｖ１３．０．０（２０１４−０９）、セクション４．３．２２「ＵＥ電力節約モード」を参照されたい。たとえば、３ＧＰＰＴＳ２３．６８２Ｖ１３．４．０（２０１５−１２）を参照されたい。

さらなる状態２８２、２８３において、インターフェース１３０３は、概して、たとえば、少なくともいくつかのタイムスロットの間におよび／またはいくつかの周波数上でおよび／またはいくつかのコーディング／変調に従って、ＤＬデータを受信する準備ができている。したがって、状態２８２、２８３は、アクティブ状態と呼ばれることがある（図７における破線）。

ＲＲＣ接続状態２８３において、端末１３０は、ネットワーク１００とのデータ接続１６０を維持する。ＴＳ３６．３３１、チャプター４．２を参照されたい。これは、セルラーネットワーク１００の異なるサービングセル間のハンドオーバがデータ接続１６０の損失なしに実装され得ることを意味する。これについて、端末１３０は、ワイヤレスリンク上の通信品質に関する測定報告を送信し得る。ネットワーク１００は、サービングセルに気づいている。別様に、ＲＲＣアイドル状態２８２において、端末１３０は、ネットワーク１００とのデータ接続１６０を維持しないことがある。位置更新は、同等に低頻度で、または過程精度で送信されるにすぎず、たとえば、セルレベルで定義されないことがある。インターフェース１３０３は、それにもかかわらず、少なくともある程度、電源投入され得る。これは、ネットワーク１００からのＤＬページング信号の受信を可能にし得る。インターフェース１３０３は、制限された復調および復号機能を実施し得る。ＤＬページングを受信したことに応答して、端末１３０は、ＲＲＣ接続状態２８３に遷移し得る。たとえば、接続状態２８３において動作するインターフェース１３０３の電力消費は、アイドル状態２８２において動作するインターフェースの電力消費よりも少なくとも３０％だけ高くなり得る。したがって、端末１３０およびアクティブ状態を維持すると同時に、ページングの必要性によってもたらされるレイテンシを犠牲にして電力消費が依然として低減され得る。

たとえば、スリープ状態２８１からＲＲＣ接続状態２８３へのまたはＲＲＣアイドル状態２８２からＲＲＣ接続状態２８３への遷移２８８は、ワイヤレスリンク１０１のペイロードチャネルを含むデータ接続１６０を確立するためのアタッチプロシージャを実施することを伴い得る。たとえば、アタッチプロシージャ２８８は、端末１３０のランダムに選択されたコードおよび／または一時的な識別に基づいて、ネットワーク１００にアクセスしようとするさらなる端末との衝突が緩和される、端末１３０のランダムアクセスを含み得る。一般に、ランダムアクセスは、ＯＳＩモデルに従って物理レイヤ上で定義される。たとえば、アタッチプロシージャ２８８は、代替または追加として、ＯＳＩモデルに従って上位レイヤ上で定義された制御シグナリングを含み得る。例は、ＲＲＣアタッチプロシージャを含む。

ＲＲＣ接続状態２８３からＲＲＣアイドル状態２８２へのまたはＲＲＣ接続状態２８３からＲＲＣスリープ状態２８１への遷移２８９は、ＲＲＣリリースプロシージャを含み得る。図７では、さらに、ＲＲＣアイドル状態２８２からＲＲＣスリープ状態２８１への遷移２８７が例示されている。

図７の例では、２つのアクティブ状態２８２、２８３が例示されているが、さらなる例では、より多数のアクティブ状態がプロビジョニングされることが可能である。いくつかの例は、３ＧＰＰＬＴＥＴＳ２５．３３１、セクション７．１による、ＰＣＨ状態、ＣＥＬＬ＿ＰＣＨ状態、ＵＲＡ＿ＰＣＨ状態、ＣＥＬＬ＿ＦＡＣＨ状態、およびＣＥＬＬＤＣＨ状態を含み得る。さらに、図７の例では、様々な状態２８１〜２８３が３ＧＰＰＬＴＥＲＲＣレイヤ機能に関して説明されたが、他の例では、他のレイヤ上でおよび／または３ＧＰＰＬＴＥ以外の他のプロトコルに従って、インターフェース１３０３の電力節約機能を実装することも可能である。それにもかかわらず、３ＧＰＰＬＴＥＲＲＣレイヤ機能のコンテキストにおいて状態２８１〜２８３について上記で説明されたような様々な性質が、他の例にも適用され得る。

図８は、反復的なスケジュール２００に関する態様を例示する。特に、図８は、スケジュール２００からの一時的な逸脱を実装することに関する態様を例示する。図８の例は、概して、図６の例に対応する。

反復２３１において、端末１３０は、サービスのＵＬペイロードデータ２５１を送信する。サービスは、一定のラウンドトリップレイテンシ２６０に関連する。ラウンドトリップレイテンシ２６０は、極めて長く、サービスの、ＵＬペイロードデータ２５１に関連する、ＤＬペイロードデータ２６１は、オン時間２０１の間に到着しない。ＤＬペイロードデータ２６１は、オフ時間２４０の間に到着する。オフ時間２４０では、インターフェース１３０３は、スリープ状態２８１において動作する。それゆえ、インターフェース１３０３は、データを受信するのに不適当であり、特に、サービスのＤＬペイロードデータ２６１を受信することができない。その場合、ＤＬペイロードデータ２６１の受信が次のオン時間（簡単のために図８では例示されない）まで遅延される。これは、サービスのレイテンシを増加させる。

反復２３２において、スケジュール２００からの一時的な逸脱が実装される。特に、（図８において破線によって例示されている）延長２０９が実装される。延長２０９は、オン時間２０２を拡張する。したがって、延長２０９は、反復２３２におけるアクティブ状態２８３を延長する。これは、ＤＬペイロードデータ２６１を正常に受信するための機会の別のウィンドウを開く。

図８は、延長２０９の持続時間２１９をも例示する。持続時間２１９は、端末１３０に常駐する論理によっておよび／またはネットワーク１００中に常駐する論理によって決定されることが可能であり得る。単純な例では、持続時間２１９はまた、あらかじめ定義され得る。たとえば、延長の持続時間は、ペイロードデータ２５１、２６１が属するサービスのラウンドトリップレイテンシ２６０に関する知識に基づいて決定され得る。たとえば、アプリオリな知識がサービスのペイロードデータの前の送信から導出され得る。それにより、延長２０９の持続時間２１９を調整することが可能であり、したがって、電力消費の過大な増加が回避される。

概して、延長２０９の持続時間２１９は、インターフェース１３０３がスケジュール２００に従ってアクティブ状態２８２、２８３においてその間に動作するオン時間２０２の持続時間２１１の５０％以上であり得る。いくつかの例では、持続時間２１９は、持続時間２１１の２００％以上、場合によっては５００％以上であり得る。それにより、追加のＤＬデータを受信するための機会のかなり大きいウィンドウが開いていることがある。一方、オン時間２０１の持続時間２１１は、通常、スケジュール２００に従って短くなるように設定され、それにより、平均電力消費を低減し得る。

一方、本明細書で説明される様々な技法は、特に長いオフ時間２４０の設定を可能にする。一時的な延長２０９によって、ＵＬペイロードデータ２５１も送信される同じ反復２３１〜２３３内でＤＬペイロードデータ２６１を受信する可能性が増加され得る。それにより、オフ時間２４０の持続時間２１２を増加させることが可能である。たとえば、延長２０９の持続時間２１９は、持続時間２１２の１０％以下、場合によっては２％以下、さらに場合によっては０．１％以下であり得る。絶対的には、持続時間２１２は、数分、数時間、さらには数日程度であり得る。特に、ＩＯＴ適用例のコンテキストでは、これは、低減された電力消費を可能にし得る。

図８の例では、一時的な逸脱は単一の反復２３２に制限される。したがって、反復２３２に隣接および後続する遅くとも反復２３３までには、スケジュール２００への撤退（ｆａｌｌｂａｃｋ）が実装される。一時的な逸脱を単一の反復に制限することによって、電力消費を最適化されたスケジュール２００は、ＤＬペイロードデータを受信する必要が検出された反復を除いてほとんど実装され得る。他の例では、一時的な逸脱はまた、単一の反復よりも多くの反復をカバーし得る。

図９Ａは、反復的なスケジュール２００に関する態様を例示する。特に、図９Ａは、スケジュール２００からの一時的な逸脱を実装することに関する態様を例示する。図９Ａの例は、概して、図８の例に対応する。

図９Ａの例では、この場合も、スケジュール２００の反復２３２において、スケジュール２００からの逸脱としての延長２０９が実装される。ここで、インターフェース１３０３は、延長２０９の間にアイドル状態２８２において動作する。したがって、インターフェース１３０３が２８３における接続状態において動作する、オン時間２０２の満了時に、インターフェース１３０３は、動作モードを切り替え、次いで、アイドル状態２８２において動作することに進む。これは、アイドル状態２８２において、オン時間２０２の間に確立されたデータ接続１６０を解放することと、ＤＬページング信号をリスニングすることとを含み得る。次いで、ＤＬページング信号は、ＤＬペイロードデータ２６１がｅＮＢ１１２における送信の準備ができていると、別のアタッチプロシージャ２８８をトリガするのを助けることができる（簡単のために図９Ａでは例示されない）。図９Ａの例に従って２つのアクティブ状態２８３、２８２を実装することによって、ＤＬペイロードデータ２６１を受信するための機会のさらなるウィンドウを依然として開いている間、端末１３０の電力消費が低減され得る。

図９Ｂは、反復的なスケジュール２００に関する態様を例示する。特に、図９Ｂは、スケジュール２００からの一時的な逸脱を実装することに関する態様を例示する。図９Ｂの例は、概して、図９Ａの例に対応する。ここで、ダウンリンクペイロードデータ２６１を受信した後に、非アクティビティタイマー２１５がトリガされる。

図１０は、反復的なスケジュール２００に関する態様を例示する。特に、図１０は、スケジュール２００からの一時的な逸脱を実装することに関する態様を例示する。図１０の例は、概して、図９Ａの例に対応する。

図１０の例では、この場合も、スケジュール２００の反復２３２において、スケジュール２００からの逸脱としての延長２０９が実装される。ここで、インターフェース１３０３は、延長２０９の間にアイドル状態２８２において動作する。図１０の例では、ＤＬペイロードデータ２６１を受信したことに応答して、スケジュール２００への撤退が実装される。これは、ＤＬペイロードデータ２６１を受信した後に、一定の持続時間の間、引き続きアイドル状態２８２において動作する代わりに、インターフェース１３０３がスリープ状態２４０において動作することに直接切り替えることを意味する。これは、端末１３０の電力消費をさらに低減するのを助ける。そのようなシナリオは、他の例、たとえば、図８の例によるスケジュール２００のためにも利用され得る。

図１１は、反復的なスケジュール２００に関する態様を例示する。特に、図１１は、スケジュール２００からの一時的な逸脱を実装することに関する態様を例示する。図１１の例は、概して、図８の例に対応する。

図１１の例では、延長２０９は、オン時間２０２の終わりまでにトリガされない。むしろ、ＵＬペイロードデータ２５１を送信したことに応答して、延長２０９の決定された持続時間２１９に基づいて、タイマーが初期化される。それにより、予想されるラウンドトリップレイテンシ２６０に関する正確な測度が実装され得る。端末１３０の過大な電力消費が回避され得る。

図８〜図１１で説明された様々な例は、さらなる例では互いと組み合わせられ得る。たとえば、図１１のタイマー技法は、図９および図１０のアイドル状態技法と組み合わせられ得る。

以上のことから諒解されるように、たとえば、３ＧＰＰＬＴＥフレームワークにおいて、ＤＲＸサイクルに従って、異なる状態２８１〜２８３の間で切り替える技法を実装することが可能であり得る。ここで、異なる状態２８１〜２８３の間で切り替える技法を実装するために、接続ＤＲＸおよび／またはアイドルＤＲＸが使用され得る。たとえば、延長２０９は、ＤＲＸの非アクティビティタイマーを一時的に再設定することによって実装され得る。非アクティビティタイマーは、インターフェース１３０３が、ＤＬペイロードデータ２６１を予想するとき、その間に少なくとも１つのアクティブ状態２８２、２８３において動作を続けるように制御される、継続時間を指定し得る。たとえば、非アクティビティタイマーは、ＵＬペイロードデータ２５１を送信したことに応答しておよび／またはＤＬペイロードデータを受信したことに応答してトリガされ得る。

図１２は、反復的なスケジュール２００からの一時的な逸脱を示すＵＬ制御データ３００をシグナリングすることに関する態様を例示するシグナリング図である。図１２は、異なる状態２８１、２８３間の切替えに関する態様をさらに例示する。

最初に、端末１３０のインターフェース１３０３は、スリープ状態２８１において動作する。次いで、スケジュール２００に従って、インターフェース１３０３は、接続状態２８３に切り替える。これは、ＤＬペイロードチャネルおよびＵＬペイロードチャネルを確立するためのアタッチプロシージャ２８８を実施することを含む。アタッチプロシージャ２８８は、ランダムアクセス（図１２では例示されない）を含み得る。アタッチプロシージャ２８８は、端末１３０がＲＲＣ接続要求メッセージ８００１を送信することをも含む。ＲＲＣ接続要求メッセージ８００１は、データ接続１６０など、ＲＲＣ接続を確立しようとする。次いで、ｅＮＢ１１２は、ＲＲＣ接続応答メッセージ８００２で応答。これは、データ接続１６０を確立することを可能にする。図１２からわかるように、接続状態２８３への遷移は、接続状態２８３を設定するためのＲＲＣレイヤ制御メッセージを通信することを伴う。したがって、接続状態２８３は、概して、ＯＳＩネットワークレイヤレベル上で定義され得る。

次に、端末１３０は、ＵＬ制御メッセージ８００３を送信する。ＵＬ制御メッセージ８００３は、ＵＬ制御データ３００を含む。ＵＬ制御データ３００は、アクティブ反復のためのスケジュール２００からの逸脱としての一時的な延長２０９を示す。

端末１３０は、ＵＬペイロードデータ２５１を含むメッセージ８００４をも送信する。次いで、ＵＬ制御データ３００に従って、端末１３０は、接続状態２８３の一時的な延長２０９を実装する。延長２０９の間に、端末１３０は、ネットワーク１００から、特にｅＮＢ１１２から、ＤＬペイロードデータ２６１を含むメッセージ８００５を受信する。ＤＬペイロードデータ２６１とＵＬペイロードデータ２５１とは、同じサービスに属する。ＤＬペイロードデータ２６１は、ＵＬペイロードデータ２５１が、たとえば、ＯＳＩモデルによるＴＣＰ／ＩＰレベルまたはトランスポートレイヤ上でアドレス指定される、同じサーバから発信することが可能である。

次いで、延長２０９の満了時に、ＲＲＣ接続解放メッセージ８００６がネットワーク１００から端末１３０に送信される。メッセージ８００６は、スリープ状態２８１への遷移２８９を可能にする。データ接続１６０が解放される。これは、スリープ状態２８１を設定する。

図１３は、反復的なスケジュール２００からの一時的な逸脱を示すＵＬ制御データ３００をシグナリングすることに関する態様を例示するシグナリング図である。図１３は、異なる状態２８１、２８２、２８３間の切替えに関する態様をさらに例示する。

８０１１〜８０１４が、概して、８００１〜８００４に対応する。次いで、ＲＲＣ接続解放メッセージ８０１５がネットワーク１００から端末１３０に送信される。これは、接続状態２８３からアイドル状態２８２への遷移を可能にする。特に、データ接続１６０が解放される。次いで、端末１３０は、延長２０９の間にＤＬページング８０１６を受信する。ＤＬページング８０１６の受信に応答して、アタッチプロシージャ２８８が実施され、アタッチプロシージャ２８８は、この場合も、ＲＲＣ接続要求メッセージ８０１７およびＲＲＣ接続応答メッセージ８０１８の通信を含む。メッセージ８０１７、８０１８は、データ接続１６０の確立を可能にする。次いで、データ接続１６０を介して、ＤＬペイロードデータ２６１を含むメッセージ８０１９が受信され得る。

延長２０９の終わりに、データ接続１６０を解放し、スリープ状態２８１に遷移するために、ＲＲＣ接続解放メッセージ８０２０が通信される。

図１２および図１３の例では、制御データ３００は、アタッチプロシージャ２８８の完了の後に送信される制御メッセージ８００３、８０１３の一部として送信される。たとえば、制御メッセージ８００３、８０１３は、３ＧＰＰＬＴＥフレームワークにおける物理ＵＬ制御チャネル（ＰＵＣＣＨ）など、制御チャネル上で送信される専用制御メッセージであり得る。制御データ３００を送信することの他の例が可能である。たとえば、制御データ３００は、アタッチプロシージャの一部として送信され得る。

図１４は、反復的なスケジュール２００からの一時的な逸脱を示すＵＬ制御データ３００をシグナリングすることに関する態様を例示するシグナリング図である。図１４は、異なる状態２８１、２８３間の切替えに関する態様をさらに例示する。図１４は、制御メッセージ上にＵＬ制御データをピギーバックすることに関する態様をさらに例示する。

図１４の例は、概して、図１２の例に対応する。しかしながら、図１４の例では、スケジュール２００からの逸脱を示し、特に延長２００を示す、制御データ３００は、アタッチプロシージャ２８８の間に通信されるＲＲＣ接続要求メッセージ８０３１上にピギーバックされる。制御データ３００は、アタッチプロシージャ２８８を通信される異なる制御メッセージ上にピギーバックされることも可能であろう。したがって、図１４の例によれば、ＵＬ制御データ３００は、アタッチプロシージャ２８８の間に送信される。これは、延長２０９の十分な時間を伴ってネットワーク１００に通知するのを助ける。さらに、制御シグナリングオーバーヘッドが低減され得る。図１４の例は、たとえば、図１３の例などと組み合わせられ得る。

８０３２〜８０３５が、概して、８００２、８００４〜８００６に対応する。

概して、制御データ３００は、シングルビット情報フィールドであり得る。その場合、スケジュール２００からの逸脱は、あらかじめ定義されたルールに従って実装され得る。さらなる例では、制御データ３００は、マルチビット情報を含むことも可能であろう。たとえば、制御データ３００は、一時的な逸脱の持続時間を示し、たとえば、延長２０９の持続時間２１９を示し得る。その場合、端末１３０は、たとえば、ペイロードデータ２５１、２６１に関連する予期された電力消費および／またはサービスのラウンドトリップレイテンシに基づいて、所与の状況において一時的な逸脱のどんな持続時間が適切であるかをフレキシブルに決定し得る。他の例では、一時的な逸脱の持続時間がネットワーク定義されることも可能であり得る。たとえば、対応する論理がｅＮＢ１１２中に存在し得る。そのようなシナリオでは、複数の端末間の送信衝突など、さらなるファクタを考慮することが可能であり得る。たとえば、ＵＬ制御データ３００は、サービスを示し得る。その場合、ネットワーク１００は、そのサービスに関連する一般的なラウンドトリップレイテンシに関する追加のアプリオリな知識を有し得る。たとえば、ｅＮＢ１１２は、ラウンドトリップレイテンシを監視し得る。さらに、ネットワークは、ＤＬペイロードデータ２６１を送信するためのスケジューリング制約を考慮に入れ得る。これは、一時的な逸脱の持続時間を寸法決定することの精度を増加させ得る。たとえば、ＤＬ制御データは、ネットワーク１００から端末１３０に送信され得、ＤＬ制御データは、たとえば、デフォルト持続時間の倍数単位で、スケジュール２００からの一時的な逸脱の持続時間を示す（図１４に例示されない）。

制御データ３００によって、ネットワーク１００は、スケジュール２００からの逸脱に気づかされる。次いで、ｅＮＢ１１２は、ＤＬペイロードデータ２６１のタイムリーな受信を可能にするために、逸脱に従ってＤＬペイロードデータ２６１を送信し得る。

図１５は、反復的なスケジュール２００からの一時的な逸脱を示すＵＬ制御データ３００をシグナリングすることに関する態様を例示するシグナリング図である。図１５は、異なる状態２８１、２８３間の切替えに関する態様をさらに例示する。図１５は、ネットワーク１００から端末１３０にダウンリンク確認応答を通信することに関する態様をさらに例示する。

図１５の例は、概して、図１２の例に対応する。たとえば、８０４１〜８０４３が８００１〜８００３に対応する。図１５の例では、ネットワーク１００は、ＤＬ制御メッセージ８０４４を送る。制御メッセージ８０４４は、制御メッセージ８０４３の一部として前に通信されたＵＬ制御データ３００の確認応答３１０を示す。

図１５の例では、ネットワーク１００は、スケジュール２００からの逸脱としての一時的な延長２０９を肯定応答し、すなわち、肯定応答（ＰＡＣＫ）を送り、時々、ＰＡＣＫは、単にＡＣＫと呼ばれる。この確認応答３１０のために、端末１３０は、次に進み、延長２０９を実装する。たとえば、否定応答（ＮＡＣＫ）が端末１３０によって受信された場合（図１５では例示されない）、端末１３０は、あらかじめ定義されたスケジュール２００に従って続き、すなわち、延長２０９をスキップすることができる。

概して、確認応答の送信は必須でない。ネットワークによる確認応答の送信は随意である。たとえば、明示的ダウンリンク制御シグナリングなしの技法が実装された場合、端末の要求に暗黙的に確認応答することが可能であろう。本明細書で説明される他の例では、たとえば、図１２〜図１４の例では、確認応答技法も採用され得る。

たとえば、ＵＬ制御データを送信したことに応答して、端末１３０は確認応答を受信し得る。ＵＬ制御データは、延長２０９の持続時間を示さないことが可能であろう。その場合、延長２０９の持続時間のためのあらかじめ定義された値が使用され得る。たとえば、そのようなあらかじめ定義された値は、事前設定されたデフォルトタイマー値の規格化された倍数を使用することができる。たとえば、ＵＬ制御データは、延長２０９の持続時間を示すことも可能であろう。次いで、確認応答が、端末１３０によって行われたそのような要求に肯定応答する場合、延長２０９の示された持続時間が使用され得る。しかしながら、確認応答が、端末１３０によって行われたそのような要求に否定応答する場合、延長２０９の持続時間２１９のために、デフォルト値が使用され得る。

さらなる例では、ＤＬ制御データは、確認応答および場合によっては応答パラメータを含むことができる。たとえば、端末は、応答パラメータを含む肯定応答を受信し、このパラメータは、たとえば、以前の設定されたデフォルト値の乗数として、延長２０９の持続時間２１９を定義し得る。たとえば、端末は、否定応答を受信し、デフォルト値が使用され得る。

その場合、８０４５〜８０４７が、８００４〜８００６に対応する。

本発明は、いくつかの好ましい実施形態に関して示され、説明されたが、本明細書を読み、理解すれば、等価物および変更形態が他の当業者には想起されるであろう。本発明は、すべてのそのような等価物および変更形態を含み、添付の特許請求の範囲によって限定されるにすぎない。

上記の様々な例は、インターフェースのネットワークレイヤの定義された状態に関して説明されたが、同様の例が、物理レイヤ（レイヤ１）および／またはデータリンクレイヤ（レイヤ２）などのレイヤ上で定義されるインターフェースの状態に関しても採用され得る。

上記の様々な例は、一時的な延長に関して説明されたが、同様の技法が、たとえば、少なくとも１つのアクティブ状態の一時的な短縮または反復の持続時間の一時的な拡張など、他の種類の、ネゴシエートされたスケジュールからの一時的な逸脱に関しても適用され得る。

上記の様々な例は、周期的スケジュールに関して説明されたが、それぞれの技法が、イベントトリガ型スケジュールのために容易に適用され得る。たとえば、ＵＬデータを送信する必要に応答して、オン時間がトリガされ得る。

たとえば、ＤＬデータの受信時にトリガされる非アクティビティタイマーに関して様々な例が説明されたが、ＵＬデータの送信時に、代替または追加として、非アクティビティタイマーをトリガするとき、同様の技法が容易に実装され得る。

Claims

− ワイヤレスリンク（１０１）上でネットワーク（１００）と通信するように設定されたインターフェース（１３０３）と、
− スケジュール（２００）に従って、少なくとも１つのアクティブ状態（２８２、２８３）とスリープ状態（２８１）との間で切り替えるように前記インターフェース（１３０３）を制御するように設定された、少なくとも１つのプロセッサ（１３０１）と
を備える、端末（１３０）であって、
前記少なくとも１つのプロセッサ（１３０１）が、前記ネットワーク（１００）に、前記少なくとも１つのアクティブ状態の一時的な延長（２０９）を示すアップリンク制御データ（３００）を送信するように設定された、
端末（１３０）。
前記スケジュール（２００）が反復的であり、
前記少なくとも１つのプロセッサ（１３０１）が、前記スケジュール（２００）の所与の反復（２３１、２３２、２３３）において前記アップリンク制御データ（３００）を送信するように設定され、前記アップリンク制御データ（３００）が、前記所与の反復（２３１、２３２、２３３）における前記少なくとも１つのアクティブ状態（２８２、２８３）の前記延長（２０９）を示す、
請求項１に記載の端末（１３０）。
前記少なくとも１つのプロセッサ（１３０１）が、前記インターフェース（１３０３）を介して、前記スケジュール（２００）の前記所与の反復（２３１、２３２、２３３）においてサービスのアップリンクペイロードデータ（２５１）を送信するように設定され、
前記少なくとも１つのプロセッサ（１３０１）が、前記インターフェース（１３０３）を介して、前記スケジュール（２００）の前記所与の反復（２３１、２３２、２３３）においておよび前記延長（２０９）の間に、前記サービスのダウンリンクペイロードデータ（２６１）を受信するように設定され、
前記少なくとも１つのプロセッサ（１３０１）が、前記サービスのラウンドトリップレイテンシ（２６０）に関する知識に基づいて前記延長（２０９）の持続時間を決定するように設定された、
請求項２に記載の端末（１３０）。
前記少なくとも１つのプロセッサ（１３０１）が、前記インターフェース（１３０３）を介して、前記スケジュール（２００）の前記所与の反復（２３１、２３２、２３３）においておよび前記延長（２０９）の間に、ダウンリンクページング信号を受信するように設定され、
前記少なくとも１つのプロセッサ（１３０１）が、前記ダウンリンクページング信号の前記受信に応答して、前記ワイヤレスリンク（１０１）上でデータ接続（１６０）を確立するためのアタッチプロシージャ（２８８）を実施するように設定され、
前記少なくとも１つのプロセッサ（１３０１）が、前記データ接続（１６０）上で前記ダウンリンクペイロードデータ（２６１）を受信するように設定された、
請求項３に記載の端末（１３０）。
前記少なくとも１つのプロセッサ（１３０１）が、前記延長（２０９）の前記決定された持続時間に基づいて、および前記アップリンクペイロードデータ（２５１）を送信したことに応答して、タイマーを初期化するように設定された、
請求項３または４に記載の端末（１３０）。
前記少なくとも１つのプロセッサ（１３０１）が、前記ダウンリンクペイロードデータ（２６１）を受信したことに応答して前記スケジュール（２００）にフォールバックするように設定された、
請求項３から５のいずれか一項に記載の端末（１３０）。
前記少なくとも１つのプロセッサ（１３０１）が、前記所与の反復（２３１、２３２、２３３）においておよび前記延長（２０９）より前に、前記少なくとも１つのアクティブ状態（２８２、２８３）から選択された接続状態（２８３）において動作するように前記インターフェース（１３０３）を制御するように設定され、前記インターフェース（１３０３）が、前記接続状態（２８３）において前記ワイヤレスリンク（１０１）のデータ接続（１６０）を維持するように設定され、
前記少なくとも１つのプロセッサ（１３０１）が、前記延長（２０９）の間に、前記スケジュール（２００）の前記所与の反復（２３１、２３２、２３３）において前記少なくとも１つのアクティブ状態（２８２、２８３）から選択されたアイドル状態（２８２）において動作するように前記インターフェース（１３０３）を制御するように設定され、前記インターフェース（１３０３）が、前記アイドル状態において、前記データ接続（１６０）を解放することと、ダウンリンクページング信号をリッスンすることとを行うように設定された、
請求項２から６のいずれか一項に記載の端末（１３０）。
前記延長（２０９）の持続時間が、前記スケジュール（２００）による前記少なくとも１つのアクティブ状態（２８２、２８３）の持続時間の５０％以上、随意に２００％以上、さらに随意に５００％以上であり、および／または
前記延長（２０９）の前記持続時間が、前記スリープ状態（２８１）の持続時間の一部分である、
請求項２から７のいずれか一項に記載の端末（１３０）。
前記スケジュール（２００）が、間欠受信（ＤＲＸ）サイクルを実装し、
前記延長（２０９）が、前記ＤＲＸサイクルの非アクティビティタイマー（１２５）を一時的に再設定することによって実装され、前記非アクティビティタイマーは、前記インターフェース（１３０３）が、ダウンリンクペイロードデータ（２６１）を予想するとき、その間に前記少なくとも１つのアクティブ状態（２８２、２８３）において動作を続けるように制御される、継続時間を定義する、
請求項１から８のいずれか一項に記載の端末（１３０）。
前記少なくとも１つのプロセッサ（１３０１）が、前記ワイヤレスリンク（１０１）上で前記ネットワーク（１００）とのデータ接続（１６０）を確立するためのアタッチプロシージャ（２８８）の間に、前記アップリンク制御データ（３００）を送信するように設定された、
請求項１から９のいずれか一項に記載の端末（１３０）。
前記アップリンク制御データ（３００）が、前記一時的な延長（２０９）の持続時間（２１９）を示す、
請求項１から１０のいずれか一項に記載の端末（１３０）。
前記少なくとも１つのプロセッサ（１３０１）が、前記アップリンク制御データ（３００）の確認応答を示すダウンリンク制御データ（３１０）を受信するように設定され、
前記少なくとも１つのプロセッサ（１３０１）が、前記確認応答に基づいて、前記一時的な延長（２０９）を選択的に実装するように設定された、
請求項１から１１のいずれか一項に記載の端末（１３０）。
前記ダウンリンク制御データ（３１０）が、前記一時的な延長（２０９）の持続時間（２１９）をさらに示す。
請求項１２に記載の端末（１３０）。
前記スケジュール（２００）が反復的であり、
前記少なくとも１つのプロセッサ（１３０１）が、前記スケジュール（２００）の第１の反復（２３１、２３２、２３３）において前記一時的な延長（２０９）を実装するように設定され、
前記少なくとも１つのプロセッサ（１３０１）が、遅くとも前記スケジュール（２００）の第２の反復（２３１、２３２、２３３）までには、前記スケジュール（２００）にフォールバックするように設定され、前記第２の反復（２３１、２３２、２３３）が、前記第１の反復（２３１、２３２、２３３）に隣接および後続する、
請求項１から１３のいずれか一項に記載の端末（１３０）。
前記少なくとも１つのプロセッサ（１３０１）が、サービスのダウンリンクペイロードデータ（２６１）を受信する必要に応答して、前記一時的な延長（２０９）を選択的にトリガするように設定され、
前記少なくとも１つのプロセッサ（１３０１）が、前記延長（２０９）の間に、前記ダウンリンクペイロードデータ（２６１）を受信するように設定された、
請求項１から１４のいずれか一項に記載の端末（１３０）。
前記スケジュールが、ネットワーク（１００）とネゴシエートされるか、またはあらかじめ定義された、
請求項１から１５のいずれか一項に記載の端末（１３０）。
− 端末（１３０）から、前記端末（１３０）のインターフェース（１３０３）を、少なくとも１つのアクティブ状態（２８２、２８３）とスリープ状態（２８１）との間で切り替えるためのスケジュール（２００）の少なくとも１つのアクティブ状態（２８２、２８３）の一時的な延長（２０９）を示すアップリンク制御データ（３００）を受信するように設定された少なくとも１つのプロセッサ（１１２１）
を備える、ネットワーク（１００）のネットワークノード（１１２）。
− 少なくとも１つのプロセッサを有するネットワークノード（１１２）と、
− 基地局と通信するように設定されたインターフェース（１３０３）と、少なくとも１つのプロセッサとを有する端末（１３０）と
を備える、システムであって、
前記端末（１３０）の前記少なくとも１つのプロセッサが、スケジュール（２００）に従って、少なくとも１つのアクティブ状態（２８２、２８３）とスリープ状態（２８１）との間で切り替えるように前記端末（１３０）の前記インターフェース（１３０３）を制御するように設定され、
端末（１３０）および前記基地局が、前記少なくとも１つのアクティブ状態（２８２、２８３）の一時的な延長（２０９）を示すアップリンク制御データ（３００）を通信するように設定された、
システム。
− スケジュールに従って、少なくとも１つのアクティブ状態とスリープ状態との間で切り替えるように、ネットワークに接続された端末のインターフェースを制御することと、
− 前記ネットワークに、前記少なくとも１つのアクティブ状態の一時的な延長を示すアップリンク制御データを送信することと
を含む、方法。
− 端末からアップリンク制御データを受信することであって、前記アップリンク制御データが、少なくとも１つのアクティブ状態とスリープ状態との間で前記端末のインターフェースを切り替えるためのスケジュールの少なくとも１つのアクティブ状態の一時的な延長を示す、受信すること
を含む、方法。