JP2023535834A - ユーザ機器、スケジューリングノード、ユーザ機器のための方法、およびスケジューリングノードのための方法 - Google Patents
ユーザ機器、スケジューリングノード、ユーザ機器のための方法、およびスケジューリングノードのための方法 Download PDFInfo
- Publication number
- JP2023535834A JP2023535834A JP2023506323A JP2023506323A JP2023535834A JP 2023535834 A JP2023535834 A JP 2023535834A JP 2023506323 A JP2023506323 A JP 2023506323A JP 2023506323 A JP2023506323 A JP 2023506323A JP 2023535834 A JP2023535834 A JP 2023535834A
- Authority
- JP
- Japan
- Prior art keywords
- transmissions
- tbs
- scheduling
- scheduled
- dci
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W72/00—Local resource management
- H04W72/20—Control channels or signalling for resource management
- H04W72/23—Control channels or signalling for resource management in the downlink direction of a wireless link, i.e. towards a terminal
- H04W72/232—Control channels or signalling for resource management in the downlink direction of a wireless link, i.e. towards a terminal the control data signalling from the physical layer, e.g. DCI signalling
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W72/00—Local resource management
- H04W72/20—Control channels or signalling for resource management
- H04W72/23—Control channels or signalling for resource management in the downlink direction of a wireless link, i.e. towards a terminal
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L5/00—Arrangements affording multiple use of the transmission path
- H04L5/003—Arrangements for allocating sub-channels of the transmission path
- H04L5/0053—Allocation of signaling, i.e. of overhead other than pilot signals
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L5/00—Arrangements affording multiple use of the transmission path
- H04L5/003—Arrangements for allocating sub-channels of the transmission path
- H04L5/0058—Allocation criteria
- H04L5/0064—Rate requirement of the data, e.g. scalable bandwidth, data priority
Landscapes
- Engineering & Computer Science (AREA)
- Signal Processing (AREA)
- Computer Networks & Wireless Communication (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
本開示はユーザ機器（ＵＥ）に関する。ＵＥは送受信機および回路を備える。前記送受信機は、動作時に、ダウンリンク制御情報（ＤＣＩ）シグナリングと、制御情報とを受信する。前記回路は、動作時に、前記ＤＣＩシグナリングから、複数のトランスポートブロック（ＴＢ）の各ＴＢに対して前記各ＴＢの１つ以上の送信のスケジューリングを通知する通知を取得する。前記回路は、動作時に、前記制御情報から、リソースを通知する取り消し通知（ＣＩ）を取得する。また、前記回路は、動作時に、前記通知されたリソースと所定のルールとに基づいて、前記複数のＴＢのスケジュールされた送信のうちどの送信が取り消されるかを決定する。
【選択図】図７
【選択図】図７
Description
本開示は、３ＧＰＰ（登録商標）通信システムなどの通信システムにおける方法、デバイス、および物品を対象とする。
本開示は、通信システムにおける信号の送受信に関し、特に、そのような送受信のための方法および通信装置に関する。
３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ （３ＧＰＰ）では、１００ＧＨｚまでの周波数範囲で動作する、第５世代（５Ｇ）とも呼ばれる次世代セルラ技術（Ｎｅｗ Ｒａｄｉｏ（ＮＲ）無線アクセス技術（ＲＡＴ：radio access technology）を含む）の技術仕様を策定している。ＮＲは、ＬＴＥ（Long Term Evolution）やＬＴＥ－Ａ（LTE Advanced）に代表される技術の後継である。
ＬＴＥ、ＬＴＥ－Ａ、ＮＲといったシステムでは、さらなる改良やオプションによって、通信システムやシステムに関連する特定の機器の効率的な運用が促進され得る。
ＬＴＥおよびＮＲといったシステムでは、さらなる改良およびオプションによって、通信システムならびにそのシステムに関連する特定のデバイスの効率的な動作が促進され得る。
非限定的で例示的な一実施形態は、ダウンリンク制御情報（ＤＣＩ：Ｄｏｗｎｌｉｎｋ Ｃｏｎｔｒｏｌ Ｉｎｆｏｒｍａｔｉｏｎ）シグナリング（本開示では「マルチＴＢスケジューリングＤＣＩ」とも呼ぶ）を用いた複数のトランスポートブロック（ＴＢ：ｔｒａｎｓｐｏｒｔ ｂｌｏｃｋ）の効率的なスケジューリング、ならびにマルチＴＢスケジューリングＤＣＩによってスケジュールされた送信の効率的な取り消しを促進することに資する。
一実施形態では、本明細書で開示する技術は、装置（例えば、ユーザ機器（ＵＥ：ｕｓｅｒ ｅｑｕｉｐｍｅｎｔ））を特徴とする。この装置は、動作時に、ＤＣＩシグナリングと制御情報を受信する送受信機を備える。この装置はさらに、動作時に、前記ＤＣＩシグナリングから通知（本開示では「スケジューリング通知」とも呼ぶ）を取得する回路を備える。前記通知は、複数のＴＢの各ＴＢに対して、前記各ＴＢの１つ以上の送信のスケジューリングを通知する。また、前記回路は、前記制御情報からリソースを通知する取り消し通知（ＣＩ）を取得する。さらに、前記回路は、前記通知されたリソースと所定のルール（本開示では「取り消しルール」とも呼ぶ）とに基づいて、前記複数のＴＢのスケジュールされた送信のうちどの送信が取り消されるかを決定する。
なお、これらの包括的または具体的な態様は、システム、方法、集積回路、コンピュータプログラム、または、記録媒体で実現されてもよく、システム、装置、方法、集積回路、コンピュータプログラムおよび記録媒体の任意な組み合わせで実現されてもよい。
本開示の一実施例における更なる利点および効果は、明細書および図面から明らかにされる。かかる利点および／または効果は、いくつかの実施形態並びに明細書および図面に記載された特徴によってそれぞれ提供されるが、１つまたはそれ以上の同一の特徴を得るために必ずしも全てが提供される必要はない。
以下において、例示的な実施例は添付した図面を参照してより詳細に説明される。
３ＧＰＰ ＮＲシステムのアーキテクチャの一例を示す図
ＮＧ－ＲＡＮと５ＧＣとの間の機能分割を示す概略図
ＲＲＣ接続設定／再設定手順のためのシーケンス図
高速大容量（ｅＭＢＢ：enhanced Mobile Broadband）、多数同時接続（ｍＭＴＣ：massive Machine Type Communications）及び超高信頼低遅延（ＵＲＬＬＣ：Ultra Reliable and Low Latency Communications）の利用シナリオを示す概略図
非ローミングのための５Ｇシステムアーキテクチャの一例を示すブロック図
一実施形態による基地局およびユーザ機器の機能コンポーネントを示すブロック図である。
ＵＥのための例示的な通信方法のステップならびに基地局のための例示的な通信方法のステップを示すブロック図である。
トランスポートブロックの例示的なスケジューリングの概略図である。
設定グラント（ＣＧ：Ｃｏｎｆｉｇｕｒｅｄ Ｇｒａｎｔ）または半永続的スケジューリング（ＳＰＳ：Ｓｅｍｉ Ｐｅｒｓｉｓｔｅｎｔ Ｓｃｈｅｄｕｌｉｎｇ）フレームワークを使用した２つのトランスポートブロックの例示的なスケジューリングの概略図である。
４つの繰り返し送信を伴う２つのトランスポートブロックをスケジューリングするＤＣＩ、およびそれに続く、第１のスロットを示すＣＩが受信されるシナリオの一例の概略図である。
４つの繰り返し送信を伴う２つのトランスポートブロックをスケジューリングするＤＣＩ、およびそれに続く、第１のスロットを示すＣＩが受信されるシナリオの一例の概略図である。
第１の閾値に基づいた、４つのＴＢの優先度の割り当てを示す概略図である。
第１の明示的な優先度通知に基づいた、２つのＴＢの優先度の割り当てを示す概略図である。
＜５Ｇ ＮＲシステムアーキテクチャ及びプロトコルスタック＞
３ＧＰＰは、１００ＧＨｚまでの周波数範囲で動作する新無線アクセス技術（ＮＲ）の開発を含む、第５世代セルラ技術（単純に５Ｇともいう）の次期リリースに取り組んでいる。２０１７年末に５Ｇ規格の初版が完成し、５Ｇ ＮＲ規格に準拠したスマートフォンの試行及び商用展開を進めることができた。
３ＧＰＰは、１００ＧＨｚまでの周波数範囲で動作する新無線アクセス技術（ＮＲ）の開発を含む、第５世代セルラ技術（単純に５Ｇともいう）の次期リリースに取り組んでいる。２０１７年末に５Ｇ規格の初版が完成し、５Ｇ ＮＲ規格に準拠したスマートフォンの試行及び商用展開を進めることができた。
特に、全体的なシステムアーキテクチャは、ｇＮＢを備えるＮＧ－ＲＡＮ（Next Generation-Radio Access Network）を想定する。ｇＮＢは、ＮＧ無線アクセスのユーザプレーン（ＳＤＡＰ／ＰＤＣＰ／ＲＬＣ／ＭＡＣ／ＰＨＹ）及び制御プレーン（ＲＲＣ）プロトコルのＵＥ側の終端を提供する。ｇＮＢは、Ｘｎインタフェースによって相互に接続される。また、ｇＮＢは次世代（ＮＧ：Next Generation）インタフェースによって次世代コア（ＮＧＣ：Next Generation Core）に、より具体的には、ＮＧ－Ｃインタフェースによってアクセス・モビリティ管理機能（ＡＭＦ：Access and Mobility Management Function。例えば、ＡＭＦを実行する特定のコアエンティティ）に、また、ＮＧ－Ｕインタフェースによってユーザプレーン機能（ＵＰＦ：User Plane Function。例えば、ＵＰＦを実行する特定のコアエンティティ）に接続される。ＮＧ－ＲＡＮアーキテクチャは、図１に示される（例えば、３ＧＰＰ ＴＳ ３８．３００ ｖ１５．６．０のセクション４参照）。
ＮＲのユーザプレーンプロトコルスタック（例えば、３ＧＰＰ ＴＳ ３８．３００のセクション４．４．１参照）は、ｇＮＢにおいてネットワーク側で終端されるＰＤＣＰ（Packet Data Convergence Protocol。ＴＳ ３８．３００のセクション６．４参照）サブレイヤ、ＲＬＣ(Radio Link Control。ＴＳ ３８．３００のセクション６．３参照）サブレイヤ、及びＭＡＣ(Medium Access Control。ＴＳ ３８．３００のセクション６．２参照）サブレイヤを含む。さらに、ＰＤＣＰの上位には、新たなアクセス層（ＡＳ：Access Stratum）サブレイヤ（ＳＤＡＰ：Service Data Adaptation Protocol）が導入されている（例えば、３ＧＰＰ ＴＳ ３８．３００のｓｕｂ－ｃｌａｕｓｅ ６．５参照）。また、ＮＲでは制御プレーンのプロトコルスタックも定義されている（例えば、ＴＳ ３８．３００のセクション４．４．２参照）。レイヤ２機能の概要は、ＴＳ ３８．３００のｓｕｂ－ｃｌａｕｓｅ ６に記載されている。ＰＤＣＰサブレイヤ、ＲＬＣサブレイヤ、及びＭＡＣサブレイヤの機能は、それぞれＴＳ ３８．３００のセクション６．４、６．３、及び６．２に記載されている。ＲＲＣレイヤの機能は、ＴＳ ３８．３００のｓｕｂ－ｃｌａｕｓｅ ７に列挙されている。
例えば、ＭＡＣレイヤでは、論理チャネルの多重化や、様々なヌメロロジーの処理を含むスケジューリングやスケジューリング関連の機能を担う。
物理レイヤ（ＰＨＹ：physical layer）は、例えば、符号化、ＰＨＹ ＨＡＲＱ処理、変調、マルチアンテナ処理、及び信号の適切な物理時間－周波数リソースへの配置を担う。また、トランスポートチャネルの物理チャネルへの配置も行う。物理レイヤは、トランスポートチャネルの形式でＭＡＣレイヤにサービスを提供する。物理チャネルは、特定のトランスポートチャネルの送信に使用される時間－周波数リソースの組に対応し、各トランスポートチャネルは、対応する物理チャネルに配置される。例えば、物理チャネルは、上りリンクではＰＲＡＣＨ（Physical Random Access Channel）、ＰＵＳＣＨ（Physical Uplink Shared Channel）及びＰＵＣＣＨ（Physical Uplink Control Channel）となり、下りリンクではＰＤＳＣＨ（Physical Downlink Shared Channel）、ＰＤＣＣＨ（Physical Downlink Control Channel）及びＰＢＣＨ（Physical Broadcast Channel）となる。
ＮＲのユースケース／展開シナリオには、ｅＭＢＢ（enhanced Mobile Broadband）、ＵＲＬＬＣ（Ultra-Reliable Low-Latency Communications）、ｍＭＴＣ（massive Machine Type Communication）などがあり、これらはデータレート、遅延、カバレッジに関して多様な要件を持つ。例えば、ｅＭＢＢでは、ＩＭＴ－Ａｄｖａｎｃｅｄで提供されているものの三倍ほどのピークデータレート（下り２０Ｇｂｐｓ、上り１０Ｇｂｐｓ）および実効（user-experienced）データレートに対応することが求められる。一方、ＵＲＬＬＣでは、より厳しい要件が超低遅延（ユーザプレーンの遅延はＵＬ、ＤＬともに０．５ｍｓ）と高信頼性（１ｍｓ以内に１－１０－５）について課されている。最後に、ｍＭＴＣには、好ましくは、高い接続密度（都市環境では１平方キロメートルあたり１００万台）、悪環境での広いカバレッジ、低コスト機器の超長寿命バッテリー（１５年）が求められる。
したがって、一つのユースケースに適したＯＦＤＭヌメロロジー（例えば、サブキャリア間隔、ＯＦＤＭシンボル長、巡回プレフィクス（ＣＰ）長、スケジューリング間隔あたりのシンボル数）は、他のユースケースには有効でない場合がある。例えば、低遅延サービスは、好ましくは、ｍＭＴＣサービスよりも短いシンボル長（したがって、より大きなサブキャリア間隔）および／またはスケジューリング区間（換言すると、ＴＴＩ）毎のシンボル数が少ないことが求められうる。さらに、チャネルの遅延スプレッドが大きい展開シナリオでは、好ましくは、遅延スプレッドが短いシナリオよりもＣＰ長が長いことが求められうる。同様のＣＰオーバーヘッドを維持するためには、サブキャリア間隔は適宜最適化される必要がある。ＮＲでは、複数の値のサブキャリア間隔をサポートしてもよい。これに対応して、現時点では１５ｋＨｚ、３０ｋＨｚ、６０ｋＨｚ、…、のサブキャリア間隔が検討されている。シンボル長Ｔｕとサブキャリア間隔Δｆは、式Δｆ＝１／Ｔｕによって直接関係づけられる。ＬＴＥシステムと同様、「リソースエレメント」という用語は、１つのＯＦＤＭ／ＳＣ－ＦＤＭＡシンボルの長さに対する一つのサブキャリアで構成される最小のリソース単位を示すのに使用することができる。
新しい無線システム５Ｇ－ＮＲでは、ニューメロロジーおよびキャリアごとに、サブキャリアおよびＯＦＤＭシンボルのリソースグリッドがアップリンクおよびダウンリンクそれぞれについて定義されている。リソースグリッド内の各エレメントはリソースエレメントと呼ばれ、周波数領域の周波数インデックスと、時間領域のシンボル位置とに基づいて識別される（３ＧＰＰ ＴＳ３８．２１１ｖ１６．０．０、例えば、セクション４参照）。例えば、ダウンリンクおよびアップリンクの送信は、持続時間が１０ｍｓのフレームに編成され、各フレームは、持続時間がそれぞれ１ｍｓの１０個のサブフレームから成る。５Ｇ ＮＲの実装では、サブフレームあたりの連続するＯＦＤＭシンボルの数は、サブキャリア間隔の設定によって異なる。例えば、１５ｋＨｚのサブキャリア間隔の場合、サブフレームは１４個のＯＦＤＭシンボルを有する（通常のサイクリックプレフィックスを想定するＬＴＥ準拠の実装と同様）。一方、３０ｋＨｚのサブキャリア間隔の場合、サブフレームは２つのスロットを有し、各スロットは１４個のＯＦＤＭシンボルで構成される。
ＬＴＥニューメロロジー（サブキャリア間隔およびシンボル長）と比較すると、ＮＲは複数の異なるタイプのサブキャリア間隔をサポートし、これらはパラメータμによってラベル付けされる（ＬＴＥでは１５ｋＨｚのサブキャリア間隔しかなく、これはＮＲでのμ＝０に対応する）。ＮＲニューメロロジーのタイプについては、３ＧＰＰ ＴＳ３８．２１１、ｖ１５．７．０にまとめられている。
＜ＮＧ－ＲＡＮと５ＧＣとの間の機能分割＞
図２は、ＮＧ－ＲＡＮと５ＧＣとの間の機能分割を示す。ＮＧ－ＲＡＮ論理ノードは、ｇＮＢ又はｎｇ－ｅＮＢである。５ＧＣには、ＡＭＦ、ＵＰＦ、およびＳＭＦの論理ノードが含まれる。
図２は、ＮＧ－ＲＡＮと５ＧＣとの間の機能分割を示す。ＮＧ－ＲＡＮ論理ノードは、ｇＮＢ又はｎｇ－ｅＮＢである。５ＧＣには、ＡＭＦ、ＵＰＦ、およびＳＭＦの論理ノードが含まれる。
ｇＮＢ及びｎｇ－ｅＮＢは、具体的に、以下の主要な機能を提供する。
・無線ベアラ制御、無線アドミッション制御、接続モビリティ制御、上りリンクおよび下りリンクの双方におけるＵＥへの動的なリソース割り当て（スケジューリング）等の、無線リソース管理機能
・データのＩＰヘッダ圧縮、暗号化、及び完全性保護
・ＵＥから提供された情報からＡＭＦへのルーティングが決定できない場合のＵＥアタッチ時のＡＭＦ選択
・ＵＰＦに向けたユーザプレーンデータのルーティング
・ＡＭＦに向けた制御プレーン情報のルーティング
・接続の設定と解除
・ページングメッセージのスケジューリングと送信
・（ＡＭＦ又はＯＡＭから発信される）システム報知情報のスケジューリングと送信
・モビリティとスケジューリングのための測定および測定報告設定
・上りリンクにおけるトランスポートレベルのパケットマーキング
・セッション管理
・ネットワークスライシングのサポート
・ＱｏＳフロー管理とデータ無線ベアラへの配置
・ＲＲＣ＿ＩＮＡＣＴＩＶＥ状態のＵＥのサポート
・ＮＡＳメッセージの配信機能
・無線アクセスネットワークシェアリング
・デュアルコネクティビティ
・ＮＲとＥ－ＵＴＲＡとの間の緊密な連携
・無線ベアラ制御、無線アドミッション制御、接続モビリティ制御、上りリンクおよび下りリンクの双方におけるＵＥへの動的なリソース割り当て（スケジューリング）等の、無線リソース管理機能
・データのＩＰヘッダ圧縮、暗号化、及び完全性保護
・ＵＥから提供された情報からＡＭＦへのルーティングが決定できない場合のＵＥアタッチ時のＡＭＦ選択
・ＵＰＦに向けたユーザプレーンデータのルーティング
・ＡＭＦに向けた制御プレーン情報のルーティング
・接続の設定と解除
・ページングメッセージのスケジューリングと送信
・（ＡＭＦ又はＯＡＭから発信される）システム報知情報のスケジューリングと送信
・モビリティとスケジューリングのための測定および測定報告設定
・上りリンクにおけるトランスポートレベルのパケットマーキング
・セッション管理
・ネットワークスライシングのサポート
・ＱｏＳフロー管理とデータ無線ベアラへの配置
・ＲＲＣ＿ＩＮＡＣＴＩＶＥ状態のＵＥのサポート
・ＮＡＳメッセージの配信機能
・無線アクセスネットワークシェアリング
・デュアルコネクティビティ
・ＮＲとＥ－ＵＴＲＡとの間の緊密な連携
アクセス・モビリティ管理機能（ＡＭＦ）は、以下の主要な機能を提供する。
・非アクセス層（ＮＡＳ：Non-Access Stratum）シグナリングの終端
・ＮＡＳシグナリングのセキュリティ
・アクセス層（ＡＳ：Access Stratum）セキュリティ制御
・３ＧＰＰアクセスネットワーク間のモビリティのためのコアネットワーク（ＣＮ：Core Network）ノード間シグナリング
・アイドルモードＵＥの到達可能性（ページング再送の制御及び実行を含む）
・登録エリア管理
・システム内モビリティ及びシステム間モビリティのサポート
・アクセス認証
・ローミング権限のチェックを含むアクセス認可
・モビリティ管理制御（加入及びポリシー）
・ネットワークスライシングのサポート
・セッション管理機能（ＳＭＦ：Session Management Function）選択
・非アクセス層（ＮＡＳ：Non-Access Stratum）シグナリングの終端
・ＮＡＳシグナリングのセキュリティ
・アクセス層（ＡＳ：Access Stratum）セキュリティ制御
・３ＧＰＰアクセスネットワーク間のモビリティのためのコアネットワーク（ＣＮ：Core Network）ノード間シグナリング
・アイドルモードＵＥの到達可能性（ページング再送の制御及び実行を含む）
・登録エリア管理
・システム内モビリティ及びシステム間モビリティのサポート
・アクセス認証
・ローミング権限のチェックを含むアクセス認可
・モビリティ管理制御（加入及びポリシー）
・ネットワークスライシングのサポート
・セッション管理機能（ＳＭＦ：Session Management Function）選択
さらに、ユーザプレーン機能（ＵＰＦ）は、以下の主要な機能を提供する。
・ＲＡＴ内／ＲＡＴ間モビリティのアンカーポイント（適用可能時）
・データネットワークとの相互接続のための外部ＰＤＵセッションポイント
・パケットルーティングと転送
・パケット検査およびユーザプレーン部分のポリシールールの強制（Policy rule enforcement）
・トラフィック使用量の報告
・データネットワークへのトラフィックフローのルーティングをサポートする上りリンククラス分類（uplink classifier）
・マルチホームＰＤＵセッションをサポートする分岐点
・パケットフィルタリング、ゲーティング、ＵＬ／ＤＬ（uplink/downlink）レート強化などのユーザプレーンに対するＱｏＳ処理
・上りリンクトラフィック検証（ＳＤＦのＱｏＳフローに対する配置）
・下りリンクパケットバッファリング及び下りリンクデータ通知トリガ
・ＲＡＴ内／ＲＡＴ間モビリティのアンカーポイント（適用可能時）
・データネットワークとの相互接続のための外部ＰＤＵセッションポイント
・パケットルーティングと転送
・パケット検査およびユーザプレーン部分のポリシールールの強制（Policy rule enforcement）
・トラフィック使用量の報告
・データネットワークへのトラフィックフローのルーティングをサポートする上りリンククラス分類（uplink classifier）
・マルチホームＰＤＵセッションをサポートする分岐点
・パケットフィルタリング、ゲーティング、ＵＬ／ＤＬ（uplink/downlink）レート強化などのユーザプレーンに対するＱｏＳ処理
・上りリンクトラフィック検証（ＳＤＦのＱｏＳフローに対する配置）
・下りリンクパケットバッファリング及び下りリンクデータ通知トリガ
最後に、セッション管理機能（ＳＭＦ）は、以下の主要な機能を提供する。
・セッション管理
・ＵＥに対するＩＰアドレスの割り当てと管理
・ＵＰＦの選択と制御
・トラフィックを適切な宛先にルーティングするための、ユーザプレーン機能（ＵＰＦ）におけるトラフィックステアリングの設定
・制御部分のポリシーの強制およびＱｏＳ
・下りリンクデータの通知
・セッション管理
・ＵＥに対するＩＰアドレスの割り当てと管理
・ＵＰＦの選択と制御
・トラフィックを適切な宛先にルーティングするための、ユーザプレーン機能（ＵＰＦ）におけるトラフィックステアリングの設定
・制御部分のポリシーの強制およびＱｏＳ
・下りリンクデータの通知
＜ＲＲＣ接続設定及び再設定手順＞
図３は、ＵＥがＮＡＳ部においてＲＲＣ＿ＩＤＬＥからＲＲＣ＿ＣＯＮＮＥＣＴＥＤに移行する際の、ＵＥと、ｇＮＢと、ＡＭＦ（５ＧＣエンティティ）との間のやり取りの一部を示す（ＴＳ ３８．３００ ｖ１５．６．０を参照）。
図３は、ＵＥがＮＡＳ部においてＲＲＣ＿ＩＤＬＥからＲＲＣ＿ＣＯＮＮＥＣＴＥＤに移行する際の、ＵＥと、ｇＮＢと、ＡＭＦ（５ＧＣエンティティ）との間のやり取りの一部を示す（ＴＳ ３８．３００ ｖ１５．６．０を参照）。
ＲＲＣは、ＵＥおよびｇＮＢの設定に使用される上位レイヤシグナリング（プロトコル）である。この移行は、具体的には、ＡＭＦがＵＥコンテキストデータ（例えば、ＰＤＵセッションコンテキスト、セキュリティキー、ＵＥ無線性能（UE Radio Capability）、ＵＥセキュリティ性能（UE Security Capabilities）等を含む）を準備し、初期コンテキスト設定要求（INITIAL CONTEXT SETUP REQUEST）と共にｇＮＢに送信することを含む。そして、ｇＮＢは、ＵＥと共にＡＳセキュリティを起動する。この動作は、ｇＮＢがＵＥにセキュリティモードコマンド（SecurityModeCommand）メッセージを送信し、ＵＥがセキュリティモード完了（SecurityModeComplete）メッセージでｇＮＢに応答することによって行われる。その後、ｇＮＢは、ＵＥにＲＲＣ再設定（RRCReconfiguration）メッセージを送信し、これに対するＵＥからのＲＲＣ再設定完了（RRCReconfigurationComplete）をｇＮＢが受信することによって、シグナリング無線ベアラ２（ＳＲＢ２：Signaling Radio Bearer 2）およびデータ無線ベアラ（ＤＲＢ：Data Radio Bearer）を設定するための再構成を実行する。シグナリングのみの接続の場合、ＳＲＢ２およびＤＲＢは設定されないので、ＲＲＣ再構成に関連するステップは省略される。最後に、ｇＮＢは、設定手順が完了したことを、初期コンテキスト設定応答（INITIAL CONTEXT SETUP RESPONSE）でＡＭＦに通知する。
そこで、本開示では、ｇＮｏｄｅＢとの次世代（ＮＧ）接続を動作時に確立する制御回路と、ｇＮｏｄｅＢと端末（ＵＥ）との間のシグナリング無線ベアラが設定されるように動作時にＮＧ接続を介して初期コンテキスト設定メッセージをｇＮｏｄｅＢに送信する送信部とを備える、第５世代コア（５ＧＣ）のエンティティ（例えば、ＡＭＦ、ＳＭＦ等）が提供される。具体的には、ｇＮｏｄｅＢは、シグナリング無線ベアラを介して、リソース割り当て設定情報エレメントを含む無線リソース制御（ＲＲＣ：Radio Resource Control）シグナリングをＵＥに送信する。そして、ＵＥは、リソース割り当て設定に基づいて、上りリンクの送信または下りリンクの受信を行う。
＜２０２０年以降のＩＭＴの利用シナリオ＞
図４は、５Ｇ ＮＲのユースケースの一部を示す。第３世代パートナーシッププロジェクトＮＲ（３ＧＰＰ ＮＲ）では、ＩＭＴ－２０２０によって多種多様なサービスやアプリケーションに対応することが想定されている三つのユースケースが検討されている。高速大容量（ｅＭＢＢ）のための第一段階の仕様の策定は終了している。ｅＭＢＢのサポートをさらに拡充することに加え、現在および将来的には、超高信頼低遅延（ＵＲＬＬＣ）および多数同時接続の標準化の研究も進められる。図４は、２０２０年以降のＩＭＴで想定される利用シナリオの例を示す（例えば、ＩＴＵ－Ｒ Ｍ．２０８３の図２を参照）。
図４は、５Ｇ ＮＲのユースケースの一部を示す。第３世代パートナーシッププロジェクトＮＲ（３ＧＰＰ ＮＲ）では、ＩＭＴ－２０２０によって多種多様なサービスやアプリケーションに対応することが想定されている三つのユースケースが検討されている。高速大容量（ｅＭＢＢ）のための第一段階の仕様の策定は終了している。ｅＭＢＢのサポートをさらに拡充することに加え、現在および将来的には、超高信頼低遅延（ＵＲＬＬＣ）および多数同時接続の標準化の研究も進められる。図４は、２０２０年以降のＩＭＴで想定される利用シナリオの例を示す（例えば、ＩＴＵ－Ｒ Ｍ．２０８３の図２を参照）。
ＵＲＬＬＣのユースケースは、スループット、遅延、アベイラビリティ等の性能に対する厳しい要件を有し、工業生産や製造プロセスの無線制御、遠隔医療手術、スマートグリッドの配電自動化、交通安全等、将来の垂直アプリケーションを実現するものの一つとして想定されている。ＵＲＬＬＣの超高信頼性は、ＴＲ ３８．９１３によって設定された要件を満たす技術を特定することでサポートされる。リリース１５におけるＮＲ ＵＲＬＬＣの場合、ＵＬ（上りリンク）０．５ｍｓ、ＤＬ（下りリンク）０．５ｍｓのユーザプレーン遅延を目標とすることが主要な要件である。一度のパケット送信に対する一般的なＵＲＬＬＣの要件は、ユーザプレーン遅延が１ｍｓの場合、３２バイトのパケットサイズに対してブロック誤り率（ＢＬＥＲ：block error rate）が１Ｅ－５であることである。
物理レイヤの観点から、信頼性を向上させるには様々な方法がある。現在、信頼性を向上させるためには、ＵＲＬＬＣ用の独立したＣＱＩテーブル、よりコンパクトなＤＣＩフォーマット、ＰＤＣＣＨの繰り返し等を定義することが考えられる。しかし、ＮＲが（ＮＲ ＵＲＬＣの主要要件に対して）より安定し、かつより発展するにつれて、超高信頼性を達成するために考えられる方法の範囲は広がり得る。リリース１５におけるＮＲ ＵＲＬＬＣ特有のユースケースには、拡張現実／仮想現実（ＡＲ／ＶＲ）、ｅ－ヘルス、ｅ－セーフティ、及びミッションクリティカルアプリケーションが含まれる。
また、ＮＲ ＵＲＬＬＣが目標とする技術強化は、遅延の改善と信頼性の向上である。遅延改善のための技術強化には、設定可能なヌメロロジー、フレキシブルなマッピングによる非スロットベースのスケジューリング、グラントフリーの（設定されたグラントの）上りリンク、データチャネルのスロットレベルの繰り返し、および下りリンクのプリエンプション（pre-emption）が含まれる。プリエンプションとは、すでにリソースが割り当てられている送信を停止し、すでに割り当てられている当該リソースを、後から要求された、より少ない遅延や高い優先度を必要とする別の送信に使用することを意味する。したがって、すでに許可されていた送信は、後の送信によって差し替えられる。プリエンプションは、特定のサービスタイプとは無関係に適用できる。例えば、サービスタイプＡ（ＵＲＬＬＣ）の送信は、サービスタイプＢ（例えばｅＭＢＢ）の送信によってプリエンプトされてよい。信頼性向上に関する技術強化には、目標ＢＬＥＲ １Ｅ－５のための専用ＣＱＩ／ＭＣＳテーブルが含まれる。
ｍＭＴＣ（多数同時接続）のユースケースの特徴は、典型的には遅延の影響を受けにくい比較的少量のデータを送信する接続装置の数が極めて多いことである。デバイスは低コストで、非常に長いバッテリー寿命を持つことが要求される。ＮＲの観点からは、非常に狭い帯域幅部分を利用することが、ＵＥにとっての省電力化と、バッテリーの長寿命化を可能にする一つの策である。
上述のように、ＮＲにおける信頼性向上の範囲はより広くなることが予想される。あらゆるケースに共通する重要な要件の一つであり、特にＵＲＬＬＣとｍＭＴＣに必要な要件は、高信頼性または超高信頼性である。信頼性を向上させるには、無線の観点やネットワークの観点から、いくつかのメカニズムが考えられる。一般的に、信頼性の向上に役立ついくつかの重要な領域がある。これらの領域には、コンパクトな制御チャネル情報、データ／制御チャネルの繰り返し、周波数領域、時間領域、空間領域におけるダイバーシティなどがある。これらの領域は、特定の通信シナリオに関わらず、一般的に、信頼性向上に適用可能である。
ＮＲ ＵＲＬＬＣについては、ファクトリーオートメーション、輸送産業、配電など、より厳しい要件を持つさらなるユースケースが特定されている。より厳しい要件とは、ユースケースに応じた、高い信頼性（最大１０－６レベル）、高いアベイラビリティ、最大２５６バイトのパケットサイズ、数μｓ程度までの時刻同期（周波数範囲および０．５～１ｍｓ程度の短い遅延（例えば、目標とするユーザプレーンでの０．５ｍｓの遅延）に応じて１μｓまたは数μｓとすることができる）である。
さらに、ＮＲ ＵＲＬＬＣでは、物理レイヤの観点からいくつかの技術強化が確認されている。これらの中には、コンパクトなＤＣＩに関するＰＤＣＣＨ（Physical Downlink Control Channel）の強化、ＰＤＣＣＨの繰り返し、ＰＤＣＣＨのモニタリングの増加がある。また、上りリンク制御情報（ＵＣＩ：Uplink Control Information）の強化は、拡張ＨＡＲＱ（Hybrid Automatic Repeat Request）とＣＳＩフィードバックの強化に関係する。また、ミニスロットレベルのホッピングに関連するＰＵＳＣＨの強化や再送／繰り返しの強化も確認されている。「ミニスロット」とは、スロット（１４シンボルで構成されるスロット）よりも少ない数のシンボルを含む送信時間間隔（ＴＴＩ）を表す。
＜ＱｏＳの制御＞
５ＧのＱｏＳ（Quality of Service）モデルは、ＱｏＳフローに基づいており、保証されたフロービットレートが求められるＱｏＳフロー（ＧＢＲ ＱｏＳフロー）と、保証されたフロービットレートが求められないＱｏＳフロー（非ＧＢＲ ＱｏＳフロー）の両方に対応している。そのため、ＮＡＳレベルでは、ＱｏＳフローはＰＤＵセッションにおける最も微細な粒度のＱｏＳの区分である。ＱｏＳフローは、ＮＧ－Ｕインタフェースを介してカプセル化ヘッダにおいて搬送されるＱｏＳフローＩＤ（ＱＦＩ）によってＰＤＵセッション内で識別される。
５ＧのＱｏＳ（Quality of Service）モデルは、ＱｏＳフローに基づいており、保証されたフロービットレートが求められるＱｏＳフロー（ＧＢＲ ＱｏＳフロー）と、保証されたフロービットレートが求められないＱｏＳフロー（非ＧＢＲ ＱｏＳフロー）の両方に対応している。そのため、ＮＡＳレベルでは、ＱｏＳフローはＰＤＵセッションにおける最も微細な粒度のＱｏＳの区分である。ＱｏＳフローは、ＮＧ－Ｕインタフェースを介してカプセル化ヘッダにおいて搬送されるＱｏＳフローＩＤ（ＱＦＩ）によってＰＤＵセッション内で識別される。
各ＵＥに対して、５ＧＣは、１つまたは複数のＰＤＵセッションを確立する。各ＵＥに対して、ＮＧ－ＲＡＮは、ＰＤＵセッションに合わせて少なくとも一つのデータ無線ベアラ（ＤＲＢ）を確立し、そのＰＤＵセッションのＱｏＳフローに対する追加のＤＲＢは、例えば、図３を参照して上述したように、後から設定可能である（いつ設定するかはＮＧ－ＲＡＮ次第である）。ＮＧ－ＲＡＮは、異なるＰＤＵセッションに属するパケットを異なるＤＲＢに配置する。ＵＥと５ＧＣにおけるＮＡＳレベルパケットフィルタは、ＵＬパケットとＤＬのパケットとをＱｏＳフローに関連付けるのに対し、ＵＥとＮＧ－ＲＡＮのＡＳレベルマッピングルールは、ＵＬのＱｏＳフローとＤＬのＱｏＳフローとをＤＲＢに関連付ける。
図５は、５Ｇ ＮＲの非ローミング参照アーキテクチャを示す（ＴＳ ２３．５０１ ｖ１６．１．０、セクション４．２３参照）。図４に例示される、５Ｇサービスをホストする外部アプリケーションサーバなどのアプリケーション機能（ＡＦ）は、サービスを提供するために３ＧＰＰコアネットワークとやり取りを行う。例えば、トラフィックルーティングに影響を与えるアプリケーションをサポートするためにネットワーク公開機能（ＮＥＦ：Network Exposure Function）にアクセスすること、ＱｏＳ制御などのポリシー制御のためにポリシーフレームワークとやり取りすること（ポリシー制御機能（ＰＣＦ）参照）が挙げられる。オペレータによる配備に基づき、オペレータから信頼されているとみなされるアプリケーション機能は、関連するネットワーク機能と直接やり取りすることができる。ネットワーク機能への直接のアクセスをオペレータから許可されていないアプリケーション機能は、ＮＥＦを介して外部に対する開放フレームワークを使用して、関連するネットワーク機能とやり取りする。
図５は、５Ｇアーキテクチャのさらなる機能ユニット、すなわち、ネットワークスライス選択機能（ＮＳＳＦ：Network Slice Selection Function）、ネットワークリポジトリ機能（ＮＲＦ：Network Repository Function）、統合データ管理（ＵＤＭ：Unified Data Management）、認証サーバ機能（ＡＵＳＦ：Authentication Server Function）、アクセス・モビリティ管理機能（ＡＭＦ）、セッション管理機能（ＳＭＦ）、及びデータネットワーク（ＤＮ）（オペレータによるサービス、インターネットアクセス、サードパーティによるサービス等）を示している。すべて又は一部のコアネットワーク機能及びアプリケーションサービスは、クラウドコンピューティング環境上に展開されかつ動作してもよい。
したがって、本開示では、ＱｏＳ要件に応じたｇＮｏｄｅＢとＵＥとの間の無線ベアラを含むＰＤＵセッションを確立するために、動作時に、ＵＲＬＬＣ、ｅＭＢＢおよびｍＭＴＣサービスのうちの少なくとも一つに対するＱｏＳ要件を含む要求を、５ＧＣの機能（例えば、ＮＥＦ、ＡＭＦ、ＳＭＦ、ＰＣＦ、ＵＰＦ等）の少なくとも一つに送信する送信部と、動作時に、確立されたＰＤＵセッションを使用してサービスを実行する制御回路と、を備えるアプリケーションサーバ（例えば、５ＧアーキテクチャのＡＦ）が提供される。
＜ＲＲＣ状態（ＲＲＣ＿Ｃｏｎｎｅｃｔｅｄ、ＲＲＣ＿Ｉｎａｃｔｉｖｅ）＞
ＬＴＥでは、ＲＲＣステートマシンは、ＲＲＣアイドル状態（高い省電力性、ＵＥ自律モビリティ、およびコアネットワークへのＵＥ接続が確立されていないことを主に特徴とする）と、無損失のサービスの継続性をサポートするようにモビリティがネットワーク制御されながらＵＥがユーザプレーンデータを送信できるＲＲＣ接続状態と、の２つの状態のみから成っていた。５Ｇ ＮＲに関連して、ＬＴＥ関連のＲＲＣステートマシンも、以下で説明するＮＲ ５Ｇと同様に、非アクティブ状態で拡張され得る（例えば、ＴＳ３８．３３１ｖ１５．８．０、図４．２．１－２参照）。
ＬＴＥでは、ＲＲＣステートマシンは、ＲＲＣアイドル状態（高い省電力性、ＵＥ自律モビリティ、およびコアネットワークへのＵＥ接続が確立されていないことを主に特徴とする）と、無損失のサービスの継続性をサポートするようにモビリティがネットワーク制御されながらＵＥがユーザプレーンデータを送信できるＲＲＣ接続状態と、の２つの状態のみから成っていた。５Ｇ ＮＲに関連して、ＬＴＥ関連のＲＲＣステートマシンも、以下で説明するＮＲ ５Ｇと同様に、非アクティブ状態で拡張され得る（例えば、ＴＳ３８．３３１ｖ１５．８．０、図４．２．１－２参照）。
ＮＲ ５ＧのＲＲＣ（ＴＳ３８．３３１ｖ１５．８．０、セクション４参照）は、ＲＲＣアイドル、ＲＲＣ非アクティブ、およびＲＲＣ接続の３つの状態をサポートする。ＲＲＣ接続が確立されると、ＵＥはＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態またはＲＲＣ＿ＩＮＡＣＴＩＶＥ状態のいずれかになる。そうでない場合、すなわち、ＲＲＣ接続が確立されていない場合、ＵＥはＲＲＣ＿ＩＤＬＥ状態である。その後、以下の状態遷移が起こり得る。
・例えば、「接続確立」手順に従って、ＲＲＣ＿ＩＤＬＥからＲＲＣ＿ＣＯＮＮＥＣＴＥＤへ
・例えば、「接続リリース」手順に従って、ＲＲＣ＿ＣＯＮＮＥＣＴＥＤからＲＲＣ＿ＩＤＬＥへ
・例えば、「一時停止による接続リリース」手順に従って、ＲＲＣ＿ＣＯＮＮＥＣＴＥＤからＲＲＣ＿ＩＮＡＣＴＩＶＥへ
・例えば、「接続再開」手順に従って、ＲＲＣ＿ＩＮＡＣＴＩＶＥからＲＲＣ＿ＣＯＮＮＥＣＴＥＤへ
・例えば、「接続リリース」手順に従って、ＲＲＣ＿ＩＮＡＣＴＩＶＥからＲＲＣ＿ＩＤＬＥへ（一方向）
・例えば、「接続確立」手順に従って、ＲＲＣ＿ＩＤＬＥからＲＲＣ＿ＣＯＮＮＥＣＴＥＤへ
・例えば、「接続リリース」手順に従って、ＲＲＣ＿ＣＯＮＮＥＣＴＥＤからＲＲＣ＿ＩＤＬＥへ
・例えば、「一時停止による接続リリース」手順に従って、ＲＲＣ＿ＣＯＮＮＥＣＴＥＤからＲＲＣ＿ＩＮＡＣＴＩＶＥへ
・例えば、「接続再開」手順に従って、ＲＲＣ＿ＩＮＡＣＴＩＶＥからＲＲＣ＿ＣＯＮＮＥＣＴＥＤへ
・例えば、「接続リリース」手順に従って、ＲＲＣ＿ＩＮＡＣＴＩＶＥからＲＲＣ＿ＩＤＬＥへ（一方向）
新しいＲＲＣ状態であるＲＲＣ非アクティブは、シグナリング、省電力、遅延などの点で大きく異なる要件を有する、ｅＭＢＢ（拡張モバイルブロードバンド）、ｍＭＴＣ（大規模マシンタイプ通信）、ＵＲＬＬＣ（超高信頼・低遅延通信）などのより幅広いサービスをサポートする際に利点をもたらすように、５Ｇ ３ＧＰＰの新しい無線技術用に定義されている。このため、新しいＲＲＣ非アクティブ状態は、無線アクセスネットワークおよびコアネットワークでのシグナリング、電力消費、およびリソースコストの最小化を可能にしつつ、なおも低遅延でのデータ転送の開始などを可能にするように設計されなければならない。
＜帯域幅パート＞
ＮＲシステムは、ＬＴＥの２０ＭＨｚよりもはるかに広い最大チャネル帯域幅（例えば、数百ＭＨｚ）をサポートする。ＬＴＥでは、最大２０ＭＨｚのコンポーネントキャリアのキャリアアグリゲーション（ＣＡ：ｃａｒｒｉｅｒ ａｇｇｒｅｇａｔｉｏｎ）による広帯域通信もサポートされている。ＮＲにおいてより広いチャネル帯域幅を定義することにより、スケジューリングを介して周波数リソースを動的に割り当てることが可能になり、これは、アクティブ化／非アクティブ化がＭＡＣ制御エレメントに基づくＬＴＥのキャリアアグリゲーション動作よりも効率的かつ柔軟であり得る。単一の広帯域キャリアを有することは、単一の制御シグナリングしか必要としないので、制御オーバーヘッドが低いという点でもメリットがある（キャリアアグリゲーションでは、集約されるキャリアごとに個別の制御シグナリングが必要である）。
ＮＲシステムは、ＬＴＥの２０ＭＨｚよりもはるかに広い最大チャネル帯域幅（例えば、数百ＭＨｚ）をサポートする。ＬＴＥでは、最大２０ＭＨｚのコンポーネントキャリアのキャリアアグリゲーション（ＣＡ：ｃａｒｒｉｅｒ ａｇｇｒｅｇａｔｉｏｎ）による広帯域通信もサポートされている。ＮＲにおいてより広いチャネル帯域幅を定義することにより、スケジューリングを介して周波数リソースを動的に割り当てることが可能になり、これは、アクティブ化／非アクティブ化がＭＡＣ制御エレメントに基づくＬＴＥのキャリアアグリゲーション動作よりも効率的かつ柔軟であり得る。単一の広帯域キャリアを有することは、単一の制御シグナリングしか必要としないので、制御オーバーヘッドが低いという点でもメリットがある（キャリアアグリゲーションでは、集約されるキャリアごとに個別の制御シグナリングが必要である）。
また、ＬＴＥと同様に、ＮＲはキャリアアグリゲーションまたはデュアルコネクティビティを介した複数のキャリアのアグリゲーションもサポートし得る。
ＵＥは常に高速なデータレートを要求するわけではないので、広い帯域幅を使用すると、ＲＦおよびベースバンド信号処理の両方の観点からアイドリング消費電力が高くなり得る。この点に関して、ＮＲ用に新しく開発された帯域幅パートの概念は、設定されたチャネル帯域幅よりも狭い帯域幅でＵＥを動作させる手段を提供することによって、広帯域動作をサポートするにもかかわらずエネルギー効率の高いソリューションを提供する。ＮＲの全帯域幅にアクセスできないこのローエンドの端末は、その恩恵を受けることができる。
帯域幅パート（ＢＷＰ：ｂａｎｄｗｉｄｔｈ ｐａｒｔ）は、セルの総セル帯域幅のサブセットであり、例えば、隣接する物理リソースブロック（ＰＲＢ：ｐｈｙｓｉｃａｌ ｒｅｓｏｕｒｃｅ ｂｌｏｃｋ）の位置および数である。これはアップリンクおよびダウンリンクで別々に定義され得る。さらに、各帯域幅パートは特定のＯＦＤＭニューメロロジーに、例えば、サブキャリア間隔およびサイクリックプレフィックスに関連付けることができる。例えば、ＵＥにＢＷＰ（複数可）を設定し、設定されたＢＷＰのいずれが現在アクティブであるかをＵＥに伝えることによって、帯域幅適応が実現される。
例示的には、５Ｇ ＮＲでは、ＲＲＣ＿Ｃｏｎｎｅｃｔｅｄ状態のＵＥに対してのみ特定のＢＷＰが設定される。例えば、初期ＢＷＰ（例えば、ＵＬ用およびＤＬ用に１つずつ）以外に、ＢＷＰは接続状態のＵＥに対してのみ存在する。ＵＥをＲＲＣ＿ＩＤＬＥまたはＲＲＣ＿ＩＮＡＣＴＩＶＥ状態からＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態に移行させる過程などで、ＵＥとネットワークとの間の初期データ交換をサポートするために、初期ＤＬ ＢＷＰおよび初期ＵＬ ＢＷＰが最小ＳＩで設定される。
ＵＥには２つ以上のＢＷＰを設定することができるが（例えば、現在ＮＲで定義されているように、サービングセルあたり最大４つのＢＷＰ）、ＵＥは一度に１つのアクティブＤＬ ＢＷＰしか有さない。
設定されたＢＷＰ間の切り替えは、ダウンリンク制御情報（ＤＣＩ）により実現され得る。
プライマリセル（ＰＣｅｌｌ：Ｐｒｉｍａｒｙ Ｃｅｌｌ）の場合、初期ＢＷＰは初期アクセスに使用されるＢＷＰであり、他の初期ＢＷＰが明示的に設定されていない限り、デフォルトのＢＷＰが初期ＢＷＰである。セカンダリセル（ＳＣｅｌｌ：Ｓｅｃｏｎｄａｒｙ Ｃｅｌｌ）の場合、初期ＢＷＰは常に明示的に設定され、デフォルトのＢＷＰも設定され得る。サービングセルにデフォルトのＢＷＰが設定されている場合、そのセルに関連付けられた非アクティブタイマが切れると、アクティブなＢＷＰがデフォルトのＢＷＰに切り替えられる。
典型的には、ダウンリンク制御情報にはＢＷＰ ＩＤが含まれていないことが想定される。
＜ダウンリンク制御情報（ＤＣＩ）＞
例えば、制御情報ならびにユーザトラフィック（例えば、ＰＤＣＣＨ上のＤＣＩ、およびＰＤＣＣＨによって示されるＰＤＳＣＨ上のユーザデータ）などのＵＥ向けの情報を識別および受信するために、ＵＥによってＰＤＣＣＨ監視が行われる。
例えば、制御情報ならびにユーザトラフィック（例えば、ＰＤＣＣＨ上のＤＣＩ、およびＰＤＣＣＨによって示されるＰＤＳＣＨ上のユーザデータ）などのＵＥ向けの情報を識別および受信するために、ＵＥによってＰＤＣＣＨ監視が行われる。
ダウンリンクの制御情報（ダウンリンク制御情報ＤＣＩと呼ばれ得る）は、５Ｇ ＮＲでの目的がＬＴＥでのＤＣＩと同じであり、すなわち、ダウンリンクデータチャネル（ＰＤＳＣＨなど）またはアップリンクデータチャネル（ＰＵＳＣＨなど）をスケジューリングする特別な制御情報のセットである。５Ｇ ＮＲでは、いくつかの異なる定義済みのＤＣＩフォーマットがある（ＴＳ３８．２１２ｖ１６．０．０セクション７．３．１参照）。概要を以下の表に示す。
ＰＤＣＣＨサーチスペースは、ＰＤＣＣＨ（ＤＣＩ）が搬送され得るダウンリンクリソースグリッド（時間－周波数リソース）内のエリアである。大まかに言えば、基地局がダウンリンクで制御情報を１つまたは複数のＵＥに送信するために無線リソース領域が使用される。ＵＥはサーチスペース全体でブラインド復号を実行して、ＰＤＣＣＨデータ（ＤＣＩ）を見つけようとする。概念的には、５Ｇ ＮＲでのサーチスペースの概念は、詳細に関して多くの違いがあるものの、ＬＴＥのサーチスペースに類似している。
５Ｇ ＮＲでは、制御リソースセット（ＣＯＲＥＳＥＴ：ｃｏｎｔｒｏｌ ｒｅｓｏｕｒｃｅ ｓｅｔ）と呼ばれる無線リソース領域においてＰＤＣＣＨが送信される。ＬＴＥでは、ＣＯＲＥＳＥＴの概念は明示的には存在しない。代わりに、ＬＴＥのＰＤＣＣＨは、最初の１～３個のＯＦＤＭシンボル（最も狭帯域の場合は４個）における全キャリア帯域幅を使用する。対照的に、ＮＲのＣＯＲＥＳＥＴはスロット内の任意の位置およびキャリアの周波数範囲内の任意の場所に存在し得るが、ＵＥがそのアクティブな帯域幅パート（ＢＷＰ）外でＣＯＲＥＳＥＴをハンドリングすることは想定されていない。ＣＯＲＥＳＥＴは、物理無線リソースのセット（例えば、ＮＲダウンリンクリソースグリッド上の特定のエリア）、およびＰＤＣＣＨ／ＤＣＩを搬送するために使用されるパラメータのセットである。
したがって、ＵＥは、対応するサーチスペースセットを使用したＰＤＣＣＨ監視が設定された、アクティブ化されたサービングセルごとのアクティブＤＬ ＢＷＰ上の１つまたは複数のＣＯＲＥＳＥＴにおけるＰＤＣＣＨ候補のセットを監視し、監視は、例えば、３ＧＰＰ ＴＳ３８．２１３バージョン１６．０．０、セクション１０および１１で定義された、監視されたＤＣＩフォーマットに従って各ＰＤＣＣＨ候補を復号することを意味する。
簡潔に言えば、サーチスペースは、同じ集約レベルに関連付けられた複数のＰＤＣＣＨ候補を含み得る（例えば、ＰＤＣＣＨ候補は、監視するＤＣＩフォーマットに関して異なる）。そして、サーチスペースセットは、異なる集約レベルの複数のサーチスペースを含むが、同じＣＯＲＥＳＥＴに関連付けられ得る。上述のように、制御チャネルがキャリア帯域幅全体に広がるＬＴＥとは異なり、ＣＯＲＥＳＥＴの帯域幅は、例えば、アクティブなＤＬ周波数帯域幅パート（ＢＷＰ）内に設定することができる。言い換えれば、ＣＯＲＥＳＥＴ設定は、サーチスペースセットの、ひいてはそのセットに含まれるサーチスペースのＰＤＣＣＨ候補の周波数リソースを定義する。ＣＯＲＥＳＥＴ設定は、サーチスペースセットの持続時間も定義し、この長さは１～３個のＯＦＤＭシンボルにすることができる。一方、開始時間は、サーチスペースセット設定自体によって設定され、例えば、そのＯＦＤＭシンボルから、ＵＥはセットのサーチスペースのＰＤＣＣＨの監視を開始する。組み合わせで、サーチスペースセットの設定およびＣＯＲＥＳＥＴの設定は、ＵＥのＰＤＣＣＨ監視要件に関する周波数および時間領域での明確な定義を提供する。ＣＯＲＥＳＥＴおよびサーチスペースセットの両方の設定は、ＲＲＣシグナリングを介して半静的に設定することができる。
最初のＣＯＲＥＳＥＴであるＣＯＲＥＳＥＴ０が、マスター情報ブロック（ＭＩＢ：ｍａｓｔｅｒ ｉｎｆｏｒｍａｔｉｏｎ ｂｌｏｃｋ）により初期帯域幅パートの設定の一部として提供され、ネットワークから残りのシステム情報および追加の設定情報を受信することが可能になる。接続設定後、ＲＲＣシグナリングを使用して、複数の、場合によっては重なり合うＣＯＲＥＳＥＴをＵＥに設定することができる。
ネットワークは、共通の制御領域およびＵＥ固有の制御領域を定義し得る。ＮＲでは、ＣＯＲＥＳＥＴの数は、共通のＣＯＲＥＳＥＴとＵＥ別のＣＯＲＥＳＥＴとの両方を含めて、ＢＷＰあたり３つに制限されている。各サービングセルに４つのＢＷＰが設定可能であると例示的に仮定すると、サービングセルあたりのＣＯＲＥＳＥＴの最大数は１２になる。一般に、ＢＷＰあたりのサーチスペースの数は、例えば、現在のＮＲと同様に１０に制限することができ、ＢＷＰあたりのサーチスペースの最大数は４０になる。各サーチスペースはＣＯＲＥＳＥＴに関連付けられる。
共通のＣＯＲＥＳＥＴはセル内の複数のＵＥによって共有されるので、ネットワークはこれに対応して、この設定のための全てのＵＥとの調整に対応する必要がある。共通のＣＯＲＥＳＥＴは、ランダムアクセス、ページング、およびシステム情報に使用することができる。
ＮＲでは、半静的なダウンリンク／アップリンク割り当て方式でのセル別および／またはＵＥ別の上位レイヤシグナリングによって、またはグループ共通のＰＤＣＣＨ（ＧＣ－ＰＤＣＣＨ：ｇｒｏｕｐ－ｃｏｍｍｏｎ ＰＤＣＣＨ）内のＤＣＩフォーマット２＿０などを介した動的なシグナリングによって、ＵＥに対して柔軟なスロットフォーマットを設定することができる。動的なシグナリングが設定されている場合、ＵＥは動的スロットフォーマット通知（ＳＦＩ：ｓｌｏｔ ｆｏｒｍａｔ ｉｎｄｉｃａｔｉｏｎ）を搬送するＧＣ－ＰＤＣＣＨ（ＤＣＩフォーマット２＿０）を監視する。
一般に、共通のＣＯＲＥＳＥＴおよびＵＥ別のＣＯＲＥＳＥＴの両方を含む１つまたは複数のＣＯＲＥＳＥＴがＢＷＰごとに設定され得る（例えば、ＢＷＰごとに最大３つのＣＯＲＥＳＥＴ）。そして、各ＣＯＲＥＳＥＴは複数のサーチスペースを有することができ、各サーチスペースはＵＥが監視できる１つまたは複数のＰＤＣＣＨ候補を有する。
＜５Ｇ ＮＲでの時間領域スケジューリング＞
時間領域において、５Ｇ ＮＲでの送信は長さ１０ｍｓのフレームに編成され、各フレームは、長さ１ｍｓの１０個の等サイズのサブフレームに分割される。そして、サブフレームは、それぞれ１４個のＯＦＤＭシンボルから成るスロットに分割される。ミリ秒単位のスロットの持続時間は、ニューメロロジーによって異なる。このため、例えば、１５ｋＨｚのサブキャリア間隔の場合、ＮＲスロットは通常のサイクリックプレフィックスを有するＬＴＥサブフレームと同じ構造を有する。ＮＲのサブフレームはニューメロロジーに依存しない時間基準として機能し、これは、スロットが典型的な動的スケジューリングの単位であるのに対し、同じキャリアで複数のニューメロロジーが混合されている場合に特に有用である。
時間領域において、５Ｇ ＮＲでの送信は長さ１０ｍｓのフレームに編成され、各フレームは、長さ１ｍｓの１０個の等サイズのサブフレームに分割される。そして、サブフレームは、それぞれ１４個のＯＦＤＭシンボルから成るスロットに分割される。ミリ秒単位のスロットの持続時間は、ニューメロロジーによって異なる。このため、例えば、１５ｋＨｚのサブキャリア間隔の場合、ＮＲスロットは通常のサイクリックプレフィックスを有するＬＴＥサブフレームと同じ構造を有する。ＮＲのサブフレームはニューメロロジーに依存しない時間基準として機能し、これは、スロットが典型的な動的スケジューリングの単位であるのに対し、同じキャリアで複数のニューメロロジーが混合されている場合に特に有用である。
以下では、３ＧＰＰ技術仕様で現在実装されている時間領域リソース割り当てについて示す。以下の説明は、時間領域リソース割り当ての特定の例示的な実装として理解されるべきであり、可能性のある唯一の可能な時間領域リソース割り当てとして理解されるべきではない。それどころか、本開示および解決策は、将来実装され得る時間領域リソース割り当ての異なる実装に対応する方法で適用される。例えば、以下のＴＤＲＡテーブルは特定のパラメータ（例えば、５つのパラメータ）に基づいているが、時間領域リソース割り当ては、異なる数のパラメータおよび／または異なるパラメータにも基づいてもよい。
受信または送信されるデータへの時間領域割り当てはＤＣＩで動的にシグナリングされ、これは、動的ＴＤＤの使用、またはアップリンク制御シグナリングに使用されるリソースの量の結果としてダウンリンク受信またはアップリンク送信に利用可能なスロットの部分がスロットごとに異なり得るという点で有用である。送信が発生するスロットは、時間領域割り当ての一部としてシグナリングされる。ダウンリンクデータは多くの場合、対応するリソース割り当てと同じスロットで送信されるが、これはアップリンク送信には当てはまらないことが多い。
ＵＥがＤＣＩによってＰＤＳＣＨを受信またはＰＵＳＣＨを送信するようにスケジューリングされる場合、ＤＣＩの時間領域リソース割り当て（ＴＤＲＡ：Ｔｉｍｅ Ｄｏｍａｉｎ Ｒｅｓｏｕｒｃｅ Ａｓｓｉｇｎｍｅｎｔ）フィールド値は、時間領域リソース割り当て（ＴＤＲＡ：ｔｉｍｅ－ｄｏｍａｉｎ ｒｅｓｏｕｒｃｅ ａｌｌｏｃａｔｉｏｎ）テーブルの行インデックスを示す。ＴＤＲＡエントリが、対応する３ＧＰＰ技術仕様ではテーブルとして提示されているので、「テーブル」という用語を本明細書では使用するが、これは論理上の、どちらかと言えば非限定的な用語として解釈されたい。具体的には、本開示はいかなる特定の編成にも限定されず、ＴＤＲＡテーブルは、それぞれのエントリインデックスに関連付けられたパラメータのセットとして任意の方法で実装され得る。
例えば、ＤＣＩによってインデックス付けされたＴＤＲＡテーブルの行は、時間領域での無線リソースの割り当てに使用できるいくつかのパラメータを定義する。現在の例では、ＴＤＲＡテーブルは、スロットオフセットＫ０／Ｋ２、開始および長さインジケータＳＬＩＶ（ｓｔａｒｔ ａｎｄ ｌｅｎｇｔｈ ｉｎｄｉｃａｔｏｒ）、または直接的に開始シンボルＳおよび割り当て長Ｌを示すことができる。さらに、ＴＤＲＡテーブルはまた、ＰＤＳＣＨ受信で想定されるＰＤＳＣＨマッピングタイプと、スケジューリングされた時間領域無線リソースに直接関係しないｄｍｒｓ－ＴｙｐｅＡ－Ｐｏｓｉｔｉｏｎパラメータとを示し得る。ＤＣＩの時間領域割り当てフィールドはこのテーブルへのインデックスとして使用され、そこから実際の時間領域割り当てが取得される。このため、そのような例示的な実装では、ＴＤＲＡテーブルの行のＤＣＩ通知（行インデックスの１つの値）は、ｄｍｒｓ－ＴｙｐｅＡ－Ｐｏｓｉｔｉｏｎ、ＰＤＳＣＨマッピングタイプ、Ｋ０値、Ｓ値、および／またはＬ値の特定の値の組み合わせの通知に対応する。
アップリンクスケジューリンググラント用の１つのテーブルと、ダウンリンクスケジューリング割り当て用の１つのテーブルとがある。例えば、１６個の行を設定することができ、各行は以下を含む。
・ＤＣＩが取得されたスロットを基準にしたスロットであるスロットオフセット（Ｋ０、Ｋ２）。現在、０～３のダウンリンクスロットオフセットが可能であり、０～７のアップリンクスロットオフセットを使用することができる。スロットオフセットは、ＰＤＣＣＨ（Ｋ０／Ｋ２を含む）のスロットと、ＰＤＣＣＨによってスケジューリングされた対応するＰＤＳＣＨのスロットとの間のスロット数としてのギャップ（例えば、タイムギャップまたはスロットギャップ）とも呼ばれ得る。
・データが送信されるスロットの最初のＯＦＤＭシンボル。
・スロット内のＯＦＤＭシンボル数での送信の持続時間。開始および長さの全ての組み合わせが１スロットに収まるわけではない。そのため、開始および長さは、有効な組み合わせのみをカバーするように一緒に符号化される。
・ダウンリンクの場合、ＰＤＳＣＨマッピングタイプ、すなわちＤＭＲＳ位置もテーブルの一部である。これにより、マッピングタイプを別に示す場合に比べてさらなる柔軟性が提供される。
・ＤＣＩが取得されたスロットを基準にしたスロットであるスロットオフセット（Ｋ０、Ｋ２）。現在、０～３のダウンリンクスロットオフセットが可能であり、０～７のアップリンクスロットオフセットを使用することができる。スロットオフセットは、ＰＤＣＣＨ（Ｋ０／Ｋ２を含む）のスロットと、ＰＤＣＣＨによってスケジューリングされた対応するＰＤＳＣＨのスロットとの間のスロット数としてのギャップ（例えば、タイムギャップまたはスロットギャップ）とも呼ばれ得る。
・データが送信されるスロットの最初のＯＦＤＭシンボル。
・スロット内のＯＦＤＭシンボル数での送信の持続時間。開始および長さの全ての組み合わせが１スロットに収まるわけではない。そのため、開始および長さは、有効な組み合わせのみをカバーするように一緒に符号化される。
・ダウンリンクの場合、ＰＤＳＣＨマッピングタイプ、すなわちＤＭＲＳ位置もテーブルの一部である。これにより、マッピングタイプを別に示す場合に比べてさらなる柔軟性が提供される。
スロットアグリゲーション、すなわち、同じトランスポートブロックが最大８スロットで繰り返される送信を設定することも可能である。
現在の３ＧＰＰ標準ＴＳ３８．２１４ｖ１６．０．０、例えばＤＬのセクション５．１．２およびＵＬのセクション６．１．２は、時間領域スケジューリングに関連し、例えば、ＵＥで利用可能なＲＲＣで設定されるテーブル（例えば、ｐｄｓｃｈ－ＣｏｎｆｉｇＣｏｍｍｏｎまたはｐｄｓｃｈ－Ｃｏｎｆｉｇのいずれかのｐｄｓｃｈ－ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ）がない場合などに、その観点で使用できるいくつかのデフォルトのテーブルを提供する。これらのフィールド（例えば、ｐｄｓｃｈ－ＡｌｌｏｃａｔｉｏｎＬｉｓｔ）がＲＲＣメッセージで定義されると、どのエレメントが各ＰＤＳＣＨスケジューリングに使用されるかが、（例えば、ＤＣＩ１＿０およびＤＣＩ１＿１の）時間領域リソース割り当てと呼ばれるフィールドによって決定される。
以下に、通常のサイクリックプレフィックスのデフォルトのＰＤＳＣＨ時間領域リソース割り当てＡを示す。
この表から明らかなように、Ｋ０値は常に０であると想定され、実際に同一スロットダウンリンクスケジューリングが適用される。
以下に、通常のサイクリックプレフィックスのデフォルトのＰＵＳＣＨ時間領域リソース割り当てＡを示す。
この表から明らかなように、Ｋ２値は今度は以下の表に示されるパラメータｊに依存する。
パラメータμＰＵＳＣＨは、ＰＵＳＣＨのサブキャリア間隔の設定である。
上記から明らかなように、ＰＵＳＣＨおよびＰＤＳＣＨのＴＤＲＡテーブルは、ＰＵＳＣＨマッピングタイプ、Ｋ０／Ｋ２値、Ｓ値、Ｌ値などの共通のパラメータに基づいている。Ｋ０は、スケジューリングＰＤＣＣＨとスケジューリングされたＰＤＳＣＨとの間のスロットオフセットであり、すなわち、ＤＬスケジューリング用である。Ｋ２は、スケジューリングＰＤＣＣＨとスケジューリングされたＰＵＳＣＨとの間のスロットオフセットであり、すなわち、ＵＬスケジューリング用である。ＴＤＲＡテーブルのＳ値は、関連するスロット（これはスケジューリングされたリソースが受信／送信されるスロットであり、Ｋ０／Ｋ２によって与えられる）内のスケジューリングされたリソースの開始シンボルの位置を示し得る。ＴＤＲＡテーブルのＬ値は、シンボルの観点／単位でのＰＤＳＣＨ／ＰＵＳＣＨの長さを示し、および／またはシンボルの観点／単位でのスケジューリングされたリソースの長さを示し得る。
ＰＤＳＣＨのＲＲＣで設定されるＴＤＲＡテーブルの一例が以下に示され、ここで、パラメータＫ０は０～４スロットの間で変化する。
それに対応して、ＲＲＣで設定されるＴＤＲＡテーブルでは、最大で４タイムスロットのＫ０値が可能であるので、同一スロットならびにクロススロットのスケジューリング（すなわち、異なるタイムスロットでのＤＣＩおよび対応するリソース割り当て）が効果的に可能になる。
現在の５Ｇ固有の例示的な実装では、設定されたＴＤＲＡテーブルは、ＲＲＣを介してＰＤＳＣＨ関連設定内でシグナリングされ（例えば、３ＧＰＰ ＴＳ３８．３３１ｖ１５．９．０の情報エレメントＰＤＳＣＨ－Ｃｏｎｆｉｇ）、転じてＰＤＳＣＨ関連設定は、帯域幅パートに関連する情報エレメント（（ＢＷＰ）－ＤｏｗｎｌｉｎｋＤｅｄｉｃａｔｅｄ）内にあり得る。そのため、ＴＤＲＡテーブルが上位レイヤで設定される場合、ＴＤＲＡテーブルはＢＷＰ固有であり得る。通信デバイスは、デフォルトのテーブルを使用してよく、または上位レイヤで設定されるＴＤＲＡテーブル（ｐｄｓｃｈ－ＣｏｎｆｉｇＣｏｍｍｏｎまたはｐｄｓｃｈ－Ｃｏｎｆｉｇのいずれかのｐｄｓｃｈ－ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔと呼ばれるもの）を適用してよい。しかしながら、これはＴＤＲＡ設定とＮＲのＢＷＰ概念との間のやりとりの、考えられる１つの例にすぎない。本発明はＢＷＰを使用することを前提とせず、ＴＤＲＡテーブルを使用するリソース割り当てに限定されない。
＜下り制御チャネル監視、ＰＤＣＣＨ、ＤＣＩ＞
ＵＥによって作動する多くの機能には、ＵＥ宛ての特定の制御情報またはデータなどを受信するためのダウンリンク制御チャネル（ＰＤＣＣＨなど、３ＧＰＰ ＴＳ３８．３００ ｖ１５．６．０、セクション５．２．３参照）の監視が含まれる。
ＵＥによって作動する多くの機能には、ＵＥ宛ての特定の制御情報またはデータなどを受信するためのダウンリンク制御チャネル（ＰＤＣＣＨなど、３ＧＰＰ ＴＳ３８．３００ ｖ１５．６．０、セクション５．２．３参照）の監視が含まれる。
これらの機能の非網羅的なリストを以下に示す。
・ページングメッセージ監視機能
・システム情報取得機能
・不連続受信（ＤＲＸ：Ｄｉｓｃｏｎｔｉｎｕｅｄ Ｒｅｃｅｐｔｉｏｎ）機能のためのシグナリング監視動作
・不連続受信（ＤＲＸ）機能のための非アクティブ状態（ｉｎａｃｔｉｖｉｔｙ）監視動作
・ランダムアクセス機能のためのランダムアクセス応答受信
・パケットデータコンバージェンスプロトコル（ＰＤＣＰ）レイヤのリオーダリング（ｒｅｏｒｄｅｒｉｎｇ）機能
・ページングメッセージ監視機能
・システム情報取得機能
・不連続受信（ＤＲＸ：Ｄｉｓｃｏｎｔｉｎｕｅｄ Ｒｅｃｅｐｔｉｏｎ）機能のためのシグナリング監視動作
・不連続受信（ＤＲＸ）機能のための非アクティブ状態（ｉｎａｃｔｉｖｉｔｙ）監視動作
・ランダムアクセス機能のためのランダムアクセス応答受信
・パケットデータコンバージェンスプロトコル（ＰＤＣＰ）レイヤのリオーダリング（ｒｅｏｒｄｅｒｉｎｇ）機能
上述のように、制御情報ならびにユーザトラフィック（例えば、ＰＤＣＣＨ上のＤＣＩ、およびＰＤＣＣＨによって示されるＰＤＳＣＨ上のユーザデータ）などのＵＥ向けの情報を識別および受信するために、ＰＤＣＣＨ監視がＵＥによって行われる。
ダウンリンクの制御情報（ダウンリンク制御情報（ＤＣＩ）と呼ばれ得る）は、５Ｇ ＮＲでの目的がＬＴＥでのＤＣＩと同じであり、すなわち、ダウンリンクデータチャネル（ＰＤＳＣＨなど）またはアップリンクデータチャネル（ＰＵＳＣＨなど）をスケジューリングする特別な制御情報のセットである。５Ｇ ＮＲでは、いくつかの異なる定義済みのＤＣＩフォーマットがある（ＴＳ３８．２１２ｖ１５．６．０セクション７．３．１参照）。
上記ＤＣＩフォーマットは、それぞれの情報が形成および送信される所定のフォーマットを表す。具体的には、１つのセルでＰＵＳＣＨおよびＰＤＳＣＨをスケジューリングするために、それぞれＤＣＩフォーマット０＿１および１＿１が使用される。
これらの機能のうちのそれぞれのＰＤＣＣＨ監視は、特定の目的を果たし、したがって、その終わりに向けて開始される。ＰＤＣＣＨ監視は、典型的には、少なくともＵＥが動作させるタイマに基づいて制御される。タイマにはＰＤＣＣＨ監視を制御するという目的があり、例えば、ＵＥがＰＤＣＣＨを監視する最大時間を制限する。例えば、ＵＥは、ＰＤＣＣＨを無期限に監視しなくてもよく、電力を節約できるように、しばらくした後に監視を停止してもよい。
上述のように、ＰＤＣＣＨ上のＤＣＩの目的の１つは、ダウンリンク、アップリンク、さらにはサイドリンクでのリソースの動的スケジューリングである。具体的には、特定のユーザのデータチャネルに割り当てられたリソース（リソース割り当てＲＡ：ｒｅｓｏｕｒｃｅ ａｌｌｏｃａｔｉｏｎ）の通知を搬送するために、ＤＣＩのいくつかのフォーマットが提供される。リソース割り当ては、周波数領域および／または時間領域におけるリソースの指定を含んでよい。
＜端末および基地局＞
端末もしくはユーザ端末またはユーザデバイスは、ＬＴＥおよびＮＲでは、ユーザ機器（ＵＥ）と呼ばれる。これは、ユーザ機器の機能を有するワイヤレスフォン、スマートフォン、タブレットコンピュータ、ＵＳＢ（ユニバーサルシリアルバス：Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）スティックなどのモバイルデバイスまたは通信装置であり得る。しかしながら、モバイルデバイスという用語はこれらに限定されず、一般に、中継機もそのようなモバイルデバイスの機能を有し得、モバイルデバイスが中継機としても機能し得る。例えば、移動局もしくは移動ノードまたはユーザ端末あるいはＵＥは、通信ネットワークにおける物理エンティティ（物理ノード）である。またさらに、通信デバイスは、ＩｏＴデバイスなどの任意のマシンタイプ通信デバイスであり得る。１つのノードは複数の機能エンティティを有し得る。機能エンティティとは、所定の機能セットを実装する、ならびに／あるいは所定の機能セットを同じもしくは他のノードまたはネットワークの他の機能エンティティに提供するソフトウェアまたはハードウェアモジュールを指す。ノードは、ノードが通信できる通信設備または媒体にノードを接続する１つまたは複数のインタフェースを有してよい。同様に、ネットワークエンティティは、他の機能エンティティまたは対応するノードと通信し得る通信設備または媒体に機能エンティティを接続する論理インタフェースを有してよい。
端末もしくはユーザ端末またはユーザデバイスは、ＬＴＥおよびＮＲでは、ユーザ機器（ＵＥ）と呼ばれる。これは、ユーザ機器の機能を有するワイヤレスフォン、スマートフォン、タブレットコンピュータ、ＵＳＢ（ユニバーサルシリアルバス：Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）スティックなどのモバイルデバイスまたは通信装置であり得る。しかしながら、モバイルデバイスという用語はこれらに限定されず、一般に、中継機もそのようなモバイルデバイスの機能を有し得、モバイルデバイスが中継機としても機能し得る。例えば、移動局もしくは移動ノードまたはユーザ端末あるいはＵＥは、通信ネットワークにおける物理エンティティ（物理ノード）である。またさらに、通信デバイスは、ＩｏＴデバイスなどの任意のマシンタイプ通信デバイスであり得る。１つのノードは複数の機能エンティティを有し得る。機能エンティティとは、所定の機能セットを実装する、ならびに／あるいは所定の機能セットを同じもしくは他のノードまたはネットワークの他の機能エンティティに提供するソフトウェアまたはハードウェアモジュールを指す。ノードは、ノードが通信できる通信設備または媒体にノードを接続する１つまたは複数のインタフェースを有してよい。同様に、ネットワークエンティティは、他の機能エンティティまたは対応するノードと通信し得る通信設備または媒体に機能エンティティを接続する論理インタフェースを有してよい。
基地局は、例えば端末にサービスを提供するネットワークの一部を形成するネットワークノードである。基地局は、端末にワイヤレスアクセスを提供するネットワークノードまたはスケジューリングノードである。端末および基地局の間の通信は、典型的には標準化されている。ＬＴＥおよびＮＲでは、ワイヤレスインターフェースプロトコルスタックは、物理レイヤ、媒体アクセスレイヤ（ＭＡＣ：ｍｅｄｉｕｍ ａｃｃｅｓｓ ｌａｙｅｒ）、および上位レイヤを含む。制御プレーンでは、上位レイヤプロトコルの無線リソース制御プロトコルが提供される。ＲＲＣを介して、基地局は端末の設定を制御することができ、端末は基地局と通信して、接続およびベアラの確立、変更など、測定、ならびに他の機能などの制御タスクを実行し得る。ＬＴＥで使用される用語はｅＮＢ（またはｅＮｏｄｅＢ）であるが、５Ｇ ＮＲで現在使用されている用語はｇＮＢである。本明細書での「基地局」または「無線基地局」という用語は、通信ネットワーク内の物理エンティティを指す。移動局と同様に、基地局はいくつかの機能エンティティを有してよい。機能エンティティとは、所定の機能セットを実装する、ならびに／あるいは所定の機能セットを同じもしくは他のノードまたはネットワークの他の機能エンティティに提供するソフトウェアまたはハードウェアモジュールを指す。物理エンティティは、スケジューリングおよび設定のうちの１つまたは複数を含む、通信デバイスに関するいくつかの制御タスクを実行する。なお、基地局の機能および通信デバイスの機能は単一のデバイス内に統合されてもよい。例えば、移動端末は、他の端末のための基地局の機能も実装し得る。ＬＴＥで使用されている用語はｅＮＢ（またはｅＮｏｄｅＢ）であるが、５Ｇ ＮＲで現在使用されている用語はｇＮＢである。
＜用語＞
以下では、ＵＥ、基地局、および手順について説明し、これらは５Ｇ移動通信システム用を想定した新しい無線アクセス技術のためのものであるが、ＬＴＥ移動通信システムでも使用され得る。異なる実装および変形例についても説明する。以下の開示は、上述の議論および発見によって促進されており、例えば、少なくともその一部に基づき得る。
以下では、ＵＥ、基地局、および手順について説明し、これらは５Ｇ移動通信システム用を想定した新しい無線アクセス技術のためのものであるが、ＬＴＥ移動通信システムでも使用され得る。異なる実装および変形例についても説明する。以下の開示は、上述の議論および発見によって促進されており、例えば、少なくともその一部に基づき得る。
なお、全体的に、本開示の根底にある原理を明確かつ理解可能な方法で説明できるようにするために、本明細書では多くの仮定を用いている。しかしながら、これらの仮定は、説明のために本明細書で作成した単なる例として理解されるべきであり、本開示の範囲を限定すべきではない。
また、以下で使用する手順、エンティティ、レイヤなどの用語の一部は、ＬＴＥ／ＬＴＥ－Ａシステム、または現在の３ＧＰＰ ５Ｇ標準化で使用されている用語と密接に関連しているが、次の３ＧＰＰ ５Ｇ通信システムの新しい無線アクセス技術のコンテキストで使用される特定の用語は、まだ完全には決定されておらず、最終的に変更され得る。このため、実施形態の機能に影響を与えることなく、用語は将来的に変更され得る。したがって、当業者は、実施形態およびそれらの保護の範囲が、より新しいまたは最終的に合意される用語がないために、本明細書で例示的に使用した特定の用語に限定されるべきではなく、本開示の機能および原理の根底にある機能および概念に関してより広く理解されるべきであるということを認識する。
＜省電力の可能性＞
発明者らは、ＵＥでの電力を節約し、それによって、特に簡易機能（ｒｅｄｕｃｅｄ ｃａｐａｂｉｌｉｔｙ）ＮＲデバイス（例えば、リリース１７に対応するもの）に関して、ＵＥのバッテリー寿命を延ばす可能性を見出した。具体的には、ｉ）ブラインド復号および／またはＣＣＥ制限の数を少なくするなどしてＰＤＣＣＨ監視を削減すること、ｉｉ）ＲＲＣ非アクティブ状態、アイドル状態、および／または接続状態のＤＲＸを拡張すること、ならびにｉｉｉ）固定デバイスのＲＲＭを緩和することにより、適用可能なユースケース（例えば、耐遅延性）においてＵＥの電力消費が節約され得る。
発明者らは、ＵＥでの電力を節約し、それによって、特に簡易機能（ｒｅｄｕｃｅｄ ｃａｐａｂｉｌｉｔｙ）ＮＲデバイス（例えば、リリース１７に対応するもの）に関して、ＵＥのバッテリー寿命を延ばす可能性を見出した。具体的には、ｉ）ブラインド復号および／またはＣＣＥ制限の数を少なくするなどしてＰＤＣＣＨ監視を削減すること、ｉｉ）ＲＲＣ非アクティブ状態、アイドル状態、および／または接続状態のＤＲＸを拡張すること、ならびにｉｉｉ）固定デバイスのＲＲＭを緩和することにより、適用可能なユースケース（例えば、耐遅延性）においてＵＥの電力消費が節約され得る。
ＵＥの電力を節約する方法として、ＰＤＣＣＨの監視とスケジューリングを改善することが考えられる。具体的には、ＲＲＣ ＣＯＮＮＥＣＴＥＤモードで頻繁にトラフィックが発生するＵＥの場合、ＰＤＣＣＨオンリー（ＰＤＣＣＨ－ｏｎｌｙ）が依然としてＵＥの電力消費の大部分を占めている。したがって、ＰＤＳＣＨ／ＰＵＳＣＨスケジューリングを伴わないＰＤＣＣＨオンリーのスロットが総電力消費の大部分を占め得るので、ＰＤＣＣＨオンリーのスロットの数を減らすことにより、ＵＥの電力消費の大幅な削減が促進され得る。上記ＤＣＩによってスケジューリングされたＴＢのうちの１つまたは複数（あるいは全て）の繰り返しの送信および／または受信も上記ＤＣＩでスケジューリングすることによって、電力消費がさらに削減され得る。
なお、特定のＵＥ／サービスに関してスループットなどの特定のサービス要件が満たされる必要があるときに、遅延にあまり敏感でないサービスタイプの場合には、複数のＴＢのスケジューリングが特に適切／効率的であり得る。そのような場合、ｇＮＢはスケジューリング予測を実行してよく、これにより、１つのＤＣＩで２つ以上のＴＢをその後の複数のスロットにスケジューリングすることで、スロットをより有効に利用することが可能になり得る。
簡易機能ＵＥの場合、カバレッジの回復も重要な側面であり得る。Ｒｘ／Ｔｘアンテナの削減など、特定のコスト／複雑性の削減が行われているので、繰り返し送信を用いたデータチャネルスケジューリングはカバレッジの向上に有益であり得る。複数のＴＢのスケジューリングは、以下でさらに説明するように、ＰＤＣＣＨ監視の削減／適応、ＵＬの取り消し、および／またはＤＬのプリエンプションとの相互作用において、さらなる電力消費の削減を可能にし得る。
＜ＵＬ／ＤＬにおける送信の取り消し通知（ＣＩ）と優先度通知＞
この点において、以下では、取り消し通知（ＣＩ：Ｃａｎｃｅｌｌａｔｉｏｎ Ｉｎｄｉｃａｔｉｏｎ）は一般的にＵＬ ＣＩまたはＤＬ ＰＩ（Ｐｒｅ－ｅｍｐｔｉｏｎ Ｉｎｄｉｃａｔｉｏｎ）であることに留意されたい。ＰＵＳＣＨ／ＰＤＳＣＨの繰り返し送信の場合、ＵＬ ＣＩ／ＤＬ ＰＩは繰り返し送信のそれぞれに個別に適用されてよい（ＰＵＳＣＨ繰り返し送信タイプＢの場合は実際の繰り返し送信）。つまり、ＵＬ ＣＩ／ＤＬ ＰＩで通知されたリソースと（時間および周波数において）重なる繰り返し送信は（例えば、Ｒｅｌ．１６ ＮＲ ＵＲＬＬＣに記載されるように）取り消されて／プリエンプトされてよい。
この点において、以下では、取り消し通知（ＣＩ：Ｃａｎｃｅｌｌａｔｉｏｎ Ｉｎｄｉｃａｔｉｏｎ）は一般的にＵＬ ＣＩまたはＤＬ ＰＩ（Ｐｒｅ－ｅｍｐｔｉｏｎ Ｉｎｄｉｃａｔｉｏｎ）であることに留意されたい。ＰＵＳＣＨ／ＰＤＳＣＨの繰り返し送信の場合、ＵＬ ＣＩ／ＤＬ ＰＩは繰り返し送信のそれぞれに個別に適用されてよい（ＰＵＳＣＨ繰り返し送信タイプＢの場合は実際の繰り返し送信）。つまり、ＵＬ ＣＩ／ＤＬ ＰＩで通知されたリソースと（時間および周波数において）重なる繰り返し送信は（例えば、Ｒｅｌ．１６ ＮＲ ＵＲＬＬＣに記載されるように）取り消されて／プリエンプトされてよい。
また、特にＵＥの取り消し動作を制御するため、優先度インジケータが導入されてもよい。例えば、優先度インジケータは、Ｒｅｌ．１６ ＮＲ等と同様、ＤＣＩフォーマット０＿１、０＿２、１＿１、および／または１＿２において通知されてよい。ＵＥにＵＬ ＣＩ／ＤＬ ＰＩとＵＥ内優先度インジケータとの両方が設定された場合、２つ以上のＵＥ動作（例えば、２つ以上の取り消しルール）があり得る。例えば、第１の動作によると、ＵＬ ＣＩ／ＤＬ ＰＩは低優先度レベルと通知された／設定されたＵＬ／ＤＬ送信のみに適用されてよく、第２の動作によると、ＵＬ ＣＩ／ＤＬ ＰＩは優先度レベルに関わらずＵＬ／ＤＬ送信に適用されてよい。２つ以上の設定動作のうちいずれの動作にＵＥが従うかは、例えばＲＲＣを用いて通知／設定されてよい。より具体的には、ＵＥは、２つ以上の設定動作の中から１つの動作を示す通知を、ＲＲＣを介して受信してよい。この通知に基づいて、ＵＥは通知された動作を決定してよい。さらに、ＵＥは、（例えば、動作を示す他の通知を、ＲＲＣを介して受信するまで）次に受信するＣＩによって取り消される送信を決定するために、通知／決定された動作を用いてよい。
一般的に、マルチＴＢスケジューリングＤＣＩは長時間のリソースを効率的にスケジューリングし得る。しかしながら、長時間の複数のＴＢ送信は以降の高優先度のトラフィックを妨害する恐れがある。換言すると、マルチＴＢスケジューリングＤＣＩで複数のＴＢをスケジューリングした後に、当該ＤＣＩでスケジュールされたリソースの一部が他のトラフィック（例えば、高優先度のトラフィック）のために必要になる事態が起こり得る。
この観点から、発明者らは、マルチＴＢスケジューリングのフレームワークにおいて、取り消しのための効率的なＣＩ／ＰＩの可能性を見出した。さらに、発明者らは、複数のＴＢの優先度を効率的に通知する可能性も見出した。以下の実施形態は、ＵＬ ＣＩとＤＬ ＰＩの両方に適用され、それぞれＵＬの取り消しとＤＬのプリエンプションに対応する。
＜実施形態＞
本開示は、ＵＥの省電力化を促進し得る繰り返し送信を伴うまたは伴わない複数のＴＢスケジューリングのための技術を提供する。具体的には、本開示は、繰り返し送信を伴うまたは伴わない複数のＴＢスケジューリングのためのシグナリングのサポートおよびフレームワークの設計に対応する。また、本開示は、繰り返し送信を伴うまたは伴わない動的な複数のＴＢスケジューリングを可能にし得るフレームワークを提供する。そして、本開示は、マルチＴＢスケジューリングＤＣＩによりスケジュールされた送信の一つまたは複数の、効率的な取り消しのための技術を提供する。さらに、本開示は、マルチＴＢスケジューリングＤＣＩによりスケジュールされたＴＢの優先度の効率的な通知を促進し得る技術を提供する。
本開示は、ＵＥの省電力化を促進し得る繰り返し送信を伴うまたは伴わない複数のＴＢスケジューリングのための技術を提供する。具体的には、本開示は、繰り返し送信を伴うまたは伴わない複数のＴＢスケジューリングのためのシグナリングのサポートおよびフレームワークの設計に対応する。また、本開示は、繰り返し送信を伴うまたは伴わない動的な複数のＴＢスケジューリングを可能にし得るフレームワークを提供する。そして、本開示は、マルチＴＢスケジューリングＤＣＩによりスケジュールされた送信の一つまたは複数の、効率的な取り消しのための技術を提供する。さらに、本開示は、マルチＴＢスケジューリングＤＣＩによりスケジュールされたＴＢの優先度の効率的な通知を促進し得る技術を提供する。
本開示は、被スケジューリングデバイス（典型的には通信デバイス／送受信機デバイス）およびスケジューリングデバイス（典型的にはネットワークノード）の両方のエンティティが参加するスケジューリングに関する。したがって、本開示は、基地局およびユーザ機器を提供する。図６に示すように、ユーザ機器６１０および基地局６６０は、無線通信システムにおいて無線チャネルを介して互いに通信し得る。例えば、ユーザ機器はＮＲユーザ機器であってよく、基地局はＮＲ ｇＮＢ、特に非地上系ネットワーク（ＮＴＮ：Ｎｏｎ－Ｔｅｒｒｅｓｔｒｉａｌ Ｎｅｔｗｏｒｋ）ＮＲシステムにおけるｇＮＢなどのネットワークノードまたはスケジューリングノードであってよい。
本開示は、被スケジューリングデバイスおよびスケジューリングデバイスを含むシステム、ならびに対応する方法およびプログラムをさらに提供する。そのような通信システムの一例を図６に示す。通信システム６００は、５Ｇの技術仕様に応じた無線通信システム、特にＮＲ通信システムであってよい。しかしながら、本開示は３ＧＰＰ ＮＲに限定されず、ＮＴＮなどの他の無線またはセルラシステムに適用されてもよい。
図６は、ユーザ機器６１０（「通信デバイス」、「端末」、「ＵＥ」とも呼ぶ）と、ここでは例示的にｅＮＢまたはｇＮＢなどの基地局（ネットワークノード）への配置を想定されるスケジューリングデバイス６６０との一般的で簡略化した例示的なブロック図を示している。しかしながら、一般にスケジューリングデバイスは、２つの端末間のサイドリンク接続の場合の端末であり得る。また、特にＵＲＬＬＣ、ｅＭＢＢおよびｍＭＴＣのユースケースに関して、通信デバイス６１０は、センサデバイス、ウェアラブルデバイス、もしくは接続車両、または工場内の自動化された機械のコントローラでもあり得る。さらに、通信デバイス６１０は、基地局６６０と他の通信デバイスとの間の中継機として機能することが可能であってよい（例えば、本開示は通信「端末」にもユーザ「端末」にも限定されない）。
ＵＥおよびｅＮＢ／ｇＮＢは、自身の送受信機６２０（ＵＥ側）および送受信機６７０（基地局側）をそれぞれ使用して（無線）物理チャネル６５０を介して互いに通信する。基地局６６０および端末６１０は、一緒に通信システム６００を形成する。通信システム６００は、図１に示すような他のエンティティをさらに含んでもよい。
図６に示すように、いくつかの実施形態では、ユーザ機器（ＵＥ）６１０は送受信機６２０を備え、送受信機６２０は、動作時に、ダウンリンク制御情報（ＤＣＩ）シグナリング（本開示ではマルチＴＢスケジューリングＤＣＩともいう）を受信する。送受信機はさらに、動作時に、制御情報を受信する。ＵＥはさらに回路６３０、６３５を備え、回路６３０、６３５は、動作時に、ＤＣＩシグナリングからスケジューリング通知を取得する。例えば、ＵＥは、ＤＣＩを解析することによって、および／またはＤＣＩからスケジューリング通知を抽出することによって、ＤＣＩからそのスケジューリング通知を取得してよい。そのスケジューリング通知は、複数のトランスポートブロック（ＴＢ）のそれぞれに対して、そのＴＢの１つ以上の送信のスケジューリングを通知する。例えば、そのスケジューリング通知は、Ｎ個のトランスポートブロック（ＴＢ）のスケジューリングを通知してもよい（ここで、Ｎは１より大きい整数）。また、回路は、制御情報からリソースを通知する取り消し通知（ＣＩ）を取得してもよい。さらに、回路は、通知されたリソースと所定のルール（取り消しルール）とに基づいて、複数のＴＢのスケジュールされた送信のうちどの送信が取り消されているかを決定してもよい。
また、図６に示すように、いくつかの実施形態では、基地局／スケジューリングデバイス６６０は、回路６８０、６８５を備える。回路６８０、６８５は、動作時に、ダウンリンク制御情報（ＤＣＩ）シグナリング（本開示ではマルチＴＢスケジューリングＤＣＩともいう）を生成する。ＤＣＩシグナリングは、複数のトランスポートブロック（ＴＢ）のそれぞれに対して、そのＴＢの１つ以上の送信のスケジューリングを通知するスケジューリング通知を含んでよい。例えば、ＤＣＩシグナリングは、Ｎ個のトランスポートブロック（ＴＢ）のスケジューリングをＵＥに通知するスケジューリング通知を含んでよい（ここで、Ｎは１より大きい整数）。また、回路６８０、６８５は、複数のＴＢのスケジュールされた送信のうちどの送信が取り消されるかを決定してもよい。さらに、回路６８０、６８５は、所定のルール（取り消しルール）に基づいて、取り消されると決定した、スケジュールされた送信を示すリソースを決定し、当該リソースを通知する取り消し通知（ＣＩ）を含む制御情報を生成してもよい。基地局６６０は、さらに送受信機を備えてもよく、送受信機は、動作時に、ＤＣＩシグナリングと制御情報を送信する。
なお、通信デバイス６１０は送受信機６２０および（処理）回路６３０を備えてよく、スケジューリングデバイス６６０は送受信機６７０および（処理）回路６８０を備えてよい。転じて、送受信機６２０は、受信機および／または送信機を備えてよく、および／またはそれらとして機能してよい。本開示では、換言すれば、「送受信機」という用語は、通信デバイス６１０あるいは基地局６６０が物理チャネル６５０を介して無線信号を送信および／または受信することを可能にするハードウェアおよびソフトウェアコンポーネントに使用される。したがって、送受信機は、受信機、送信機、または受信機および送信機の組み合わせに対応する。典型的には、基地局および通信デバイスは、無線信号を送信することも受信することも可能であると想定される。しかしながら、特にｅＭＢＢ、ｍＭＴＣ、ＵＲＬＬＣの一部の用途（スマートホーム、スマートシティ、産業オートメーションなど）に関しては、センサなどのデバイスが信号の受信のみを行う場合が考えられる。また、「回路」という用語は、１つまたは複数のプロセッサまたは処理ユニットなどによって形成される処理回路を含む。
回路６３０、６８０（または処理回路）は、１つまたは複数のハードウェア、例えば、１つまたは複数のプロセッサまたは任意のＬＳＩであり得る。送受信機と処理回路との間には入力／出力ポイント（またはノード）があり、それを介して処理回路は、動作時に、送受信機を制御し、すなわち、受信機および／または送信機を制御し、受信／送信データを交換することができる。送受信機は、送信機および受信機として、１つまたは複数のアンテナ、増幅器、ＲＦ変調器／復調器などを含むＲＦ（無線周波数：ｒａｄｉｏ ｆｒｅｑｕｅｎｃｙ）フロントを含んでよい。処理回路は、処理回路によって提供されたユーザデータおよび制御データを送信し、および／または処理回路によってさらに処理されるユーザデータおよび制御データを受信するように送受信機を制御するなどの制御タスクを実施してよい。処理回路はまた、決定、判断、計算、測定などの他の処理の実行を担ってもよい。送信機は、送信処理およびそれに関連する他の処理の実行の実行を担ってよい。受信機は、受信処理およびそれに関連する他の処理の実行を担ってよい。
上述のＵＥ６１０に対応して、ＵＥによって実行される通信方法を提供する。図７の左側に示すように、この方法は、ＤＣＩシグナリング（本開示ではマルチＴＢスケジューリングＤＣＩともいう）を受信するステップＳ７２５、および、当該ＤＣＩシグナリングからスケジューリング通知を取得するステップＳ７４５を含む。例えば、そのスケジューリング通知は、ＤＣＩを解析することによって、および／またはＤＣＩからスケジューリング通知を抽出することによって、ＤＣＩから取得されてよい。そのスケジューリング通知は、複数のＴＢのそれぞれに対して、そのＴＢの１つ以上の送信のスケジューリングを通知する。換言すると、そのスケジューリング通知は、ｉ）Ｎ個のＴＢのスケジューリング（ここで、Ｎは１より大きい整数）と、ｉｉ）Ｍ回のＴＢの繰り返し送信のスケジューリング（ここで、Ｍは１以上）とを通知してよい。また、その方法は、制御情報を受信するステップＳ７６５、およびその制御情報からリソースを示すＣＩを取得するステップＳ７７５を含む。さらに、その方法は、通知されたリソースと所定のルール（取り消しルール）とに基づいて、複数のＴＢのスケジュールされた送信のうちどの送信が取り消されているかを決定するステップＳ７８５を含む。
さらに、図７に示すように、ＵＥは、ＤＣＩ／ＰＤＣＣＨから取得したスケジューリング通知と制御情報から取得したＣＩとに従って、ＤＣＩによってスケジュールされ、ＣＩに取り消されていないトランスポートブロックを送信（Ｓ７９５）および／または受信（Ｓ７９５）してよい。
なお、図７では、Ｎ個のＴＢの送信／受信（Ｓ７９５）は、ＣＩの受信（Ｓ７６５）、制御情報の取得（Ｓ７７５）、および取り消される送信の決定（Ｓ７８５）の後に行われるように示されているが、本発明はこれに限定されない。一般的に、受信（Ｓ７６５）、取得（Ｓ７７５）、および／または決定（Ｓ７８５）は、Ｎ個のＴＢのスケジュールされた送信の一部がＵＥによって送信／受信（Ｓ７９５）された後に行われ得る。具体的に、ステップＳ７６５、Ｓ７７５、および／またはＳ７８５は、ステップＳ７９５の最中（つまり、Ｎ個のＴＢのスケジュールされた送信の一部（ただしすべてではない）が行われた後）に行われ得る。この場合、まだ送信／受信されていない送信のみが取り消されてよい。具体的に、Ｓ７８５の決定において、ＵＥは、すでに送信／受信されたスケジュールされた送信はすべて取り消されていないと決定してよい（つまり、取り消しルールがそのように特定してよい）。
さらに、上述の基地局に対応して、基地局（スケジューリングデバイス）によって実行される通信方法を提供する。図７の右側に示すように、この方法は、ＤＣＩシグナリング（本開示ではマルチＴＢスケジューリングＤＣＩともいう）を生成するステップＳ７１０、および生成されたＤＣＩシグナリングを送信するステップＳ７２０を含む。ＤＣＩシグナリングは、複数のＴＢのそれぞれに対して、そのＴＢの１つ以上の送信のスケジューリングを通知するスケジューリング通知を含む。換言すると、スケジューリング通知は、ｉ）Ｎ個のＴＢのスケジューリング（ここで、Ｎは１より大きい整数）、およびｉｉ）Ｎ個のＴＢのＭ回の送信／繰り返し送信のスケジューリング（ここで、Ｍは１以上）をＵＥに通知してよい。さらに、この方法は、複数のＴＢのスケジュールされた送信のうちどの送信が取り消されるかを決定するステップＳ７３０を含む。例えば、基地局は、トラフィック状況や送信のスケジューリングが変更されたときに送信が取り消されると決定してよい。一般的に、送信は、その送信用にスケジュールされたリソースを、より効率的に（同じまたは他のＵＥの）他の送信に使用することができる場合に取り消され得る。具体的に、基地局は、送信が取り消されること（取り消すかどうか、および、どの送信を取り消すか）を決定するとき、他のＵＥ、すでにスケジュールされた送信のＱＯＳ要件、ならびに、リソースが使用可能だった場合にスケジュールされ得る送信のＱＯＳ要件を考慮してよい。
さらに、この方法は、所定のルール（本開示では、取り消しルールとも呼ぶ）に基づいて、取り消されると決定した、スケジュールされた送信を示すリソースを決定するステップＳ７４０、当該リソースを通知する取り消し通知（ＣＩ）を含む制御情報を生成するステップＳ７５０、および、当該制御情報を送信するステップＳ７６０を含む。
図７に示すように、基地局の方法はステップＳ７００を実行してもよく、基地局のための方法はステップＳ７００を含んでもよい。ステップＳ７１０におけるマルチＴＢスケジューリングＤＣＩの生成の前に行われるステップＳ７００では、基地局はＮ個のトランスポートブロックの送信および／または受信のための時間領域のリソースの割り当て／スケジューリングを行う。このスケジューリングは、複数（例えば、Ｎ＞１）のＴＢのスケジューリングを１つまたは複数のＵＥに通知することを決定するステップを含んでよい。ステップ７００は一般的に、他のＵＥの他の送信／受信のためのリソースのスケジューリングと併せて、トラフィック状況および１つまたは複数のＵＥによって使用されるサービスの品質要件を考慮して実行されてよい。さらに、図７に示すように、スケジューリングデバイスは、ＤＣＩ／ＰＤＣＣＨのスケジューリングとＣＩとに従って、取り消されていないスケジュールされたトランスポートブロックを受信（Ｓ７９０）および／または送信（Ｓ７９０）してよい。
なお、図７では、Ｎ個のＴＢの受信／送信（Ｓ７９０）は、ＣＩの送信（Ｓ７６０）、制御情報の生成（Ｓ７５０）、リソースの決定（Ｓ７４０）、および取り消される送信の決定（Ｓ７３０）の後に行われるように示されているが、本発明はこれに限定されない。一般的に、決定（Ｓ７３０）ならびにそれに続くステップＳ７４０、Ｓ７５０、および／またはＳ７６０は、Ｎ個のＴＢのスケジュールされた送信の一部がスケジューリングデバイスによって送信／受信（Ｓ７９０）された後に行われ得る。
なお、以下に説明するステップ／動作のいずれもが、回路６３０（ＵＥ側）および／または回路６８０（基地局側）によって実行または制御され得る。
さらなる説明において、詳細および実施形態は、明示的な記述または文脈が別段の指示をしない限り、送受信機デバイス、スケジューリングデバイス（またはスケジューリングノード）、および方法のそれぞれに適用される。特に、ＵＥと基地局は、ＣＩによって通知されたリソースが取り消される送信を通知する、同じ取り消しルールを使用してよい。
＜マルチＴＢスケジューリングＤＣＩ＞
一般的に、ＤＣＩ（またはＤＣＩシグナリング）は複数のＴＢをスケジューリングし得る。換言すれば、繰り返し送信を伴うまたは伴わない複数のＴＢ送信が、（単一のまたは１つの）ＤＣＩによってスケジューリングされ得る。本開示において、そのようなＤＣＩはマルチＴＢスケジューリングＤＣＩとも呼ばれる。より具体的には、マルチＴＢスケジューリングＤＣＩは、複数のＴＢのスケジューリングを（同じＵＥに）通知する。同様に、「マルチＴＢスケジューリング」という用語は、同じＵＥへの単一の（または１つの）ＤＣＩによる複数のＴＢのスケジューリングを指す。換言すると、マルチＴＢスケジューリングＤＣＩは、複数のＴＢのスケジューリングを（同じＵＥに）通知するスケジューリング通知を含んでよい。
一般的に、ＤＣＩ（またはＤＣＩシグナリング）は複数のＴＢをスケジューリングし得る。換言すれば、繰り返し送信を伴うまたは伴わない複数のＴＢ送信が、（単一のまたは１つの）ＤＣＩによってスケジューリングされ得る。本開示において、そのようなＤＣＩはマルチＴＢスケジューリングＤＣＩとも呼ばれる。より具体的には、マルチＴＢスケジューリングＤＣＩは、複数のＴＢのスケジューリングを（同じＵＥに）通知する。同様に、「マルチＴＢスケジューリング」という用語は、同じＵＥへの単一の（または１つの）ＤＣＩによる複数のＴＢのスケジューリングを指す。換言すると、マルチＴＢスケジューリングＤＣＩは、複数のＴＢのスケジューリングを（同じＵＥに）通知するスケジューリング通知を含んでよい。
一般的に、マルチＴＢスケジューリングＤＣＩに含まれるスケジューリング通知は、Ｎ個のトランスポートブロックのスケジューリングを通知する。つまり、スケジューリング通知は、Ｎ個のＴＢのそれぞれに対して、そのＴＢの１つ以上の送信を通知してよい。さらに、スケジューリング通知は、各送信に対して通知し、それ（スケジューリング通知）は、当該送信のためのリソースを通知する。
マルチＴＢスケジューリングＤＣＩ（それに含まれるスケジューリング通知）は、ｉ）ＴＢの数Ｎ（Ｎは１より大きい整数）、ｉｉ）ＴＢの繰り返し送信の数Ｍ（Ｍは１以上）、ｉｉｉ）送信ギャップ（例えば、Ｎ個のＴＢ間の送信ギャップ）、およびｉｖ）インターリーブパターン、のうちの少なくとも１つ（１つ、２つ、３つ、さらには４つ全て）を上記ＵＥにさらに通知してよい。なお、本開示では、「マルチスケジューリングＤＣＩにスケジュールされたＴＢ」という用語、および「Ｎ個のＴＢ」という用語は同義的に用いられる。
なお、数Ｎは、一般的に、１より大きい非負整数（または自然数）である。また、マルチＴＢスケジューリングＤＣＩによってスケジュールされた相互に異なるＴＢの数／量がＮであってよい。
換言すれば、マルチＴＢスケジューリングＤＣＩ（例えば、当該マルチＴＢスケジューリングＤＣＩに含まれるスケジューリング通知）は、ｉ）ＴＢの数Ｎを示す通知、ｉｉ）ＴＢの繰り返し送信の数Ｍを示す通知、ｉｉｉ）送信ギャップを示す通知、およびｉｖ）インターリーブパターンを示す通知、を含んでいてよい。なお、ＴＢの数Ｎの通知はＮ個のＴＢのスケジューリングを暗黙的に示してよく、Ｍ回の繰り返し送信の通知はＴＢのＭ回の繰り返し送信のスケジューリングを暗黙的に示してよい。より具体的には、マルチＴＢスケジューリングＤＣＩにおける数Ｎの通知は、Ｎ個のＴＢのスケジューリングも通知してよい。換言すれば、数Ｎの通知は、数ＮとＮ個のＴＢのスケジューリングとの統合通知と考えられる。同様に、マルチＴＢスケジューリングＤＣＩにおける数Ｍの通知は、Ｍ回の繰り返し送信のスケジューリングも通知してよい。換言すれば、数Ｍの通知は、数ＭとＭ回の繰り返し送信のスケジューリングとの統合通知と考えられる。なお、インターリーブパターンは、Ｎ個のＴＢのスケジューリング、もしくはＴＢのＭ回の繰り返し送信のスケジューリング、またはその両方を暗黙的に通知してよい。
一般的に、マルチＴＢスケジューリングＤＣＩにおけるスケジューリング通知は、明示的な通知（例えば、ＴＢの数Ｎおよび／または繰り返し送信の数Ｍを示すためのＤＣＩ内のビットフィールド）、あるいはＴＤＲＡテーブルのエントリなどによる統合通知など（そのようなＴＤＲＡテーブルは、ＴＢおよび繰り返し送信の数の異なる組み合わせを指定する複数のエントリを含み得る）であってよい。具体的に、Ｎ個のＴＢのスケジューリングを示す通知は、Ｎ個のＴＢのスケジューリングと、ｉ）Ｍ回の繰り返し送信のスケジューリング、ｉｉ）インターリーブパターン、およびｉｉｉ）送信ギャップのうちの少なくとも１つとを統合的に通知してよい。そのような統合スケジューリング通知は、オーバーヘッドを削減し得る。
＜マルチＴＢスケジューリングＤＣＩのスケジューリング＞
一般的に、Ｎ個のＴＢのスケジューリングを示す通知は、数Ｎの通知を含み得る。換言すれば、マルチＴＢスケジューリングＤＣＩ（例えば、スケジューリング通知）は一般に、スケジュールされたＴＢの数Ｎの通知を含み得る。数Ｎの通知は、明示的または暗黙的であってよい。
一般的に、Ｎ個のＴＢのスケジューリングを示す通知は、数Ｎの通知を含み得る。換言すれば、マルチＴＢスケジューリングＤＣＩ（例えば、スケジューリング通知）は一般に、スケジュールされたＴＢの数Ｎの通知を含み得る。数Ｎの通知は、明示的または暗黙的であってよい。
しかしながら、本発明はこれに限定されない。すなわち、マルチＴＢスケジューリングＤＣＩによるＮ個のＴＢのスケジューリングは、そのマルチＴＢスケジューリングＤＣＩがスケジュールされたＴＢの数Ｎの明示的な通知を含むことは要求されない。換言すれば、マルチＴＢスケジューリングＤＣＩは、スケジュールされたＴＢの数Ｎを示す通知を含んでも含まなくてもよい。例えば、いくつかの実施形態では、ＵＥ（例えば、その送受信機）は、無線リソース制御（ＲＲＣ：Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ）シグナリングを受信するように構成される。これらの実施形態では、ＵＥ（例えば、その処理回路）は次いで、動作時に、受信したＲＲＣシグナリングからＴＢの数Ｎを示す通知を取得する。
同様に、ＴＢのＭ回の繰り返し送信のスケジューリングを示す通知は一般に、数Ｍの通知を含み得る。換言すれば、マルチＴＢスケジューリングＤＣＩ（例えば、スケジューリング通知）は一般に、繰り返し送信の数Ｍの通知を含み得る。繰り返し送信の数Ｍの通知は、明示的または暗黙的であってよい。
しかしながら、本発明はこれに限定されない。すなわち、マルチＴＢスケジューリングＤＣＩによるＭ回の繰り返し送信のスケジューリングは、そのマルチＴＢスケジューリングＤＣＩがスケジュールされたＴＢの繰り返し数Ｍの明示的な通知を含むことは要求されない。換言すれば、ＴＢの繰り返し送信をスケジューリングするマルチＴＢスケジューリングＤＣＩは、スケジュールされたＴＢの繰り返し送信の数Ｍを示す通知を含んでも含まなくてもよい。ＴＢの数Ｎと同様に、繰り返し送信の数ＭはＲＲＣを介して通知され得る。
一般に、一部のマルチＴＢスケジューリングＤＣＩはＮおよび／またはＭを明示的に通知し得るが、他のマルチＴＢスケジューリングＤＣＩについては、Ｎおよび／またはＭの現在の値（マルチＴＢスケジューリングＤＣＩによって明示的に通知されたＮ／Ｍの最後の値）が適用されることが暗黙的に理解される。代替的または追加的に、Ｎおよび／またはＭはＲＲＣを介して設定されてもよく、マルチＴＢスケジューリングＤＣＩは、トリガ（例えば、ＤＣＩ内の１ビットのフィールド）のみによってＮ個のトランスポートブロック（および該当する場合はＭ回の繰り返し送信）のスケジューリングを通知してよい。すなわち、トランスポートブロックの数Ｎ、繰り返し送信の数Ｍ、インターリーブパターン、および送信ギャップは、他の手段よって通知されてもよく、例えば、ＲＲＣによって設定されてよい。
また、マルチＴＢスケジューリングＤＣＩは一般に、複数のＴＢのスケジュールされた送信／繰り返し送信のためのリソースをスケジューリングしてよい。なお、このリソースのスケジューリングは、スロット単位（図８ａ～８ｄおよび図９に図示）または非スロット単位であり得る。換言すれば、マルチＴＢスケジューリングＤＣＩは、スロット単位のマルチＴＢスケジューリングであってもよいし、非スロット単位のマルチＴＢスケジューリングであってもよい。より具体的には、スロット単位のスケジューリングは、ＴＢの全ての送信／繰り返し送信がスロットの粒度でスケジューリングされる、リソースのスケジューリングを指す。換言すれば、スケジューリングされた各ＴＢ送信／繰り返し送信ついて、１つまたは複数のそれぞれのスロットの全ての時間領域リソースが使用される（例えば、各送信／繰り返し送信は、１つまたは複数のスロット全体／全スロットを使用する）。一方、非スロット単位のスケジューリングは、ＴＢまたはその繰り返し送信のためにスケジューリングされる時間領域リソースが１スロット未満である、例えば、１つ、２つまたはいくつかのＯＦＤＭシンボルであるスケジューリングを指す。具体的には、非スロット単位のスケジューリングは、ＴＢの複数の送信／繰り返し送信を同じスロットにスケジューリングし得る。
なお、本開示では、「ＤＣＩがスケジューリングする」、「ＤＣＩがスケジューリングを通知する」、「ＤＣＩがスケジューリングを示す通知を含む」などの形の記述が同義的に使用される。さらに、「複数のＴＢの送信をスケジューリングする」、「複数のＴＢの送信および／または受信をスケジューリングする」、「複数のＴＢをスケジューリングする」などの形の記述が同義的に使用される。
さらに、Ｎ個のＴＢ（および該当する場合はＭ回の繰り返し送信）のスケジューリングは、アップリンク（ＵＬ：Ｕｐｌｉｎｋ、例えばＰＵＳＣＨ）またはダウンリンク（ＤＬ：Ｄｏｗｎｌｉｎｋ、例えばＰＤＳＣＨ）での送信のスケジューリングであり得る。換言すれば、マルチＴＢスケジューリングＤＣＩによってスケジューリングされるＴＢは、ＵＥによる送信または受信のために（およびそれに対応して基地局による受信または送信のために）スケジューリングされ得る。さらに言い換えれば、特に明記していない限り、「送信」という用語はＵＥによる送信または基地局による送信を指し、「受信」という用語はＵＥによる受信または基地局による受信を指す。
なお、スケジューリングするＮ個のＴＢ（および該当する場合はＭ回の繰り返し送信）の送信／受信に使用されるリソースは、上記マルチＴＢスケジューリングＤＣＩによって（明示的または暗黙的に）通知されてもよいしされなくてもよい。例えば、ＳＰＳ／ＣＧフレームワークを使用して、上記リソースがＲＲＣを介して通知されてもよい。
＜トランスポートブロック（ＴＢ）および繰り返し送信＞
一般的に、Ｎ個のＴＢは相互に異なるデータを搬送し得る。
一般的に、Ｎ個のＴＢは相互に異なるデータを搬送し得る。
なお、「トランスポートブロック」という用語は、特にＭＩＭＯのコンテキストなどで使用される、「コードワード」という用語にも置き換えられてよい。より具体的には、コードワードという用語は、１つまたは複数のコードワードを記述するために現在ＭＩＭＯでよく使用されており、各コードワードをスケジューリングして、１つ以上／複数の空間レイヤにマッピングすることができる。チャネル符号化および変調の観点では、本発明に関する限り、動作はトランスポートブロックおよびコードワードに対して区別されない。換言すれば、本開示は、マルチＴＢスケジューリングＤＣＩと同様に機能するマルチコードワードスケジューリングＤＣＩ（「トランスポートブロック」という用語を「コードワード」という用語に置き換えた）を提供することによって、複数のコードワードのスケジューリングも可能にする。
一般に、Ｍ回の繰り返し送信はそれぞれ、Ｎ個のＴＢのうちの対応するＴＢと同じデータを搬送し得る。換言すれば、Ｍ回の繰り返し送信はそれぞれ、マルチＴＢスケジューリングＤＣＩによってスケジューリングされたＮ個のＴＢのうちの１つに対応し得る。ＴＢおよびそのＴＢに対応する繰り返し送信は、一般に同じデータを搬送し得る。しかしながら、ＴＢおよび対応する繰り返し送信は必ずしも同一ではない。例えば、上記同じデータは、ＴＢおよび対応する繰り返し送信において異なって符号化され得る。すなわち、ＴＢの繰り返し送信は、そのＴＢの異なる冗長バージョン（ＲＶ：Ｒｅｄｕｎｄａｎｃｙ Ｖｅｒｓｉｏｎ）であり得る。一般に、Ｍは１以上の数であってよく、繰り返し送信の数Ｍが１であることは、ＴＢのうちの１つに対して１つの送信（のみ）がスケジューリングされることを意味し／示し、または各ＴＢの１つの送信（のみ）がスケジューリングされることを意味して／示してよい（すなわち、各ＴＢの最初の送信が、そのＴＢの繰り返し送信の１つとしてカウントされる）。換言すれば、Ｍ＝１は、繰り返し送信がスケジューリングされていないことを示してよい。さらに言い換えれば、「送信」および「繰り返し送信」という用語は、本明細書では同義的に使用される。なお、本開示では、「さらなる繰り返し送信」という用語は、ＴＢの最初の送信以外のＴＢの送信（複数可）を指す。
なお、繰り返し送信の数Ｍは、マルチＴＢスケジューリングＤＣＩによってスケジュールされた繰り返し送信／送信の合計であってよい。しかしながら、本発明はこれに限定されず、その理由は、マルチＴＢスケジューリングＤＣＩが、Ｎ個のスケジューリングされたトランスポートブロックのそれぞれのＭ回の繰り返し送信（合計でＮ×Ｍ回の繰り返し送信）をスケジューリングし得るためである。あるいは、ＤＣＩは、ＴＢのうちの１つ（例えば、最初のもの）または一部（１つおきなど）に対してのみＭ回の繰り返し送信をスケジューリングし、他のＴＢは１度のみ送信してもよい。一般に、マルチＴＢスケジューリングＤＣＩは、スケジュールされたＴＢのそれぞれについて異なる繰り返し送信の数を通知してよい。
なお、本開示で言及する繰り返し送信および送信は、名目上の（ｎｏｍｉｎａｌ）繰り返し送信／送信または実際の繰り返し送信／送信であり得る。名目上の繰り返し送信および実際の繰り返し送信は、ＰＵＳＣＨ繰り返し送信タイプＢのためにリリース１６ＮＲで導入された概念であり、ＴＳ３８．２１４、セクション６．１．２．１に詳細な説明がある。より具体的には、名目上の繰り返し送信／送信は、設定された／スケジュールされた／通知されたリソースに基づいて意図として設定された／スケジュールされた／通知されたものである。しかしながら、一般に、名目上の繰り返し送信に割り当てられたＯＦＤＭシンボルの一部が無効であったり、名目上の繰り返し送信がスロットの境界を越えてしまったりして、その名目上の繰り返し送信が途切れたりすることがある。その結果、名目上の繰り返し送信／送信は、スロット境界または無効なＯＦＤＭシンボルによってさらに分割されて、結果的に１つまたは複数の実際の繰り返し送信となり得る。
＜送信ギャップ＞
一般的に、マルチＴＢスケジューリングＤＣＩ（例えば、スケジューリング通知）は、送信ギャップを通知してよい（例えば、その通知を含んでよい）。ここで、送信ギャップとは、ＴＢの連続する送信および／またはさらなる繰り返し送信の間の（例えば、スロットまたはＯＦＤＭシンボル単位で測定される）時間のギャップを指す。換言すれば、送信ギャップは、２つの連続する送信の間の期間（時間領域におけるリソース）を指す。２つの連続する送信／繰り返し送信は、マルチＴＢスケジューリングＤＣＩがＮ個のスケジュールされたＴＢのうちの１つの他の送信／繰り返し送信を間にスケジューリングしていない２つの送信／繰り返し送信である。
一般的に、マルチＴＢスケジューリングＤＣＩ（例えば、スケジューリング通知）は、送信ギャップを通知してよい（例えば、その通知を含んでよい）。ここで、送信ギャップとは、ＴＢの連続する送信および／またはさらなる繰り返し送信の間の（例えば、スロットまたはＯＦＤＭシンボル単位で測定される）時間のギャップを指す。換言すれば、送信ギャップは、２つの連続する送信の間の期間（時間領域におけるリソース）を指す。２つの連続する送信／繰り返し送信は、マルチＴＢスケジューリングＤＣＩがＮ個のスケジュールされたＴＢのうちの１つの他の送信／繰り返し送信を間にスケジューリングしていない２つの送信／繰り返し送信である。
これについて、図８ｃおよび図８ｄを参照してここでさらに説明する。
図８ｃは、送信ギャップを伴わない複数のＴＢのスケジューリングの一例を示している。見て分かるように、図８ｃの最初のスロットでは、マルチＴＢスケジューリングＤＣＩを含むＰＤＣＣＨが基地局によって送信され、および／またはＵＥによって受信される。そのマルチＴＢスケジューリングＤＣＩは、第３～第６のスロットに４つのＴＢをそれぞれスケジューリングする。換言すれば、マルチＴＢスケジューリングＤＣＩは、その４つのスケジュールされたＴＢ間に送信ギャップがないように４つのＴＢをスケジューリングする。すなわち、４つのＴＢは、立て続けのスロットで送信されるようにスケジューリングされる。
図８ｄは、送信ギャップを伴う複数のＴＢのスケジューリングの一例を示している。図８ｃと同様、マルチＴＢスケジューリングＤＣＩが最初のスロットで送信される。具体的には、第３のスロットから始まり１スロットおきに４つのＴＢがスケジューリングされる。すなわち、第１～第４のＴＢは、それぞれスロット＃３、＃５、＃７、および＃９で送信されるようにスケジューリングされる。すなわち、４つのＴＢは、ＴＢ間に１スロットずつの送信ギャップが設けられた状態でスケジューリングされる。
なお、一般的に、マルチＴＢスケジューリングＤＣＩによって異なる／複数の送信ギャップが通知されてよい。例えば、第１の送信ギャップはＴＢの２つの連続する最初の送信に適用され、第２のギャップは２つの連続するさらなる繰り返し送信に適用され、第３のギャップはＴＢの最初の送信および後続のさらなる繰り返し送信に適用され、ならびに／あるいは第４のギャップはさらなる繰り返し送信およびＴＢの後続の送信に適用されてよい。
＜インターリーブパターン＞
一般的に、マルチＴＢスケジューリングＤＣＩによってスケジューリングされた２つ以上のＴＢをインターリーブするために使用されるインターリーブパターンは、事前に定義されたおよび／または所定のインターリーブパターンのセットから選択されてよい。換言すれば、複数の事前に定義されたおよび／または所定のインターリーブパターンのうちの１つ（例えば、いずれか１つ）が、マルチＴＢスケジューリングＤＣＩによって通知されてよい。例えば、これらのインターリーブパターンは、ＲＲＣシグナリングを介して設定され、または例えば規格で定義されてよい。
一般的に、マルチＴＢスケジューリングＤＣＩによってスケジューリングされた２つ以上のＴＢをインターリーブするために使用されるインターリーブパターンは、事前に定義されたおよび／または所定のインターリーブパターンのセットから選択されてよい。換言すれば、複数の事前に定義されたおよび／または所定のインターリーブパターンのうちの１つ（例えば、いずれか１つ）が、マルチＴＢスケジューリングＤＣＩによって通知されてよい。例えば、これらのインターリーブパターンは、ＲＲＣシグナリングを介して設定され、または例えば規格で定義されてよい。
ＴＢの数Ｎおよび／または繰り返し送信の数Ｍは、インターリーブパターンによって暗黙的に通知されてよい。換言すれば、各インターリーブパターンは、ＴＢの数Ｎおよび／または繰り返し送信の数Ｍに関連付けられてよい。すなわち、インターリーブパターンを通知することによって、マルチＴＢスケジューリングＤＣＩは、関連付けられたＴＢの数Ｎおよび／または関連付けられた繰り返し送信の数Ｍを暗黙的に通知する。同様に、送信ギャップはインターリーブパターンによって固定されてもよく、すなわち、インターリーブパターンは特定の送信ギャップに関連付けられてよい。これらの関連付けは一般に固定されても動的であってもよく、例えば、ＲＲＣを介して設定可能であってよい。
しかしながら、本発明はこれに限定されない。一般的に、マルチＴＢスケジューリングＤＣＩ（例えば、スケジューリング通知）は、そのＤＣＩで示されるインターリーブパターンとは独立して基地局が決定および設定できる送信ギャップの明示的な通知を含んでよく、それによってスケジューリングの柔軟性が高められる。この通知は、明示的な通知（例えば、ギャップを示すためのＤＣＩ内のビットフィールド）、またはＴＤＲＡテーブルのエントリを言及する、インターリーブパターンなどとの統合表示など（そのようなＴＤＲＡテーブルは、異なる送信ギャップを指定する同じインターリーブパターンの複数のエントリを含み得る）であってよい。
一般的に、インターリーブパターンは、２つ以上の事前に定義されたインターリーブパターン、例えば、以下でさらに説明するＴＢ優先パターンおよびＲＶ優先パターンから選択されてよいが、これらに限定されない。換言すれば、インターリーブを示すマルチＴＢスケジューリングＤＣＩ内のスケジューリング通知は、２つ以上の事前に定義されたインターリーブパターンのうちのいずれが、スケジューリングされたＴＢ（および該当する場合はスケジューリングされたさらなる繰り返し送信）に使用されるかを示してよい。
ここで、図８ａ～図８ｄを参照して、いくつかの例示的なインターリーブパターンについて説明する。
図８ａは、ＴＢの送信（繰り返し送信を含む）がインターリーブされない「ＴＢ優先パターン」による繰り返し送信を伴うＴＢスケジューリングを示している。すなわち、図８ａは、ＴＢの自明（ｔｒｉｖｉａｌ）なインターリーブを伴うインターリーブパターンを示している。
図８ａ、ならびにそれに続く図８ｂから図１３ｂは一連のスロットを示しており、各ボックスは１スロットに相当する。図において、マルチＴＢスケジューリングＤＣＩは最初に示されたスロット、つまり、最も左側のスロットで受信され、そのスロットはこれ以降スロット＃１と呼ばれる。続くスロットは順に番号が振られている（スロット＃２、スロット＃３、…）。なお、矢印は時間方向を示している。
ＴＢ優先インターリーブパターンは、（２つのＴＢの場合）概略的に次のように記述され得る。
｛ＴＢ０＿ＲＶ０、ＴＢ０＿ＲＶ２、ＴＢ０＿ＲＶ３、ＴＢ０＿ＲＶ１、ＴＢ１＿ＲＶ０、ＴＢ１＿ＲＶ２、ＴＢ１＿ＲＶ３、ＴＢ１＿ＲＶ１｝
｛ＴＢ０＿ＲＶ０、ＴＢ０＿ＲＶ２、ＴＢ０＿ＲＶ３、ＴＢ０＿ＲＶ１、ＴＢ１＿ＲＶ０、ＴＢ１＿ＲＶ２、ＴＢ１＿ＲＶ３、ＴＢ１＿ＲＶ１｝
ここで、「＿」の前の表示はトランスポートブロックを示し、「＿」の後の表示は冗長バージョンを示す。より具体的には、同じく図８ａに示すように、マルチＴＢスケジューリングＤＣＩによって２つのＴＢの送信がスケジューリングされる。さらに、これら２つのＴＢのそれぞれについて、４回の繰り返し送信がスケジューリングされる。したがって、２つのスケジューリングされたＴＢはそれぞれ４回送信される（場合によってはこれら４回で異なって符号化される）。第１のＴＢの送信は、最初にスロット３～６にスケジューリングされる。具体的には、第３のスロットでは「０」の冗長バージョンが送信され、第４のスロットでは「２」の冗長バージョンが送信され、第５のスロットでは「３」の冗長バージョンが送信され、第３のスロットでは「１」の冗長バージョンが送信される。図８ａに示す例では、第１のＴＢの送信後に１スロットの送信ギャップがある。第１のＴＢの送信および送信ギャップの後に、第２のＴＢの送信がスロット８～１１にスケジューリングされる。第２のＴＢの冗長バージョンは、第１のＴＢの冗長バージョンと同じ順序で送信される。
一般的に、ＴＢ優先パターンでは、ＴＢの送信（繰り返し送信を含む）は連続して（例えば、連続するスロットで）、すなわち、それらの間に他のスケジューリングされたＴＢの送信／繰り返し送信なしで実行され得る。一般的に、ＴＢの送信の間には送信ギャップがあってもなくてもよい。さらに、あるＴＢの最後の送信と他のＴＢの最初の送信との間に送信ギャップがあってもなくてもよい。これらの送信ギャップの一部または全ては、同一であってもよく、相互に異なってもよい。
ＴＢ優先パターンは、第１のＴＢの送信の高い信頼性および低遅延を可能にし得る。第１のＴＢが第２のＴＢ（および該当する場合はさらなるＴＢ）よりも際立って高い優先度およびパフォーマンス要件を有する場合、ＴＢ優先オプションを利用することが特に有益であり得る。
図８ｂは、ＴＢの送信（繰り返し送信を含む）がインターリーブされる「ＲＶ優先パターン」による繰り返し送信を伴うＴＢスケジューリングを示している。ＲＶ優先インターリーブパターンは、概略的に次のように記述され得る。
｛ＴＢ０＿ＲＶ０、ＴＢ１＿ＲＶ０、ＴＢ０＿ＲＶ２、ＴＢ１＿ＲＶ２、ＴＢ０＿ＲＶ３、ＴＢ１＿ＲＶ３、ＴＢ０＿ＲＶ１、ＴＢ１＿ＲＶ１｝
｛ＴＢ０＿ＲＶ０、ＴＢ１＿ＲＶ０、ＴＢ０＿ＲＶ２、ＴＢ１＿ＲＶ２、ＴＢ０＿ＲＶ３、ＴＢ１＿ＲＶ３、ＴＢ０＿ＲＶ１、ＴＢ１＿ＲＶ１｝
より具体的には、同じく図８ｂに示すように、マルチＴＢスケジューリングＤＣＩによって２つのＴＢの送信がスケジューリングされる。さらに、これら２つのＴＢのそれぞれについて、４回の繰り返し送信がスケジューリングされる。したがって、２つのスケジューリングされたＴＢはそれぞれ４回送信される（場合によってはこれら４回で異なって符号化される）。
第１のＴＢの送信は、第３のスロットから始まって１スロットおきに（スロット＃３、＃５、＃７、および＃９に）スケジューリングされる。第２のＴＢの送信は、第４のスロットから始まって１スロットおきに（スロット＃４、＃６、＃８、および＃１０に）スケジューリングされる。すなわち、第１スロットおよび第２スロットの送信はインターリーブされる。
各ＴＢの最初の送信（スロット＃３および＃４）では、それぞれのＴＢの「０」の冗長バージョンが送信され、各ＴＢの２回目の送信、すなわち最初のさらなる繰り返し送信（スロット＃５および＃６）では、それぞれのＴＢの「２」の冗長バージョンが送信され、各ＴＢの３回目の送信（スロット＃７および＃８）では、それぞれのＴＢの「３」の冗長バージョンが送信され、各ＴＢの４回目の送信（スロット＃９および＃１０）では、それぞれのＴＢの「１」の冗長バージョンが送信される。図８ｂに示す例では、ＴＢおよびさらなる繰り返し送信は、それらの間にギャップなく送信される。
一般に、ＲＶ優先パターンでは、あるＴＢの２つの送信の間に、互いにスケジューリングされたＴＢの（例えば、１つの）送信が存在し得る。異なるＴＢの冗長バージョンは同じ順序（これはＲＶ優先パターンによって指定されてよい）で送信されてよい。
ＲＶ優先パターンは時間ダイバーシティを高めることを可能にし、これは特に周波数ダイバーシティが低い状況で信頼性を高めることを可能にし得る。一般に、ＲＶ優先パターンでは、ＴＢの送信／繰り返し送信は連続して（例えば、連続するスロットで）、すなわち、送信／繰り返し送信間にギャップなしで実行されてよい。しかしながら、送信／繰り返し送信の間にギャップが存在してもよく、これにより時間ダイバーシティがさらに高まり得る。
図８ｃおよび図８ｄは、それぞれギャップなしおよびギャップありでＴＢがスケジューリングされる、繰り返し送信なしのインターリーブパターンのさらなる例を示している。これらについては、すでにＴＢ間の送信ギャップを説明する際に上記で説明している。
なお、容量を増加させるために、時間領域インターリーブをインターリーブ分割多元接続（ＩＤＭＡ：ｉｎｔｅｒｌｅａｖｅ－ｄｉｖｉｓｉｏｎ ｍｕｌｔｉｐｌｅ－ａｃｃｅｓｓ）で使用することもできる。
＜統合スケジューリング通知およびＴＤＲＡテーブル＞
一般的に、スケジューリング通知はＴＤＲＡテーブルのエントリを通知して良く、当該エントリは数ＮとスケジューリングギャップＫとを示してよい。また、当該エントリは、マルチＴＢスケジューリングＤＣＩにスケジュールされた送信を示してよく、各送信に対して、その送信のための１つまたは複数のリソースを示してよい。さらに、当該エントリは、以下で説明されるように、インターリーブパターンおよび／または送信ギャップといった、スケジュールされた送信に関連する他のパラメータも示してよい。
一般的に、スケジューリング通知はＴＤＲＡテーブルのエントリを通知して良く、当該エントリは数ＮとスケジューリングギャップＫとを示してよい。また、当該エントリは、マルチＴＢスケジューリングＤＣＩにスケジュールされた送信を示してよく、各送信に対して、その送信のための１つまたは複数のリソースを示してよい。さらに、当該エントリは、以下で説明されるように、インターリーブパターンおよび／または送信ギャップといった、スケジュールされた送信に関連する他のパラメータも示してよい。
具体的に、マルチＴＢスケジューリングＤＣＩは、ｉ）ＴＢの数Ｎ、ｉｉ）繰り返し送信の数、ｉｉｉ）送信ギャップ、およびｉｖ）インターリーブパターン、のうちの１つ、複数、または全てを統合的にＵＥに通知してよい。換言すれば、マルチＴＢスケジューリングＤＣＩ内のスケジューリング通知は、Ｎ個のＴＢのスケジューリングと、前述のポイントｉ）～ｉｖ）のうちの１つまたは複数との統合通知であってよい。
例えば、そのような統合スケジューリング通知は、ＤＣＩ内のパラメータまたはＤＣＩ内のフィールドであってよい。統合スケジューリング通知は、時間領域リソース割り当て（ＴＤＲＡ：ｔｉｍｅ ｄｏｍａｉｎ ｒｅｓｏｕｒｃｅ ａｌｌｏｃａｔｉｏｎ）テーブルのエントリの言及であってもよい。具体的には、統合通知は、ＴＤＲＡテーブルのエントリ（例えば、行）を示すインデックス（例えば、行インデックス）の通知であってよい。すなわち、統合スケジューリング通知は、上記のパラメータｉ）～ｖｉ）のうちの１つまたは複数に対応する列が追加されたＴＤＲＡテーブルによって通知され得る。換言すれば、ＴＤＲＡテーブルシグナリングフレームワークは、例えば既存のＴＤＲＡテーブルを追加のエントリ／行／列で拡張することによって、複数のＴＢのスケジューリングに対応するように強化され得る。
複数のＴＢのスケジューリングのためのＴＤＲＡテーブルの一例を以下に示す。
上記のテーブル一例に示すように、複数のＴＢのスケジューリングのためのＴＤＲＡテーブルは以下（上記のテーブル一例の最後の４行にそれぞれ対応する）を含んでよい。
ｉ）１つまたは複数の（さらには各）行インデックスについて、ＴＢの数Ｎを特定または通知する行、
ｉｉ）１つまたは複数の（さらには各）行インデックスについて、繰り返し送信の数Ｍを特定または通知する行、
ｉｉｉ）１つまたは複数の（さらには各）行インデックスについて、送信ギャップを特定または通知する行、ならびに／あるいは、
ｉｖ）１つまたは複数の（さらには各）行インデックスについて、インターリーブパターンを特定または通知する行。
ｉ）１つまたは複数の（さらには各）行インデックスについて、ＴＢの数Ｎを特定または通知する行、
ｉｉ）１つまたは複数の（さらには各）行インデックスについて、繰り返し送信の数Ｍを特定または通知する行、
ｉｉｉ）１つまたは複数の（さらには各）行インデックスについて、送信ギャップを特定または通知する行、ならびに／あるいは、
ｉｖ）１つまたは複数の（さらには各）行インデックスについて、インターリーブパターンを特定または通知する行。
換言すれば、行インデックスごとに、上記のポイントｉ）～ｉｖ）で述べたパラメータのうちの１つまたは複数が定義され得る。行が行インデックスを（明示的に）特定しない場合（上記のテーブル一例では、最後の４行の「ＮＡ」エントリに対応）、事前に定義された値またはデフォルトの値が使用されてよい。例えば、いくつかのインターリーブパターンは、デフォルトの送信ギャップに関連付けられてよい。
具体的には、行インデックスは、マルチＴＢスケジューリングＤＣＩ内のスケジューリング通知によって示されてよい。すなわち、行インデックスは、Ｎ個のＴＢのスケジューリングと、パラメータｉ）～ｉｖ）のうちの１つまたは複数とを示す、マルチＴＢスケジューリングＤＣＩ内の統合スケジューリング通知であってよい。
複数のパラメータ（例えば、複数のＴＢの数、繰り返し送信の数Ｍ、インターリーブパターン、および送信ギャップ）の統合スケジューリング通知を使用することにより、ＤＣＩオーバーヘッドが追加されることなく、または最小限の追加での、複数のＴＢのスケジューリングを可能にし得る。さらに、ＴＤＲＡテーブルなどに基づく統合スケジューリング通知は、単一のＤＣＩによる複数のＴＢの送信／受信のための時間／周波数領域リソースの柔軟な割り当てを可能にし得る。
なお、複数のＴＢのスケジューリングに対応するＴＤＲＡテーブルは、特定のサーチスペース（ＳＳ：Ｓｅａｒｃｈ Ｓｐａｃｅ）セットまたは帯域幅パート（ＢＷＰ）で設定され得る／これに関連付けられ得る。すなわち、複数のＴＢのスケジューリングに対応する１つまたは複数のＴＤＲＡテーブルと、複数のＴＢのスケジューリングに対応しない１つまたは複数のＴＤＲＡテーブルとが存在し得る。
＜設定グラント（ＣＧ）および半永続的スケジューリング（ＳＰＳ）フレームワーク＞
一般に、ＵＥ（例えば、その処理回路）は、動作時に、マルチＴＢスケジューリングＤＣＩから、設定グラント（ＣＧ）または半永続的スケジューリング（ＳＰＳ）をアクティブ化する通知を取得してよい。例えば、Ｎ個のＴＢのスケジューリングを示すスケジューリング通知は、ＣＧ／ＳＰＳをアクティブ化する通知であってよい（またはその通知を含んでよい）。ＣＧ／ＳＰＳをアクティブ化する通知を取得した後、回路は、動作時に、その通知に従ってＣＧまたはＳＰＳをアクティブ化してよい。ＣＧまたはＳＰＳは、複数の送信機会を通知してよい。回路は、動作時に、上記マルチＴＢスケジューリングＤＣＩの受信から始まるＮ回の送信機会の後、ＣＧまたはＳＰＳを非アクティブ化してよい。なお、ＳＰＳおよびＣＧ（特に「タイプ２」ＣＧ）は、それぞれＤＬおよびＵＬにおける複数のＴＢのスケジューリングを可能にするために使用されてよい。
一般に、ＵＥ（例えば、その処理回路）は、動作時に、マルチＴＢスケジューリングＤＣＩから、設定グラント（ＣＧ）または半永続的スケジューリング（ＳＰＳ）をアクティブ化する通知を取得してよい。例えば、Ｎ個のＴＢのスケジューリングを示すスケジューリング通知は、ＣＧ／ＳＰＳをアクティブ化する通知であってよい（またはその通知を含んでよい）。ＣＧ／ＳＰＳをアクティブ化する通知を取得した後、回路は、動作時に、その通知に従ってＣＧまたはＳＰＳをアクティブ化してよい。ＣＧまたはＳＰＳは、複数の送信機会を通知してよい。回路は、動作時に、上記マルチＴＢスケジューリングＤＣＩの受信から始まるＮ回の送信機会の後、ＣＧまたはＳＰＳを非アクティブ化してよい。なお、ＳＰＳおよびＣＧ（特に「タイプ２」ＣＧ）は、それぞれＤＬおよびＵＬにおける複数のＴＢのスケジューリングを可能にするために使用されてよい。
すなわち、ＣＧ／ＳＰＳは、繰り返し送信の有無にかかわらず複数のＴＢのスケジューリングを可能にするように強化され得る。特にこの場合、マルチＴＢスケジューリングＤＣＩは単にトリガ（例えば、マルチＴＢスケジューリングＤＣＩ内の１ビットのフィールド）であり得る。すなわち、トランスポートブロックの数Ｎ、繰り返し送信の数Ｍ、インターリーブパターン、および送信ギャップは、他の手段によって通知されてよく、例えば、ＣＧ／ＳＰＳによりＲＲＣ設定でシグナリングされてよい。しかしながら、本発明はこれに限定されず、その理由は、インターリーブパターンおよび／または送信ギャップが、ＣＧ／ＳＰＳをアクティブ化するマルチＴＢスケジューリングＤＣＩによって通知されてもされなくてもよいためである。
一般的に、複数の送信機会（例えば、時間リソース）は、（例えば、ＣＧ／ＳＰＳフレームワークを使用して）ＲＲＣで設定され得る。複数の送信機会の一部は、ＣＧ／ＳＰＳトリガＤＣＩの制御情報によって選択されてよい。複数の送信機会の一部の残りはリリースされる。例えば、ＣＧ／ＳＰＳのＤＣＩは、スケジュールされたＴＢ（および該当する場合はさらなる繰り返し送信）の送信／受信のために、設定された送信機会から選択される送信機会の明示的な通知を含んでよい。ＣＧ／ＳＰＳのＤＣＩにトリガフラグしかない場合、スケジュールされたＴＢの数Ｎおよび／または送信機会の数は、トリガされたＣＧ／ＳＰＳ設定のためにＲＲＣを介して設定されてよい。
＜ＣＧ／ＳＰＳトリガＤＣＩによって通知されるトランスポートブロック数Ｎ＞
一般的に、ＴＢ数Ｎは、ＣＧ／ＳＰＳをトリガ／アクティブ化するＤＣＩで通知され得る。すなわち、マルチＴＢスケジューリングＤＣＩの制御情報（例えば、Ｎ個のＴＢのスケジューリングを示すスケジューリング通知）は、ＴＢの数Ｎであるか、またはこれを含み得る。この場合、ＵＥは、Ｎ回の送信機会の後、またはＴＢのＮ回の実際の送信後に、ＣＧ／ＳＰＳを自動的にリリースしてよい。あるいは、ＵＥは、繰り返し送信を含むスケジュールされた送信の数に等しい／対応する数の送信機会の後、または繰り返し送信を含むスケジュールされたＴＢを実際に送信／受信した後に、ＣＧ／ＳＰＳを自動的にリリースしてよい。具体的には、ＵＥ／基地局は、ＴＢ／繰り返し送信を実際に送信するために、ＣＧ／ＳＰＳをトリガ／アクティブ化するＤＣＩによってスケジュールされた送信／繰り返し送信の全てを使用しなくてもよい。
一般的に、ＴＢ数Ｎは、ＣＧ／ＳＰＳをトリガ／アクティブ化するＤＣＩで通知され得る。すなわち、マルチＴＢスケジューリングＤＣＩの制御情報（例えば、Ｎ個のＴＢのスケジューリングを示すスケジューリング通知）は、ＴＢの数Ｎであるか、またはこれを含み得る。この場合、ＵＥは、Ｎ回の送信機会の後、またはＴＢのＮ回の実際の送信後に、ＣＧ／ＳＰＳを自動的にリリースしてよい。あるいは、ＵＥは、繰り返し送信を含むスケジュールされた送信の数に等しい／対応する数の送信機会の後、または繰り返し送信を含むスケジュールされたＴＢを実際に送信／受信した後に、ＣＧ／ＳＰＳを自動的にリリースしてよい。具体的には、ＵＥ／基地局は、ＴＢ／繰り返し送信を実際に送信するために、ＣＧ／ＳＰＳをトリガ／アクティブ化するＤＣＩによってスケジュールされた送信／繰り返し送信の全てを使用しなくてもよい。
＜ＲＲＣによって通知される／設定されるトランスポートブロック数Ｎ＞
一般的に、既に上述したように、トランスポートブロックの数ＮはＲＲＣを介して通知されてよい。
一般的に、既に上述したように、トランスポートブロックの数ＮはＲＲＣを介して通知されてよい。
具体的には、特定のＣＧ／ＳＰＳ設定内で、ＴＢの数ＮまたはタイマがＲＲＣによって設定されてよい。タイマを使用する場合、タイマは、例えば最初のＴＢの送信から開始してもよく、あるいはマルチＴＢスケジューリングＤＣＩの送信から開始してもよい。ＣＧ／ＳＰＳ設定がトリガされた場合、タイマ満了後、またはＴＢ数の送信後に、定期的な送信が自動的にリリース／終了される。換言すれば、複数のＣＧ／ＳＰＳ設定が設定されてよく、ＣＧ／ＳＰＳトリガＤＣＩは、設定されたＣＧ／ＳＰＳ設定のうちの１つを明示的または暗黙的に通知してよい。例えば、ＣＧ／ＳＰＳトリガＤＣＩはそのＣＧ／ＳＰＳをトリガしてよく、その時間領域リソースはＣＧ／ＳＰＳトリガＤＣＩが送信されるスロットを含む。さらなる例として、ＣＧ／ＳＰＳトリガＤＣＩが送信されるスロットを２つ以上のＣＧ／ＳＰＳ設定が含む場合、より低いインデックスまたはより高い優先度を有するＣＧ／ＳＰＳがトリガされる。インデックスおよび／または優先度は、例えば、ＣＧ／ＳＰＳ設定にＲＲＣで設定され得る。
図９は、ＣＧ／ＳＰＳフレームワークを使用して複数のＴＢをスケジューリングする場合の自動リリースを示している。なお、インターリーブパターン、送信ギャップ、ならびに数ＮおよびＭは図８ａと同じである。したがって、同じ説明は繰り返さない。図９に示すように、最後にスケジュールされたＴＢの送信（スケジュールされた繰り返し送信を含む）の後に、ＣＧ／ＳＰＳが自動的にリリース／非アクティブ化される。すなわち、第２のＴＢの「１」の冗長バージョンの送信後である（すなわち、スロット＃１１の後であり、＃１はＣＧ／ＳＰＳトリガＤＣＩを送信するスロットである）。
ＣＧ／ＳＰＳを使用して単一のＤＣＩで複数のＴＢをスケジューリングすることは、既存のＳＰＳ／ＣＧフレームワークを使用するため、単純で効率的な解決策であり得る。具体的には、このアプローチは、規格に導入される必要があるパラメータの数を減らし得るので、仕様への影響が少なくなり得る。さらに、現在のＳＰＳ／ＣＧフレームワークとは対照的に、複数のＴＢのスケジューリングにＣＧ／ＳＰＳを使用することにより、ｇＮＢは、２つのＤＣＩ（１つはＳＰＳ／ＣＧのアクティブ化用、１つは非アクティブ化用）を使用するのではなく、１つのＤＣＩを使用するだけで複数のＴＢのスケジューリングを終了することが可能になり得る。これによりＵＥはＳＰＳ／ＣＧの非アクティブ化のためにＰＤＣＣＨを監視することが不要になり得るので、ＰＤＣＣＨ監視の電力消費がさらに節約され得る。
一般的に、ＵＥのＰＤＣＣＨ（Ｐｈｙｓｉｃａｌ Ｄｏｗｎｌｉｎｋ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ）監視動作は、ＤＣＩによってスケジュールされたＴＢの数Ｎに応じて適応され得る。
一般的に、複数のＴＢのスケジューリングは、それに応じて適応することにより、さらなる省電力を可能にし得る。より具体的には、複数のＴＢのスケジューリングは、より少ないＤＣＩで同じ量のリソースおよび／またはＴＢをスケジューリングすることを可能にし得る。したがって、より多くのリソースが一度にＵＥにスケジューリングされるため、ＰＤＣＣＨ監視は複数のＴＢのスケジューリングに適応され得る。ＰＤＣＣＨ監視動作／行動のそのような適応は、ＵＥ自体の電力消費をさらに削減することを促進し得るが、他のＵＥにより多くのスケジューリング機会を与えるためにも使用され得る。
例えば、パラメータ「ｍｏｎｉｔｏｒｉｎｇＳｌｏｔＰｅｒｉｏｄｉｃｉｔｙＡｎｄＯｆｆｓｅｔ」および「ｍｏｎｉｔｏｒｉｎｇＳｙｍｂｏｌｓＷｉｔｈｉｎＳｌｏｔ」の複数のセットを設定することができる。一方で、単一ＴＢスケジューリングＤＣＩは、ＵＥを第１のパラメータのセットによって指定されたＰＤＣＣＨ監視機会に切り替わらせ、マルチＴＢスケジューリングＤＣＩは、ＵＥを第２のパラメータのセットによって指定されたＰＤＣＣＨ監視機会に切り替わらせてよい。ＵＥは、単一ＴＢスケジューリングＤＣＩを受信したときに第１のセットを既に使用している場合、第１のパラメータのセットを使用し続けてよい。同様に、ＵＥは、マルチＴＢスケジューリングＤＣＩを受信したときに第２のパラメータのセットを既に使用している場合、第２のセットを使用し続けてよい。
換言すれば、単一ＴＢスケジューリングＤＣＩを受信した場合、および／またはマルチＴＢスケジューリングＤＣＩを受信した場合、ＵＥは上記パラメータの２つ以上のセットのうちのいずれを使用すべきかを再評価してよく、またはより一般的には、自身のＰＤＣＣＨ監視行動を再評価してよい。一般的に、マルチＴＢスケジューリングＤＣＩおよび単一ＴＢスケジューリングＤＣＩの一方または両方が、パラメータセットの適応／再評価をトリガし得る。
より具体的に、ＵＥがＤＣＩを受信すると、ＵＥ（またはその処理回路）は、そのＰＤＣＣＨ監視動作を変更するか否かを判定してよい。この判定は、上記ＤＣＩが単一ＴＢスケジューリングＤＣＩであるかマルチＴＢスケジューリングＤＣＩであるかに基づいてよい。しかしながら、この判定は、例えば、バッテリーの状態、予想されるトラフィックなどのさらなる基準に依存し得る（例えば、考慮し得る）。
例えば、上記ＤＣＩが単一ＴＢスケジューリングＤＣＩである場合、ＵＥは第１のＰＤＣＣＨ候補のセットを監視することを決定してよい。一方、上記ＤＣＩがマルチＴＢスケジューリングＤＣＩである場合、ＵＥは第２のＰＤＣＣＨ候補のセットを監視することを決定してよい。換言すれば、ＵＥは第１または第２のＰＤＣＣＨ候補のセットのいずれを監視するかを決定してよい。第２のＰＤＣＣＨ候補のセットは、第１のＰＤＣＣＨ候補のセットより小さくてもよい。代替的または追加的に、ＵＥは、上記ＤＣＩが単一ＴＢスケジューリングＤＣＩである場合と比較して、上記ＤＣＩがマルチＴＢスケジューリングＤＣＩである場合に、より少ない頻度でそのＰＤＣＣＨを監視することを決定してよい。ＵＥは削減された数のＰＤＣＣＨ候補を監視してもよく、あるいは所定の期間の間、および／または他のＤＣＩを受信するまで（具体的には、単一ＴＢスケジューリングＤＣＩを受信するまで）より少ない頻度で監視を実行してもよい。具体的には、マルチＴＢスケジューリングＤＣＩを受信した場合、ＵＥはＰＤＣＣＨ監視を所定の期間完全に停止することを決定さえしてもよい。
＜取り消し通知（ＣＩ）＞
一般的に、（例えば、ＤＣＩシグナリングにおける）制御情報は取り消し通知（ＣＩ）を含んでよい。一般的に、そのようなＣＩは、ＵＬ ＣＩまたはＤＬプリエンプション通知（ＰＩ）であり得る。ＣＩは取り消される１つまたは複数の送信を通知してよい。ＣＩは、リソース（例えば、１つまたは複数の時間領域リソース、シンボルの数、またはスロット全体）を通知することにより、取り消される１つまたは複数の送信を通知してよい。換言すると、ＣＩはリソースを示す通知を含んでよい。一般的に、ＣＩによって通知される１つまたは複数の送信をスケジューリングするＤＣＩは、当該ＣＩを含む制御情報の前に受信／送信され、当該ＣＩは通知された送信が行われる前に受信／送信される。
一般的に、（例えば、ＤＣＩシグナリングにおける）制御情報は取り消し通知（ＣＩ）を含んでよい。一般的に、そのようなＣＩは、ＵＬ ＣＩまたはＤＬプリエンプション通知（ＰＩ）であり得る。ＣＩは取り消される１つまたは複数の送信を通知してよい。ＣＩは、リソース（例えば、１つまたは複数の時間領域リソース、シンボルの数、またはスロット全体）を通知することにより、取り消される１つまたは複数の送信を通知してよい。換言すると、ＣＩはリソースを示す通知を含んでよい。一般的に、ＣＩによって通知される１つまたは複数の送信をスケジューリングするＤＣＩは、当該ＣＩを含む制御情報の前に受信／送信され、当該ＣＩは通知された送信が行われる前に受信／送信される。
以下では、マルチＴＢスケジューリングＤＣＩによってスケジュールされた送信のうち、１つまたは複数の送信を効果的な方法で通知できるようにする取り消しルールが提供される。
＜取り消しルール‐一般事項＞
一般的に、ＵＥ（例えば、回路６３０または６３５）はＣＩによって取り消される送信を（例えば、ステップ７８５において）決定してよい。この決定は、取り消しルールおよび／またはＣＩによって通知されるリソースに基づいてよい。それぞれの送信に対して、この決定の結果は、その送信のリソースにさらに基づいてよい。
一般的に、ＵＥ（例えば、回路６３０または６３５）はＣＩによって取り消される送信を（例えば、ステップ７８５において）決定してよい。この決定は、取り消しルールおよび／またはＣＩによって通知されるリソースに基づいてよい。それぞれの送信に対して、この決定の結果は、その送信のリソースにさらに基づいてよい。
基地局（例えば、回路６８０または６８５）は、ＣＩによって通知されるリソースを、ＣＩを解釈するために使用する取り消しルールと同じ取り消しルールに基づいて決定してよい。すなわち、ＵＥは通知されたリソースに基づいて取り消される送信を決定するために取り消しルールを使用し、基地局は通知するリソースを（例えば、ステップ７４０において）決定するために取り消しルールを使用する。より具体的に、基地局は、ＵＥが取り消しルールと通知されるリソースとに基づいて、取り消される送信を正しく決定できるように、通知するリソースを決定してよい。ここで、「正しく」とは、ＵＥが取り消されると決定する送信が、実際に基地局が取り消そうとしている送信（例えば、基地局がステップＳ７３０で取り消されることを決定した送信）であるようにすることを意味している。
なお、いくつかの実装において、取り消しルールは、ＣＩが送信されるスロットの後、および／または通知されたリソースのスロットの後にある、マルチＴＢスケジューリングＤＣＩによってスケジュールされた送信のみに適用される。換言すると、いくつかの実装において、ＣＩは、当該ＣＩの後のスロット、および／または当該ＣＩによって通知されるリソースのスロットの後のスロットにスケジュールされた送信のみを取り消してもよい。
＜ＴＢ優先度を使用しない取り消しルール＞
以下では、スケジュールされた複数のＴＢ（の一部またはすべての）取り消しのための所定／取り消しルールを５つ例示する。これらのルールは、スケジュールされたＮ個のＴＢの優先度とは無関係に適用されるルールの一例である。具体的に、これらのルールは、ＴＢに優先度が割り当てられることを必要としない。
以下では、スケジュールされた複数のＴＢ（の一部またはすべての）取り消しのための所定／取り消しルールを５つ例示する。これらのルールは、スケジュールされたＮ個のＴＢの優先度とは無関係に適用されるルールの一例である。具体的に、これらのルールは、ＴＢに優先度が割り当てられることを必要としない。
しかしながら、本発明はこれに限定されない。一般的に、どの取り消しルールもＴＢの優先度を使用して実行されてよい。例えば、所定のルールは、特定の優先度（例えば、ある閾値より上／下の優先度）を有するＴＢにのみ適用されてよい。例えば、ｉ）取り消しルールは高優先度（例えば、ある優先度閾値より上）のＴＢにのみ適用され、低優先度のＴＢ（例えば、ある優先度閾値より下）のＴＢはすべてＣＩを受信すると取り消されてよい、ｉｉ）取り消しルールは低優先度のＴＢにのみ適用されてよく、高優先度のＴＢはＣＩが受信されても取り消されない、またはｉｉｉ）ＴＢにはそれぞれ異なる取り消しルールが使用されてもよい（例えば、Ｎ個のＴＢに対して（異なる可能性のある）Ｎ個の取り消しルールがそれぞれ定義されてよい）。
＜取り消しルールの第１の例＞
いくつかの実施形態において、Ｎ個のＴＢのためにスケジュールされた各送信に対して、（ＣＩによって）通知されたリソースが当該送信のリソースのいずれかと重なる場合、当該送信は取り消されると決定される。
いくつかの実施形態において、Ｎ個のＴＢのためにスケジュールされた各送信に対して、（ＣＩによって）通知されたリソースが当該送信のリソースのいずれかと重なる場合、当該送信は取り消されると決定される。
ここで、図１０ａおよび図１０ｂを参照して、第１の取り消しルールをさらに説明する。図１０ａにおいて、マルチＴＢスケジューリングＤＣＩはスロット＃１で受信される。マルチＴＢスケジューリングＤＣＩは、２つのＴＢのそれぞれに対して４つの繰り返し送信のスケジューリング、図８ａを参照してすでに説明された「ＴＢ優先パターン」（ＴＢ優先インターリーブパターンを含む）、および異なるＴＢの送信間の１スロットの送信ギャップを通知する。また、ＣＩを含む制御情報がスロット＃２で受信される。ＣＩは、ＴＢ＃１の第１の送信（ＲＶ０）と重なるスロット＃４全体またはスロット＃４のリソースを通知する。
図１０ｂは、第１の取り消しルールが適用された場合、図１０ａのどの送信が取り消されるかを示す。より具体的には、図１０ｂ（ならびに図１０ｃ、１０ｄ、１１ｂ、１１ｃ）において、線で消されたスロットの送信は、図に示された取り消しルールに従って取り消される送信である。つまり、図１０ｂに示されるように、通知されるリソースと重なるＴＢ＃１の第１の送信（ＲＶ０）のみが取り消されると通知／決定される。一方、通知されるリソースに重ならないＴＢ＃１の他の３つの送信ならびにＴＢ＃２の４つの送信は取り消されない。
一般的に、送信のリソースが通知されるリソースと重なる場合、当該送信の取り消しが決定されてよい。さらに、送信のリソースがいずれも通知されるリソースと重ならない場合、当該送信は取り消されないと決定されてよい。具体的に、通知されるリソースがＴＢのためにスケジュールされた送信のリソースのいずれにも重ならない場合、ＴＢのためにスケジュールされた送信はいずれも取り消されないと決定されてよい。
換言すると、ＣＩは、当該ＣＩによって通知されるリソースと重なる（例えば、マルチＴＢスケジューリングＤＣＩによってスケジュールされた送信のうちの）それらの送信は取り消されると（例えば、明確に）通知してよい。すなわち、第１の取り消しルールに従って、ＣＩによって通知されるリソースと重なるＴＢのそれらの繰り返し送信のみが取り消されてよい。これは、ＴＢの繰り返し送信が特定のインターリーブパターン（例えば、上述したＲＶ優先パターン）を利用する場合にも適用できる。
第１の取り消しルールは、特定／単一の送信を幾分柔軟に取り消すことができ、仕様上の影響が少ない可能性がある。ＴＢの送信をできるだけ残すことで、送信のパフォーマンスに与える影響を少なくすることができる。特に、第１の取り消しルールは、ＴＢの個々の送信を選択的に取り消すことを可能にし得る。
＜取り消しルールの第２の例＞
いくつかの実施形態において、マルチＴＢスケジューリングＤＣＩによってスケジュールされた各ＴＢに対して、通知されるリソースが、当該ＴＢのためにスケジュールされた１つまたは複数の送信のリソースのいずれかと重なる場合、通知されるリソースと重なる、および／または通知されるリソースの後にスケジュールされた、当該ＴＢのためにスケジュールされた１つまたは複数の送信のうちのそれらの送信は取り消されると決定される。
いくつかの実施形態において、マルチＴＢスケジューリングＤＣＩによってスケジュールされた各ＴＢに対して、通知されるリソースが、当該ＴＢのためにスケジュールされた１つまたは複数の送信のリソースのいずれかと重なる場合、通知されるリソースと重なる、および／または通知されるリソースの後にスケジュールされた、当該ＴＢのためにスケジュールされた１つまたは複数の送信のうちのそれらの送信は取り消されると決定される。
ここで、図１１ａおよび図１１ｂを参照して、第２の取り消しルールをさらに説明する。図１１ａにおいて、マルチＴＢスケジューリングＤＣＩはスロット＃１で受信される。マルチＴＢスケジューリングＤＣＩは、２つのＴＢのそれぞれに対して４つの繰り返し送信のスケジューリング、図８ａを参照してすでに説明された「ＴＢ優先パターン」（ＴＢ優先インターリーブパターンを含む）、および異なるＴＢの送信間の１スロットの送信ギャップを通知する。また、ＣＩを含む制御情報がスロット＃２で受信される。ＣＩは、ＴＢ＃１の第２１の送信（ＲＶ２）と重なるスロット＃５全体またはスロット＃５のリソースを通知する。
図１１ｂは、第２の取り消しルールが適用された場合、図１１ａのどの送信が取り消されるかを示す。つまり、図１１ｂに示されるように、通知される（スロット＃５の）リソースと重なるＴＢ＃１の第２の送信（スロット＃５のＲＶ２）が取り消されると通知／決定される。さらに、ＴＢ＃１の第３（スロット＃６のＲＶ３）および第４（スロット＃７のＲＶ１）の送信は、通知されるリソースと重なるＴＢの送信の後の、同じＴＢの送信であるため、それらも取り消されると通知／決定される。すなわち、ＴＢ＃１の送信のうち、通知されるリソースと重ならず、通知されるリソースと重なるＴＢ＃１の送信の後でもない、ＴＢ＃１の第１の送信のみが取り消されない。また、ＴＢ＃２の４つの送信はいずれも通知されるリソースと重ならないため、それらの送信はいずれも取り消されない。
一般的に、第２の取り消しルールによると、特定のＴＢ（複数可）の繰り返し送信のいずれかがＣＩによって通知されるリソースと重なる場合、その（それらの）ＴＢの繰り返し送信は通知されるリソース以降すべて取り消されてよい。より具体的に、各ＴＢに対して、通知されるリソースが当該ＴＢの送信のためにスケジュールされたリソースのいずれにも重ならない場合、当該ＴＢのためにスケジュールされた送信はいずれも取り消されないと決定されてよい。また、通知されるリソースの前（かつ重ならない）の送信はいずれも取り消されないと決定されてよい。さらに、各ＴＢに対して、通知されるリソースが当該ＴＢの送信のためにスケジュールされたリソースのうちの１つと重なる場合、通知されるリソースに重なる、および／または通知されるリソースの後の当該ＴＢの送信は取り消されると決定されてよい。
第２の取り消しルールは特定の／選択されたＴＢの送信の一部またはすべてを取り消すことができ、仕様上の影響が少ない可能性がある。ＴＢの各送信に対して判定／決定が行われるわけではないため、デバイスの実装も低いレベルでよい。特に、第２の取り消しルールは、１つのＤＣＩで特定のＴＢの多くの送信を取り消すことを可能にしながら、当該ＴＢの送信を適当な回数（自由に選択可能）取り消さない柔軟性も確保する。
＜取り消しルールの第３の例＞
いくつかの実施形態において、マルチＴＢスケジューリングＤＣＩによってスケジュールされた各ＴＢに対して、通知されるリソースが、当該ＴＢのためにスケジュールされた１つまたは複数の送信のリソースのいずれか（例えば、少なくとも一つ）と重なる場合、当該ＴＢのためにスケジュールされた１つまたは複数の送信はすべて取り消されると決定される。
いくつかの実施形態において、マルチＴＢスケジューリングＤＣＩによってスケジュールされた各ＴＢに対して、通知されるリソースが、当該ＴＢのためにスケジュールされた１つまたは複数の送信のリソースのいずれか（例えば、少なくとも一つ）と重なる場合、当該ＴＢのためにスケジュールされた１つまたは複数の送信はすべて取り消されると決定される。
図１０ｃは、第３の取り消しルールが適用された場合、図１０ａのどの送信が取り消されるかを示す。つまり、図１０ｃに示されるように、ＴＢ＃１の送信の１つのリソースが通知されるリソースと重なる（より具体的には、ＴＢ＃１の第１の送信が通知されるリソースと重なる）ため、ＴＢ＃１の４つの送信はすべて取り消されると通知／決定される。また、ＴＢ＃２の４つの送信はいずれも通知されるリソースと重ならないため、それらの送信はいずれも取り消されないと通知／決定される。
一般的に、第３の取り消しルールによると、特定のＴＢ（複数可）の繰り返し送信のいずれかがＣＩによって通知されるリソースと重なる場合、その（それらの）ＴＢの繰り返し送信はすべて取り消されてよい。より具体的に、各ＴＢに対して、通知されるリソースが当該ＴＢの送信のためにスケジュールされたリソースのいずれにも重ならない場合、当該ＴＢのためにスケジュールされた送信はいずれも取り消されないと決定されてよい。さらに、各ＴＢに対して、通知されるリソースが当該ＴＢの送信のためにスケジュールされたリソースのうちの１つ（例えば、任意のリソース、または少なくとも一つのリソース）と重なる場合、当該ＴＢの送信はすべて取り消されると決定されてよい。つまり、ＴＢの送信はすべて取り消されるか、いずれも取り消されないかのどちらかであってよい。
第３の取り消しルールは特定の／選択されたＴＢの送信をすべて取り消すことができ、仕様上の影響が少ない可能性がある。加えて、ＴＢの送信をすべて取り消すことは、高優先度の他のトラフィックのより良い保護につながる。特に、第３の取り消しルールは、１つのＤＣＩで特定のＴＢの（残っている）送信をすべて取り消すことが可能であり、ＴＢの送信がすべて取り消されるか、いずれも取り消されないかのどちらかであるため、とりわけ単純であり得る。
＜取り消しルールの第４の例＞
いくつかの実施形態において、通知されるリソースが、複数のＴＢのためにスケジュールされた送信のいずれかのリソースと重なる場合、その（すべての）ＴＢのためにスケジュールされた送信はすべて取り消されると決定される。換言すると、通知されるリソースが、複数のＴＢのためにスケジュールされた送信の少なくとも一つの送信の少なくとも一つのリソースと重なる場合、その複数のＴＢのためにスケジュールされた送信はすべて取り消されると決定してよい。
いくつかの実施形態において、通知されるリソースが、複数のＴＢのためにスケジュールされた送信のいずれかのリソースと重なる場合、その（すべての）ＴＢのためにスケジュールされた送信はすべて取り消されると決定される。換言すると、通知されるリソースが、複数のＴＢのためにスケジュールされた送信の少なくとも一つの送信の少なくとも一つのリソースと重なる場合、その複数のＴＢのためにスケジュールされた送信はすべて取り消されると決定してよい。
図１０ｄは、第４の取り消しルールが適用された場合、図１０ａのどの送信が取り消されるかを示す。つまり、図１０ｄに示されるように、複数のＴＢの送信のうちの１つのリソースが通知されるリソースと重なる（より具体的には、ＴＢ＃１の第１の送信が、スロット＃４において通知されるリソースと重なる）ため、すべてのＴＢのすべての送信が取り消されると通知／決定される。
一般的に、複数のＴＢのリソースのいずれかが、ＣＩによって通知されるリソースと重なる場合、すべてのＴＢのすべての繰り返し送信が取り消されてよい。より具体的に、通知されるリソースが、複数のＴＢの送信のためにスケジュールされたリソースのいずれにも重ならない場合、マルチＴＢスケジューリングＤＣＩによってスケジュールされた送信はいずれも取り消されないと決定されてよい。さらに、通知されるリソースが、Ｎ個のＴＢの送信のためにスケジュールされたリソースのいずれか（例えば、少なくとも一つ）に重なる場合、マルチＴＢスケジューリングＤＣＩによってスケジュールされた送信／繰り返し送信はすべて取り消されると決定されてよい。つまり、第４の取り消しルールによると、複数のＴＢの送信はすべて取り消されるか、いずれも取り消されないかのどちらかであってよい。
第４の取り消しルールは、マルチＴＢスケジューリングＤＣＩによってスケジュールされたすべてのＴＢのすべての送信を取り消すことができ、仕様上の影響が少ない可能性がある。加えて、すべてのＴＢのすべての送信を取り消すことは、高優先度の他のトラフィックのより良い保護につながる。特に、第４の取り消しルールは、１つのＤＣＩでマルチＴＢスケジューリングＤＣＩによってスケジュールされた（残っている）送信をすべて取り消すことが可能であり、送信がすべて取り消されるか、いずれも取り消されないかのどちらかであるため、とりわけ単純であり得る。
＜取り消しルールの第５の例＞
いくつかの実施形態において、通知されるリソースと重なる、および／または通知されるリソースの後にスケジュールされた、Ｎ個のＴＢのためにスケジュールされた送信は取り消されると決定される。
いくつかの実施形態において、通知されるリソースと重なる、および／または通知されるリソースの後にスケジュールされた、Ｎ個のＴＢのためにスケジュールされた送信は取り消されると決定される。
図１１ｃは、第５の取り消しルールが適用された場合、図１１ａのどの送信が取り消されるかを示す。つまり、図１１ｃに示されるように、通知されるリソースが、ＴＢ＃１の第２の送信（スロット＃５のＲＶ２）と重なるため、ＴＢ＃１の当該第２の送信は取り消される。さらに、通知されるリソース（スロット＃５）の後であるという理由から、ＴＢ＃１の第３の送信（スロット＃６のＲＶ３）、ＴＢ＃１の第４の送信（スロット＃７のＲＶ１）、およびＴＢ＃２の４つの送信のすべて（スロット＃９から＃１２）も取り消される。
一般的に、特定のＴＢ（複数可）の繰り返し送信のいずれかがＣＩによって通知されるリソースと重なる場合、その（それらの）ＴＢの繰り返し送信は通知されるリソース以降すべて取り消されてよい。これは、ＴＢの繰り返し送信が特定のインターリーブパターン（例えば、上述したＲＶ優先パターン）を利用する場合にも適用できる。
より具体的には、通知されるリソースより前の、マルチＴＢスケジューリングＤＣＩによってスケジュールされた送信はいずれも取り消されないと決定されてよい。さらに、送信のリソースが通知されるリソースと重なる場合、その送信は取り消されると決定されてよい。
また、送信のリソースが通知されるリソースと重なる場合、通知されるリソースの後の、マルチＴＢスケジューリングＤＣＩによってスケジュールされた送信はすべて取り消されると決定されてよい。しかしながら、第５の取り消しルールのいくつかの実装においては、通知されるリソースの後の、マルチＴＢスケジューリングＤＣＩによってスケジュールされた送信はすべて取り消される。つまり、たとえ通知されるリソースが、マルチＴＢスケジューリングＤＣＩによってスケジュールされた送信の少なくとも一つのリソースと重ならないとしても（例えば、通知されるリソースが、ＴＢの２つの送信の間の送信ギャップに該当する場合）、通知されるリソースの後の送信は取り消されてよい。
第５の取り消しルールは、マルチＴＢスケジューリングＤＣＩによってスケジュールされたＴＢの送信の一部またはすべてを取り消すことができ、仕様上の影響が少ない可能性がある。加えて、スケジュールされたＴＢのパフォーマンスと、他の高優先度のトラフィックへの影響とのトレードオフを実現できる。さらに、第５の取り消しルールは、各ＴＢの送信を適当な回数（自由に選択可能）取り消さない柔軟性を確保する。特に、上述のＲＶ優先パターンを使用する場合、各ＴＢを十分な信頼性で復号するために、Ｎ個のＴＢのそれぞれの送受信回数を確保でき得る。
＜ＴＢ優先度を使用する取り消しルール＞
一般的に、複数の優先度（優先度レベル）がサポートされ得る。ＴＢの優先度（優先度レベル）は、当該ＴＢの送受信の重要性を示してよい。具体的に、ＴＢのすべての送信は同じ優先度を有してよい。したがって、本開示では、ＴＢの送信の優先度は、当該ＴＢの優先度を示して（または、優先度であって）よい。
一般的に、複数の優先度（優先度レベル）がサポートされ得る。ＴＢの優先度（優先度レベル）は、当該ＴＢの送受信の重要性を示してよい。具体的に、ＴＢのすべての送信は同じ優先度を有してよい。したがって、本開示では、ＴＢの送信の優先度は、当該ＴＢの優先度を示して（または、優先度であって）よい。
つまり、優先度レベルが高いほど、そのＴＢの送受信は重要である。例えば、優先度は、ＴＢの送受信がどれだけタイムクリティカルであるか、および／または、信頼性に関する要件がどの程度であるかを示してよい。それに応じて、ＴＢの優先度は、当該ＴＢに関連するサービスのＱＯＳ要件に関連し得る。なお、ＴＢのすべての送信は同じ優先度を有してよい。また、送信の優先度は、当該送信によって送信された（または送信される）ＴＢの優先度であってよい。異なる優先度レベルを用いることで、特に上述したような取り消しルールの組み合わせにおいて、より効果的に限られたリソースを使用することができる。換言すると、特定の、重要度が低くそれほどタイムクリティカルでないＴＢを選択的に取り消すことができる。
一般的に、ＴＢ優先度が使用される場合、ＵＬ ＣＩは、低優先度レベル（例えば、特定の／閾値優先度レベルより下）と通知／設定されたＵＬ送信のみに適用されてよい。つまり、閾値優先度レベル以上の送信はいずれも取り消されないと決定されてよい。また、当該閾値優先度を下回る送信はすべて、さらなる検討なしに取り消されると決定されてよい。つまり、低優先度の送信は常にすべて取り消される。しかしながら、本発明はこれに限定されない。例えば、そのような低優先度の送信のうち、ある条件を満たす送信のみが取り消されると決定されてよい。例えば、第１から第５の取り消しルールの一つが、どの低優先度の送信が取り消されるかを決定するために適用されてよい。
以下では、スケジュールされた複数のＴＢ（の一部またはすべて）の取り消しのための所定／取り消しルールを２つ例示する。これらのルールは、上述のように、スケジュールされたＴＢの優先度に基づくルールの一例である。具体的に、第６の取り消しルールは第１の取り消しルールを適用するが、低優先度のＴＢのみに適用され、高優先度のＴＢの送信はいずれも取り消されない。第７の取り消しルールは第３の取り消しルールを適用するが、低優先度のＴＢのみに適用され、高優先度のＴＢの送信はいずれも取り消されない。
＜取り消しルールの第６の例＞
いくつかの実施形態において、ＴＢのためにスケジュールされた各送信に対して、ｉ）通知されたリソースが当該送信のリソースのいずれかと重なる場合、かつｉｉ）当該送信によって送信されるＴＢの優先度が所定の閾値（本開示では閾値レベルとも呼ばれる）を下回る場合、当該送信は取り消されると決定される。
いくつかの実施形態において、ＴＢのためにスケジュールされた各送信に対して、ｉ）通知されたリソースが当該送信のリソースのいずれかと重なる場合、かつｉｉ）当該送信によって送信されるＴＢの優先度が所定の閾値（本開示では閾値レベルとも呼ばれる）を下回る場合、当該送信は取り消されると決定される。
一般的に、第６の取り消しルールによると、ＵＬ ＣＩは、低優先度レベルと通知／設定されたＵＬ送信のみに適用される。より具体的には、閾値レベルより下の優先度を有し、ＣＩによって通知されるリソースと重なるＴＢの繰り返し送信のみが取り消される。
換言すると、スケジュールされた各送信に対して、当該送信のリソースがいずれも通知されるリソースと重ならない場合、当該送信は取り消されないと決定されてよい。また、スケジュールされた各送信に対して、当該送信の優先度レベルが閾値レベルより下でない場合、当該送信は取り消されないと決定されてよい。さらに、スケジュールされた各送信に対して、当該送信の優先度が当該閾値レベルを下回り、当該送信のリソースが通知されるリソースと重なる場合、当該送信は取り消されると決定されてよい。すなわち、両方の条件（重複と低優先度）が満たされた場合に限り、送信は取り消される。
第６の取り消しルールは、低優先度の特定／単一の送信を幾分柔軟に取り消すことができ、仕様上の影響が少ない可能性がある。ＴＢの送信をできるだけ残すことで、送信のパフォーマンスに与える影響を少なくすることができる。特に、第６の取り消しルールは、低優先度のＴＢの個々の送信を選択的に取り消すことを可能にし得る。
なお、第６の取り消しルールは、ＴＢの繰り返し送信が特定のインターリーブパターン（例えば、上述した実施形態におけるＲＶ優先パターン）を利用する場合にも適用できる。
＜取り消しルールの第７の例＞
いくつかの実施形態において、複数のＴＢのそれぞれに対して、通知されるリソースが、当該ＴＢのためにスケジュールされた１つまたは複数の送信のリソースのいずれかと重なる場合、かつ当該ＴＢの優先度が所定の閾値（本開示では閾値レベルとも呼ばれる）を下回る場合、その１つまたは複数のスケジュールされた送信はすべて取り消されると決定される。
いくつかの実施形態において、複数のＴＢのそれぞれに対して、通知されるリソースが、当該ＴＢのためにスケジュールされた１つまたは複数の送信のリソースのいずれかと重なる場合、かつ当該ＴＢの優先度が所定の閾値（本開示では閾値レベルとも呼ばれる）を下回る場合、その１つまたは複数のスケジュールされた送信はすべて取り消されると決定される。
一般的に、第７の取り消しルールによると、ＵＬ ＣＩは、低優先度レベルと通知／設定されたＵＬ送信のみに適用される。より具体的には、閾値レベルより下の優先度を有する特定のＴＢ（複数可）の繰り返し送信のいずれかが、ＣＩによって通知されるリソースと重なる場合、その（それらの）ＴＢの繰り返し送信はすべて取り消される。
換言すると、各ＴＢに対して、通知されるリソースが、当該ＴＢの送信のためにスケジュールされたリソースのいずれにも重ならない場合、当該ＴＢのためにスケジュールされた（１つまたは複数の）送信はいずれも取り消されないと決定されてよい。また、各ＴＢに対して、当該ＴＢの優先度が閾値レベルより下でない場合、当該ＴＢのためにスケジュールされた送信はいずれも取り消されないと決定されてよい。さらに、各ＴＢに対して、当該ＴＢの優先度が閾値レベルを下回り、通知されるリソースが当該ＴＢの送信のためにスケジュールされたリソースのうちの１つ（例えば、任意のリソース、または少なくとも一つのリソース）と重なる場合、当該ＴＢの送信はすべて取り消されると決定されてよい。すなわち、両方の条件（重複と低優先度）が満たされた場合に限り、ＴＢの送信はすべて取り消される。特に、ＴＢの送信はすべて取り消されるか、いずれも取り消されないかのどちらかであってよい。
第７の取り消しルールは特定の／選択された低優先度のＴＢの送信をすべて取り消すことができ、仕様上の影響が少ない可能性がある。加えて、ＴＢの送信をすべて取り消すことは、高優先度の他のトラフィックのより良い保護につながる。
＜優先度の通知と優先度の決定＞
以下では、マルチＴＢスケジューリングＤＣＩによってスケジュールされた複数のＴＢのそれぞれの優先度を通知および／または決定するための手法を例示する。
以下では、マルチＴＢスケジューリングＤＣＩによってスケジュールされた複数のＴＢのそれぞれの優先度を通知および／または決定するための手法を例示する。
＜暗黙的な優先度通知＞
いくつかの実施形態において、マルチＴＢスケジューリングＤＣＩによってスケジュールされたＴＢのそれぞれに対して、当該ＴＢの優先度は時間間隔と閾値との比較に応じて決定される。
いくつかの実施形態において、マルチＴＢスケジューリングＤＣＩによってスケジュールされたＴＢのそれぞれに対して、当該ＴＢの優先度は時間間隔と閾値との比較に応じて決定される。
一般的に、マルチＴＢスケジューリングＤＣＩによってスケジュールされた各ＴＢの優先度は、１つまたは複数の閾値、および／または当該ＴＢの送信のために割り当てられた時間領域のリソースに基づいて決定されてよい。
一般的に、そのような閾値は（例えば、規格で定義された）デフォルトの値でもよいし、無線リソース制御（ＲＲＣ）シグナリングによって通知されてもよい。閾値は一つであっても（特に、サポートされる優先度が２つの場合）複数であっても（例えば、サポートされる優先度の数より１つ少ない数）であってもよい。閾値は、マルチＴＢスケジューリングＤＣＩによってスケジュールされたＴＢの優先度を決定（ＵＥ）／通知（基地局）するために使用されてよい。一般的に、閾値はスロット数Ｂであり得る。この数Ｂは、非負整数であってよい。
また、閾値は、異なる優先度のＴＢ間の（時間領域における）境界に対応してよい。換言すると、閾値は、Ｎ個のＴＢの優先度を通知／決定するために使用され得る境界を定義／通知してよい。このような境界は、例えば、ＤＣＩスロットのＢスロット後のスロットと、ＤＣＩスロットのＢ＋１スロット後のスロットとの間にあってよい。なお、本開示において、「ＤＣＩスロット」という用語は、マルチＴＢスケジューリングＤＣＩが受信／送信されるスロットを指す。例えば、図１２ａでは、低優先度のＴＢと高優先度のＴＢを分ける境界／閾値が１つ存在している。当該境界はスロット＃３とスロット＃４の間、すなわち、ＤＣＩスロット（スロット＃１）の２スロット後に置かれている。つまり、図１２ａにおいてＢは２であってよい。また、図１２ｂでは、低優先度のＴＢと高優先度のＴＢを分ける境界／閾値が１つ存在している。当該境界はスロット＃４とスロット＃５の間、すなわち、ＤＣＩスロット（スロット＃１）の３スロット後に置かれている。つまり、図１２ｂにおいてＢは３であってよい。
しかしながら、数Ｂは必ずしもＤＣＩスロットから見た境界を定義／通知するわけではない。例えば、境界はＮ個のＴＢの第１の送信スロットのＢスロット後のスロットと、Ｎ個のＴＢの第１の送信スロットのＢ＋１スロット後のスロットとの間にあってもよい。
なお、スロットの数Ｂ（つまり境界）は、数Ｔに関連して付与／通知されてもよい。ここで、Ｔとは、Ｎ個のＴＢのうち、特定の優先度を有するＴＢの数を示す非負整数であってよい。つまり、境界は、Ｎ個のＴＢの送信のうちＴ番目の送信が行われるスロットと、それに続くスロットとの間であってよい。換言すると、境界は、その後にＮ個のＴＢのうち少なくともＴ個の異なるＴＢの送信がスケジュールされている最初のスロットの直後であってよい。例えば、図１２ａにおいてＴは３であり、図１２ｂにおいてＴは２であってよい。
各閾値／境界に対して、スロットの数Ｂおよび／またはＴＢの数Ｔは、例えばＲＲＣで通知されても、（例えば、関連する規格により付与される）デフォルトの値でもよい。
なお、境界が特定の優先度のＴＢの数に関連して与えられる場合、境界はＮ個のＴＢのスケジュールされた送信に依存してよい。すなわち、ＵＥは、ＴＢの数Ｔと、例えば、スケジュールされた送信の時間領域のリソースとに基づいて境界を決定してよい。一方、境界がスロットの数に関連して与えられる場合、境界はスケジュールされた送信に依存しなくてよい。
上述のように、Ｎ個のＴＢのそれぞれに対して、当該ＴＢの優先度は、時間間隔と閾値との比較に応じて（例えば、基づいて）決定されてよい。例えば、時間間隔とは、マルチＴＢスケジューリングＤＣＩと、当該ＴＢの１つまたは複数のスケジュールされた送信の中の第１の送信との間の（例えば、スロットの観点における）時間間隔であってよい。一般的に、このような比較では、当該ＴＢの第１の送信が、閾値に相当する境界の前にあるか後にあるかを決定してよい。
サポートされる優先度が２つ（例えば、「低優先度」と「高優先度」）のみの場合、それらの優先度は、１つの境界／閾値に基づいて、低優先度ＴＢと高優先度ＴＢに分けることができる。この場合、境界の前に第１の送信がスケジュールされているＴＢは高優先度ＴＢとなり、境界の後に第１の送信がスケジュールされているＴＢは低優先度ＴＢとなってよい。一般的に、マルチＴＢスケジューリングＤＣＩに近いＴＢほど優先度が高くなってよい。つまり、第１の境界の前にスケジュールされた送信を少なくとも一つ有するＴＢが、Ｎ個のＴＢのうちで最も高い優先度を有するＴＢであり得る。換言すると、第１の境界の前に第１の送信がある送信の優先度が最も高い。第２の境界が定義されている場合、ｉ）第１の境界の前に送信がなく、ｉｉ）第１と第２の境界の間に少なくとも一つの送信がある送信が、２番目に高い優先度を有するＴＢであり得る。換言すると、第１と第２の境界の間の第１の送信がある送信が２番目に高い優先度を有するＴＢであり得る。これに伴い、最後の境界の後に第１の送信がある送信が最も低い優先度であり得る。
マルチＴＢスケジューリングＤＣＩによってスケジュールされたＴＢの優先度を、境界を用いて暗黙的に通知することで、オーバーヘッドが低減され得る。また、遅延にクリティカルなトラフィックが、それほどクリティカルでない他のトラフィックより早くスケジュールされることにより保護される。
＜明示的な優先度通知＞
一般的に、Ｎ個のＴＢの優先度は明示的に通知されてもよい。
一般的に、Ｎ個のＴＢの優先度は明示的に通知されてもよい。
例えば、いくつかの実施形態において、ＵＥ（例えば、ＵＥの送受信機）は、動作時に、優先度通知を含むＤＣＩシグナリング（これはマルチＴＢスケジューリングＤＣＩと同じＤＣＩでも異なるＤＣＩでもよい）を受信する。優先度通知は、マルチＴＢスケジューリングＤＣＩによってスケジュールされた複数のＴＢのそれぞれに対して、当該ＴＢの優先度を通知してよい。そして、ＵＥの回路は、動作時に、当該ＤＣＩシグナリングから、当該通知を受信してよい。また、ＵＥの回路は、マルチＴＢスケジューリングＤＣＩによってスケジュールされた複数のＴＢのそれぞれに対して、優先度通知に基づいて、ＴＢの優先度を決定してよい。
一般的に、ＴＢの優先度は、１つまたは複数の組み合わせが（例えば、ＲＲＣシグナリングを通じて）設定されてよい。ここで、ＴＢの優先度の組み合わせは、Ｎ個のＴＢのそれぞれに対して、当該ＴＢの優先度を特定／通知してよい。また、各組み合わせは、インデックス（またはインデックスの値）と、例えば一対一の対応関係で関連付けられてもよい。複数のインデックス（または組み合わせ）が設定される場合、ＵＥは、複数の設定エントリから１つを選択するＤＣＩシグナリングによってＮ個のＴＢの優先度を決定してよい。換言すると、ＵＥは、設定された複数の組み合わせの中から１つの組み合わせを選択／決定してよい。
具体的に、優先度通知は、Ｎ個のＴＢのうちの複数（またはすべて）のＴＢの優先度を統合的に通知してよい。例えば、優先度通知はインデックスを通知し得る。優先度通知またはインデックスは、テーブルのエントリ（例えば、行または列）を通知してよい。一般的に、Ｎ個のＴＢの優先度の異なる／特定の組み合わせが、異なるインデックスの値で設定（または通知）される。すなわち、インデックスは、Ｎ個のＴＢのそれぞれに対して、当該ＴＢの優先度を通知し得る。各インデックス（またはインデックスの各値）に対して、当該インデックスが通知するＮ個のＴＢの優先度の組み合わせは、例えば、ＲＲＣでシグナリングされてもよいし、（例えば、適用可能な規格において）定義されていてもよい。
下記のテーブルを参照してさらに説明する。
見てわかるように、上記テーブルの各行はインデックス（例えば、インデックス値）に対応しており、ＴＢの優先度の特定の組み合わせを指定している。換言すると、上記テーブルの各行はＴＢの優先度の１つの組み合わせに対応している。
より具体的には、上記例において、「インデックス１」は、第１と第２のＴＢの優先度が高いことを通知するよう構成されている。上記テーブルが設定され、優先度通知によって「インデックス１」が通知された場合の優先度の割り当ては、図１３ａにも示される。また、「インデックス２」は、第１のＴＢの優先度が高く、第２のＴＢの優先度が低いことを通知するよう構成されている。上記テーブルが設定され、優先度通知によって「インデックス２」が通知された場合の優先度の割り当ては、図１３ｂにも示される。
ここで、複数のＴＢは、それらの第１にスケジュールされた送信に応じて順序付けられてよい。つまり、第１のＴＢの第１の送信は第２のＴＢの第１の送信（およびすべての他の送信）の前であってよく、第２のＴＢの第１の送信は第３のＴＢの第１の送信の前であってよく、その後も同様である（Ｎ番目のＴＢの第１の送信はＮ個のＴＢの送信の中の最後の送信であってよい）。
ＤＣＩシグナリングによる明示的なシグナリングを使用することで、ＴＢの優先度の組み合わせを任意にシグナリングでき得るため、非常に柔軟にＮ個のＴＢの優先度を通知することが容易になると考えられる。
なお、本開示の実施形態は、比較的長い往復時間（ＲＴＴ：Ｒｏｕｎｄ Ｔｒｉｐ Ｔｉｍｅ）のシナリオ、例えば、ＨＡＲＱプロセスＩＤの数がＲＴＴと比較して少ない、すなわち、
ｓｌｏｔ＿ｌｅｎｇｔｈ×「ＨＡＲＱプロセスＩＤの数」＜ＲＴＴ
である、５２．６ＧＨｚを超える非地上系ネットワーク（ＮＴＮ）にも適用可能で有益であり、その理由は、１つのＤＣＩが単一のＨＡＲＱプロセスＩＤで複数のスロットをスケジューリングできるためである。
ｓｌｏｔ＿ｌｅｎｇｔｈ×「ＨＡＲＱプロセスＩＤの数」＜ＲＴＴ
である、５２．６ＧＨｚを超える非地上系ネットワーク（ＮＴＮ）にも適用可能で有益であり、その理由は、１つのＤＣＩが単一のＨＡＲＱプロセスＩＤで複数のスロットをスケジューリングできるためである。
＜本開示のハードウェアおよびソフトウェアの実装＞
本開示は、ソフトウェア、ハードウェア又はハードウェアと連動するソフトウェアによって実現することができる。上述した各実施例の説明に用いた各機能ブロックは、集積回路（ＩＣ）等のＬＳＩ（Ｌａｒｇｅ Ｓｃａｌｅ Ｉｎｔｅｇｒａｔｉｏｎ）によって部分的又は全体的に実現可能であり、各実施例で説明される各処理は、同一のＬＳＩ又はＬＳＩの組み合わせによって部分的又は全体的に制御されてもよい。ＬＳＩは、個別にチップとして形成されていてもよいし、あるいは、機能ブロックの一部又は全部を含むように１つのチップが形成されていてもよい。ＬＳＩは、それに結合されたデータ入出力を含んでもよい。ここで、ＬＳＩとは、集積度の違いにより、ＩＣ、システムＬＳＩ、スーパーＬＳＩ又はウルトラＬＳＩとして呼ばれうる。しかし、集積回路を実現する技術はＬＳＩに限定されず、専用回路、汎用プロセッサ又は特定用途向けプロセッサを用いて実現されてもよい。さらに、ＬＳＩ内部に配置される回路セルの接続及び設定が再設定可能なＬＳＩ又はリコンフィギュラブルプロセッサの製造後にプログラミング可能なＦＰＧＡ（Ｆｉｅｌｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ）が利用されてもよい。本開示は、デジタル処理又はアナログ処理として実現することができる。半導体技術や他の派生技術の進歩の結果として、将来の集積回路技術がＬＳＩに取って代わる場合、機能ブロックは、将来の集積回路技術を用いて集積化することができる。バイオテクノロジーも適用できる。
本開示は、ソフトウェア、ハードウェア又はハードウェアと連動するソフトウェアによって実現することができる。上述した各実施例の説明に用いた各機能ブロックは、集積回路（ＩＣ）等のＬＳＩ（Ｌａｒｇｅ Ｓｃａｌｅ Ｉｎｔｅｇｒａｔｉｏｎ）によって部分的又は全体的に実現可能であり、各実施例で説明される各処理は、同一のＬＳＩ又はＬＳＩの組み合わせによって部分的又は全体的に制御されてもよい。ＬＳＩは、個別にチップとして形成されていてもよいし、あるいは、機能ブロックの一部又は全部を含むように１つのチップが形成されていてもよい。ＬＳＩは、それに結合されたデータ入出力を含んでもよい。ここで、ＬＳＩとは、集積度の違いにより、ＩＣ、システムＬＳＩ、スーパーＬＳＩ又はウルトラＬＳＩとして呼ばれうる。しかし、集積回路を実現する技術はＬＳＩに限定されず、専用回路、汎用プロセッサ又は特定用途向けプロセッサを用いて実現されてもよい。さらに、ＬＳＩ内部に配置される回路セルの接続及び設定が再設定可能なＬＳＩ又はリコンフィギュラブルプロセッサの製造後にプログラミング可能なＦＰＧＡ（Ｆｉｅｌｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ）が利用されてもよい。本開示は、デジタル処理又はアナログ処理として実現することができる。半導体技術や他の派生技術の進歩の結果として、将来の集積回路技術がＬＳＩに取って代わる場合、機能ブロックは、将来の集積回路技術を用いて集積化することができる。バイオテクノロジーも適用できる。
本開示は、通信装置と呼ばれる、通信機能を有する何れかのタイプの装置、デバイス又はシステムによって実現することができる。
通信装置は、送受信機及び処理／制御回路を有してもよい。送受信機は、受信機及び送信機を有し、及び／又は機能してもよい。送信機及び受信機としての送受信機は、増幅器、ＲＦ変調器／復調器など及び１つ以上のアンテナを含むＲＦ（Ｒａｄｉｏ Ｆｒｅｑｕｅｎｃｙ）モジュールを含んでもよい。
そのような通信装置のいくつかの非限定的な例は、電話機（例えば、携帯（セル）電話、スマートフォン）、タブレット、パーソナルコンピュータ（ＰＣ）（例えば、ラップトップ、デスクトップ、ネットブック）、カメラ（例えば、デジタルスチル／ビデオカメラ）、デジタルプレーヤ（デジタルオーディオ／ビデオプレーヤ）、ウェアラブルデバイス（例えば、ウェアラブルカメラ、スマートウォッチ、トラッキングデバイス）、ゲームコンソール、デジタルブックリーダ、遠隔ヘルス／遠隔医療（リモートヘルス及びリモート医療）デバイス、及び通信機能を提供する車両（例えば、自動車、飛行機、船舶）、並びにそれらの様々な組み合わせを含む。
通信装置は、携帯型又は可動型であることに限定されず、スマートホームデバイス（例えば、家電、ライティング、スマートメータ、制御パネル）、自動販売機及び“Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ（ＩｏＴ）”のネットワークにおける他の何れかの“物”など、非携帯型又は固定型である何れかのタイプの装置、デバイス又はシステムを含んでもよい。
通信は、例えば、セルラシステム、無線ＬＡＮシステム、衛星システムなど、及びそれらの様々な組み合わせを介してデータを交換することを含んでもよい。
通信装置は、本開示に記載された通信の機能を実行する通信デバイスに結合されたコントローラ又はセンサなどのデバイスを含んでもよい。例えば、通信装置は、通信装置の通信機能を実行する通信デバイスによって使用される制御信号又はデータ信号を生成するコントローラ又はセンサを含んでもよい。
通信装置はまた、基地局、アクセスポイントなどのインフラストラクチャファシリティと、上記の非限定的な例におけるものなどの装置と通信又は制御する他の何れかの装置、デバイス又はシステムを含んでもよい。
さらに、様々な実施形態はまた、プロセッサにより実行されるソフトウェアモジュールを用いて、またはハードウェアで直接、実施され得る。また、ソフトウェアモジュールとハードウェア実装との組み合わせも可能であり得る。ソフトウェアモジュールは、任意の種類のコンピュータ可読記憶媒体に記憶され得る。具体的には、他の実装によれば、非一時的コンピュータ可読記録媒体が提供される。記録媒体は、１つまたは複数のプロセッサによって実行された場合に、１つまたは複数のプロセッサに本開示による方法のステップを実行させるプログラムを記憶する。
一例として、限定的ではなく、そのようなコンピュータ可読記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、ＣＤ－ＲＯＭもしくは他の光ディスクストレージ、磁気ディスクストレージ、または他の磁気ストレージデバイス、フラッシュメモリ、あるいは指示またはデータ構造の形態で所望のプログラムコードを記憶するために使用することができ、コンピュータによりアクセスすることができる他の任意の媒体を含むことができる。また、任意の接続を適正にコンピュータ可読媒体と呼ぶ。例えば、ウェブサイト、サーバ、または他のリモートソースから、同軸ケーブル、光ファイバケーブル、ツイストペア、デジタル加入者線（ＤＳＬ：ｄｉｇｉｔａｌ ｓｕｂｓｃｒｉｂｅｒ ｌｉｎｅ）、または赤外線、無線、およびマイクロ波などのワイヤレス技術を使用して指示が送信される場合、同軸ケーブル、光ファイバケーブル、ツイストペア、ＤＳＬ、または赤外線、無線、およびマイクロ波などのワイヤレス技術は、媒体の定義に含まれる。しかしながら、コンピュータ可読記憶媒体およびデータ記憶媒体は、接続、搬送波、信号、または他の一時的な媒体を含まず、代わりに非一時的有形記憶媒体を対象とすることを理解されたい。本明細書で使用するディスク（ｄｉｓｋ）およびディスク（ｄｉｓｃ）は、本明細書で使用する場合、コンパクトディスク（ＣＤ：ｃｏｍｐａｃｔ ｄｉｓｃ）、レーザーディスク、光ディスク、デジタルバーサタイルディスク（ＤＶＤ：ｄｉｇｉｔａｌ ｖｅｒｓａｔｉｌｅ ｄｉｓｃ）、フロッピーディスク、およびブルーレイディスクを含み、ディスク（ｄｉｓｋ）は通常磁気的にデータを再生するが、ディスク（ｄｉｓｃ）はレーザーを使用して光学的にデータを再生する。上記の組み合わせも、コンピュータ可読媒体の範囲内に含まれるべきである。
なお、異なる実施形態の個々の特徴は、個々にまたは任意の組み合わせで、他の実施形態の主題となり得る。特定の実施形態に示したように、本開示に対して多数の変形および／または修正がなされ得ることは当業者によって理解されよう。そのため、本実施形態は、全ての点で例示的であって限定的ではないと考えられるべきである。
＜さらなる態様＞
第１の態様によれば、ＵＥが提供される。前記ＵＥは、送受信機および回路を備える。前記送受信機は、動作時に、ＤＣＩシグナリングと制御情報を受信する。前記回路は、動作時に、前記ＤＣＩシグナリングからスケジューリング通知を取得する。前記スケジューリング通知は、複数のＴＢの各ＴＢに対して、前記各ＴＢの１つ以上の送信のスケジューリングを通知する。また、前記回路は、動作時に、前記制御情報からリソースを通知する取り消し通知（ＣＩ）を取得する。さらに、前記回路は、動作時に、前記通知されたリソースと所定のルールとに基づいて、前記複数のＴＢのスケジュールされた送信のうちどの送信が取り消されるかを決定する。
第１の態様によれば、ＵＥが提供される。前記ＵＥは、送受信機および回路を備える。前記送受信機は、動作時に、ＤＣＩシグナリングと制御情報を受信する。前記回路は、動作時に、前記ＤＣＩシグナリングからスケジューリング通知を取得する。前記スケジューリング通知は、複数のＴＢの各ＴＢに対して、前記各ＴＢの１つ以上の送信のスケジューリングを通知する。また、前記回路は、動作時に、前記制御情報からリソースを通知する取り消し通知（ＣＩ）を取得する。さらに、前記回路は、動作時に、前記通知されたリソースと所定のルールとに基づいて、前記複数のＴＢのスケジュールされた送信のうちどの送信が取り消されるかを決定する。
第１の態様に加えて提供される第２の態様によれば、前記決定は、前記複数のＴＢのためにスケジュールされた送信の各送信に対して、前記通知されたリソースが前記各送信のリソースのいずれかと重なる場合、前記各送信の取り消しを決定することを含む。
第１または第２の態様に加えて提供される第３の態様によれば、前記決定は、前記複数のＴＢの各ＴＢに対して、前記通知されたリソースが前記各ＴＢのためにスケジュールされた１つ以上の送信のリソースのいずれかと重なる場合、前記各ＴＢのためにスケジュールされた１つ以上の送信のうち、前記通知されたリソースの後にスケジュールされた送信の取り消しを決定することを含む。
第１～第３の態様のうちの１つに加えて提供される第４の態様によれば、前記決定は、前記複数のＴＢの各ＴＢに対して、前記通知されたリソースが前記各ＴＢのためにスケジュールされた１つ以上の送信のリソースのいずれかと重なる場合、前記各ＴＢのためにスケジュールされた１つ以上の送信のすべての取り消しを決定することを含む。
第１～第４の態様のうちの１つに加えて提供される第５の態様によれば、前記決定は、前記通知されたリソースが前記複数のＴＢのためにスケジュールされた送信のうちのいずれかの送信のいずれかのリソースと重なる場合、前記複数のＴＢのためにスケジュールされた送信のすべての取り消しを決定することを含む。
第１～第５の態様のうちの１つに加えて提供される第６の態様によれば、前記決定は、前記通知されたリソースの後にスケジュールされた、前記複数のＴＢのためにスケジュールされた送信の取り消しを決定することを含む。
第１～第６の態様のうちの１つに加えて提供される第７の態様によれば、前記決定は、前記複数のＴＢのためにスケジュールされた送信の各送信に対して、前記通知されたリソースが前記各送信のリソースのいずれかと重なり、前記各送信によって送信されるＴＢの優先度が所定の閾値より低い場合、前記各送信の取り消しを決定することを含む。
第１～第７の態様のうちの１つに加えて提供される第８の態様によれば、前記決定は、前記複数のＴＢの各ＴＢに対して、前記通知されたリソースが前記各ＴＢのためにスケジュールされた１つ以上の送信のリソースのいずれかと重なり、前記各ＴＢの優先度が所定の閾値より低い場合、前記各ＴＢのスケジュールされた１つ以上の送信のすべての取り消しを決定することを含む。
第７または第８の態様に加えて提供される第９の態様によれば、前記回路は、動作時に、前記複数のＴＢの各ＴＢに対して、時間間隔と閾値との比較に応じて前記各ＴＢの優先度を決定する。ここで、前記時間間隔は、前記ＤＣＩシグナリングと、前記各ＴＢのスケジュールされた１つ以上の送信のうちの第１の送信との間の時間間隔であり、前記閾値はデフォルトの値、または無線リソース制御（ＲＲＣ）シグナリングによって通知される。
第７または第８の態様に加えて提供される第１０の態様によれば、前記送受信機は、動作時に、通知を含むＤＣＩシグナリングを受信する。前記通知は、前記複数のＴＢの各ＴＢに対して前記各ＴＢの優先度を通知する。前記回路は、動作時に、前記ＤＣＩシグナリングから、前記通知を取得する
第１１の態様によれば、スケジューリングデバイスが提供される。前記スケジューリングデバイスは、回路および送受信機を備える。前記回路は、動作時に、ＤＣＩシグナリングを生成する。前記ＤＣＩシグナリングは、複数のＴＢの各ＴＢに対して、前記各ＴＢの１つ以上の送信のスケジューリングを通知する通知を含む。また、前記回路は、動作時に、前記複数のＴＢのスケジュールされた送信のうちどの送信が取り消されるかを決定する。また、前記回路は、動作時に、所定のルールに基づいて、取り消されると決定した、スケジュールされた送信を示すリソースを決定する。さらに、前記回路は、動作時に、前記リソースを通知する取り消し通知（ＣＩ）を含む制御情報を生成する。前記送受信機は、動作時に、前記ＤＣＩシグナリングおよび前記制御情報を送信する。
第１１の態様によれば、スケジューリングデバイスが提供される。前記スケジューリングデバイスは、回路および送受信機を備える。前記回路は、動作時に、ＤＣＩシグナリングを生成する。前記ＤＣＩシグナリングは、複数のＴＢの各ＴＢに対して、前記各ＴＢの１つ以上の送信のスケジューリングを通知する通知を含む。また、前記回路は、動作時に、前記複数のＴＢのスケジュールされた送信のうちどの送信が取り消されるかを決定する。また、前記回路は、動作時に、所定のルールに基づいて、取り消されると決定した、スケジュールされた送信を示すリソースを決定する。さらに、前記回路は、動作時に、前記リソースを通知する取り消し通知（ＣＩ）を含む制御情報を生成する。前記送受信機は、動作時に、前記ＤＣＩシグナリングおよび前記制御情報を送信する。
第１２の態様によれば、ＵＥのための方法が提供される。前記方法は、ＤＣＩシグナリングを受信するステップと、前記ＤＣＩシグナリングから通知を取得するステップとを含む。前記通知は、複数のＴＢの各ＴＢに対して前記各ＴＢの１つ以上の送信のスケジューリングを通知する。前記方法はまた、制御情報を受信するステップと、前記制御情報から、リソースを通知する取り消し通知（ＣＩ）を取得するステップとを含む。前記方法はさらに、前記通知されたリソースと所定のルールとに基づいて、前記複数のＴＢのスケジュールされた送信のうちどの送信が取り消されるかを決定するステップを含む。
第１３の態様によれば、スケジューリングデバイスのための方法が提供される。前記方法は、通知を含むＤＣＩシグナリングを生成するステップと、前記ＤＣＩシグナリングを送信するステップとを含む。前記通知は、複数のＴＢの各ＴＢに対して前記各ＴＢの１つ以上の送信のスケジューリングを通知する。前記方法はまた、前記複数のＴＢのスケジュールされた送信のうちどの送信が取り消されるかを決定するステップと、所定のルールに基づいて、前記取り消されると決定されたスケジュールされた送信を示すリソースを決定するステップとを含む。前記方法はさらに、前記決定されたリソースを通知する取り消し通知（ＣＩ）を含む制御情報を生成するステップと、前記制御情報を送信するステップとを含む。
Claims (15)
- 動作時に、ダウンリンク制御情報（ＤＣＩ）シグナリングと、制御情報とを受信する送受信機と、
動作時に、
前記ＤＣＩシグナリングから、複数のトランスポートブロック（ＴＢ）の各ＴＢに対して前記各ＴＢの１つ以上の送信のスケジューリングを通知する通知を取得（Ｓ７４５）し、
前記制御情報から、リソースを通知する取り消し通知（ＣＩ）を取得し、
前記通知されたリソースと所定のルールとに基づいて、前記複数のＴＢのスケジュールされた送信のうちどの送信が取り消されるかを決定する回路と、
を備えるユーザ機器（ＵＥ）。 - 前記決定は、前記複数のＴＢのためにスケジュールされた送信の各送信に対して、前記通知されたリソースが前記各送信のリソースのいずれかと重なる場合、前記各送信の取り消しを決定することを含む、
請求項１に記載のユーザ機器（ＵＥ）。 - 前記決定は、前記複数のＴＢの各ＴＢに対して、前記通知されたリソースが前記各ＴＢのためにスケジュールされた１つ以上の送信のリソースのいずれかと重なる場合、前記各ＴＢのためにスケジュールされた１つ以上の送信のうち、前記通知されたリソースの後にスケジュールされた送信の取り消しを決定することを含む、
請求項１または２に記載のユーザ機器（ＵＥ）。 - 前記決定は、前記複数のＴＢの各ＴＢに対して、前記通知されたリソースが前記各ＴＢのためにスケジュールされた１つ以上の送信のリソースのいずれかと重なる場合、前記各ＴＢのためにスケジュールされた１つ以上の送信のすべての取り消しを決定することを含む、
請求項１から３のいずれか一項に記載のユーザ機器（ＵＥ）。 - 前記決定は、前記通知されたリソースが前記複数のＴＢのためにスケジュールされた送信のうちのいずれかの送信のいずれかのリソースと重なる場合、前記複数のＴＢのためにスケジュールされた送信のすべての取り消しを決定することを含む、
請求項１から４のいずれか一項に記載のユーザ機器（ＵＥ）。 - 前記決定は、前記通知されたリソースの後にスケジュールされた、前記複数のＴＢのためにスケジュールされた送信の取り消しを決定することを含む、
請求項１から５のいずれか一項に記載のユーザ機器（ＵＥ）。 - 前記決定は、前記複数のＴＢのためにスケジュールされた送信の各送信に対して、前記通知されたリソースが前記各送信のリソースのいずれかと重なり、前記各送信によって送信されるＴＢの優先度が所定の閾値より低い場合、前記各送信の取り消しを決定することを含む、
請求項１から６のいずれか一項に記載のユーザ機器（ＵＥ）。 - 前記決定は、前記複数のＴＢの各ＴＢに対して、前記通知されたリソースが前記各ＴＢのためにスケジュールされた１つ以上の送信のリソースのいずれかと重なり、前記各ＴＢの優先度が所定の閾値より低い場合、前記各ＴＢのスケジュールされた１つ以上の送信のすべての取り消しを決定することを含む、
請求項１から７のいずれか一項に記載のユーザ機器（ＵＥ）。 - 前記回路は、動作時に、前記複数のＴＢの各ＴＢに対して、時間間隔と閾値との比較に応じて前記各ＴＢの優先度を決定し、
前記時間間隔は、前記ＤＣＩシグナリングと、前記各ＴＢのスケジュールされた１つ以上の送信のうちの第１の送信との間の時間間隔であり、
前記閾値はデフォルトの値、または無線リソース制御（ＲＲＣ）シグナリングによって通知される、
請求項７または８に記載のユーザ機器（ＵＥ）。 - 前記送受信機は、動作時に、前記複数のＴＢの各ＴＢに対して前記各ＴＢの優先度を通知する通知を含むＤＣＩシグナリングを受信し、
前記回路は、動作時に、前記ＤＣＩシグナリングから、前記複数のＴＢの各ＴＢに対して前記各ＴＢの優先度を通知する前記通知を取得する、
請求項７または８に記載のユーザ機器（ＵＥ）。 - 動作時に、
複数のトランスポートブロック（ＴＢ）の各ＴＢに対して前記各ＴＢの１つ以上の送信のスケジューリングを通知する通知を含むダウンリンク制御情報（ＤＣＩ）シグナリングを生成し、
前記複数のＴＢのスケジュールされた送信のうちどの送信が取り消されるかを決定し、
所定のルールに基づいて、前記取り消されると決定されたスケジュールされた送信を示すリソースを決定し、
前記リソースを通知する取り消し通知（ＣＩ）を含む制御情報を生成する回路と、
動作時に、前記ＤＣＩシグナリングと前記制御情報とを送信する送受信機と、
を備えるスケジューリングデバイス。 - ダウンリンク制御情報（ＤＣＩ）シグナリングを受信するステップと、
前記ＤＣＩシグナリングから、複数のトランスポートブロック（ＴＢ）の各ＴＢに対して前記各ＴＢの１つ以上の送信のスケジューリングを通知する通知を取得するステップと、
制御情報を受信するステップと、
前記制御情報から、リソースを通知する取り消し通知（ＣＩ）を取得するステップと、
前記通知されたリソースと所定のルールとに基づいて、前記複数のＴＢのスケジュールされた送信のうちどの送信が取り消されるかを決定するステップと、
を含むユーザ機器（ＵＥ）のための方法。 - 複数のトランスポートブロック（ＴＢ）の各ＴＢに対して前記各ＴＢの１つ以上の送信のスケジューリングを通知する通知を含むダウンリンク制御情報（ＤＣＩ）シグナリングを生成するステップと、
前記ＤＣＩシグナリングを送信するステップと、
前記複数のＴＢのスケジュールされた送信のうちどの送信が取り消されるかを決定するステップと、
所定のルールに基づいて、前記取り消されると決定されたスケジュールされた送信を示すリソースを決定するステップと、
前記リソースを通知する取り消し通知（ＣＩ）を含む制御情報を生成するステップと、
前記制御情報を送信するステップと、
を含むスケジューリングデバイスのための方法。 - 動作時に、ユーザ機器（ＵＥ）の処理を制御する集積回路であって、
前記処理は、
ダウンリンク制御情報（ＤＣＩ）シグナリングを受信するステップと、
前記ＤＣＩシグナリングから、複数のトランスポートブロック（ＴＢ）の各ＴＢに対して前記各ＴＢの１つ以上の送信のスケジューリングを通知する通知を取得するステップと、
制御情報を受信するステップと、
前記制御情報から、リソースを通知する取り消し通知（ＣＩ）を取得するステップと、
前記通知されたリソースと所定のルールとに基づいて、前記複数のＴＢのスケジュールされた送信のうちどの送信が取り消されるかを決定するステップと、
を含む集積回路。 - 動作時に、スケジューリングデバイスの処理を制御する集積回路であって、
前記処理は、
複数のトランスポートブロック（ＴＢ）の各ＴＢに対して前記各ＴＢの１つ以上の送信のスケジューリングを通知する通知を含むダウンリンク制御情報（ＤＣＩ）シグナリングを生成するステップと、
前記ＤＣＩシグナリングを送信するステップと、
前記複数のＴＢのスケジュールされた送信のうちどの送信が取り消されるかを決定するステップと、
所定のルールに基づいて、前記取り消されると決定されたスケジュールされた送信を示すリソースを決定するステップと、
前記リソースを通知する取り消し通知（ＣＩ）を含む制御情報を生成するステップと、
前記制御情報を送信するステップと、
を含む集積回路。
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| EP20189045.6A EP3945745A1 (en) | 2020-07-31 | 2020-07-31 | User equipment, scheduling node, method for user equipment, and method for scheduling node |
| EP20189045.6 | 2020-07-31 | ||
| PCT/EP2021/071338 WO2022023497A1 (en) | 2020-07-31 | 2021-07-29 | User equipment, scheduling node, method for user equipment, and method for scheduling node |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2023535834A true JP2023535834A (ja) | 2023-08-21 |
Family
ID=71899670
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2023506323A Pending JP2023535834A (ja) | 2020-07-31 | 2021-07-29 | ユーザ機器、スケジューリングノード、ユーザ機器のための方法、およびスケジューリングノードのための方法 |
Country Status (5)
| Country | Link |
|---|---|
| US (1) | US20230269752A1 (ja) |
| EP (2) | EP3945745A1 (ja) |
| JP (1) | JP2023535834A (ja) |
| CN (1) | CN116058047A (ja) |
| WO (1) | WO2022023497A1 (ja) |
Families Citing this family (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111385889B (zh) * | 2018-12-29 | 2024-02-02 | 华为技术有限公司 | 用于侧行链路通信的方法、网络设备以及终端设备 |
| US20230269817A1 (en) * | 2022-02-18 | 2023-08-24 | Qualcomm Incorporated | Idle/inactive mode procedures for reduced capability user equipment |
| WO2023211716A1 (en) * | 2022-04-29 | 2023-11-02 | Qualcomm Incorporated | State changes associated with a configured grant transmission of a plurality of transport blocks |
| WO2023221029A1 (en) * | 2022-05-19 | 2023-11-23 | Huawei Technologies Co.,Ltd. | Systems and methods for a multi-link serving cell |
Family Cites Families (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US10873934B2 (en) * | 2017-09-28 | 2020-12-22 | Ofinno, Llc | Pre-emption indication in a wireless device |
| CN112514501A (zh) * | 2018-08-10 | 2021-03-16 | 苹果公司 | 用于多种服务类型的上行链路共存的下行链路控制信道信令 |
-
2020
- 2020-07-31 EP EP20189045.6A patent/EP3945745A1/en not_active Withdrawn
-
2021
- 2021-07-29 WO PCT/EP2021/071338 patent/WO2022023497A1/en active Application Filing
- 2021-07-29 CN CN202180058432.6A patent/CN116058047A/zh active Pending
- 2021-07-29 EP EP21751818.2A patent/EP4190093A1/en active Pending
- 2021-07-29 JP JP2023506323A patent/JP2023535834A/ja active Pending
- 2021-07-29 US US18/007,013 patent/US20230269752A1/en active Pending
Also Published As
| Publication number | Publication date |
|---|---|
| CN116058047A (zh) | 2023-05-02 |
| EP3945745A1 (en) | 2022-02-02 |
| EP4190093A1 (en) | 2023-06-07 |
| WO2022023497A1 (en) | 2022-02-03 |
| US20230269752A1 (en) | 2023-08-24 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP2023521109A (ja) | ページングに関与するユーザ機器および基地局 | |
| JP2023535834A (ja) | ユーザ機器、スケジューリングノード、ユーザ機器のための方法、およびスケジューリングノードのための方法 | |
| US20220132506A1 (en) | User equipment and scheduling device | |
| JP7459123B2 (ja) | 端末および通信方法 | |
| EP3940982A1 (en) | User equipment and base station | |
| US20220217758A1 (en) | Devices and methods for cross-slot scheduling adaption | |
| KR20220100591A (ko) | 사용자 장비 및 스케줄링 노드, 사용자 장비를 위한 방법 및 스케줄링 노드를 위한 방법 | |
| CN114667768A (zh) | 用户设备和调度节点 | |
| JP2023534473A (ja) | ユーザ機器、スケジューリングノード、ユーザ機器のための方法、およびスケジューリングノードのための方法 | |
| WO2021070508A1 (ja) | 基地局、端末、送信方法及び受信方法 | |
| JP2024519220A (ja) | ユーザ機器、スケジューリングノード、ユーザ機器のための方法、スケジューリングノードのための方法および集積回路 | |
| US20230269726A1 (en) | User equipment, scheduling node, method for user equipment, and method for scheduling node | |
| JP7492527B2 (ja) | 端末装置、通信方法及び集積回路 | |
| WO2023013217A1 (ja) | 基地局、端末及び通信方法 | |
| KR20230162608A (ko) | 통신 장치 및 통신 방법 | |
| KR20230162615A (ko) | 통신 장치 및 통신 방법 |