JP6594553B2 - 接続モードｄｒｘオペレーションを制御するための方法 - Google Patents

Description

本開示は、一般に、無線通信、さらに詳しくは、接続モード間欠受信オペレーションを制御するための方法に関する。

狭帯域のモノのインターネット（ＮＢ−ＩｏＴ）は、第３世代パートナーシッププロジェクト（３ＧＰＰ）によって、セルラーのモノのインターネット（ＩｏＴ）のために開発された狭帯域（１８０ＫＨｚ帯域幅）システムである。このシステムは、Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ（ＬＴＥ）システムに基づき、以下の特徴、すなわち、低いスループット（たとえば、２Ｋｂｐｓ）、低い遅れ感度（たとえば、約１０秒）、極めて低いデバイスコスト（たとえば、５ドル未満）、および、低いデバイス電力消費量（たとえば、１０年のバッテリ寿命）、のうちのいずれかを有する大量のデバイスのために最適化されたネットワークアーキテクチャおよび改良された屋内カバレッジを取り扱う。

このシステムにおける各セル（たとえば、約１Ｋｍ^２）は、センサ、メータ、アクチュエータ、および他のデバイスのような数千（たとえば、約５０，０００）個のデバイスにサーブするであろうことが構想されている。このシステムは、しばしば屋内深くに配置され（たとえば、地階における地下空間、または、建物の壁に内蔵され）、バッテリ充電の機会が制限されているか、または、機会がないデバイスのために良好なカバレッジを提供できることが必須である。多くの異なるタイプのデバイスが構想されているが、簡略のために、本明細書では、ユーザ機器（ＵＥ）または無線デバイスと置換可能に称されるであろう。

１つの再委託されたＧＳＭキャリアのみを使用してＮＢ−ＩｏＴを展開し、ＮＢ−ＩｏＴ ＵＥのためのより低い製造コストをサポートすることを可能にするために、帯域幅は、いくつかのサブキャリアへ分割された１８０ＫＨｚサイズの１つの物理リソースブロック（ＰＲＢ）へ低減された。

周波数分割複信（ＦＤＤ）（すなわち、異なるキャリア周波数において送信機および受信機がオペレーションする）のために、半二重モードのみが、ＵＥにおいてサポートされる必要がある。デバイスの複雑さがより低いこと（たとえば、１つのみの送信／受信機チェーン）は、何らかの繰返しが、通常のカバレッジにおいても必要とされ得ることを意味する。さらに、ＵＥの複雑さを緩和するために、ワーキング仮説は、サブフレーム間スケジューリングを有することである。すなわち、送信は先ず、狭帯域物理ダウンリンク制御チャネル（ＮＢ−ＰＤＣＣＨまたはＮＰＤＣＣＨ）としても知られているエンハンスト物理ダウンリンク制御チャネル（Ｅ−ＰＤＣＣＨ）においてスケジュールされる。次に、ＮＢ−ＰＤＣＣＨの最後の送信後、狭帯域物理ダウンリンク共有チャネル（ＮＢ−ＰＤＳＣＨまたはＮＰＤＳＣＨ）における実際のデータの最初の送信が実行される。同様に、アップリンク（ＵＬ）データ送信のために、ＵＬ送信のためにネットワークによってスケジュールされ、ＵＥによって必要とされるリソースに関する情報が、先ず、ＮＢ−ＰＤＣＣＨで伝送され、次に、ＮＢ−ＰＤＣＣＨの最後の送信後、狭帯域物理アップリンク共有チャネル（ＮＢ−ＰＵＳＣＨまたはＮＰＵＳＣＨ）におけるＵＥによる実際のデータの最初の送信が実行される。言い換えれば、上記両ケースについて、ＵＥの観点から、同時の制御チャネルの受信およびデータチャネルの受信／送信はない。

高速パケットアクセス（ＨＳＰＡ）およびＬＴＥのようなレガシーセルラー通信システムでは、ソフトコンバインを有するハイブリッド自動再送要求（ＨＡＲＱ）と呼ばれる再送信手順がサポートされている。データブロックが一方向で（たとえば、ＵＥと無線基地局との間で）送信された後、ＨＡＲＱフィードバックメッセージとして示される、復号結果に関するフィードバックが、通常、逆方向で送信される。このフィードバックメッセージは、典型的に「２進法」復号結果、または、スケジューリンググラント／割当メッセージのいずれかである。フィードバックが「２進法」復号結果であるケースでは、フィードバックは、データブロック復号が成功したことを示すアクノレッジメント（ＡＣＫ）、または、データブロック復号が不成功であったことを示す否定的アクノレッジメント（ＮＡＣＫ）の形態であり得る。フィードバックが、スケジューリンググラント／割当メッセージの形態であるケースでは、スケジューリンググラント／割当メッセージは、（上述したＮＡＣＫと同様に、データブロック復号が不成功であった場合）再送信、または、（上述したＡＣＫと同様に）前のデータブロックが成功裏に復号されたことを暗黙的にアクノレッジする新たなデータブロックの送信、のいずれかを要求し得る。

いくつかのケースでは、ＨＡＲＱフィードバック情報は、無送信（ＤＴＸ）によっても示され得る。そのようなシナリオでは、無送信は、ＡＣＫまたはＮＡＣＫのいずれか（典型的には後者）を意味し、何か（たとえば、プリアンブルまたは他のある信号／符号）を送信することは、ＡＣＫを示し得る。ＨＡＲＱフィードバックメッセージの送信がないことはまた、成功または不成功いずれかの復号データブロック（すなわち、ＡＣＫまたはＮＡＣＫ）を示すことが可能であり得る。その後、ＨＡＲＱフィードバックが（または、ＨＡＲＱフィードバックなしで）、再送信をトリガする。または、データが成功裏に受信され、より多くのデータが利用可能であれば、新たなデータ送信が開始され得る。

典型的には、多数のいわゆるＨＡＲＱプロセスが、並列的に（たとえば、ＨＳＰＡおよびＬＴＥにおいて）使用される。ＨＡＲＱプロセスは、独立して、データパケットを転送し、再送信または新たな送信のいずれかが送信される前にＨＡＲＱフィードバックを待つ、ストップアンドウェイト（ＳＡＷ）ＨＡＲＱエンティティである。レガシーＬＴＥ ＦＤＤでは、典型的には、８つのＨＡＲＱプロセスが、方向毎にサポートされている。同じことが、２ミリ秒のＵＬ送信時間間隔（ＴＴＩ）を有するＨＳＰＡに当てはまる。

同期ＨＡＲＱオペレーションは、前の送信後、固定時間において再送信が生じることを意味する。一方、非同期ＨＡＲＱオペレーションでは、再送信は、前の送信後、任意の時間において生じ得る。レガシーＬＴＥとＨＳＰＡとの両方において、ＵＥは、同期ＨＡＲＱを使用し、ダウンリンク（ＤＬ）は、非同期ＨＡＲＱを使用する。

ＵＥバッテリ消費量を低減するために、接続モード間欠受信（ＤＲＸ）と呼ばれる概念が使用される。これは、ＵＥが、ＬＴＥにおいて接続モード中、スリープモード（すなわち、受信および／または送信が要求されない）に入ることを可能にする。主要なアイデアは、時間期間、いずれの送信および／または受信動作（たとえば、送信／再送信がなく、ペンディング中の再送信もない）場合、ＵＥは、スリープモードに入ることができ、ＤＬ制御チャネルをモニタするために、ＤＲＸサイクル毎に、短時間、定期的にウェイクすることだけ必要である。新たなＵＬデータが利用可能になると、ＵＥは、任意の時間においてウェイクすることができるが、設定されたＵＬリソースによって、ネットワークに通知する必要がある（たとえば、スケジューリング要求が、物理アップリンク制御チャネル（ＰＵＣＣＨ）で送信されるようにトリガされ得る）。

ＤＲＸオペレーションは、レガシーＬＴＥのために、３ＧＰＰ ＴＳ ３６．３２１、ｖ．１３．０．０において定義され、事前に定義されているか、または、ＵＥへ送信されるかのいずれかであるタイマ／パラメータのセットによって制御される。具体的には、ｏｎＤｕｒａｔｉｏｎタイマ、ｄｒｘＳｔａｒｔＯｆｆｓｅｔ（３ＧＰＰ ＴＳ ３６．３３１、ｖ．１３．０．０におけるｌｏｎｇＤＲＸ−ＣｙｃｌｅＳｔａｒｔＯｆｆｓｅｔから）、ｌｏｎｇＤＲＸ−Ｃｙｃｌｅ（３ＧＰＰ ＴＳ ３６．３３１、ｖ．１３．３．０におけるｌｏｎｇＤＲＸ−ＣｙｃｌｅＳｔａｒｔＯｆｆｓｅｔから）、ｓｈｏｒｔＤＲＸ−Ｃｙｃｌｅ、ｄｒｘＳｈｏｒｔＣｙｃｌｅタイマ、ｄｒｘ−Ｉｎａｃｔｉｖｉｔｙタイマ、ＨＡＲＱ−ＲＴＴ−タイマ、およびｄｒｘ−Ｒｅｔｒａｎｓｍｉｓｓｉｏｎタイマである。本明細書において、規格の特定のバージョン（たとえば、ＴＳ ３６．３３１、ｖ．１３．０．０）に対する引用は、本願のオリジナル出願時に利用可能な代表的なバージョンとして意図されている。しかしながら、必要に応じて、他のバージョンもまた当てはまる。

図１は、接続モードＤＲＸ中のＵＥオペレーションの例を例示する。さらに詳しくは、（３ＧＰＰ ＴＳ ３６．３２１、ｖ．１３．０．０から再現される）図１は、接続モードＤＲＸサイクル１０５中、ＵＥが、アウェイクし、（図１の例においてＰＤＣＣＨとして示されるが、ＰＤＣＣＨおよび／またはｅＰＤＣＣＨであり得る）ＤＬ制御チャネルをモニタする必要がある場合を例示する。一般に、ＤＲＸサイクル１０５中、ＵＥは、ＯｎＤｕｒａｔｉｏｎ期間１１０中、ＤＬ制御チャネルをモニタし、ＤＲＸのための機会１１５中、スリープする。ＯｎＤｕｒａｔｉｏｎ時間１０５中、（ＵＬまたはＤＬのいずれかにおいて）新たなデータがスケジュールされると、ＵＥは、ＤＲＸから出て、ｄｒｘ−Ｉｎａｃｔｉｖｉｔｙタイマと呼ばれるタイマを開始する。

図２は、レガシーＤＲＸオペレーションの例を例示する。新たなデータ２０５が（ＤＬ制御チャネル２１０によって）スケジュールされると、ｄｒｘ−Ｉｎａｃｔｉｖｉｔｙタイマ２１５は、再開始されるか、そうではない場合、最終的に満了し、ＵＥは、ＤＲＸへ入る。図２の例では、ＵＥは、ｄｒｘ−Ｉｎａｃｔｉｖｉｔｙタイマ２１５の期間中に、ＰＤＣＣＨを検出しなければ、ｄｒｘ−Ｉｎａｃｔｉｖｉｔｙタイマ２１５が満了すると、ＤＲＸへ入る。それに加えて、図２は、（図２の例において「新たなデータ」２０５として図示される）ＨＡＲＱデータ２０５と、（図２において、ＵＬ２３０におけるＡＣＫ送信２２５として図示される）ＨＡＲＱフィードバック２２５との間のオフセット２２０を例示する。ＬＴＥでは、ＨＡＲＱデータ２０５とＨＡＲＱフィードバック２２５との間のオフセットは、時間機会Ｎにおけるデータ送信後、常にＮ＋４、すなわち、常に４ミリ秒（または、等価なサブフレーム）である。

図３は、ＤＬ再送信がある場合におけるレガシーＤＲＸオペレーションの例を例示する。そのようなシナリオでは、ＵＥは、再送信を監督するために、他の２つのタイマ、すなわち、ＨＡＲＱ−ＲＴＴ−タイマ３０５およびｄｒｘ−Ｒｅｔｒａｎｓｍｉｓｓｉｏｎタイマ３１０を使用する。これらタイマは、ｄｒｘ−Ｉｎａｃｔｉｖｉｔｙタイマ２１５と独立していることに注目されたい。図３の例に図示されるように、再送信（図３においてＲｅＴｘ３１５として図示される）が成功裏に復号された場合、ｄｒｘ−Ｒｅｔｒａｎｓｍｉｓｓｉｏｎタイマ３１０が停止／キャンセルされる。図３の例では、「新たなデータ」２０５後、ＰＤＣＣＨでシグナリングされた他のＵＬ／ＤＬ ＨＡＲＱプロセスのための動作が存在し得ることに注目されたい。新たなデータが、これらのうちのいずれかにおいてスケジュールされているのであれば、ｄｒｘ−Ｉｎａｃｔｉｖｉｔｙタイマ２１５は再開始される。

図４は、ＵＬ再送信が存在する場合、レガシーＤＲＸオペレーションの例を例示する。図４の例では、ＯｎＤｕｒａｔｉｏｎタイマ４１５が実行している間、ＵＥは、ＤＬ制御チャネル４１０でＵＬグラント４０５を受信する。ＵＬグラント４０５を受信すると、ＵＥは、ＯｎＤｕｒａｔｉｏｎタイマ４１５を停止させ、ｄｒｘ−Ｉｎａｃｔｉｖｉｔｙタイマ２１５を開始する。図４の例では、ＵＥは、ＵＬグラント４０５に関連付けられた（図４の例における「新たなデータ」として図示される）ＵＬ送信４２０を実行する。ＵＬ送信４２０を実行した後、ＵＥは、ｄｒｘ−Ｉｎａｃｔｉｖｉｔｙタイマ２１５の持続時間中、ＰＤＣＣＨを検出しないのであれば、ｄｒｘ−Ｉｎａｃｔｉｖｉｔｙタイマ２１５が満了すると、ＤＲＸへ入るであろう。

レガシーＬＴＥでは、ＵＬ再送信４２５が存在するのであれば、同期ＨＡＲＱが使用されるので、再送信タイマは必要とされない。同期ＨＡＲＱは、ＨＡＲＱフィードバック（たとえば、ＡＣＫ４３５および／またはＮＡＣＫ４３０）および再送信がスケジュールされるときに関する正確なタイミングを提供する。ＤＬ制御チャネル４１０（たとえば、ＰＤＣＣＨ）における新たなグラントもまた、ＮＡＣＫ４３０が物理ハイブリッド指示チャネル（ＰＨＩＣＨ）において送信されるのと同じサブフレームにおいて与えられ得、再送信は、「アダプティブ」と呼ばれる。ＵＬグラント４０５とＵＬ送信４２０との間、アップリンク送信４２０とＮＡＣＫ４３０との間、ＮＡＣＫ４３０とＵＬ再送信４２５との間、およびＵＬ再送信４２５とＡＣＫ４３５との間のＮ＋４のオフセットがそれぞれ、要素２２０ａ、２２０ｂ、２２０ｃ、２２０ｄとして図示されている。

図４の例では、ＵＬグラント４０５後、ダウンリンク制御チャネル４１０（たとえば、ＰＤＣＣＨ）でシグナリングされる他のＵＬ／ＤＬ ＨＡＲＱプロセスのための動作が存在し得ることに注目されたい。これらのうちのいずれかにおいて、新たなデータがスケジュールされると、（使用されている／実行しているのであれば）ｄｒｘ−Ｉｎａｃｔｉｖｉｔｙタイマが再開始される。いくつかのケースでは、たとえば、新たなデータに関するグラントがＨＡＲＱプロセスのために与えられているのであれば、ＡＣＫ４３５はまた、暗黙的なアクノレッジメントでもあり得ることも注目されたい。

３ＧＰＰリリース１３では、エンハンストマシン型通信（ｅＭＴＣ）のためのワークアイテムが継続中であり、ここでは、レガシーＬＴＥと比較して、ＨＡＲＱオペレーションに対して変更がなされる。３つの並列的なＨＡＲＱプロセスがサポートされることが決定された。それに加えて、ＵＬ ＨＡＲＱが、同期から非同期へ変更され、ＨＡＲＱフィードバックは暗黙的のみであり、ＰＵＳＣＨ送信後、最初のＮ＋４のＭ−ＰＤＣＣＨ（すなわち、ＰＨＩＣＨチャネルが存在しない）で受信される。その結果、ＨＡＲＱフィードバックのタイミングはもはや固定されないので、再送信がある場合、ＵＥがどのようにしてＤＲＸへ入るべきかに関する変更が必要とされる。

ライセンスアシストアクセス（ＬＡＡ）に関連する３ＧＰＰリリース１３における別のワークアイテムでは、ＵＬ ＨＡＲＱは、レガシーＬＴＥと比較して、同期から非同期へ変更される必要があることもまた確認された。このインパクトは、本明細書では、参照においてその全体が組み込まれている３ＧＰＰ ＴＲ ３６．８８９、ｖ．１３．０．０（および特にセクション７．２．２．２）に詳細に説明されている。

ＬＴＥ／ｅＭＴＣでは、すべてのＤＲＸパラメータが、無線リソース制御（ＲＲＣ）シグナリングに基づいて、ＵＥにおいて半静的に設定される。「アクティブ時間」中、ＵＥがショート／ロングＤＲＸへ入ることを制御するために、媒体アクセス制御（ＭＡＣ）シグナリングによって、いくつかの動的な変更がサポートされている。

既存のアプローチに伴う問題は、低レイテンシが重要でありＵＥバッテリ消費量を最小化することが主な目標ではない、マルチＨＡＲＱプロセスおよび使用事例のために、ＨＡＲＱ／ＤＲＸ設計が最適化されていることである。同じ設計が、半二重オペレーション、サブフレーム間スケジューリング、および１つのみのＨＡＲＱプロセスしかサポートしないＵＥへ適用されているのであれば、ＭＴＣ／ＩｏＴアプリケーションにおいて典型的に使用される多くのトラフィック使用事例のために、ＵＥが、必要よりもより長い時間、アウェイクするという結果に至るであろう。たとえば、トラフィック使用事例の多くでは、ＵＬおよびＤＬの同時のデータ転送はない。その代わり、ほとんどの使用事例は、ＩＰパケットが１つの方向で送信され、他の方向で応答が後続する、要求−応答タイプのトラフィックパターンに依存する。

さらに、既存のアプローチ（ＬＴＥとＨＳＰＡとの両方）に従って、ＵＬにおけるＨＡＲＱオペレーションは同期的である。ＨＡＲＱオペレーションが非同期へ変更されると、送信／再送信がなされた後、ＵＥがＨＡＲＱフィードバックをどれくらい待つのかは知られていない。１つのアプローチは、ＵＬのためにもＤＬ設計をコピーすること（すなわち、ＵＬのためにも同様なタイマ（たとえば、ＨＡＲＱ−ＲＴＴ−タイマ／ｄｒｘ−Ｒｅｔｒａｎｓｍｉｓｓｉｏｎタイマ）を導入すること）であろう。そのようなアプローチは、レガシーＬＴＥ使用事例のために許容可能であり得るが、ＭＴＣ／ＩｏＴのエリアにおける使用事例のために良好に適している訳ではない。これらアプリケーションは、半二重、１つのＨＡＲＱプロセス、およびサブフレーム間スケジューリングのみのためのサポートを有する新たな、簡素化されたＵＥの使用を含む。したがって、さらに最適化された解決策が望ましい。この理由は、半二重、１つのＨＡＲＱプロセス、サブフレーム間のみのスケジューリング、および、典型的なトラフィックパターンの特性が、この設計において利用されているのであれば、他の解決策が、ＵＥバッテリ／電力消費量を低減し、したがって、より良好に実行することである。

ＮＢ−ＩｏＴの１つの目標は、レガシーＬＴＥを可能な限り多く再使用する（ｅＭＴＣ変更を含む）ことである。重要な考慮は、ＨＡＲＱおよび接続モードＤＲＸオペレーションがどのように動作すべきであるかである。レガシー設計が、ＮＢ−ＩｏＴに適用されるのであれば、これは、ＵＥの、より大きなバッテリ／電力消費量に至るであろう。さらに、すべてのＤＲＸ関連タイマは半静的であるので、ｅＮＢが、ＨＡＲＱ送信、再送信、およびＨＡＲＱフィードバックをスケジュールするために非常に限られた柔軟性しかない。多くのＵＥ、および／または、異なるカバレッジレベル（したがって、異なる送信持続時間）を有するＵＥが、サーブされる必要があるのであれば、半静的パラメータを有する以前のアプローチは、ＵＥのための短い「アクティブ時間」を可能にするほど柔軟ではない。レガシーＬＴＥにおけるものと同じ設計を適用することは、より大きなタイマ値の使用を必要とするので、ＵＥアウェイク時間は、より長くなり、その結果、バッテリ／電力消費量がより大きくなるであろう。

既存の解決策に伴う前述した問題に対処するために、ユーザ機器（ＵＥ）における方法が開示される。この方法は、少なくとも第１のタイマの持続時間中、ダウンリンク制御チャネルをモニタすることを含む。この方法は、ＵＥのためのダウンリンクまたはアップリンク送信を示すインジケーションを、モニタされたダウンリンク制御チャネルで受信することを含む。この方法は、ＵＥのためのダウンリンクまたはアップリンク送信を示すインジケーションを受信した後、第１のタイマをモニタすることを停止することを含む。第１のタイマが停止された後、ＵＥは、ダウンリンク制御チャネルをモニタする必要はない。この方法は、ＵＥのための示されたダウンリンクまたはアップリンク送信に関連付けられたアップリンク送信を実行することを含む。この方法は、ＵＥのためのダウンリンクまたはアップリンク送信を示すインジケーションを受信した後、第２のタイマを開始することを含み、第２のタイマの持続時間は、オフセット期間を含む。この方法は、第２のタイマが満了した場合、第３のタイマを開始することを含み、ＵＥは、第３のタイマの持続時間の間、ダウンリンク制御チャネルをモニタする。

