(58)【調査した分野】(Int.Cl.,DB名)
前記少なくとも1つのプロセッサ(1301)が、前記インターフェース(1303)を介して、前記スケジュール(200)の前記所与の反復(231、232、233)においてサービスのアップリンクペイロードデータ(251)を送信するように設定され、
前記少なくとも1つのプロセッサ(1301)が、前記インターフェース(1303)を介して、前記スケジュール(200)の前記所与の反復(231、232、233)においておよび前記延長(209)の間に、前記サービスのダウンリンクペイロードデータ(261)を受信するように設定され、
前記少なくとも1つのプロセッサ(1301)が、前記サービスのラウンドトリップレイテンシ(260)に関する知識に基づいて前記延長(209)の持続時間を決定するように設定された、
請求項2に記載の端末(130)。
前記少なくとも1つのプロセッサ(1301)が、前記インターフェース(1303)を介して、前記スケジュール(200)の前記所与の反復(231、232、233)においておよび前記延長(209)の間に、ダウンリンクページング信号を受信するように設定され、
前記少なくとも1つのプロセッサ(1301)が、前記ダウンリンクページング信号の前記受信に応答して、前記ワイヤレスリンク(101)上でデータ接続(160)を確立するためのアタッチプロシージャ(288)を実施するように設定され、
前記少なくとも1つのプロセッサ(1301)が、前記データ接続(160)上で前記ダウンリンクペイロードデータ(261)を受信するように設定された、
請求項3に記載の端末(130)。
前記少なくとも1つのプロセッサ(1301)が、前記延長(209)の前記決定された持続時間に基づいて、および前記アップリンクペイロードデータ(251)を送信したことに応答して、タイマーを初期化するように設定された、
請求項3または4に記載の端末(130)。
前記少なくとも1つのプロセッサ(1301)が、前記ダウンリンクペイロードデータ(261)を受信したことに応答して前記スケジュール(200)にフォールバックするように設定された、
請求項3から5のいずれか一項に記載の端末(130)。
前記少なくとも1つのプロセッサ(1301)が、前記所与の反復(231、232、233)においておよび前記延長(209)より前に、前記少なくとも1つのアクティブ状態(282、283)から選択された接続状態(283)において動作するように前記インターフェース(1303)を制御するように設定され、前記インターフェース(1303)が、前記接続状態(283)において前記ワイヤレスリンク(101)のデータ接続(160)を維持するように設定され、
前記少なくとも1つのプロセッサ(1301)が、前記延長(209)の間に、前記スケジュール(200)の前記所与の反復(231、232、233)において前記少なくとも1つのアクティブ状態(282、283)から選択されたアイドル状態(282)において動作するように前記インターフェース(1303)を制御するように設定され、前記インターフェース(1303)が、前記アイドル状態において、前記データ接続(160)を解放することと、ダウンリンクページング信号をリッスンすることとを行うように設定された、
請求項2から6のいずれか一項に記載の端末(130)。
前記延長(209)の持続時間が、前記スケジュール(200)による前記少なくとも1つのアクティブ状態(282、283)の持続時間の50%以上、随意に200%以上、さらに随意に500%以上であり、および/または
前記延長(209)の前記持続時間が、前記スリープ状態(281)の持続時間の一部分である、
請求項2から7のいずれか一項に記載の端末(130)。
前記少なくとも1つのプロセッサ(1301)が、前記ワイヤレスリンク(101)上で前記ネットワーク(100)とのデータ接続(160)を確立するためのアタッチプロシージャ(288)の間に、前記アップリンク制御データ(300)を送信するように設定された、
請求項1から9のいずれか一項に記載の端末(130)。
前記少なくとも1つのプロセッサ(1301)が、前記アップリンク制御データ(300)の確認応答を示すダウンリンク制御データ(310)を受信するように設定され、
前記少なくとも1つのプロセッサ(1301)が、前記確認応答に基づいて、前記一時的な延長(209)を選択的に実装するように設定された、
請求項1から11のいずれか一項に記載の端末(130)。
前記少なくとも1つのプロセッサ(1301)が、サービスのダウンリンクペイロードデータ(261)を受信する必要に応答して、前記一時的な延長(209)を選択的にトリガするように設定され、
前記少なくとも1つのプロセッサ(1301)が、前記延長(209)の間に、前記ダウンリンクペイロードデータ(261)を受信するように設定された、
請求項1から14のいずれか一項に記載の端末(130)。
− 端末(130)から、前記端末(130)のインターフェース(1303)を、少なくとも1つのアクティブ状態(282、283)とスリープ状態(281)との間で切り替えるためのスケジュール(200)の少なくとも1つのアクティブ状態(282、283)の一時的な延長(209)を示すアップリンク制御データ(300)を受信するように設定された少なくとも1つのプロセッサ(1121)
を備え、
前記少なくとも1つのアクティブ状態が、前記端末(130)が前記ネットワークとの間のデータ接続を維持している接続状態を含み、前記データ接続は、前記スリープ状態の間は確立されず、
前記アップリンク制御データは、データ接続を確立するためのプロシージャの間に通信される制御メッセージ上にピギーバックされる、ネットワーク(100)のネットワークノード(112)。
− スケジュールに従って、少なくとも1つのアクティブ状態とスリープ状態との間で切り替えるように、ネットワークに接続された端末のインターフェースを制御することと、
− 前記ネットワークに、前記少なくとも1つのアクティブ状態の一時的な延長を示すアップリンク制御データを送信することと
を含み、
前記少なくとも1つのアクティブ状態が、前記端末が前記ネットワークとの間のデータ接続を維持している接続状態を含み、前記データ接続は、前記スリープ状態の間は確立されず、
前記アップリンク制御データは、データ接続を確立するためのプロシージャの間に通信される制御メッセージ上にピギーバックされる、方法。
− 端末からアップリンク制御データを受信することであって、前記アップリンク制御データが、少なくとも1つのアクティブ状態とスリープ状態との間で前記端末のインターフェースを切り替えるためのスケジュールの少なくとも1つのアクティブ状態の一時的な延長を示す、受信すること
を含み、
前記少なくとも1つのアクティブ状態が、前記端末が前記ネットワークとの間のデータ接続を維持している接続状態を含み、前記データ接続は、前記スリープ状態の間は確立されず、
前記アップリンク制御データは、データ接続を確立するためのプロシージャの間に通信される制御メッセージ上にピギーバックされる、方法。
【発明を実施するための形態】
【0018】
以下では、添付の図面を参照しながら本発明の実施形態が詳細に説明される。実施形態の以下の説明は、限定的な意味にとられるべきではないことを理解されたい。本発明の範囲は、以下で説明される実施形態によってまたは図面によって限定されるものではなく、これらは、例示的なものにすぎないものととられる。
【0019】
図面は、概略表現であると見なされるべきであり、図面に例示されている要素は、必ずしも一定の縮尺で示されているとは限らない。むしろ、様々な要素は、それらの機能および一般的目的が当業者に明らかになるように表される。図面に示されるかまたは本明細書で説明される機能ブロック、デバイス、構成要素、または他の物理または機能ユニットとの間の接続または結合は、間接的接続または結合によっても実装され得る。また、ワイヤレス接続を介して構成要素間の結合が確立され得る。機能ブロックは、ハードウェア、ファームウェア、ソフトウェア、またはそれらの組合せで実装され得る。
【0020】
以下で、端末のインターフェースの少なくとも1つのアクティブ状態とスリープ状態との間で切り替える技法が説明される。時々、少なくとも1つのアクティブ状態とスリープ状態との間で切り替えるそのような技法は、DRXと呼ばれる。単に、時々インターフェースのアクティブ状態をアクティブ化することによって、端末の電力消費が低減され得る。
【0021】
切替えは、スケジュールに従って実装され得る。たとえば、スケジュールは、端末とネットワークとの間でネゴシエートされ得る。スケジュールのそのようなネゴシエーションは、UL制御シグナリングおよび/またはDL制御シグナリングを伴い得る。時々、ネゴシエーションは、端末とネットワークとの間でワイヤレスリンク上でデータ接続を確立するためのアタッチプロシージャの一部として行われ得る。他の例では、スケジュールは、たとえば、確定された規格などに従ってあらかじめ定義されることも可能であろう。
【0022】
スケジュールは、反復的であり得、すなわち、異なる状態間の切替えの反復を定義し得る。たとえば、スケジュールは、時間領域において反復的であり得る。いくつかの例では、反復的なスケジュールが後続の反復についての周期性を実装することが可能である。反復的なスケジュールは、厳密に周期的ではないが、反復ごとに一定の変動を示すことも可能である。スケジュールの反復は、時間領域において定義されることを必要とされず、反復がイベント領域において定義されることも可能であろう。たとえば、スケジュールの異なる反復がイベントトリガ型であり得る。イベントの一例は、ULデータを送信する必要である。イベントのさらなる例は、端末のユーザアクティビティまたはモビリティである。いくつかの例では、反復は、時間領域およびイベント領域において定義され得る。
【0023】
スケジュールは、少なくとも1つのアクティブ状態とスリープ状態との間で切り替えるためのタイミングを示し得る。これは、ネットワークが、その場合、端末が到達可能である時間に気づき得るので、端末へのDLデータ送信を可能にし得る。
【0024】
たとえば、スケジュール、たとえば、各反復についてのスケジュールは、インターフェースの1つまたは複数のアクティブ状態がその間にアクティブ化される、一定のオン時間を含み得る。オン時間の間に、1つまたは複数のアクティブ状態のうちの異なるアクティブ状態の間で切り替えることが可能であり得る。さらに、各反復は、インターフェースのスリープ状態がその間にアクティブ化される、オフ時間を含み得る。
【0025】
インターフェースは、スリープ状態において動作するとき、完全にまたはほとんど電源切断され得る。時々、スリープ状態は、ドーマント状態または電力セーフ状態とも呼ばれる。たとえば、スリープ状態の間に、インターフェースのアナログフロントエンドが無効にされ得る。これは、アナログ増幅器、アナログデジタル変換器のうちの1つまたは複数を電源切断することを含み得る。たとえば、スリープ状態の間に、電源電圧がアナログ増幅器および/またはアナログデジタル変換器に与えられないことがある。概して、スリープ状態の間に、インターフェースは、ワイヤレスリンク上でDLデータを受信するのに不適当であり得る。端末は、スリープ状態において位置更新を送らないことがある。したがって、概して、スリープ状態において、端末にDLデータを送ることが可能でないことがある。スリープ状態の間に、端末がネットワークのそれぞれのリポジトリに登録されたままであることが可能である。このすべては、スリープ状態における端末の低電力消費を可能にする。
【0026】
様々なアクティブ状態が考えられる。例は、接続状態を含む。接続状態において、端末とネットワークとの間の進行中のデータ接続が維持され得る。たとえば、データ接続は、国際標準化機構(ISO)ITU−T X.200(07/1994)文書に従って、開放型システム間相互接続(OSI)モデルのネットワークレイヤ上に実装され得る。たとえば、データ接続は、ULペイロードチャネルおよび/またはDLペイロードチャネル上のデータを識別するためのベアラを含み得る。端末は、接続状態においてネットワークに頻度が高い位置更新を送信し得る。たとえば、端末が現在キャンピングするサービングセルが、ネットワークに適時に所与の瞬間において知られ得る。接続状態において、端末のインターフェースは、完全に電源投入され得る。3GPP LTEフレームワークでは、一例は、RRC接続状態である。一般に、接続状態は、端末の著しい電力消費に関連する。
【0027】
アクティブ状態のさらなる例は、アイドル状態を含む。たとえば、アイドル状態は、接続状態とスリープ状態との混合であり得る。これのために、時々、アイドル状態は、非接続接続状態(disconnected connected state)とも呼ばれる。アイドル状態において、端末とネットワークとの間の進行中のデータ接続を維持することを必要とされないことがある。たとえば、アイドル状態では、接続状態とは異なり、端末が接続可能であるセルラーネットワークの特定のサービングセルは、ネットワークに知られていないことがある。端末は、たとえば、トラッキングエリアを変更するときなど、頻度が低い位置更新を送信することも送信しないこともある。たとえば、アイドル状態において、ネットワークが端末をページングすること、すなわち、端末にDLページングを送ることが可能であり得る。しかしながら、DLペイロードデータを直接送ることが可能でないことがある。DLページングは、端末を接続状態に遷移するようにトリガし得る。これは、ワイヤレスリンクのペイロードチャネルを確立するためのアタッチプロシージャを実施することを伴い得る。たとえば、アイドル状態において、端末のインターフェースのアナログフロントエンドが、完全に電源切断されないが、概して機能的であることがある。しかしながら、制限された復調/復号機能などを含み得る、デジタルフロントエンド中のいくつかの機能が無効にされ得る。3GPP LTEフレームワークにおけるアイドル状態の一例は、RRCアイドル状態である。アイドル状態の一例は、R14について3GPPにおいて議論されているRRC接続非アクティブ状態である。
【0028】
たとえば、スケジュールは、スリープ状態と組み合わせて1つまたは複数のアクティブ状態を実装し得る。
【0029】
様々な例によれば、スケジュールから一時的に逸脱するための技法が提供される。言い換えれば、スケジュールからの一時的な例外を実装することを可能にする様々な例による技法が提供される。たとえば、スケジュールからのそのような一時的な逸脱は、1つまたは複数の反復のオン時間を増加または減少させることを含み得る。たとえば、スケジュールからのそのような一時的な逸脱は、スケジュールの1つまたは複数の反復のオフ時間を増加または減少させることを含み得る。たとえば、スケジュールからのそのような一時的な逸脱は、スケジュールの1つまたは複数の反復のうちの反復の持続時間を増加または減少させることを含み得る。したがって、一時的な逸脱を設定するための様々な可能性が存在する。たとえば、そのような一時的な延長は、オン時間を定義する少なくとも1つのアクティブ状態の延長に対応し得る。それにより、端末および/またはネットワークの一時的な必要に従ってスケジュールを動的に調整することが可能である。
【0030】
様々な例によれば、端末は、スケジュールからのそのような逸脱をトリガし得る。次いで、端末は、ネットワークに、端末によって想定されるスケジュールからの一時的な逸脱を示すアップリンク制御データを送信し得る。それにより、ネットワークは、それに応じて、DLデータを送信するための機会の任意の追加のウィンドウを利用するように、または一時的な逸脱により失敗すると見なされるDL送信試みを回避するように通知され得る。
【0031】
たとえば、一時的な逸脱は、オン時間の延長として、すなわち、少なくとも1つのアクティブ状態の延長として実装されることが可能であり得る。これは、DLペイロードデータなど、DLデータを受信するための機会の追加のウィンドウを開き得る。
【0032】
端末によって実行されるサービスがDLペイロードデータを予想しているシナリオを考慮することができる。このDLペイロードデータは、ネットワーク主導型/端末終了トラフィックであり得る。たとえば、DLペイロードデータは、サービスのULペイロードデータの送信によってトリガされ得る。サービスに関連するラウンドトリップレイテンシ、たとえば、端末からネットワークを介して、サービスをホストするサーバへの、および戻って、ネットワークを介して端末への通信のために定義されたレイテンシにより、DLペイロードデータは、オン時間の満了の後に端末に到着し得る。その場合、インターフェースは、すでにスリープ状態に入っており、その時間においてネットワークによって到達可能でないので、端末によって実行されるサービスは、DLペイロードデータを受信しないことになる。次のオン時間までの継続時間が大きい場合、これは、サーバとのデバイス通信にとっての困難を課し得る。そのようなシナリオは、端末が、インターネットサーバにULペイロードデータを送信しているときに発生し得、ここで、インターネットサーバは、オン時間よりも長い遅延で端末への応答を与える。そのようなシナリオが発生し得る他の例は、端末が、いくつかの構成設定の更新のためにサービスをホストするサーバをポーリングすることを含む。シナリオが発生し得るまたさらなる例は、端末が、ファームウェア更新のためにサービスをホストするサーバをポーリングすることを含む。
【0033】
本明細書で説明される技法に基づいて、DLペイロードデータはオン時間の満了の後におよびオフ時間の間に、すなわち、インターフェースがスリープ状態にすでに切り替わった時点において到着する、そのようなシナリオを予期することが可能であり得る。次いで、本明細書で説明される様々な例によれば、端末がネットワークにUL制御データを送信することが可能であり得、UL制御データは、スケジュールからの一時的な逸脱を示す。たとえば、少なくとも1つのアクティブ状態が延長される場合、機会のウィンドウが、予想されるDLペイロードデータを受信するために開いていることがある。
【0034】
図1は、ネットワーク100に関する態様を例示する。
図1は、ネットワーク100のアーキテクチャに関する態様を例示する。
図1の例によるネットワーク100は、3GPP LTEアーキテクチャを実装する。3GPP LTEによれば、ワイヤレスリンク101は、RAN114において定義される。ワイヤレスリンク101は、発展型ノードB(eNB)112の形態の基地局と1つまたは複数のUE130との間で定義される。ワイヤレスリンク101は、ペイロードチャネルおよび/または制御チャネルなど、1つまたは複数のチャネルを実装し得る。
【0035】
さらに、ネットワーク100はコアネットワーク113を含む。コアネットワーク113はRAN114と通信している。コアネットワーク113は、制御レイヤとデータレイヤとを含む。制御レイヤは、ホーム加入者サーバ(HSS)115、モバイル管理エンティティ(MME)116、ならびにポリシーおよび課金ルール機能(PCRF)119など、制御ノードを含む。データレイヤは、サービングゲートウェイ(SGW)117およびパケットデータネットワークゲートウェイ(PGW)118など、ゲートウェイノードを含む。
【0036】
データ接続160が、RAN114を介してUE130−1とコアネットワーク113のデータレイヤとの間に、およびアクセスポイント121のほうへ確立される。たとえば、アクセスポイント121を介してインターネットまたは別のパケットデータネットワークとの接続が確立され得る。パケットデータネットワークまたはインターネットのサーバが、データ接続160を介してペイロードデータが通信されるサービスをホストし得る。データ接続160は、専用ベアラまたはデフォルトベアラなど、1つまたは複数のベアラを含み得る。データ接続160は、RRCレイヤ上で定義され得る。したがって、データ接続160を確立することは、OSIネットワークレイヤ制御シグナリングを含み得る。データ接続160によって、リソースが、物理アップリンク共有チャネル(PUSCH)および/または物理ダウンリンク共有チャネル(PDSCH)など、ペイロードチャネル上に割り振られ得る。
【0037】
コアネットワーク113のネットワークノード115〜119、121の一般的機能および目的は、当技術分野でよく知られており、したがって、このコンテキストにおいて詳細な説明が必要とされない。
【0038】
3GPP LTEフレームワークにおけるネットワーク100の例示は、例示的な目的のためのものにすぎない。同様の技法が、モバイル通信用グローバルシステム(GSM)、広帯域符号分割多重(WCDMA)、汎用パケット無線サービス(GPRS)、GSM進化型高速データレート(EDGE)、拡張GPRS(EGPRS)、ユニバーサルモバイルテレコミュニケーションズシステム(UMTS)、および高速パケットアクセス(HSPA)など、様々な種類の3GPP指定アーキテクチャに容易に適用され得る。たとえば、本明細書で説明される技法は、3GPP eNB−IoTまたはMTCシステムあるいは3GPP新無線(NR)システムに適用され得る。たとえば、3GPP RP−161321およびRP−161324を参照されたい。さらに、それぞれの技法は、Bluetooth、衛星ネットワーク、IEEE802.11x Wi−Fi技術など、様々な種類の非3GPP指定ネットワークに容易に適用され得る。
【0039】
図2は、端末130に関する態様を例示する。端末130は、プロセッサ1301、たとえば、マルチコアプロセッサを含む。端末130は、メモリ1302、たとえば、不揮発性メモリをさらに含む。端末130は、インターフェース1303をさらに含む。
【0040】
インターフェース1303は、デジタルフロントエンドおよび/またはアナログフロントエンドを含み得る。アナログフロントエンドは、1つまたは複数のアンテナに接続可能であり得る。たとえば、インターフェース1303は、1つまたは複数のアンテナポートを含み得る。たとえば、アナログフロントエンドは、変調および符号化された信号を受信するための低雑音増幅器およびアナログデジタル変換器など、増幅器を含み得る。アナログフロントエンドは、送信のためのデジタルアナログ変換器を含み得る。たとえば、デジタルフロントエンドは、データを受信したとき、復調、復号、デインターリービング、チェックサムの計算など、タスクを実施するように設定され得る。たとえば、デジタルフロントエンドは、OSIモデルに従って下位レベル機能を実装し得る。一般に、復調および復号などのタスクが、かなりのエネルギー消費にも関連する。
【0041】
インターフェース1303は、異なる動作状態に従って動作し得る。これらの状態は、インターフェース1303が、ワイヤレスリンク101上で送信された一部または全部のDLデータおよび/または信号を受信することが可能である、1つまたは複数のアクティブ状態を含み得る。たとえば、アクティブ状態では、増幅器および/またはアナログデジタル変換器は、少なくとも時々および/または少なくとも部分的に電源電圧を与えられ得る。これらの状態は、インターフェース1303が、ワイヤレスリンク101上で送信されたDLデータを受信するのに不適当である、スリープ状態をさらに含み得る。一般に、少なくとも1つのアクティブ状態のうちの1つに従って動作するインターフェース1303と比較した場合に、スリープ状態に従ってインターフェース1303が動作する場合、端末130の電力消費が低減される。
【0042】
メモリ1302は、プロセッサ1301によって実行され得る制御命令を記憶し得る。制御命令を実行することは、プロセッサ1301に電力節約の技法を実施させることができ、これらは、スケジュールに従って、少なくとも1つのアクティブ状態とスリープ状態との間で切り替えるようにインターフェース1303を制御することを含み得る。
【0043】
図3は、様々な例による、方法のフローチャートである。たとえば、
図3による方法は、端末130のプロセッサ1301によって実行され得る。
【0044】
最初に、ブロック6001において、端末のインターフェースが、少なくとも1つのアクティブ状態とスリープ状態との間で切り替えるように制御される。いくつかの例では、これは、スケジュールに従って発生し得る。概して、スケジュールは、ネットワークに知られていることがある。これは、スケジュールをネゴシエートすることによって発生し得る。スケジュールは、確定されたルールに従って定義されることも可能であろう。スケジュールは周期的であり得る。スケジュールは、イベントトリガ型挙動を定義することも可能である。たとえば、スケジュールは、ULペイロードデータの送信の後のオン持続時間を定義することができる。ここで、オン持続時間をトリガするイベントは、ULデータを送信する必要であろう。スケジュールは、端末とネットワークとの間でネゴシエートされ得る。たとえば、
図3による方法は、ブロック6001より前に、端末とネットワークとの間でスケジュールをネゴシエートすることをさらに含み得る。
【0045】
ブロック6001によるそのような切替えは、DRXサイクルを実装し得る。いくつかの例では、3GPP LTEフレームワークに従って、ブロック6001において切替えを実装するためのスケジュールは、3GPP LTEフレームワークに従って接続DRXおよび/またはアイドルDRXを実装し得る。しかしながら、本明細書で説明されるいくつかの例は、3GPP LTE DRXをしのぐか、または代替実装形態を提供し得る。いくつかの例では、ブロック6001による切替えは、イベントトリガ型であり得る。たとえば、オン持続時間は、ULデータを送信する必要に応答してアクティブ化され得る。
【0046】
次に、ブロック6002において、UL制御データがネットワークに送信される。UL制御データは、スケジュールからの一時的な逸脱を示す。
図3の例では、これは、少なくとも1つのアクティブ状態の一時的な延長として実装される。たとえば、上記の例では、ULデータを送信する必要に応答して、拡張されたオン持続時間が示され得る。
【0047】
たとえば、UL制御データは、専用制御メッセージ、たとえば、RRCレイヤ制御メッセージ中に含まれ得る。さらなる例では、UL制御データが、他の目的を果たす制御メッセージ、たとえば、データ接続またはペイロードチャネルを確立するためのアタッチプロシージャの間に通信される制御メッセージ上にピギーバックされることが可能である。
【0048】
スケジュールからの一時的な逸脱は、オン時間の延長に対応し得る。したがって、一時的な逸脱は、端末のインターフェースの少なくとも1つのアクティブ状態の延長に対応し得る。延長の持続時間は、UL制御データによっても示されることが可能であり、持続時間は、代替的にネットワーク定義され得る。
【0049】
方法は、UL制御データを送信することおよびブロック6002に応答して、スケジュールからの一時的な逸脱を実装することをさらに含み得る。時々、一時的な逸脱は、UL制御データを送信した後にネットワークの確認応答に応じて選択的に実装され得る。
【0050】
確認応答は、明示的確認応答または暗黙的確認応答であり得る。確認応答は、肯定応答(PACK)または否定応答(NACK)であり得る。たとえば、ネットワークがスケジュールからの一時的な逸脱を否定応答した場合、一時的な逸脱の実装が抑圧され得る。たとえば、ネットワークがスケジュールからの一時的な逸脱を肯定応答した場合、一時的な逸脱の実装が実行され得る。確認応答を含むそれぞれのDL制御データは、随意に、逸脱の持続時間、たとえば、オン時間の延長の持続時間をも含み得る。
【0051】
図4は、eNB112に関する態様を例示する。eNB112は、プロセッサ1121、たとえば、マルチコアプロセッサを含む。eNB112は、メモリ1122、たとえば、不揮発性メモリをさらに含む。eNB112は、インターフェース1123をさらに含む。インターフェース1123は、デジタルフロントエンドおよび/またはアナログフロントエンドを含み得る。アナログフロントエンドは、1つまたは複数のアンテナに接続可能であり得る。たとえば、インターフェース1123は、1つまたは複数のアンテナポートを含み得る。たとえば、アナログフロントエンドは、ワイヤレスリンク101上で、変調および符号化された信号を受信するための低雑音増幅器およびアナログデジタル変換器など、増幅器を含み得る。
【0052】
メモリ1122は、プロセッサ1121によって実行され得る制御命令を記憶し得る。制御命令を実行することは、プロセッサ1121に、eNB112に接続可能な端末130における電力節約の技法を実施させることができる。そのような技法は、端末130において少なくとも1つのアクティブ状態とスリープ状態との間で切り替えるためのスケジュールに従ってその端末との通信を同期させることを含み得る。スケジュールは、端末とネゴシエートされ得る。
【0053】
図5は、様々な例による、方法のフローチャートである。たとえば、
図5による方法は、端末の電力節約の技法を実施するためにプロセッサ1121によって実行され得る。
【0054】
最初に、ブロック6011において、端末において、少なくとも1つのアクティブ状態とスリープ状態との間で切り替えるためのスケジュールがネゴシエートされる。ブロック6011は、端末におよび/または端末から制御データを送信および/または受信することを含み得る。ブロック6011は、一方向または二方向ネゴシエーションであり得る。ブロック6011は随意である。たとえば、スケジュールをネゴシエートする代わりに、スケジュールは、固定してあらかじめ定義され得る。
【0055】
次に、ブロック6012において、UL制御データが端末から受信される。UL制御データは、スケジュールからの一時的な逸脱を示す。
図5の例では、一時的な逸脱は、この場合も、少なくとも1つのアクティブ状態の延長として実装される。
【0056】
方法は、スケジュールからの一時的な逸脱に従って、DLペイロードデータおよび/またはDL制御データの送信を実装することをさらに含み得る。
【0057】
たとえば、
図5の方法は、
図3の方法に相互に関係し得る。
【0058】
図6は、反復的なスケジュール200に関する態様を概略的に例示する。
図6では、説明の目的で、スケジュール200の3つの反復231〜233が例示されている。しかしながら、スケジュール200は、より多数の反復231〜233またはより少数の反復231〜233を含み得る。
【0059】
各反復231〜233は、
図6の例によれば、オン時間201と、オフ時間240とを含む。たとえば、反復231において、オン時間201の持続時間211は、オフ時間240の持続時間212よりも短い。持続時間211、212は、合計すると反復231全体の持続時間213になる。
図6の例では反復231〜233の周期性が実装されるが、他の例では、異なる反復が異なる持続時間を有し得る。
【0060】
オン時間201において、端末130のインターフェース1303は、接続状態283において動作する。オフ時間240において、端末130のインターフェース1303は、スリープ状態281において動作する。オン時間201の間に接続状態283において動作するとき、インターフェース1303は、データ接続160上でDLデータを受信する準備ができている。これは、
図6の例における反復232に関して例示され、ここで、DLペイロードデータ261は、ネットワーク100によっておよびスケジュール200に従って送信され、すなわち、DLペイロードデータ261は、インターフェース1303が接続状態283において動作するとき、オン時間201の間に端末130に到着する。
【0061】
図6の例では、DLペイロードデータ261の受信が非アクティビティタイマー215をトリガする。非アクティビティタイマー215は、ULペイロードデータ261の送信によってもトリガされ得る。また、オン時間201の間の他のアクティビティが、非アクティビティタイマー215をトリガし得る。非アクティビティタイマー215は、(
図6中の破線によって例示されている)オン時間201の延長207を実装する。これは、あらかじめ定義された挙動であるので、スケジュール200に従うものである。延長207は、非アクティビティタイマー215が満了していない間、さらなるDLペイロードデータを受信するための機会の追加のウィンドウを開く。非アクティビティタイマー215は、スケジュール200の一部であり、したがって、ネットワーク100は、非アクティビティタイマー215により、DLペイロードデータを送信するための機会の別のウィンドウが開かれることに気づいている。
【0062】
以上のことから諒解されるように、スケジュール200は、完全に決定論的挙動を規定することが必要とされない。たとえば、スケジュール200は、異なる状態間で切り替えることおよび/またはタイマーを使用することおよび/またはオン時間201とオフ時間240とをアクティブ化することを行うためのルールのセットを定義し得る。しかしながら、これらのルールは、データの受信および/または送信など、いくつかの変動するものを考慮に入れることができる。したがって、状況に応じて、端末130の挙動がアプリオリに完全には定義されないことがある。
【0063】
本明細書で説明される様々な例によれば、スケジュール定義された値と比較した場合、非アクティビティタイマー215の値を、たとえば、より大きい値またはより小さい値に再設定するように、スケジュール200からの一時的な逸脱を実装することが可能であり得る。たとえば、ULペイロードデータ251を送信することに応答して、非アクティビティタイマー215が次いでトリガされ得る。非アクティビティタイマー215のために固定値を使用する代わりに、再設定された値がサービスの必要に従ってフレキシブルに調整され得る。
【0064】
図7は、端末130のインターフェース1303が動作することができる様々な状態281〜283に関する態様を概略的に例示する。
【0065】
図7の例では、スリープ状態281は、インターフェース1303のドーマント状態に対応する。ここで、端末130は、ネットワーク100から完全には切断されないが、依然として登録されている。位置更新は、端末130からネットワーク100に送信されない。したがって、ネットワーク100は、端末130の位置に気づいていない。さらに、インターフェース1303の1つまたは複数の構成要素が電源切断され得、したがって、インターフェース1303は、DLデータを受信することが可能でない。データ接続160は確立されていないことがある。時々、3GPP LTEでは、スリープ状態281は電力節約モードとも呼ばれる。3GPP TS 23.401 V13.0.0(2014−09)、セクション4.3.22「UE電力節約モード」を参照されたい。たとえば、3GPP TS 23.682 V13.4.0(2015−12)を参照されたい。
【0066】
さらなる状態282、283において、インターフェース1303は、概して、たとえば、少なくともいくつかのタイムスロットの間におよび/またはいくつかの周波数上でおよび/またはいくつかのコーディング/変調に従って、DLデータを受信する準備ができている。したがって、状態282、283は、アクティブ状態と呼ばれることがある(
図7における破線)。
【0067】
RRC接続状態283において、端末130は、ネットワーク100とのデータ接続160を維持する。TS 36.331、チャプター4.2を参照されたい。これは、セルラーネットワーク100の異なるサービングセル間のハンドオーバがデータ接続160の損失なしに実装され得ることを意味する。これについて、端末130は、ワイヤレスリンク上の通信品質に関する測定報告を送信し得る。ネットワーク100は、サービングセルに気づいている。別様に、RRCアイドル状態282において、端末130は、ネットワーク100とのデータ接続160を維持しないことがある。位置更新は、同等に低頻度で、または過程精度で送信されるにすぎず、たとえば、セルレベルで定義されないことがある。インターフェース1303は、それにもかかわらず、少なくともある程度、電源投入され得る。これは、ネットワーク100からのDLページング信号の受信を可能にし得る。インターフェース1303は、制限された復調および復号機能を実施し得る。DLページングを受信したことに応答して、端末130は、RRC接続状態283に遷移し得る。たとえば、接続状態283において動作するインターフェース1303の電力消費は、アイドル状態282において動作するインターフェースの電力消費よりも少なくとも30%だけ高くなり得る。したがって、端末130およびアクティブ状態を維持すると同時に、ページングの必要性によってもたらされるレイテンシを犠牲にして電力消費が依然として低減され得る。
【0068】
たとえば、スリープ状態281からRRC接続状態283へのまたはRRCアイドル状態282からRRC接続状態283への遷移288は、ワイヤレスリンク101のペイロードチャネルを含むデータ接続160を確立するためのアタッチプロシージャを実施することを伴い得る。たとえば、アタッチプロシージャ288は、端末130のランダムに選択されたコードおよび/または一時的な識別に基づいて、ネットワーク100にアクセスしようとするさらなる端末との衝突が緩和される、端末130のランダムアクセスを含み得る。一般に、ランダムアクセスは、OSIモデルに従って物理レイヤ上で定義される。たとえば、アタッチプロシージャ288は、代替または追加として、OSIモデルに従って上位レイヤ上で定義された制御シグナリングを含み得る。例は、RRCアタッチプロシージャを含む。
【0069】
RRC接続状態283からRRCアイドル状態282へのまたはRRC接続状態283からRRCスリープ状態281への遷移289は、RRCリリースプロシージャを含み得る。
図7では、さらに、RRCアイドル状態282からRRCスリープ状態281への遷移287が例示されている。
【0070】
図7の例では、2つのアクティブ状態282、283が例示されているが、さらなる例では、より多数のアクティブ状態がプロビジョニングされることが可能である。いくつかの例は、3GPP LTE TS 25.331、セクション7.1による、PCH状態、CELL_PCH状態、URA_PCH状態、CELL_FACH状態、およびCELL DCH状態を含み得る。さらに、
図7の例では、様々な状態281〜283が3GPP LTE RRCレイヤ機能に関して説明されたが、他の例では、他のレイヤ上でおよび/または3GPP LTE以外の他のプロトコルに従って、インターフェース1303の電力節約機能を実装することも可能である。それにもかかわらず、3GPP LTE RRCレイヤ機能のコンテキストにおいて状態281〜283について上記で説明されたような様々な性質が、他の例にも適用され得る。
【0071】
図8は、反復的なスケジュール200に関する態様を例示する。特に、
図8は、スケジュール200からの一時的な逸脱を実装することに関する態様を例示する。
図8の例は、概して、
図6の例に対応する。
【0072】
反復231において、端末130は、サービスのULペイロードデータ251を送信する。サービスは、一定のラウンドトリップレイテンシ260に関連する。ラウンドトリップレイテンシ260は、極めて長く、サービスの、ULペイロードデータ251に関連する、DLペイロードデータ261は、オン時間201の間に到着しない。DLペイロードデータ261は、オフ時間240の間に到着する。オフ時間240では、インターフェース1303は、スリープ状態281において動作する。それゆえ、インターフェース1303は、データを受信するのに不適当であり、特に、サービスのDLペイロードデータ261を受信することができない。その場合、DLペイロードデータ261の受信が次のオン時間(簡単のために
図8では例示されない)まで遅延される。これは、サービスのレイテンシを増加させる。
【0073】
反復232において、スケジュール200からの一時的な逸脱が実装される。特に、(
図8において破線によって例示されている)延長209が実装される。延長209は、オン時間202を拡張する。したがって、延長209は、反復232におけるアクティブ状態283を延長する。これは、DLペイロードデータ261を正常に受信するための機会の別のウィンドウを開く。
【0074】
図8は、延長209の持続時間219をも例示する。持続時間219は、端末130に常駐する論理によっておよび/またはネットワーク100中に常駐する論理によって決定されることが可能であり得る。単純な例では、持続時間219はまた、あらかじめ定義され得る。たとえば、延長の持続時間は、ペイロードデータ251、261が属するサービスのラウンドトリップレイテンシ260に関する知識に基づいて決定され得る。たとえば、アプリオリな知識がサービスのペイロードデータの前の送信から導出され得る。それにより、延長209の持続時間219を調整することが可能であり、したがって、電力消費の過大な増加が回避される。
【0075】
概して、延長209の持続時間219は、インターフェース1303がスケジュール200に従ってアクティブ状態282、283においてその間に動作するオン時間202の持続時間211の50%以上であり得る。いくつかの例では、持続時間219は、持続時間211の200%以上、場合によっては500%以上であり得る。それにより、追加のDLデータを受信するための機会のかなり大きいウィンドウが開いていることがある。一方、オン時間201の持続時間211は、通常、スケジュール200に従って短くなるように設定され、それにより、平均電力消費を低減し得る。
【0076】
一方、本明細書で説明される様々な技法は、特に長いオフ時間240の設定を可能にする。一時的な延長209によって、ULペイロードデータ251も送信される同じ反復231〜233内でDLペイロードデータ261を受信する可能性が増加され得る。それにより、オフ時間240の持続時間212を増加させることが可能である。たとえば、延長209の持続時間219は、持続時間212の10%以下、場合によっては2%以下、さらに場合によっては0.1%以下であり得る。絶対的には、持続時間212は、数分、数時間、さらには数日程度であり得る。特に、IOT適用例のコンテキストでは、これは、低減された電力消費を可能にし得る。
【0077】
図8の例では、一時的な逸脱は単一の反復232に制限される。したがって、反復232に隣接および後続する遅くとも反復233までには、スケジュール200への撤退(fallback)が実装される。一時的な逸脱を単一の反復に制限することによって、電力消費を最適化されたスケジュール200は、DLペイロードデータを受信する必要が検出された反復を除いてほとんど実装され得る。他の例では、一時的な逸脱はまた、単一の反復よりも多くの反復をカバーし得る。
【0078】
図9Aは、反復的なスケジュール200に関する態様を例示する。特に、
図9Aは、スケジュール200からの一時的な逸脱を実装することに関する態様を例示する。
図9Aの例は、概して、
図8の例に対応する。
【0079】
図9Aの例では、この場合も、スケジュール200の反復232において、スケジュール200からの逸脱としての延長209が実装される。ここで、インターフェース1303は、延長209の間にアイドル状態282において動作する。したがって、インターフェース1303が283における接続状態において動作する、オン時間202の満了時に、インターフェース1303は、動作モードを切り替え、次いで、アイドル状態282において動作することに進む。これは、アイドル状態282において、オン時間202の間に確立されたデータ接続160を解放することと、DLページング信号をリスニングすることとを含み得る。次いで、DLページング信号は、DLペイロードデータ261がeNB112における送信の準備ができていると、別のアタッチプロシージャ288をトリガするのを助けることができる(簡単のために
図9Aでは例示されない)。
図9Aの例に従って2つのアクティブ状態283、282を実装することによって、DLペイロードデータ261を受信するための機会のさらなるウィンドウを依然として開いている間、端末130の電力消費が低減され得る。
【0080】
図9Bは、反復的なスケジュール200に関する態様を例示する。特に、
図9Bは、スケジュール200からの一時的な逸脱を実装することに関する態様を例示する。
図9Bの例は、概して、
図9Aの例に対応する。ここで、ダウンリンクペイロードデータ261を受信した後に、非アクティビティタイマー215がトリガされる。
【0081】
図10は、反復的なスケジュール200に関する態様を例示する。特に、
図10は、スケジュール200からの一時的な逸脱を実装することに関する態様を例示する。
図10の例は、概して、
図9Aの例に対応する。
【0082】
図10の例では、この場合も、スケジュール200の反復232において、スケジュール200からの逸脱としての延長209が実装される。ここで、インターフェース1303は、延長209の間にアイドル状態282において動作する。
図10の例では、DLペイロードデータ261を受信したことに応答して、スケジュール200への撤退が実装される。これは、DLペイロードデータ261を受信した後に、一定の持続時間の間、引き続きアイドル状態282において動作する代わりに、インターフェース1303がスリープ状態240において動作することに直接切り替えることを意味する。これは、端末130の電力消費をさらに低減するのを助ける。そのようなシナリオは、他の例、たとえば、
図8の例によるスケジュール200のためにも利用され得る。
【0083】
図11は、反復的なスケジュール200に関する態様を例示する。特に、
図11は、スケジュール200からの一時的な逸脱を実装することに関する態様を例示する。
図11の例は、概して、
図8の例に対応する。
【0084】
図11の例では、延長209は、オン時間202の終わりまでにトリガされない。むしろ、ULペイロードデータ251を送信したことに応答して、延長209の決定された持続時間219に基づいて、タイマーが初期化される。それにより、予想されるラウンドトリップレイテンシ260に関する正確な測度が実装され得る。端末130の過大な電力消費が回避され得る。
【0085】
図8〜
図11で説明された様々な例は、さらなる例では互いと組み合わせられ得る。たとえば、
図11のタイマー技法は、
図9および
図10のアイドル状態技法と組み合わせられ得る。
【0086】
以上のことから諒解されるように、たとえば、3GPP LTEフレームワークにおいて、DRXサイクルに従って、異なる状態281〜283の間で切り替える技法を実装することが可能であり得る。ここで、異なる状態281〜283の間で切り替える技法を実装するために、接続DRXおよび/またはアイドルDRXが使用され得る。たとえば、延長209は、DRXの非アクティビティタイマーを一時的に再設定することによって実装され得る。非アクティビティタイマーは、インターフェース1303が、DLペイロードデータ261を予想するとき、その間に少なくとも1つのアクティブ状態282、283において動作を続けるように制御される、継続時間を指定し得る。たとえば、非アクティビティタイマーは、ULペイロードデータ251を送信したことに応答しておよび/またはDLペイロードデータを受信したことに応答してトリガされ得る。
【0087】
図12は、反復的なスケジュール200からの一時的な逸脱を示すUL制御データ300をシグナリングすることに関する態様を例示するシグナリング図である。
図12は、異なる状態281、283間の切替えに関する態様をさらに例示する。
【0088】
最初に、端末130のインターフェース1303は、スリープ状態281において動作する。次いで、スケジュール200に従って、インターフェース1303は、接続状態283に切り替える。これは、DLペイロードチャネルおよびULペイロードチャネルを確立するためのアタッチプロシージャ288を実施することを含む。アタッチプロシージャ288は、ランダムアクセス(
図12では例示されない)を含み得る。アタッチプロシージャ288は、端末130がRRC接続要求メッセージ8001を送信することをも含む。RRC接続要求メッセージ8001は、データ接続160など、RRC接続を確立しようとする。次いで、eNB112は、RRC接続応答メッセージ8002で応答。これは、データ接続160を確立することを可能にする。
図12からわかるように、接続状態283への遷移は、接続状態283を設定するためのRRCレイヤ制御メッセージを通信することを伴う。したがって、接続状態283は、概して、OSIネットワークレイヤレベル上で定義され得る。
【0089】
次に、端末130は、UL制御メッセージ8003を送信する。UL制御メッセージ8003は、UL制御データ300を含む。UL制御データ300は、アクティブ反復のためのスケジュール200からの逸脱としての一時的な延長209を示す。
【0090】
端末130は、ULペイロードデータ251を含むメッセージ8004をも送信する。次いで、UL制御データ300に従って、端末130は、接続状態283の一時的な延長209を実装する。延長209の間に、端末130は、ネットワーク100から、特にeNB112から、DLペイロードデータ261を含むメッセージ8005を受信する。DLペイロードデータ261とULペイロードデータ251とは、同じサービスに属する。DLペイロードデータ261は、ULペイロードデータ251が、たとえば、OSIモデルによるTCP/IPレベルまたはトランスポートレイヤ上でアドレス指定される、同じサーバから発信することが可能である。
【0091】
次いで、延長209の満了時に、RRC接続解放メッセージ8006がネットワーク100から端末130に送信される。メッセージ8006は、スリープ状態281への遷移289を可能にする。データ接続160が解放される。これは、スリープ状態281を設定する。
【0092】
図13は、反復的なスケジュール200からの一時的な逸脱を示すUL制御データ300をシグナリングすることに関する態様を例示するシグナリング図である。
図13は、異なる状態281、282、283間の切替えに関する態様をさらに例示する。
【0093】
8011〜8014が、概して、8001〜8004に対応する。次いで、RRC接続解放メッセージ8015がネットワーク100から端末130に送信される。これは、接続状態283からアイドル状態282への遷移を可能にする。特に、データ接続160が解放される。次いで、端末130は、延長209の間にDLページング8016を受信する。DLページング8016の受信に応答して、アタッチプロシージャ288が実施され、アタッチプロシージャ288は、この場合も、RRC接続要求メッセージ8017およびRRC接続応答メッセージ8018の通信を含む。メッセージ8017、8018は、データ接続160の確立を可能にする。次いで、データ接続160を介して、DLペイロードデータ261を含むメッセージ8019が受信され得る。
【0094】
延長209の終わりに、データ接続160を解放し、スリープ状態281に遷移するために、RRC接続解放メッセージ8020が通信される。
【0095】
図12および
図13の例では、制御データ300は、アタッチプロシージャ288の完了の後に送信される制御メッセージ8003、8013の一部として送信される。たとえば、制御メッセージ8003、8013は、3GPP LTEフレームワークにおける物理UL制御チャネル(PUCCH)など、制御チャネル上で送信される専用制御メッセージであり得る。制御データ300を送信することの他の例が可能である。たとえば、制御データ300は、アタッチプロシージャの一部として送信され得る。
【0096】
図14は、反復的なスケジュール200からの一時的な逸脱を示すUL制御データ300をシグナリングすることに関する態様を例示するシグナリング図である。
図14は、異なる状態281、283間の切替えに関する態様をさらに例示する。
図14は、制御メッセージ上にUL制御データをピギーバックすることに関する態様をさらに例示する。
【0097】
図14の例は、概して、
図12の例に対応する。しかしながら、
図14の例では、スケジュール200からの逸脱を示し、特に延長200を示す、制御データ300は、アタッチプロシージャ288の間に通信されるRRC接続要求メッセージ8031上にピギーバックされる。制御データ300は、アタッチプロシージャ288を通信される異なる制御メッセージ上にピギーバックされることも可能であろう。したがって、
図14の例によれば、UL制御データ300は、アタッチプロシージャ288の間に送信される。これは、延長209の十分な時間を伴ってネットワーク100に通知するのを助ける。さらに、制御シグナリングオーバーヘッドが低減され得る。
図14の例は、たとえば、
図13の例などと組み合わせられ得る。
【0098】
8032〜8035が、概して、8002、8004〜8006に対応する。
【0099】
概して、制御データ300は、シングルビット情報フィールドであり得る。その場合、スケジュール200からの逸脱は、あらかじめ定義されたルールに従って実装され得る。さらなる例では、制御データ300は、マルチビット情報を含むことも可能であろう。たとえば、制御データ300は、一時的な逸脱の持続時間を示し、たとえば、延長209の持続時間219を示し得る。その場合、端末130は、たとえば、ペイロードデータ251、261に関連する予期された電力消費および/またはサービスのラウンドトリップレイテンシに基づいて、所与の状況において一時的な逸脱のどんな持続時間が適切であるかをフレキシブルに決定し得る。他の例では、一時的な逸脱の持続時間がネットワーク定義されることも可能であり得る。たとえば、対応する論理がeNB112中に存在し得る。そのようなシナリオでは、複数の端末間の送信衝突など、さらなるファクタを考慮することが可能であり得る。たとえば、UL制御データ300は、サービスを示し得る。その場合、ネットワーク100は、そのサービスに関連する一般的なラウンドトリップレイテンシに関する追加のアプリオリな知識を有し得る。たとえば、eNB112は、ラウンドトリップレイテンシを監視し得る。さらに、ネットワークは、DLペイロードデータ261を送信するためのスケジューリング制約を考慮に入れ得る。これは、一時的な逸脱の持続時間を寸法決定することの精度を増加させ得る。たとえば、DL制御データは、ネットワーク100から端末130に送信され得、DL制御データは、たとえば、デフォルト持続時間の倍数単位で、スケジュール200からの一時的な逸脱の持続時間を示す(
図14に例示されない)。
【0100】
制御データ300によって、ネットワーク100は、スケジュール200からの逸脱に気づかされる。次いで、eNB112は、DLペイロードデータ261のタイムリーな受信を可能にするために、逸脱に従ってDLペイロードデータ261を送信し得る。
【0101】
図15は、反復的なスケジュール200からの一時的な逸脱を示すUL制御データ300をシグナリングすることに関する態様を例示するシグナリング図である。
図15は、異なる状態281、283間の切替えに関する態様をさらに例示する。
図15は、ネットワーク100から端末130にダウンリンク確認応答を通信することに関する態様をさらに例示する。
【0102】
図15の例は、概して、
図12の例に対応する。たとえば、8041〜8043が8001〜8003に対応する。
図15の例では、ネットワーク100は、DL制御メッセージ8044を送る。制御メッセージ8044は、制御メッセージ8043の一部として前に通信されたUL制御データ300の確認応答310を示す。
【0103】
図15の例では、ネットワーク100は、スケジュール200からの逸脱としての一時的な延長209を肯定応答し、すなわち、肯定応答(PACK)を送り、時々、PACKは、単にACKと呼ばれる。この確認応答310のために、端末130は、次に進み、延長209を実装する。たとえば、否定応答(NACK)が端末130によって受信された場合(
図15では例示されない)、端末130は、あらかじめ定義されたスケジュール200に従って続き、すなわち、延長209をスキップすることができる。
【0104】
概して、確認応答の送信は必須でない。ネットワークによる確認応答の送信は随意である。たとえば、明示的ダウンリンク制御シグナリングなしの技法が実装された場合、端末の要求に暗黙的に確認応答することが可能であろう。本明細書で説明される他の例では、たとえば、
図12〜
図14の例では、確認応答技法も採用され得る。
【0105】
たとえば、UL制御データを送信したことに応答して、端末130は確認応答を受信し得る。UL制御データは、延長209の持続時間を示さないことが可能であろう。その場合、延長209の持続時間のためのあらかじめ定義された値が使用され得る。たとえば、そのようなあらかじめ定義された値は、事前設定されたデフォルトタイマー値の規格化された倍数を使用することができる。たとえば、UL制御データは、延長209の持続時間を示すことも可能であろう。次いで、確認応答が、端末130によって行われたそのような要求に肯定応答する場合、延長209の示された持続時間が使用され得る。しかしながら、確認応答が、端末130によって行われたそのような要求に否定応答する場合、延長209の持続時間219のために、デフォルト値が使用され得る。
【0106】
さらなる例では、DL制御データは、確認応答および場合によっては応答パラメータを含むことができる。たとえば、端末は、応答パラメータを含む肯定応答を受信し、このパラメータは、たとえば、以前の設定されたデフォルト値の乗数として、延長209の持続時間219を定義し得る。たとえば、端末は、否定応答を受信し、デフォルト値が使用され得る。
【0107】
その場合、8045〜8047が、8004〜8006に対応する。
【0108】
本発明は、いくつかの好ましい実施形態に関して示され、説明されたが、本明細書を読み、理解すれば、等価物および変更形態が他の当業者には想起されるであろう。本発明は、すべてのそのような等価物および変更形態を含み、添付の特許請求の範囲によって限定されるにすぎない。
【0109】
上記の様々な例は、インターフェースのネットワークレイヤの定義された状態に関して説明されたが、同様の例が、物理レイヤ(レイヤ1)および/またはデータリンクレイヤ(レイヤ2)などのレイヤ上で定義されるインターフェースの状態に関しても採用され得る。
【0110】
上記の様々な例は、一時的な延長に関して説明されたが、同様の技法が、たとえば、少なくとも1つのアクティブ状態の一時的な短縮または反復の持続時間の一時的な拡張など、他の種類の、ネゴシエートされたスケジュールからの一時的な逸脱に関しても適用され得る。
【0111】
上記の様々な例は、周期的スケジュールに関して説明されたが、それぞれの技法が、イベントトリガ型スケジュールのために容易に適用され得る。たとえば、ULデータを送信する必要に応答して、オン時間がトリガされ得る。
【0112】
たとえば、DLデータの受信時にトリガされる非アクティビティタイマーに関して様々な例が説明されたが、ULデータの送信時に、代替または追加として、非アクティビティタイマーをトリガするとき、同様の技法が容易に実装され得る。