JP6659861B2 - Ｎｂ−ｉｏｔにおける単一ｈａｒｑプロセス動作のｄｒｘメカニズムのための装置および方法 - Google Patents

Description

［関連出願への相互参照］
この出願は、２０１６年２月１２日に出願された米国仮特許出願第６２／２９４６２０号に関連し、その利益および優先権を主張し、その全体が、参照により、ここに組み込まれる。

このセクションは、特許請求の範囲に記載されている本願発明の背景またはコンテキストを提供することを意図している。本明細書の説明は、追求することができた概念を含むことができるが、しかし、必ずしもこれまでに考え出され、実装され、記述されてきた概念ではない。したがって、本明細書で別段の指示がない限り、このセクションに記載されていることは、本出願の説明および特許請求の範囲の先行技術ではない。

第３世代パートナーシップ・プロジェクト（３ＧＰＰ）ＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）およびその次世代ＬＴＥ（ＬＴＥ−Ａ）は、低コストで、より高いデータ転送速度と低レイテンシとの手段により既存の移動体通信システムの大幅に強化したサービスを提供する。ＬＴＥ−Ａは、現在のＬＴＥリリースとの下位互換性を維持しながら、進化した国際移動通信のための国際電気通信連合無線通信部門の要件を満たす、より最適化された無線システムとなるであろう。

マシンツーマシン（Ｍ２Ｍ）通信は、３ＧＰＰエコシステムの重要な成長機会を表す。いわゆるＩｏＴ（Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ）をサポートするために、３ＧＰＰ事業者は、電力効率が良く（数年のバッテリ寿命を有する）、屋内および地下室など、挑戦的なカバレッジ条件で到達でき、そして、より重要なことに、それらは大規模に配備され、使い捨て可能でさえあるほどに十分に安価であるデバイスでの使用シナリオに対処しなければならない。３ＧＰＰにおいて研究項目が、最近、承認された。その目的は、現在のシステムを発展させる可能性と、低複雑性および低スループットの無線アクセス技術に対する新しいアクセス・システムの設計との両方を、セルラＩｏＴ（ｃｅｌｌｕｌａｒ ｉｎｔｅｒｎｅｔ ｏｆ ｔｈｉｎｇｓ）の要件に取り組むために、研究することであった。この研究の目的は、屋内カバレッジの改善、大量の低スループット・デバイスのサポート、低遅延感度、超低デバイス・コスト、低デバイス消費電力、および（最適化）ネットワーク・アーキテクチャであった。狭帯域（ＮＢ）ＩｏＴの展開は、特定のキャリア上のスタンドアローンと並んで、インバンドＬＴＥ、ＬＴＥへのガードバンド、ＵＭＴＳまたは他のシステムであることができる。

第１の実施形態によれば、本願方法は、ユーザ機器が、狭帯域ＩｏＴ（ＮＢ−ＩｏＴ）ユーザ機器であるかどうかを判定するステップと、ハイブリッド自動再送要求ラウンド・トリップ・タイム（ＨＡＲＱ ＲＴＴ）タイマが満了するかどうかを判定するステップと、前記ユーザ機器がＮＢ−ＩｏＴユーザ機器であり、前記ＨＡＲＱ ＲＴＴタイマが満了する場合、不連続受信（ＤＲＸ）インアクティビティ・タイマ（ｉｎａｃｔｉｖｉｔｙ ｔｉｍｅｒ）を開始または再開するステップと、を含むことができる。

第２の実施形態によれば、本願装置は、少なくとも１つのプロセッサと、少なくとも１つのメモリと、コンピュータ・プログラム・コードとを含むことができる。少なくとも１つのメモリおよびコンピュータ・プログラム・コードは、前記少なくとも１つのプロセッサで、前記装置に、少なくとも、ユーザ機器が、狭帯域ＩｏＴ（ＮＢ−ＩｏＴ）ユーザ機器であるかどうかを判断させ、ハイブリッド自動再送要求ラウンド・トリップ・タイム（ＨＡＲＱ ＲＴＴ）タイマが満了するかどうかを判断させ、前記ユーザ機器がＮＢ−ＩｏＴユーザ機器であり、前記ＨＡＲＱ ＲＴＴタイマが満了する場合、不連続受信（ＤＲＸ）インアクティビティ・タイマ（ｉｎａｃｔｉｖｉｔｙ ｔｉｍｅｒ）を開始または再開させるように構成され得る。