いくつかの実施形態では、第２のタイマは、関連付けられたアップリンク送信を実行した後、または、ＵＥのためのダウンリンクまたはアップリンク送信を示す受信されたインジケーションの終了時のいずれかにおいて開始され得る。

いくつかの実施形態では、この方法は、第３のタイマが満了した場合、間欠受信モードに入ることを含み得る。この方法は、第２および第３のタイマのうちの少なくとも１つの持続時間に関する情報を含むメッセージを受信することを含み得る。いくつかの実施形態では、第１のタイマは、間欠受信サイクルのｏｎＤｕｒａｔｉｏｎタイマであり得る。いくつかの実施形態では、第１のタイマおよび第３のタイマのうちの少なくとも１つは、ｄｒｘ−Ｉｎａｃｔｉｖｉｔｙタイマであり得る。いくつかの実施形態では、第１のタイマおよび第３のタイマのうちの少なくとも１つは、間欠受信再送信タイマを含み得る。いくつかの実施形態では、第２のタイマは、オフセット期間を含むハイブリッド自動再送要求（ＨＡＲＱ）−ラウンドトリップタイム（ＲＴＴ）タイマであり得る。

いくつかの実施形態では、ＵＥのためのダウンリンクまたはアップリンク送信を示すインジケーションは、ダウンリンクスケジューリング割当を含み得、示されたダウンリンク送信に関連付けられたアップリンク送信は、アクノレッジメントメッセージを含み得る。いくつかの実施形態では、ＵＥのためのダウンリンクまたはアップリンク送信を示すインジケーションは、アップリンクグラントを含み得、示されたアップリンク送信に関連付けられたアップリンク送信は、アップリンクにおけるデータ送信を含み得る。いくつかの実施形態では、ＵＥのためのダウンリンクまたはアップリンク送信を示すインジケーションは、第２または第３のタイマのうちの少なくとも１つの持続時間に関する情報を含み得る。

ユーザ機器（ＵＥ）もまた開示される。ＵＥは、処理回路を備える。処理回路は、少なくとも第１のタイマの持続時間中、ダウンリンク制御チャネルをモニタするように構成される。処理回路は、ＵＥのためのダウンリンクまたはアップリンク送信を示すインジケーションを、モニタされたダウンリンク制御チャネルで受信するように構成される。処理回路は、ＵＥのためのダウンリンクまたはアップリンク送信を示すインジケーションを受信した後、第１のタイマをモニタすることを停止するように構成される。第１のタイマが停止された後、ＵＥは、ダウンリンク制御チャネルをモニタする必要はない。処理回路は、ＵＥのための示されたダウンリンクまたはアップリンク送信に関連付けられたアップリンク送信を実行するように構成される。処理回路は、ＵＥのためのダウンリンクまたはアップリンク送信を示すインジケーションを受信した後、第２のタイマを開始するように構成され、第２のタイマの持続時間は、オフセット期間を含む。第２のタイマが満了した場合、処理回路は、第３のタイマを開始するように構成され、ＵＥは、第３のタイマの持続時間の間、ダウンリンク制御チャネルをモニタする。

ネットワークノードにおける方法もまた開示される。この方法は、間欠受信オペレーションを制御するために、ユーザ機器（ＵＥ）による使用のための、第１のタイマの持続時間と、第２のタイマの持続時間とを判定することを含み、第１のタイマの持続時間は、オフセット期間を含む。この方法は、第１のタイマの持続時間と、第２のタイマの持続時間とに関する情報をＵＥへ送信することを含む。

いくつかの実施形態では、第１のタイマの持続時間と、第２のタイマの持続時間とに関する情報をＵＥへ送信することは、第１のタイマの持続時間と、第２のタイマの持続時間とに関する情報を含むメッセージをＵＥへ送信することを含み得る。

いくつかの実施形態では、第１のタイマの持続時間と、第２のタイマの持続時間とに関する情報は、ＵＥのためのダウンリンクまたはアップリンク送信を示すインジケーションに含まれ得る。この方法は、ＵＥのためのダウンリンクまたはアップリンク送信を示すインジケーションをＵＥへ送信することと、ＵＥのための示されたダウンリンクまたはアップリンク送信に関連付けられたアップリンク送信をＵＥから受信することとを含み得る。いくつかの実施形態では、ＵＥのためのダウンリンクまたはアップリンク送信を示すインジケーションは、ダウンリンクスケジューリング割当を含み得、示されたダウンリンク送信に関連付けられたアップリンク送信は、アクノレッジメントメッセージを含み得る。いくつかの実施形態では、ＵＥのためのダウンリンクまたはアップリンク送信を示すインジケーションは、アップリンクグラントを含み得、示されたアップリンク送信に関連付けられたアップリンク送信は、アップリンクにおけるデータ送信を含み得る。

いくつかの実施形態では、第１のタイマの持続時間は、ＵＥのための示されたダウンリンクまたはアップリンク送信に関連付けられたアップリンク送信の送信後、ＵＥが第２のタイマを開始する前に、ＵＥが待つ時間の長さ、および、ＵＥのためのダウンリンクまたはアップリンク送信を示すインジケーションの終了後、ＵＥが第２のタイマを開始する前に、ＵＥが待つ時間の長さのうちの１つを含む。いくつかの実施形態では、第１のタイマは、ハイブリッド自動再送要求（ＨＡＲＱ）−ラウンドトリップタイム（ＲＴＴ）タイマであり得る。いくつかの実施形態では、第２のタイマの持続時間は、間欠受信モードに入る前にＵＥがダウンリンク制御チャネルをモニタする時間の長さを含み得る。いくつかの実施形態では、第２のタイマは、ｄｒｘ−Ｉｎａｃｔｉｖｉｔｙタイマであり得る。

ネットワークノードもまた開示される。ネットワークノードは、処理回路を備える。処理回路は、間欠受信オペレーションを制御するために、ユーザ機器（ＵＥ）による使用のための、第１のタイマの持続時間と、第２のタイマの持続時間とを判定するように構成され、第１のタイマの持続時間は、オフセット期間を含む。処理回路は、第１のタイマの持続時間と、第２のタイマの持続時間とに関する情報を、ＵＥへ送信するように構成される。

本開示のいくつかの実施形態は、１つまたは複数の技術的利点を提供し得る。たとえば、いくつかの実施形態は、有利なことに、既存のアプローチと比較して、ＵＥバッテリおよび／または電力消費量を低減し得る。別の例として、いくつかの実施形態は、有利なことに、ダウンリンク制御チャネルをモニタするために、ＵＥがアウェイクする必要がある時間を低減し得る。さらに別の例として、ダウンリンク制御チャネルをモニタするためにＵＥがアウェイクする必要がある時間の長さが、ネットワークノード（たとえば、ｅＮＢ）における現在のスケジューリング状況へ適応され得る。さらにまた別の例として、ＮＢ−ＩｏＴにおけるダウンリンク制御チャネルは、ＵＥ同士の間で、および、ダウンリンク共有チャネルにおける送信とともに時間多重化される必要があるので、いくつかの実施形態は、有利なことに、ＵＥのための「アクティブ時間」の時間多重化を有効化し得る。これは、ネットワークノードにおけるスケジューリング柔軟性を増加させ、ＵＥが、より短い間（すなわち、より短い時間持続中）しかアウェイクしないことを可能にし得る。他の利点は、当業者に容易に明らかになり得る。いくつかの実施形態は、述べられた利点のうちのいずれも有し得ないか、いくつか、またはすべてを有し得る。

開示された実施形態およびその特徴ならびに利点のより完全な理解のために、以下の添付図面と併せて読まれる以下の説明に対する参照がここでなされる。

接続モードＤＲＸ中のＵＥオペレーションの例を例示する図である。 レガシーＤＲＸオペレーションの例を例示する図である。 ＤＬ再送信がある場合におけるレガシーＤＲＸオペレーションの例を例示する図である。 ＵＬ再送信があるときのレガシーＤＲＸオペレーションの例を例示する図である。 いくつかの実施形態に従って、ネットワーク５００の実施形態を例示するブロック図である。 いくつかの実施形態に従って、ＤＲＸオペレーションを制御するためのタイミングおよび送信の第１の例を例示する図である。 いくつかの実施形態に従って、図６ＡにおけるＤＲＸオペレーションを制御するためのタイミングおよび送信の第１の例のバリエーションを例示する図である。 いくつかの実施形態に従って、ＤＲＸオペレーションを制御するためのタイミングおよび送信の第２の例を例示する図である。 いくつかの実施形態に従って、図７ＡにおけるＤＲＸオペレーションを制御するためのタイミングおよび送信の第２の例のバリエーションを例示する図である。 いくつかの実施形態に従って、ＤＲＸオペレーションを制御するためのタイミングおよび送信の第３の例を例示する図である。 いくつかの実施形態に従って、図８ＡにおけるＤＲＸオペレーションを制御するためのタイミングおよび送信の第３の例のバリエーションを例示する図である。 いくつかの実施形態に従って、ＤＲＸオペレーションを制御するためのタイミングおよび送信の第４の例を例示する図である。 いくつかの実施形態に従って、図９ＡにおけるＤＲＸオペレーションを制御するためのタイミングおよび送信の第４の例のバリエーションを例示する図である。 いくつかの実施形態に従う、ＤＲＸオペレーションの例のフローチャートである。 いくつかの実施形態に従う、ＵＥにおける方法のフロー図である。 いくつかの実施形態に従う、ネットワークノードにおける方法のフロー図である。 いくつかの実施形態に従う、例示的なＵＥのブロック系統図である。 いくつかの実施形態に従う、例示的なネットワークノードのブロック系統図である。 いくつかの実施形態に従う、例示的な無線ネットワークコントローラまたはコアネットワークノードのブロック系統図である。 いくつかの実施形態に従う、例示的なＵＥのブロック系統図である。 いくつかの実施形態に従う、例示的なネットワークノードのブロック系統図である。

上述したように、１つの重要な考慮は、ＨＡＲＱおよび接続モードＤＲＸオペレーションが、ＮＢ−ＩｏＴにおいてどのように動作すべきであるかである。レガシーＬＴＥにおいて使用されるもののような既存のアプローチは、ＮＢ−ＩｏＴオペレーションに関連付けられた使用事例のために許容可能ではない。たとえば、レガシー設計がＮＢ−ＩｏＴに適用されるのであれば、これは、ＵＥの、より大きなバッテリおよび／または電力消費量に至るであろう。さらに、すべてのＤＲＸ関連タイマは、半静的であるので、ｅＮＢが、ＨＡＲＱ送信／再送信およびＨＡＲＱフィードバックをスケジュールするために、非常に限られた柔軟性しかない。多くのＵＥ、および／または、異なるカバレッジレベル（したがって、異なる送信持続時間）を有するＵＥが、サーブされる必要があるのであれば、半静的パラメータを有する既存のアプローチは、ＵＥのための短い「アクティブ時間」を可能にするほど柔軟ではない。レガシーＬＴＥにおいて使用されている既存のアプローチをＮＢ−ＩｏＴ使用事例へ適用することは、より大きなタイマ値の使用を必要とし、これは、ＵＥがアウェイクすることを必要とされる時間の長さを増加させるという望ましくない結果を有するので、その結果、ＵＥによるバッテリおよび／または電力消費量がより大きくなる。

本開示は、既存のアプローチに関連付けられたこれらおよび他の欠点に対処し得る様々な実施形態を考慮する。いくつかの実施形態では、既存のアプローチに関連付けられた欠点は、ＮＢ−ＩｏＴのための接続モードにおける「アクティブ時間」を取り扱う／制御する新たな、柔軟な手法を使用して克服され得る。一般に、このために２つのパラメータ、すなわち、ＵＥがＤＲＸへ入る前に、ＤＬ制御チャネルをモニタするために、どれだけ長くアウェイクするべきかを判定する「アクティブ時間」と、「アクティブ時間」をいつ開始すべきかを判定する「オフセット時間」とが使用され得る。いくつかのケースでは、「オフセット時間」は、ＤＬ制御チャネル（たとえば、ＮＢ−ＰＤＣＣＨ）において制御メッセージを受信することによってトリガされたＵＬ送信に対して設定される。１つの限定しない例において、ＵＬ送信は、ＤＬデータを受信するためにＤＬ割当に関連付けられたＨＡＲＱフィードバックメッセージであるか、または、ＵＬデータのＵＬ送信となるＵＬグラントであるか、のいずれかであり得る。新たな制御メッセージが、「アクティブ時間」中に、ＤＬ制御チャネルにおいて受信されたのであれば、「アクティブ時間」が停止される（すなわち、ＵＥは、ＤＬ制御チャネルをモニタするために、アウェイクしている必要はない）。その後、制御メッセージ（ＤＬ割当またはＵＬグラント）によって示される動作が実行され、新たな「アクティブ時間」および「オフセット時間」パラメータが使用される。これら２つのパラメータ（「アクティブ時間」および「オフセット時間」）の値に関する情報が、任意の適切な方式で提供され得る。いくつかの実施形態では、これら２つのパラメータの値に関する情報が、ＤＬ制御チャネルで送信されたＤＬ割当／ＵＬグラントメッセージの一部として、送信毎に提供され得、異なるＤＬ割当／ＵＬグラント同士の間で変動し得る。

本明細書で説明された実施形態の態様は、接続モードＤＲＸオペレーションと、ＵＥおよびネットワークノード（たとえば、無線基地局／ｅＮＢ）のための挙動とを制御する通信システムにおけるＵＥ（たとえば、ＮＢ−ＩｏＴ）によって実行される方法に関する。いくつかの実施形態では、この方法は、上述したＮＢ−ＩｏＴデバイスの通信機能の特性（たとえば、半二重、１つのＨＡＲＱプロセス、サブフレーム間スケジューリング）と、バッテリおよび／または電力消費量を最小化するために、デバイス（ＵＥ）のための「アクティブ時間」を最適化するために使用される典型的なトラフィックパターンとを利用する。いくつかの実施形態はまた、有利なことに、含まれるパラメータを動的にシグナリングすることによって、接続モードＤＲＸオペレーションを制御する柔軟な手法をも紹介し得る。

１つの例示的な実施形態に従って、ＵＥにおける方法が開示される。ＵＥは、少なくとも第１のタイマの持続時間中、ＤＬ制御チャネルをモニタする。ＵＥは、モニタされたＤＬ制御チャネルで、ＵＥのためのＤＬまたはＵＬ送信を示すインジケーションを受信する。ＵＥのためのＤＬまたはＵＬ送信を示すインジケーションの受信後、ＵＥは、第１のタイマをモニタすることを停止する。第１のタイマが停止された後、ＵＥは、ダウンリンク制御チャネルをモニタする必要はない。ＵＥは、ＵＥのための示されたＤＬまたはＵＬ送信に関連付けられたＵＬ送信を実行する。ＵＥは、ＵＥのためのダウンリンクまたはアップリンク送信のためのインジケーションを受信した後、第２のタイマを開始する。第２のタイマの持続時間は、オフセット期間を含む。いくつかの実施形態では、第２のタイマは、関連付けられたＵＬ送信を実行した後、または、ＵＥのためのＤＬまたはＵＬ送信を示す受信されたインジケーションの終了時、のいずれかにおいて開始され得る。第２のタイマが満了した場合、ＵＥは第３のタイマを開始する。ここで、ＵＥは、第３のチャネルの持続時間の間、ダウンリンク制御チャネルをモニタする。いくつかの実施形態では、第３のタイマが満了した場合、ＵＥは、間欠受信モードへ入り得る。いくつかの実施形態では、ＵＥは、第２および第３のタイマの少なくとも１つの持続時間に関する情報を含むメッセージを受信し得る。

別の例示的な実施形態に従って、ネットワークノードにおける方法が開示される。ネットワークノードは、間欠受信オペレーションを制御するために、ＵＥによる使用のための、第１のタイマの持続時間と、第２のタイマの持続時間とを判定し、第１のタイマの持続時間は、オフセット期間を含む。いくつかの実施形態では、第１のタイマの持続時間は、ＵＥのための示されたダウンリンクまたはアップリンク送信に関連付けられたアップリンク送信の送信後、ＵＥが第２のタイマを開始する前に、ＵＥが待つ時間の長さ、および、ＵＥのためのダウンリンクまたはアップリンク送信を示すインジケーションの終了後、ＵＥが第２のタイマを開始する前に、ＵＥが待つ時間の長さのうちの少なくとも１つを含み得る。いくつかの実施形態では、第２のタイマの持続時間は、間欠受信モードに入る前に、ＵＥがＤＬ制御チャネルをモニタする時間の長さを含み得る。ネットワークノードは、第１のタイマの持続時間、および、第２のタイマの持続時間に関する情報を、ＵＥへ送信する。１つの限定しない例として、ネットワークノードは、第１のタイマの持続時間と、第２のタイマの持続時間とに関する情報を含むメッセージをＵＥへ送信し得る。いくつかのケースでは、第１のタイマの持続時間と、第２のタイマの持続時間とに関する情報は、ＵＥのためのＤＬまたはＵＬ送信を示すインジケーションに含まれ得る。

図５は、いくつかの実施形態に従って、ネットワーク５００の実施形態を例示するブロック図である。ネットワーク５００は、（置換可能に無線デバイス５１０と称され得る）１つまたは複数のＵＥ５１０と、（置換可能にｅＮＢ５１５と称され得る）１つまたは複数のネットワークノード５１５とを含む。ＵＥ５１０は、無線インターフェースを介してネットワークノード５１５と通信し得る。たとえば、ＵＥ５１０は、ネットワークノード５１５のうちの１つまたは複数へ無線信号を送信し得るか、および／または、ネットワークノード５１５のうちの１つまたは複数から無線信号を受信し得る。無線信号は、音声トラフィック、データトラフィック、制御信号、および／または、他の任意の適切な情報を含み得る。いくつかの実施形態では、ネットワークノード５１５に関連付けられた無線信号カバレッジのエリアは、セル５２５と称され得る。いくつかの実施形態では、ＵＥ５１０は、デバイスツーデバイス（Ｄ２Ｄ）機能を有し得る。したがって、ＵＥ５１０は、別のＵＥから信号を受信することができ得るか、および／または、別のＵＥへ直接信号を送信することができ得る。

いくつかの実施形態では、ネットワークノード５１５は、無線ネットワークコントローラとインターフェースし得る。無線ネットワークコントローラは、ネットワークノード５１５を制御し得、いくつかの無線リソース管理機能、モビリティ管理機能、および／または、他の適切な機能を提供し得る。いくつかの実施形態では、無線ネットワークコントローラの機能は、ネットワークノード５１５に含まれ得る。無線ネットワークコントローラは、コアネットワークノードとインターフェースし得る。いくつかの実施形態では、無線ネットワークコントローラは、相互接続ネットワーク５２０を経由してコアネットワークノードとインターフェースし得る。相互接続ネットワーク５２０は、オーディオ、ビデオ、信号、データ、メッセージ、または、前述したものの任意の組合せを送信することが可能な任意の相互接続システムを指し得る。相互接続ネットワーク５２０は、公衆交換電話網（ＰＳＴＮ）と、公衆またはプライベートデータネットワークと、ローカルエリアネットワーク（ＬＡＮ）と、都市内ネットワーク（ＭＡＮ）と、広域ネットワーク（ＷＡＮ）と、ローカル、地域、またはグローバル通信と、または、インターネット、ワイヤラインまたは無線ネットワーク、企業イントラネット、または、これらの組合せを含む他の任意の適切な通信リンクのようなコンピュータネットワークと、のうちのすべてまたは一部を含み得る。

いくつかの実施形態では、コアネットワークノードは、ＵＥ５１０のための、通信セッションの確立、および、他の様々な機能を管理し得る。ＵＥ５１０は、非アクセス階層レイヤを使用して、コアネットワークノードと、いくつかの信号を交換し得る。非アクセス階層シグナリングでは、ＵＥ５１０とコアネットワークノードとの間の信号は、無線アクセスネットワークを介して透過的に渡され得る。いくつかの実施形態では、ネットワークノード５１５は、たとえばＸ２インターフェースのようなノード間インターフェースを介して１つまたは複数のネットワークノードとインターフェースし得る。

上述したように、ネットワーク５００の例示的な実施形態は、１つまたは複数のＵＥ５１０と、ＵＥ５１０と（直接または間接的に）通信することができる１つまたは複数の異なるタイプのネットワークノードとを含み得る。

いくつかの実施形態では、限定しない用語であるＵＥが使用される。本明細書において説明されるＵＥ５１０は、無線信号によってネットワークノード５１５または別のＵＥと通信することが可能な任意のタイプの無線デバイスであり得る。ＵＥ５１０はまた、無線通信デバイス、ターゲットデバイス、Ｄ２Ｄ ＵＥ、マシン型通信ＵＥ、または、マシンツーマシン通信（Ｍ２Ｍ）可能なＵＥ、低コストおよび／または複雑さの低いＵＥ、ＵＥ装備センサ、タブレット、モバイル端末、スマートフォン、ラップトップ埋込機器（ＬＥＥ）、ラップトップ搭載機器（ＬＭＥ）、ＵＳＢドングル、カスタマ構内設備（ＣＰＥ）などであり得る。ＵＥ５１０は、ＵＥ５１０のサービングセルに対して、通常のカバレッジ、または、増強されたカバレッジのいずれかの下で動作し得る。増強されたカバレッジは、置換可能に、拡張されたカバレッジと称され得る。ＵＥ５１０はまた、複数のカバレッジレベル（たとえば、通常のカバレッジ、増強されたカバレッジレベル１、増強されたカバレッジレベル２、増強されたカバレッジレベル３等）で動作し得る。いくつかのケースでは、ＵＥ５１０はまた、カバレッジ外シナリオでも動作し得る。

