▶ パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカの特許一覧
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2022-10-12
(54)【発明の名称】送受信装置およびスケジューリング装置
(51)【国際特許分類】
H04W 52/02 20090101AFI20221004BHJP
H04W 28/04 20090101ALI20221004BHJP
H04W 72/04 20090101ALI20221004BHJP
H04L 1/16 20060101ALI20221004BHJP
【ＦＩ】
H04W52/02 111
H04W28/04 110
H04W72/04 131
H04L1/16
【審査請求】未請求
【予備審査請求】未請求
(21)【出願番号】P 2022506653
(86)(22)【出願日】2020-06-10
(85)【翻訳文提出日】2022-02-01
(86)【国際出願番号】 EP2020066044
(87)【国際公開番号】W WO2021023416
(87)【国際公開日】2021-02-11
(31)【優先権主張番号】19189862.6
(32)【優先日】2019-08-02
(33)【優先権主張国・地域又は機関】EP
(81)【指定国・地域】
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．３ＧＰＰ
(71)【出願人】
【識別番号】514136668
【氏名又は名称】パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ
【氏名又は名称原語表記】Ｐａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ
(74)【代理人】
【識別番号】110002952
【氏名又は名称】弁理士法人鷲田国際特許事務所
(72)【発明者】
【氏名】シャー リキン
(72)【発明者】
【氏名】バムリ アンキット
(72)【発明者】
【氏名】鈴木 秀俊
(72)【発明者】
【氏名】タオ ミン－フン
(72)【発明者】
【氏名】西尾 昭彦
【テーマコード（参考）】
5K014
5K067
【Ｆターム（参考）】
5K014FA03
5K067AA43
5K067CC21
5K067DD11
5K067EE02
5K067EE10
5K067FF05
5K067HH28
(57)【要約】
本開示は、送受信装置およびスケジューリング装置と、送受信装置およびスケジューリング装置のための通信方法を提供する。送受信装置は、動作中に、物理ダウンリンク制御チャネルであるＰＤＣＣＨを介して、データのスケジュールされた送信を示す制御情報を受信する送受信機と、動作中に、データのブラインド再送信の回数に応じてモニタリング期間を設定する回路と、を備え、送受信機は、動作中に、モニタリング期間中にＰＤＣＣＨをモニターする。
【特許請求の範囲】
【請求項1】
動作中に、物理ダウンリンク制御チャネルであるＰＤＣＣＨを介して、データのスケジュールされた送信を示す制御情報を受信する送受信機と、動作中に、前記データのブラインド再送信の回数に応じてモニタリング期間を設定する回路と、
を備え、
前記送受信機は、動作中に、前記モニタリング期間中に前記ＰＤＣＣＨをモニターする、
送受信装置。
【請求項2】
前記送受信機は、動作中に、前記モニタリング期間内の前記ＰＤＣＣＨを介して、前記データのスケジュールされた再送信を示す第２制御情報を受信する、請求項１に記載の送受信装置。
【請求項3】
前記回路は、動作中に、前記制御情報が受信された場合、前記モニタリング期間を開始する、請求項１または請求項２に記載の送受信装置。
【請求項4】
前記送受信機は、動作中に、前記モニタリング期間の継続時間を示す継続インジケータを受信し、前記回路は、動作中に、前記継続インジケータにより示される前記継続時間に応じて前記モニタリング期間の前記継続時間を設定する、
請求項１～３の何れか１項に記載の送受信装置。
【請求項5】
前記回路は、動作中に、前記ブラインド再送信の回数に比例した前記モニタリング期間の継続時間を設定する、請求項１～３の何れか１項に記載の送受信装置。
【請求項6】
前記送受信機は、動作中に、前記ブラインド再送信の回数を示す再送信インジケータを受信する、請求項１～５の何れか１項に記載の送受信装置。
【請求項7】
前記送受信機は、動作中に、前記モニタリング期間の終了を示す終了インジケータを受信し、前記回路は、動作中に、前記終了インジケータが受信された場合、前記モニタリング期間を終了する、
請求項１～６の何れか１項に記載の送受信装置。
【請求項8】
前記回路は、動作中に、制御情報または第２制御情報が受信される時間ごとに部分的なモニタリング期間を開始することによる前記モニタリング期間を設定する、請求項２に記載の送受信装置。
【請求項9】
前記送受信機は、動作中に、前記制御情報または前記第２制御情報に応じて前記データを受信し、前記回路は、動作中に、
前記制御情報または前記第２制御情報に応じて、受信された前記データをデコードし、
デコードされた前記データが正常であるか否か判定し、
受信された前記データが正常にデコードされていない時間ごとに部分的なモニタリング期間を開始することによる前記モニタリング期間を設定する、
請求項２に記載の送受信装置。
【請求項10】
前記送受信機は、動作中に、再送信の回数を示す再送信インジケータを受信し、前記回路は、動作中に、受信された第２制御情報の回数が、示された前記再送信の回数と等しい場合、部分的なモニタリング期間を開始しない、
請求項８または請求項９に記載の送受信装置。
【請求項11】
前記送受信機は、動作中に、前記制御情報または第２制御情報に応じて前記データを受信し、前記回路は、動作中に、
前記送受信機により受信された前記データをデコードし、
前記データが正常にデコードされた場合、前記モニタリング期間を終了する、
請求項１～１０の何れか１項に記載の送受信装置。
【請求項12】
前記回路は、動作中に、前記モニタリング期間の継続時間に等しいランタイムでタイマーを開始することによる前記モニタリング期間を設定する、請求項１～１１の何れか１項に記載の送受信装置。
【請求項13】
間欠受信であるＤＲＸ周期が設定され、前記送受信機は、動作中に、アクティブ時間で前記ＰＤＣＣＨをモニターし、オフ期間で前記ＰＤＣＣＨをモニターしない、
請求項１～１２の何れか１項に記載の送受信装置。
【請求項14】
動作中に、データのブラインド再送信の回数を決定する回路と、動作中に、物理ダウンリンク制御チャネルであるＰＤＣＣＨを介して、前記ブラインド再送信の回数に応じた、前記データの、スケジュールされた送信または再送信を示す制御情報を送信する送受信機と、
を備えるスケジューリング装置。
【請求項15】
物理ダウンリンク制御チャネルであるＰＤＣＣＨを介して、データのスケジュールされた送信を示す制御情報を受信するステップと、前記データのブラインド再送信の回数に応じてモニタリング期間を設定するステップと、
を有し、
前記ＰＤＣＣＨは、前記モニタリング期間中にモニターされる、
方法。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、通信システムにおける信号の送受信に関する。特に、本開示は、そのような送受信のための方法および装置に関する。
【背景技術】
【0002】
現在、３ＧＰＰ（３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ）は、第５世代（５Ｇ）とも呼ばれる次世代セルラ技術の技術仕様に取り組んでいる。
【0003】
１つの目的は、ｅｎｈａｎｃｅｄ ｍｏｂｉｌｅ ｂｒｏａｄｂａｎｄ（ｅＭＢＢ）、ｕｌｔｒa－Ｒｅｌｉａｂｌｅ ｌｏｗ－ｌａｔｅｎｃｙ ｃｏｍｍｕｎｉｃａｔｉｏｎｓ（ＵＲＬＬＣ）、ｍａｓｓｉｖｅ ｍａｃｈｉｎｅ ｔｙｐｅ ｃｏｍｍｕｎｉｃａｔｉｏｎ（ｍＭＴＣ）を少なくとも含む、全ての利用シナリオ、要件及び配置シナリオ（例えば、ＴＲ３８．９１３ ｖｅｒｓｉｏｎ １５．０．０のセクション６を参照されたい）に対処する単一の技術的枠組みを提供することである。例えば、ｅＭＢＢ配置シナリオは、屋内ホットスポット、密集した都市、地方、都市マクロ及び高速を含んでもよく、ＵＲＬＬＣ配置シナリオは、産業制御システム、モバイルヘルスケア（リモートモニタリング、診断及び処置）、車両のリアルタイム制御、スマートグリッドのための広域モニタリング及び制御システムを含んでもよく、ｍＭＴＣ配置シナリオは、スマートウェアラブル及びセンサネットワークなどの非時間クリティカルなデータ伝送による多数のデバイスによるシナリオを含んでもよい。ｅＭＢＢ及びＵＲＬＬＣサービスは、その双方が極めて広い帯域幅を要求する点で類似するが、ＵＲＬＬＣサービスは超低遅延を好ましくは要求しうる点で異なる。
【0004】
第２目的は、順方向互換性を実現することである。Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ（ＬＴＥ，ＬＴＥ－Ａ）セルラシステムとの後方互換性は必要とされず、全く新しいシステム設計及び／又は新規な特徴の導入を容易にする。
【発明の概要】
【0005】
１つの非限定的かつ例示的な実施形態は、ダウンリンク制御チャネルの監視を伴う手順を含む、ＵＥ電力を節約することを容易にするための改善された手順を提供することを容易にする。
【0006】
一実施形態では、本明細書で開示される技術は、動作中に、物理ダウンリンク制御チャネルであるＰＤＣＣＨを介して、データのスケジュールされた送信を示す制御情報を受信する送受信機と、動作中に、データのブラインド再送信の回数に応じてモニタリング期間を設定する回路と、を備え、送受信機は、動作中に、モニタリング期間中にＰＤＣＣＨをモニターする。
【0007】
一般的または特定の実施形態は、システム、方法、集積回路、コンピュータプログラム、記憶媒体、またはそれらの任意の選択的な組合せとして実装され得ることに留意されたい。
【0008】
開示された実施形態のさらなる利益および利点は、明細書および図面から明らかになり得る。利益および／または利点は、明細書および図面の様々な実施形態および特徴によって個別に得ることができ、これらは、そのような利益および／または利点のうちの１つまたは複数を得るためにすべてが提供される必要はない。
【図面の簡単な説明】
【0009】
以下では、例示的な実施形態が、添付の図面を参照してより詳細に説明される。
【図1】３ＧＰＰ ＮＲシステムの一例となるアーキテクチャを示す図である。
【図2】ＬＴＥ ｅＮＢ、ｇＮＢ及びＵＥのための一例となるユーザ及び制御プレーンアーキテクチャを示す図である。
【図3】ＮＧ－ＲＡＮと５ＧＣとの間の機能分割を示す概略図である。
【図4】ＲＲＣ接続のセットアップ／再設定手順のシーケンス図である。
【図5】ｅｎｈａｎｃｅｄ Ｍｏｂｉｌｅ Ｂｒｏａｄｂａｎｄ、Ｍａｓｓｉｖｅ Ｍａｃｈｉｎｅ Ｔｙｐｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ（ｍＭＴＣ）およびＵｌｔｒａ－Ｒｅｌｉａｂｌｅ ａｎｄ Ｌｏｗ Ｌａｔｅｎｃｙ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ（ＵＲＬＬＣ）の使用シナリオを示す概略図である。
【図6】非ローミングシナリオのための例示的な５Ｇシステムアーキテクチャを示すブロック図である。
【図7A】ダウンリンクデータの送信のためのＨＡＲＱフィードバックを伴うＤＲＸ手順を示す図である。
【図7B】アップリンクデータの送信のためのＨＡＲＱフィードバックを伴うＤＲＸ手順を示す図である。
【図8】ＡＣＫ／ＮＡＣＫフィードバックを受信しないブラインド再送信のプロセスを示す図である。
【図9】ＤＲＸ周期が送受信装置のために設定される場合のデータの再送信のプロセスを示す図である。
【図10】ＨＡＲＱフィードバックなしのブラインド再送信プロセスを概略的に示す図である。
【図11】制御情報およびダウンリンクデータが、スケジュールされた再送信なしに送受信装置によって受信され、送受信装置がＰＤＣＣＨを不必要にモニターする状況を示す図である。
【図12】制御情報およびダウンリンクデータが、スケジュールされた再送信で送受信装置によって受信され、送受信装置がデータの誤再送信する状況を示す図である。
【図13】一実施形態に係るスケジューリング装置および送受信装置の機能構成要素を示すブロック図である。
【図14】ｄｒｘ－ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒを使用してモニタリング期間を設定した場合の、スケジューリング装置と送受信装置との間の送信の時系列を示す図である。
【図15】ｄｒｘ－ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒを使用してモニタリング期間が設定されている場合に送受信装置で実行される方法のステップを示す図である。
【図16】ｄｒｘ－ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒを使用してモニタリング期間が設定される場合の、スケジューリング装置と送受信装置との間の送信の時系列を示す図である。
【図17】ｄｒｘ－ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒを使用してモニタリング期間が設定された場合に送受信装置によって実行される方法のステップを示す図である。
【図18】ｄｒｘ－ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒを使用してモニタリング期間が設定され、終了インジケータが受信されたときの、スケジューリング装置と送受信装置との間の送信の時系列を示す図である。
【図19】ｄｒｘ－ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒを使用してモニタリング期間が設定され、終了インジケータが受信されたときに送受信装置によって実行される方法のステップを示す図である。
【図20】ｄｒｘ－ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒを使用してモニタリング期間が設定され、終了インジケータが受信された場合の、スケジューリング装置と送受信装置との間の送信の時系列を示す図である。
【図21】ｄｒｘ－ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒを使用してモニタリング期間が設定され、終了インジケータが受信されたときに送受信装置によって実行される方法のステップを示す図である。
【図22】ブラインド再送信の数を示す再送信インジケータが受信され、ｄｒｘ－ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒを使用してモニタリング期間を設定するために使用される、実施形態による方法を示すフローチャートである。
【図23】ブラインド再送信の数を示す再送信インジケータが受信され、ｄｒｘ－ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒがモニタリング期間を設定するために使用される、実施形態による方法を示すフローチャートである。
【図24】ｄｒｘ－ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒを使用して部分的なモニタリング期間を設定することによってモニタリング期間が設定される場合の、スケジューリング装置と送受信装置との間の送信の時系列を示す図である。
【図25】ｄｒｘ－ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒを使用して部分的なモニタリング期間を設定することによってモニタリング期間が設定される場合の、送受信装置によって実行される方法のステップを示す図である。
【図26】ｄｒｘ－ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒを使用して部分的なモニタリング期間を設定することによってモニタリング期間が設定される場合の、スケジューリング装置と送受信装置との間の送信の時系列を示す図である。
【図27】ｄｒｘ－ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒを使用して部分的なモニタリング期間を設定することによってモニタリング期間が設定される場合の、送受信装置によって実行される方法のステップを示す図である。
【図28】ｄｒｘ－ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒを使用して部分的なモニタリング期間を設定することによってモニタリング期間が設定され、ブラインド再送信の数が示される場合に、送受信装置によって実行される方法のステップを示すフローチャートを示す。
【図29】ｄｒｘ－ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒを使用して部分的なモニタリング期間を設定することによってモニタリング期間が設定され、ブラインド再送信の数が示される場合に、送受信装置によって実行される方法のステップを示すフローチャートである。
【図30】一実施形態によるブラインド再送信の数を示すＭＡＣ制御要素ＣＥを概略的に示す図である。
【発明を実施するための形態】
【0010】
５Ｇ ＮＲシステムアーキテクチャ及びプロトコルスタック
３ＧＰＰは、１００ＧＨｚまでの範囲の周波数において動作するＮＲ（Ｎｅｗ Ｒａｄｉｏ Ａｃｃｅｓｓ Ｔｅｃｈｎｏｌｏｇｙ）の開発を含む、単に５Ｇと呼ばれる第５世代セルラ技術のための次のリリースに取り組んでいる。５Ｇ規格の最初のバージョンは、２０１７年の終わりに完了され、５Ｇ ＮＲ規格に準拠したスマートフォンの試行と商業展開に進むことを可能にした。
３ＧＰＰは、１００ＧＨｚまでの範囲の周波数において動作するＮＲ（Ｎｅｗ Ｒａｄｉｏ Ａｃｃｅｓｓ Ｔｅｃｈｎｏｌｏｇｙ）の開発を含む、単に５Ｇと呼ばれる第５世代セルラ技術のための次のリリースに取り組んでいる。５Ｇ規格の最初のバージョンは、２０１７年の終わりに完了され、５Ｇ ＮＲ規格に準拠したスマートフォンの試行と商業展開に進むことを可能にした。
【0011】
特に、全体のシステムアーキテクチャは、ｇＮＢを含み、ＵＥに対してＮＧ無線アクセスユーザプレーン（ＳＤＡＰ／ＰＤＣＰ／ＲＬＣ／ＭＡＣ／ＰＨＹ）及び制御プレーン（ＲＲＣ）プロトコルターミネーションを提供するＮＧ－ＲＡＮ（Ｎｅｘｔ Ｇｅｎｅｒａｔｉｏｎ－Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ）を想定する。ｇＮＢは、Ｘｎインターフェースによって互いに相互接続される。ｇＮＢはまた、ＮＧ（Ｎｅｘｔ Ｇｅｎｅｒａｔｉｏｎ）インターフェースによってＮＧＣ（Ｎｅｘｔ Ｇｅｎｅｒａｔｉｏｎ Ｃｏｒｅ）に接続され、より詳細には、ＮＧ－ＣインターフェースによってＡＭＦ（Ａｃｃｅｓｓ ａｎｄ Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｆｕｎｃｔｉｏｎ）（例えば、ＡＭＦを実行する特定のコアエンティティ）と、ＮＧ－ＵインターフェースによってＵＰＦ（Ｕｓｅｒ Ｐｌａｎｅ Ｆｕｎｃｔｉｏｎ）（例えば、ＵＰＦを実行する特定のコアエンティティ）とに接続される。図１において、ＮＧ－ＲＡＮアーキテクチャが示される（例えば、３ＧＰＰ ＴＳ３８．３００ ｖ１５．６．０のセクション４を参照されたい）。
【0012】
様々な異なる配備シナリオがサポート可能である（例えば、３ＧＰＰ ＴＲ３８．８０１ ｖ１４．０．０を参照されたい）。例えば、非集中配備シナリオがそこに提示され（例えば、ＴＲ３８．８０１のセクション５．２を参照されたい。集中配置はセクション５．４に示される）、５Ｇ ＮＲをサポートする基地局が配備可能である。図２は、一例となる非集中配備シナリオ（例えば、ＴＲ３８．８０１のＦｉｇｕｒｅ ５．２－１を参照されたい）を示し、更にｇＮＢとＬＴＥ ｅＮＢとの双方に接続されるユーザ装置（ＵＥ）と共にＬＴＥ ｅＮＢを示す。ＮＲ ５Ｇのための新たなｅＮＢは、例示的にｇＮＢと呼ばれうる。ｅＬＴＥ ｅＮＢは、ＥＰＣ（Ｅｖｏｌｖｅｄ Ｐａｃｋｅｔ Ｃｏｒｅ）とＮＧＣ（Ｎｅｘｔ Ｇｅｎｅｒａｔｉｏｎ Ｃｏｒｅ）との接続性をサポートするｅＮＢの進化型である。
【0013】
ＮＲのユーザプレーンプロトコルスタック（例えば、３ＧＰＰ ＴＳ３８．３００ セクション４．４．１を参照されたい）は、ネットワーク側でｇＮＢにおいて終端される、ＰＤＣＰ（Ｐａｃｋｅｔ Ｄａｔａ Ｃｏｎｖｅｒｇｅｎｃｅ Ｐｒｏｔｏｃｏｌ、ＴＳ３８．３００のセクション６．４を参照されたい）サブレイヤ、ＲＬＣ（Ｒａｄｉｏ Ｌｉｎｋ Ｃｏｎｔｒｏｌ、ＴＳ３８．３００のセクション６．３を参照されたい）サブレイヤ、及びＭＡＣ（ＭｅｄｉｕＭＡＣ ＣＥｓｓ Ｃｏｎｔｒｏｌ、ＴＳ３８．３００のセクション６．２を参照されたい）サブレイヤを有する。さらに、新たなアクセス層（ＡＳ）サブレイヤ（ＳＤＡＰ，Ｓｅｒｖｉｃｅ Ｄａｔａ Ａｄａｐｔａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）が、ＰＤＣＰ（例えば、３ＧＰＰ ＴＳ３８．３００のサブクローズ６．５を参照されたい）の上に導入される。制御プレーンプロトコルスタックがまた、ＮＲに対して規定される（例えば、ＴＳ３８．３００のセクション４．４．２を参照されたい）。レイヤ２機能の概略は、ＴＳ３８．３００のサブクローズ６に与えられる。ＰＤＣＰ、ＲＬＣ及びＭＡＣサブレイヤの機能は、ＴＳ３８．３００のセクション６．４，６．３及び６．２にそれぞれ列記される。ＲＲＣレイヤの機能は、ＴＳ３８．３００のサブクローズ７に列記される。
【0014】
例えば、ＭＡＣレイヤは、異なるニューメロロジのハンドリングを含む、論理チャネルの多重化及びスケジューリングとスケジューリング関連機能とを扱う。
【0015】
物理レイヤ（ＰＨＹ）は、例えば、符号化、ＰＨＹ ＨＡＲＱ処理、変調、マルチアンテナ処理、及び適切な物理時間周波数リソースへの信号のマッピングを担当する。それはまた、トランスポートチャネルの物理チャネルへのマッピングを扱う。物理レイヤは、トランスポートチャネルの形式によりサービスをＭＡＣレイヤに提供する。物理チャネルは、特定のトランスポートチャネルの送信に利用される時間周波数リソースのセットに対応し、各トランスポートチャネルは、対応する物理チャネルにマッピングされる。１つの物理チャネルは、ランダムアクセスに利用されるＰＲＡＣＨ（Ｐｈｙｓｉｃａｌ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｃｈａｎｎｅｌ）である。
【0016】
ＮＲのための利用ケース／配備シナリオは、データレート、遅延及びカバレッジに関する多様な要件を有するｅＭＢＢ（ｅｎｈａｎｃｅｄ Ｍｏｂｉｌｅ Ｂｒｏａｄｂａｎｄ）、ＵＲＬＬＣ（Ｕｌｔｒａ－Ｒｅｌｉａｂｌｅ Ｌｏｗ－Ｌａｔｅｎｃｙ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ）及びｍＭＴＣ（ｍａｓｓｉｖｅ Ｍａｃｈｉｎｅ Ｔｙｐｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）を含みうる。例えば、ｅＭＢＢは、ＩＭＴ－Ａｄｖａｎｃｅｄによって提供されるもの３倍のオーダのピークデータレート（ダウンリンクについて２０Ｇｂｐｓと、アップリンクについて１０Ｇｂｐｓ）とユーザ体感データレートとをサポートすることが期待される。他方、ＵＲＬＬＣのケースでは、よりタイトな要件が超低遅延（ユーザプレーン遅延のＵＬ及びＤＬのそれぞれについて０．５ｍｓ）及び高信頼性（１ｍｓ内に１－１０－５）に対して課される。最終的に、ｍＭＴＣは、好ましくは、高い接続密度（都市環境において１，０００，０００デバイス数／ｋｍ２）、厳しい環境での大きなカバレッジ、及び低コストデバイスのための極めて長寿命のバッテリ（１５年間）を要求しうる。
【0017】
従って、１つのユースケースに適したＯＦＤＭニューメロロジ（例えば、サブキャリア間隔、ＯＦＤＭシンボル持続時間、サイクリックプリフィックス（ＣＰ）持続時間、スケジューリングインターバル毎のシンボル数など）は、別のユースケースでは良好には機能しないかもしれない。例えば、低遅延サービスは、好ましくは、ｍＭＴＣサービスより短いシンボル持続時間（及び、従ってより大きなサブキャリア間隔）及び／又はスケジューリング間隔毎のより少ないシンボル（別名、ＴＴＩ）を必要としうる。さらに、大きなチャネル遅延スプレッドを有する配備シナリオは、好ましくは、短い遅延スプレッドを有するシナリオよりも長いＣＰ持続時間を必要としうる。同様のＣＰオーバ－ヘッドを保持するため、サブキャリア間隔はそれに応じて最適化されるべきである。ＮＲは、サブキャリア間隔の複数の値をサポートしてもよい。これに対応して、現在、１５ｋＨｚ、３０ｋＨｚ、６０ｋＨｚ・・・のサブキャリア間隔が検討されている。シンボル持続時間Ｔｕとサブキャリア間隔Δｆは、Δｆ＝１／Ｔuの式を介し直接関連する。ＬＴＥシステムと同様に、“リソースエレメント”という用語は、１つのＯＦＤＭ／ＳＣ－ＦＤＭＡシンボルの長さに対して１つのサブキャリアから構成される最小のリソースユニットを示すのに利用できる。
【0018】
新しい無線システム５Ｇ－ＮＲでは、各ニューメロロジ及び搬送波に対して、サブキャリアとＯＦＤＭシンボルのリソースグリッドが、アップリンクとダウンリンクについてそれぞれ規定される。リソースグリッドにおける各要素は、リソースエレメントと呼ばれ、周波数領域の周波数インデックス及び時間領域のシンボル位置に基づいて特定される（３ＧＰＰ ＴＳ３８．２１１ ｖ１５．６．０を参照されたい）。
【0019】
ＮＧ－ＲＡＮと５ＧCとの間の５Ｇ ＮＲ機能分割
図３は、ＮＧ－ＲＡＮと５ＧCとの間の機能分割を示す図である。ＮＧ－ＲＡＮ論理ノードはｇＮＢまたはｎｇ－ｅＮＢである。５ＧＣには、論理ノードＡＭＦ、ＵＰＦ、およびＳＭＦがある。
図３は、ＮＧ－ＲＡＮと５ＧCとの間の機能分割を示す図である。ＮＧ－ＲＡＮ論理ノードはｇＮＢまたはｎｇ－ｅＮＢである。５ＧＣには、論理ノードＡＭＦ、ＵＰＦ、およびＳＭＦがある。
【0020】
特に、ｇＮＢとｎｇ－ｅＮＢは以下の主な機能をホストする。
・無線ベアラ制御、無線アドミッション制御、接続モビリティ制御、アップリンクとダウンリンクとの両方におけるＵＥへのリソースの動的割り当て（スケジューリング）などの無線リソース管理のための機能
・ＩＰヘッダの圧縮、暗号化、データの完全性保護
・ＡＭＦへのルーティングがＵＥによって提供される情報から決定され得ない場合のＵＥアタッチメントにおけるＡＭＦの選択
・ＵＰＦへのユーザプレーンデータのルーティング
・ＡＭＦへの制御プレーン情報のルーティング
・接続の設定と解除
・ページングメッセージのスケジューリングと送信
・システムブロードキャスト情報（ＡＭＦまたはＯＡＭから発信される）のスケジューリングおよび送信
・モビリティおよびスケジューリングのための測定および測定報告設定
・アップリンクにおけるトランスポートレベルのパケットマーキング
・セッション管理
・ネットワークスライシングのサポート
・ＱｏＳフロー管理とデータ無線ベアラへのマッピング
・ＲＲＣ＿ＩＮＡＣＴＩＶＥ状態のＵＥのサポート
・ＮＡＳメッセージの配布機能
・無線アクセスネットワークシェアリング
・デュアルコネクティビティ
・ＮＲとＥ－ＵＴＲＡとの間の緊密な相互作用
・無線ベアラ制御、無線アドミッション制御、接続モビリティ制御、アップリンクとダウンリンクとの両方におけるＵＥへのリソースの動的割り当て（スケジューリング）などの無線リソース管理のための機能
・ＩＰヘッダの圧縮、暗号化、データの完全性保護
・ＡＭＦへのルーティングがＵＥによって提供される情報から決定され得ない場合のＵＥアタッチメントにおけるＡＭＦの選択
・ＵＰＦへのユーザプレーンデータのルーティング
・ＡＭＦへの制御プレーン情報のルーティング
・接続の設定と解除
・ページングメッセージのスケジューリングと送信
・システムブロードキャスト情報（ＡＭＦまたはＯＡＭから発信される）のスケジューリングおよび送信
・モビリティおよびスケジューリングのための測定および測定報告設定
・アップリンクにおけるトランスポートレベルのパケットマーキング
・セッション管理
・ネットワークスライシングのサポート
・ＱｏＳフロー管理とデータ無線ベアラへのマッピング
・ＲＲＣ＿ＩＮＡＣＴＩＶＥ状態のＵＥのサポート
・ＮＡＳメッセージの配布機能
・無線アクセスネットワークシェアリング
・デュアルコネクティビティ
・ＮＲとＥ－ＵＴＲＡとの間の緊密な相互作用
【0021】
アクセスおよびモビリティ管理機能（ＡＭＦ）は、以下のメイン機能をホストする。
・非アクセス層（ＮＡＳ）、シグナリング終了
・ＮＡＳシグナリングセキュリティ
・アクセス層（ＡＳ）、セキュリティコントロール
・３ＧＰＰアクセスネットワーク間のモビリティのためのコアネットワーク（ＣＮ）ノード間シグナリング
・アイドルモードＵＥ到達可能性（ページング再送の制御および実行を含む）
・レジストレーションエリア管理
・システム内およびシステム間モビリティの支援
・アクセス認証
・ローミング権のチェックを含むアクセス権限
・モビリティ管理制御（サブスクリプションおよびポリシー）
・ネットワークスライシングのサポート
・セッション管理機能（ＳＭＦ）、選択
・非アクセス層（ＮＡＳ）、シグナリング終了
・ＮＡＳシグナリングセキュリティ
・アクセス層（ＡＳ）、セキュリティコントロール
・３ＧＰＰアクセスネットワーク間のモビリティのためのコアネットワーク（ＣＮ）ノード間シグナリング
・アイドルモードＵＥ到達可能性（ページング再送の制御および実行を含む）
・レジストレーションエリア管理
・システム内およびシステム間モビリティの支援
・アクセス認証
・ローミング権のチェックを含むアクセス権限
・モビリティ管理制御（サブスクリプションおよびポリシー）
・ネットワークスライシングのサポート
・セッション管理機能（ＳＭＦ）、選択
【0022】
さらに、ユーザプレーン機能（ＵＰＦ）は、以下のメイン機能をホストする。
・ＲＡＴ内／間モビリティのアンカーポイント（該当する場合）
・データネットワークへの相互接続の外部ＰＤＵセッションポイント
・パケットルーティングと転送
・ポリシールール施行のパケット検査およびユーザプレーン部分
・トラフィック使用報告
・データネットワークへのトラフィックフローのルーティングをサポートするアップリンク分類子
・マルチホームＰＤＵセッションをサポートする分岐ポイント
・パケットフィルタリング、ゲーティング、ＵＬ／ＤＬレート施行などのユーザプレーンのためのＱｏＳ処理
・アップリンクトラフィック検証（ＳＤＦからＱｏＳへのフローマッピング）
・ダウンリンクパケットバッファリングとダウンリンクデータ通知トリガ
・ＲＡＴ内／間モビリティのアンカーポイント（該当する場合）
・データネットワークへの相互接続の外部ＰＤＵセッションポイント
・パケットルーティングと転送
・ポリシールール施行のパケット検査およびユーザプレーン部分
・トラフィック使用報告
・データネットワークへのトラフィックフローのルーティングをサポートするアップリンク分類子
・マルチホームＰＤＵセッションをサポートする分岐ポイント
・パケットフィルタリング、ゲーティング、ＵＬ／ＤＬレート施行などのユーザプレーンのためのＱｏＳ処理
・アップリンクトラフィック検証（ＳＤＦからＱｏＳへのフローマッピング）
・ダウンリンクパケットバッファリングとダウンリンクデータ通知トリガ
【0023】
最後に、セッション管理機能（ＳＭＦ）は、以下のメイン機能をホストする。
・セッション管理
・ＵＥ ＩＰアドレスの割り当てと管理
・ＵＰ機能の選択と制御
・トラフィックを適切な宛先にルーティングするための、ユーザプレーン機能（ＵＰＦ）でのトラフィックステアリングの設定
・ポリシー施行およびＱｏＳの制御部分
・データ通知のダウンリンク
・セッション管理
・ＵＥ ＩＰアドレスの割り当てと管理
・ＵＰ機能の選択と制御
・トラフィックを適切な宛先にルーティングするための、ユーザプレーン機能（ＵＰＦ）でのトラフィックステアリングの設定
・ポリシー施行およびＱｏＳの制御部分
・データ通知のダウンリンク
【0024】
ＲＲＣ接続のセットアップと再設定の手順
図４は、ＮＡＳの一部（ＴＳ３８．３００ v１５．６．０参照）のためのＲＲＣ＿ＩＤＬＥからＲＲＣ＿ＣＯＮＮＥＣＴＥＤへのＵＥの移行のコンテキストにおける、ＵＥ、ｇＮＢ、ＡＭＦ（５ＧＣエンティティ）間のいくつかの相互作用を示す図である。
図４は、ＮＡＳの一部（ＴＳ３８．３００ v１５．６．０参照）のためのＲＲＣ＿ＩＤＬＥからＲＲＣ＿ＣＯＮＮＥＣＴＥＤへのＵＥの移行のコンテキストにおける、ＵＥ、ｇＮＢ、ＡＭＦ（５ＧＣエンティティ）間のいくつかの相互作用を示す図である。
【0025】
ＲＲＣは、ＵＥおよびｇＮＢ設定のために使用される上位レイヤシグナリング（プロトコル）である。特に、この移行はＡＭＦがＵＥコンテキストデータ（例えば、ＰＤＵセッションコンテキスト、セキュリティキー、ＵＥ無線能力およびＵＥセキュリティ能力などを含む）を準備し、それをＩＮＩＴＩＡＬ ＣＯＮＴＥＸＴ ＳＥＴＵＰ ＲＥＱＵＥＳＴと共にｇＮＢに送信することを含む。次に、ｇＮＢは、ＵＥとのＡＳセキュリティをアクティブにする。これは、ＵＥに対してＳｅｃｕｒｉｔｙＭｏｄｅＣｏｍｍａｎｄのメッセージを送信するｇＮＢと、ＳｅｃｕｒｉｔｙＭｏｄｅＣｏｍｐｌｅｔｅのメッセージでｇＮＢに応答するＵＥと、によって実行される。その後、ｇＮＢは、ＲＲＣＲｅｃｏｎｆｉｇｕｒａｔｉｏｎのメッセージをＵＥに送信し、それに応答して、ＵＥからＲＲＣＲｅｃｏｎｆｉｇｕｒａｔｉｏｎＣｏｍｐｌｅｔｅのメッセージをｇＮＢによって受信することによって、シグナリング無線ベアラ２（ＳＲＢ２）、およびデータ無線ベアラ（ＤＲＢ（複数可））を設定するための再設定を実行する。信号のみの接続の場合、ＳＲＢ２およびＤＲＢは設定されないので、ＲＲＣＲｅｃｏｎｆｉｇｕｒａｔｉｏｎに関連するステップはスキップされる。最後に、ｇＮＢは、設定手順がＩＮＩＴＩＡＬ ＣＯＮＴＥＸＴ ＳＥＴＵＰ ＲＥＳＰＯＮＳＥで完了したことをＡＭＦに通知する。
【0026】
したがって、本開示では、動作中に、ｇＮｏｄｅＢとの次世代（ＮＧ）接続を確立する制御回路と、動作中に、初期コンテキスト設定メッセージを、ＮＧ接続を介してｇＮｏｄｅＢに送信して、ｇＮｏｄｅＢとユーザ装置（ＵＥ）との間のシグナリング無線ベアラ設定を引き起こす送信機とを備える、第５世代コア（５ＧC）のエンティティ（たとえばＡＭＦ、ＳＭＦなど）が提供される。具体的には、ｇＮｏｄｅＢは、シグナリング無線ベアラを介して、リソース割り当て設定情報要素を含むシグナリングである無線リソース制御（ＲＲＣ）をＵＥに送信する。次に、ＵＥは、リソース割り当て設定に基づいて、アップリンク送信またはダウンリンク受信を実行する。
【0027】
２０２０年以降のＩＭＴの利用シナリオ
図５は、５Ｇ ＮＲのためのいくつかの使用事例を示す図である。３ＧＰＰ ＮＲ（３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ ｎｅｗ ｒａｄｉｏ）では、ＩＭＴ－２０２０によって多種多様なサービスおよびアプリケーションをサポートすることが想定されている３つのユースケースが考慮されている。ｅＭＢＢ（ｅｎｈａｎｃｅｄ ｍｏｂｉｌｅ ｂｒｏａｄｂａｎｄ）のフェーズ１の仕様が完成している。ｅＭＢＢサポートをさらに拡張することに加えて、現在および将来の作業は、Ｕｌｔｒａ－Ｒｅｌｉａｂｌｅ ａｎｄ Ｌｏｗ Ｌａｔｅｎｃｙ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ（ＵＲＬＬＣ）およびＭａｓｓｉｖｅ Ｍａｃｈｉｎｅ Ｔｙｐｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓのための標準化を伴うことになる。図５は、２０２０年以降のＩＭＴについて想定される使用シナリオのいくつかの例を示す図である。
図５は、５Ｇ ＮＲのためのいくつかの使用事例を示す図である。３ＧＰＰ ＮＲ（３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ ｎｅｗ ｒａｄｉｏ）では、ＩＭＴ－２０２０によって多種多様なサービスおよびアプリケーションをサポートすることが想定されている３つのユースケースが考慮されている。ｅＭＢＢ（ｅｎｈａｎｃｅｄ ｍｏｂｉｌｅ ｂｒｏａｄｂａｎｄ）のフェーズ１の仕様が完成している。ｅＭＢＢサポートをさらに拡張することに加えて、現在および将来の作業は、Ｕｌｔｒａ－Ｒｅｌｉａｂｌｅ ａｎｄ Ｌｏｗ Ｌａｔｅｎｃｙ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ（ＵＲＬＬＣ）およびＭａｓｓｉｖｅ Ｍａｃｈｉｎｅ Ｔｙｐｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓのための標準化を伴うことになる。図５は、２０２０年以降のＩＭＴについて想定される使用シナリオのいくつかの例を示す図である。
【0028】
ＵＲＬＬＣのユースケースは、スループット、レイテンシ、および有効性などの能力に対する厳しい要件を有し、産業製造または生産プロセスの無線制御、遠隔医療手術、スマートグリッドにおける流通自動化、輸送安全などの将来の垂直アプリケーションのためのイネーブラの１つとして想定されている。ＵＲＬＬＣの高信頼性は、ＴＲ ３８．９１３によって設定された要件を満たす技術を識別することによってサポートされる。リリース１５におけるＮＲ ＵＲＬＬＣについては、キー要件は、ＵＬ（アップリンク）については０．５ｍｓのターゲットユーザプレーンレイテンシ、およびＤＬ（ダウンリンク）については０．５ｍｓのターゲットユーザプレーンレイテンシを含む。パケットの１回の送信の一般的なＵＲＬＬＣ要件は、１ｍｓのユーザプレーンレイテンシが３２バイトのパケットサイズに対して１Ｅ－５のＢＬＥＲ（ブロックエラーレート）である。
【0029】
ＲＡＮ１の観点から、信頼性は、多くの可能な方法で改良することができる。信頼性を改善するための現状の範囲は、ＵＲＬＬＣ、よりコンパクトなＤＣＩフォーマット、ＰＤＣＣＨの繰り返しなどのための別個のＣＱＩテーブルを定義することを含む。しかし、ＮＲがより安定し、開発されるにつれて（ＮＲ ＵＲＬＬＣキー要求に対して）、高信頼性を達成するための範囲が広がるかもしれない。Ｒｅｌ．１５におけるＮＲ ＵＲＬＬＣの特定の使用事例には、拡張現実／仮想現実（ＡＲ／ＶＲ）、ｅ－ｈｅａｌｔｈ、ｅ－ｓａｆｅｔｙ、およびミッションクリティカルアプリケーションが含まれる。
【0030】
さらに、ＮＲ ＵＲＬＬＣが対象とする技術強化は、レイテンシの改善および信頼性の改善を目指している。レイテンシ改善のための技術拡張には、設定可能なニューメロロジ、柔軟なマッピングによる非スロットベーススケジューリング、無料（設定済み許可）アップリンクの許可、データチャネルのスロットレベルの繰り返し、ダウンリンクのプリエンプションが含まれる。プリエンプションとは、すでにリソースが割り当てられている送信を停止し、すでに割り当てられているリソースが、後で要求された別の送信に使用されるが、遅延が少なく、優先順位の高い要件があることを意味する。したがって、既に許可された送信は、後の送信によってプリエンプトされる。プリエンプションは、特定のサービスタイプとは無関係に適用可能である。例えば、サービスタイプＡ（ＵＲＬＬＣ）のための送信は、サービスタイプＢ（ｅＭＢＢなど）のための送信によってプリエンプトされ得る。信頼性改善に関する技術強化には、１Ｅ－５のターゲットＢＬＥＲのための専用ＣＱＩ／ＭＣＳテーブルが含まれる。
【0031】
ｍＭＴＣ（ｍａｓｓｉｖｅ ｍａｃｈｉｎｅ ｔｙｐｅ ｃｏｍｍｕｎｉｃａｔｉｏｎ）のユースケースは、非常に多数の接続されたデバイスが、典型的には、比較的少量の非遅延センシティブデータを送信することを特徴とする。装置は低コストで、バッテリ寿命が非常に長いことが要求される。ＮＲの観点から、非常に狭い帯域幅の部分を利用することは、ＵＥの観点から省電力を有し、長いバッテリ寿命を可能にする一つの可能な解決策である。
【0032】
このように、ＮＲの信頼性の範囲が広がることが期待される。すべての場合に対する、特にＵＲＬＬＣおよびｍＭＴＣに必要な１つの重要な要件は、高信頼性または超信頼性である。無線の観点およびネットワークの観点から信頼性を改善するために、いくつかのメカニズムが考えられる。一般に、信頼性を改善するのに役立ついくつかの重要な潜在的領域がある。これらの領域の中には、コンパクトな制御チャネル情報、データ／制御チャネルの繰り返し、および周波数、時間、および／または空間領域に関するダイバーシティがある。これらの領域は、特定の通信シナリオにかかわらず、一般に信頼性に適用可能である。
【0033】
ＮＲ ＵＲＬＬＣについては、ファクトリーオートメーション、輸送産業、およびファクトリーオートメーション、輸送産業、電力供給を含む電力供給など、より厳しい要件を有するさらなる使用事例が特定されている。より厳しい要件は、より高い信頼性（１０～６レベルまで）、より高い有効性、２５６バイトまでのパケットサイズ、数μｓ程度までの時間同期であり、値は、周波数範囲に応じて１μｓまたは数μｓとすることができ、短いレイテンシは、使用ケースに応じて、０．５～１ｍｓ程度、特に目標ユーザプレーンレイテンシは０．５ｍｓとすることができる。
【0034】
さらに、ＮＲ ＵＲＬＬＣについては、ＲＡＮ１の観点からのいくつかの技術強化が識別されている。これらの中には、コンパクトＤＣＩ、ＰＤＣＣＨの繰り返し、増加したＰＤＣＣＨのモニタリングに関連するＰＤＣＣＨ（物理ダウンリンク制御チャネル）強化がある。さらに、ＵＣＩ（アップリンク制御情報）拡張は、拡張ＨＡＲＱ（ハイブリッド自動再送要求）およびＣＳＩフィードバック拡張に関連する。また、ミニスロットレベルホッピングおよび再送／反復エンハンスメントに関連するＰＵＳＣＨエンハンスメントも識別されている。「ミニスロット」という用語は、スロット（１４個のシンボルを含むスロット）よりも少ない数のシンボルを含む送信時間間隔（ＴＴＩ）を指す。
【0035】
ＱｏＳ制御
５Ｇ ＱｏＳ（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）モデルはＱｏＳフローに基づいており、保証されたフロービットレート（ＧＢＲ ＱｏＳフロー）を必要とするＱｏＳフローと、保証されたフロービットレートを必要としないＱｏＳフロー（非ＧＢＲ ＱｏＳフロー）の両方をサポートする。したがって、ＮＡＳレベルでは、ＱｏＳフローはＰＤＵセッションにおけるＱｏＳ差別化の最も細かい粒度である。ＱｏＳフローは、ＮＧ－Ｕインターフェース上のカプセル化ヘッダで運ばれるＱｏＳフローＩＤ（ＱＦＩ）によってＰＤＵセッション内で識別される。
５Ｇ ＱｏＳ（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）モデルはＱｏＳフローに基づいており、保証されたフロービットレート（ＧＢＲ ＱｏＳフロー）を必要とするＱｏＳフローと、保証されたフロービットレートを必要としないＱｏＳフロー（非ＧＢＲ ＱｏＳフロー）の両方をサポートする。したがって、ＮＡＳレベルでは、ＱｏＳフローはＰＤＵセッションにおけるＱｏＳ差別化の最も細かい粒度である。ＱｏＳフローは、ＮＧ－Ｕインターフェース上のカプセル化ヘッダで運ばれるＱｏＳフローＩＤ（ＱＦＩ）によってＰＤＵセッション内で識別される。
【0036】
各ＵＥについて、５ＧＣは、１つまたは複数のＰＤＵセッションを確立する。各ＵＥについて、ＮＧ－ＲＡＮは、ＰＤＵセッションと一緒に少なくとも１つのデータ無線ベアラ（ＤＲＢ）を確立し、そのＰＤＵセッションのＱｏＳフロー（複数可）のための追加のＤＲＢ（複数可）は、例えば、図４を参照して上記で示されるように、その後に設定され得る（それは、そうするときにＮＧ－ＲＡＮまでである）。ＮＧ－ＲＡＮは、異なるＰＤＵセッションに属するパケットを異なるＤＲＢにマッピングする。ＵＥ内および５ＧＣ内のＮＡＳレベルパケットフィルタは、ＵＬおよびＤＬパケットをＱｏＳフローに関連付け、一方、ＵＥ内およびＮＧ－ＲＡＮ内のＡＳレベルマッピングルールは、ＵＬおよびＤＬ ＱｏＳフローをＤＲＢに関連付ける。
【0037】
図６は、５Ｇ ＮＲ非ローミング参照アーキテクチャを示す（ＴＳ ２３．５０１ ｖ１６．１．０、セクション４．２３を参照）。アプリケーション機能（ＡＦ）、例えば、図５で例示的に説明されている５Ｇサービスをホストする外部アプリケーションサーバは、例えば、トラフィックルーティングに対するアプリケーションの影響、または、ネットワーク露出機能（ＮＥＦ）へのアクセス、または、ポリシー制御（ポリシー制御機能、ＰＣＦを参照）のためのポリシーフレームワーク（例えば、ＱｏＳ制御）との対話、をサポートするサービスを提供するために、３ＧＰＰコアネットワークと対話する。オペレータの配置に基づいて、オペレータによって信頼されていると見なされるアプリケーション関数は、関連するネットワーク関数と直接対話することができる。オペレータがネットワーク機能に直接アクセスすることを許可されていないアプリケーション機能は、ＮＥＦを介して外部公開フレームワークを使用して、関連するネットワーク機能と対話する。
【0038】
図６は、５Ｇアーキテクチャのさらなる機能ユニット、すなわち、ネットワークスライス選択機能（ＮＳＳＦ）、ネットワークリポジトリ機能（ＮＲＦ）、統合データ管理（ＵＤＭ）、認証サーバ機能（ＡＵＳＦ）、アクセスおよびモビリティ管理機能（ＡＭＦ）、セッション管理機能（ＳＭＦ）、およびデータネットワーク（ＤＮ）、すなわち、オペレータサービス、インターネットアクセスまたはサードパーティサービスを示す。
【0039】
端末は、ＬＴＥおよびＮＲにおいて、ユーザ装置（ＵＥ）として称される。これはワイヤレス電話、スマートフォン、タブレットコンピュータ、またはユーザ装置の機能を有するＵＳＢ（ｕｎｉｖｅｒｓａｌ ｓｅｒｉａｌ ｂｕｓ）スティックなどのモバイル装置であってもよい。しかしながら、モバイル装置という用語は、これに限定されず、一般に、リレーが、そのようなモバイル装置の機能性を有してもよいし、モバイル装置は、リレーとしても機能してもよい。
【0040】
基地局は、例えば、端子にサービスを提供するためのネットワークの一部を形成するネットワークノードである。基地局は、端末への無線アクセスを提供するネットワークノードである。端末と基地局との間の通信は、典型的には標準化されている。ＬＴＥおよびＮＲでは、ワイヤレスインターフェースプロトコルスタックは、物理レイヤ、ＭＡＣ（ｍｅｄｉｕｍ ａｃｃｅｓｓ ｃｏｎｔｒｏｌ）、および上位レイヤを含む。制御プレーンでは、上位レイヤプロトコル無線リソース制御プロトコルが提供される。ＲＲＣを介して、基地局は、端末の設定を制御することができ、端末は、接続およびベアラの確立、修正などの制御タスク、測定、および他の機能を実行するために基地局と通信することができる。
【0041】
レイヤによって提供されるデータを上位レイヤに転送するためのサービスは、通常、チャネルと称される。例えば、ＬＴＥおよびＮＲは、ＭＡＣレイヤによって上位レイヤに提供される論理チャネルと、物理レイヤによってＭＡＣレイヤに提供されるトランスポートチャネルと、物理リソース上のマッピングを定義する物理チャネルとを区別する。
【0042】
論理チャネルは、ＭＡＣによって提供されるさまざまな種類のデータ転送サービスである。各論理チャネルタイプは、転送される情報のタイプによって定義される。論理チャネルは、制御チャネルとトラフィックチャネルの２つのグループに分類される。制御チャネルは、制御プレーン情報の転送のみに使用される。トラフィックチャネルは、ユーザプレーン情報の転送のみに使用される。
【0043】
間欠受信－ＤＲＸ
パケットデータは、しばしばバースト性が高く、時折無音の期間がある。遅延の観点から、アップリンク許可またはダウンリンクデータ送信を受信し、トラフィック挙動の変化に即座に反応するために、ダウンリンク制御シグナリングを永続的にモニターすることが有益である。同時に、これは、装置における電力消費の点でコストがかかる。装置の消費電力を低減するために、ＬＴＥは間欠受信（ＤＲＸ）のためのメカニズムを含む。
パケットデータは、しばしばバースト性が高く、時折無音の期間がある。遅延の観点から、アップリンク許可またはダウンリンクデータ送信を受信し、トラフィック挙動の変化に即座に反応するために、ダウンリンク制御シグナリングを永続的にモニターすることが有益である。同時に、これは、装置における電力消費の点でコストがかかる。装置の消費電力を低減するために、ＬＴＥは間欠受信（ＤＲＸ）のためのメカニズムを含む。
【0044】
現在規格化されているバージョンによるＰＤＣＣＨモニタリングに関する５Ｇ ＮＲにおける間欠受信（ＤＲＸ）機能の例示的な実現形態が、以下において簡単化及び省略された形式で説明される。
【0045】
ＤＲＸの基本的なメカニズムは、装置内の設定可能なＤＲＸ周期である。ＤＲＸ周期が設定されている場合、装置は、ダウンリンク制御シグナリングをＤＲＸ周期あたりのアクティブ期間のみモニターし、残りのオフ期間で受信回路がオフになった状態でスリープする。これにより、消費電力を大幅に削減することができる。当然ながら、これは、装置がアクティブ期間においてのみ対応可能であるため、スケジューラへの制限を意味する。
【0046】
ＵＥにおけるバッテリ消費を低減するため、ＵＥがＰＤＣＣＨを監視するのに費やす時間を最小限に抑える機構が利用され、これは、間欠受信（ＤＲＸ）機能と呼ばれる。ＤＲＸ機能は、ＲＲＣ＿ＩＤＬＥに対して設定でき、この場合、ＵＥは、特定のＤＲＸ値又はデフォルトのＤＲＸ値（ｄｅｆａｕｌｔＰａｇｉｎｇＣｙｃｌｅ）を利用する。デフォルトのページング周期はシステム情報において報知され、３２、６４、１２８、２５６個の無線フレームの値を有することができる。ＵＥは、ＤＲＸ周期毎に１つのページング機会においてウェイクアップする必要があり、ページング機会は、１サブフレームである。ＤＲＸ機能はまた。“ＲＲＣ＿ＣＯＮＮＥＣＴＥＤ”ＵＥに対して設定でき、これにより、ダウンリンク制御情報（又は単に、ＵＥはＰＤＣＣＨをモニタリングすると表現される）のダウンリンク制御チャネルを常にモニタリングする必要はない（３ＧＰＰ Ｔｅｃｈｎｉｃａｌ Ｓｔａｎｄａｒｄ ＴＳ３８．３２１ 「ＮＲ；ＭＡＣ（Ｍｅｄｉｕｍ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）プロトコル仕様書」、１５．６．０、ｃｈａｐｔｅｒ ５．７ を参照されたい）。
【0047】
以下のパラメータが、例えば、移動ノードがアクティブになるＯｎ－Ｄｕｒａｔｉｏｎ周期（すなわち、ＤＲＸ Ａｃｔｉｖｅ Ｔｉｍｅ）と、移動ノードがＤＲＸにある周期（すなわち、ＤＲＸ Ａｃｔｉｖｅ Ｔｉｍｅにない）とが、ＤＲＸ ＵＥの動作を規定するのに利用可能である。
【0048】
－ ｄｒｘ－ｏｎＤｕｒａｔｉｏｎＴｉｍｅｒ：ＤＲＸ周期の開始時の継続期間
－ ｄｒｘ－ＳｌｏｔＯｆｆｓｅｔ：ｄｒｘ－ｏｎＤｕｒａｔｉｏｎＴｉｍｅｒを開始する前の遅延
－ ｄｒｘ－ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒ：ＰＳＣＣＨがＭＡＹエンティティ用の最新のＵＬまたはＤＬ送信を示すＰＤＣＣＨ機会の後の継続期間
－ ｄｒｘ－ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒＤＬ（ブロードキャストプロセスを除くＤＬ ＨＡＲＱプロセス毎）：ＤＬ再送信が受信されるまでの最大継続期間
－ ｄｒｘ－ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒＵＬ（ＵＬ ＨＡＲＱプロセス毎）：ＵＬ再送信の許可が受信されるまでの最大継続期間
－ ｄｒｘ－ＬｏｎｇＣｙｃｌｅＳｔａｒｔＯｆｆｓｅｔ：ロングＤＲＸ周期およびショートＤＲＸ周期が開始するサブフレームを定義するロングＤＲＸ周期およびｄｒｘ－ＳｔａｒｔＯｆｆｓｅｔ
－ ｄｒｘ－ＳｈｏｒｔＣｙｃｌｅ（オプション）：ショートＤＲＸ周期
－ ｄｒｘ－ＳｈｏｒｔＣｙｃｌｅＴｉｍｅｒ（オプション）：ＵＥがショートＤＲＸ周期に従う継続期間
－ ｄｒｘ－ＨＡＲＱ－ＲＴＴ－ＴｉｍｅｒＤＬ（ブロードキャストプロセスを除くＤＬ ＨＡＲＱプロセス毎）：ＭＡＣエンティティにより期待されるＨＡＲＱ再送信用のＤＬ割り当て前の最小継続期間
－ ｄｒｘ－ＨＡＲＱ－ＲＴＴ－ＴｉｍｅｒＵＬ（ＵＬ ＨＡＲＱプロセス毎）：ＭＡＣエンティティにより期待されるＵＬ ＨＡＲＱ再送信許可前の最小継続期間
－ ｄｒｘ－ＳｌｏｔＯｆｆｓｅｔ：ｄｒｘ－ｏｎＤｕｒａｔｉｏｎＴｉｍｅｒを開始する前の遅延
－ ｄｒｘ－ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒ：ＰＳＣＣＨがＭＡＹエンティティ用の最新のＵＬまたはＤＬ送信を示すＰＤＣＣＨ機会の後の継続期間
－ ｄｒｘ－ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒＤＬ（ブロードキャストプロセスを除くＤＬ ＨＡＲＱプロセス毎）：ＤＬ再送信が受信されるまでの最大継続期間
－ ｄｒｘ－ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒＵＬ（ＵＬ ＨＡＲＱプロセス毎）：ＵＬ再送信の許可が受信されるまでの最大継続期間
－ ｄｒｘ－ＬｏｎｇＣｙｃｌｅＳｔａｒｔＯｆｆｓｅｔ：ロングＤＲＸ周期およびショートＤＲＸ周期が開始するサブフレームを定義するロングＤＲＸ周期およびｄｒｘ－ＳｔａｒｔＯｆｆｓｅｔ
－ ｄｒｘ－ＳｈｏｒｔＣｙｃｌｅ（オプション）：ショートＤＲＸ周期
－ ｄｒｘ－ＳｈｏｒｔＣｙｃｌｅＴｉｍｅｒ（オプション）：ＵＥがショートＤＲＸ周期に従う継続期間
－ ｄｒｘ－ＨＡＲＱ－ＲＴＴ－ＴｉｍｅｒＤＬ（ブロードキャストプロセスを除くＤＬ ＨＡＲＱプロセス毎）：ＭＡＣエンティティにより期待されるＨＡＲＱ再送信用のＤＬ割り当て前の最小継続期間
－ ｄｒｘ－ＨＡＲＱ－ＲＴＴ－ＴｉｍｅｒＵＬ（ＵＬ ＨＡＲＱプロセス毎）：ＭＡＣエンティティにより期待されるＵＬ ＨＡＲＱ再送信許可前の最小継続期間
【0049】
ＵＥが起動している総継続期間は、「アクティブ時間」またはＤＲＸアクティブ時間と称される。アクティブ時間は、例えば、以下の何れかの時間を含む。
－ ｄｒｘ－ｏｎＤｕｒａｔｉｏｎＴｉｍｅｒ、ｄｒｘ－ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒ、ｄｒｘ－ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒＤＬ、ｄｒｘ－ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒＵＬ、または、ｒａ－ＣｏｎｔｅｎｔｉｏｎＲｅｓｏｌｕｔｉｏｎＴｉｍｅｒ（３ＧＰＰ ＴＳ ３８．３２１の５．１．５節に記載されている）が実行中の時間
－ （３ＧＰＰ ＴＳ ３８．３２１の５．４．４節に記載されているように）スケジューリング要求がＰＵＣＣＨで送信され、ペンディングしている時間
－ （３ＧＰＰ ＴＳ ３８．３２１の５．１．４節に記載されているように）コンテンションベースのランダムアクセスプリアンブルのうち、ＭＡＣエンティティによって選択されていないランダムアクセスプリアンブル用のランダムアクセスレスポンスを正常に受信した後、ＭＡＣエンティティのＣーＲＮＴＩ宛の新しい送信を示すＰＤＣＣＨが受信されない時間
－ ｄｒｘ－ｏｎＤｕｒａｔｉｏｎＴｉｍｅｒ、ｄｒｘ－ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒ、ｄｒｘ－ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒＤＬ、ｄｒｘ－ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒＵＬ、または、ｒａ－ＣｏｎｔｅｎｔｉｏｎＲｅｓｏｌｕｔｉｏｎＴｉｍｅｒ（３ＧＰＰ ＴＳ ３８．３２１の５．１．５節に記載されている）が実行中の時間
－ （３ＧＰＰ ＴＳ ３８．３２１の５．４．４節に記載されているように）スケジューリング要求がＰＵＣＣＨで送信され、ペンディングしている時間
－ （３ＧＰＰ ＴＳ ３８．３２１の５．１．４節に記載されているように）コンテンションベースのランダムアクセスプリアンブルのうち、ＭＡＣエンティティによって選択されていないランダムアクセスプリアンブル用のランダムアクセスレスポンスを正常に受信した後、ＭＡＣエンティティのＣーＲＮＴＩ宛の新しい送信を示すＰＤＣＣＨが受信されない時間
【0050】
“ＤＲＸ期間”又は“ＤＲＸオフ期間”は、ＵＥがバッテリ節約目的のためにダウンリンクチャネルの受信をスキップすることが可能である、すなわち、ダウンリンクチャネルをモニタリングすることが必要とされないダウンリンクサブフレームの継続期間である。ＤＲＸの動作は、電力を節約するため、移動端末に（現在アクティブなＤＲＸ周期に従って）無線回路を繰り返し非アクティビティ化する機会を与える。ＵＥが実際にＤＲＸ期間中にＤＲＸに留まるか（すなわち、アクティブでない）否かは、ＵＥによって決定されてもよく、例えば、ＵＥは、Ｏｎ－Ｄｕｒａｔｉｏｎ期間には実行可能でない、従って、他の時間、例えば、ＤＲＸオフ時間中に実行される必要がある異周波測定を通常実行する。
【0051】
競合する要件を満たすため、２つのＤＲＸ周期（短い周期及び長い周期）が各ＵＥに対して設定することができ、短いＤＲＸ周期は任意選択的であり、すなわち、長いＤＲＸ周期のみを使用することができる。短いＤＲＸ周期、長いＤＲＸ周期及び連続受信の間の遷移は、タイマー又はｇＮＢからの明示的なコマンドによって制御される。ある意味において、短いＤＲＸ周期は、ＵＥが長いＤＲＸ周期に入る前に、遅いパケットが到着した場合における確認期間とみなすことができる。ＵＥが短いＤＲＸ周期にある間にデータがｇＮＢに到着した場合、データは、次のｏｎ－ｄｕｒａｔｉｏｎ時間における送信のためにスケジューリングされ、そして、ＵＥは連続受信を再開する。他方、短いＤＲＸ周期の間にｇＮＢにデータが到着しない場合、ＵＥは、パケットアクティビティが時間終了したと仮定して、長いＤＲＸ周期に入る。
【0052】
アクティブ時間中、ＵＥは、ＰＤＣＣＨをモニタリングし、設定されたＳＲＳ（Ｓｏｕｎｄｉｎｇ Ｒｅｆｅｒｅｎｃｅ Ｓｉｇｎａｌ）を報告し、ＰＵＣＣＨ上でＣＱＩ（Ｃｈａｎｎｅｌ Ｑｕａｌｉｔｙ Ｉｎｆｏｒｍａｔｉｏｎ）／ＰＭＩ（Ｐｒｅｃｏｄｉｎｇ Ｍａｔｒｉｘ Ｉｎｄｉｃａｔｏｒ）／ＲＩ（Ｒａｎｋ Ｉｎｄｉｃａｔｏｒ）／ＰＴＩ（Ｐｒｅｃｏｄｅｒ Ｔｙｐｅ Ｉｎｄｉｃａｔｉｏｎ）を報告する。ＵＥがアクティブ時間にないとき、タイプ０トリガされたＳＲＳ及びＰＵＣＣＨ上のＣＱＩ／ＰＭＩ／ＲＩ／ＰＴＩは報告されなくてもよい。ＣＱＩマスクがＵＥに設定される場合、ＰＵＣＣＨ上のＣＱＩ／ＰＭＩ／ＲＩ／ＰＴＩの報告は、Ｏｎ－Ｄｕｒａｔｉｏｎサブフレームに限定される。
【0053】
ＤＲＸ周期は、例えば、３ＧＰＰ ＴＳ ３８．３２１（「ＮＲ；Ｍｅｄｉｕｍ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ（ＭＡＣ）プロトコル仕様」、バージョン１５．６．０、セクション５．７）で接続モードが定義され、かつ、３ＧＰＰ ＴＳ ３８．３０４（「アイドルモードおよびＲＲＣインアクティブ状態でのユーザ装置（ＵＥ）手順」、バージョン１５．４．０、セクション７．１）で、アイドルまたはインアクティブ状態が定義されているように、受信機のスイッチを定期的にオフにすることによって、ＵＥに物理ダウンリンク制御チャネル（ＰＤＣＣＨ）をデコードしたり、特定の期間で物理ダウンリンク共有チャネル（ＰＤＳＣＨ）送信を受信したりする必要がないように、ＮＲダウンリンクに設定され得る。
【0054】
３ＧＰＰ ＴＳ ３８．３２１ ｖ１５．６．０仕様書によれば、ＤＲＸ周期が設定されるとき、アクティブ時間は、３ＧＰＰ ＴＳ ３８．３２１のセクション５．１．５に記載されるように、ｄｒｘ－ｏｎＤｕｒａｔｉｏｎＴｉｍｅｒ、ｄｒｘ－ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒ、ｄｒｘ－ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒＤＬ、ｄｒｘ－ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒＵＬ、またはｒａ－ＣｏｎｔｅｎｔｉｏｎＲｅｓｏｌｕｔｉｏｎＴｉｍｅｒが動作している時間を含む。
【0055】
ｄｒｘ－ｏｎＤｕｒａｔｉｏｎＴｉｍｅｒは、ＤＲＸ周期の開始時の継続時間を定義し、ｄｒｘ－ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒは、ＰＤＣＣＨがＭＡＣエンティティのための新しいアップリンク（ＵＬ）またはダウンリンク（ＤＬ）送信を示すＰＤＣＣＨ機会の後の継続時間を指定する。ｄｒｘ－ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒＤＬとＵＬは、ＤＬ再送を受信するまでの最大継続時間と、ＵＬ再送の許可を受信するまでの最大継続時間をそれぞれ定義する。
【0056】
ＨＡＲＱフィードバックによる間欠受信
ワイヤレスチャネルを介した送信は、例えば、受信信号の品質変動に起因する誤りを受けやすい。したがって、ワイヤレス通信システムは、送信された信号に冗長性を追加して、受信機が誤りを訂正することを可能にする、順方向誤り訂正（ＦＥＣ：ｆｏｒｗａｒｄ ｅｒｒｏｒ ｃｏｒｒｅｃｔｉｏｎ）の形態を使用することができる。しかしながら、誤って受信されたデータユニットがあり得る。ＨＡＲＱ（Ｈｙｂｒｉｄ Ａｕｔｏｍａｔｉｃ Ｒｅｐｅａｔ Ｒｅｑｕｅｓｔ）プロセスは、誤りデータユニットの誤り訂正符号化と再送信（ｒｅＴｘ）との組み合わせに依存し、多くの通信システムで使用される。
ワイヤレスチャネルを介した送信は、例えば、受信信号の品質変動に起因する誤りを受けやすい。したがって、ワイヤレス通信システムは、送信された信号に冗長性を追加して、受信機が誤りを訂正することを可能にする、順方向誤り訂正（ＦＥＣ：ｆｏｒｗａｒｄ ｅｒｒｏｒ ｃｏｒｒｅｃｔｉｏｎ）の形態を使用することができる。しかしながら、誤って受信されたデータユニットがあり得る。ＨＡＲＱ（Ｈｙｂｒｉｄ Ａｕｔｏｍａｔｉｃ Ｒｅｐｅａｔ Ｒｅｑｕｅｓｔ）プロセスは、誤りデータユニットの誤り訂正符号化と再送信（ｒｅＴｘ）との組み合わせに依存し、多くの通信システムで使用される。
【0057】
誤り訂正符号化にもかかわらず誤りのあるデータユニットは、送信機からの再送信を要求する受信機によって検出される。特に、肯定応答（ＡＣＫ：ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）メッセージまたは否定応答（ＮＡＣＫ：ｎｅｇａｔｉｖｅ ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）メッセージは、受信機によって送信され得る。ＮＡＣＫが送信される場合、スケジューリング装置は、データユニットの再送をスケジュールし、対応するＤＣＩを送信することができる。
【0058】
すなわち、ＰＤＣＣＨは、データの再送信のためのＤＣＩの受信のためにモニターされるべきである。これは、ＤＲＸ周期が受信機のために設定される場合にも当てはまる。
【0059】
以下では、本開示による送受信装置は、ＵＥとも呼ばれ得る。しかし、本開示は、ＵＥという用語を使用するが、ＬＴＥまたはＮＲにおけるＵＥに限定されず、任意の他の送受信装置に適用することができる。
【0060】
図７Ａは、ＨＡＲＱフィードバックによるＤＲＸ手順を示す。時間Ａにおいて、ＵＥは、設定されたＤＲＸ周期のアクティブ時間中に、新しいダウンリンク送信のためのＤＣＩを受信する。時間Ｂにおいて、対応するデータがＰＤＳＣＨを介してＵＥによって受信され、その後、受信されたデータがデコードされる。データが正常にデコードできなかった場合、時間ＣでＵＥからｇＮＢにＮＡＣＫメッセージが送信される。
【0061】
電磁波に基づくあらゆる信号送信には、光速に起因する信号送信遅延が生じる。特に、ソースと送り先との間の無線信号の一方向伝搬遅延の２つ分は、往復遅延（ＲＴＤ：ｒｏｕｎｄ ｔｒｉｐ ｄｅｌａｙ）と呼ばれる。ＲＴＤには、応答信号を生成するための処理ノードにおける処理時間も含まれ得る。
【0062】
このため、ＵＥは、ＮＡＣＫを送信した後、ＰＤＣＣＨのモニタリングを停止し、ｄｒｘ－ＨＡＲＱ－ＲＴＴ－ＴｉｍｅｒＤＬのタイマーを起動する。ｄｒｘ－ＨＡＲＱ－ＲＴＴ－ＴｉｍｅｒＤＬが満了していない限り、ＵＥは、電力消費を低減するためにＰＤＣＣＨをモニターしない。スリープ期間は、図７Ａにおいて斜線領域として示されている。
【0063】
時間Ｄにおいて、ｄｒｘ－ＨＡＲＱ－ＲＴＴ－ＴｉｍｅｒＤＬが満了し、ＵＥは、再びＰＤＣＣＨのモニタリングを開始し、その後、データの再送信のためにＤＣＩを受信する。時間Ｅにおいて、データは再び送信され、ＵＥによって受信される。受信データが正常にデコードできない場合、時間ＦでさらにＮＡＣＫが送信されてもよい。
【0064】
この手順では、再送信は、前に送信されたデータが正常に受信され、デコードされたかどうかについてのＵＥのフィードバックによってトリガされる。ＲＴＤによりデータの再送信のためのＤＣＩの送信が予想されない期間中、ＵＥは、電力消費を減少させるために、ＰＤＣＣＨがモニターされないスリープモードに入る。タイマーが満了し、再送信のためのＤＣＩの送信が予想され得ると、ＵＥは、ＰＤＣＣＨのモニターを再び開始する。
【0065】
図７Ｂは、アップリンクデータの送信のためのＨＡＲＱフィードバックを伴うＤＲＸ手順を示す。
【0066】
時間Ａにおいて、ＵＥは、設定されたＤＲＸ周期のアクティブ時間中に新しいアップリンク送信のためのＤＣＩを受信し、ｄｒｘ－ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒを開始する。時間Ｂにおいて、対応するデータは、ＰＤＳＣＨを介してＵＥによって送信される。
【0067】
ＵＬデータを送信した後、ＵＥは、ＰＤＣＣＨのモニターを停止し、ｄｒｘ－ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒＵＬ（実行中の場合）を停止し、ｄｒｘ－ＨＡＲＱ－ＲＴＴ－ＴｉｍｅｒＵＬのタイマーを開始する。ｄｒｘ－ＨＡＲＱ－ＲＴＴ－ＴｉｍｅｒＵＬが満了していない限り、ＵＥは、電力消費を低減するためにＰＤＣＣＨをモニターしない。スリープ期間は、図７Ｂにおいて斜線領域として示されている。
【0068】
時間Ｃにおいて、ｄｒｘ－ＨＡＲＱ－ＲＴＴ－ＴｉｍｅｒＵＬが満了し、ｄｒｘ－ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒＵＬが開始され、ＵＥは再びＰＤＣＣＨのモニターを開始する。その後、データの再送信のためのＤＣＩが受信される。時間Ｄにおいて、ＵＬデータが再び送信され、ｄｒｘ－ＨＡＲＱ－ＲＴＴ－ＴｉｍｅｒＵＬが再開され、ＵＥは、時間Ｅにおいてｄｒｘ－ＨＡＲＱ－ＲＴＴ－ＴｉｍｅｒＵＬが満了するまでＰＤＣＣＨのモニターを停止し、時間Ｆにおいてｄｒｘ－ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒＵＬが満了する。
【0069】
この手順では、再送信は、ＵＬデータの再送信のためのＤＣＩの受信によってトリガされる。ＲＴＤによりデータの再送のためのＤＣＩの送信が予想されない期間中、ＵＥは、電力消費を減少させるために、ＰＤＣＣＨがモニターされないスリープモードに入る。タイマーが満了し、再送信のためのＤＣＩの送信が予想され得ると、ＵＥは、ＰＤＣＣＨのモニターを再び開始する。
【0070】
非地上ネットワーク
３ＧＰＰでは、非地上ネットワーク（ＮＴＮ：ｎｏｎ－ｔｅｒｒｅｓｔｒｉａｌ ｎｅｔｗｏｒｋ）におけるＮＲベースの動作を研究し記述する（例えば、３ＧＰＰ ＴＲ ３８．８１１、非地上ネットワークをサポートするためのＮＲ（Ｎｅｗ Ｒａｄｉｏ）に関する研究、バージョン１５．０．０、および３ＧＰＰ ＴＲ ３８．８２１、非地上ネットワークをサポートするためのＮＲ用ソリューション、バージョン０．３．０を参照）。
３ＧＰＰでは、非地上ネットワーク（ＮＴＮ：ｎｏｎ－ｔｅｒｒｅｓｔｒｉａｌ ｎｅｔｗｏｒｋ）におけるＮＲベースの動作を研究し記述する（例えば、３ＧＰＰ ＴＲ ３８．８１１、非地上ネットワークをサポートするためのＮＲ（Ｎｅｗ Ｒａｄｉｏ）に関する研究、バージョン１５．０．０、および３ＧＰＰ ＴＲ ３８．８２１、非地上ネットワークをサポートするためのＮＲ用ソリューション、バージョン０．３．０を参照）。
【0071】
広いサービスカバレッジ能力と、物理的な攻撃や自然災害に対する宇宙／航空機の脆弱性の低減の結果、ＮＴＮは、地上のＮＲネットワークによってカバーできない非保護領域（例えば、航空機または船舶上の、隔離された、または離れた領域、）、および、非保護領域（例えば、郊外および地方の領域）において、ＮＲサービスの展開を促進することができる。さらに、ＮＴＮは、移動プラットフォーム上の乗客にサービス継続性を提供することによって、または、特に重要な通信のために、どこでもサービスの利用可能性を保証することによって、ＮＲサービスの信頼性を強化することができる。
【0072】
利点は、単独で動作する非地上ネットワーク、またはカバレッジ、ユーザ帯域幅、システム容量、サービス信頼性、または可用性に影響を及ぼし得る統合された地上ネットワークおよび非地上ネットワークのいずれかに関係する。
【0073】
非地上ネットワークは、例えば、サテライトに搭載されたＲＦリソースを使用する、ネットワークまたはネットワークのセグメントを指す。ＮＴＮは、通常、以下のシステム要素を特徴とする。
３ＧＰＰ ＵＥを指すＮＴＮ端末、または、サテライトが３ＧＰＰ ＵＥに直接サービスしない場合における、サテライトシステムに特有の端末
ユーザ装置と宇宙／空中プラットフォームとの間の無線リンクを指すサービスリンク
ペイロードを搭載する空中プラットフォーム
宇宙／空中プラットフォームをコアネットワークに接続するゲートウェイ
ゲートウェイセンター宇宙／空中プラットフォーム間の無線リンクを指すフィーダリンク
３ＧＰＰ ＵＥを指すＮＴＮ端末、または、サテライトが３ＧＰＰ ＵＥに直接サービスしない場合における、サテライトシステムに特有の端末
ユーザ装置と宇宙／空中プラットフォームとの間の無線リンクを指すサービスリンク
ペイロードを搭載する空中プラットフォーム
宇宙／空中プラットフォームをコアネットワークに接続するゲートウェイ
ゲートウェイセンター宇宙／空中プラットフォーム間の無線リンクを指すフィーダリンク
【0074】
往復遅延は、ソースノード、例えば、端末（ＵＥ）と送り先ノードとの間の距離に依存する。ＮＴＮでは、信号がサテライトなどを介して送信される場合があり、ＲＴＤの値は地上ネットワークよりもはるかに大きい場合がある。例えば、静止軌道上のサテライトを介して送信される信号の場合、すなわち、高度約３５７８６ｋｍにおいて、ＲＴＤは、５４１．１４ｍｓの大きさであってもよい。
【0075】
ＨＡＲＱフィードバックなしのブラインド再送信
データの高速かつ信頼性のある送信を保証するために、ＵＥからフィードバックを受信することなく、再送信が送信され得る。すなわち、ＵＥは、受信データを正常にデコードできなかった場合には、ｇＮＢにＮＡＣＫを送信しない場合がある。代わりに、ｇＮＢは設定された回数だけデータを再送することができる。
データの高速かつ信頼性のある送信を保証するために、ＵＥからフィードバックを受信することなく、再送信が送信され得る。すなわち、ＵＥは、受信データを正常にデコードできなかった場合には、ｇＮＢにＮＡＣＫを送信しない場合がある。代わりに、ｇＮＢは設定された回数だけデータを再送することができる。
【0076】
さらに、アップリンクデータ送信のために、ｇＮＢは、ＵＬデータの最初の送信を受信することなく、ＵＬの再送信のためのＤＣＩを送信することができ、その結果、ＵＥは、ＵＬデータのブラインド再送信を実行する。
【0077】
このアプローチでは、フィードバックループによるＲＴＤは発生せず、同時に、データ送信の信頼性は、複数の再送信によって増加する。
【0078】
ブラインド再送信とは、データの送り先、例えば、ＵＥにおける受信またはデコードの成功／失敗に関するフィードバックを受信することなく、データをさらに送信することを指す。
【0079】
ＨＡＲＱフィードバックは、例えば、ネットワークによって無効にすることができる。この場合、たとえば、ダウンリンクのためにｇＮＢにＡＣＫ／ＮＡＣＫが返されることはない。しかしながら、ＡＣＫ／ＮＡＣＫフィードバックがなくても、ｇＮＢは、設定されている場合、依然として再送信を送信することができる。言い換えれば、ｇＮＢは、データの過去の送信または再送信のためのＮＡＣＫを想定することができる。
【0080】
図８にｇＮＢでＮＡＣＫを受信しないデータの再送を示す。最初のステップとして、新しい送信のためのＤＣＩがＵＥに送信され、続いてデータ（ＤＬデータ）が送信される。その後、ｇＮＢはＮＡＣＫを想定し、さらにＤＣＩと対応するＤＬデータを送信する。言い換えれば、データは、ＵＥからフィードバックを受信することなく、ｇＮＢによって複数回（ＤＣＩの先行送信を伴って）送信され得る。
【0081】
ＨＡＲＱあり／なしのＤＲＸにおける再送信
図９にＤＲＸ周期を設定した場合のＤＬデータの再送信の処理を示す。図では、送信の時間的シーケンスが左から右に示されている。ＤＲＸ周期が設定される場合、ＵＥのオフ期間内にデータ及び対応するＤＣＩの再送信が行われないために、ＵＥは、新たな送信のためのＤＣＩが受信されると、ｄｒｘ－ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒを開始する。ｄｒｘ－ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒが満了していない限り、ＵＥは、ＤＬデータの受信のためにチャネルをモニターする。ＤＬデータが受信され、正常にデコードできない場合、ＵＥはｇＮＢにＮＡＣＫを送信し、ＲＴＤを考慮してｄｒｘ－ＨＡＲＱ－ＲＴＴ－ＴｉｍｅｒＤＬを起動する。
図９にＤＲＸ周期を設定した場合のＤＬデータの再送信の処理を示す。図では、送信の時間的シーケンスが左から右に示されている。ＤＲＸ周期が設定される場合、ＵＥのオフ期間内にデータ及び対応するＤＣＩの再送信が行われないために、ＵＥは、新たな送信のためのＤＣＩが受信されると、ｄｒｘ－ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒを開始する。ｄｒｘ－ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒが満了していない限り、ＵＥは、ＤＬデータの受信のためにチャネルをモニターする。ＤＬデータが受信され、正常にデコードできない場合、ＵＥはｇＮＢにＮＡＣＫを送信し、ＲＴＤを考慮してｄｒｘ－ＨＡＲＱ－ＲＴＴ－ＴｉｍｅｒＤＬを起動する。
【0082】
ｄｒｘ－ＨＡＲＱ－ＲＴＴ－ＴｉｍｅｒＤＬが満了していない限り、ＵＥは、電力消費を低減するためにＰＤＣＣＨをモニターしない。ｄｒｘ－ＨＡＲＱ－ＲＴＴ－ＴｉｍｅｒＤＬが満了した後、ｄｒｘ－ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒＤＬが開始され、上記のタイマーが満了していない限り、ＰＤＣＣＨは、ＤＬデータの再送信のためのＤＣＩの受信についてモニターされ、ＤＬデータは、その後に受信され得る。
【0083】
同様に、データがＵＥによってｇＮＢに送信され、ＤＲＸ周期が設定される場合、ＵＥは、ＵＬデータの最初の送信のためのＤＣＩが受信されると、ｄｒｘ－ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒを開始する。したがって、ＵＬデータを送信した後、ＲＴＤを考慮するために、ｄｒｘ－ＨＡＲＱ－ＲＴＴ－ＴｉｍｅｒＵＬが開始される。ｄｒｘ－ＨＡＲＱ－ＲＴＴ－ＴｉｍｅｒＵＬが満了していない限り、ＵＥは、電力消費を低減するためにＰＤＣＣＨをモニターしない。ｄｒｘ－ＨＡＲＱ－ＲＴＴ－ＴｉｍｅｒＵＬが満了した後、ｄｒｘ－ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒＵＬが開始され、上記のタイマーが満了していない限り、ＰＤＣＣＨは、ＵＬデータの再送信のためのＤＣＩの受信についてモニターされ、ＵＬデータは、その後に受信され得る。
【0084】
ＵＬデータの再送信のためのＤＬデータまたはＤＣＩの受信の成功／不成功に関するフィードバックがなければ、ＵＥは、過去の送信の後に、デコードに成功できなかったさらなる再送信が予想されるかどうかを認識しない。
【0085】
この場合、ｄｒｘ－ＨＡＲＱ－ＲＴＴ－ＴｉｍｅｒＤＬは、ｄｒｘ－ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒＤＬまたはｄｒｘ－ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒＵＬがすぐに開始するようにゼロに設定され得る。あるいは、前記タイマーは、ｄｒｘ－ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒＤＬ（またはＵＬ）が、直ちに、または最小処理時間が満了した後に開始するように、無効にされてもよい。
【0086】
ｄｒｘ－ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒＤＬは、図１０に示すように、ＤＬデータが正常にデコードできなかったときに開始することができる。図では、送信の時間的シーケンスが左から右に示されている。
【0087】
しかしながら、ＵＥがｄｒｘ－ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒＤＬまたはｄｒｘ－ＲｅｔｒａｎｓｍｉｓｓｉｎＴｉｍｅｒＵＬを開始し、ｇＮＢが再送信をスケジューリングしていない場合、ＵＥの電力消費は不必要に増加する。
【0088】
図１１は、ＤＣＩおよびＤＬデータがＵＥによって受信され、ＤＬデータがうまくデコードされ得なかった状況を示す。図では、送信の時間的シーケンスが左から右に示されている。ＨＡＲＱフィードバックがネットワークによって無効にされ、ｇＮＢがＤＬデータの再送信をスケジュールしなくても、ＵＥがｄｒｘ－ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒＤＬまたはｄｒｘ－ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒＵＬを開始する場合、ＵＥは、タイマーが動作している限りＰＤＣＣＨを不必要にモニターし、それによって電力消費を増加させる。
【0089】
一方、ＵＥが、新たな送信において受信されたＤＬデータのデコードに失敗した後に、ｄｒｘ－ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒＤＬを開始しない場合、ＵＥは、図１２に示すように、スリープ状態になり、ｇＮＢからの再送信を失敗する可能性がある。図では、送信の時間的シーケンスが左から右に示されている。
【0090】
本開示は、フィードバックなしのブラインド再送信のフレームワークにおいて調整されるモニタリングの継続時間を容易にすることができる技術を提供する。特に、本開示は、再送信の受信を確実にすると同時に、送受信装置の電力消費を低減するための、設定されたＤＲＸ周期における手順を提供する。
【0091】
本開示は、図１３に示されるような送受信装置およびスケジューリング装置を提供する。
【0092】
送受信装置１００は、送受信機１１０（１つ以上のアンテナなどのハードウェア構成要素およびハードウェア構成要素の操作を制御する制御回路を備える送信機および／または受信器）を備え、この送受信機は、動作中に、データのスケジュールされた送信を示す制御情報である物理ダウンリンク制御チャネルであるＰＤＣＣＨを介して制御情報を受信する。さらに、送受信装置１００は、動作中に、データのブラインド再送信の回数に従ってモニタリング期間を設定する回路１２０を備え、動作中に送受信機１１０は、モニタリング期間中にＰＤＣＣＨをモニターする。
【0093】
例えば、送受信装置１００は、ＮＲネットワークにおけるＵＥである。従って、送受信機１１０及び回路１２０は、「ＵＥ送受信機」及び「ＵＥ回路」とも呼ばれる。しかし、これらの用語は、単に、送受信機１１０および回路１２０を、スケジューリング装置２００または基地局などの他の装置によって構成される回路および送受信機と区別するために使用される。送受信装置１００は、端末サービス、中継装置、または同様の通信システムの通信装置とすることができる。ＵＥ回路１２０は、「モニタリング期間制御回路」と見なされるか、または「モニタリング期間制御回路」を含むと見なされてもよい。
【0094】
さらに、図１３に示すようなスケジューリング装置２００（またはスケジューリングノード）が提供される。
【0095】
スケジューリング装置２００は、動作中に、データのブラインド再送信の回数を決定する回路２２０を備える。スケジューリング装置２００は、動作中に、物理ダウンリンク制御チャネルであるＰＤＣＣＨを介して制御情報を送信する送受信機２１０をさらに備え、制御情報は、ブラインド再送信の回数に従って、データのスケジュールされた送信または再送信を示す。
【0096】
例えば、スケジューリング装置２００は、ＮＲネットワークシステム（ｇＮＢ）内または同様の通信システム内のネットワークノード（基地局）である。回路２２０は、ＵＥ回路１２０のような回路と区別するために、「再送信制御回路」又は「スケジューリング装置回路」とも呼ばれる。
【0097】
物理ダウンリンク制御チャネル（ＰＤＣＣＨ）を介してデータのスケジュールされた送信を示す制御情報を受信することと、データのブラインド再送信の回数に従ってモニタリング期間を設定することとを含む方法がさらに提供され、ＰＤＣＣＨは、モニタリング期間中にモニターされる。
【0098】
さらなる説明では、詳細および実施形態は、明示的な記載または文脈がそうでないことを示さない限り、送受信装置１００、スケジューリング装置２００（またはスケジューリングノード）、および方法のそれぞれに適用される。
【0099】
【0100】
この実施形態では、送受信機１１０がデータの最初の送信用のＤＣＩ（制御情報）を受信したときにタイマーを開始することによって、回路１２０によってモニタリング期間が設定される。タイマー値、すなわち、タイマーのランタイムは、送受信機１１０が設定された回数の再送信のすべてを受信するのに十分である。さらなるＤＣＩ、例えば、再送信のためのＤＣＩが受信されると、タイマーは開始されない。再送信用のＤＣＩは、第２制御情報と呼ばれることがある。再送信の全ラウンド中にスリープ時間がないので、ｄｒｘ－ＨＡＲＱ－ＲＴＴ－ＴｉｍｅｒＤＬ（またはＵＬ）を使用する必要がない。そのため、ＵＥ１００は、ＨＡＲＱフィードバックがＵＥ１００からｇＮＢ２００に送信されない。
【0101】
ブラインド再送信が実行されるか否かは、半静的にまたは動的に設定することができ、それに応じて、モニタリング期間の継続時間に対応するタイマーのランタイムも、半静的にまたは動的に設定することができる。ブラインド送信が半静的な方法で設定される場合、ＲＲＣ信号は、タイマーのランタイム値の設定のために利用され得る。ブラインド再送信が動的な方法で構成される場合、タイマーのランタイム値は、例えば、ＤＣＩまたはＭＡＣ制御要素（ＭＡＣ ＣＥ）を介して、同様に動的な方法で設定することができる。例えば、ブラインド再送信が設定されているかどうかを示すために、１ビットが使用されることがある。例えば、ゼロの値は、ブラインド再送信が設定されていないことを示し、１の値は、ブラインド再送信が設定されていることを示す可能性がある。タイマーのランタイムのシグナリング、またはＲＲＣ、ＭＡＣ ＣＥ、またはＤＣＩによる再送信の回数の詳細は、以下に記載されている。
【0102】
言い換えれば、本実施形態によれば、ＵＥ１００は、再送信が予想される期間を認識している。このモニタリング期間中、ＰＤＣＣＨは、再送信のためにＤＣＩについてモニターされる。
【0103】
この実施形態によれば、モニタリング期間を設定するために単一のタイマーを利用することができ、送受信機１１０はＰＤＣＣＨをモニターする。これは、例えば、ＮＴＮにおいて、長いＲＴＤを補償するために、フィードバック（ＨＡＲＱ）なしの高速再送信を可能にする。
【0104】
以下、図１４および図１５を参照して、本実施の形態の第１変形例について説明する。図１４は、ｄｒｘ－ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒを利用してモニタリング期間を設定した場合の、ｇＮＢ２００（スケジューリング装置）とＵＥ１００（送受信装置）との間の送信の時系列を示す。図１５は、ｄｒｘ－ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒを利用してモニタリング期間が設定される場合にＵＥ１００によって実行される方法のステップを示す。
【0105】
ステップＳ１００において、送受信装置１００、またはより具体的には、ＵＥ送受信機１１０は、設定されたＤＲＸ周期のアクティブ時間中に、ｇＮＢからのダウンリンク（ＤＬ）データの最初の送信用のＤＣＩを受信する。新しい送信用のＤＣＩを受信した後、回路１２０は、ｄｒｘ－ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒを開始することによってモニタリング期間を開始し、これにより、送受信機１１０は、ブラインド送信のためにチャネルをモニターする。
【0106】
さらに、ステップＳ１１０において、ｄｒｘ－ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒが実行中であるか否かが判定される。すなわち、ＵＥ１００がアクティブ時間であるか否かが判定される。ｄｒｘ－ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒが実行中でない場合（ステップＳ１１０、ＮＯ）、本方法は終了する。しかしながら、ＵＥがアクティブ時間にあると判定された場合、送受信機１１０は、ステップＳ１２０において、ブラインド再送信のためにチャネルをモニターする。
【0107】
さらに、ＤＬデータが受信されると、それは回路１２０によってデコードされる。ステップＳ１３０では、受信したデータが正常にデコードできたか否かが判定される。受信データのデコードに成功した場合（ステップＳ１３０、ＹＥＳ）、本方法は終了する。しかし、データが正常にデコードされなかった場合、方法はステップＳ１１０に進み、ｄｒｘ－ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒのタイマーがまだ実行中であるかどうかが判定される。
【0108】
ただし、ＰＤＳＣＨ送信が正常にデコードされた場合（つまり、ＤＬデータが正常にデコードされた場合）、この特定のＨＡＲＱプロセスでＰＤＣＣＨをモニターする必要はない。しかしながら、ＵＥ１００は、受信される他の送信についてＰＤＣＣＨをモニターし続けてもよい。
【0109】
さらに、ｄｒｘ－ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒは、再送信のフレームワークで受信されたデータが正常にデコードされると終了しない可能性があるが、それぞれのランタイムの後に満了し得る。
【0110】
以下、図１６および図１７を参照して、本実施形態の第２変形例について説明する。図１６は、ｄｒｘ－ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒを利用してモニタリング期間を設定した場合の、ｇＮＢ２００（スケジューリング装置）とＵＥ１００（送受信装置）との間の送信の時系列を示す。図１７は、ｄｒｘ－ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒを利用してモニタリング期間が設定される場合にＵＥ１００によって実行される方法のステップを示す。
【0111】
本実施形態のこの変形例では、ＵＥ１００は、最初の送信において送信されたデータをデコードした後に、ｄｒｘ－ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒを開始する。図１６に見られるように、ｄｒｘ－ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒは、設定されたＤＲＸ手順に従って、最初の送信用のＤＣＩの受信の後に開始される。さらに、対応するＤＬデータが受信され、デコードされると、ＤＬデータのデコードにエラーが発生したときに、ｄｒｘ－ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒが開始される。
【0112】
上述の変形例と同様に、ｄｒｘ－ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒのランタイムは、例えば、ＲＲＣ、ＭＡＣ ＣＥまたはＤＣＩを介してｇＮＢによって信号を送られる設定に従って設定され、設定された再送信をカバーするモニタリング期間を保証することができる。再送信のタイマーはＨＡＲＱプロセス毎であるため、ＵＥ１００が正常に受信データをデコードすると停止する場合がある。
【0113】
図１７のステップＳ２００では、ＤＬデータの最初の送信のためのＤＣＩを受信し、それぞれのＤＬデータを受信した後、データをデコードし、デコードが成功しなかった場合には、ｄｒｘ－ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒを起動する。
【0114】
ステップＳ２１０において、ＵＥ１００がアクティブ時間にあるかどうかが判定される。すなわち、ｄｒｘ－ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒが実行中であるか否かが判定される。ＵＥ１００がアクティブ時間でない場合（ステップＳ２１０、ＮＯ）、本方法は終了する。一方、ｄｒｘ－ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒが実行中である、すなわち、ＵＥ１００がアクティブ時間にないと判定された場合、ステップＳ２２０に進む。
【0115】
ステップＳ２２０で、ＰＤＣＣＨは、ＤＬデータのブラインド再送信用のＤＣＩについてモニターされ、ＤＣＩが受信されると、それに応じて対応するＤＬデータが受信される。
【0116】
ステップＳ２３０において、受信されたデータは、回路１２０によってデコードされ、受信されたＤＬデータのデコードが成功したか否かが判定される。ＤＬデータが正常にデコードできなかった場合（ステップＳ２３０、ＮＯ）、ステップＳ２１０に進み、ｄｒｘ－ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒが（まだ）実行中であるかどうかを再度判定する。そうでない場合、すなわち、受信されたデータが正常にデコードされたと判定された場合（ステップＳ２３０、ＹＥＳ）、ステップＳ２４０に進む。
【0117】
ステップＳ２４０において、現在のＨＡＲＱプロセスに対応するｄｒｘ－ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒが停止し、その後、本方法は終了する。
【0118】
ＤＬデータがうまくデコードされた後、ｄｒｘ－ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒは終了されるが、本開示は、それに限定されず、上記のタイマーは、その設定されたランタイムの後に満了することができる。
【0119】
本実施形態の記載された変形例では、単一のタイマーが、ブラインド再送信用のＤＣＩの受信のためにＰＤＣＣＨがモニターされるモニタリング期間を設定するために利用される。特に、モニタリング期間の継続時間は、全てのブラインド再送信をカバーするように構成される。
【0120】
モニタリング期間を実現するタイマーとしては、ｄｒｘ－ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒやｄｒｘ－ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒを用いることができる。ｄｒｘ－ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒとは対照的に、ｄｒｘ－ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒは、複数のＨＡＲＱプロセスまたはデータ受信プロセスのそれぞれに対して開始され得ることに留意されたい。すなわち、ｄｒｘ－ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒは、対応するＤＬデータがうまくデコードされた後に終了されてもよい。一方、ｄｒｘ－ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒは、それ以上のＨＡＲＱプロセスがアクティブでない場合にのみ終了することができる。
【0121】
なお、本開示は、モニタリング期間を設定するためにｄｒｘ－ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒやｄｒｘ－ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒを利用することに限定されず、他のタイマーを用いてもよい。例えば、新しいタイマーを導入することができる。
【0122】
図１８～図２２を参照して以下に説明されるさらなる実施形態では、ＵＥ送受信機１１０は、再送信用のモニタリング期間を定義するタイマーの終了を示す終了インジケータをさらに受信する。続いて、回路１２０は、終了インジケータが受信されると、モニタリング期間を終了する。
【0123】
上述の実施形態と同様に、モニタリング期間の継続時間、またはより具体的には、再送のためにＰＤＣＣＨをモニターする期間の継続時間を定義するタイマーのランタイムは、例えば、ＲＲＣ、ＭＡＣ ＣＥまたはＤＣＩ信号によって設定されてもよい。
【0124】
例えば、モニタリング期間は、タイマーを停止する明示のインジケーション（指示）が受信されたときに終了されてもよい。これは、例えば、ＤＬの最後の再送信またはＵＬデータの送信の受信時に、ＭＡＣ ＣＥを介して実行されてもよい。
【0125】
代替的に、暗黙のインジケーションは、回路１３０をトリガしてタイマーを停止させ、したがって、ＰＤＣＣＨをモニターするためのモニタリング期間を終了させることができる。例えば、モニタリング期間を終了する暗黙のインジケーションは、最後のＰＤＣＣＨ送信における最後の送信のインジケーションとして実装することができ、ここで、それが最後の再送信であるか否かを示すために１ビットを使用することができる。例えば、最後のビット値１は最後の再送信を示し得るが、最後のビット値０はさらなる再送信を示し得る。この場合、ＵＥ１００は、受信した最後のビットが１の値を示す場合、モニタリング期間を終了する。
【0126】
このアプローチでは、追加のシグナリングが必要とされる場合であっても、ＵＥは、最後のＤＣＩが受信されたときにそれぞれのタイマーを停止することによってモニタリング期間を終了することができ、それによって、ＰＤＣＣＨの不必要なモニターを防止し、したがって、装置の電力消費を低減する。
【0127】
第１変形例では、ｄｒｘ－ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒが無効にされる。言い換えれば、ＵＥは、受信されたデータが正常にデコードされなかった場合に、ｄｒｘ－ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒを開始または再開しない。代わりに、ｄｒｘ－ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒは、最初の送信において受信されたデータのデコードが正常にデコードされ得なかったときに開始される。また、モニタリング期間の終了を示すインジケータ（終了インジケータ）を受信した場合には、各ｄｒｘ－ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒを停止させることにより、モニタリング期間を終了する。この手順を図１８および１９に示す。
【0128】
図１８は、ｄｒｘ－ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒを利用してモニタリング期間を設定し、終了インジケータを受信した場合の、ｇＮＢ２００（スケジューリング装置）とＵＥ１００（送受信装置）との間の送信の時系列を示す。図１９は、ｄｒｘ－ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒを利用してモニタリング期間が設定され、終了インジケータが受信されるときにＵＥ１００によって実行される方法のステップを示す。
【0129】
ステップＳ３００において、最初のＰＤＣＣＨ送信が受信され、ｄｒｘ－ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒが開始される。
【0130】
ステップＳ３１０において、ＵＥがアクティブ時間にあるかどうかが判定される。すなわち、ｄｒｘ－ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒが満了したか否かを判定する。さらに、モニタリング期間の終了を示す終了インジケータが受信されたかどうかが判定される。終了インジケータは、上述のように、明示的または暗黙的に送信されてもよい。ＵＥ１００がアクティブ時間にないか、または終了インジケータが受信された場合（ステップＳ３１０、ＹＥＳ）、方法は終了する。一方、ＵＥ１００がアクティブ時間であり、終了インジケータを受信していない場合（ステップＳ３１０、ＮＯ）、処理はステップＳ３２０に進む。
【0131】
ステップＳ３２０において、ＵＥ１００は、ＤＬデータの再送信のためのＤＣＩの受信のためのＰＤＣＣＨをモニターする。すなわち、ＰＤＣＣＨは、第２制御情報の受信についてモニターされる。ＤＬデータを受信すると、ステップＳ３３０で、受信したデータが正常にデコードできたか否かが判断される。ＰＤＳＣＨを介して受信されたデータが正常にデコードされることができた場合（ステップＳ３３０、ＹＥＳ）、方法は終了する。一方、受信データのデコードに成功しなかった場合（ステップＳ３３０、ＮＯ）、ステップＳ３１０に進む。
【0132】
ＵＥが受信データを正常にデコードした場合でも、ｄｒｘ－ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒが満了するか、ｇＮＢから明示／暗黙のインジケーションが受信されるまで、ＰＤＣＣＨはさらにモニターされることに注意する。上述の方法における「終了」は、すべてのタイマーの終了を意味しない。
【0133】
さらに、モニタリング期間の終了を示す終了インジケータは、ＵＬデータのブラインド再送信用の対応する手順において、ＵＥ１００によって受信され得ることに留意されたい。
【0134】
第２変形例では、ＤＬデータの最初の送信のためのＤＣＩが受信されると、ｄｒｘ－ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒが開始される。さらに、モニタリング期間は、最初の送信で受信されたデータがデコードされたときにｄｒｘ－ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒを開始することによって開始される。さらに、ｄｒｘ－ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒは、暗黙または明示のインジケーションの受信時に停止される。この手順を図２０および２１に示す。
【0135】
図２０は、ｄｒｘ－ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒを利用してモニタリング期間を設定し、終了インジケータを受信した場合の、ｇＮＢ２００（スケジューリング装置）とＵＥ１００（送受信装置）との間の送信の時系列を示す。図２１は、ｄｒｘ－ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒを利用してモニタリング期間が設定され、終了インジケータが受信されるときにＵＥ１００によって実行される方法のステップを示す。
【0136】
ＤＬデータの最初の送信のためのＤＣＩを受信した後、ｄｒｘ－ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒは、設定されたＤＲＸプロセスに従って開始される。さらに、対応するＤＬデータはＰＤＳＣＨを介して受信され、デコードされる。
【0137】
ステップＳ４００では、受信データが正常にデコードできなかった場合、すなわち、最初の送信においてＰＤＳＣＨのデコードエラーが発生した場合に、ｄｒｘ－ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒが開始される。
【0138】
ステップＳ４１０において、ＵＥ１００がアクティブ時間にあるか否かが判定される。すなわち、ｄｒｘ－ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒが実行中であるか否かが判定される。また、モニタリング期間の終了を示す終了インジケータを受信したか否かを判定する。ＵＥ１００がアクティブ時間にない場合、または終了インジケータが受信された場合（ステップＳ４１０、ＹＥＳ）、ステップＳ４４０に進む。一方、ＵＥがアクティブ時間にあり、終了インジケータが受信されていない場合、ステップＳ４２０に進む。
【0139】
ステップＳ４２０で、ＰＤＣＣＨは、ＤＬデータの再送信用のＤＣＩについてモニターされる。
【0140】
受信されたＤＣＩに従ってＤＬデータが受信されると、ステップＳ４３０において、受信されたデータが正常にデコードされたか否かが判断される。正常に受信データがデコードされなかった場合（ステップＳ４３０、ＮＯ）、ステップＳ４１０に進む。一方、正常に受信データがデコードされた場合（ステップＳ４３０、ＹＥＳ）、ステップＳ４４０に進む。
【0141】
ステップＳ４４０において、現在のＨＡＲＱプロセスに対応するｄｒｘ－ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒが終了し、本方法は終了する。
【0142】
実施形態の記載された変形例では、ＰＤＣＣＨが第２制御情報のためにモニターされるモニタリング期間を定義するタイマーを停止するための明示または暗黙のインジケーション（終了インジケータ）が受信される。終了インジケータを受信すると、モニタリング期間は、それぞれのタイマーを停止することによって終了される。
【0143】
このアプローチでは、ｇＮＢ２００は、例えば、ＤＬデータのさらなる再送信が意図されておらず、その結果、ＵＥの電力消費が低減されるときに、モニタリング期間の終了をアクティブにトリガすることができる。
【0144】
さらなる実施形態では、ｇＮＢ２００は、モニタリング期間の継続時間を示す継続インジケータを送信する。例えば、モニタリング期間の継続時間は、専用タイマーのランタイムとして示されてもよい。また、ｇＮＢ２００は、再送信回数を示す再送信インジケータをＵＥ１００に送信する。
【0145】
ＵＥ１００は、ランタイム値を受信し、再送信回数を示すと、実際のタイマーのランタイム値を再送信回数の倍数として拡張する。すなわち、ｇＮＢ２００によって一定回数の再送信が示され、あるタイマーのランタイム値が設定されている場合には、設定されているランタイムと再送回数との乗算によって、モニタリング期間の継続時間の定義専用のタイマーのランタイムが算出される。最初の送信を受信した後、ＵＥ１００は、計算された拡張ランタイム値を用いてタイマーを開始する。
【0146】
特に、再送信の回数が（例えば、ＲＲＣを介して）半静的に設定されるか、または（例えば、ＭＡＣ ＣＥまたはＤＣＩを介して）動的に設定されるかに応じて、ブラインド再送信の回数はまた、半静的にまたは動的に示され得る。
【0147】
このアプローチでは、モニタリング期間は、最後の送信が受信されたときに終了することができる。
【0148】
異なるＨＡＲＱプロセスは、ブラインド再送信の回数およびＤＲＸタイマーの値（例えば、ｄｒｘ－ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒおよびｄｒｘ－ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒ）とは独立して設定され得ることに留意されたい。ブラインド再送信およびＤＲＸタイマーの動的値は、例えば、ＤＣＩシグナリングを介して設定することができる。
【0149】
第１変形例では、ＵＥ１００が再送信の受信時にｄｒｘ－ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒを開始しないように、ｄｒｘ－ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒは無効にされる。代わりに、ｄｒｘ－ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒは、最初のＰＤＣＣＨ送信が受信されたときに計算されたランタイムで開始される。タイマーは、最後の再送信が受信され、別のＨＡＲＱプロセスのためにインアクティビティタイマーが実行されていないと判定されたときに停止されてもよい。なお、本開示は、タイマーが停止されることに限定されるものではなく、タイマーが満了するまで実行されてもよい。この手順の詳細については、図２２を参照して説明する。
【0150】
ステップＳ５００では、ブラインド再送信回数を示す再送信インジケータを受信する。さらに、ｄｒｘ－ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒのランタイムを示す継続インジケータが、ＵＥ１００によって受信される。
【0151】
ステップＳ５１０において、ｄｒｘ－ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒの新しいランタイム値が、ｄｒｘ－ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒの設定されたランタイム値とブラインド再送信の回数との積として計算される。
【0152】
ステップＳ５２０において、最初のＰＤＣＣＨ送信が受信され、ｄｒｘ－ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒが、新たに計算されたランタイムで開始される。
【0153】
ステップＳ５３０において、ＵＥ１００がアクティブ時間にあるかどうかが判定される。すなわち、ｄｒｘ－ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒが実行中であるか否かを判定する。ｄｒｘ－ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒが実行中でない、すなわち、ＵＥ１００がアクティブ時間にないと判定された場合（ステップＳ５３０、ＮＯ）、処理は終了する。ＵＥ１００がアクティブ時間にあると判定された場合、ステップＳ５４０に進む。
【0154】
ステップＳ５４０で、ＰＤＣＣＨは、ＤＬデータの再送信用のＤＣＩの受信（第２制御情報）についてモニターされる。
【0155】
上記のＤＣＩ及び各ＤＬデータを受信した場合、ステップＳ５５０で、受信したＤＬデータが正常にデコードできたか否かが判断される。ＰＤＳＣＨを介して受信したＤＬデータが正常にデコードできた場合（ステップＳ５５０、ＹＥＳ）、本方法は終了する。受信したＤＬデータを正常にデコードできなかったと判定した場合には、ステップＳ５６０に移行する。
【0156】
ステップＳ５６０では、ブラインド再送信回数が終了したか否かが判定される。言い換えれば、ＵＥ１００は、受信されたブラインド再送信の回数を追跡し、この回数を、ステップＳ５００で受信されたブラインド再送信の指示された回数と比較する。ブラインド再送信の回数が終了していない場合（ステップＳ５６０、ＮＯ）、さらに再送信が予想されるので、処理はステップＳ５３０に進む。一方、ブラインド再送信の回数が終了した場合（ステップＳ５６０、ＹＥＳ）、ステップＳ５７０に進む。
【0157】
ステップＳ５７０において、ｄｒｘ－ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒが別のＨＡＲＱプロセスのために実行されているかどうかが判定される。他のＨＡＲＱ処理によりｄｒｘ－ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒが動作していない場合（ステップＳ５７０、ＮＯ）、タイマーを停止し、本方法を終了する。ｄｒｘ－ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒが別のＨＡＲＱプロセスのために実行されている場合、ステップＳ５３０に進む。
【0158】
第２変形例では、ｄｒｘ－ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒは、最初の送信からのデータのデコード中にエラーが発生したときに、計算されたランタイム値で開始される。上記のタイマーは、ブラインド再送信で受信されたデータが正常にデコードされた場合、または指示された再送信回数の後に停止されてもよい。この手順の詳細については、図２３を参照して説明する。
【0159】
ステップＳ６００において、再送信インジケータは、ブラインド再送信の回数を示す。さらに、モニタリング期間の継続時間を示す継続インジケータが受信される。例えば、継続インジケータは、ｄｒｘ－ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒのランタイム値を示すことができる。
【0160】
ステップＳ６１０において、ｄｒｘ－ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒの新しいランタイム値が、ｄｒｘ－ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒの受信されたランタイム値とブラインド再送信の回数との積として計算される。
【0161】
ステップＳ６２０で、最初のＰＤＣＣＨ送信が受信され、計算されたランタイムでｄｒｘ－ｒｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒが開始される。
【0162】
ステップＳ６３０において、ＵＥ１００がアクティブ時間にあるかどうかが判定される。すなわち、ｄｒｘ－ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒが動作しているか否かを判定する。ｄｒｘ－ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒが実行中でない、すなわち、ＵＥ１００がアクティブ時間にないと判定された場合（ステップＳ６３０、ＮＯ）、処理は終了する。ＵＥ１００がアクティブ時間にあると判定された場合、ステップＳ６４０に進む。
【0163】
ステップＳ６４０では、ＰＤＣＣＨは、ＤＬデータ（第２制御情報）の再送信用のＤＣＩの受信をモニターする。
【0164】
上記のＤＣＩ及び各ＤＬデータを受信した場合、ステップＳ６５０で、受信したＤＬデータを正常にデコードできたか否かが判断される。ＰＤＳＣＨを介して受信したＤＬデータを正常にデコードした場合（ステップＳ６５０、ＹＥＳ）、処理はステップＳ６７０に進む。受信したＤＬデータを正常にデコードできなかったと判定された場合、処理はステップＳ６６０に進む。
【0165】
ステップＳ６６０では、ブラインド再送信の回数が終了したか否かが判定される。言い換えれば、ＵＥ１００は、受信されたブラインド再送信の回数を追跡し、上記の回数を、ステップＳ６００で受信されたブラインド再送信の指示された回数と比較する。ブラインド再送信の回数が終了していない場合（ステップＳ６６０、ＮＯ）、さらに再送信が予想できるので、ステップＳ６３０に進む。一方、ブラインド再送信の回数が終了した場合（ステップＳ６６０、ＹＥＳ）、ステップＳ６７０に進む。
【0166】
ステップＳ６７０において、現在のＨＡＲＱプロセスに対応するｄｒｘ－ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒが停止され、その後、処理は終了する。
【0167】
上述した実施形態の変形例によれば、ｇＮＢは、ＵＥ１００に再送信の回数を示す再送信インジケータを送信する。さらに、専用タイマーのランタイムを示す継続インジケータが、ＵＥ１００によって受信される。ＵＥ１００は、その後、ブラインド再送信の指示された回数に比例するように、モニタリング期間の継続時間を計算する。具体的には、モニタリング期間の継続時間は、指示されたブラインド再送信の回数と、それぞれのタイマーの指示されたランタイムとの積として設定される。
【0168】
さらなる実施形態では、モニタリング期間は、送受信装置１００（ＵＥ）の送受信機１１０が、データのブラインド再送信についてＤＣＩについてＰＤＣＣＨをモニターする、１つ以上の部分的なモニタリング期間を設定することによって設定される。これは、例えば、受信されたＤＣＩがデータの最初の送信に関連するか、または上記データのブラインド再送信に関連するかにかかわらず、ＤＣＩがＰＤＣＣＨを介して受信されるときはいつでも、専用タイマーを再開することによって実行される。
【0169】
なお、部分的なモニタリング期間は、ＤＣＩを受信した直後であってもよいし、ＰＤＳＣＨを介して受信したＤＬデータをデコードした後であってもよい。
【0170】
この実施形態では、タイマーのランタイム値は、ＵＥ１００が次の再送信を受信するときにアクティブ時間にあるのに十分であるように設定される。
【0171】
正常に受信データをデコードしなかった後にそれぞれのタイマーをスタートさせ、上記のデータを正常にデコードした場合にそれぞれのタイマーをスタートさせない場合、ＵＥ１００の電力消費を低減することができ、同時に、必要に応じてブラインド再送信が受信されることが保証される。
【0172】
第１変形例によれば、ｄｒｘ－ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒは、ＵＥ１００が再送信を受信したときにｄｒｘ－ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒを開始または再開しないように無効にされる。代わりに、ｄｒｘ－ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒは、送信または再送信が受信されるたびに開始される。この手順の詳細は、図２４および図２５を参照して説明される。
【0173】
図２４は、ｄｒｘ－ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒを用いて部分的なモニタリング期間を設定することによってモニタリング期間を設定した場合の、ｇＮＢ２００（スケジューリング装置）とＵＥ１００（送受信装置）との間の送信の時系列を示す。図２５は、ｄｒｘ－ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒを使用して部分的なモニタリング期間を設定することによってモニタリング期間が設定される場合にＵＥ１００によって実行される方法のステップを示す。
【0174】
図２４に示すように、ＰＤＣＣＨ送信または再送信がＵＥ１００によって受信されるたびに、ｄｒｘ－ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒが開始される。受信されたデータが正常にデコードされ得る場合（図２４に示される最後の送信に対するＡＣＫ）、ｄｒｘ－ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒは再開されない。
【0175】
図２５に示すように、ステップＳ７００において、ＵＥ１００がアクティブ時間にあるかどうかが判定される。すなわち、ｄｒｘ－ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒが実行中であるか否かを判定する。ｄｒｘ－ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒが実行中でない場合（ステップＳ７００、ＮＯ）、本方法は終了する。ｄｒｘ－ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒが実行中である場合（ステップＳ７１０、ＹＥＳ）、ステップＳ７１０に進む。
【0176】
ステップＳ７１０において、ＰＤＣＣＨは、ＤＬデータのブラインド再送信用のＤＣＩの受信についてモニターされる。
【0177】
ＤＣＩとそれぞれのＤＬデータを受信すると、ステップＳ７２０で、受信したＤＬデータが正常にデコードできたか否かが判断される。ＰＤＳＣＨを介して受信したデータがデコードできた場合（ステップＳ７２０、ＹＥＳ）、本方法は終了する。受信したＤＬデータを正常にデコードできなかった場合（ステップＳ７２０、ＮＯ）、ステップＳ７３０に進む。
【0178】
ステップＳ７３０において、ＤＬデータのブラインド再送信用のＤＣＩがＰＤＣＣＨを介して受信されるとすぐに、ｄｒｘ－ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒが再開され、ステップＳ７００に進む。
【0179】
第２変形例によれば、ＵＥ１００は、再送信において受信されたデータが正常にデコードされ得ないたびに、ｄｒｘ－ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒを開始する。この手順の詳細は、図２６および図２７を参照して説明される。
【0180】
図２６は、ｄｒｘ－ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒを用いて部分的なモニタリング期間を設定することによってモニタリング期間を設定した場合の、ｇＮＢ２００（スケジューリング装置）とＵＥ１００（送受信装置）との間の送信の時系列を示す。図２７は、ｄｒｘ－ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒを使用して部分的なモニタリング期間を設定することによってモニタリング期間が設定される場合にＵＥ１００によって実行される方法のステップを示す。
【0181】
図２６から分かるように、ＤＬデータの新たな送信用のＤＣＩが受信されると、ｄｒｘ－ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒは、例えば、設定されたＤＲＸプロセスに従って開始される。それぞれのＤＬデータが受信され、正常にデコードできなかった場合、ｄｒｘ－ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒが開始され、ＤＬデータの再送信用のＤＣＩの受信についてＰＤＣＣＨがモニターされる。ＤＬデータが受信されるが、正常にデコードできないたびに、ｄｒｘ－ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒは、次のブラインド再送信の受信のために（再）開始される。ＰＤＳＣＨを介して受信されたデータが正常にデコードされると、最後のブラインド再送信において受信されたデータの正常な（ＡＣＫ）デコードによって示されるように、ｄｒｘ－ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒは停止され得る。
【0182】
図２７から分かるように、ステップＳ８００において、ｄｒｘ－ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒは、ＰＤＳＣＨを介して受信されたデータに対してデコードエラーが発生したときに開始される。
【0183】
ステップＳ８１０では、ＵＥ１００がアクティブ状態であるか否かが判定される。すなわち、ｄｒｘ－ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒが動作しているか否かを判定する。ｄｒｘ－ＲｅｔｒａｎｓｍｉｓｓｉｏＴｉｍｅｒが実行中でない場合（ステップＳ８１０、ＮＯ）、本方法は終了する。ＵＥ１００がアクティブ状態であり、ｄｒｘ－ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒが実行中である場合（ステップＳ８２０、ＹＥＳ）、ステップＳ８２０に進む。
【0184】
ステップＳ８２０で、ＰＤＣＣＨは、ＤＬデータの再送信用のＤＣＩの受信についてモニターされる。
【0185】
ステップＳ８３０では、ＰＤＳＣＨを介して受信されたＤＬデータが正常にデコードされたか否かが判定される。正常にデコードされた場合（ステップＳ８３０、ＹＥＳ）、ステップＳ８５０に進む。正常にデコードされていないと判定された場合（ステップＳ８３０、ＮＯ）、ステップＳ８４０に進む。
【0186】
ステップＳ８４０において、ｄｒｘ－ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒが（受信されたデータをデコードした後に）再開され、方法はステップＳ８１０に続く。
【0187】
ステップＳ８５０において、現在のＨＡＲＱプロセスに対応するｄｒｘ－ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒが停止され、その後、方法は終了する。
【0188】
本実施形態の説明した変形例によれば、モニタリング期間は、制御情報または第２制御情報が受信される毎に部分的なモニタリング期間を開始することによって、送受信装置１００の回路１３０によって設定される。
【0189】
なお、回路は、受信データを正常にデコードしなかった後に、部分的なモニタリング期間を開始してもよい。このアプローチでは、正常にデコードした場合に部分的なモニタリング期間が開始されないため、ＰＤＣＣＨは不必要にモニターされない。
【0190】
さらなる実施形態では、部分的なモニタリング期間のためのタイマーのランタイムは、再送信用のＤＣＩが送信されるときに、ＵＥ１００がアクティブであるために十分に長い。さらに、ｇＮＢは、ブラインド再送信の回数を示すそれぞれの再送信インジケータを送信することによって、ブラインド再送信の回数を示す。ＵＥ１００は、送信または再送信のためのＤＣＩがＰＤＣＣＨを介して受信されるたびに、それぞれのタイマーを（再）開始する。
【0191】
なお、タイマーは、ＤＣＩを受信した直後であってもよいし、受信した各ＤＬデータをデコードした後であってもよい。
【0192】
さらに、モニタリング期間を開始する前に（それぞれのタイマーを開始することによって）、受信された再送信の回数がｇＮＢ２００によって示される再送信の回数と等しいかどうかが判定される。受信した再送信の回数が指示された再送信の回数以上である場合には、専用タイマーは起動されない。
【0193】
このアプローチにより、ブラインド再送信が予想されない場合に、ＵＥ１００がＰＤＣＣＨをモニターすることが回避される。
【0194】
ブラインド再送信の回数が半静的または動的に設定されるかに応じて、ブラインド再送信の回数は、それぞれ半静的または動的に示され得ることに留意されたい。例えば、半静的指示のために、ＲＲＣシグナリングが利用されてもよく、動的指示のために、ＭＡＣ ＣＥまたはＤＣＩが利用されてもよい。
【0195】
さらに、異なるＨＡＲＱプロセスは、ｄｒｘ－ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒおよびｄｒｘ－ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒを含む、いくつかのブラインド再送信およびＤＲＸのタイマー値（モニタリング期間の継続時間）を用いて独立して設定され得ることに留意されたい。ブラインド再送信の回数の動的な値は、ＤＣＩシグナリングによって設定または指示することができる。
【0196】
第１変形例では、モニタリング期間は、ＰＤＳＣＨを介してＤＬデータが受信されるたびに開始されるｄｒｘ－ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒを使用して部分的なモニタリング期間を開始することによって設定され、これは、ＰＤＳＣＨを介してＤＬデータを受信するたびに開始され、正常にデコードすることができず、最後のブラインド再送信は、示されたブラインド再送信の回数に従ってまだ実行されていない。また、本実施形態の変形例では、ｄｒｘ－ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒを無効にしている。
【0197】
図２８は、ｄｒｘ－ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒを使用して部分的なモニタリング期間を設定することによってモニタリング期間が設定され、ブラインド再送信の回数が示される場合に、ＵＥ１００によって実行される方法のステップを示すフローチャートを示す。
【0198】
ステップＳ８００では、ブラインド再送回数を示す再送信インジケータがｇＮＢ２００から受信される。
【0199】
ステップＳ８１０において、ＵＥ１００がアクティブ時間にあるか否かが判定される。すなわち、ｄｒｘ－ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒが実行中であるか否かが判定される。ｄｒｘ－ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒが実行中でない場合（ステップＳ８１０、ＮＯ）、すなわち、ＵＥがアクティブ時間にない場合、方法は終了する。ＵＥ１００がアクティブ時間にある場合（ステップＳ８２０、ＹＥＳ）、ステップＳ８２０に進む。
【0200】
ステップＳ８２０において、ＵＥ１００は、ブラインド再送信用のＤＣＩの受信のためにＰＤＣＣＨをモニターする。
【0201】
ＤＬデータの送信又は再送信用にＤＣＩを受信した後、ＤＬデータを受信し、ステップＳ８３０で受信したＤＬデータが正常にデコード可能か否かを判定する。ＤＬデータを正常にデコードした場合（ステップＳ８３０、ＹＥＳ）、本方法は終了する。ＤＬデータを正常にデコードしなかった場合（ステップＳ８３０、ＮＯ）、ステップＳ８４０に進む。
【0202】
ステップＳ８４０では、ブラインド再送信の回数が終了したか否かを判定する。言い換えると、ＵＥ１００は、受信されたブラインド再送信の回数を追跡し、受信されたブラインド再送信の回数が、ステップＳ８００で受信されたインジケータによって示されるブラインド再送信の回数に等しいかどうかを判定する。ブラインド再送信の回数が終了した場合（ステップＳ８４０、ＹＥＳ）、本方法は終了する。ブラインド再送信の回数が終了していない場合（ステップＳ８４０、ＮＯ）、ステップＳ８５０に進む。
【0203】
ステップＳ８５０において、ｄｒｘ－ＩｍａｃｔｉｖｉｔｙＴｉｍｅｒが再開され、ステップＳ８１０に続く。
【0204】
第２変形例では、ＰＤＳＣＨを介して受信されたＤＬデータが正常にデコードできない毎に開始され、かつ、最後のブラインド再送信がブラインド再送信の指示された回数に従ってまだ実行されていない、ｄｒｘ－ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒを使用して部分的なモニタリング期間を開始することによって、モニタリング期間は、設定される。
【0205】
図２９は、ｄｒｘ－ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒを使用して部分的なモニタリング期間を設定することによってモニタリング期間が設定され、ブラインド再送信の回数が示される場合にＵＥ１００によって実行される方法のステップを示すフローチャートを示す。
【0206】
ステップＳ９００では、ブラインド再送信の回数を示す再送信インジケータがｇＮＢ２００から受信される。さらに、ｄｒｘ－ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒのランタイムの値が受信される。ブラインド再送信の回数およびタイマーのランタイムのシグナリングの詳細については、以下でさらに説明する。
【0207】
ステップＳ９１０において、ＵＥ１００がアクティブ時間にあるか否かが判定される。すなわち、ｄｒｘ－ＲｅｔｒａｎｓｍｓｓｉｏｎＴｉｍｅｒが実行中であるか否かが判定される。ｄｒｘ－ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒが実行中でない場合（ステップＳ９１０、ＮＯ）、すなわち、ＵＥがアクティブ時間にない場合、方法は終了する。ＵＥ１００がアクティブ時間にある場合（ステップＳ９２０、ＹＥＳ）、ステップＳ９２０に進む。
【0208】
ステップＳ９２０において、ＵＥ１００は、ブラインド再送信用のＤＣＩの受信のためにＰＤＣＣＨをモニターする。
【0209】
ステップＳ９３０では、ＤＬデータの再送用のＤＣＩを受信した後、ＤＬデータを受信し、受信したＤＬデータが正常にデコード可能か否かを判定する。ＤＬデータを正常にデコードした場合（ステップＳ９３０、ＹＥＳ）、本方法は終了する。ＤＬデータを正常にデコードしなかった場合（ステップＳ９３０、ＮＯ）、ステップＳ９４０に進む。
【0210】
ステップＳ９４０では、ブラインド再送信の回数が終了したか否かを判定する。言い換えると、ＵＥ１００は、受信されたブラインド再送信の回数を追跡し、受信されたブラインド再送信の回数が、ステップＳ９００で受信されたインジケータによって示されるブラインド再送信の回数に等しいかどうかを判定する。ブラインド再送信の回数が終了した場合（ステップＳ９４０、ＹＥＳ）、本方法は終了する。ブラインド再送信の回数が終了していない場合（ステップＳ９４０、ＮＯ）、ステップＳ９５０に進む。
【0211】
ステップＳ８５０では、ｄｒｘ－ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒが（ＰＤＳＣＨを介して受信されたＤＬデータのデコード後に）再開され、ステップＳ９１０に続く。
【0212】
本実施形態の変形例によれば、送受信装置１００は、再送信の回数を示す再送信インジケータを受信する。さらに、モニタリング期間は、１つ以上の部分的なモニタリング期間を開始することによって設定される。これは、例えば、各タイマーを起動することにより行われる。指示された再送信の回数がまだ終了していない場合にのみ、上記のタイマーが開始される。
【0213】
このアプローチにより、送受信装置１００は、ｇＮＢ２００が上記のデータを再送信しない場合に、ＤＬデータのブラインド再送信についてＤＣＩ用のＰＤＣＣＨをモニターすることを防止される。したがって、送受信装置の電力消費が低減され、同時に、第２制御情報が送信されるか、または対応するＤＬデータが再送信されるときに、送受信装置１００がアクティブ時間にあることが保証される。
【0214】
以下では、ブラインド再送信の回数の可能な設定パスの詳細について説明する。
【0215】
すでに示されているように、ブラインド再送信の回数は、ＲＲＣメッセージによって設定される可能性がある。ブラインド再送信の回数は、以下に示すように、ＤＲＸ設定要素で設定することができる。
【0216】
【表1】
【0217】
特に、ブラインド再送信の回数は、追加のパラメータを介して設定されてもよく、これは、上記の例では、「ｄｒｘ－ＮｕｍｂｅｒｏｆＢｌｉｎｄＲｅｔｒａｎｓｍｉｓｓｉｏｎｓ」として示される。
【0218】
また、ブラインド再送信の回数は、ＭＡＣ ＣＥによって設定してもよい。
【0219】
ＮＲでは、例えば、ＭＡＣレイヤは、いわゆるＭＡＣ制御要素（ＭＡＣ ＣＥ）を、トランスポートチャネルを介して送信されるべきトランスポートブロックに挿入することができる。ＭＡＣ ＣＥは、インバンド制御シグナリング、例えば、タイミングアドバンスコマンドまたはランダムアクセス応答のために使用される。
【0220】
しかしながら、本開示によれば、ＭＡＣ ＣＥは、ブラインド再送信の回数に関する情報を搬送することができ、ＭＡＣ ＣＥは、例えば、０から７までのブラインド再送信の回数を示すことができる。
【0221】
図３０は、一実施形態によるブラインド再送信の回数を示すＭＡＣ制御要素であるＣＥを概略的に示す。例えば、ＭＡＣ ＣＥのフィールドＤｉは、ブラインド再送信の回数を示すことができ、Ｄｉが“１”に設定されている場合、ブラインド再送信の回数がｉであることを示すことができる。例えば、Ｄ１は、１つのブラインド再送信、Ｄ２は、２つのブラインド再送信、Ｄ３は、３つのブラインド再送信などに関連している。しかしながら、本発明は、７回までの再送信を示す１バイトに限定されず、より多くのブラインド再送信がＭＡＣ ＣＥによって設定されてもよい。
【0222】
さらに、ブラインド再送信の回数は、ＤＣＩによって設定されてもよく、例えば、ブラインド再送信の回数は、８回までのブラインド再送信を示すために３ビットを使用してシグナリングされてもよい。
【0223】
以下では、タイマーのランタイムの可能な設定パスの詳細について説明する。
【0224】
すでに示されているように、タイマーのランタイムは、ＲＲＣメッセージによって設定されてもよい。タイマーのランタイムは、以下に示すように、ＤＲＸ設定要素で設定できる。
【0225】
【表2】
【0226】
特に、タイマーのランタイムは、パラメータｄｒｘ－ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒ、ｄｒｘ－ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒＤＬ、およびｄｒｘ－ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒＵＬを介して設定することができる。つまり、各タイマーのランタイム値はインデックスに関連付けられる。
【0227】
また、タイマーの値は、例えば、図３０に示すように、ＭＡＣ ＣＥによって示されてもよい。この場合、ＭＡＣ ＣＥは、それぞれのタイマーに対するインデックス値を示すことができる。ＭＡＣ ＣＥがＵＥによって受信される場合、ＭＡＣ ＣＥによって示されるインデックスに対応するタイマーの値は、ブラインド再送信のＤＣＩのためのＰＤＣＣＨをモニターするためのモニタリング期間における専用タイマーに適用されてもよい。
【0228】
あるいは、時間値は、ＤＣＩによって示されてもよく、ＤＣＩは、インデックス番号を示し、ＵＳは、ＤＣＩの受信時に、ＤＣＩによって示されるインデックスに従ってランタイムを適用する。
【0229】
なお、ブラインド再送信の設定は、上述した実施形態のいずれかに限定されるものではなく、上述した方法の間で切り替えてもよい。
【0230】
例えば、時間ｔにおいて、ｇＮＢは、ＤＣＩもしくはＲＲＣのいずれかによって、タイマーのランタイムの値を設定する可能性がある。さらに、別の時間ｔ’において、ブラインド再送信の回数は、ＤＣＩを介して設定されてもよい。この場合、ＵＥは、上述したように、タイマーの値にブラインド再送信の回数を乗算することによって、新しいタイマーの値を導出することができる。
【0231】
同様に、ｇＮＢは、設定オプション間で切り替わることができる。例えば、時間ｔでｇＮＢがブラインド再送信の回数を設定できない時、ＵＥは受信データを正常にデコードできない時にタイマーを再開する。さらに、時間ｔ’において、ｇＮＢは、ブラインド再送信の回数を設定してもよい。
【0232】
記載された実施形態およびそれぞれの変形例では、ブラインド再送信の回数は、パケット優先度に基づいて、ＨＡＲＱプロセスごとに設定され得る。
【0233】
例えば、３つのブラインド再送信は、ＨＡＲＱプロセス１用に設定されることができ、一方、単一のブラインド再送信は、ＨＡＲＱプロセス２用に設定されることができ、ブラインド再送信なしは、ＨＡＲＱプロセス３用に設定されることができる。
【0234】
さらに、例えば、ブラインド再送信の回数は、送信されるパケットの優先度レベルに従って設定してもよい。例えば、第２のパケットより高い優先度レベルを有する第１のパケットに対して、より高い回数のブラインド再送信が、より低い優先度レベルを有する第２のパケットに関して設定されてもよい。例えば、ブラインド再送信の回数は、送信されるパケットの優先度レベルに比例するように設定してもよい。
【0235】
さらに、異なるＨＡＲＱプロセスは、異なるタイマーの値を用いて設定され得ることに留意されたい。さらに、ブラインド再送信の回数が設定される場合、設定された再送信の回数は、異なるＨＡＲＱプロセスに対して異なってもよい。
【0236】
説明された実施形態およびそれぞれの変形例では、ｄｒｘ－ＨＡＲＱ－ＲＴＴのタイマーは、ＨＡＲＱフィードバックが無効にされたときに無効にされるか、またはそのランタイムの値がゼロに設定され得る。
【0237】
なお、実施形態およびそれぞれの変形例に係る方法は、単一のＨＡＲＱプロセスについて説明されている。しかし、本開示はこれに限定されない。特に、方法の「終了」は、すべての実行タイマーの終了を意味しない。
【0238】
実施形態の方法およびそれぞれの変形例は、ｇＮＢからＵＥに送信されるダウンリンクデータに関連して主に説明されるが、これらの方法は、ＵＥからｇＮＢへの送信、すなわち、アップリンクデータの送信に等しく適用され得る。
【0239】
すなわち、ｄｒｘ－ＨＡＲＱ－ＲＴＴ－ＴｉｍｅｒＵＬは、ｄｒｘ－ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒおよび／またはｄｒｘ－ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒＵＬが、最初の送信のためにＤＣＩを受信した後に、または送信の後に開始されるように、ゼロに設定されるか、または無効にされてもよい。
【0240】
本開示で使用される用語ｄｒｘ－ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒは、ダウンリンクデータの再送信のためのｄｒｘ－ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒＤＬ、またはアップリンクデータの再送信のためのｄｒｘ－ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒＵＬを指してもよい。さらに、本開示で使用される用語ｄｒｘ－ＨＡＲＱ－ＲＴＴ－Ｔｉｍｅｒは、ｄｒｘＨＡＲＱ－ＲＴＴ－ＴｉｍｅｒＤＬまたはＨＡＲＱ－ＲＴＴ－ＴｉｍｅｒＵＬを指すことができる。
【0241】
本開示は、ソフトウェア、ハードウェア又はハードウェアと連動するソフトウェアによって実現することができる。上述した各実施例の説明に用いた各機能ブロックは、集積回路（ＩＣ）等のＬＳＩ（Ｌａｒｇｅ Ｓｃａｌｅ Ｉｎｔｅｇｒａｔｉｏｎ）によって部分的又は全体的に実現可能であり、各実施例で説明される各処理は、同一のＬＳＩ又はＬＳＩの組合せによって部分的又は全体的に制御されてもよい。ＬＳＩは、個別にチップとして形成されていてもよいし、あるいは、機能ブロックの一部又は全部を含むように１つのチップが形成されていてもよい。ＬＳＩは、それに結合されたデータ入出力を含んでもよい。ここで、ＬＳＩとは、集積度の違いにより、ＩＣ、システムＬＳＩ、スーパーＬＳＩ又はウルトラＬＳＩとして呼ばれうる。しかしながら、集積回路を実現する技術はＬＳＩに限定されず、専用回路、汎用プロセッサ又は特定用途向けプロセッサを用いて実現されてもよい。さらに、ＬＳＩ内部に配置される回路セルの接続及び設定が再設定可能なＬＳＩ又はリコンフィギュラブルプロセッサの製造後にプログラミング可能なＦＰＧＡ（Ｆｉｅｌｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ）が利用されてもよい。本開示は、デジタル処理又はアナログ処理として実現することができる。半導体技術や他の派生技術の進歩の結果として、将来の集積回路技術がＬＳＩに取って代わる場合、機能ブロックは、将来の集積回路技術を用いて集積化することができる。バイオテクノロジーも適用できる。
【0242】
本開示は、通信装置と呼ばれる、通信機能を有する何れかのタイプの装置、デバイス又はシステムによって実現することができる。
【0243】
そのような通信装置のいくつかの非限定的な例は、電話機（例えば、携帯（セル）電話、スマートフォン）、タブレット、パーソナルコンピュータ（ＰＣ）（例えば、ラップトップ、デスクトップ、ネットブック）、カメラ（例えば、デジタルスチル／ビデオカメラ）、デジタルプレーヤ（デジタルオーディオ／ビデオプレーヤ）、ウェアラブルデバイス（例えば、ウェアラブルカメラ、スマートウォッチ、トラッキングデバイス）、ゲームコンソール、デジタルブックリーダ、遠隔ヘルス／遠隔医療（リモートヘルス及びリモート医療）デバイス、及び通信機能を提供する車両（例えば、自動車、飛行機、船舶）、並びにそれらの様々な組み合わせを含む。
【0244】
通信装置は、携帯型又は可動型であることに限定されず、スマートホームデバイス（例えば、家電、ライティング、スマートメータ、制御パネル）、自動販売機及び“Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ（ＩｏＴ）”のネットワークにおける他の何れかの“物”など、非携帯型又は固定型である何れかのタイプの装置、デバイス又はシステムを含んでもよい。
【0245】
通信は、例えば、セルラシステム、無線ＬＡＮシステム、衛星システムなど、及びそれらの様々な組合せを介してデータを交換することを含んでもよい。
【0246】
通信装置は、本開示に記載された通信の機能を実行する通信デバイスに結合されたコントローラ又はセンサなどのデバイスを含んでもよい。例えば、通信装置は、通信装置の通信機能を実行する通信デバイスによって使用される制御信号又はデータ信号を生成するコントローラ又はセンサを含んでもよい。
【0247】
通信装置はまた、基地局、アクセスポイントなどのインフラストラクチャファシリティと、上記の非限定的な例におけるものなどの装置と通信又は制御する他の何れかの装置、デバイス又はシステムを含んでもよい。
【0248】
上述したように、ＤＲＸ周期が設定されるときに上記の送信の受信を保証しながらブラインド再送信を可能にする装置および方法が提供される。
【0249】
動作中に、物理ダウンリンク制御チャネルであるＰＤＣＣＨを介して、データのスケジュールされた送信を示す制御情報を受信する送受信機と、動作中に、データのブラインド再送信の回数に応じてモニタリング期間を設定する回路と、を備え、送受信機は、動作中に、モニタリング期間中にＰＤＣＣＨをモニターする、送受信装置が提供される。
【0250】
いくつかの実施形態では、送受信機は、動作中に、制御情報に応じてデータを受信する。
【0251】
いくつかの実施形態では、送受信機は、動作中に、制御情報に応じてデータを送信する。
【0252】
言い換えると、送受信機は、動作中、制御情報がデータの受信または送信のどちらを指すかに応じて、制御情報に応じてデータを受信または送信することができる。本開示によって達成される利点は、データが送信されるか受信されるかにかかわらず、ＰＤＣＣＨがモニターされるモニタリング期間を設定することによって達成される。
【0253】
つまり、制御情報は、データのブラインド再送信のスケジューリングを示す。すなわち、制御情報は、前記のデータを含まないが、データを受信するため、またはデータを送信するために、送受信装置にスケジューリング情報を提供する。
【0254】
さらに、ブラインド再送信は、過去に送信されたデータの送信と呼ばれることがある。特に、ブラインド再送信は、フィードバックの有無にかかわらず、データの再送信である。
【0255】
いくつかの実施形態では、送受信機は、動作中に、モニタリング期間内のＰＤＣＣＨを介して、データのスケジュールされた再送信を示す第２制御情報を受信する。
【0256】
いくつかの実施形態では、送受信機は、動作中に、第２制御情報に応じてデータを受信する。
【0257】
いくつかの実施形態では、送受信機は、動作中に、第２制御情報に応じてデータを送信する。
【0258】
言い換えると、送受信機は、動作中に、第２制御情報がデータの受信または送信のいずれを指すかに応じて、第２制御情報に応じてデータを受信または送信することができる。本開示によって達成される利点は、データが送信されるか受信されるかにかかわらず、ＰＤＣＣＨがモニターされるモニタリング期間を設定することによって達成される。
【0259】
いくつかの実施形態では、回路は、動作中に、制御情報が受信された場合、モニタリング期間を開始する。
【0260】
いくつかの実施形態では、送受信機は、動作中に、モニタリング期間の継続時間を示す継続インジケータを受信し、回路は、動作中に、継続インジケータにより示される継続時間に応じてモニタリング期間の継続時間を設定する。
【0261】
いくつかの実施形態では、回路は、動作中に、ブラインド再送信の回数に比例したモニタリング期間の継続時間を設定する。
【0262】
いくつかの実施形態では、送受信機は、動作中に、ブラインド再送信の回数を示す再送信インジケータを受信する。
【0263】
いくつかの実施形態では、送受信機は、動作中に、モニタリング期間の終了を示す終了インジケータを受信し、回路は、動作中に、終了インジケータが受信された場合、モニタリング期間を終了する。
【0264】
いくつかの実施形態では、回路は、動作中に、制御情報または第２制御情報が受信される時間ごとに部分的なモニタリング期間を開始することによるモニタリング期間を設定する。
【0265】
いくつかの実施形態では、送受信機は、動作中に、制御情報または第２制御情報に応じてデータを受信し、回路は、動作中に、制御情報または第２制御情報に応じて、受信されたデータをデコードし、デコードされたデータが正常であるか否か判定し、受信されたデータが正常にデコードされていない時間ごとに部分的なモニタリング期間を開始することによるモニタリング期間を設定する。
【0266】
いくつかの実施形態では、送受信機は、動作中に、再送信の回数を示す再送信インジケータを受信し、回路は、動作中に、受信された第２制御情報の回数が、示された再送信の回数と等しい場合、部分的なモニタリング期間を開始しない。
【0267】
いくつかの実施形態では、送受信機は、動作中に、制御情報または第２制御情報に応じてデータを受信し、回路は、動作中に、送受信機により受信されたデータをデコードし、データが正常にデコードされた場合、モニタリング期間を終了する。
【0268】
いくつかの実施形態では、回路は、動作中に、モニタリング期間の継続時間に等しいランタイムでタイマーを開始することによるモニタリング期間を設定する。
【0269】
いくつかの実施形態では、間欠受信であるＤＲＸ周期が設定され、送受信機は、動作中に、アクティブ時間でＰＤＣＣＨをモニターし、オフ期間でＰＤＣＣＨをモニターしない。
【0270】
さらに、動作中に、データのブラインド再送信の回数を決定する回路と、動作中に、物理ダウンリンク制御チャネルであるＰＤＣＣＨを介して、ブラインド再送信の回数に応じた、データの、スケジュールされた送信または再送信を示す制御情報を送信する送受信機と、を備えるスケジューリング装置が提供される。
【0271】
いくつかの実施形態では、送受信機は、動作中に、制御情報に応じてデータを受信する。
【0272】
いくつかの実施形態では、送受信機は、動作中に、制御情報に応じてデータを送信する。
【0273】
言い換えると、送受信機は、動作中に、制御情報がデータの受信または送信のどちらを指すかに応じて、制御情報に応じてデータを受信または送信することができる。本開示によって達成される利点は、データが送信されるか受信されるかにかかわらず、ＰＤＣＣＨがモニターされるモニタリング期間を設定することによって達成される。
【0274】
言い換えると、制御情報は、データの送信またはブラインド再送信のスケジューリングを示す。すなわち、制御情報は、前記のデータを含まないが、送受信装置がデータを受信するか、またはデータを送信するためのスケジューリング情報を提供する。
【0275】
さらに、ブラインド再送信は、過去に送信されたデータの送信と呼ばれることがある。特に、ブラインド再送信は、フィードバックの有無にかかわらず、データの再送信である。
【0276】
いくつかの実施形態では、回路は、動作中に、モニタリング期間の継続時間を決定し、送受信機は、動作中に、モニタリング期間の継続時間を示す継続インジケータを送信する。
【0277】
いくつかの実施形態では、送受信機は、動作中に、再送信の回数を示す再送信インジケータを送信する。
【0278】
いくつかの実施形態では、送受信機は、動作中に、モニタリング期間の終了を示す終了インジケータを送信する。
【0279】
物理ダウンリンク制御チャネルであるＰＤＣＣＨを介して、データのスケジュールされた送信を示す制御情報を受信するステップと、データのブラインド再送信の回数に応じてモニタリング期間を設定するステップと、を有し、ＰＤＣＣＨは、前記モニタリング期間中にモニターされる、方法がさらに提供される。
【0280】
いくつかの実施形態では、方法は、制御情報に応じてデータを受信するステップを含む。
【0281】
いくつかの実施形態では、方法は、制御情報に応じてデータを送信するステップを含む。
【0282】
言い換えると、この方法は、制御情報がデータの受信または送信のいずれを指すかに応じて、制御情報に応じてデータを受信または送信するステップを含むことができる。本開示によって達成される利点は、データが送信されるか受信されるかにかかわらず、ＰＤＣＣＨがモニターされるモニタリング期間を設定することによって達成される。
【0283】
つまり、制御情報は、データのブラインド再送信のスケジューリングを示す。すなわち、制御情報は、前記のデータを含まないが、送受信装置がデータを受信するか、またはデータを送信するためのスケジューリング情報を提供する。
【0284】
さらに、ブラインド再送信は、過去に送信されたデータの送信と呼ばれることがある。特に、ブラインド再送信は、送信されたフィードバックの有無にかかわらず、データの再送信である。
【0285】
いくつかの実施形態では、方法は、モニタリング期間内のＰＤＣＣＨを介して、データのスケジュールされた再送信を示す第２制御情報を受信するステップをさらに含む。
【0286】
いくつかの実施形態では、方法は、第２制御情報に応じてデータを受信するステップを含む。
【0287】
いくつかの実施形態では、方法は、第２制御情報に応じてデータを送信するステップを含む。
【0288】
言い換えると、この方法は、制御情報がデータの受信または送信のどちらを指すかに応じて、第２制御情報に応じてデータを受信または送信するステップを含むことができる。本開示によって達成される利点は、データが送信されるか受信されるかにかかわらず、ＰＤＣＣＨがモニターされるモニタリング期間を設定することによって達成される。
【0289】
つまり、制御情報は、データのブラインド再送信のスケジューリングを示す。すなわち、制御情報は、前記のデータを含まないが、送受信装置がデータを受信するか、またはデータを送信するためのスケジューリング情報を提供する。
【0290】
さらに、ブラインド再送信は、過去に送信されたデータの送信と呼ばれることがある。特に、ブラインド再送信は、受信したフィードバックの有無にかかわらず、データの再送信である。
【0291】
いくつかの実施形態では、この方法は、制御情報が受信された場合、モニタリング期間を開始するステップを含む。
【0292】
いくつかの実施形態では、方法は、モニタリング期間の継続時間を示す継続インジケータを受信するステップと、継続インジケータにより示される継続時間に応じてモニタリング期間の継続時間を設定するステップとを含む。
【0293】
いくつかの実施形態では、方法は、ブラインド再送信の回数に比例したモニタリング期間の継続時間を設定するステップを含む。
【0294】
いくつかの実施形態では、方法は、ブラインド再送信の回数を示す再送信インジケータを受信するステップを含む。
【0295】
いくつかの実施形態では、この方法は、モニタリング期間の終了を示す終了インジケータを受信するステップと、終了インジケータが受信された場合、モニタリング期間を終了するステップとを含む。
【0296】
いくつかの実施形態では、この方法は、制御情報または第２制御情報が受信される時間ごとに部分的なモニタリング期間を開始することによるモニタリング期間を設定するステップを含む。
【0297】
いくつかの実施形態では、本方法は、制御情報または第２制御情報に応じてデータを受信するステップと、制御情報または第２制御情報に応じて、受信されたデータをデコードするステップと、デコードされたデータが正常であるか否か判定するステップと、受信されたデータが正常にデコードされていない時間ごとに部分的なモニタリング期間を開始することによるモニタリング期間を設定するステップとを含む。
【0298】
いくつかの実施形態では、本方法は、再送信の回数を示す再送信インジケータを受信するステップと、受信された第２制御情報の回数が、示された再送信の回数と等しい場合、部分的なモニタリング期間を開始しないステップとを含む。
【0299】
いくつかの実施形態では、方法は、制御情報または第２制御情報に応じてデータを受信するステップと、送受信機により受信されたデータをデコードするステップと、データが正常にデコードされた場合、モニタリング期間を終了するステップとを含む。
【0300】
いくつかの実施形態では、方法は、モニタリング期間の継続時間に等しいランタイムでタイマーを開始することによるモニタリング期間を設定するステップを含む。
【0301】
いくつかの実施形態では、間欠受信であるＤＲＸ周期が設定され、送受信機は、動作中に、アクティブ時間でＰＤＣＣＨをモニターし、オフ期間でＰＤＣＣＨをモニターしない。
【0302】
さらに、データのブラインド再送信の回数を決定するステップと、物理ダウンリンク制御チャネルであるＰＤＣＣＨを介して、ブラインド再送信の回数に応じた、データの、スケジュールされた送信または再送信を示す制御情報を送信するステップとを含む方法が提供される。
【0303】
いくつかの実施形態では、方法は、制御情報に応じてデータを受信するステップを含む。
【0304】
いくつかの実施形態では、方法は、制御情報に応じてデータを送信するステップを含む。
【0305】
言い換えると、この方法は、制御情報がデータの受信または送信のいずれを指すかに応じて、制御情報に応じてデータを受信または送信するステップを含むことができる。本開示によって達成される利点は、データが送信されるか受信されるかにかかわらず、ＰＤＣＣＨがモニターされるモニタリング期間を設定することによって達成される。
【0306】
言い換えると、制御情報は、データの送信またはブラインド再送信のスケジューリングを示す。すなわち、制御情報は、前記のデータを含まないが、送受信装置がデータを受信するか、またはデータを送信するためのスケジューリング情報を提供する。
【0307】
さらに、ブラインド再送信は、過去に送信されたデータの送信と呼ばれることがある。特に、ブラインド再送信は、フィードバックの有無にかかわらず、データの再送信である。
【0308】
いくつかの実施形態では、方法は、モニタリング期間の継続時間を決定するステップと、モニタリング期間の継続時間を示す継続インジケータを送信するステップとを含む。
【0309】
いくつかの実施形態では、方法は、再送信の回数を示す再送信インジケータを送信するステップを含む。
【0310】
いくつかの実施形態では、方法は、モニタリング期間の終了を示す終了インジケータを送信するステップを含む。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7A】
【図7B】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図22】
【図23】
【図24】
【図25】
【図26】
【図27】
【図28】
【図29】
【図30】
【国際調査報告】