第３の実施形態によれば、本願装置は、第１の実施形態による方法を実行するための手段を含むことができる。

第４の実施形態によれば、コンピュータ・プログラム・プロダクトは、第１の実施形態による方法を含むプロセスを実行するためのコンピュータ・プログラム・コードを有するコンピュータ可読メディアを備えることができる。

第５の実施形態によれば、非一時的コンピュータ可読メディアは、ハードウェアで実行されると、第１の実施形態による方法を含むプロセスを実行する命令を格納することができる。

本発明の例示的な実施形態のより完全な理解のために、添付図面に関連して以下の説明を参照する。
図１は、本出願の例示的な実施形態によるフローチャートを示す。 図２は、本出願の別の例示的な実施形態によるフローチャートを示す。 図３は、本出願の様々な例示的実施形態を実施する際に使用するのに適した例示的装置の簡略ブロック図を示す。

既存のＬＴＥメカニズムと比較して、ＮＢ−ＩｏＴのためのアップリンク（ＵＬ）ハイブリッド自動再送要求（ＨＡＲＱ）は、既存のＬＴＥシステムのように同期的ではなく、アップリンクでは非同期となり、ＨＡＲＱフィードバック用の物理ＨＡＲＱインジケータチャネル（ＰＨＩＣＨ）がない場合のみ、物理ダウンリンク制御チャネル（ＰＤＣＣＨ）を介してスケジューリングされる（これにより、非適応再送信を除く）。さらに、ＵＬ用の１つのＨＡＲＱプロセスと、ダウンリンク（ＤＬ）用の１つのＨＡＲＱプロセスのみが非常に低いデータレートでコスト削減を達成するために、使用される可能性がある。

ＬＴＥでは、リリース８（Ｒｅｌ−８）以降、各方向（アップリンクおよびダウンリンク）に、８つのＨＡＲＱプロセスが存在する。複数のＨＡＲＱプロセスを有することの利点は、ＨＡＲＱ往復時間（ＲＴＴ）および再送信の発生の可能性にもかかわらず連続送信が可能になることである。その欠点は、バッファリング要求およびコストが増加することである。ＬＴＥのための現在の不連続受信（ＤＲＸ）動作は、３ＧＰＰ ＴＳ３６．３２１ｖ１３．０．０に規定されており、その全体が参照により本明細書に組み込まれ、新たな送信のためのＰＤＣＣＨが受信されたときにインアクティビティ・タイマが再開される。ＤＬの場合、ＨＡＲＱ ＲＴＴタイマが満了し、トランスポートブロック（ＴＢ）が正常にデコードされなかった場合、ｄｒｘ−ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒが開始される。同期化されたＨＡＲＱおよび非適応的な再送信を伴うＵＬの場合、ユーザ機器（ＵＥ）は、再送信のための許可を予期するときにウェイクアップする。既存のＤＲＸメカニズムは、連続送信と８つのＨＡＲＱプロセスとにはうまく対応するが、１つのＨＡＲＱプロセスのみが使用されている場合、省電力を最大化することができない。

例示的な実施形態では、ＤＲＸ機会を最大にするために、１つのＨＡＲＱプロセスのみが使用される場合、ＤＬに対して、ＵＥが他の選択肢を持たないが、次の送信機会（新規または再送信）にＨＡＲＱ ＲＴＴを待つために、−新規の送信に対してＰＤＣＣＨの受信時にインアクティビティ・タイマを再開してはならない（ＴＢを受信したときにＨＡＲＱ ＲＴＴタイマが開始される）。
− ＨＡＲＱ ＲＴＴの満了時に、ＴＢが復号されない場合に潜在的な再送信のＰＤＣＣＨ監視のために再送信タイマが開始され、ＴＢが首尾良く復号された場合、インアクティビティ・タイマが開始される。
− 代替的に、新規の送信および再送信の監視に同じ長さを使用できる場合、インアクティビティ・タイマおよび再送信タイマを１つのタイマに組み合わせることができる。