また、いくつかの実施形態では、一般的な用語である「無線ネットワークノード」（または、単に「ネットワークノード」）が使用される。無線ネットワークノードは、任意の種類のネットワークノードであり得、基地局（ＢＳ）、無線基地局、ノードＢ、ＭＳＲ ＢＳのようなマルチスタンダード無線（ＭＳＲ）無線ノード、エボルブドノードＢ（ｅＮＢ）、ネットワークコントローラ、無線ネットワークコントローラ（ＲＮＣ）、基地局コントローラ（ＢＳＣ）、リレーノード、リレーを制御するリレードナーノード、基地トランシーバ局（ＢＴＳ）、アクセスポイント（ＡＰ）、無線アクセスポイント、送信ポイント、送信ノード、リモートラジオユニット（ＲＲＵ）、リモート無線ヘッド（ＲＲＨ）、分散アンテナシステム（ＤＡＳ）におけるノード、マルチセル／マルチキャスト連携エンティティ（ＭＣＥ）、コアネットワークノード（たとえば、ＭＳＣ、ＭＭＥ等）、Ｏ＆Ｍ、ＯＳＳ、ＳＯＮ、位置決めノード（たとえば、Ｅ−ＳＭＬＣ）、ＭＤＴ、または他の任意の適切なネットワークノードを含み得る。

ネットワークノードおよびＵＥのような用語は、限定しないと考慮されるべきであり、特に、これら２つの間のある階層的な関係を示唆するものではなく、一般に、「ｅノードＢ」がデバイス１として、「ＵＥ」がデバイス２として考慮され得、これら２つのデバイスは、ある無線チャネルを介して互いに通信する。

ＵＥ５１０、ネットワークノード５１５、および（無線ネットワークコントローラまたはコアネットワークノードのような）他のネットワークノードの例示的な実施形態は、図１３〜図１７に関して以下により詳細に説明される。

図５は、ネットワーク５００の特定の構成を例示しているが、本開示は、本明細書で説明された様々な実施形態が、任意の適切な構成を有する様々なネットワークへ適用され得ることを考慮する。たとえば、ネットワーク５００は、任意の適切な数のＵＥ５１０およびネットワークノード５１５のみならず、ＵＥ同士の間、または、ＵＥと（陸線電話のような）別の通信デバイスとの間の通信をサポートするために適切な任意の追加要素を含み得る。さらに、いくつかの実施形態は、Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ（ＬＴＥ）ネットワークにおいて実施されるものとして説明され得るが、これら実施形態は、（５Ｇ規格を含む）任意の適切な通信規格をサポートし、任意の適切な構成要素を使用している任意の適切なタイプの通信システムにおいて実施され得、ＵＥが信号（たとえば、データ）を受信および／または送信する、任意の無線アクセス技術（ＲＡＴ）またはマルチＲＡＴシステムに適用可能である。たとえば、本明細書で説明される様々な実施形態は、ＬＴＥ、ＬＴＥ−Ａｄｖａｎｃｅｄ、ＮＢ−ＩｏＴ、５Ｇ、ＵＭＴＳ、ＨＳＰＡ、ＧＳＭ、ｃｄｍａ２０００、ＷＣＤＭＡ、ＷｉＭａｘ、ＵＭＢ、ＷｉＦｉ、別の適切な無線アクセス技術、または、１つまたは複数の無線アクセス技術の任意の適切な組合せへ適用可能であり得る。いくつかの実施形態は、ＤＬにおける無線送信のコンテキストで説明され得るが、本開示は、様々な実施形態がＵＬにおいて等しく適用可能であることを考慮する。

上述したように、いくつかの実施形態は、接続モードにおけるＤＲＸオペレーションを制御するための新規性のある方法を提供する。限定しない様々な例示的な実施形態の以下の説明では、ＮＢ−ＩｏＴのためのスケジューリングおよびＨＡＲＱオペレーションに関して、いくつかの仮定がなされ得る。第１に、ＤＬ／ＵＬデータが、ＤＬ制御チャネル（たとえば、ＮＢ−ＰＤＣＣＨ）においてメッセージによってスケジュールされることが仮定される。第２に、ＤＬ／ＵＬデータが、共有チャネル（たとえば、ＮＢ−ＰＤＳＣＨおよびＮＢ−ＰＵＳＣＨそれぞれ）において送信されることが仮定される。第３に、ＨＡＲＱフィードバックが、チャネルＮＢ−ＰＤＣＣＨ／ＮＢ−ＰＵＳＣＨにおいて送信されることが仮定される（ＨＡＲＱフィードバックのためのＵＬリソースは、ＮＢ−ＰＤＣＣＨにおいて、ＤＬ割当の一部として送信されると仮定される）。最後に、非同期ＨＡＲＱがＤＬとＵＬとの両方で使用されることが仮定される。本開示の範囲は、本明細書で説明された様々な例示的な実施形態に限定されないことに注目されたい。いくつかのケースでは、上記仮定のどれも当てはまらないか、いくつか、または、すべてが当てはまり得る。

上述したように、ＵＥ５１０は、ＤＬ制御チャネル（たとえば、ＮＢ−ＰＤＣＣＨ）をモニタし得る。本明細書では、ＵＥ５１０がＤＬ制御チャネルをモニタする時間は、「アクティブ時間」と称される。「アクティブ時間」の開始、「アクティブ時間」の停止、「アクティブ時間」の満了、および、「アクティブ時間」の長さおよび開始の情報をどのようにして取得するのかに関するＵＥ５１０の挙動が、図５のコンテキストにおいて以下に一般的に、および、以下の図６Ａ〜図９Ｂに関して詳細に説明される。いくつかの実施形態では、「アクティブ時間」の開始は、ＵＥ５１０からのＵＬ送信後の「オフセット時間」を発生させる。

いくつかの実施形態では、ＵＥ５１０の挙動は、ＮＢ−ＩｏＴのコンテキストで説明され、「アクティブ時間」が満了した場合、ＵＥ５１０は、レガシーＬＴＥにおける場合と同様な手法でＤＲＸオペレーションへ入ると言われる（すなわち、ＤＲＸサイクル毎に、「ＯｎＤｕｒａｔｉｏｎ時間」中のみ、ＮＢ−ＰＤＣＣＨがモニタされる）。しかしながら、本明細書で説明された様々な実施形態は、ＮＢ−ＩｏＴコンテキストに限定されないことに注目されたい。むしろ、本開示は、本明細書で説明された様々な実施形態が、任意の適切なＲＡＴへ適用可能であることを考慮する。

一般に、２つの主なパラメータ、すなわち、ＵＥがＤＲＸへ入る前に、ＤＬ制御チャネルをモニタするために、どれくらい長くＵＥがアウェイクすべきであるかを判定する「アクティブ時間」と、「アクティブ時間」をいつ開始するのかを判定する「オフセット時間」とが使用される。上述されるように、（本明細書では置換可能に「オフセット期間」と称され得る）「オフセット時間」は、ＵＥ５１０のためのＤＬまたはＵＬ送信を示すインジケーションを受信することによってトリガされたＵＥ５１０によって実行されるＵＬ送信（たとえば、ＵＬ送信がＨＡＲＱフィードバックメッセージであるという結果になるＤＬデータを受信するためのＤＬ割当、または、前記ＵＬ送信がＵＬデータであるという結果となるＵＬグラントのような、ＤＬ制御チャネル（たとえば、ＮＢ−ＰＤＣＣＨ）における制御メッセージ）に対して開始される。

新たな制御メッセージが、「アクティブ時間」中に、ＤＬ制御チャネルにおいて受信されるのであれば、「アクティブ時間」は停止される（すなわち、ＵＥは、ＤＬ制御チャネル（たとえば、ＮＢ−ＰＤＣＣＨ）をモニタするために、アウェイクする必要はない）。代わりに、示された前記制御メッセージ（たとえば、ＤＬ割当またはＵＬグラント）のような動作が先ず実行され、新たな「アクティブ時間」および「オフセット時間」が使用される。

いくつかの実施形態では、２つのパラメータ（「アクティブ時間」および「オフセット時間」）の値に関する情報が、ＤＬ制御チャネルで送信されたＤＬ割当／ＵＬグラントメッセージの一部として、送信毎に提供され、すべてのＤＬ割当／ＵＬグラント間で変動し得る。たとえば、いくつかの実施形態では、ネットワークノード（たとえば、ネットワークノード５１５）が、ＤＲＸオペレーションを制御するために、ＵＥ５１０による使用のための「アクティブ時間」および「オフセット時間」の持続時間を判定し得る。ネットワークノード５１５は、「アクティブ時間」および「オフセット時間」の持続時間に関する情報を、ＵＥ５１０へ送信し得る。ネットワークノード５１５は、任意の適切な方式で、この情報をＵＥ５１０へ送信し得る。一例として、ネットワークノード５１５は、「アクティブ時間」および「オフセット時間」の持続時間に関する情報を含むメッセージをＵＥ５１０へ送信し得る。別の例として、「アクティブ時間」および「オフセット時間」の持続時間に関する情報は、ＵＥ５１０のためのＤＬまたはＵＬ送信を示すインジケーション（たとえば、ＵＬ送信がＨＡＲＱフィードバックメッセージであるという結果になるＤＬデータを受信するためのＤＬ割当、または、前記ＵＬ送信がＵＬデータであるという結果となるＵＬグラントのようなＤＬ制御チャネル（たとえば、ＮＢ−ＰＤＣＣＨ）における制御メッセージ）に含まれ得る。

いくつかの例示的な実施形態は、時間持続として説明されたパラメータに関して説明され得るが、これは、例示のみの目的のためである。本明細書において説明された様々な実施形態は、そのような例に限定されない。むしろ、本開示は、様々な実施形態のこれらの特徴を実施、指定、説明、および／または、モデル化する場合に、代わりに使用され得ることを考慮する。当業者は、時間持続またはタイマを使用する説明は、等価であり得ることを理解する。いくつかのケースでは、本明細書で説明された様々な実施形態をデバイスにおいて実施する場合、タイマが好適に使用され得る。そのようなシナリオでは、ＵＥ５１０は、ＵＬ送信の終了後、（持続時間「オフセット時間」で）タイマを開始し、そして、前記タイマの満了時に、（持続時間「オフセット時間」で）新たなタイマが開始され得、実行中、ＵＥ５１０は、ＤＬ制御チャネル（たとえば、ＮＢ−ＰＤＣＣＨ）をモニタする。多数のタイマの使用が本明細書で考察されているが、代替実施形態に従って、時間持続がまだモニタされ判定される限り、より少ないタイマが使用され得る（または、タイマがない場合さえもある）。

たとえば、いくつかの実施形態では、ＵＥ５１０は、少なくとも第１のタイマの持続時間中、ＤＬ制御チャネル（たとえば、ＮＢ−ＰＤＣＣＨ）をモニタする。いくつかの実施形態では、１つまたは複数のタイマが、このとき、実行中であり得る。いくつかの実施形態では、１つまたは複数のタイマのうちの第１のタイマは、ＤＲＸサイクルのＯｎＤｕｒａｔｉｏｎタイマ、ｄｒｘ−Ｉｎａｃｔｉｖｉｔｙタイマ、およびＤＲＸ再送信タイマのうちの１つであり得る。ＵＥ５１０は、モニタされたＤＬ制御チャネルにおいて、ＵＥ５１０のためのＤＬまたはＵＬ送信を示すインジケーション（たとえば、ＤＬスケジューリング割当またはＵＬグラントそれぞれ）を受信し得る。ＵＥ５１０のためのＤＬまたはＵＬ送信を示すインジケーションを受信した後、ＵＥ５１０は、第１のタイマをモニタすることを停止し、ＵＥ５１０のための示されたＤＬまたはＵＬ送信に関連付けられたＵＬ送信を実行し得る（たとえば、ＵＬにおいてＡＣＫメッセージまたはデータ送信を送信し得る）。いくつかの実施形態に従って、ＵＥ５１０のためのＤＬまたはＵＬ送信を示すインジケーションを受信した後、ＵＥ５１０はまた、ＤＬ制御チャネルをモニタすることを停止し得る。代替実施形態に従って、ＵＥは、この点において、ＤＬ制御チャネルをモニタすることを要求されないが、モニタし続け得る。ＤＬまたはＵＬ送信を示すインジケーションを受信した後、ＵＥ５１０は、第２のタイマを開始し、第２のタイマの持続時間は、オフセット期間を含む（たとえば、オフセット期間を含むＨＡＲＱ−ＲＴＴタイマ）。いくつかの実施形態に従って、ＵＥは、関連付けられたＵＬ送信を実行した後、第２のタイマを開始し得る。第２のタイマが満了した場合、ＵＥ５１０は、第３のタイマ（たとえば、ｄｒｘ−Ｉｎａｃｔｉｖｉｔｙタイマまたは間欠受信再送信タイマ）を開始し得る。いくつかの実施形態では、ＵＥ５１０は、第３のタイマの持続時間中、ＤＬ制御チャネルをモニタし得、第３のタイマが満了した場合、ＤＲＸモードに入り得る。

ここで、様々な実施形態が、図６〜図９に関してより詳細に以下に説明される。図６〜図９に図示される送信の時間持続と、送信間のオフセットとは、実物通りに拡大縮小されておらず、必ずしも１フレーム／サブフレーム（たとえば、１ミリ秒）のような時間単位である必要はないことに注目されたい。むしろ、図６〜図９は、異なるＮＢ−ＩｏＴ物理チャネルで何が（たとえば、制御／データが）送信されるのか、どのような順序か、異なるチャネル／送信オフセット、および、どのようなタイマ持続時間が存在するのかを例示するために使用される。以下の説明は、時間持続とタイマとの両方の使用の例を含むことに注目されたい。いずれかの実施が可能であることを反映するために、図６〜図９は、「＊時間／タイマ」、「オフセット時間／タイマ」、および「アクティブ時間／タイマ」を例示する。

図６Ａは、いくつかの実施形態に従って、ＤＲＸオペレーションを制御するためのタイミングおよび送信の第１の例を例示する。さらに詳しくは、図６Ａは、ダウンリンク制御チャネル６１０（図６Ａの例におけるＮＢ−ＰＤＣＣＨ）において受信された、ＵＥのためのＤＬ送信６０５を示すインジケーション、すなわち、（図６Ａの例示おいてＤＣＩ−１と示される）ＤＬスケジューリング割当を、結果として得られるデータ送信６１５とともに図示する。言い換えれば、ＤＬデータブロック６１５（図６Ａの例においてＳＲＢ／ＤＲＢと示される）がＮＢ−ＰＤＳＣＨ６２０において（シグナリング無線ベアラ（ＳＲＢ）またはデータ無線ベアラ（ＤＲＢ）のいずれかにおいて）ＵＥによって受信されるようにスケジュールするメッセージ６０５（ＤＣＩ−１と示される）が、ＤＬ制御チャネル６１０においてＵＥによって受信される。上述したように、ＮＢ−ＰＵＳＣＨ６２５のためのＨＡＲＱフィードバックリソースは、ＮＢ−ＰＤＣＣＨメッセージ６０５（すなわち、ＤＣＩ−１）に含まれるべきであると仮定される。

図６Ａの例では、ＵＥのためのＤＬ送信６０５を示すインジケーションを受信した後（すなわち、ＤＣＩ−１が受信された場合）、「＊時間」６３０が停止され、ＵＥは、ＤＬ制御チャネル６１０をモニタすることを停止する。なぜなら、ＵＥにおける成功裏の受信によって、ＤＬ制御チャネル６１０はもはやモニタされる必要はないからである。代替実施形態に従って、たとえＵＥがモニタすることを要求されなくても、制御チャネル６１０は未だにモニタされ得る。「＊」は、「Ｏｎ Ｄｕｒａｔｉｏｎ」または「アクティブ」時間のいずれかであり得ることを示す。たとえば、１つまたは複数のタイマが使用される実施形態では、図６Ａの例で図示される「＊時間」６３０は、ＵＥがＤＬ制御チャネル６１０をモニタする持続時間中、第１のタイマであり得る。たとえば、第１のタイマ６３０は、ＤＲＸサイクルのｏｎＤｕｒａｔｉｏｎタイマ、ｄｒｘ−Ｉｎａｃｔｉｖｉｔｙタイマ、およびＤＲＸ再送信タイマのうちの１つであり得る。メッセージ６０５は、時間的に後に、ＵＬ送信動作６３５をトリガする。図６Ａの例で図示されるＤＬ割当のケースでは、ＮＢ−ＰＤＳＣＨ６２０において、先ず、ＳＲＢ／ＤＲＢデータ６１５が受信され、復号結果に基づいて、ＨＡＲＱフィードバック（図６Ａの例におけるＡＣＫ６３５）がＮＢ−ＰＵＳＣＨ６２５において送信される。言い換えれば、ＤＣＩ−１メッセージ６０５は、ＵＥのためのＤＬ送信を示すインジケーションであり、ＵＥは、示されたＤＬ送信（すなわち、アクノレッジメントメッセージの送信）に関連付けられたＵＬ送信６３５を実行する。

関連付けられたＵＬ送信６３５を実行した後、ＵＬ送信６３５終了の「オフセット時間」６４５後に「アクティブ時間」６４０が開始される。タイマが使用される実施形態では、たとえば、関連付けられたＵＬ送信６３５（図６Ａの例におけるＡＣＫメッセージ）を実行した後、ＵＥは、第２のタイマ６４５を開始する。第２のタイマ６４５の持続時間は、オフセット期間であり得るか、または、オフセット期間を含み得る。たとえば、第２のタイマ６４５は、オフセット期間を含むＨＡＲＱ−ＲＴＴタイマであり得る。第２のタイマ６４５が満了した場合、ＵＥは、上述した「アクティブ時間」に対応する第３のタイマ６４０を開始する。いくつかの実施形態では、第３のタイマ６４０は、ｄｒｘ−ＩｎａｃｔｉｖｉｔｙタイマおよびＤＲＸ再送信タイマのうちの１つであり得る。「アクティブ時間」中（たとえば、第３のタイマ６４０の持続時間中）、ＵＥは、ＤＬ制御チャネル６１０（図６Ａの例におけるＮＢ−ＰＤＣＣＨ）をモニタする。「アクティブ時間」６４０が終了する前（たとえば、第３のタイマ６４０が満了する前）に、ＮＢ−ＰＤＣＣＨメッセージが受信されないのであれば、ＵＥは、図６Ａの例に図示されるように、ＤＲＸモード６６０へ入る。ＤＲＸの間、ＤＬ制御チャネル６１０（たとえば、ＮＢ−ＰＤＣＣＨ）をモニタするために、以前に説明された概念が当てはまる（すなわち、ＵＥは、時間期間６５０（「Ｏｎ Ｄｕｒａｔｉｏｎ」）ウェイクアップする）。

図６Ａの例では、ＤＣＩ−１メッセージ６０５から伸びる矢印６５５ａ〜ｄは、「オフセット時間」６４５および「アクティブ時間」６４０のサイズ（たとえば、持続時間）（または、上述した第２のタイマ６４５および第３のタイマ６４０それぞれの持続時間）が、ＤＣＩ−１メッセージ６０５（または、タイマ持続時間を判定することができる関連情報）に含まれていることを例示することが意図されている。いくつかの実施形態では、これらパラメータは、スケジュールされた各送信（たとえば、ＤＬ割当またはＵＬグラント）間で変化し得、これらパラメータは、すべての送信のために、動的に変化されるようになる。たとえば、ネットワークノード（たとえば、図５に関して上述したｅＮＢ５１５）は、ＤＲＸオペレーションを制御するために、ＵＥによる使用のために、上述したオフセット期間を含む第２のタイマ６４５と、第３のタイマ６４０との持続時間を判定し得る。第２のタイマ６４５の持続時間は、ＵＥが第３のタイマ６４０を開始する前に、ＵＥのための示されたＤＬ送信に関連付けられたＵＬ送信６３５を送信した後、ＵＥが待つ時間の長さであり得る。第３のタイマ６４０の持続時間は、ＤＲＸモードに入る前にＵＥがＤＬ制御チャネル６１０をモニタする時間の長さを含み得る。ネットワークノードは、第２のタイマ６４５および第３のタイマ６４０の持続時間に関する情報をＵＥへ送信し得る。

本開示は、様々なパラメータ（たとえば、上述した「オフセット時間」６４５および「アクティブ時間」６４０の長さ、または、第２のタイマ６４５および第３のタイマ６４０の持続時間）に関する情報が、任意の適切な方式でシグナリングされ得ることを考慮する。たとえば、これら情報は、Ｌ３メッセージの一部であり得るか、または、システム情報でブロードキャストされ得る。そのようなシナリオでは、これらパラメータは、以前のアプローチにおけるように半静的であり、ＮＢ−ＰＤＣＣＨメッセージ６０５の一部（たとえば、図６Ａの例におけるＤＣＩ−１）として送信するほど柔軟ではない。また、正確な値が必ずしもシグナリングされる必要はないことに注目されたい。その代わり、テーブルがブロードキャストおよび／または事前定義され得、そのテーブルへのインデクスがシグナリングされ得、および／または、含まれ得る。

ＤＬ割当を含む図６Ａの例では、異なる時間持続の典型的な例が以下に与えられる。しかしながら、たとえば、使用されるＵＬ／ＤＬ周波数リソース、符号化率および繰返しの数（すなわち、反復）、メッセージ／データサイズ、変調タイプ、ネットワークノード（たとえば、ｅＮＢ）スケジューリング戦略、および、他の任意の適切な基準に依存して、任意の値が当てはまり得ることに注目されたい。いくつかの実施形態では、ＮＢ−ＰＤＣＣＨ（ＤＣＩ−１）持続時間は２ミリ秒であり得る。ＮＢ−ＰＤＣＣＨとＮＢ−ＰＤＳＣＨとの間のオフセットは、４ミリ秒であり得る。ＮＢ−ＰＤＳＣＨ（ＳＲＢ／ＤＲＢ）持続時間は、２０ミリ秒であり得る。ＮＢ−ＰＤＳＣＨとＮＢ−ＰＵＳＣＨとの間のオフセットは、２ミリ秒であり得る。ＮＢ−ＰＵＳＣＨ（ＡＣＫ）持続時間は、４ミリ秒であり得る。「オフセット時間」６４５の持続時間は、１０ミリ秒であり得る。「アクティブ時間」６４０の持続時間は、２０ミリ秒であり得る。

図６Ｂは、いくつかの実施形態に従って、図６ＡにおけるＤＲＸオペレーションを制御するためのタイミングおよび送信の第１の例のバリエーションを例示する。図６Ｂは、図６Ａに類似しているので、相違点のみが説明される。図６Ｂの例示的な実施形態では、ＤＬ制御チャネル６１０（図６Ｂの例におけるＮＢ−ＰＤＣＣＨ）において受信されたＵＥのためのＤＬ送信６０５の受信されたインジケーション、すなわち、（図６Ｂの例においてＤＣＩ−１と示される）ＤＬスケジューリング割当の終了の「オフセット時間」６４５後に「アクティブ時間」６４０が開始される。タイマが使用される実施形態では、たとえば、ＵＥのためのＤＬ送信６０５を示す受信されたインジケーションの終了後、ＵＥが第２のタイマ６４５を開始する。第２のタイマ６４５の持続時間は、オフセット期間であり得るか、または、オフセット期間を含み得る。たとえば、第２のタイマ６４５は、オフセット期間を含むＨＡＲＱ−ＲＴＴタイマであり得る。第２のタイマ６４５が満了した場合、ＵＥは、「アクティブ時間」に対応する第３のタイマ６４０を開始する。

図７Ａは、いくつかの実施形態に従って、ＤＲＸオペレーションを制御するためのタイミングおよび送信の第２の例を例示する。さらに詳しくは、図７Ａは、ＵＥのためのＵＬ送信を示すインジケーション、すなわち、（図７Ａの例においてＤＣＩ−０と示される）ＵＬグラント７０５を、結果として得られるＵＬ送信７１０とともに図示する。言い換えれば、（ＤＣＩ−０と示される）メッセージ７０５は、ＮＢ−ＰＵＳＣＨ７２０において（ＳＲＢまたはＤＲＢのいずれかにおいて）ＵＥによって送信されるべきＵＬデータブロック７１０をスケジュールするＤＬ制御チャネル７１５（図７Ａの例におけるＮＢ−ＰＤＣＣＨ）においてＵＥによって受信される。

図７Ａの例では、ＵＥのためのＵＬ送信を示すインジケーションを受信した後（すなわち、ＤＣＩ−０ ７０５が受信された場合）、「＊時間」７２５が停止され、ＵＥは、ＤＬ制御チャネル７１５をモニタすることを停止する。なぜなら、ＤＬ制御チャネル７１５（図７の例におけるＮＢ−ＰＤＣＣＨ）は、ＵＥにおける成功裏の受信によって、もはやモニタされる必要はないからである。代替実施形態に従って、たとえＵＥがモニタすることを要求されなくても、制御チャネル７１５は未だにモニタされ得る。上述した図６Ａと同様に、「＊時間」７２５は、「Ｏｎ Ｄｕｒａｔｉｏｎ」または「アクティブ」時間のいずれかであり得ることを示す。たとえば、１つまたは複数のタイマが使用される実施形態では、「＊時間」７２５は、ＵＥがＤＬ制御チャネル７１５をモニタする持続時間中の第１のタイマ７２５であり得る。たとえば、第１のタイマ７２５は、ＤＲＸサイクルのｏｎＤｕｒａｔｉｏｎタイマ、ｄｒｘ−Ｉｎａｃｔｉｖｉｔｙタイマ、およびＤＲＸ再送信タイマのうちの１つであり得る。メッセージ７０５は、時間的に後に、ＵＬ送信動作７１０をトリガする。図７Ａの例において図示されるＵＬグラントのケースでは、ＵＥは、ＮＢ−ＰＵＳＣＨ７２０におけるＳＲＢ／ＤＲＢデータの送信７１０を実行する。言い換えれば、ＤＣＩ−０メッセージ７０５は、ＵＥのためのＵＬ送信７１０を示すインジケーションであり、ＵＥは、このインジケーションに関連付けられたＵＬ送信（すなわち、ＮＢ−ＰＵＳＣＨ７２０におけるＳＲＢ／ＤＲＢデータの送信７１０）を実行する。

関連付けられたＵＬ送信７１０を実行した後、ＵＬ送信７１０終了の「オフセット時間」７３５後に「アクティブ時間」７３０が開始される。タイマが使用される実施形態では、たとえば、関連付けられたＵＬ送信７１０を実行した後、ＵＥは、上述した「オフセット時間」に対応する第２のタイマ７３５を開始する。第２のタイマ７３５の持続時間は、オフセット期間であり得るか、または、オフセット期間を含み得る。たとえば、第２のタイマ７３５は、オフセット期間を含むＨＡＲＱ−ＲＴＴタイマであり得る。第２のタイマ７３５が満了した場合、ＵＥは、上述した「アクティブ時間」に対応する第３のタイマ７３０を開始する。いくつかの実施形態では、第３のタイマ７３０は、ｄｒｘ−ＩｎａｃｔｉｖｉｔｙタイマおよびＤＲＸ再送信タイマのうちの１つであり得る。「アクティブ時間」７３０中（たとえば、第３のタイマ７３０の持続時間中）、ＵＥは、ＤＬ制御チャネル７１５（図７Ａの例におけるＮＢ−ＰＤＣＣＨ）をモニタする。「アクティブ時間」７３０が終了する前（すなわち、第３のタイマ７３０が満了する前）に、ＮＢ−ＰＤＣＣＨメッセージが受信されないのであれば、ＵＥは、図７Ａの例に図示されるように、ＤＲＸモード７５０へ入る。ＤＲＸの間、ＤＬ制御チャネル７１５（たとえば、ＮＢ−ＰＤＣＣＨ）をモニタするために、以前に適用された概念が当てはまる（すなわち、ＵＥは、時間期間７４０（「Ｏｎ Ｄｕｒａｔｉｏｎ」）ウェイクアップする）。

図７Ａの例では、ＤＣＩ−０メッセージ７０５から伸びる矢印７４５ａ〜ｃは、「オフセット時間」７３５および「アクティブ時間」７３０のサイズ（たとえば、持続時間）（または、上述した第２のタイマ７３５および第３のタイマ７３０それぞれの持続時間）が、ＤＣＩ−０メッセージ７０５（または、タイマ持続時間を判定することができる関連情報）に含まれていることを例示することが意図されている。いくつかの実施形態では、これらパラメータは、スケジュールされた各送信（たとえば、ＤＬ割当またはＵＬグラント）間で変化し得、これらパラメータは、すべての送信のために、動的に変化されるようになる。たとえば、ネットワークノード（たとえば、図５に関して上述したｅＮＢ５１５）は、ＤＲＸオペレーションを制御するために、ＵＥによる使用のために、上述した第２のタイマ７３５および第３のタイマ７３０の持続時間を判定し得る。第２のタイマ７３５の持続時間は、ＵＥのための示されたＤＬまたはＵＬ送信に関連付けられたＵＬ送信７１０を送信した後、ＵＥが第３のタイマ７３０を開始する前にＵＥが待つ時間の長さであり得る。第３のタイマ７３０の持続時間は、ＤＲＸモードに入る前に、ＵＥがＤＬ制御チャネル７１５をモニタする時間の長さを含み得る。ネットワークノードは、第２のタイマ７３５および第３のタイマ７３０の持続時間に関する情報をＵＥへ送信し得る。

本開示は、様々なパラメータ（たとえば、上述した「オフセット時間」７３５および「アクティブ時間」７３０の長さ、または、第２のタイマ７３５および第３のタイマ７３０の持続時間）に関する情報が、任意の適切な方式でシグナリングされ得ることを考慮する。たとえば、これら情報は、Ｌ３メッセージの一部であり得るか、または、システム情報でブロードキャストされ得る。そのようなシナリオでは、これらパラメータは、半静的であり、ＮＢ−ＰＤＣＣＨメッセージの一部（たとえば、図７Ａの例におけるＤＣＩ−０ ７０５）として送信するほど柔軟ではない。また、正確な値が必ずしもシグナリングされる必要はないことに注目されたい。その代わり、テーブルがブロードキャストおよび／または事前定義され得、そのテーブルへのインデクスがシグナリングされ得、および／または、含まれ得る。

本開示は、様々なパラメータの値は、任意の適切な値であり得ることを考慮する。いくつかの実施形態では、値は、任意の適切な基準に基づいて変動し得る。たとえば、様々なパラメータの値は、使用されるＵＬ／ＤＬ周波数リソース、符号化率および繰返しの数（すなわち、反復）、メッセージ／データサイズ、変調タイプ、ネットワークノード（たとえば、ｅＮＢ）スケジューリング戦略、および、他の任意の適切な基準に依存し得る。

図７Ｂは、いくつかの実施形態に従って、図７ＡにおけるＤＲＸオペレーションを制御するためのタイミングおよび送信の第２の例のバリエーションを例示する。図７Ｂは、図７Ａに類似しているので、相違点のみが説明される。図７Ｂの例示的な実施形態では、ＤＬ制御チャネル７１５（図７Ｂの例におけるＮＢ−ＰＤＣＣＨ）において受信されたＵＥのためのＤＬ送信７０５の受信されたインジケーション、すなわち、（図７Ｂの例においてＤＣＩ−０と示される）ＵＬグラントの終了の「オフセット時間」７３５後に「アクティブ時間」７３０が開始される。タイマが使用される実施形態では、たとえば、ＵＥのためのＵＬ送信７０５を示す受信されたインジケーションの終了後、ＵＥは、第２のタイマ７３５を開始する。第２のタイマ７３５の持続時間は、オフセット期間であり得るか、または、オフセット期間を含み得る。たとえば、第２のタイマ７３５は、オフセット期間を含むＨＡＲＱ−ＲＴＴタイマであり得る。第２のタイマ７３５が満了した場合、ＵＥは「アクティブ時間」に対応する第３のタイマ７３０を開始する。

図８Ａは、いくつかの実施形態に従って、ＤＲＸオペレーションを制御するためのタイミングおよび送信の第３の例を例示する。さらに詳しくは、図８Ａは、ＤＬのためのＨＡＲＱ再送信がトリガされるシナリオを例示する。図６Ａに例示されたＤＲＸオペレーションを制御するためのタイミングおよび送信の例と類似して、図８Ａは、ＵＥのためのＤＬ送信８０５を示すインジケーション、すなわち、ダウンリンク制御チャネル８１０におけるＤＬスケジューリング割当（図８Ａの例においてＤＣＩ−１と示される）を、結果として得られるデータ送信８１５とともに図示する。言い換えれば、ＤＬ制御チャネル８１０（図８Ａの例におけるＮＢ−ＰＤＣＣＨ）においてＵＥによって受信されたメッセージ８０５（ＤＣＩ−１と示される）は、ＮＢ−ＰＤＳＣＨ８２０において（ＳＲＢまたはＤＲＢのいずれか一方において）ＵＥによって受信されるべきＤＬデータブロック８１５（図８Ａの例においてＳＲＢ／ＤＲＢと示される）をスケジュールする。

図８Ａの例では、ＵＥのためのＤＬ送信８０５を示すインジケーションを受信すると（すなわち、ＤＣＩ−１ ８０５が受信された場合）、「＊時間」８２５が停止され、ＵＥは、ＤＬ制御チャネル８１０をモニタすることを停止する。なぜなら、ＤＬ制御チャネル８１０は、ＵＥにおける成功裏の受信によって、もはやモニタされる必要はないからである。代替実施形態に従って、たとえＵＥがモニタすることを要求されなくても、制御チャネル８１０は未だにモニタされ得る。「＊時間」８２５は、「Ｏｎ Ｄｕｒａｔｉｏｎ」または「アクティブ」時間のいずれかであり得ることを示す。たとえば、１つまたは複数のタイマが使用される実施形態では、図８Ａの例において図示される「＊時間」８２５は、ＵＥがＤＬ制御チャネル８１０をモニタする持続時間中、第１のタイマ８２５であり得る。たとえば、第１のタイマ８２５は、ＤＲＸサイクルのｏｎＤｕｒａｔｉｏｎタイマ、ｄｒｘ−Ｉｎａｃｔｉｖｉｔｙタイマ、およびＤＲＸ再送信タイマのうちの１つであり得る。メッセージ８０５は、時間的に後に、ＵＬ送信動作８３０をトリガする。

図８Ａの例において図示されるＤＬ割当のケースでは、ＮＢ−ＰＤＳＣＨ８２０において、先ず、ＳＲＢ／ＤＲＢデータ８１５が受信され、復号結果に基づいて、ＨＡＲＱフィードバック８３０（図８Ａの例におけるＮＡＣＫ）が送信される。言い換えれば、ＤＣＩ−１メッセージ８０５は、ＵＥのためのＤＬ送信を示すインジケーションであり、ＵＥは、示されたＤＬ送信に関連付けられたＵＬ送信８３０を実行する。図８Ａの例では、関連付けられたＵＬ送信８３０は、ＨＡＲＱ再送信をトリガする「ＮＡＣＫ」の形態のＨＡＲＱフィードバックである。

関連付けられたＵＬ送信８３０を実行した後、ＵＬ送信８３０が終了した後、ＵＬ送信８３０終了の「オフセット時間」８４０後に「アクティブ時間」８３５が開始される。タイマが使用される実施形態では、たとえば、関連付けられたＵＬ送信８３０（図８Ａの例におけるＮＡＣＫメッセージ）を実行した後、ＵＥは、第２のタイマ８４０を開始する。第２のタイマ８４０の持続時間は、オフセット期間であり得るか、オフセット時間を含み得る。たとえば、第２のタイマ８４０は、オフセット期間を含むＨＡＲＱ−ＲＴＴタイマであり得る。第２のタイマ８４０が満了した場合、ＵＥは、上述した「アクティブ時間」に対応する第３のタイマ８３５を開始する。いくつかの実施形態では、第３のタイマ８３５は、ｄｒｘ−ＩｎａｃｔｉｖｉｔｙタイマおよびＤＲＸ再送信タイマのうちの１つであり得る。「アクティブ時間」８３５中（たとえば、第３のタイマ８３５の持続時間中）、ＵＥは、ＤＬ制御チャネル８１０（図８Ａの例におけるＮＢ−ＰＤＣＣＨ）をモニタする。「アクティブ時間」８３５が終了する前（すなわち、第３のタイマ８３５が満了する前）に、ＮＢ−ＰＤＣＣＨメッセージが受信されないのであれば、ＵＥは、ＤＲＸモードに入る。ＤＲＸの間、ＤＬ制御チャネル８１０（たとえば、ＮＢ−ＰＤＣＣＨ）をモニタするために、以前に適用された概念が当てはまる（すなわち、ＵＥは、時間期間（「Ｏｎ Ｄｕｒａｔｉｏｎ」）ウェイクアップする）。

しかしながら、図８Ａの例では、ＵＥは、ＵＥのための第２のＤＬ送信８４５を示すインジケーションを受信し（すなわち、第２のＤＣＩ−１ ８４５が受信された場合）、「アクティブ時間」８３５が停止され、ＵＥがＤＬ制御チャネル８１０をモニタすることを停止する。なぜなら、ＤＬ制御チャネル８１０（図８Ａの例におけるＮＢ−ＰＤＣＣＨ）は、第２のＤＣＩ−１メッセージ８４５のＵＥにおける成功裏の受信によって、もはやモニタされる必要はないからである。第２のメッセージ８４５は、時間的に後に、ＵＬ送信動作８５０をトリガする。図８Ａの例に図示されるＤＬ割当のケースでは、先ず、ＮＢ−ＰＤＳＣＨ８２０でＳＲＢ／ＤＲＢデータ８５５の第２のインスタンスが受信され、復号結果に基づいて、ＨＡＲＱフィードバック（図８Ａの例におけるＡＣＫ８５０）が送信される。言い換えれば、第２のＤＣＩ−１メッセージ８４５は、ＵＥのためのＤＬ送信８５５（すなわち、ＤＬ送信８３５のＨＡＲＱ再送信）を示す第２のインジケーションであり、ＵＥは、示されたＤＬ ＨＡＲＱ再送信に関連付けられたＵＬ送信８５０（すなわち、ＡＣＫメッセージ８５０の送信）を実行する。

関連付けられたＵＬ送信８５０を実行した後、ＵＬ送信８５０終了の「オフセット時間」８６５後に「アクティブ時間」８６０が開始される。タイマが使用される実施形態では、たとえば、関連付けられたＵＬ送信８５０（図８Ａの例におけるＮＡＣＫメッセージ）を実行した後、ＵＥは、第２のタイマ８６５を開始する。第２のタイマ８６５の持続時間は、オフセット期間であり得るか、または、オフセット期間を含み得る。たとえば、第２のタイマ８６５は、オフセット期間を含むＨＡＲＱ−ＲＴＴタイマであり得る。第２のタイマ８６５が満了した場合、ＵＥは、上述した「アクティブ時間」に対応する第３のタイマ８６０を開始する。いくつかの実施形態では、第３のタイマ８６０は、ｄｒｘ−ＩｎａｃｔｉｖｉｔｙタイマおよびＤＲＸ再送信タイマのうちの１つであり得る。「アクティブ時間」８６０中（たとえば、第３のタイマ８６０の持続時間中）、ＵＥは、ＤＬ制御チャネル８１０（図８Ａの例におけるＮＢ−ＰＤＣＣＨ）をモニタする。「アクティブ時間」８６０が終了する前に（すなわち、第３のタイマ８６０が満了する前に）、ＮＢ−ＰＤＣＣＨが受信されないのであれば、ＵＥは、図８Ａの例に図示されるように、ＤＲＸモード８８０へ入る。ＤＲＸの間、ＤＬ制御チャネル８１０（たとえば、ＮＢ−ＰＤＣＣＨ）をモニタするために、以前に適用された概念が当てはまる（すなわち、ＵＥが、時間期間（「Ｏｎ Ｄｕｒａｔｉｏｎ」）ウェイクアップする）。

図８Ａの例では、第１のＤＣＩ−１メッセージ８０５から伸びる矢印８７０ａ〜ｄと、第２のＤＣＩ−１メッセージ８４５から伸びる矢印８７５ａ〜ｄとは、「オフセット時間」８４０、「アクティブ時間」８３５、「オフセット時間」８６５、および「アクティブ時間」８６０のサイズ（たとえば、持続時間）（または、いくつかの実施形態では、上述した第２および第３のタイマそれぞれの持続時間）が、第１のＤＣＩ−１メッセージ８０５および第２のＤＣＩ−１メッセージ８４５それぞれ（または、タイマ持続時間を判定することができる関連情報）に含まれ得ることを例示することが意図されている。いくつかの実施形態では、これらパラメータは、（たとえば、第１のＤＣＩ−１メッセージと第２のＤＣＩ−１メッセージとの間で）スケジュールされた各送信間で変化し得、これらパラメータは、すべての送信のために、動的に変化されるようになる。したがって、「オフセット時間」８４０の持続時間は、「オフセット時間」８６５と同じであり得るか、または、異なり得る。同様に、「アクティブ時間」８３５の持続時間は、「アクティブ時間」８６０と同じであり得るか、または、異なり得る。ネットワークノード（たとえば、図５に関して上述したｅＮＢ５１５）は、ＤＲＸオペレーションを制御するために、ＵＥによる使用のために、上述した第２のタイマ８４０、８６５と第３のタイマ８３５、８６０の持続時間を判定し得る。第２のタイマ８４０、８６５の持続時間は、ＵＥのための示されたＤＬまたはＵＬ送信それぞれに関連付けられたＵＬ送信８３０、８５０を送信した後、ＵＥが第３のタイマ８３５、８６０を開始する前に、ＵＥが待つ時間の長さであり得る。第３のタイマ８３５、８６０の持続時間は、ＵＥが、ＤＲＸモードに入る前に、ＤＬ制御チャネルをモニタする時間の長さを含み得る。ネットワークノードは、第２のタイマ８４０、８６５および第３のタイマ８３５、８６０の持続時間に関する情報をＵＥへ送信し得る。いくつかのケースでは、持続時間は、第１のＤＣＩ−１メッセージ８０５および第２のＤＣＩ−１メッセージ８４５に関連付けられた第１のＤＬ送信について異なり得る。いくつかの実施形態では、持続時間は、同じであり得る。様々なパラメータ（たとえば、上述した「オフセット時間」８４０、８６５および「アクティブ時間」８３５、８６０の長さ、または、第２のタイマ８４０、８６５および第３のタイマ８３５、８６０の持続時間）は、任意の適切な方式でシグナリングされ得る。図６に関して上述したシグナリングの様々な例は、図８Ａの例示的な実施形態に等しく適用可能である。