例示的な実施形態では、１つのＨＡＲＱプロセスのみが使用されるときに、ＤＲＸ機会を最大化するために、ＵＬに対して、ＨＡＲＱ ＲＴＴタイマは、ＰＤＣＣＨ許可の受信時に開始される。
− ＵＥは、ＨＡＲＱ ＲＴＴＩタイマが満了すると一定期間ウェイクアップする。インアクティブ・タイマまたは再送信タイマのいずれかを使用することができるが、ＵＥがＨＡＲＱフィードバックのためにＰＨＩＣＨなしで開始するタイマを知ることができないため、ＵＬに対して２つの異なるタイマを有する必要はない。ＵＥは、新規の送信または再送信のために次のＰＤＣＣＨ許可が受信されるまで、ＴＢが進化型ノードＢ（ｅＮＢ：ｅｖｏｌｖｅｄ ＮｏｄｅＢ）によって首尾よく受信されたかどうかだけを知る。

例示的な実施形態では、ＤＲＸサイクルが構成され、１つのＨＡＲＱプロセスのみが使用される場合、アクティブ時間は、
− ｏｎＤｕｒａｔｉｏｎＴｉｍｅｒまたはｄｒｘ−ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒまたはｄｒｘ−ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒまたはｍａｃ−ＣｏｎｔｅｎｔｉｏｎＲｅｓｏｌｕｔｉｏｎＴｉｍｅｒが実行中である、または、
− スケジューリング要求が物理アップリンク制御チャネル（ＰＵＣＣＨ）で送信され、保留中である、または、
− ＭＡＣエンティティのＣ−ＲＮＴＩに宛てた新規の送信を示すＰＤＣＣＨが、ＭＡＣエンティティによって選択されなかったプリアンブルに対するランダムアクセス応答を成功裏に受信した後に、受信されていない、
間の時間を含む。

しかし、アクティブ時間には、保留中のＨＡＲＱ再送信のためのアップリンク・グラントが発生することができ、対応するＨＡＲＱバッファにデータが存在する間の時間は含まれない。

例示的な実施形態では、ＤＲＸが構成され、１つのＨＡＲＱプロセスのみが使用される場合、ＭＡＣエンティティは、各サブフレームに対して、
− ＤＬ ＨＡＲＱプロセスのためのＨＡＲＱ ＲＴＴタイマがこのサブフレームで満了する場合、
− 対応するＨＡＲＱプロセスのデータが正常にデコードされなかった場合、
− 対応するＨＡＲＱプロセスのｄｒｘ−ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒを開始する。
− そうでなければ、
− ｄｒｘ−ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒを（再）起動する。
− このサブフレームでＵＬ ＨＡＲＱプロセスのためのＨＡＲＱ ＲＴＴタイマが満了する場合、
− 対応するＨＡＲＱプロセスのｄｒｘ−ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒを開始する。
− アクティブ時間の間に、ＰＤＣＣＨサブフレーム以外のサブフレームについて、アグリゲートされたセルにおいて同時受信および送信ができないＵＥについて、サブフレームが、ＳｐＣｅｌｌの有効なｅＩＭＴＡ Ｌ１シグナリングによって示されるダウンリンクサブフレームである場合、および、サブフレームが設定された測定ギャップに含まれていない場合、
− ＰＤＣＣＨを監視する。
− ＰＤＣＣＨがＤＬ／ＵＬ送信を示す場合、または、ＤＬサブスクリプション／ＵＬ許可がこのサブフレームに設定されている場合、
− 対応するＨＡＲＱプロセスのためにＨＡＲＱ ＲＴＴタイマを開始する。
− 対応するＨＡＲＱプロセスのｄｒｘ−ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒを停止する。
− しかし、ＰＤＣＣＨが新規の送信（ＤＬ、ＵＬ、またはサイドリンク（ＳＬ））を示している場合は、ｄｒｘ−ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒを開始または再起動しない。

図１は、本出願の例示的な実施形態によるフローチャートを示す。図１の例では、ＤＲＸが構成され、１つのＨＡＲＱプロセスのみが使用される場合、各サブフレームについて、ＵＥのＭＡＣエンティティは、ステップ１０１において、ＤＬ ＨＡＲＱプロセスのためのＨＡＲＱ ＲＴＴタイマが満了するかどうかを判定する。ＨＡＲＱ ＲＴＴタイマが満了しない場合、ＭＡＣエンティティは、ステップ１０５において、ＵＬ ＨＡＲＱプロセス用のＨＡＲＱ ＲＴＴタイマが満了するかどうかを判断する。ＤＬ ＨＡＲＱプロセスのためのＨＡＲＱ ＲＴＴタイマが、１０１で満了する場合、ＭＡＣエンティティは、ステップ１０２において、対応するＨＡＲＱプロセスのデータが首尾よく復号されたか否かをチェックする。データが首尾よくデコードされなかった場合、ＭＡＣエンティティは、対応するＤＬ ＨＡＲＱプロセスのために１０３でｄｒｘ−ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒを開始する。データが首尾よくデコードされた場合、ＭＡＣエンティティは、ステップ１０４でｄｒｘ−ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒを（再）開始する。いずれにしても、ＭＡＣエンティティは、ステップ１０５において、ＵＬ ＨＡＲＱプロセスのためのＨＡＲＱ ＲＴＴタイマが満了する？かどうかを判定する。ＵＬ ＨＡＲＱプロセスのためのＨＡＲＱ ＲＴＴタイマがステップ１０５で満了すると、ＭＡＣエンティティは、対応するＵＬ ＨＡＲＱプロセスのために１０６でｄｒｘ−ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒを開始する。

一例として、再送信タイマは、ＨＡＲＱ ＲＴＴタイマ満了後のＵＬのために使用されることに留意されたい。これは、インアクティビティ・タイマであってもよい。

例示的な実施形態では、上記の挙動は、ブロードキャストシグナリング、または、例えば無線リソース制御（ＲＲＣ）メッセージなどの専用シグナリングを介してｅＮＢによって構成されることができる。別の例示的な実施形態では、ＮＢ−ＩｏＴカテゴリに属するＵＥに対して暗黙的にアクティブ化されてもよい。例示的な実施形態を図２のフローチャートに示す。図２において、ＵＥは、ステップ２０１および２０２において、ＨＡＲＱプロセスおよび／またはＤＲＸ構成情報を搬送するシグナリングメッセージを受信し、ＵＥは、受信された情報に基づいてＨＡＲＱプロセスおよび／またはＤＲＸ動作を構成する。

本出願の様々な例示的実施形態を実施する際に使用するのに適した例示的装置の簡略ブロック図を示すために図３を参照する。図３では、ユーザ機器、ＵＥ３０１は、簡略化のために図示されていない他のネットワークエンティティとの通信に適合している。ＵＥ３０１は、少なくとも１つのプロセッサ３０５、少なくとも１つのプロセッサ３０５に結合された少なくとも１つのメモリ（ＭＥＭ）３０４、および、少なくとも１つのプロセッサ３０５に結合された（送信機（ＴＸ）および受信機（ＲＸ）を有する）適切なトランシーバを含む。少なくとも１つのＭＥＭ３０４は、プログラム（ＰＲＯＧ）３０２を格納する。ＴＲＡＮＳ３０３は、他のネットワークエンティティとの双方向無線通信用である。

図３に示すように、ＵＥ３０１は、ＨＡＲＱ／ＤＲＸ構成ユニット３０６をさらに含むことができる。ユニット３０６は、少なくとも１つのプロセッサ３０５およびＰＲＯＧ３０２とともに、本願明細書で記載されるように、本願の様々な例示的実施形態と共にＵＥ３０１によって利用されてもよい。

ＰＲＯＧ３０２は、関連するプロセッサによって実行されると、本願明細書で説明するように、本願開示の例示的な実施形態に従って電子装置を動作させるプログラム命令を含むものと仮定する。

一般に、装置３０１の様々な例示的実施形態は、携帯電話、無線通信能力を有するパーソナルデジタルアシスタント（ＰＤＡ）、無線通信能力を有するポータブルコンピュータ、無線通信能力を有するデジタルカメラなどの画像キャプチャ装置、ワイヤレス通信能力を有するゲーム装置、無線通信能力を有する音楽記憶装置および再生装置、ワイヤレスインターネットアクセスおよびブラウジングを可能にするインターネット装置、ならびに、携帯型装置、機械型ＵＥ、または、そのような機能の組合せを組み込む他の端末を含むことができるが、それらに限られるものではない。