図８Ｂは、いくつかの実施形態に従って、図８ＡにおけるＤＲＸオペレーションを制御するためのタイミングおよび送信の第３の例のバリエーションを例示する。図８Ｂは、図８Ａに類似しているので、相違点のみが説明される。図８Ｂの例示的な実施形態では、ＤＬ制御チャネル８１０（図８Ｂの例におけるＮＢ−ＰＤＣＣＨ）において受信されたＵＥのためのＤＬ送信８０５を示す受信されたインジケーション、すなわち、（図８Ｂの例においてＤＣＩ−１と示される）ＤＬスケジューリング割当の終了の「オフセット時間」８４０後に「アクティブ時間」８３５が開始される。タイマが使用される実施形態では、たとえば、ＵＥのためのＤＬ送信８０５を示す受信されたインジケーションの終了後、ＵＥは、第２のタイマ８４０を開始する。第２のタイマ８４０の持続時間は、オフセット期間であり得るか、または、オフセット期間を含み得る。たとえば、第２のタイマ８４０は、オフセット期間を含むＨＡＲＱ−ＲＴＴタイマであり得る。第２のタイマ８４０が満了した場合、ＵＥは、「アクティブ時間」に対応する第３のタイマ８３５を開始する。

上述した図８Ａと同様に、図８Ｂの例では、ＵＥは、ＵＥのための第２のＤＬ送信８４５を示すインジケーションを受信する（すなわち、第２のＤＣＩ−１ ８４５が受信された場合）。そのようなシナリオでは、「アクティブ時間」８３５が停止され、ＵＥは、ＤＬ制御チャネル８１０をモニタすることを停止する。しかしながら、図８Ｂの例では、ＤＬ制御チャネル８１０（図８Ｂの例におけるＮＢ−ＰＤＣＣＨ）において受信されたＵＥのためのＤＬ送信８４５を示す受信された第２のインジケーション、すなわち、（図８Ｂの例においてＤＣＩ−１と示される）ＤＬスケジューリング割当の終了の「オフセット時間」８６５後に「アクティブ時間」８６０が開始される。タイマが使用される実施形態では、たとえば、ＵＥのためのＤＬ送信８４５を示す受信された第２のインジケーションの終了後、ＵＥは、第２のタイマ８６５を開始する。第２のタイマ８６５の持続時間は、オフセット期間であり得るか、または、オフセット期間を含み得る。たとえば、第２のタイマ８６５は、オフセット期間を含むＨＡＲＱ−ＲＴＴタイマであり得る。第２のタイマ８６５が満了した場合、ＵＥは、「アクティブ時間」に対応する第３のタイマ８６０を開始する。

図９Ａは、いくつかの実施形態に従って、ＤＲＸオペレーションを制御するためのタイミングおよび送信の第４の例を例示する。さらに詳しくは、図９Ａは、ＨＡＲＱ再送信がＵＬのためにトリガされるシナリオを例示する。上述した図７Ａと同様に、図９Ａの例は、ＵＥのためのＵＬ送信９０５を示す第１のインジケーション、すなわち、（図９Ａの例においてＤＣＩ−０と示される）ＵＬグラントを、結果として得られるＵＬ送信９１０とともに図示する。言い換えれば、第１のメッセージ９０５（ＤＣＩ−０と示される）は、ＮＢ−ＰＵＳＣＨ９２０で（ＳＲＢまたはＤＲＢのいずれかで）ＵＥによって送信されるべきＵＬデータブロック９１０をスケジュールするＤＬ制御チャネル９１５（図９Ａの例におけるＮＢ−ＰＤＣＣＨ）においてＵＥによって受信される。

図９Ａの例では、ＵＥのためのＵＬ送信９０５を示すインジケーションを受信すると（すなわち、ＤＣＩ−０が受信された場合）、「＊時間」９２５が停止され、ＵＥは、ＤＬ制御チャネル９１５をモニタすることを停止する。なぜなら、ＤＬ制御チャネル９１５（図９Ａの例におけるＮＢ−ＰＤＣＣＨ）は、ＵＥにおける成功裏の受信によって、もはやモニタされる必要はないからである。代替実施形態に従って、たとえＵＥがモニタすることを要求されなくても、制御チャネル９１５は未だにモニタされ得る。上述した図７Ａと同様に、「＊時間」９２５は、「Ｏｎ Ｄｕｒａｔｉｏｎ」または「アクティブ」時間のいずれかであり得ることを示す。たとえば、１つまたは複数のタイマが使用される実施形態では、図９Ａの例に図示される「＊時間」９２５は、ＵＥがＤＬ制御チャネル９１５をモニタする持続時間中、第１のタイマ９２５であり得る。たとえば、第１のタイマ９２５は、ＤＲＸサイクルのｏｎＤｕｒａｔｉｏｎタイマ、ｄｒｘ−Ｉｎａｃｔｉｖｉｔｙタイマ、およびＤＲＸ再送信タイマのうちの１つであり得る。メッセージ９０５は、時間的に後に、ＵＬ送信動作９１０をトリガする。図９Ａの例に図示されるＵＬグラントケースにおいて、ＵＥは、ＮＢ−ＰＵＳＣＨ９２０において、ＳＲＢ／ＤＲＢデータの送信９１０を実行する。言い換えれば、ＤＣＩ−０メッセージ９０５は、ＵＥのためのＵＬ送信を示すインジケーションであり、ＵＥは、示されたＵＬ送信に関連付けられたＵＬ送信９１０（すなわち、ＮＢ−ＰＵＳＣＨ９２０におけるＳＲＢ／ＤＲＢデータの送信）を実行する。

関連付けられたＵＬ送信を実行した後、ＵＬ送信９１０終了の「オフセット時間」９３５後に「アクティブ時間」９３０が開始される。タイマが使用される実施形態では、たとえば、関連付けられたＵＬ送信９１０（図９Ａの例において、ＳＲＢ／ＤＲＢのいずれかにおけるＵＬ送信）を実行した後、ＵＥは、第２のタイマ９３５を開始する。第２のタイマ９３５の持続時間は、オフセット期間であり得るか、または、オフセット期間を含み得る。たとえば、第２のタイマ９３５は、オフセット期間を含むＨＡＲＱ−ＲＴＴタイマであり得る。第２のタイマ９３５が満了した場合、ＵＥは、上述した「アクティブ時間」に対応する第３のタイマ９３０を開始する。いくつかの実施形態では、第３のタイマ９３０は、ｄｒｘ−ＩｎａｃｔｉｖｉｔｙタイマおよびＤＲＸ再送信タイマのうちの１つであり得る。「アクティブ時間」９３０中（たとえば、第３のタイマ９３０の持続時間中）、ＵＥは、ＤＬ制御チャネル９１５（図９Ａの例におけるＮＢ−ＰＤＣＣＨ）をモニタする。「アクティブ時間」９３０が終了する前（たとえば、第３のタイマ９３０が満了する前）に、ＮＢ−ＰＤＣＣＨメッセージが受信されないのであれば、ＵＥはＤＲＸモードに入る。

しかしながら、図９Ａの例に図示されるＵＬグラントのケースでは、ＵＥは、「アクティブ時間」９３０の満了前に（たとえば、第３のタイマ９３０の満了前に）ＤＬ制御チャネル９１５において、第２のＤＣＩ−０メッセージまたはＮＡＣＫメッセージのいずれかである第２のメッセージ９４０を受信する。第２のメッセージ９４０がＮＡＣＫメッセージであるシナリオでは、第２のメッセージ９４０は、適応ＨＡＲＱ再送信が使用される（すなわち、暗黙的なＮＡＣＫが使用される）ケースにおいてトグルされない新たなデータインジケータ（ＮＤＩ）を有するＵＬグラントであり得る。第２のメッセージ９４０は、ＵＥのためのＨＡＲＱ ＵＬ再送信９４５を示すインジケーションを提供する。第２のメッセージ９４０を受信すると、「アクティブ時間」９３０（または、いくつかのケースでは、第３のタイマ９３０）が停止され、ＵＥは、ＤＬ制御チャネル９１５をモニタすることを停止する。なぜなら、ＤＬ制御チャネル９１５（図９Ａの例におけるＮＢ−ＰＤＣＣＨ）は、第２のメッセージ９４０（第２のＤＣＩ−０メッセージまたはＮＡＣＫのいずれか）のＵＥにおける成功裏の受信によって、もはやモニタされる必要はないからである。第２のメッセージ９４０は、時間的に後に、ＵＬ送信動作９４５（すなわち、ＵＬ送信９１０のＨＡＲＱ再送信）をトリガする。図９Ａの例に図示されるＵＬグラントのケースでは、ＵＥは、第２のＵＬ送信９４５（すなわち、ＮＢ−ＰＵＳＣＨ９２０における第２のＳＲＢ／ＤＲＢデータの送信）を実行する。

関連付けられた第２のＵＬ送信９４５を実行した後、ＵＬ送信９４５終了の「オフセット時間」９５５後に「アクティブ時間」９５０が開始される。タイマが使用される実施形態では、たとえば、関連付けられた第２のＵＬ送信９４５（図９Ａの例におけるＮＢ−ＰＵＳＣＨ９２０における第２のＳＲＢ／ＤＲＢデータの送信）を実行した後、ＵＥは、第２のタイマ９５５を開始する。第２のタイマ９５５の持続時間は、オフセット期間であり得るか、または、オフセット期間を含み得る。たとえば、第２のタイマ９５５は、オフセット期間を含むＨＡＲＱ−ＲＴＴタイマであり得る。第２のタイマ９５５が満了した場合、ＵＥは、上述した「アクティブ時間」に対応する第３のタイマ９５０を開始する。いくつかの実施形態では、第３のタイマ９５０は、ｄｒｘ−ＩｎａｃｔｉｖｉｔｙタイマおよびＤＲＸ再送信タイマのうちの１つであり得る。「アクティブ時間」９５０中（たとえば、第３のタイマ９５０の持続時間中）、ＵＥは、ＤＬ制御チャネル９１５（図９Ａの例におけるＮＢ−ＰＤＣＣＨ）をモニタする。ＮＢ−ＰＤＣＣＨメッセージが、「アクティブ時間」９５０が終了する前（たとえば、第３のタイマ９５０が満了する前）に受信されないのであれば、ＵＥは、図９Ａの例に図示されるように、ＤＲＸモード９７０へ入る。ＤＲＸの間、ＤＬ制御チャネル９１５（たとえば、ＮＢ−ＰＤＣＣＨ）をモニタするために、以前に適用された概念が当てはまる（すなわち、ＵＥが、時間期間（「Ｏｎ Ｄｕｒａｔｉｏｎ」）ウェイクアップする）。

図９Ａの例において、第１のＤＣＩ−０メッセージ９０５から伸びる矢印９６０ａ〜ｃと、第２のＤＣＩ−０メッセージ９０５から伸びる矢印９６５ａ〜ｃとは、「オフセット時間」９３５、「アクティブ時間」９３０、「オフセット時間」９５５、および「アクティブ時間」９５０のサイズ（たとえば、持続時間）（または、いくつかの実施形態では、上述した第２のタイマ９３５、９５５および第３のタイマ９３０、９５０それぞれの持続時間）が、第１のＤＣＩ−０メッセージ９０５および第２のＤＣＩ−０メッセージ９４０それぞれ（または、タイマ持続時間を判定することができる関連情報）に含まれ得ることを例示することが意図されている。いくつかの実施形態では、これらパラメータは、（たとえば、第１のＤＣＩ−０メッセージ９０５と第２のＤＣＩ−０メッセージ９４０との間で）スケジュールされた各送信間で変化し得、これらパラメータは、すべての送信のために、動的に変化されるようになる。したがって、「オフセット時間」９３５の持続時間は、「オフセット時間」９５５と同じであり得るか、または、異なり得る。同様に、「アクティブ時間」９３０の持続時間は、「アクティブ時間」９５０と同じであり得るか、または、異なり得る。ネットワークノード（たとえば、図５に関して上述したｅＮＢ５１５）は、ＤＲＸオペレーションを制御するために、ＵＥによる使用のために、上述した第２のタイマ９３５、９５５および第３のタイマ９３０、９５０の持続時間を判定し得る。第２のタイマ９３５、９５５の持続時間は、ＵＥのための示されたＵＬ送信にそれぞれ関連付けられたＵＬ送信９１０、９４５を送信した後、ＵＥが第３のタイマ９３０、９５０を開始する前に、ＵＥが待つ時間の長さであり得る。第３のタイマ９３０、９５０の持続時間は、ＤＲＸモードに入る前にＵＥがＤＬ制御チャネル９１５をモニタする時間の長さを含み得る。ネットワークノードは、第２のタイマ９３５、９５５および第３のタイマ９３０、９５０の持続時間に関する情報をＵＥへ送信し得る。いくつかのケースでは、持続時間は、第１のＤＣＩ−０メッセージ９０５と第２のＤＣＩ−０メッセージ９４０に関連付けられた第１のＵＬ送信について異なり得る。いくつかの実施形態では、持続時間は、同じであり得る。様々なパラメータ（たとえば、上述した「オフセット時間」９３５、９５５および「アクティブ時間」９３０、９５０または、第２のタイマ９３５、９５５および第３のタイマ９３０，９５０の持続時間）は、任意の適切な方式でシグナリングされ得る。図６Ａに関して上述したシグナリングの様々な例は、図９Ａの例示的な実施形態に等しく適用可能である。

本開示は、様々なパラメータの値は、任意の適切な値であり得ることを考慮する。いくつかの実施形態では、これら値は、任意の適切な基準に基づいて変動し得る。たとえば、様々なパラメータの値は、使用されるＵＬ／ＤＬ周波数リソース、符号化率および繰返しの数（すなわち、反復）、メッセージ／データサイズ、変調タイプ、ネットワークノード（たとえば、ｅＮＢ）スケジューリング戦略、および、他の任意の適切な基準に依存し得る。

図９Ｂは、いくつかの実施形態に従って、図９ＡにおけるＤＲＸオペレーションを制御するためのタイミングおよび送信の第４の例のバリエーションを例示する。図９Ｂは、図９Ａに類似しているので、相違点のみが説明される。図９Ｂの例示的な実施形態では、ＤＬ制御チャネル９１５（図９Ｂの例におけるＮＢ−ＰＤＣＣＨ）において受信されたＵＥのためのＵＬ送信９０５を示す受信されたインジケーション、すなわち、（図９Ｂの例においてＤＣＩ−０と示される）ＵＬグラントの終了の「オフセット時間」９３５後に「アクティブ時間」９３０が開始される。タイマが使用される実施形態では、たとえば、ＵＥのためのＵＬ送信９０５の受信されたインジケーションの終了後、ＵＥが、第２のタイマ９３５を開始する。第２のタイマ９３５の持続時間は、オフセット期間であり得るか、または、オフセット期間を含み得る。たとえば、第２のタイマ９３５は、オフセット期間を含むＨＡＲＱ−ＲＴＴタイマであり得る。第２のタイマ９３５が満了した場合、ＵＥは、「アクティブ時間」に対応する第３のタイマ９３０を開始する。

上述した図９Ａと同様に、図９Ｂの例では、ＵＥは、「アクティブ時間」９３０の満了前に（たとえば、第３のタイマ９３０の満了前に）ＤＬ制御チャネル９１５において、第２のＤＣＩ−０メッセージまたはＮＡＣＫメッセージのいずれかである第２のメッセージ９４０を受信する。第２のメッセージ９４０は、ＵＥのための第２のＵＬ送信９４５を示すインジケーションを提供する。第２のメッセージ９４０を受信すると、「アクティブ時間」９３０（または、いくつかのケースでは、第３のタイマ９３０）が停止され、ＵＥは、ＤＬ制御チャネル９１５をモニタすることを停止する。しかしながら、図９Ｂの例では、ＤＬ制御チャネル９１５（図９Ｂの例におけるＮＢ−ＰＤＣＣＨ）において受信されたＵＥのためのＵＬ送信９４０の受信された第２のインジケーションの終了の「オフセット時間」９３５後に「アクティブ時間」９５０が開始される。タイマが使用される実施形態では、たとえば、ＵＥのためのＵＬ送信９４０を示す受信された第２のインジケーションの終了時に、ＵＥは、第２のタイマ９５５を開始する。第２のタイマ９５５の持続時間は、オフセット期間であり得るか、オフセット期間を含み得る。たとえば、第２のタイマ９５５は、オフセット期間を含むＨＡＲＱ−ＲＴＴタイマであり得る。第２のタイマ９５５が満了した場合、ＵＥは、「アクティブ時間」に対応する第３のタイマ９５０を開始する。

図６Ａ〜図９Ｂの例示的な実施形態は、停止基準の例としてＤＬ割当およびＵＬグラントを説明しているが、本開示は、これらの例に限定されない。むしろ、本開示は、たとえば、ＤＬ割当またはＵＬグラントではない、定義された他のメッセージを、ＮＢ−ＰＤＣＣＨで送信することによって、「アクティブ時間」のための代替停止基準の使用を考慮する。そのようなメッセージは、たとえば、（ＯｎＤｕｒａｔｉｏｎ／ＤＲＸサイクルを適用して）ＤＲＸへ直接入るようにとの「指示」であり得る。別の例は、「アクティブ時間」および「オフセット時間」を、受信されたＮＢ−ＰＤＣＣＨメッセージに対して延期するために、新たな「オフセット時間」／「アクティブ時間」パラメータを送信することであり得る。これは、（たとえば、現在、あまりに多くのＵＥがサーブされているので）一時的にサーブできないことをＵＥへ示すために行われた。

図１０は、いくつかの実施形態に従う、ＤＲＸオペレーションの例のフローチャートである。ステップ１００５において、ＵＥは、ＯｎＤｕｒａｔｉｏｎ時間またはアクティブ時間の間、ＤＬ制御チャネル（たとえば、ＮＢ−ＰＤＣＣＨ）をモニタする。ステップ１０１０において、ＯｎＤｕｒａｔｉｏｎ時間またはアクティブ時間のいずれかが満了すると、フローはステップ１０１５へ進み、ＵＥは、ＤＲＸモードへ入り、次のＯｎＤｕｒａｔｉｏｎ発生を待つ。ＵＥが、次のＯｎＤｕｒａｔｉｏｎ発生を待つ時間中、ＵＥは、ＤＬ制御チャネルをモニタしない。ステップ１０２０において、次のＯｎＤｕｒａｔｉｏｎ発生が生じる。ステップ１０２５において、ＵＥは、ＯｎＤｕｒａｔｉｏｎタイマを開始する。ＯｎＤｕｒａｔｉｏｎタイマが開始されると、フローはステップ１００５へ戻り、ＵＥは、ＯｎＤｕｒａｔｉｏｎ時間またはアクティブ時間中、ダウンリンク制御チャネル（たとえば、ＮＢ−ＰＤＣＣＨ）をモニタする。

あるいは、ステップ１００５においてＮＢ−ＰＤＣＣＨをモニタしている間、ＵＥがダウンリンク制御チャネルでメッセージ（たとえば、ＤＬスケジューリング割当またはＵＬグラント）を受信したのであれば、フローはステップ１０３０へ進み得る。

いくつかのケースでは、ステップ１０３０において受信されたＮＢ−ＰＤＣＣＨメッセージは、ステップ１０３５において、ＤＲＸ指示であり得る。そのようなシナリオでは、フローは、ステップ１０１５へ進み、ＵＥは、ＤＲＸへ入り、次のＯｎＤｕｒａｔｉｏｎ発生を待つ。そこから、上述したように、ＤＲＸオペレーションが進む。

いくつかのケースでは、ステップ１０４０において、ＵＥは、ダウンリンク制御チャネルで受信されたメッセージの内容を判定する。ステップ１０４０において、ＵＥは、受信したメッセージがＵＬグラントであると判定した場合、フローはステップ１０４５へ進み、ＵＥは、ＵＬ共有チャネル（図１０の例におけるＮＢ−ＰＵＳＣＨ）でＵＬ ＳＲＢおよび／またはＤＲＢデータを送信する。あるいは、ステップ１０４０において、ＵＥは、受信したメッセージが、ＤＬスケジューリング割当であると判定し得る。そのようなシナリオでは、フローはステップ１０５０へ進み、ＵＥは、ＤＬ共有チャネル（図１０の例におけるＮＢ−ＰＤＳＣＨ）でＳＲＢおよび／またはＤＲＢデータを受信し復号する。ステップ１０５５において、ＵＥはＵＬ共有チャネル（たとえば、ＮＢ−ＰＵＳＣＨ）でＨＡＲＱフィードバックを送信する。いくつかの実施形態では、たとえば、ＨＡＲＱフィードバックは、ＡＣＫメッセージまたはＮＡＣＫメッセージであり得る。

フローはその後、ステップ１０６０へ進み、ＵＥは、「オフセット時間」待つ。いくつかの実施形態では、ＵＥはタイマを開始し得る。いくつかの実施形態では、タイマは、関連付けられたＵＬ送信を実行した後（たとえば、ＵＥが、受信したメッセージがＵＬグラントであることを判定した場合）、または、ＵＥのためのＤＬまたはＵＬ送信を示す受信されたインジケーションの終了時、（たとえば、受信したメッセージがＤＬスケジューリング割当であると、ＵＥが判定した場合）のいずれかにおいて開始され得る。したがって、タイマの持続時間は、ステップ１０４５においてＵＬ送信を送信した後、ＵＥが「アクティブ時間」を開始する前に、ＵＥが待つ時間の長さ、または、ステップ１０３０においてＤＬまたはＵＬ送信を示すインジケーションの終了後、ＵＥが「アクティブ時間」を開始する前に、ＵＥが待つ時間の長さを含み得る。ステップ１０６０において「オフセット時間」を待った（または、いくつかの実施形態では、オフセット時間の持続時間を有するタイマが満了した）後、フローはステップ１０６５へ進む。ステップ１０６５において、ＵＥは、アクティブ時間を開始する。いくつかの実施形態では、ＵＥは、ＵＥがＤＲＸモードに入る前にＵＥがＤＬ制御チャネル（たとえば、ＮＢ−ＰＤＣＣＨ）をモニタする時間の長さである持続時間を有する別のタイマを開始し得る。ステップ１０６５においてアクティブ時間を開始した後、フローはステップ１００５へ戻り、ＵＥは、「アクティブ時間」の持続時間中、ＮＢ−ＰＤＣＣＨをモニタする。

図１１は、いくつかの実施形態に従う、ＵＥにおける方法１１００のフロー図である。この方法は、ステップ１１０４において始まり、ＵＥは、少なくとも第１のタイマの持続時間中、ＤＬ制御チャネルをモニタする。いくつかの実施形態では、第１のタイマは、間欠受信サイクルのｏｎＤｕｒａｔｉｏｎタイマであり得る。いくつかの実施形態では、第１のタイマは、ｄｒｘ−Ｉｎａｃｔｉｖｉｔｙタイマであり得る。いくつかの実施形態では、第１のタイマは、間欠受信再送信タイマであり得る。

ステップ１１０８において、ＵＥは、モニタされたＤＬ制御チャネルで、ＵＥのためのＤＬまたはＵＬ送信を示すインジケーションを受信する。いくつかの実施形態では、ＵＥのためのＤＬまたはＵＬ送信を示すインジケーションは、第２および第３のタイマのうちの少なくとも１つの持続時間に関する情報を含み得る。ステップ１１１２において、ＵＥのためのＤＬまたはＵＬ送信を示すインジケーションを受信した後、ＵＥは、第１のタイマをモニタすることを停止する。第１のタイマが停止された後、ＵＥは、ダウンリンク制御チャネルをモニタする必要はない。

ステップ１１１６において、ＵＥは、ＵＥのための示されたＤＬまたはＵＬ送信に関連付けられたＵＬ送信を実行する。いくつかの実施形態では、ＵＥのためのＤＬまたはＵＬ送信を示すインジケーションは、ＤＬスケジューリング割当を含み得、示されたＤＬ送信に関連付けられたＵＬ送信は、アクノレッジメントメッセージを含み得る。いくつかの実施形態では、ＵＥのためのＤＬまたはＵＬ送信を示すインジケーションは、ＵＬグラントを含み得、示されたＵＬ送信に関連付けられたＵＬ送信は、ＵＬにおけるデータ送信を含み得る。

ステップ１１２０において、ＵＥは、ＵＥのためのダウンリンクまたはアップリンク送信のためのインジケーションを受信した後、第２のタイマを開始し、第２のタイマの持続時間は、オフセット期間を含む。いくつかの実施形態では、第２のタイマは、関連付けられたＵＬ送信を実行した後、または、ＵＥのためのＤＬまたはＵＬ送信を示す受信されたインジケーションの終了時、のいずれかにおいて開始され得る。いくつかの実施形態では、第２のタイマは、オフセット期間を含むハイブリッド自動再送要求（ＨＡＲＱ）−ラウンドトリップタイム（ＲＴＴ）タイマであり得る。あるいは、ステップ１１２０において、ＵＥは、ＵＥのためのダウンリンクまたはアップリンク送信のためのインジケーションを受信した後、第２のタイマを開始する。

ステップ１１２４において、第２のタイマが満了した場合、ＵＥは、第３のタイマを開始する。いくつかの実施形態では、この方法は、第３のタイマの持続時間中、ＤＬ制御チャネルをモニタすることを含み得る。いくつかの実施形態では、第１のタイマおよび第３のタイマのうちの少なくとも１つは、ｄｒｘ−Ｉｎａｃｔｉｖｉｔｙタイマであり得る。いくつかの実施形態では、第１のタイマおよび第３のタイマのうちの少なくとも１つは、間欠受信再送信タイマであり得る。

いくつかの実施形態では、この方法は、第３のタイマが満了した場合、間欠受信モードへ入ることを含み得る。いくつかの実施形態では、この方法は、第２および第３のタイマのうちの少なくとも１つの持続時間に関する情報を含むメッセージを受信することを含み得る。

図１２は、いくつかの実施形態に従う、ネットワークノードにおける方法１２００のフロー図である。この方法は、ステップ１２０４において始まり、ネットワークノードは、間欠受信オペレーションを制御するために、ＵＥによる使用のための、第１のタイマの持続時間および第２のタイマの持続時間を判定する。第１のタイマの持続時間は、オフセット期間を含む。いくつかの実施形態では、第１のタイマの持続時間は、ＵＥのための示されたＤＬまたはＵＬ送信に関連付けられたＵＬ送信の送信後、ＵＥが第２のタイマを開始する前に、ＵＥが待つ時間の長さ、および、ＵＥのためのＤＬまたはＵＬ送信を示すインジケーションの終了後、ＵＥが第２のタイマを開始する前に、ＵＥが待つ時間の長さ、のうちの１つを含み得る。いくつかの実施形態では、第１のタイマは、ハイブリッド自動再送要求（ＨＡＲＱ）−ラウンドトリップタイム（ＲＴＴ）タイマであり得る。いくつかの実施形態では、第２のタイマの持続時間は、間欠受信モードに入る前にＵＥがＤＬ制御チャネルをモニタする時間の長さを含み得る。いくつかの実施形態では、第２のタイマは、ｄｒｘ−Ｉｎａｃｔｉｖｉｔｙタイマであり得る。いくつかの実施形態では、第２のタイマは、間欠受信再送信タイマであり得る。

ステップ１２０８において、ネットワークノードは、第１のタイマの持続時間、および、第２のタイマの持続時間に関する情報をＵＥへ送信する。いくつかの実施形態では、第１のタイマの持続時間、および、第２のタイマの持続時間に関する情報は、ＵＥのためのＤＬまたはＵＬ送信を示すインジケーションに含まれ得る。いくつかの実施形態では、第１のタイマの持続時間、および、第２のタイマの持続時間に関する情報をＵＥへ送信することは、第１のタイマの持続時間、および、第２のタイマの持続時間に関する情報を含むメッセージをＵＥへ送信することを含み得る。

いくつかの実施形態では、この方法は、ＵＥのためのＤＬまたはＵＬ送信を示すインジケーションをＵＥへ送信することと、ＵＥのための示されたＤＬまたはＵＬ送信に関連付けられたＵＬ送信をＵＥから受信することとを含み得る。いくつかの実施形態では、ＵＥのためのＤＬまたはＵＬ送信を示すインジケーションは、ＤＬスケジューリング割当を含み得、示されたＤＬ送信に関連付けられたＵＬ送信は、アクノレッジメントメッセージを含み得る。いくつかの実施形態では、ＵＥのためのＤＬまたはＵＬ送信を示すインジケーションは、ＵＬグラントを含み得、示されたＵＬ送信に関連付けられたＵＬ送信は、ＵＬにおけるデータ送信を含み得る。いくつかの実施形態に従って、ネットワークノードは、第３のタイマの持続時間中、ダウンリンク制御メッセージを送信し得る。これは、第１のタイマが停止された後、ＵＥがダウンリンク制御チャネルをモニタすることを停止した場合、有益であり得る。

図１３は、いくつかの実施形態に従う、例示的なＵＥのブロック系統図である。ＵＥ５１０は、セルラーまたは移動体通信システムにおいて、ノードと、および／または、別の無線デバイスと通信する任意のタイプの無線デバイスを指し得る。ＵＥ５１０の例は、モバイル電話、スマートフォン、ＰＤＡ（携帯情報端末）、ポータブルコンピュータ（たとえば、ラップトップ、タブレット）、センサ、モデム、マシン型通信（ＭＴＣ）デバイス／マシンツーマシン（Ｍ２Ｍ）デバイス、ラップトップ埋込機器（ＬＥＥ）、ラップトップ搭載機器（ＬＭＥ）、ＵＳＢドングル、Ｄ２Ｄ対応デバイス、または、無線通信を提供できる別のデバイスを含む。ＵＥ５１０はまた、いくつかの実施形態では、無線デバイス、局（ＳＴＡ）、デバイス、または端末と称され得る。ＵＥ５１０は、トランシーバ１３１０、処理回路１３２０、およびメモリ１３３０を含む。いくつかの実施形態では、トランシーバ１３１０は、（たとえば、アンテナ１３４０を経由して）ネットワークノード５１５へ無線信号を送信することと、ネットワークノード５１５から無線信号を受信することとを容易にし、処理回路１３２０は、ＵＥ５１０によって提供されている上述した機能のうちのいくつかまたはすべてを提供するための命令を実行し、メモリ１３３０は、処理回路１３２０によって実行される命令を記憶する。

処理回路１３２０は、図１〜図１２に関して上述したＵＥ５１０の機能のようなＵＥ５１０の説明された機能のうちのいくつかまたはすべてを実行するための命令を実行し、データを操作するために、１つまたは複数のモジュールにおいて実施されるハードウェアとソフトウェアとの任意の適切な組合せを含み得る。いくつかの実施形態では、処理回路１３２０は、たとえば、１つまたは複数のコンピュータ、１つまたは複数の中央処理装置（ＣＰＵ）、１つまたは複数のマイクロプロセッサ、１つまたは複数のアプリケーション、１つまたは複数の特定用途向け集積回路（ＡＳＩＣ）、１つまたは複数のフィールドプログラマブルゲートアレイ（ＦＰＧＡ）、および／または、他のロジックを含み得る。

メモリ１３３０は、一般に、コンピュータプログラムと、ソフトウェアと、ロジック、ルール、アルゴリズム、コード、テーブル等のうちの１つまたは複数を含むアプリケーションのような命令、および／または、処理回路１３２０によって実行可能な他の命令を記憶するように動作可能である。メモリ１３３０の例は、コンピュータメモリ（たとえば、ランダムアクセスメモリ（ＲＡＭ）または読取専用メモリ（ＲＯＭ））、大容量記憶媒体（たとえば、ハードディスク）、リムーバブル記憶媒体（たとえば、コンパクトディスク（ＣＤ）またはデジタルビデオディスク（ＤＶＤ））、および／または、処理回路１３２０によって使用され得る情報、データ、および／または、命令を記憶する他の任意の揮発性または不揮発性の非一時的コンピュータ読取可能および／またはコンピュータ実行可能なメモリデバイスを含む。

ＵＥ５１０の他の実施形態は、上述した機能のうちのいずれか、および／または、任意の追加機能を含む（上述した解決策をサポートするために必要な任意の機能を含む）、ＵＥの機能のうちのいくつかの態様を提供することを担当し得る、図１３に図示されたものを除く追加の構成要素を含み得る。単なる一例として、ＵＥ５１０は、処理回路１３２０の一部であり得る入力デバイスおよび回路、出力デバイス、および、１つまたは複数の同期ユニットまたは回路を含み得る。入力デバイスは、ＵＥ５１０へのデータの入力のためのメカニズムを含む。たとえば、入力デバイスは、マイクロホン、入力素子、ディスプレイ等のような入力メカニズムを含み得る。出力デバイスは、オーディオ、ビデオ、および／または、ハードコピーフォーマットでデータを出力するためのメカニズムを含み得る。たとえば、出力デバイスは、スピーカ、ディスプレイ等を含み得る。

図１４は、いくつかの実施形態に従う、例示的なネットワークノードのブロック系統図である。ネットワークノード５１５は、ＵＥと、および／または、別のネットワークノードと通信する、任意のタイプの無線ネットワークノードまたは任意のネットワークノードであり得る。ネットワークノード５１５の例は、ｅノードＢ、ノードＢ、基地局、無線アクセスポイント（たとえば、Ｗｉ−Ｆｉアクセスポイント）、低電力ノード、基地トランシーバ局（ＢＴＳ）、リレー、リレーを制御するドナーノード、送信ポイント、送信ノード、リモートＲＦユニット（ＲＲＵ）、リモート無線ヘッド（ＲＲＨ）、ＭＳＲ ＢＳのようなマルチスタンダード無線（ＭＳＲ）無線ノード、分散アンテナシステム（ＤＡＳ）におけるノード、Ｏ＆Ｍ、ＯＳＳ、ＳＯＮ、位置決めノード（たとえば、Ｅ−ＳＭＬＣ）、ＭＤＴ、または他の任意の適切なネットワークノードを含む。ネットワークノード５１５は、ホモジニアス配置、ヘテロジニアス配置、または、混合配置としてネットワーク５００の全体にわたって配置され得る。ホモジニアス配置は、一般に、同じ（または類似の）タイプのネットワークノード５１５、および／または、類似のカバレッジおよびセルサイズおよびサイト間距離から構成された配置を説明し得る。ヘテロジニアス配置は、一般に、異なるセルサイズ、送信電力、能力、およびサイト間距離を有する種々のタイプのネットワークノード５１５を使用した配置を説明し得る。たとえば、ヘテロジニアス配置は、マクロセルレイアウトの全体にわたって据えられた複数の低電力ノードを含み得る。混合配置は、ホモジニアス部分とヘテロジニアス部分との混合を含み得る。

ネットワークノード５１５は、トランシーバ１４１０、処理回路１４２０、メモリ１４３０、およびネットワークインターフェース１４４０のうちの１つまたは複数を含み得る。いくつかの実施形態では、トランシーバ１４１０は、（たとえば、アンテナ１４５０を経由して）ＵＥ５１０へ無線信号を送信し、ＵＥ５１０から無線信号を受信することを容易にし、処理回路１４２０は、ネットワークノード５１５によって提供されている上述した機能のうちのいくつかまたはすべてを提供するための命令を実行し、メモリ１４３０は、処理回路１４２０によって実行される命令を記憶し、ネットワークインターフェース１４４０は、ゲートウェイ、スイッチ、ルータ、インターネット、公衆交換電話網（ＰＳＴＮ）、コアネットワークノード、または、無線ネットワークコントローラ１３０等のようなバックエンドネットワーク構成要素へ信号を通信する。

処理回路１４２０は、上記図１〜図１２に関して上述したもののようなネットワークノード５１５の説明された機能のうちのいくつかまたはすべてを実行するための命令を実行しデータを操作するために、１つまたは複数のモジュールにおいて実施されるハードウェアおよびソフトウェアの任意の適切な組合せを含み得る。いくつかの実施形態では、処理回路１４２０はたとえば、１つまたは複数のコンピュータ、１つまたは複数の中央処理装置（ＣＰＵ）、１つまたは複数のマイクロプロセッサ、１つまたは複数のアプリケーション、および／または、他のロジックを含み得る。

メモリ１４３０は一般に、コンピュータプログラムと、ソフトウェアと、ロジック、ルール、アルゴリズム、コード、テーブル等のうちの１つまたは複数を含むアプリケーションのような命令、および／または、処理回路１４２０によって実行可能な他の命令を記憶するように動作可能である。メモリ１４３０の例は、コンピュータメモリ（たとえば、ランダムアクセスメモリ（ＲＡＭ）または読取専用メモリ（ＲＯＭ））、大容量記憶媒体（たとえば、ハードディスク）、リムーバブル記憶媒体（たとえば、コンパクトディスク（ＣＤ）またはデジタルビデオディスク（ＤＶＤ））、および／または、情報を記憶する他の任意の揮発性または不揮発性、非一時的なコンピュータ読取可能な、および／または、コンピュータ実行可能なメモリデバイスを含む。

いくつかの実施形態では、ネットワークインターフェース１４４０は、処理回路１４２０へ通信可能に結合され、ネットワークノード５１５のための入力を受信し、ネットワークノード５１５からの出力を送信し、入力または出力またはその両方の適切な処理を実行し、他のデバイスへ通信し、または、前述したものの任意の組合せを行うように動作可能な任意の適切なデバイスを指し得る。ネットワークインターフェース１４４０は、ネットワークを介して通信するために、プロトコル変換およびデータ処理機能を含む、適切なハードウェア（たとえば、ポート、モデム、ネットワークインターフェースカード等）およびソフトウェアを含み得る。

ネットワークノード５１５の他の実施形態は、上述した機能のうちのいずれか、および／または、任意の追加機能を含む（上述した解決策をサポートするために必要な任意の機能を含む）、無線ネットワークノードの機能のうちのいくつかの態様を提供することを担当し得る、図１４に図示されたものを除く追加の構成要素を含み得る。様々な異なるタイプのネットワークノードは、同じ物理的なハードウェアを有するが、異なる無線アクセス技術をサポートするように（たとえば、プログラミングによって）設定された構成要素を含み得るか、または、異なる物理的な構成要素を部分的または全体的に表し得る。

図１５は、いくつかの実施形態に従う、例示的な無線ネットワークコントローラまたはコアネットワークノード１３０のブロック系統図である。ネットワークノードの例は、モバイル交換センタ（ＭＳＣ）、サービングＧＰＲＳサポートノード（ＳＧＳＮ）、モビリティ管理エンティティ（ＭＭＥ）、無線ネットワークコントローラ（ＲＮＣ）、基地局コントローラ（ＢＳＣ）等を含み得る。無線ネットワークコントローラまたはコアネットワークノード１３０は、処理回路１５２０、メモリ１５３０、およびネットワークインターフェース１５４０を含む。いくつかの実施形態では、処理回路１５２０は、ネットワークノードによって提供されている上述した機能のうちのいくつかまたはすべてを提供するための命令を実行し、メモリ１５３０は、処理回路１５２０によって実行される命令を記憶し、ネットワークインターフェース１５４０は、ゲートウェイ、スイッチ、ルータ、インターネット、公衆交換電話網（ＰＳＴＮ）、ネットワークノード５１５、無線ネットワークコントローラ、または、コアネットワークノード１３０等のような任意の適切なノードへ信号を通信する。

処理回路１５２０は、無線ネットワークコントローラまたはコアネットワークノード１３０の説明された機能のうちのいくつかまたはすべてを実行するための命令を実行するため、および、データを操作するために、１つまたは複数のモジュールにおいて実施されるハードウェアおよびソフトウェアの任意の適切な組合せを含み得る。いくつかの実施形態では、処理回路１５２０はたとえば、１つまたは複数のコンピュータ、１つまたは複数の中央処理装置（ＣＰＵ）、１つまたは複数のマイクロプロセッサ、１つまたは複数のアプリケーション、および／または、他のロジックを含み得る。

メモリ１５３０は一般に、コンピュータプログラムと、ソフトウェアと、ロジック、ルール、アルゴリズム、コード、テーブル等のうちの１つまたは複数を含むアプリケーションのような命令と、および／または、処理回路１５２０によって実行することが可能な他の命令とを記憶するように動作可能である。メモリ１５３０の例は、コンピュータメモリ（たとえば、ランダムアクセスメモリ（ＲＡＭ）または読取専用メモリ（ＲＯＭ））、大容量記憶媒体（たとえば、ハードディスク）、リムーバブル記憶媒体（たとえば、コンパクトディスク（ＣＤ）またはデジタルビデオディスク（ＤＶＤ））、および／または、情報を記憶する他の任意の揮発性または不揮発性、非一時的なコンピュータ読取可能な、および／または、コンピュータ実行可能なメモリデバイスを含む。

いくつかの実施形態では、ネットワークインターフェース１５４０は、処理回路１５２０へ通信可能に結合され、ネットワークノードのための入力を受信し、ネットワークノードからの出力を送信し、入力または出力またはその両方の適切な処理を実行し、他のデバイスへ通信し、または、前述したものの任意の組合せを行うように動作可能な任意の適切なデバイスを指し得る。ネットワークインターフェース１５４０は、ネットワークを介して通信するために、プロトコル変換およびデータ処理機能を含む、適切なハードウェア（たとえば、ポート、モデム、ネットワークインターフェースカード等）およびソフトウェアを含み得る。

ネットワークノードの他の実施形態は、上述した機能のうちのいずれか、および／または、任意の追加機能を含む（上述した解決策をサポートするために必要な任意の機能を含む）、ネットワークノードの機能のうちのいくつかの態様を提供することを担当し得る、図１５に図示されたものを除く追加の構成要素を含み得る。

図１６は、いくつかの実施形態に従う、例示的なＵＥのブロック系統図である。ＵＥ５１０は、１つまたは複数のモジュールを含み得る。たとえば、ＵＥ５１０は、判定モジュール１６１０、通信モジュール１６２０、受信モジュール１６３０、入力モジュール１６４０、ディスプレイモジュール１６５０、および他の任意の適切なモジュールを含み得る。いくつかの実施形態では、判定モジュール１６１０、通信モジュール１６２０、受信モジュール１６３０、入力モジュール１６４０、ディスプレイモジュール１６５０、または他の任意の適切なモジュールのうちの１つまたは複数は、図１４に関して上述した処理回路１４２０のような処理回路を使用して実施され得る。いくつかの実施形態では、様々なモジュールのうちの複数の機能が、単一のモジュールへ組み合わされ得る。ＵＥ５１０は、図１〜図１２に関して上述した接続モードＤＲＸオペレーションを制御するための方法を実行し得る。

判定モジュール１６１０は、ＵＥ５１０の処理機能を実行し得る。たとえば、判定モジュール１６１０は、少なくとも第１のタイマの持続時間中、ＤＬ制御チャネルをモニタし得る。別の例として、判定モジュール１６１０は、ＵＥのためのＤＬまたはＵＬ送信を示すインジケーションを受信した後、第１のタイマをモニタすることを停止し得る。第１のタイマが停止された後、ＵＥは、ダウンリンク制御チャネルをモニタする必要はない。また別の例として、判定モジュール１６１０は、ＵＥのためのダウンリンクまたはアップリンク送信のためのインジケーションを受信した後、第２のタイマを開始し得、第２のタイマの持続時間は、オフセット期間を含む。さらに別の例として、判定モジュール１６１０は、第２のタイマが満了した場合、第３のタイマを開始し得る。別の例として、判定モジュール１６１０は、第３のタイマの持続時間中、ＤＬ制御チャネルをモニタし得る。別の例として、判定モジュール１６１０は、第３のタイマが満了した場合、間欠受信モードへ入り得る。