本願開示の例示的な実施形態は、プロセッサ３０５によって、または、ハードウェアによって、または、ソフトウェアとハードウェアの組み合わせによって実行可能なコンピュータソフトウェアまたはコンピュータ・プログラム・コードによって実施することができる。

ＭＥＭ３０４は、ローカル技術環境に適した任意のタイプのものであることができ、半導体ベースのメモリデバイス、フラッシュメモリ、磁気メモリデバイスおよびシステム、光メモリデバイスおよびシステム、固定メモリおよびリムーバブルメモリなどの任意の適切なデータ格納技術を使用して実施することができる。ただし、これらは、非限定的な例である。プロセッサ３０５は、ローカル技術環境に適した任意のタイプのものでよく、汎用コンピュータ、専用コンピュータ、マイクロプロセッサ、デジタル信号プロセッサ（ＤＳＰ）およびマルチコアプロセッサアーキテクチャに基づくプロセッサのうちの１つまたは複数を含むことができる。ただし、これらは、非限定的な例である。

以下に示す特許請求の範囲のスコープ、解釈または適用を何ら限定するものではないが、本明細書に開示される１つまたは複数の例示的実施形態の技術的効果は、低データレートでの電力節約を最適化することができる。これは、特に、ただ１つのＨＡＲＱプロセスが使用される場合に有益である。

本発明の実施形態は、ソフトウェア、ハードウェア、アプリケーションロジック、または、ソフトウェア、ハードウェア、およびアプリケーションロジックの組み合わせで実装することができる。ソフトウェア、アプリケーションロジックおよび／またはハードウェアは、ユーザ機器、ｅＮＢまたは他の移動通信デバイスなどの装置上に存在してもよい。必要に応じて、ソフトウェア、アプリケーションロジックおよび／またはハードウェアの一部がネットワーク要素上に存在することができ、ソフトウェアの一部、アプリケーションロジックおよび／またはハードウェアがＵＥ３０１上に存在することができ、ソフトウェア、アプリケーションロジックおよび／ハードウェアは、他のチップセットまたは集積回路上に存在することができる。例示的な実施形態では、アプリケーションロジック、ソフトウェア、または命令セットは、様々な従来のコンピュータ可読媒体のいずれか１つで維持される。本願明細書の文脈において、「コンピュータ可読媒体」は、命令実行システム、装置、またはデバイスによって使用される命令を含む、格納する、通信する、伝搬する、または、伝送する任意の媒体または手段であり得る。コンピュータ可読媒体は、命令実行システム、装置、または、デバイスによって、または、結合して使用される命令を含むことができ、または、格納することができる任意の媒体または手段とすることができる非一時的なコンピュータ可読記憶媒体を含むことができる。

本願明細書では、上記は本発明の例示的な実施形態を説明しているが、これらの説明は限定的な意味で見るべきではないことにも留意されたい。むしろ、本発明の範囲から逸脱することなくなされ得るいくつかの変形および修正が存在する。

さらに、記載されたパラメータに使用されるタイマの名前などの様々な名前は、これらのパラメータが任意の適切な名前によって識別され得るため、いかなる点でも限定することを意図するものではない。

必要に応じて、本明細書で論じられる異なる機能は、異なる順序で、および／または、互いに同時に実行されることができる。さらに、所望であれば、上記の機能の１つ以上は、任意であってもよく、または組み合わせてもよい。したがって、前述の説明は、本発明の原理、教示および例示的実施形態の単なる例示であり、本発明を限定するものではないと考えられるべきである。

Claims (16)

1. ユーザ機器が、狭帯域ＩｏＴ（ＮＢ−ＩｏＴ）ユーザ機器であるかどうかを判定するステップと、
   ハイブリッド自動再送要求ラウンド・トリップ・タイム（ＨＡＲＱ ＲＴＴ）タイマが満了するかどうかを判定するステップと、
   前記ユーザ機器がＮＢ−ＩｏＴユーザ機器であり、ＨＡＲＱ ＲＴＴタイマが満了する場合、不連続受信（ＤＲＸ）インアクティビティ・タイマ（ｉｎａｃｔｉｖｉｔｙ ｔｉｍｅｒ）を開始または再開するステップと、を含む方法であって、
   前記ユーザ機器において、
   制御チャネル・メッセージを受信するステップと、
   前記制御チャネル・メッセージが新しい送信を示すかどうかを判定するステップと、
   前記ユーザ機器がＮＢ−ＩｏＴユーザ機器であり、前記制御チャネル・メッセージが新たな送信を示す場合、前記ＤＲＸインアクティビティ・タイマを開始または再開することを禁止するステップと
   を更に含む、方法。
2. アップリンクＨＡＲＱ ＲＴＴタイマが満了するか否かを判定するステップと、
   前記ユーザ機器がＮＢ−ＩｏＴユーザ機器であり、前記アップリンクＨＡＲＱ ＲＴＴタイマが満了する場合、前記不連続受信（ＤＲＸ）インアクティビティ・タイマ（ｉｎａｃｔｉｖｉｔｙ ｔｉｍｅｒ）を開始または再開するステップと
   を更に含む、請求項１に記載の方法。
3. 前記ユーザ機器において、
   ＨＡＲＱプロセスおよびＤＲＸ構成のうちの少なくとも１つの情報を含むブロードキャストまたは専用シグナリングを受信するステップと、
   前記受信したシグナリング情報に基づいて前記ＤＲＸインアクティビティ・タイマを構成するステップと
   を更に含む、請求項１または２に記載の方法。
4. ユーザ機器が、狭帯域ＩｏＴ（ＮＢ−ＩｏＴ）ユーザ機器であるかどうかを判定するステップと、
   ハイブリッド自動再送要求ラウンド・トリップ・タイム（ＨＡＲＱ ＲＴＴ）タイマが満了するかどうかを判定するステップと、
   前記ユーザ機器がＮＢ−ＩｏＴユーザ機器であり、ＨＡＲＱ ＲＴＴタイマが満了する場合、不連続受信（ＤＲＸ）インアクティビティ・タイマ（ｉｎａｃｔｉｖｉｔｙ ｔｉｍｅｒ）を開始または再開するステップと、を含む方法であって、
   ネットワーク要素において、
   制御チャネル・メッセージを生成するステップと、
   前記制御チャネル・メッセージを前記ユーザ機器に送信するステップと、
   前記ユーザ機器がＮＢ−ＩｏＴユーザ機器であり、前記制御チャネル・メッセージが新たな送信を示す場合、前記ＤＲＸインアクティビティ・タイマを開始または再開することを禁止するステップと
   を更に含む、方法。
5. アップリンクＨＡＲＱ ＲＴＴタイマが満了するか否かを判定するステップと、
   前記ユーザ機器がＮＢ−ＩｏＴユーザ機器であり、前記アップリンクＨＡＲＱ ＲＴＴタイマが満了する場合、前記不連続受信（ＤＲＸ）インアクティビティ・タイマ（ｉｎａｃｔｉｖｉｔｙ ｔｉｍｅｒ）を開始または再開するステップと
   を更に含む、請求項４に記載の方法。
6. ネットワーク要素において、
   前記ＤＲＸインアクティビティ・タイマを構成するステップと、
   前記ユーザ機器に、前記不連続受信（ＤＲＸ）インアクティビティ・タイマ（ｉｎａｃｔｉｖｉｔｙ ｔｉｍｅｒ）の構成情報を含む、ＨＡＲＱプロセスおよびＤＲＸ構成うちの少なくとも１つの情報を示すブロードキャストまたは専用シグナリングを送信するステップと
   を更に含む、請求項４または５に記載の方法。
7. 前記ユーザ機器と前記ネットワーク要素との間のデータ通信に１つだけのＨＡＲＱプロセスを使用するステップを更に含む、請求項４ないし６のいずれか１項に記載の方法。
8. ユーザ機器が、狭帯域ＩｏＴ（ＮＢ−ＩｏＴ）ユーザ機器であるかどうかを判定する手段と、
   ハイブリッド自動再送要求ラウンド・トリップ・タイム（ＨＡＲＱ ＲＴＴ）タイマが満了するかどうかを判定する手段と、
   前記ユーザ機器がＮＢ−ＩｏＴユーザ機器であり、ＨＡＲＱ ＲＴＴタイマが満了する場合、不連続受信（ＤＲＸ）インアクティビティ・タイマ（ｉｎａｃｔｉｖｉｔｙ ｔｉｍｅｒ）を開始または再開するための手段と
   を備える装置であって、
   前記装置が前記ユーザ機器であるとき、
   制御チャネル・メッセージを受信するための手段と、
   前記制御チャネル・メッセージが新しい送信を示すかどうかを判定する手段と、
   前記ユーザ機器がＮＢ−ＩｏＴユーザ機器であり、前記制御チャネル・メッセージが新たな送信を示す場合、前記ＤＲＸインアクティビティ・タイマを開始または再開することを禁止するための手段と
   を備える、装置。