判定モジュール１６１０は、図１３に関して上述した処理回路１３２０のような１つまたは複数のプロセッサを含み得るか、または、図１３に関して上述した処理回路１３２０のような１つまたは複数のプロセッサに含まれ得る。判定モジュール１６１０は、上述した判定モジュール１６１０および／または処理回路１３２０の機能のうちのいずれかを実行するように構成されたアナログおよび／またはデジタル回路を含み得る。上述した判定モジュール１６１０の機能は、いくつかの実施形態では、１つまたは複数の別個のモジュールにおいて実行され得る。

通信モジュール１６２０は、ＵＥ５１０の送信機能を実行し得る。たとえば、通信モジュール１６２０は、ＵＥのための示されたＤＬまたはＵＬ送信に関連付けられたＵＬ送信を実行し得る。通信モジュール１６２０は、ネットワーク５００のネットワークノード５１５のうちの１つまたは複数へメッセージを送信し得る。通信モジュール１６２０は、送信機、および／または、図１３に関して上述したトランシーバ１３１０のようなトランシーバを含み得る。通信モジュール１６２０は、メッセージおよび／または信号を無線で送信するように構成された回路を含み得る。特定の実施形態では、通信モジュール１６２０は、判定モジュール１６１０から、送信のためのメッセージおよび／または信号を受信し得る。いくつかの実施形態では、上述した通信モジュール１６２０の機能は、１つまたは複数の別個のモジュールにおいて実行され得る。

受信モジュール１６３０は、ＵＥ５１０の受信機能を実行し得る。一例として、受信モジュール１６３０は、モニタされたＤＬ制御チャネルにおいて、ＵＥのためのＤＬまたはＵＬ送信を示すインジケーションを受信し得る。別の例として、受信モジュール１６３０は、第２および第３のタイマのうちの少なくとも１つの持続時間に関する情報を含むメッセージを受信し得る。受信モジュール１６３０は、受信機、および／または、図１３に関して上述したトランシーバ１３１０のようなトランシーバを含み得る。受信モジュール１６３０は、メッセージおよび／または信号を無線で受信するように構成された回路を含み得る。特定の実施形態では、受信モジュール１６３０は、受信したメッセージおよび／または信号を、判定モジュール１６１０へ通信し得る。上述した受信モジュール１６３０の機能は、いくつかの実施形態では、１つまたは複数の別個のモジュールにおいて実行され得る。

入力モジュール１６４０は、ＵＥ５１０のために意図されたユーザ入力を受信し得る。たとえば、入力モジュールは、キー押圧、ボタン押圧、タッチ、スワイプ、オーディオ信号、ビデオ信号、および／または、他の任意の適切な信号を受信し得る。入力モジュールは、１つまたは複数のキー、ボタン、レバー、スイッチ、タッチスクリーン、マイクロホン、および／または、カメラを含み得る。入力モジュールは、受信した信号を、判定モジュール１６１０へ通信し得る。上述した入力モジュール１６４０の機能は、いくつかの実施形態では、１つまたは複数の別個のモジュールにおいて実行され得る。

ディスプレイモジュール１６５０は、ＵＥ５１０のディスプレイ上に、信号を提示し得る。ディスプレイモジュール１６５０は、ディスプレイ、および／または、ディスプレイ上に信号を提示するように構成された任意の適切な回路およびハードウェアを含み得る。ディスプレイモジュール１６５０は、ディスプレイ上に提示する信号を、判定モジュール１６１０から受信し得る。上述したディスプレイモジュール１６５０の機能は、いくつかの実施形態では、１つまたは複数の別個のモジュールにおいて実行され得る。

判定モジュール１６１０、通信モジュール１６２０、受信モジュール１６３０、入力モジュール１６４０、およびディスプレイモジュール１６５０は、ハードウェアおよび／またはソフトウェアの任意の適切な構成を含み得る。ＵＥ５１０は、上述した機能のうちのいずれか、および／または、任意の追加機能を含む（本明細書で説明された様々な解決策をサポートするために必要な任意の機能を含む）、任意の適切な機能を提供することを担当し得る、図１６に図示されたものを除く追加のモジュールを含み得る。

図１７は、いくつかの実施形態に従う、例示的なネットワークノード５１５のブロック系統図である。ネットワークノード５１５は、１つまたは複数のモジュールを含み得る。たとえば、ネットワークノード５１５は、判定モジュール１７１０、通信モジュール１７２０、受信モジュール１７３０、および他の任意の適切なモジュールを含み得る。いくつかの実施形態では、判定モジュール１７１０、通信モジュール１７２０、受信モジュール１７３０、または、他の任意の適切なモジュールのうちの１つまたは複数は、図１５に関して上述した処理回路１４２０のような１つまたは複数のプロセッサを使用して実施され得る。いくつかの実施形態では、様々なモジュールのうちの複数の機能が、単一のモジュールへ組み合わされ得る。ネットワークノード５１５は、図１〜図１２に関して上述した接続モードＤＲＸオペレーションを制御するための方法を実行し得る。

判定モジュール１７１０は、ネットワークノード５１５の処理機能を実行し得る。たとえば、判定モジュール１７１０は、間欠受信オペレーションを制御するために、ＵＥによる使用のための、第１のタイマの持続時間および第２のタイマの持続時間を判定し得る。第１のタイマの持続時間は、オフセット期間を含む。判定モジュール１７１０は、図１４に関して上述した処理回路１４２０のような１つまたは複数のプロセッサを含み得るか、または、図１４に関して上述した処理回路１４２０のような１つまたは複数のプロセッサに含まれ得る。判定モジュール１７１０は、上述した判定モジュール１７１０および／または処理回路１４２０の機能のうちのいずれかを実行するように構成されたアナログおよび／またはデジタル回路を含み得る。判定モジュール１７１０の機能は、いくつかの実施形態では、１つまたは複数の別個のモジュールにおいて実行され得る。

通信モジュール１７２０は、ネットワークノード５１５の送信機能を実行し得る。一例として、通信モジュール１７２０は、第１のタイマの持続時間、および、第２のタイマの持続時間に関する情報を、ＵＥへ送信し得る。別の例として、通信モジュール１７２０は、第１のタイマの持続時間、および、第２のタイマの持続時間に関する情報を含むメッセージをＵＥへ送信し得る。さらに別の例として、通信モジュール１７２０は、ＵＥのためのＤＬまたはＵＬ送信を示すインジケーションをＵＥへ送信し得る。通信モジュール１７２０は、ＵＥ５１０の１つまたは複数へメッセージを送信し得る。通信モジュール１７２０は、送信機、および／または、図１４に関して上述したトランシーバ１４１０のようなトランシーバを含み得る。通信モジュール１７２０は、メッセージおよび／または信号を無線で送信するように構成された回路を含み得る。特定の実施形態では、通信モジュール１７２０は、判定モジュール１７１０または他の任意のモジュールから、送信のためのメッセージおよび／または信号を受信し得る。通信モジュール１７２０の機能は、いくつかの実施形態では、１つまたは複数の別個のモジュールにおいて実行され得る。

受信モジュール１７３０は、ネットワークノード５１５の受信機能を実行し得る。たとえば、受信モジュール１７３０は、ＵＥのための示されたＤＬまたはＵＬ送信に関連付けられたＵＬ送信をＵＥから受信し得る。受信モジュール１７３０は、ＵＥから任意の適切な情報を受信し得る。受信モジュール１７３０は、受信機、および／または、図１４に関して上述したトランシーバ１４１０のようなトランシーバを含み得る。受信モジュール１７３０は、メッセージおよび／または信号を無線で受信するように構成された回路を含み得る。特定の実施形態では、受信モジュール１７３０は、受信したメッセージおよび／または信号を、判定モジュール１７１０、または、他の任意の適切なモジュールへ通信し得る。受信モジュール１７３０の機能は、いくつかの実施形態では、１つまたは複数の別個のモジュールにおいて実行され得る。

判定モジュール１７１０、通信モジュール１７２０、および受信モジュール１７３０は、ハードウェアおよび／またはソフトウェアの任意の適切な構成を含み得る。ネットワークノード５１５は、上述した機能のうちのいずれか、および／または、任意の追加機能を含む（本明細書で説明された様々な解決策をサポートするために必要な任意の機能を含む）、任意の適切な機能を提供することを担当し得る、図１７に図示されたものを除く追加のモジュールを含み得る。

以下のテキストは、本明細書で説明された、いくつかの実施形態および提案に関する追加の説明を提供し、本発明の範囲を限定するとして理解されるべきではない。レガシーＬＴＥおよびｅＭＴＣにおける接続モードＤＲＸのための機能は、（ショートＤＲＸパラメータを除く）以下のパラメータに基づく。
・ＯｎＤｕｒａｔｉｏｎタイマ
・ｄｒｘＳｔａｒｔＯｆｆｓｅｔ（３６．３３１におけるｌｏｎｇＤＲＸ−ＣｙｃｌｅＳｔａｒｔＯｆｆｓｅｔとしてシグナリングされる）
・ｌｏｎｇＤＲＸ−Ｃｙｃｌｅ（３６．３３１におけるｌｏｎｇＤＲＸ−ＣｙｃｌｅＳｔａｒｔＯｆｆｓｅｔとしてシグナリングされる）
・ｄｒｘ−Ｉｎａｃｔｉｖｉｔｙタイマ
・ＨＡＲＱ−ＲＴＴ−タイマ
・ｄｒｘ−Ｒｅｔｒａｎｓｍｉｓｓｉｏｎタイマ

最初の３つのパラメータは、さらに検討を要する値範囲を除いて、ＮＢ−ＩｏＴのためにそのまま再使用され得る。最後の２つのパラメータは、ＨＡＲＱオペレーションがどのように機能するのかに関連する。このｄｒｘ−Ｉｎａｃｔｉｖｉｔｙタイマパラメータは、（ＭＡＣ ＣＥがシグナリングされないのであれば）非動作後に、ＵＥがＤＲＸに入る場合を制御するために使用されるので、よって、このパラメータの取り扱いが、主に考察されるであろう。方向毎に１つのＨＡＲＱプロセスのみをサポートすることがすでに決定されているので、ＵＥのための半二重オペレーションが仮定されるのであれば、ＨＡＲＱオペレーションの詳細が十分に決定されていなくても、これら最後の３つのパラメータに対する変更／簡素化が考察され、なされ得る。

ＮＢ−ＩｏＴ ＵＥ送信／受信機能が半二重であり、方向毎に１つのＨＡＲＱプロセスのみしか有していないことによって、接続モードＤＲＸのためのＤＲＸ非動作タイマと、ＨＡＲＱ再送信タイマとの取り扱いは、変更／簡素化され得る。したがって、いくつかの実施形態に従って、レガシーパラメータ、すなわちｄｒｘＳｔａｒｔＯｆｆｓｅｔ、ｌｏｎｇＤＲＸ−Ｃｙｃｌｅ、およびＯｎＤｕｒａｔｉｏｎタイマは、ＮＢ−ＩｏＴのために適切な値範囲を用いて、接続モードＤＲＸのためにそのまま再使用され得る。

以下の例では、ＮＢ−ＩｏＴのためのＨＡＲＱオペレーションのための高水準な概念が、ｅＭＴＣに類似していると仮定される。要約するために、以下が仮定される。
・ダウンリンク／アップリンクデータは、ダウンリンク制御チャネルＮＢ−ＰＤＣＣＨにおけるメッセージによってスケジュールされる。
・ダウンリンク／アップリンクデータは、共有チャネルＮＢ−ＰＤＳＣＨおよびＮＢ−ＰＵＳＣＨそれぞれで送信される。
・ＨＡＲＱフィードバックは、チャネルＮＢ−ＰＤＣＣＨ／ＮＢ−ＰＵＳＣＨで送信される。
・ダウンリンクとアップリンクとの両方において非同期ＨＡＲＱが使用される。

次の実施形態では、ＤＲＸオペレーションは、これらＨＡＲＱ仮定を適用することによって説明される。送信の時間持続と、送信間のオフセットとは、時間において変動し得ることに注目されたい。１つの実施形態に従って、我々は、ｄｒｘ−Ｉｎａｃｔｉｖｉｔｙタイマを用いたＤＲＸオペレーションのためにレガシー挙動を使用し、レガシー挙動をＮＢ−ＩｏＴへ適用した。ＮＢ−ＰＤＣＣＨにおけるＵＬまたはＤＬのいずれかにおいてスケジュールされた新たな送信がある毎に、タイマが開始される。このケースでは、ダウンリンク送信が成功裏に終わり、さらなるデータはスケジュールされないので、タイマ満了時に、ＵＥは、ＤＲＸスリープへ入る。

別の実施形態に従って、ＮＢ−ＩｏＴにおいてレガシーＤＲＸタイマを使用する場合、ダウンリンクに１つのＨＡＲＱ再送信が存在する。このためにタイマ、すなわち、ＨＡＲＱ−ＲＴＴタイマ／ｄｒｘ−Ｒｅｔｒａｎｓｍｉｓｓｉｏｎタイマが使用され、再送信が受信された場合、後者はキャンセルされる。

レガシーＬＴＥと比較して、ｅＭＴＣ（およびＬＡＡ）のためのアップリンクＨＡＲＱは、同期から非同期へ変更された。ここでは、非同期ＨＡＲＱによって、アップリンクのためにもＨＡＲＱ−ＲＴＴタイマ／ｄｒｘ−Ｒｅｔｒａｎｓｍｉｓｓｉｏｎタイマと同様な何かを導入する必要がある可能性があることが仮定される。ＮＢ−ＩｏＴに関し、ＤＲＸのためのレガシーベースについて考察する場合、そのようなタイマが必要とされるであろうことが仮定される。したがって、別の実施形態に従って、新たなタイマが仮定された、アップリンクにおけるＨＡＲＱ再送信が存在する。ダウンリンクのケースと同様に、タイマは、再送信がスケジュールされていることをＵＥが検出した場合、キャンセルされる。ＵＥは送信の結果を知らないので、たとえタイマが実際には「再送信タイマ」ではなくても、我々はｄｒｘ−Ｒｅｔｒａｎｓｍｉｓｓｉｏｎタイマと呼ぶことに注目されたい。これはまた、ＨＡＲＱ−ＦｅｅｄｂａｃｋＷｉｎｄｏｗタイマとも称され得る。

考察されるように、レガシーＤＲＸタイマは、ＮＢ−ＩｏＴのためにも使用され得る。このレガシー手法は、（もちろん、ＴＤＤの場合を除いて）両方向における多数のＨＡＲＱプロセスと、フル二重化オペレーションとを含むモバイルブロードバンド使用事例を念頭において開発された。（ＶｏＬＴＥを除いた）これら使用事例にとって、時々余分に数サブフレームアウェイクすることに関するＵＥ電力消費量は問題ではない。しかしながら、ＮＢ−ＩｏＴのために、良好なＵＥバッテリ寿命を得るために、その使用事例の多くのための接続モード中もまた、ＵＥアクティブ時間（すなわち、ＮＢ−ＰＤＣＣＨをモニタリングしている場合）が、可能な限り小さいことが非常に重要である。

レガシーアプローチの１つの問題は、ｄｒｘ−Ｉｎａｃｔｉｖｉｔｙタイマの値をどのようにして設定するのかである。
・短い値：これは、ＵＥ電力消費に関して良好であるが、ＤＬ ＨＡＲＱ再送信が存在するケースでは、再送信が終了したときにタイマが（恐らく）満了し、その後、新たなデータが、次のＯｎＤｕｒａｔｉｏｎ機会を待つ必要があるので、追加のレイテンシを導くであろう。この追加のレイテンシを導くことに伴う欠点は、ＵＥが、より長い時間の間、接続モードにある必要があることである。それに加えて、接続モードにおいて長時間費やされることは（特に、長いＤＲＸサイクルが使用される場合もまた）、より大きなチャネル変動および同期喪失のリスクに至り得る。
・長い値：これは、ＵＥ電力消費に関して良好ではないが、追加のレイテンシを導かないので、ＵＥがアイドルモードへより迅速に入るためにＵＥをより迅速にスケジュールすることが可能となるであろう。

特定の実施形態に従って、上記の問題に対する解決策は、ｄｒｘ−Ｉｎａｃｔｉｖｉｔｙタイマを変更することであろうから、ＮＢ−ＰＤＣＣＨ受信毎に、すなわち、（アップリンクとダウンリンクとの両方において）新たな送信または再送信であるかに関わらず、再開始されるようになる。余分なレイテンシが導かれないので、その後、短い値のｄｒｘ−Ｉｎａｃｔｉｖｉｔｙタイマが、同時に使用され得る。これが行われると、ＵＬ／ＤＬ再送信と非動作との両方を監督するために、１つのタイマしか使用されないので、ＨＡＲＱ−ＲＴＴ−タイマ／ｄｒｘ−Ｒｅｔｒａｎｓｍｉｓｓｉｏｎタイマの必要はなくなる。これはまた、１つのタイマしか必要とされないので、ＵＥ複雑さを低減させる。この実施形態に従って、ｄｒｘ−Ｉｎａｃｔｉｖｉｔｙタイマは、ＮＢ−ＰＤＣＣＨにおける任意のＤＣＩの受信時に再開始される。

追加の実施形態に従って、タイマであるｄｒｘ−Ｉｎａｃｔｉｖｉｔｙタイマを開始するための基準が変更されたのであれば、ダウンリンクとアップリンクとのいずれのためにも、タイマであるＨＡＲＱ−ＲＴＴ−タイマおよびｄｒｘ−Ｒｅｔｒａｎｓｍｉｓｓｉｏｎタイマは必要とされない。ＵＥにおける成功裏のＮＢ−ＰＤＣＣＨ受信の後、（ＵＬグラントのケースでは）ＳＲＢ／ＤＲＢデータ、または、（ＤＬ割当のケースでは）ＨＡＲＱフィードバックのいずれかを含むアップリンク送信が続くであろう。スケジュールされた後、ＵＥが、送信後まで、ＮＢ−ＰＤＣＣＨをモニタすることが要求されないと仮定されるのであれば、ｄｒｘ−Ｉｎａｃｔｉｖｉｔｙタイマの開始／再開始への追加の変更がなされ得る。タイマは、その後、ＮＢ−ＰＤＣＣＨのすべての成功裏の受信時に停止され、ＮＢ−ＰＤＣＣＨメッセージによってトリガされたアップリンク送信の終了後に開始されるべきである。これによって、特に、ＮＢ−ＰＤＣＣＨ／ＮＢ−ＰＤＳＣＨ／ＮＢ−ＰＵＳＣＨ間の時間ギャップが長いのであれば、ＵＥは、接続モードにおいて、より多くの時間機会中、受信機をオフにする（そして、潜在的にスリープモードに入る）ことが可能になるであろう。

追加の実施形態に従って、ＮＢ−ＰＤＣＣＨにおけるいずれかの成功裏の受信時にｄｒｘ−Ｉｎａｃｔｉｖｉｔｙタイマを停止させ、結果として得られる（ＤＲＢ／ＳＲＢまたはＨＡＲＱフィードバックの）アップリンク送信後に開始することによって、ＵＥは、ＮＢ−ＰＤＣＣＨモニタリング時間、したがって、電力消費量を、低減することが可能となる。したがって、いくつかの実施形態に従って、ｄｒｘ−Ｉｎａｃｔｉｖｉｔｙタイマのための開始および停止基準は、接続モードＤＲＸを制御するために、ＮＢ−ＩｏＴ ＵＥのために変更される。いくつかの実施形態に従って、ｄｒｘ−Ｉｎａｃｔｉｖｉｔｙタイマの開始基準は、ダウンリンク割当およびアップリンクグラントそれぞれのために、ＨＡＲＱ ＡＣＫまたはＤＲＢ／ＳＲＢデータのＮＢ−ＰＵＳＣＨ送信後へ変更されるべきである。いくつかの実施形態に従って、ｄｒｘ−Ｉｎａｃｔｉｖｉｔｙタイマの停止基準は、ダウンリンク割当またはアップリンクグラントが受信されたときに変更されるべきである。いくつかの実施形態に従って、ＨＡＲＱ−ＲＴＴ−タイマおよびｄｒｘ−Ｒｅｔｒａｎｓｍｉｓｓｉｏｎタイマは、ＮＢ−ＩｏＴにおいて使用されないことがあり得る。いくつかの実施形態に従って、ｄｒｘ−Ｉｎａｃｔｉｖｉｔｙタイマが満了すると、ＵＥは、次のＯｎＤｕｒａｔｉｏｎ機会まで、ＮＢ−ＰＤＣＣＨをモニタする必要はない。

ＮＢ−ＩｏＴ使用事例の多くは、同時のアップリンク／ダウンリンクトラフィックを含まず、代わりに、ほとんどの使用事例は、ＩＰパケットが一方向で送信され、他の方向での応答が続く（いくつかの使用事例のために、同じパターンに従って数回、潜在的に反復される）要求−応答タイプのトラフィックパターンに依存する。このトラフィックパターンは、Ｌ３（ＮＡＳ／ＲＲＣ）シグナリング手順についても真である。結果として、ＨＡＲＱフィードバックまたはＳＲＢ／ＤＲＢデータが、ＵＥによって、アップリンクにおいて送信された後、少なくとも１つのＨＡＲＱラウンドトリップタイムの間、いずれのＮＢ−ＰＤＣＣＨ動作も存在しないであろう。この時間の間、ＮＢ−ＩｏＴ ＵＥは、ＮＢ−ＰＤＣＣＨをモニタしないことを許可され得る。したがって、いくつかの実施形態に従って、ｄｒｘ−Ｉｎａｃｔｉｖｉｔｙタイマ取り扱いに対する変更は、アップリンク送信後、オフセット値まで、ｄｒｘ−Ｉｎａｃｔｉｖｉｔｙタイマを開始しないことであろう。

ほとんどの使用事例では、アップリンク送信の終了後、少なくとも１つのラウンドトリップタイムまで、ＵＥは、ＮＢ−ＰＤＣＣＨをモニタする必要はない。したがって、いくつかの実施形態に従って、ｄｒｘ−Ｉｎａｃｔｉｖｉｔｙタイマの開始は、ＵＥが、ＮＢ−ＰＤＣＣＨモニタリング時間を低減できるように、（ＤＲＢ／ＳＲＢまたはＨＡＲＱフィードバックの）アップリンク送信後、オフセット値においてなされるべきである。このオフセットの値は、上述したように、ラウンドトリップタイムに依存するが、ＮＢ−ＰＤＣＣＨの物理レイヤ設計、たとえば、時間アライメント、および、ＮＢ−ＰＤＣＣＨおよびＮＢ−ＰＤＳＣＨがどのようにして多重化されるのかにも依存する。この値は、物理的なレイヤ設計、および、ＵＥのカバレッジクラスに依存して可変でさえあり得る。いくつかの実施形態に従って、ｄｒｘ−Ｉｎａｃｔｉｖｉｔｙタイマの開始基準は、アップリンク送信後、少なくともラウンドトリップタイムへ設定され得るが、さらなる詳細が、ダウンリンクＮＢ−ＰＤＣＣＨ／ＰＤＳＣＨ設計におけるＲＡＮＩから利用可能になるまで、詳細は、ＦＦＳのままとされる。いくつかの実施形態に従って、ＮＢ−ＩｏＴのための半静的接続モードＤＲＸパラメータが、ＲｒｃＣｏｎｎｅｃｔｉｏｎＲｅｅｓｔａｂｌｉｓｈ、ＲｒｃＣｏｎｎｅｃｔｉｏｎＳｅｔｕｐ、ＲｒｃＣｏｎｎｅｃｔｉｏｎＲｅｓｕｍｅの一部として、すなわち、Ｍｓｇ３の一部として、含まれる。いくつかの実施形態に従って、ＵＥにおいて受信された場合、半静的接続モードＤＲＸパラメータが直接適用されるものとする。

修正、追加、または省略が、本開示の範囲から逸脱することなく、本明細書に記載されたシステムおよび装置に対してなされ得る。システムおよび装置の構成要素は、統合または分離され得る。さらに、システムおよび装置のオペレーションは、より多い、より少ない、または他の構成要素によって実行され得る。それに加えて、システムおよび装置のオペレーションは、ソフトウェア、ハードウェア、および／または、他のロジックを含む任意の適切なロジックを使用して実行され得る。この書面において使用されるように、「各々」は、セットの各メンバ、または、セットのサブセットの各メンバを指す。

修正、追加、または省略が、本開示の範囲から逸脱することなく、本明細書に記載された方法に対してなされ得る。方法は、より多い、より少ない、または他のステップを含み得る。それに加えて、ステップは、任意の適切な順序で実行され得る。

この開示は、いくつかの実施形態に関して説明されているが、実施形態の改変および置換が、当業者に明らかになるであろう。したがって、実施形態の上記説明は、この開示を制限しない。以下の特許請求の範囲によって定義されるように、この開示の趣旨および範囲から逸脱することなく、他の変形、代用、および改変が可能である。

前述した説明において使用される省略形は以下を含む。
３ＧＰＰ 第３世代パートナーシッププロジェクト
ＡＣＫ アクノレッジメント
ＡＰ アクセスポイント
ＢＳ 基地局
ＢＳＣ 基地局コントローラ
ＢＴＳ 基地トランシーバ局
ＣＰＥ カスタマ構内設備
Ｄ２Ｄ デバイスツーデバイス
ＤＡＳ 分散アンテナシステム
ＤＣＩ ダウンリンク制御情報
ＤＬ ダウンリンク
ＤＲＢ データ無線ベアラ
ＤＲＸ 間欠受信
ＤＴＸ 間欠送信
ｅＮＢ エボルブドノードＢ
ＥＰＤＣＣＨ エンハンスト物理ダウンリンク制御チャネル
ＦＤＤ 周波数分割複信
ＨＡＲＱ ハイブリッド自動再送要求
ＨＳＰＡ 高速パケットアクセス
ＩｏＴ モノのインターネット
ＬＡＮ ローカルエリアネットワーク
ＬＥＥ ラップトップ埋込機器
ＬＭＥ ラップトップ搭載機器
ＬＴＥ Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ
Ｍ２Ｍ マシンツーマシン
ＭＡＮ 都市内ネットワーク
ＭＣＥ マルチセル／マルチキャスト連携エンティティ
ＭＣＳ 変調レベルおよび符号化方式
ＭＩＭＯ 多入力多出力
ＭＲ 測定制限
ＭＳＲ マルチ規格無線
ＮＡＣＫ 否定的アクノレッジメント
ＮＡＳ 非アクセス階層
ＮＢ 狭帯域
ＮＢ−ＩｏＴ 狭帯域のモノのインターネット
ＮＢ−ＰＤＣＣＨ 狭帯域物理ダウンリンク制御チャネル
ＮＢ−ＰＤＳＣＨ 狭帯域物理ダウンリンク共有チャネル
ＮＢ−ＰＵＳＣＨ 狭帯域物理アップリンク共有チャネル
ＮＰＤＣＣＨ 狭帯域物理ダウンリンク制御チャネル
ＮＰＤＳＣＨ 狭帯域物理ダウンリンク共有チャネル
ＮＰＵＳＣＨ 狭帯域物理アップリンク共有チャネル
ＯＦＤＭ 直交周波数分割多重
ＰＤＣＣＨ 物理ダウンリンク制御チャネル
ＰＤＳＣＨ 物理ダウンリンク共有チャネル
ＰＭＩ プリコード行列インジケータ
ＰＲＢ 物理リソースブロック
ＰＳＴＮ 公衆交換電話網
ＰＨＩＣＨ 物理ハイブリッドＡＲＱインジケータチャネル
ＰＵＳＣＨ 物理アップリンク共有チャネル
ＰＵＣＣＨ 物理アップリンク制御チャネル
ＲＢ リソースブロック
ＲＩ ランクインジケータ
ＲＮＣ 無線ネットワークコントローラ
ＲＲＣ 無線リソース制御
ＲＲＨ リモート無線ヘッド
ＲＲＵ リモートラジオユニット
ＲＴＴ ラウンドトリップタイム
ＳＡＷ ストップアンドウェイト
ＳＲＢ シグナリング無線ベアラ
ＴＤＤ 時分割複信
ＴＦＲＥ 時間周波数リソースエレメント
ＵＣＩ アップリンク制御情報
ＵＥ ユーザ機器
ＵＬ アップリンク
ＷＡＮ 広域ネットワーク

Claims (35)

1. ユーザ機器（ＵＥ）（５１０）における方法であって、
   少なくとも第１のタイマ（６３０、７２５、８２５、９２５）の持続時間中、ダウンリンク制御チャネル（６１０、７１５、８１０、９１５）をモニタすること（１１０４）と、
   前記ＵＥのためのダウンリンクまたはアップリンク送信（６０５、７０５、８０５、９０５）を示すインジケーションを、前記モニタされたダウンリンク制御チャネルにおいて受信すること（１１０８）と、
   前記ＵＥのための前記ダウンリンクまたはアップリンク送信を示す前記インジケーションを受信した後、前記第１のタイマを停止すること（１１１２）であって、前記第１のタイマが停止された後、前記ＵＥは、前記ダウンリンク制御チャネルをモニタする必要はない、停止すること（１１１２）と、
   前記ＵＥのための前記示されたダウンリンクまたはアップリンク送信に関連付けられたアップリンク送信（６３５、７１０、８３０、９１０）を実行すること（１１１６）と、
   前記ＵＥのための前記ダウンリンクまたはアップリンク送信を示す前記インジケーションを受信した後、第２のタイマ（６４５、７３５、８４０、９３５）を開始すること（１１２０）であって、前記第２のタイマの持続時間は、オフセット期間を含む、開始すること（１１２０）と、
   前記第２のタイマが満了した場合、第３のタイマ（６４０、７３０、８３５、９３０）を開始すること（１１２４）であって、前記ＵＥは、前記第３のタイマの持続時間の間、前記ダウンリンク制御チャネルをモニタする、開始すること（１１２４）とを含み、
   前記第１のタイマは、間欠受信（ＤＲＸ）サイクルのｏｎＤｕｒａｔｉｏｎタイマ、ｄｒｘ−Ｉｎａｃｔｉｖｉｔｙタイマ、およびＤＲＸ再送信タイマのうちの１つを含み、前記第３のタイマは、ｄｒｘ−Ｉｎａｃｔｉｖｉｔｙタイマを含む、方法。
2. 前記第３のタイマが満了した場合、間欠受信モードに入ることを含む、請求項１に記載の方法。
3. 前記第１のタイマは、間欠受信サイクルのｏｎＤｕｒａｔｉｏｎタイマである、請求項１に記載の方法。
4. 前記第１のタイマは、間欠受信再送信タイマを含む、請求項１に記載の方法。
5. 前記第２のタイマは、前記オフセット期間を含むハイブリッド自動再送要求（ＨＡＲＱ）−ラウンドトリップタイム（ＲＴＴ）タイマである、請求項１に記載の方法。
6. 前記ＵＥのための前記ダウンリンクまたはアップリンク送信を示す前記インジケーションは、ダウンリンクスケジューリング割当（６０５、８０５）を含み、
   前記示されたダウンリンク送信に関連付けられた前記アップリンク送信は、アクノレッジメントメッセージ（６３５、８３０）を含む、請求項１に記載の方法。
7. 前記ＵＥのための前記ダウンリンクまたはアップリンク送信を示す前記インジケーションは、アップリンクグラント（７０５、９０５）を含み、
   前記示されたアップリンク送信に関連付けられた前記アップリンク送信は、前記アップリンクにおけるデータ送信（７１０、９１０）を含む、請求項１に記載の方法。
8. 前記ＵＥのための前記ダウンリンクまたはアップリンク送信を示す前記インジケーションは、前記第２または第３のタイマのうちの少なくとも１つの持続時間に関する情報を含む、請求項１に記載の方法。
9. 前記第２および第３のタイマのうちの少なくとも１つの持続時間に関する情報を含むメッセージを受信することを含む、請求項１に記載の方法。
10. 前記第２のタイマは、
    前記関連付けられたアップリンク送信を実行した後、または、
    前記ＵＥのための前記ダウンリンクまたはアップリンク送信を示す前記受信されたインジケーションの終了時、のいずれかにおいて開始される、請求項１から９のいずれか一項に記載の方法。
11. ネットワークノード（５１５）における方法であって、
    間欠受信オペレーションを制御するために、ユーザ機器（ＵＥ）（５１０）による使用のための、第１のタイマ（６４５、７３５、８４０、９３５）の持続時間と、第２のタイマ（６４０、７３０、８３５、９３０）の持続時間とを判定すること（１２０４）であって、前記第１のタイマの前記持続時間は、オフセット期間を含む、判定すること（１２０４）と、
    前記第１のタイマの前記持続時間と、前記第２のタイマの前記持続時間とに関する情報を前記ＵＥへ送信すること（１２０８）と、
    前記ＵＥのためのダウンリンクまたはアップリンク送信を示すインジケーションを前記ＵＥへ送信することと、
    前記ＵＥのための前記示されたダウンリンクまたはアップリンク送信に関連付けられたアップリンク送信（６３５、７１０、８３０、９１０）を前記ＵＥから受信することとを含み、
    前記第１のタイマの前記持続時間は、
    前記ＵＥのための前記示されたダウンリンクまたはアップリンク送信に関連付けられた前記アップリンク送信の送信後、前記ＵＥが前記第２のタイマを開始する前に、前記ＵＥが待つ時間の長さ、および、
    前記ＵＥのための前記ダウンリンクまたはアップリンク送信を示す前記インジケーションの終了後、前記ＵＥが前記第２のタイマを開始する前に、前記ＵＥが待つ時間の長さのうちの１つを含み、
    前記第２のタイマは、ｄｒｘ−Ｉｎａｃｔｉｖｉｔｙタイマである、方法。
12. 前記第１のタイマの前記持続時間と、前記第２のタイマの前記持続時間とに関する前記情報は、前記ＵＥのためのダウンリンクまたはアップリンク送信（６０５、７０５、８０５、９０５）を示すインジケーションに含まれる、請求項１１に記載の方法。
13. 前記第１のタイマの前記持続時間と、前記第２のタイマの前記持続時間とに関する情報を前記ＵＥへ送信することは、
    前記第１のタイマの前記持続時間と、前記第２のタイマの前記持続時間とに関する前記情報を含むメッセージを前記ＵＥへ送信することを含む、請求項１１に記載の方法。
14. 前記ＵＥのための前記ダウンリンクまたはアップリンク送信を示す前記インジケーションは、ダウンリンクスケジューリング割当（６０５、８０５）を含み、
    前記示されたダウンリンク送信に関連付けられた前記アップリンク送信は、アクノレッジメントメッセージ（６３５、８３０）を含む、請求項１１に記載の方法。
15. 前記ＵＥのための前記ダウンリンクまたはアップリンク送信を示す前記インジケーションは、アップリンクグラント（７０５、９０５）を含み、
    前記示されたアップリンク送信に関連付けられた前記アップリンク送信は、前記アップリンクにおけるデータ送信（７１０、９１０）を含む、請求項１１に記載の方法。
16. 前記第２のタイマの前記持続時間は、間欠受信モードに入る前に前記ＵＥがダウンリンク制御チャネル（６１０、７１５、８１０、９１５）をモニタする時間の長さを含む、請求項１１に記載の方法。
17. 前記第１のタイマは、ハイブリッド自動再送要求（ＨＡＲＱ）−ラウンドトリップタイム（ＲＴＴ）タイマである、請求項１１に記載の方法。
18. ユーザ機器（ＵＥ）（５１０）であって、
    処理回路（１３２０）を備え、前記処理回路は、
    少なくとも第１のタイマ（６３０、７２５、８２５、９２５）の持続時間中、ダウンリンク制御チャネル（６１０、７１５、８１０、９１５）をモニタすること（１１０４）と、
    前記ＵＥのためのダウンリンクまたはアップリンク送信（６０５、７０５、８０５、９０５）を示すインジケーションを、前記モニタされたダウンリンク制御チャネルにおいて受信すること（１１０８）と、
    前記ＵＥのための前記ダウンリンクまたはアップリンク送信を示す前記インジケーションを受信した後、前記第１のタイマをモニタすることを停止すること（１１１２）であって、前記第１のタイマが停止された後、前記ＵＥは、前記ダウンリンク制御チャネルをモニタする必要はない、停止すること（１１１２）と、
    前記ＵＥのための前記示されたダウンリンクまたはアップリンク送信に関連付けられたアップリンク送信（６３５、７１０、８３０、９１０）を実行すること（１１１６）と、
    前記ＵＥのための前記ダウンリンクまたはアップリンク送信を示す前記インジケーションを受信した後、第２のタイマ（６４５、７３５、８４０、９３５）を開始すること（１１２０）であって、前記第２のタイマの持続時間は、オフセット期間を含む、開始すること（１１２０）と、
    前記第２のタイマが満了した場合、第３のタイマ（６４０、７３０、８３５、９３０）を開始すること（１１２４）であって、前記ＵＥは、前記第３のタイマの持続時間の間、前記ダウンリンク制御チャネルをモニタする、開始すること（１１２４）とを行うように構成され、
    前記第１のタイマは、ＤＲＸサイクルのｏｎＤｕｒａｔｉｏｎタイマ、ｄｒｘ−Ｉｎａｃｔｉｖｉｔｙタイマ、およびＤＲＸ再送信タイマのうちの１つを含み、前記第３のタイマは、ｄｒｘ−Ｉｎａｃｔｉｖｉｔｙタイマを含む、ユーザ機器（ＵＥ）。
19. 前記処理回路は、前記第３のタイマが満了した場合、間欠受信モードに入るように構成された、請求項１８に記載のＵＥ。
20. 前記第１のタイマは、間欠受信サイクルのｏｎＤｕｒａｔｉｏｎタイマである、請求項１８に記載のＵＥ。
21. 前記第１のタイマは、ｄｒｘ−Ｉｎａｃｔｉｖｉｔｙタイマである、請求項１８に記載のＵＥ。
22. 前記第１のタイマは、間欠受信再送信タイマを含む、請求項１８に記載のＵＥ。
23. 前記第２のタイマは、前記オフセット期間を含むハイブリッド自動再送要求（ＨＡＲＱ）−ラウンドトリップタイム（ＲＴＴ）タイマである、請求項１８に記載のＵＥ。
24. 前記ＵＥのための前記ダウンリンクまたはアップリンク送信を示す前記インジケーションは、ダウンリンクスケジューリング割当（６０５、８０５）を含み、
    前記示されたダウンリンク送信に関連付けられた前記アップリンク送信は、アクノレッジメントメッセージ（６３５、８３０）を含む、請求項１８に記載のＵＥ。
25. 前記ＵＥのための前記ダウンリンクまたはアップリンク送信を示す前記インジケーションは、アップリンクグラント（７０５、９０５）を含み、
    前記示されたアップリンク送信に関連付けられた前記アップリンク送信は、前記アップリンクにおけるデータ送信（７１０、９１０）を含む、請求項１８に記載のＵＥ。
26. 前記ＵＥのための前記ダウンリンクまたはアップリンク送信を示す前記インジケーションは、前記第２または第３のタイマのうちの少なくとも１つの持続時間に関する情報を含む、請求項１８に記載のＵＥ。
27. 前記処理回路は、前記第２および第３のタイマのうちの少なくとも１つの持続時間に関する情報を含むメッセージを受信するように構成された、請求項１８に記載のＵＥ。
28. 前記処理回路は、
    前記関連付けられたアップリンク送信を実行した後、または、
    前記ＵＥのための前記ダウンリンクまたはアップリンク送信を示す前記受信されたインジケーションの終了時、のいずれかにおいて前記第２のタイマを開始するように構成された、請求項１８から２７のいずれか一項に記載のＵＥ。
29. ネットワークノード（５１５）であって、
    処理回路（１４２０）を備え、前記処理回路は、
    間欠受信オペレーションを制御するために、ユーザ機器（ＵＥ）（５１０）による使用のための、第１のタイマ（６４５、７３５、８４０、９３５）の持続時間と、第２のタイマ（６４０、７３０、８３５、９３０）の持続時間とを判定すること（１２０４）であって、前記第１のタイマの前記持続時間は、オフセット期間を含む、判定すること（１２０４）と、
    前記第１のタイマの前記持続時間と、前記第２のタイマの前記持続時間とに関する情報を前記ＵＥへ送信すること（１２０８）と、
    前記ＵＥのためのダウンリンクまたはアップリンク送信を示すインジケーションを前記ＵＥへ送信することと、
    前記ＵＥのための前記示されたダウンリンクまたはアップリンク送信に関連付けられたアップリンク送信（６３５、７１０、８３０、９１０）を前記ＵＥから受信することとを行うように構成され、
    前記第１のタイマの前記持続時間は、
    前記ＵＥのための前記示されたダウンリンクまたはアップリンク送信に関連付けられた前記アップリンク送信の送信後、前記ＵＥが前記第２のタイマを開始する前に、前記ＵＥが待つ時間の長さ、および、
    前記ＵＥのための前記ダウンリンクまたはアップリンク送信を示す前記インジケーションの終了後、前記ＵＥが前記第２のタイマを開始する前に、前記ＵＥが待つ時間の長さのうちの１つを含み、
    前記第２のタイマは、ｄｒｘ−Ｉｎａｃｔｉｖｉｔｙタイマである、ネットワークノード。
30. 前記第１のタイマの前記持続時間と、前記第２のタイマの前記持続時間とに関する前記情報は、前記ＵＥのためのダウンリンクまたはアップリンク送信（６０５、７０５、８０５、９０５）を示すインジケーションに含まれる、請求項２９に記載のネットワークノード。
31. 前記処理回路は、前記第１のタイマの前記持続時間と、前記第２のタイマの前記持続時間とに関する前記情報を含むメッセージを前記ＵＥへ送信することによって、前記第１のタイマの前記持続時間と、前記第２のタイマの前記持続時間とに関する情報を前記ＵＥへ送信するように構成された、請求項２９に記載のネットワークノード。
32. 前記ＵＥのための前記ダウンリンクまたはアップリンク送信を示す前記インジケーションは、ダウンリンクスケジューリング割当（６０５、８０５）を含み、
    前記示されたダウンリンク送信に関連付けられた前記アップリンク送信は、アクノレッジメントメッセージ（６３５、８３０）を含む、請求項２９に記載のネットワークノード。
33. 前記ＵＥのための前記ダウンリンクまたはアップリンク送信を示す前記インジケーションは、アップリンクグラント（７０５、９０５）を含み、
    前記示されたアップリンク送信に関連付けられた前記アップリンク送信は、前記アップリンクにおけるデータ送信（７１０、９１０）を含む、請求項２９に記載のネットワークノード。
34. 前記第２のタイマの前記持続時間は、間欠受信モードに入る前に前記ＵＥがダウンリンク制御チャネル（６１０、７１５、８１０、９１５）をモニタする時間の長さを含む、請求項２９に記載のネットワークノード。
35. 前記第１のタイマは、ハイブリッド自動再送要求（ＨＡＲＱ）−ラウンドトリップタイム（ＲＴＴ）タイマである、請求項２９に記載のネットワークノード。

Images