9. アップリンクＨＡＲＱ ＲＴＴタイマが満了するかどうかを判定する手段と、
   前記ユーザ機器がＮＢ−ＩｏＴユーザ機器であり、前記アップリンクＨＡＲＱ ＲＴＴタイマが満了する場合、前記不連続受信（ＤＲＸ）インアクティビティ・タイマ（ｉｎａｃｔｉｖｉｔｙ ｔｉｍｅｒ）を開始または再開するための手段と
   を備える、請求項８に記載の装置。
10. 前記装置が前記ユーザ機器であるとき、
    ＨＡＲＱプロセスおよびＤＲＸ構成のうちの少なくとも１つの情報を含むブロードキャストまたは専用シグナリングを受信する手段と、
    前記受信されたシグナリング情報に基づいて、前記ＤＲＸインアクティビティ・タイマを構成する手段と
    を備える、請求項８または９に記載の装置。
11. ユーザ機器が、狭帯域ＩｏＴ（ＮＢ−ＩｏＴ）ユーザ機器であるかどうかを判定する手段と、
    ハイブリッド自動再送要求ラウンド・トリップ・タイム（ＨＡＲＱ ＲＴＴ）タイマが満了するかどうかを判定する手段と、
    前記ユーザ機器がＮＢ−ＩｏＴユーザ機器であり、ＨＡＲＱ ＲＴＴタイマが満了する場合、不連続受信（ＤＲＸ）インアクティビティ・タイマ（ｉｎａｃｔｉｖｉｔｙ ｔｉｍｅｒ）を開始または再開するための手段と
    を備える装置であって、
    前記装置がネットワーク要素であるとき、
    制御チャネル・メッセージを生成する手段と、
    前記制御チャネル・メッセージを前記ユーザ機器に送信する手段と、
    前記ユーザ機器がＮＢ−ＩｏＴユーザ機器であり、前記制御チャネル・メッセージが新たな送信を示す場合、前記ＤＲＸインアクティビティ・タイマを開始または再開することを禁止する手段と
    を備える、装置。
12. アップリンクＨＡＲＱ ＲＴＴタイマが満了するかどうかを判定する手段と、
    前記ユーザ機器がＮＢ−ＩｏＴユーザ機器であり、前記アップリンクＨＡＲＱ ＲＴＴタイマが満了する場合、前記不連続受信（ＤＲＸ）インアクティビティ・タイマ（ｉｎａｃｔｉｖｉｔｙ ｔｉｍｅｒ）を開始または再開するための手段と
    を備える、請求項１１に記載の装置。
13. 前記装置がネットワーク要素であるとき、
    前記ＤＲＸインアクティビティ・タイマを構成する手段と、
    前記ユーザ機器に、前記不連続受信（ＤＲＸ）インアクティビティ・タイマ（ｉｎａｃｔｉｖｉｔｙ ｔｉｍｅｒ）の＜の＞構成情報を含む、ＨＡＲＱプロセスおよびＤＲＸ構成のうちの少なくとも１つの情報を含むブロードキャストまたは専用シグナリングを送信する手段と
    を備える、請求項１１または１２に記載の装置。
14. 前記ユーザ機器と前記ネットワーク要素との間のデータ通信に１つだけのＨＡＲＱプロセスを使用する手段を備える、請求項１１ないし１３のいずれか１項に記載の装置。
15. 請求項１ないし３のいずれか１項に記載の方法を含むプロセスを実行するためのコンピュータ・プログラム・コードを備えるコンピュータ・プログラム。
16. 請求項４ないし７のいずれか１項に記載の方法を含むプロセスを実行するためのコンピュータ・プログラム・コードを備えるコンピュータ・プログラム。

Images