JP2023526459A - バッファ状態報告の強化 - Google Patents

Abstract

本開示は、通信ネットワークを通じてデータを送信および／または受信するための方法および装置（デバイス）に関する。特に、アップリンク制御情報が送信および／または受信され、このアップリンク制御情報は、ユーザ機器（ＵＥ）である通信デバイスにおける送信のために利用可能なデータと、前記送信のために利用可能なデータは応答確認が有効化されたデータおよび応答確認が無効化されたデータの両方を含むこととを示す。【選択図】図１６

Description

本開示は、通信システムにおける信号の送受信に関し、特に、そのような送受信のための方法および通信装置に関する。

３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ （３ＧＰＰ（登録商標））では、１００ＧＨｚまでの周波数範囲で動作する、第５世代（５Ｇ）とも呼ばれる次世代セルラ技術（Ｎｅｗ Ｒａｄｉｏ（ＮＲ）無線アクセス技術（ＲＡＴ：radio access technology）を含む）の技術仕様を策定している。ＮＲは、ＬＴＥ（Long Term Evolution）やＬＴＥ－Ａ（LTE Advanced）に代表される技術の後継である。

ＬＴＥ、ＬＴＥ－Ａ、およびＮＲなどのシステムに対するさらなる修正およびオプションが、その通信システムおよびそのシステムに付随する特定のデバイスの効率的な動作を促進することがある。

１つの非限定的な例示的実施形態は、アップリンクに対する効率的なリソース割当てを促進し、特に送信のために利用可能なデータの量の効率的なシグナリングを促進する。

ある実施形態において、本明細書に開示される技術は、動作中に、ユーザ機器（ＵＥ：ｕｓｅｒ ｅｑｕｉｐｍｅｎｔ）である通信デバイスにおける送信のために利用可能なデータを示し、かつ前記送信のために利用可能なデータは応答確認が有効化されたデータおよび応答確認が無効化されたデータの両方を含むことを示すアップリンク制御情報を生成する回路と、動作中に、生成されたアップリンク制御情報を送信するトランシーバとを含む通信デバイスを特徴とする。

なお、これらの包括的または具体的な態様は、システム、方法、集積回路、コンピュータプログラム、または、記録媒体で実現されてもよく、システム、装置、方法、集積回路、コンピュータプログラムおよび記録媒体の任意な組み合わせで実現されてもよい。

本開示の一実施例における更なる利点および効果は、明細書および図面から明らかにされる。かかる利点および／または効果は、いくつかの実施形態並びに明細書および図面に記載された特徴によってそれぞれ提供されるが、１つまたはそれ以上の同一の特徴を得るために必ずしも全てが提供される必要はない。

以下において、例示的な実施例は添付した図面を参照してより詳細に説明される。
３ＧＰＰ ＮＲシステムのアーキテクチャの一例を示す図 ＮＧ－ＲＡＮと５ＧＣとの間の機能分割を示す概略図 ＲＲＣ接続設定／再設定手順のためのシーケンス図 高速大容量（ｅＭＢＢ：enhanced Mobile Broadband）、多数同時接続（ｍＭＴＣ：massive Machine Type Communications）及び超高信頼低遅延（ＵＲＬＬＣ：Ultra Reliable and Low Latency Communications）の利用シナリオを示す概略図 非ローミングのための５Ｇシステムアーキテクチャの一例を示すブロック図 非地上系ネットワーク（ＮＴＮ：ｎｏｎ－ｔｅｒｒｅｓｔｒｉａｌ ｎｅｔｗｏｒｋ）のシナリオを示す図であり、ここでは衛星およびＮＴＮゲートウェイを含む遠隔無線ユニットを介して端末間の送信が行われる。 非地上系ネットワークのシナリオを示す図であり、ここではスケジューリングデバイスとしてのｇＮＢを含む衛星を介して端末間の送信が行われる。 例示的なショートバッファ状態報告フォーマットを示す図 例示的なロングバッファ状態報告フォーマットを示す図 互いに異なる応答確認設定を有する論理チャネルを含む論理チャネルグループの例を示す図 チャネルを通じて通信可能な例示的な基地局およびユーザ機器を示すブロック図 特定の応答確認送信設定を有するバッファ内のデータの占有率（share）をシグナリングする例示的なバッファ状態報告（ＢＳＲ：ｂｕｆｆｅｒ ｓｔａｔｕｓ ｒｅｐｏｒｔ）を示す図 特定の応答確認送信設定および優先順位を有するバッファ内のデータの占有率をシグナリングする例示的なバッファ状態報告（ＢＳＲ）を示す図 有効化された応答確認を有するデータおよび無効化された応答確認を有するデータの量をシグナリングする例示的なＢＳＲを示す図 ＵＥおよび基地局のそれぞれにおいてアップリンク制御情報を送信および受信するための方法を示す流れ図 ＵＥ側の動作を示す流れ図 ネットワーク側の動作を示す流れ図 設定グラントおよびランダムアクセス（ＲＡ：ｒａｎｄｏｍ ａｃｃｅｓｓ）オケージョンに関する例示的なＢＳＲトリガ時間を示す概略図 例示的なＢＳＲのトリガの後にＢＳＲを送信するためのＲＡ手順のトリガが続くところを示す概略図 ＢＳＲトリガ、ＲＡトリガ、およびＢＳＲの実際の送信の例示的なタイミングを示す概略図 ＢＳＲを伝達するために設定グラントリソースまたはＲＡオケージョンを選択する可能性を示す概略図

＜５Ｇ ＮＲシステムアーキテクチャ及びプロトコルスタック＞
３ＧＰＰは、１００ＧＨｚまでの周波数範囲で動作する新無線アクセス技術（ＮＲ）の開発を含む、第５世代セルラ技術（単純に５Ｇともいう）の次期リリースに取り組んでいる。２０１７年末に５Ｇ規格の初版が完成し、５Ｇ ＮＲ規格に準拠したスマートフォンの試行及び商用展開を進めることができた。

特に、全体的なシステムアーキテクチャは、ｇＮＢを備えるＮＧ－ＲＡＮ（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）データレートに対応することが求められる。一方、ＵＲＬＬＣでは、より厳しい要件が超低遅延（ユーザプレーンの遅延はＵＬ、ＤＬともに０．５ｍｓ）と高信頼性（１ｍｓ以内に１－１０^－５）について課されている。最後に、ｍＭＴＣには、好ましくは、高い接続密度（都市環境では１平方キロメートルあたり１００万台）、悪環境での広いカバレッジ、低コスト機器の超長寿命バッテリー（１５年）が求められる。

したがって、一つのユースケースに適したＯＦＤＭヌメロロジー（例えば、サブキャリア間隔、ＯＦＤＭシンボル長、巡回プレフィクス（ＣＰ）長、スケジューリング間隔あたりのシンボル数）は、他のユースケースには有効でない場合がある。例えば、低遅延サービスは、好ましくは、ｍＭＴＣサービスよりも短いシンボル長（したがって、より大きなサブキャリア間隔）および／またはスケジューリング区間（換言すると、ＴＴＩ）毎のシンボル数が少ないことが求められうる。さらに、チャネルの遅延スプレッドが大きい展開シナリオでは、好ましくは、遅延スプレッドが短いシナリオよりもＣＰ長が長いことが求められうる。同様のＣＰオーバーヘッドを維持するためには、サブキャリア間隔は適宜最適化される必要がある。ＮＲでは、複数の値のサブキャリア間隔をサポートしてもよい。これに対応して、現時点では１５ｋＨｚ、３０ｋＨｚ、６０ｋＨｚ、…、のサブキャリア間隔が検討されている。シンボル長Ｔ_ｕとサブキャリア間隔Δｆは、式Δｆ＝１／Ｔ_ｕによって直接関係づけられる。ＬＴＥシステムと同様、「リソースエレメント」という用語は、１つのＯＦＤＭ／ＳＣ－ＦＤＭＡシンボルの長さに対する一つのサブキャリアで構成される最小のリソース単位を示すのに使用することができる。

新たな無線システム５Ｇ－ＮＲにおいては、各ｎｕｍｅｒｏｌｏｇｙおよびキャリアに対して、アップリンクおよびダウンリンクのそれぞれに対してサブキャリアおよびＯＦＤＭシンボルのリソースグリッドが定義される。リソースグリッドの各エレメントはリソースエレメントと呼ばれ、周波数領域における周波数インデックスと、時間領域におけるシンボル位置とに基づいて識別される（３ＧＰＰ ＴＳ ３８．２１１ ｖ１５．６．０を参照）。

＜ＮＧ－ＲＡＮおよび５ＧＣの間の５Ｇ ＮＲ機能分割（functional split）＞
図２は、ＮＧ－ＲＡＮおよび５ＧＣの間の機能分割を示す。ＮＧ－ＲＡＮ論理ノードはｇＮＢまたはｎｇ－ｅＮＢ（次世代（ｎｅｘｔ ｇｅｎｅｒａｔｉｏｎ）ｅＮＢ）である。５ＧＣは論理ノードＡＭＦ、ＵＰＦ、およびＳＭＦを有する。

ｇＮＢ及びｎｇ－ｅＮＢは、具体的に、以下の主要な機能を提供する。
・無線ベアラ制御、無線アドミッション制御、接続モビリティ制御、上りリンクおよび下りリンクの双方におけるＵＥへの動的なリソース割り当て（スケジューリング）等の、無線リソース管理機能
・データのＩＰヘッダ圧縮、暗号化、及び完全性保護
・ＵＥから提供された情報からＡＭＦへのルーティングが決定できない場合のＵＥアタッチ時のＡＭＦ選択
・ＵＰＦに向けたユーザプレーンデータのルーティング
・ＡＭＦに向けた制御プレーン情報のルーティング
・接続の設定と解除
・ページングメッセージのスケジューリングと送信
・（ＡＭＦ又はＯＡＭから発信される）システム報知情報のスケジューリングと送信
・モビリティとスケジューリングのための測定および測定報告設定
・上りリンクにおけるトランスポートレベルのパケットマーキング
・セッション管理
・ネットワークスライシングのサポート
・ＱｏＳフロー管理とデータ無線ベアラへの配置
・ＲＲＣ＿ＩＮＡＣＴＩＶＥ状態のＵＥのサポート
・ＮＡＳメッセージの配信機能
・無線アクセスネットワークシェアリング
・デュアルコネクティビティ
・ＮＲとＥ－ＵＴＲＡとの間の緊密な連携

アクセス・モビリティ管理機能（ＡＭＦ）は、以下の主要な機能を提供する。
・非アクセス層（ＮＡＳ：Non-Access Stratum）シグナリングの終端
・ＮＡＳシグナリングのセキュリティ
・アクセス層（ＡＳ：Access Stratum）セキュリティ制御
・３ＧＰＰアクセスネットワーク間のモビリティのためのコアネットワーク（ＣＮ：Core Network）ノード間シグナリング
・アイドルモードＵＥの到達可能性（ページング再送の制御及び実行を含む）
・登録エリア管理
・システム内モビリティ及びシステム間モビリティのサポート
・アクセス認証
・ローミング権限のチェックを含むアクセス認可
・モビリティ管理制御（加入及びポリシー）
・ネットワークスライシングのサポート
・セッション管理機能（ＳＭＦ：Session Management Function）選択

さらに、ユーザプレーン機能（ＵＰＦ）は、以下の主要な機能を提供する。
・ＲＡＴ内／ＲＡＴ間モビリティのアンカーポイント（適用可能時）
・データネットワークとの相互接続のための外部ＰＤＵセッションポイント
・パケットルーティングと転送
・パケット検査およびユーザプレーン部分のポリシールールの強制（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）モデルは、ＱｏＳフローに基づいており、保証されたフロービットレートが求められるＱｏＳフロー（ＧＢＲ ＱｏＳフロー）と、保証されたフロービットレートが求められないＱｏＳフロー（非ＧＢＲ ＱｏＳフロー）の両方に対応している。そのため、ＮＡＳレベルでは、ＱｏＳフローはＰＤＵセッションにおける最も微細な粒度のＱｏＳの区分である。ＱｏＳフローは、ＮＧ－Ｕインタフェースを介してカプセル化ヘッダにおいて搬送されるＱｏＳフローＩＤ（ＱＦＩ）によってＰＤＵセッション内で識別される。

各ＵＥに対して、５ＧＣは、１つまたは複数のＰＤＵセッションを確立する。各ＵＥに対して、ＮＧ－ＲＡＮは、ＰＤＵセッションに合わせて少なくとも一つのデータ無線ベアラ（ＤＲＢ）を確立し、そのＰＤＵセッションのＱｏＳフローに対する追加のＤＲＢは、例えば、図３を参照して上述したように、後から設定可能である（いつ設定するかはＮＧ－ＲＡＮ次第である）。ＮＧ－ＲＡＮは、異なるＰＤＵセッションに属するパケットを異なるＤＲＢに配置する。ＵＥと５ＧＣにおけるＮＡＳレベルパケットフィルタは、ＵＬパケットとＤＬのパケットとをＱｏＳフローに関連付けるのに対し、ＵＥとＮＧ－ＲＡＮのＡＳレベルマッピングルールは、ＵＬのＱｏＳフローとＤＬのＱｏＳフローとをＤＲＢに関連付ける。

図５は、５Ｇ ＮＲの非ローミング参照アーキテクチャを示す（ＴＳ ２３．５０１ ｖ１６．１．０、セクション４．２３参照）。図４に例示される、５Ｇサービスをホストする外部アプリケーションサーバなどのアプリケーション機能（ＡＦ）は、サービスを提供するために３ＧＰＰコアネットワークとやり取りを行う。例えば、トラフィックルーティングに影響を与えるアプリケーションをサポートするためにネットワーク公開機能（ＮＥＦ：Network Exposure Function）にアクセスすること、ＱｏＳ制御などのポリシー制御のためにポリシーフレームワークとやり取りすること（ポリシー制御機能（ＰＣＦ）参照）が挙げられる。オペレータによる配備に基づき、オペレータから信頼されているとみなされるアプリケーション機能は、関連するネットワーク機能と直接やり取りすることができる。ネットワーク機能への直接のアクセスをオペレータから許可されていないアプリケーション機能は、ＮＥＦを介して外部に対する開放フレームワークを使用して、関連するネットワーク機能とやり取りする。

図５は、５Ｇアーキテクチャのさらなる機能ユニット、すなわち、ネットワークスライス選択機能（ＮＳＳＦ：Network Slice Selection Function）、ネットワークリポジトリ機能（ＮＲＦ：Network Repository Function）、統合データ管理（ＵＤＭ：Unified Data Management）、認証サーバー機能（ＡＵＳＦ：Authentication Server Function）、アクセス・モビリティ管理機能（ＡＭＦ）、セッション管理機能（ＳＭＦ）、及びデータネットワーク（ＤＮ）（オペレータによるサービス、インターネットアクセス、サードパーティによるサービス等）を示している。すべて又は一部のコアネットワーク機能及びアプリケーションサービスは、クラウドコンピューティング環境上に展開されかつ動作してもよい。

したがって、本開示では、ＱｏＳ要件に応じたｇＮｏｄｅＢとＵＥとの間の無線ベアラを含むＰＤＵセッションを確立するために、動作時に、ＵＲＬＬＣ、ｅＭＢＢ、およびｍＭＴＣサービスのうちの少なくとも一つに対するＱｏＳ要件を含む要求を、５ＧＣの機能（例えば、ＮＥＦ、ＡＭＦ、ＳＭＦ、ＰＣＦ、ＵＰＦ等）の少なくとも一つに送信する送信部と、動作時に、確立されたＰＤＵセッションを使用してサービスを実行する制御回路と、を備えるアプリケーションサーバ（例えば、５ＧアーキテクチャのＡＦ）が提供される。

ＬＴＥおよびＮＲにおいて、端末はユーザ機器（ＵＥ）と呼ばれる。これは、たとえばユーザ機器の機能を有するワイヤレス電話、スマートフォン、タブレットコンピュータ、またはＵＳＢ（ユニバーサルシリアルバス（ｕｎｉｖｅｒｓａｌ ｓｅｒｉａｌ ｂｕｓ））スティックなどの移動デバイスまたは通信装置であってもよい。しかし、移動デバイスという用語はそれに限定されず、一般的にはリレーもこうした移動デバイスの機能を有してもよく、移動デバイスがリレーの働きもしてもよい。

基地局は、たとえば端末にサービスを提供するためのネットワークの一部を形成する、ネットワークノードまたはスケジューリングノードである。基地局は、端末にワイヤレスアクセスを提供するネットワークノードである。

＜ＲＲＣ状態＞
ＮＲを含むワイヤレス通信システムにおいて、デバイスまたは通信装置（例、ＵＥ）は、トラフィックアクティビティによって異なる状態となり得る。ＮＲにおいて、デバイスはＲＲＣ＿ＩＤＬＥ、ＲＲＣ＿ＣＯＮＮＥＣＴＥＤ、およびＲＲＣ＿ＩＮＡＣＴＩＶＥの３つのＲＲＣ状態のうちの１つになり得る。最初の２つのＲＲＣ状態、すなわちＲＲＣ＿ＩＤＬＥおよびＲＲＣ＿ＣＯＮＮＥＣＴＥＤはＬＴＥの対応するものと類似であるのに対して、ＲＲＣ＿ＩＮＡＣＴＩＶＥはＮＲに導入された新しい状態であり、元のＬＴＥ設計には存在しない。加えて、デバイスがコアネットワーク（ｃｏｒｅ ｎｅｔｗｏｒｋ）との接続を確立したか否かによって、ＣＮ＿ＩＤＬＥおよびＣＮ＿ＣＯＮＮＥＣＴＥＤのコアネットワーク状態が存在する。

ＲＲＣ＿ＩＤＬＥにおいて、無線アクセスネットワークにおけるＲＲＣコンテキスト、すなわちデバイスとネットワークとの通信のために必要なパラメータは存在せず、デバイスは特定のセルに属していない。コアネットワークの観点からいうと、このデバイスはＣＮ＿ＩＤＬＥ状態である。デバイスはバッテリ消費を減らすためにほとんどの時間スリープしているため、データ転送は行われないだろう。ダウンリンクにおいて、アイドル状態のデバイスは定期的にウェイクアップし、もしあればネットワークからページングメッセージを受信する。デバイスはセル再選択を通じてモビリティに対処する。アップリンク同期は維持されないため、行われ得る唯一のアップリンク送信アクティビティは、たとえば接続状態になるためのランダムアクセスである。接続状態になることの一部として、デバイスおよびネットワークの両方でＲＲＣコンテキストが確立される。

ＲＲＣ＿ＣＯＮＮＥＣＴＥＤにおいて、ＲＲＣコンテキストが確立され、デバイスと無線アクセスネットワークとの通信のために必要なすべてのパラメータが両方のエンティティに既知である。コアネットワークの観点からいうと、このデバイスはＣＮ＿ＣＯＮＮＥＣＴＥＤ状態である。このデバイスが属するセルが既知となり、デバイスとネットワークとの間のシグナリングの目的で使用されるデバイスのアイデンティティであるセル無線ネットワーク一時識別子（Ｃ－ＲＮＴＩ：Ｃｅｌｌ Ｒａｄｉｏ－Ｎｅｔｗｏｒｋ Ｔｅｍｐｏｒａｒｙ Ｉｄｅｎｔｉｆｉｅｒ）が構成されている。この接続状態はデバイスへ／からのデータ転送に対して意図されたものであるが、デバイスの電力消費を減らすために不連続受信（ＤＲＸ）が構成され得る。接続状態のｇＮＢにおいて確立されたＲＲＣコンテキストが存在するため、関連するシグナリングに伴う接続セットアップが必要ないため、ＤＲＸを残してデータの受信／送信を開始することは比較的迅速である。モビリティは無線アクセスネットワークによって管理され、すなわちデバイスはネットワークに近隣セルの測定値を提供し、ネットワークは関連するときにハンドオーバを行うようデバイスに命令する。アップリンクの時間的整合性は存在してもしなくてもよいが、データ送信を行うためにはランダムアクセスを用いてそれを確立して維持する必要がある。

ＬＴＥにおいては、アイドル状態および接続状態のみがサポートされる。実際に一般的な実例は、アイドル状態を最初のスリープ状態として用いてデバイスの電力消費を低減させるというものである。しかし、多くのスマートフォンアプリケーションは一般的に小さいパケットを頻繁に送信するため、結果としてコアネットワークにおけるかなりの量のアイドルからアクティブへの遷移がもたらされる。これらの遷移には、シグナリング負荷および関連する遅延に関する損失がある。したがって、シグナリング負荷を低減して一般的な遅延を低減させるために、ＮＲにおいて定義される第３の状態がＲＲＣ＿ＩＮＡＣＴＩＶＥ状態である。

ＲＲＣ＿ＩＮＡＣＴＩＶＥにおいては、デバイスおよびｇＮＢの両方でＲＲＣコンテキストが保持される。コアネットワーク接続も保持され、つまりコアネットワークの観点からはデバイスはＣＮ＿ＣＯＮＮＥＣＴＥＤである。よって、データ転送のために接続状態に遷移するのが迅速である。コアネットワークシグナリングは必要ない。ＲＲＣコンテキストはすでにネットワークの所定の位置にあり、アイドルからアクティブへの遷移は無線アクセスネットワークにおいて対処され得る。同時に、デバイスはアイドル状態と同様のやり方でスリープでき、モビリティはセル再選択によって対処され、すなわちネットワークは関与しない。したがって、通信装置またはデバイスのモビリティはネットワークに制御されるのではなくデバイスに制御され、通信装置はランダムアクセスを通じてネットワークに接触できる。よって、ＲＲＣ＿ＩＮＡＣＴＩＶＥはアイドル状態と接続状態との混合であるようにみえる（さらなる詳細についてはＥ．ダールマン（Ｄａｈｌｍａｎ）ら、「５ＧＮＲ：次世代ワイヤレスアクセス技術（５ＧＮＲ：Ｔｈｅ Ｎｅｘｔ Ｇｅｎｅｒａｔｉｏｎ Ｗｉｒｅｌｅｓｓ Ａｃｃｅｓｓ Ｔｅｃｈｎｏｌｏｇｙ）」、第１版、セクション６．５．１～６．５．３を参照）。

＜非地上系ネットワーク（ＮＴＮ）＞
３ＧＰＰにおいて、非地上系ネットワーク（ＮＴＮ）におけるＮＲベースの動作が研究されて記述されている（例、３ＧＰＰ ＴＲ ３８．８１１、「非地上系ネットワークをサポートするための新たな無線（ＮＲ）の研究（Ｓｔｕｄｙ ｏｎ Ｎｅｗ Ｒａｄｉｏ（ＮＲ） ｔｏ ｓｕｐｐｏｒｔ ｎｏｎ－ｔｅｒｒｅｓｔｒｉａｌ ｎｅｔｗｏｒｋｓ）」、バージョン１５．２．０、および３ＧＰＰ ＴＲ ３８．８２１、「非地上系ネットワークをサポートするためのＮＲに対するソリューション（Ｓｏｌｕｔｉｏｎｓ ｆｏｒ ＮＲ ｔｏ ｓｕｐｐｏｒｔ ｎｏｎ－ｔｅｒｒｅｓｔｒｉａｌ ｎｅｔｗｏｒｋｓ）」、バージョン１６．０．０を参照）。

宇宙船／航空機のサービスカバレッジ能力が広いことと、物理的攻撃および自然災害に対する脆弱性が低減していることとのおかげで、ＮＴＮは、地上系ＮＲネットワークにカバーされ得ない領域（たとえば隔離された領域または遠隔地、飛行機または船舶の中など）およびサービス提供されていない領域（たとえば郊外および地方の地域など）である未対応の領域（unserved areas）におけるＮＲサービスの導入を促進し得る。さらに、ＮＴＮは移動するプラットフォームの乗客に対するサービスの継続性を提供したり、特に重要な通信に対してどこでも確実にサービスを利用可能にしたりすることによって、ＮＲサービスの信頼性を強化してもよい。

これらの利益は、単独で動作する非地上系ネットワークにも、統合された地上系および非地上系ネットワークにも関するものであり、カバレッジ、ユーザの帯域幅、システム容量、サービスの信頼性または可用性に影響することがある。

非地上系ネットワークとは、たとえば衛星などに搭載されたＲＦリソースを用いるネットワーク、またはネットワークのセグメントを示す。ＮＴＮは通常、以下のシステムエレメントを特徴とする。ＮＴＮ端末、これは３ＧＰＰ ＵＥを示してもよいし、衛星が３ＧＰＰ ＵＥに直接サービス提供しない場合はその衛星システムに固有の端末を示してもよい；サービスリンク、これはユーザ機器と宇宙／空中プラットフォームとの間の無線リンクを示す；ペイロードを搭載する（embarking）空中プラットフォーム；宇宙／空中プラットフォームをコアネットワークに接続するゲートウェイ；フィーダリンク、これはゲートウェイと宇宙／空中プラットフォームとの間の無線リンクを示す。

図６は非地上系ネットワークのシナリオを示しており、ここでは衛星およびＮＴＮゲートウェイを含む遠隔無線ユニットを介して端末（ＵＥ）間の送信が行われる。ｇＮＢは、スケジューリングデバイスとしてゲートウェイに位置する。衛星ペイロードは、アップリンクおよびダウンリンク方向の両方における周波数変換および無線周波数増幅器を実現する。よって、衛星はフィーダリンク（ＮＴＮゲートウェイと衛星との間）からサービスリンク（衛星とＵＥとの間）へのＮＲ無線インタフェースおよびその逆を繰り返す。この構成の衛星はトランスペアレント衛星と呼ばれる。

図７は非地上系ネットワークのシナリオを示しており、ここではスケジューリングデバイスとしてのｇＮＢを含む衛星を介して端末（ＵＥ）間の送信が行われる。この構成の衛星は再生（regenerative）衛星と呼ばれる。

ＮＴＮには、衛星およびＵＡＳ（無人航空システム（Ｕｎｍａｎｎｅｄ Ａｅｒｉａｌ Ｓｙｓｔｅｍ））プラットフォームを含む異なる種類のプラットフォームが存在してもよく、その例を表１に挙げている（３ＧＰＰ ＴＲ ３８．８２１の表４．１－１に対応、３ＧＰＰ ＴＲ ３８．８２１、セクション４．１、「非地上系ネットワークの概要（Ｎｏｎ－Ｔｅｒｒｅｓｔｒｉａｌ Ｎｅｔｗｏｒｋｓ ｏｖｅｒｖｉｅｗ）」も参照）。

所与の地球上の点に対して自身の位置を固定しないＬＥＯ、ＭＥＯ、およびＨＥＯ衛星に対して、セルもしくはＰＣＩ（物理セルＩＤ（Ｐｈｙｓｉｃａｌ Ｃｅｌｌ ＩＤ））、またはＮＲワイヤレスシステムのＳＳＢ（同期信号ブロック（Ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ Ｓｉｇｎａｌ Ｂｌｏｃｋ））ビームに対応する衛星ビームが地球上を移動していてもよい。

＜アップリンクリソーススケジューリング＞
アップリンクのスケジューリングをサポートするために、ＵＥは、ＵＥから送信されるデータが存在することと、そのデータの量とをｇＮＢに報告する。この報告は、バッファ状態報告（ＢＳＲ）をｇＮＢに送信することによって行われる。ＢＳＲは、ＵＥにおいてバッファされるデータの量についてネットワークに通知するためにアップリンクで報告される。ＵＥにおいてバッファされるデータは、異なる特徴および／またはサービスの品質（ＱｏＳ：ｑｕａｌｉｔｙ ｏｆ ｓｅｒｖｉｃｅ）に対する異なる要件を有するデータであってもよい。言い換えると、バッファされるデータは１つ以上の論理チャネルに属してもよい。論理チャネルは、論理チャネル識別子（ＩＤ：ｉｄｅｎｔｉｆｉｅｒ）によって識別される。次いで、データは特定の論理チャネルに割当てられる。さらに、論理チャネルは論理チャネル優先順位に関連付けられてもよい。論理チャネル優先順位は、データをそのＱｏＳ要件によって区別することを可能にする識別子である。１つ以上の論理チャネルが論理チャネルグループ（ＬＣＧ：ｌｏｇｉｃａｌ ｃｈａｎｎｅｌ ｇｒｏｕｐ）を形成してもよい。論理チャネルグループは、ＬＣＧ識別子によって識別される。ショートまたはロングＢＳＲフォーマットを使用することによって、ＬＣＧごとのＢＳＲ報告が行われる。本開示の目的のために、論理チャネルＩＤおよび／またはＬＣＧ ＩＤは、たとえば数字またはシンボルなどの任意の種類のＩＤであってもよい。

ＮＲにおいて、ＢＳＲはＵＥからネットワーク（例、ｇＮＢ）に伝達されるＭＡＣ制御エレメント（ＣＥ：ｃｏｎｔｒｏｌ ｅｌｅｍｅｎｔ）の一種であり、ＵＥバッファ内に送信すべきデータがどれほどあるかについての情報を伝達する。ＢＳＲを受信した後、もしリソースが利用可能であれば、ネットワークはアップリンクグラントによって対応する量のリソースを割当てるだろう。この機構によって、ネットワークはアップリンクリソース（ＰＵＳＣＨリソース）を最適化できる。すなわち、ＵＥが何かを送信するときにのみアップリンクリソースを割当てて、リソースの無駄につながる過剰な（すなわち、ＵＥがバッファ内のデータを送信するために必要とするより多くの）リソースの割当てを回避することができる。スケジューリングがどのように働くか、およびバッファ状態報告についてのさらなる詳細は、３ＧＰＰ ＴＳ ３８．３２１ Ｖ１５．８．０（２０１９－１２）セクション５．４．５、６．１．３、および６．２．１から得ることができる。

例示的なショートＢＳＲフォーマットが図８に示される。ショートＢＳＲは１オクテット（ｏｃｔｅｔ）（Ｏｃｔ１）の長さを有し、これは８ビットすなわち１バイトを意味する。この例示的なショートＢＳＲは２つのフィールドからなり、第１のフィールドはＬＣＧグループ（特にＬＣＧ識別子（ＬＣＧ ＩＤ））を示し、第２のフィールドはバッファサイズ、すなわち第１のフィールドで示される（ＬＣＧ ＩＤによって定義される）ＬＣＧグループのデータ量を示す。ここで第１のフィールドは３ビットの長さを有するのに対し、第２のフィールドは５ビットの長さを有する。

例示的なロングＢＳＲフォーマットが図９に示される。ロングＢＳＲは、最大８のＬＣＧに対するバッファの長さを示すことができる。この目的のために、８つのＬＣＧすなわちＬＣＧ_０～ＬＣＧ_７のそれぞれに、１オクテット（Ｏｃｔ１）の８ビットが関連付けられる。これらの８ビットの各々は、前記ビットに関連付けられたＬＣＧについて同じロングＢＳＲにおいてバッファ長さがさらに指定されているか否かを示す。第１のオクテット（Ｏｃｔ１）の後に、ｍのさらなるオクテット１～ｍが続く。パラメータｍは、同じロングＢＳＲにおいてバッファ長さが指定されているＬＣＧの数に相当する。オクテット１～ｍの各々は、１つのそれぞれのＬＣＧに対するバッファ長さを指定する。ＢＳＲ内のオクテット１～ｍの順序は予め定められており、たとえば第１のオクテット（Ｏｃｔ１）のフィールド（ここではビット）と同じ順序である。

なお一般的に、本開示はこうしたショートＢＳＲおよびロングＢＳＲに限定されない。正しくは、ショートＢＳＲはロングＢＳＲよりも少ない長さを有する。しかし、ショートＢＳＲは単一オクテットに限定される必要はない。単一オクテットの長さは、非常に効率的かつコンパクトなシグナリングの利点を提供する。しかし、スケジューリングノード（基地局、ｇＮＢ）により多くの情報を提供するために、もっと長いショートＢＳＲが使用され得る。さらに、ショートＢＳＲおよびロングＢＳＲに対する、フィールドおよびそれらの長さに関する上述のフォーマットは異なっていてもよい。一般的に、ＬＣＧはまったくシグナリングされず、端末のすべての論理チャネルに対するバッファ状態が示されることが想定される。

ＮＲにおいて、ＲＲＣプロトコルは、論理チャネル（ＬＣＨ：ｌｏｇｉｃａｌ ｃｈａｎｎｅｌ）とＬＣＧ ＩＤとの間のマッピングを（半静的に）構成する。論理チャネルグループＩＤフィールドは、報告されるバッファ状態を有する論理チャネル（単数または複数）のグループを識別する。バッファサイズフィールドは、利用可能な総データ量を識別する。標準は、バッファサイズフィールドの可能な値と、実際のバイトのサイズとの間のマッピングを定義する。標準仕様３ＧＰＰ ＴＳ ３８．３２１、Ｖ．Ｆ．８．０、表６．１．３．１－１に基づく例は、５ビットのバッファサイズフィールドに対するバッファサイズレベル（バイト単位）を有する表を示す。さらに、同じ標準仕様の表６．１．３．１－２は、８ビットのバッファサイズフィールドに対するバッファサイズレベル（バイト単位）を示す。表６．１．３．１－１を以下にコピーしている。

表から分かるとおり、この表はインデックス０～３１をそれぞれのバッファサイズに関連付けている。

ショートＢＳＲフォーマットは１つの論理チャネルグループのみに対するアップリンクバッファを報告するために使用されるのに対し、ロングＢＳＲフォーマットはすべての論理チャネルグループに対するアップリンクバッファを報告するために使用される。

上述のとおり、ＮＴＮリンクはより長いラウンドトリップタイムを有することがあり、そのために物理レイヤ（または任意のその他のレイヤ）におけるＨＡＲＱ（ハイブリッド自動再送要求（Ｈｙｂｒｉｄ Ａｕｔｏｍａｔｉｃ Ｒｅｐｅａｔ Ｒｅｑｕｅｓｔ））の適用の効果が低くなる。したがって、ネットワークがＨＡＲＱフィードバックを有効化および無効化できることを可能にすることが有利であってもよい。アップリンクＨＡＲＱフィードバックの有効化または無効化は、ＵＥごと、ＨＡＲＱプロセスごと、および／またはＬＣＨごとに構成可能であり得る。ここでアップリンクＨＡＲＱフィードバックは、バッファ状態が報告されたアップリンクで伝達されたデータに対してダウンリンクで送信される、肯定および／または否定応答確認を示す。本開示は、ＭＡＣ ＣＥにおけるバッファ状態報告に限定されない。むしろ、本開示のＵＣＩは、たとえば別のＭＡＣエレメントまたは物理レイヤなどの任意のその他のシグナリングにおいて報告されてもよい。

ＵＬデータ送信遅延が増加するとき、特にＭｓｇＡおよびＭｓｇ３に対するＵＬグラントは、グラントされるデータ量に関して非常に制限されることがあり、これはＵＥがショートＢＳＲのみを送信することを可能にしてもよい。ＭｓｇＡおよびＭｓｇ３は、ランダムアクセスの目的のためにＮＲにおいて使用されるメッセージのタイプである。ランダムアクセス手順は、たとえばＲＲＣ＿ＩＤＬＥからの最初のアクセス；ＲＲＣ再接続手順；ＵＬ同期状態が「非同期」であるときのＲＲＣ＿ＣＯＮＮＥＣＴＥＤの際のＤＬまたはＵＬデータの到着；ＳＲに対する利用可能なＰＵＣＣＨリソースが存在しないときのＲＲＣ＿ＣＯＮＮＥＣＴＥＤの際のＵＬデータの到着；ＳＲの障害；同期再構成（例、ハンドオーバ）の際のＲＲＣによる要求；ＲＲＣ＿ＩＮＡＣＴＩＶＥからの遷移；二次ＴＡＧに対する時間的整合性の確立；他のＳＩの要求、またはビーム障害回復などのさまざまなイベントによってトリガされる。

特に、Ｍｓｇ３は４ステップＲＡＣＨ手順で送信される。４ステップＲＡＣＨ手順は、（ＭＡＣプロトコル）のＭｓｇ１メッセージによってＵＥからｇＮＢにプリアンブルを送信することと、ｇＮＢがＭｓｇ２によってランダムアクセスに対する応答を送信することと、ＵＥがＭｓｇ３によってＲＲＣ接続要求を送信することと、ｇＮＢがＭｓｇ４によって接続応答を送信することとを含む。他方で、ＭｓｇＡは２ステップランダムアクセスチャネル（ＲＡＣＨ：ｒａｎｄｏｍ ａｃｃｅｓｓ ｃｈａｎｎｅｌ）手順で送信される。２ステップＲＡＣＨ手順は４ステップＲＡＣＨ手順を簡略化したものであり、ここではＭｓｇＡが上記のＭｓｇ１およびＭｓｇ３の両方を伝達する一方で、ＭｓｇＢが上述のＭｓｇ２およびＭｓｇ４の両方を伝達する。３ＧＰＰ ＴＳ ３６．３２１、Ｖ１６．０．０（２０２０－０３）によると、たとえば競合解消などのためにアップリンク送信が必要とされるとき、ｅＮＢはランダムアクセス応答において５６ビット（またはＮＢ－ＩｏＴに対しては８８ビット）未満のグラントを提供するべきではない。通常、リソース操作効率を提供するために、ネットワークはＭｓｇＡ（２ステップＲＡＣＨ）およびＭｓｇ３（４ステップＲＡＣＨ）において最小サイズのＵＬグラントを提供し、それは５６ビットまたは８８ビットである。ＭｓｇＡおよびＭｓｇ３を送信するためのＵＬグラントは非常に制限される可能性があり、そのためＵＥはショートＢＳＲしか送信できないことがある。ネットワークがＵＥの完全なバッファ状態を知るためには、ＵＥにロングＢＳＲを送信させるための追加のステップが必要である。この追加のステップは、アップリンクデータ送信に対するさらに長い遅延をもたらすだろう（ＮＴＮに対する遅延は最大５４４ｍｓとなり得る）。

さらにネットワークは、互いに排他的な２ステップＲＡＣＨ手順および４ステップＲＡＣＨ手順の実行に使用される無線リソースを半静的に決定してもよい。ＲＡＣＨ手順の第１のメッセージの送信に使用される無線リソースは、少なくともＲＡＣＨオケージョンおよびプリアンブルを含む。たとえば、２ステップＲＡＣＨ手順において、第１のメッセージＭｓｇＡはＰＲＡＣＨリソース（例、ＲＡＣＨオケージョンおよびプリアンブル）だけでなく、関連するＰＵＳＣＨリソースも使用する。ＲＡＣＨオケージョンという用語は、ＵＥがプリアンブルを送信できるリソースを示す。

一般的に、ＲＡＣＨプリアンブルについては、たとえば３ＧＰＰ ＴＳ ３８．２１１ Ｖ１６．２．０、「表６．３．３．２－２：ＦＲ１に対するランダムアクセス構成および対をなすスペクトル／補足アップリンク（Ｔａｂｌｅ ６．３．３．２－２：Ｒａｎｄｏｍ ａｃｃｅｓｓ ｃｏｎｆｉｇｕｒａｔｉｏｎｓ ｆｏｒ ＦＲ１ ａｎｄ ｐａｉｒｅｄ ｓｐｅｃｔｒｕｍ／ｓｕｐｐｌｅｍｅｎｔａｒｙ ｕｐｌｉｎｋ）」およびセクション６．３．３．２、「物理リソースに対するマッピング（Ｍａｐｐｉｎｇ ｔｏ ｐｈｙｓｉｃａｌ ｒｅｓｏｕｒｃｅｓ）」などを参照されたい。

たとえば、ＵＥは３ＧＰＰ ＴＳ ３８．３２１、セクション５．４．３．１．３において言及される以下の優先順位に基づいて、グラントされたリソースを満たしてもよい。論理チャネルは以下の順序に従って優先される（最高優先順位が最初に挙げられる）：Ｃ－ＲＮＴＩ ＭＡＣ ＣＥまたはＵＬ－ＣＣＣＨからのデータ；設定グラント確認ＭＡＣ ＣＥ；ＢＳＲに対するＭＡＣ ＣＥ、ｐａｄｄｉｎｇのために含まれるＢＳＲは除く；単一エントリＰＨＲ ＭＡＣ ＣＥまたは複数エントリＰＨＲ ＭＡＣ ＣＥ；任意の論理チャネルからのデータ、ＵＬ－ＣＣＣＨからのデータは除く；推奨ビットレートクエリに対するＭＡＣ ＣＥ；およびｐａｄｄｉｎｇのために含まれるＢＳＲに対するＭＡＣ ＣＥ。よって、（上記のＢＳＲに対するＭＡＣ ＣＥに対応する）ＭｓｇＡおよびＭｓｇ３を送信するためのＵＬグラントが得られるときに、もし任意のスペースが残っていれば、ＵＥはＭＡＣ ＣＥおよびユーザデータ（任意の論理チャネルからのデータ）を含ませる。

どの種類のＬＣＨ（ＡＣＫ有効化、ＡＣＫ無効化、混合）に対するものかを知らずに、ネットワークがＬＣＨのＨＡＲＱ構成に適合するグラントを提供することはないだろう。特に、ネットワークがＢＳＲ要求を受信するとき、ネットワークはそのＢＳＲがＨＡＲＱフィードバックを有効化したＬＣＨか、またはＨＡＲＱフィードバックを無効化したＬＣＨか、またはその両方によってトリガされたものかどうかを決定できない。結果として、ＨＡＲＱフィードバック有効化またはＨＡＲＱフィードバック無効化またはその両方に対応するＵＬリソースを割当てるべきかどうかがネットワークには分からないだろう。

図１０は、ＬＣＧ（論理チャネルグループ）ごとにどれが実行されるかを報告するＢＳＲを示す。ネットワークによってＬＣＨ（論理チャネル）とＬＣＧ（論理チャネルグループ）との間のマッピングが構成され、それはネットワークおよびユーザ通信デバイス（ＵＥ）の両方に既知である。たとえば図１０においては、ＬＣＧ０およびＬＣＧ１の２つのＬＣＧが示される。ＬＣＧ０は３つのＬＣＨすなわちＬＣＨ１、ＬＣＨ２、およびＬＣＨ３を含み、このうちＬＣＨ１およびＬＣＨ２は応答確認有効化を有し、ＬＣＨ３は応答確認無効化を有する。よってＬＣＧ０は、応答確認有効化および応答確認無効化の両方を有するデータを有する。さらに、ＬＣＧ１は構成された３つのＬＣＨすなわちＬＣＨ４、ＬＣＨ５、およびＬＣＨ６を有し、このうちＬＣＨ４は応答確認有効化を有するのに対し、ＬＣＨ５およびＬＣＨ６は応答確認無効化を有する。よってＬＣＧ１も、応答確認有効化および応答確認無効化の両方を有するデータを有する。なお、すべて応答確認有効化を有するＬＣＨを有するＬＣＧを定義することが可能である（たとえばＬＣＨ１、ＬＣＨ２、およびＬＣＨ４を有する別のＬＣＧｘなど）。さらに、すべて応答確認無効化を有するＬＣＨを有するＬＣＧを定義することも可能である（たとえばＬＣＨ３、ＬＣＨ５、およびＬＣＨ６を有する別のＬＣＧｙなど）。図１０のシナリオにおいて、ネットワークがＬＣＧ０に対するＢＳＲを受信するとき、このＢＳＲがＬＣＨ１／ＬＣＨ２またはＬＣＨ３によってトリガされたものかどうかは区別されない。同様に、ネットワークがＬＣＧ１に対するＢＳＲを受信するとき、このＢＳＲがＬＣＨ４またはＬＣＨ５／ＬＣＨ６によってトリガされたものかどうかは区別されない。

ネットワークがより効率的にアップリンクリソースを割当てることを可能にするために、本開示のいくつかの実施形態によると、ＵＥは、ＨＡＲＱフィードバック有効化およびＨＡＲＱフィードバック無効化に関連する利用可能なデータの総量に関する情報（すなわちＢＳＲ）を伝達するアップリンク制御情報を生成してネットワークに送信できる。他方でネットワークも、ＨＡＲＱフィードバック有効化およびＨＡＲＱフィードバック無効化に関連する利用可能なデータの総量に関する情報（すなわちＢＳＲ）を受信できる。さらにネットワークは、受信した情報に従って、ＨＡＲＱ有効化を有するデータの量と、ＨＡＲＱ無効化を有するデータの量とを考慮に入れることによって、スケジューリングを行い得る。次いでネットワークは、それに従って単数または複数のグラントを発行する。

このアプローチはいくつかの利点を提供する。ＨＡＲＱ有効化を有するデータの量と、ＨＡＲＱ無効化を有するデータの量とをネットワークが区別することを可能にする情報に基づいて、ネットワークはスケジューリングを必要とするトラフィックに対して対応するＵＬグラントを提供する。さらに、ＨＡＲＱ有効化およびＨＡＲＱ無効化の混合データに対してただ１つのＢＳＲ送信が必要であるため、ＵＬデータ送信遅延を低減できる。

図１１は通信デバイス１１６０を示す。通信デバイス１１６０は回路１１８０を含み、回路１１８０は動作中に、（ｉ）ユーザ機器（ＵＥ）である通信デバイスにおける送信のために利用可能なデータと、（ｉｉ）前記送信のために利用可能なデータは応答確認が有効化されたデータおよび応答確認が無効化されたデータの両方を含むこととを示すアップリンク制御情報（ＵＣＩ：ｕｐｌｉｎｋ ｃｏｎｔｒｏｌ ｉｎｆｏｒｍａｔｉｏｎ）を生成する。図１１から分かるとおり、回路１１８０はこの目的のためにＵＣＩ生成回路１１８５を含んでもよい。通信デバイス１１６０はトランシーバ１１７０をさらに含み、トランシーバ１１７０は動作中に、生成されたアップリンク制御情報を送信する。この送信は、図１１において鉛直の破線で示されるチャネルを通じて行われてもよい。このやり方で、ネットワークはＵＣＩを受信して、そのＵＣＩから、前記送信のために利用可能なデータが応答確認が有効化されたデータおよび応答確認が無効化されたデータの両方を含むか否かを決定できる。

図１１は通信デバイス１１１０も示す。通信デバイス１１１０はトランシーバ１１２０を含み、トランシーバ１１２０は動作中にアップリンク制御情報（ＵＣＩ）を受信する。ＵＣＩは（ｉ）ユーザ機器（ＵＥ）における送信のために利用可能なデータと、（ｉｉ）前記送信のために利用可能なデータが応答確認が有効化されたデータおよび応答確認が無効化されたデータの両方を含むこと（例、含むか否か）とを示す。加えて通信デバイス１１１０は回路１１３０をさらに含み、回路１１３０は動作中に、アップリンク制御情報に従ってＵＥにおける前記送信のために利用可能なデータに対する少なくとも１つのグラントを提供する。この提供することは回路の特定の部分、すなわちスケジューリング回路１１３５によって行われてもよい。次いでトランシーバ１１２０は動作中に、提供された少なくとも１つのグラントを送信する。なお、本明細書において動作の活動を行うモジュール（ユニット）に言及するとき、その言及はそのモジュール（ユニット）がその活動を行うように構成されるということに相当する。

本開示におけるアップリンク制御情報は、いずれかの特定のフォーマットに限定されない。以下にいくつかの例示的な実施形態が説明されており、これはＵＣＩの可能なフォーマットを示す。第１の例示的な例において、アップリンク制御情報は、送信のために利用可能なデータのうちの応答確認が有効化されたデータおよび／または応答確認が無効化されたデータの占有率と、送信のために利用可能なデータの総量とを指定する。

図１２は、可能なＵＣＩフォーマットの例を示す。この例におけるＵＣＩは、１オクテットのサイズを有するショートＢＳＲに対応する。第１のフィールド（この例においては３ビット）１２１０は、送信のために利用可能なデータのうちの応答確認が有効化されたデータおよび応答確認が無効化されたデータの占有率を示す。第２のフィールド１２２０はバッファの合計サイズを示し、それは応答確認が有効化されたデータと、応答確認が無効化されたデータと、応答確認が有効化および無効化されたデータを含む混合データとを含んでもよい。この例では、第２のフィールド１２２０は５ビットのサイズを有する。

たとえば、各々が１０００ビットのデータを有する論理チャネルＬＣＨ_１、ＬＣＨ_２、ＬＣＨ_３、ＬＣＨ_４、ＬＣＨ_５、およびＬＣＨ_６が存在するものと想定する。よってＵＥは、論理チャネルグループのすべての論理チャネルに６０００ビットの総データ量を有する。ＵＥが総データ量と共に占有率（例、パーセンテージ）を含ませるとき（例、５０％ＨＡＲＱフィードバック有効化、５０％ＨＡＲＱフィードバック無効化）、ネットワークはそれに従ってアップリンクリソースを割当てることができる。この例では、ネットワークはＵＥに対して、ＨＡＲＱフィードバック有効化データに対する３０００ビットグラントと、ＨＡＲＱフィードバック無効化データに対する３０００ビットグラントとを割当てることができる。

ＵＥがネットワークへの自身のシグナリングに（例、パーセンテージの形態の）占有率の任意の表示を含ませないとき、ネットワークはＨＡＲＱフィードバック有効化を有するデータと、ＨＡＲＱフィードバック無効化を有するデータとの量を区別しない。したがって、ＨＡＲＱフィードバック有効化を有するデータと、ＨＡＲＱフィードバック無効化を有するデータとの量を区別するために、占有率（パーセンテージ）に関する情報は、ネットワークが効率的にアップリンクリソースを割当てることを助けてもよい。

図１２に示されるＢＳＲフォーマットは８ビットを含み、その最初の３ビットはＨＡＲＱ構成に関する情報を伝達し、残りの５ビットは総データ量を伝達する。このＢＳＲフォーマットは、第１および第２のフィールドのそれぞれの意味を指定することによって、さらに定義されてもよい。たとえば、以下の表１は、割当てられた意味（セマンティック）を有する３ビットによってシグナリングされ得る８つの値の例を示す。

特に、１つの値（ここでは「０００」）は、第２のフィールドにおいてシグナリングされる総データ量のすべてのデータが応答確認有効化を有することを示す。言い換えると、データがＵＥから基地局（または一般的にネットワーク）にアップリンク送信された後、基地局（ネットワーク）は、そのデータが受信されて正常に復号されたか否かを示す肯定または否定応答確認を送信する。さらに、別の値（ここでは「１１１」）は、第２のフィールドにおいてシグナリングされる総データ量のすべてのデータが応答確認無効化を有することを示す。残りの値は、応答確認が有効化されたデータ（およびそれによって暗黙的に無効化されたデータ）の異なるパーセンテージを示す。たとえば、値「１１０」は、約１０％のデータが応答確認有効化を有する一方で、残りのデータが応答確認無効化を有することを示す。値「００１」は、約９０％のデータが応答確認有効化を有し、残りのデータが応答確認無効化を有することを示す。「約（ａｒｏｕｎｄ）」という用語は、たとえば値「１１０」については、０より大きいが２０％未満のデータが有効化されたＨＡＲＱを有することを示してもよい。この例は、表によって定義されるパーセンテージ値を中心として重複する区間をもたらす。一般的に、これは慣例的なものであり、そのセマンティクス（解釈）はエンコーダおよびデコーダに既知であるべきである。たとえば値「１１０」は、０～１５％のデータがＨＡＲＱ有効化を有することを示すように指定されてもよい。同様に「１０１」は、１５％～２５％のデータがＨＡＲＱ有効化を有することを示してもよく、結果として表によって定義されるパーセンテージ値を中心として重複しない区間がもたらされる。さらなる代替策が可能である。たとえば、第１のフィールドは範囲を定義してもよい。たとえば、値「１１０」は有効化ＨＡＲＱを有するデータの占有率が最大１０％であることを指定するものとみなされてもよく、一方で「１０１」は有効化ＨＡＲＱを有するデータの占有率が１０％～２０％であることなどを示してもよい。このアプローチは、第１のフィールドが取り得る値が、パーセンテージが含まれると考えられるパーセンテージの範囲を示すことを想定している。

したがってＵＥ側では、有効化ＨＡＲＱを有するデータの占有率の値が下限（表１の第２列の下限、こうしたデータのより大きい占有率を意味する）と上限との間にあるとき、ＵＥは以下を選択してもよい。
－ オプション１：下限値、結果として実際よりも高い占有率がシグナリングされる。
－ オプション２：上限値、結果として実際よりも低い占有率がシグナリングされる。
－ オプション３：ＵＥにおいて決定された実際の占有率に近い値。

オプション１はＵＥの観点からは有益である。なぜならｇＮＢは、通常時間の制約があるか、または緊急を要するＨＡＲＱ無効化トラフィックに対して十分なグラントを割当てるからである。

たとえば、ＵＥの８０％のデータが有効化されたＨＡＲＱフィードバックを有するとき、ＵＥは「０１０」（オプション１の場合）および「００１」（オプション２の場合）を選択する。たとえば、ＵＥが総データ量Ｘ４を有し、ここで２０％のデータがＨＡＲＱフィードバック有効化に属する（すなわち、８０％のデータがＨＡＲＱフィードバック無効化に属する）とき、ＵＥは１０１００００１１を含ませる（Ｘ４については以下の表２を参照）。

以下の表２は、第２のフィールドの５ビットによって示され得る３２の値と、総データボリューム量Ｘ１、Ｘ２、…、Ｘ３２との例示的な関連性を示す。総データボリューム量は上記で示した表６．１．３．１－１のものに対応してもよいし、異なる態様で設計されてもよい。

ここでの総データボリューム量は、たとえば区間の下限または上限などを表し得る。

端末（ＵＥ、たとえば上記の通信デバイス１１６０など）側では、送信されるデータ量が下限Ｘｉと上限Ｘ（ｉ＋１）との間にあるとき、端末は以下を選択できる。
－ オプション１：下限値Ｘｉ。
－ オプション２：上限値Ｘ（ｉ＋１）。
－ オプション３：下限値Ｘｉおよび上限Ｘ（ｉ＋１）のうち、送信されるデータ量に近い方のもの。

オプション１は、無効化ＨＡＲＱを有するデータに対して十分なリソースを割当てる結果をもたらすため、いくつかのシナリオにおいて有益であってもよい。なお、ＵＥの挙動は３つのオプションのうちの１つを取るように標準化されてもよいし、実装に固有であってもよい。

たとえば、Ｘ１はデータの総数が０～Ｘ１（例、Ｘ１を含まない）であることを示してもよく、Ｘ２はデータの総数がＸ１～Ｘ２（例、Ｘ２を含まない）であることを示してもよく、以下同様にして、Ｘ３２はデータの総数がＸ３１と、ＢＳＲ報告に示され得るデータの総量（ボリューム）に対する割当て可能な最大値との間であることを示してもよい。上述のとおり、セマンティクスは異なるやり方で定義されてもよく、たとえばＸ値（表２の第２列）は重複する区間または重複しない区間の中央を定義してもよい。これによってＵＥの解釈の曖昧さがなくなり、実際のデータ量と定義された区間とを単に比較して、実際の量が含まれる区間を選択する。なお、シンボルＸｉ（すなわちＸ１、Ｘ２、…）は、たとえば上述のＮＲ ＭＡＣ仕様３ＧＰＰ ＴＳ３８．３２１の表６．１．３．１－１において定義されたものなどのいくつかの量か、またはＵＥおよびｇＮＢの両方に既知である任意のその他の量を表す。

例示的な実装によると、アップリンク制御情報は、送信のために利用可能なデータのうちの応答確認が有効化されたデータの第１の優先順位および／または応答確認が無効化されたデータの第２の優先順位をさらに含み、この第１の優先順位は第２の優先順位と異なる。優先順位の提供は、より効率的なＱｏＳ制御を促進してもよい。

図１３は、対応するショートＢＳＲフォーマットを示す。特に、この例におけるショートＢＳＲは、８ビットおよび次の３つのフィールドを有する。ＨＡＲＱフィードバック有効化／無効化を示すための第１のフィールド１３１０、総データ量を示すための第２のフィールド１３２０、および優先順位を示すための第３のフィールド１３３０。特にこの例において、ＵＥは、ＢＳＲフォーマットにデータボリュームおよびＨＡＲＱフィードバック構成と共に優先順位の表示を含ませる。ＢＳＲフォーマットは、表１を参照して上記で考察したセマンティクスを有する３ビットを有する第１のフィールドを含んでもよい。ＢＳＲフォーマットは、データ量を示すための３ビットを（図１２を参照して説明した例の５ビットの代わりに）さらに含んでもよい。

加えて、第３のフィールド１３３０の２ビットは、第２のフィールド１３２０に量が示されている総データの優先順位を示すために使用され得る。優先順位情報は、ネットワークがＱｏＳ（サービスの品質）を満たすために動的グラントの優先順位を付けることを助ける。たとえば、ネットワークはより高い優先順位のデータにより早くＵＬグラントを提供してもよい。

表３は、２ビットの例示的なサイズの第３のフィールドのセマンティクスを定義する表の例示的な実装を提供する。

たとえば、第１の端末ＵＥ１が優先順位表示「００」を有する総データ量を有し、第２の端末ＵＥ２が優先順位表示「１１」を有する総データ量を有するとき、ネットワークはＵＥ２により早い動的グラントを提供することとなる。なぜなら表示「００」は、応答確認が有効化されているか無効化されているかにかかわらず、ＵＥ１における送信のために利用可能なデータの総量が低い優先順位を有することを指定するからである。他方で表示「１１」は、応答確認が有効化されているか無効化されているかにかかわらず、ＵＥ２における送信のために利用可能なデータの総量が高い優先順位を有することを指定する。ここでのネットワークについての言及は、リソース割当て／スケジューリングを担う任意のネットワークインフラストラクチャデバイスを意味する。本明細書における例示的な実施形態において、これは基地局（たとえばｇＮＢなど）を示す。しかし一般的には、別のエンティティがこれらのタスクを担ってもよい。

より早いグラントまたはより早いスケジューリングについて言及するとき、それはネットワーク側で（基地局において）高い優先順位のデータが低い優先順位のデータより早く対処されることを意味する。したがって端末は（統計的に）、低い優先順位を有するデータよりも高い優先順位を有するデータに対するグラントを早く受信してもよい。

一般的に、表３に例示したとおり、端末およびネットワークは、以下のうちの少なくとも２つの場合を区別してもよい（総データは送信のために利用可能なデータであり、その量も優先順位と同じＢＳＲに示されている）。
ｉ）応答確認の有効化または無効化に関係なく総データに対する高い優先順位。
ｉｉ）応答確認の有効化または無効化に関係なく総データに対する低い優先順位。
ｉｉｉ）応答確認有効化を有する総データの部分に対する高い優先順位および応答確認無効化を有する総データの部分に対する低い優先順位。
ｉｖ）応答確認無効化を有する総データの部分に対する高い優先順位および応答確認有効化を有する総データの部分に対する低い優先順位。

本開示は、表３に示される例に限定されない。代わりに、もっと少ない優先順位レベル（例、上述の可能性のうちの２つを示すレベル０および１のみ）か、または単なる高低よりも細かい優先順位間の区別を示すもっと多い優先順位レベルが存在してもよい。さらに、優先順位と応答確認有効化／無効化との結合シグナリングが適用されてもよい。たとえば、上述のオプションｉｉ）およびｉｉｉ）は、総データが応答確認有効化および応答確認無効化の両方を有するときにのみ意味をなす。よって（ＢＳＲにおいて示される）すべての総データに対して応答確認が有効化されるときのｉｉ）およびｉｉｉ）の組み合わせは、シグナリング可能にする必要がない。ＢＳＲに示されるすべての総データに対して応答確認が無効化されるときについても同じことが当てはまる。よって、別々のシグナリングと比較して１ビットが節約されてもよい。この１ビットは、たとえば送信のために利用可能なデータの量（バッファ状態）を示すことなど、異なる目的のために使用されてもよい。当業者に明らかであるとおり、シグナリングに関するさらなる修正が可能である。

図１４は、ショートＢＳＲフォーマットの別の例、または一般的にはアップリンク制御情報内容の別の例を示す。この例において、アップリンク制御情報は、応答確認が有効化されたデータの第１の量１４１０と、応答確認が無効化されたデータの第２の量１４２０とを示す。

図１４において、最初の４ビット（第１のフィールド）は、有効化ＨＡＲＱフィードバックを有するデータの量に関する情報を含む。１オクテットの長さを有するショートＢＳＲの残りの４ビット（第２のフィールド）は、無効化ＨＡＲＱフィードバックを有するデータの量に関する情報を含む。

４ビットによってシグナリングされる値と、応答確認有効化を有する（第１のフィールドの場合）総データボリュームおよび有さない（第２のフィールドの場合）総データボリュームとの関連性を例示的な表４に示す。言い換えると、表４は、４ビットフィールドによって示され得る１６の可能な値を用いてデータ量がどのようにシグナリングされ得るかを示す。

この特定の例において、値「００００」（すなわち表４の第１列の０）は０のデータ量を示す。よって、たとえばフィールド１４１０に対して０がシグナリングされるとき、それは応答確認無効化を有するデータしか存在しないことを意味する。同様に、フィールド１４２０に対して０がシグナリングされるとき、それは応答確認有効化を有するデータしか存在しないことを意味する。０の値は上記の表２には必要なかった。なぜなら、これらの例示的な実施形態においては、アップリンク制御情報が送信されるとすぐに何らかのデータが送信のために利用可能だったからである。しかし、いくつかのアプリケーションに対しては、表２にも０値が含まれてもよい。値Ｘ１～Ｘ１６の選択／意味は、表２を参照して上述されたとおりであってもよい。Ｘ１～Ｘ１６の値は表２の値とは異なっていてもよいし、すべての第２の値に対応するなどしていてもよい。

なお、図１４の例は、図１３を参照して上述された優先順位を示す追加のフィールドを提供することによってさらに修正されてもよい。特に、１ビット長または２ビット長の優先順位フィールドが、ショートＢＳＲ内の最初か、２つのフィールド１４１０および１４２０の間か、またはオクテットの最後に提供されてもよい。したがって、フィールド１４１０および１４２０の少なくとも一方の長さが１ビット短くされてもよい。たとえば、表３の例を適用するために、オクテットのうちの２ビットが優先順位を示し、３ビットがＨＡＲＱ有効化を有する第１のデータ量を示し、残りの３ビットがＨＡＲＱ無効化を有する第２のデータ量を示すだろう。なお、「応答確認有効化」および「ＨＡＲＱ有効化」という用語は、本明細書において交換可能に使用される。特に本開示にとって、自動再送要求が実際にハイブリッドであるかどうかは重要ではない。他方で、本明細書に記載される実施形態は、たとえば物理レイヤＡＲＱがＨＡＲＱであるＮＲなどの通信システムに容易に適用可能である。

別の例示的な実装によると、アップリンク制御情報はアップリンク制御情報インデックスを含む。アップリンク制御情報インデックスは、送信のために利用可能なデータの量と、応答確認有効化状態との組み合わせに関連付けられる。さらに、応答確認有効化状態は、次のうちの少なくとも１つを示し得る。
－ 送信のために利用可能なデータに対する応答確認が有効化されているか無効化されているか、および
－ 前記送信のために利用可能なデータが、応答確認が有効化されたデータおよび応答確認が無効化されたデータの両方を含むか否か。

８つの値０～７を取り得るＵＣＩインデックスおよびその意味の例を表５に示す。ここでの意味は、総データボリュームと、応答確認が有効化および／または無効化されているかどうかの構成との特定の組み合わせを示す。表５の最終列には、ネットワークがスケジューリング／リソース割当てを行うときに、インデックスによって伝達される情報をどのように使用し得るかも含まれている。

言い換えると、ＵＣＩインデックス値は総データボリュームと共にＨＡＲＱ構成に関連付けられる。ＵＥは、そのＵＥが送信のために利用可能な総データボリュームに対応し、かつＨＡＲＱフィードバック構成に対応するＵＣＩインデックス値を選択する。ＨＡＲＱフィードバック情報は次のうちの１つである。
（ｉ）総データ量に対して応答確認が有効化されている、
（ｉｉ）総データ量に対して応答確認が無効化されている、
（ｉｉｉ）総データ量の一部に対して応答確認が有効化され、総データ量の残りの部分に対して無効化されている。

第２列は、それぞれのＨＡＲＱ構成に対するデータ量を示す。たとえばＨＡＲＱ構成（ｉ）については、データ量に対して３つの可能な値Ｘ１、Ｘ２、およびＸ３が区別可能である。ＨＡＲＱ構成（ｉｉ）についても、この例においてはデータ量に対して３つの可能な値Ｘ１、Ｘ２、およびＸ３が区別可能である。しかし一般的に、構成（ｉｉ）における値Ｘ１、Ｘ２、Ｘ３は、構成（ｉ）および／または（ｉｉｉ）における値Ｘ１、Ｘ２、Ｘ３とは異なり得ることを注記する。一般的に、構成（ｉ）および（ｉｉ）に対する可能な値の数が異なることがある。表５にみられるとおり、構成（ｉｉｉ）においては、総データ量を示す可能な値Ｘ１およびＸ２は３つではなく２つである。これも単なる一例である。一般的に、構成（ｉｉｉ）は、２つより多くの値を示すことを可能にしてもよく、加えて上述のとおり、総データのうちの応答確認されたデータの占有率を示すことを可能にしてもよい。さらに、構成（ｉｉｉ）に対する値Ｘ１およびＸ２は、構成（ｉｉ）および／または（ｉ）に対する値Ｘ１およびＸ２とは異なっていてもよい。たとえば、ＵＥがＨＡＲＱフィードバック有効化を有する総データボリュームＸ１を有するとき、ＵＥはＵＣＩインデックス０を選択する。結果として、ネットワークはＨＡＲＱフィードバック有効化を有するＵＬグラントをスケジューリングすることとなる。したがって、ｇＮＢはグラントを生成するときに、ＵＣＩを復号してそれを考慮に入れることによって、対応するＵＬグラントを決定できる。

ＵＣＩインデックスは、物理アップリンク制御チャネル（ＰＵＣＣＨ：ｐｈｙｓｉｃａｌ ｕｐｌｉｎｋ ｃｏｎｔｒｏｌ ｃｈａｎｎｅｌ）内のスケジューリング要求によって伝達されてもよい。仕様３ＧＰＰ ＴＳ３８．２１３、Ｖ１５．８．０（２０１９－１２）、セクション９．２．２はＰＵＣＣＨフォーマットを示す。ＵＣＩインデックスは、たとえば３ビットを伝達し得るＰＵＣＣＨフォーマット４などの既存のＰＵＣＣＨフォーマット内で伝達されてもよい。しかし、新たなＰＵＣＣＨフォーマットを提供することによって、たとえばデータ量に対するより多くのレベル（値）、ならびに／または示された量のうちのＨＡＲＱ有効化を有するデータおよびＨＡＲＱ無効化を有するデータの占有率を示すためのより多くの値などの、より多くの情報をｇＮＢにシグナリングすることが促進されてもよい。

たとえば上記に示された表５などのＵＣＩインデックス表は、仕様において固定されてもよく、すなわちＵＥおよびｇＮＢに既知であってもよく、かつ構成可能でなくてもよい。別の例において、ＵＣＩインデックス表は構成可能であってもよい。構成は、たとえば無線リソース制御（ＲＲＣ：Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ）プロトコルなどの上位レイヤのプロトコルなどによって行われてもよい。このオプションはより柔軟である。ネットワークは、こうした関連性をたとえばシステム情報メッセージ（単数または複数）内または専用のＲＲＣメッセージ（単数または複数）内などで送信できる。システム情報は、セル内の任意の端末によって読取り可能な共通情報として、セルによって定期的にブロードキャストされてもよい。

上述のとおり、ＵＥはＵＣＩインデックス値を物理レイヤのスケジューリング要求（ＳＲ：Ｓｃｈｅｄｕｌｉｎｇ Ｒｅｑｕｅｓｔ）メッセージに含ませてもよい。しかし表５は、または一般的に、データ量とＨＡＲＱフィードバック構成とをこうした組み合わせに対するインデックスによって結合的に符号化する表は、ＭＡＣシグナリングによって使用されてもよい。

公知のネットワークのコンテキストにおいて使用され得る実施形態において、アップリンク制御情報は媒体アクセス制御（ＭＡＣ：Ｍｅｄｉｕｍ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）レイヤにおけるバッファ状態報告であり、それはＵＥにおいて送信のために利用可能なデータの量を示す。ＵＥが送信すべきデータを有し、それに対するリソース割当てをネットワーク（例、ネットワークアーキテクチャに依存して、たとえば基地局／アクセスポイントまたは基地局コントローラなどのネットワークエンティティ）が行うべきであるときに、いつでもバッファ状態が送信される。スケジューリングされたリソースまたは競合ベースのランダムアクセス手順において、バッファ状態自体が送信されてもよい。

代替的または付加的に、上述のとおり、アップリンク制御情報は物理レイヤ（レイヤ１）におけるスケジューリング要求である。

バッファ状態報告（いくつかの公知のネットワークと同様にＭＡＣレイヤによって伝達されてもよいし、別のレイヤで伝達されてもよい）は、８ビットのサイズを有するショートバッファ状態報告であり、それは以下を含む。
－ 前記送信のために利用可能なデータが応答確認が有効化されたデータおよび応答確認が無効化されたデータの両方を含むかどうかをシグナリングするための３ビット、およびＵＥによる送信のために利用可能なデータの量をシグナリングするための５ビット；または
－ 前記送信のために利用可能なデータが応答確認が有効化されたデータおよび応答確認が無効化されたデータの両方を含むかどうかをシグナリングするための３ビット、ＵＥによる送信のために利用可能なデータの量をシグナリングするための３ビット、および送信のために利用可能なデータの優先順位をシグナリングするための２ビット；または
－ 応答確認が有効化されたデータの量に対する４ビット、および応答確認が無効化されたデータの量に対する４ビット。

本明細書における「ショートＢＳＲ」という用語は、ショートＢＳＲと、ショートＢＳＲよりも（ビット数に関して）長いロングＢＳＲとの２種類のＢＳＲをサポートする通信システムを示す。それらは通常、異なる状況で使用される。たとえば、ショートＢＳＲはＲＡＣＨ（競合ベースの送信）において使用されるのに対し、ロングＢＳＲは通常、データ通信が確立されたときか、またはショートＢＳＲを用いた交換によってロングＢＳＲに対するリソースがグラントされた後に使用される。上述の３つの例示的なオプションは、ビット数に関して本開示を限定するものではない。

ＮＲネットワークのコンテキストにおいて本明細書に記載される実施形態を使用するとき、送信のために利用可能なデータは、論理チャネルグループのすべての論理チャネルに対して利用可能なデータであってもよく；かつ論理チャネルグループの各論理チャネルは、以下のうちのいずれか１つを伝達するように構成可能である。
－ 応答確認が有効化されたデータ、
－ 応答確認が無効化されたデータ、ならびに
－ 応答確認が有効化されたデータおよび応答確認が無効化されたデータ。

本明細書においては、ＨＡＲＱフィードバック構成が論理チャネルごと、ＨＡＲＱプロセスごと、または別様に設定され得るかどうかに関する想定は行わない。

上述の実施形態のいずれかによって、アップリンク制御情報は、超高信頼性低遅延通信（ｅＵＲＬＬＣ：ｅｎｈａｎｃｅｄ Ｕｌｔｒａ Ｒｅｌｉａｂｌｅ ａｎｄ Ｌｏｗ Ｌａｔｅｎｃｙ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ）および拡張モバイルブロードバンド（ｅＭＢＢ：Ｅｎｈａｎｃｅｄ Ｍｏｂｉｌｅ Ｂｒｏａｄｂａｎｄ）の少なくとも一方を示し得るトラフィックタイプ表示をさらに含んでもよい。

特に、ＵＥはアップリンク制御情報内（例、ＢＳＲ内）にトラフィックタイプ情報（例、ｅＵＲＬＬＣ対ｅＭＢＢ）を示してもよい。こうした情報によって、ネットワークはトラフィックタイプに従って異なるグラントを割当てることができてもよい（例、ｅＭＢＢに対するグラントよりもｅＵＲＬＬＣに対するグラントの方がＭＣＳが低い）。異なるグラントという用語は、グラントがたとえば変調、ＭＩＭＯ、電力、またはその他の設定などに関して割当てられたリソースに関して互いに異なり得ることを意味する。

ネットワーク（例、ｇＮＢ）は、たとえば論理チャネルを構成するときなどにトラフィックタイプを構成する。例示的なＲＲＣプロトコル構文（ＡＳＮ．１フォーマット）が以下に示される。特に、論理チャネル構成情報エレメントLogicalChannelConfigは、アップリンク固有パラメータul-SpecificParametersの中にトラフィックタイプエレメントtraffic-type-differentiationを含み、これは第１の種類のトラフィックに対して第１の値（たとえば０）を取り、第２の種類のトラフィックに対して第２の値（たとえば１）を取るブール（Ｂｏｏｌｅａｎ）であってもよい。

たとえば、ＵＥがＢＳＲを送信するとき、ＢＳＲは総データボリュームと共にトラフィックタイプを示し、トラフィックタイプはｅＭＢＢまたはｅＵＲＬＬＣ（一般的に、それぞれ第１のトラフィックタイプおよび第２のトラフィックタイプ）のいずれかに属する。たとえば、この目的のために２ビットが使用され得る。「００」はｅＵＲＬＬＣを示してもよく、一方「０１」はｅＭＢＢを示す。値「１０」は論理チャネルグループ内の両方の種類のトラフィックを示してもよい。別の例は、最初の４ビットがｅＭＢＢに属するデータを示し、残りの４ビットがｅＵＲＬＬＣに属するデータを示すというものである。この例は、図１４を参照して説明した例に幾分類似している。言い換えると、アップリンク制御情報は、ｅＭＢＢトラフィックタイプに対するＵＥにおける送信のために利用可能なデータの量を示す第１のフィールドと、ｅＵＲＬＬＣトラフィックタイプに対するＵＥにおける送信のために利用可能なデータの量を示す第２のフィールドとを含む。ＵＣＩは、４ビットの第１のフィールドと、別の４ビットの第２のフィールドとからなる８ビットのショートＢＳＲであってもよい。しかし、本開示はこうしたＵＣＩのフォーマットに限定されない。むしろＵＣＩはさらなるフィールドを含んでもよい。たとえば、ＵＣＩは優先順位を示す第３のフィールドを含んでもよい。例示的な実装において、優先順位フィールドは次の値のうちの少なくとも２つを取ることができてもよい。（ｉ）第１のトラフィックタイプおよび第２のトラフィックタイプの両方に対する低い優先順位を示す値、（ｉｉ）第１のトラフィックタイプおよび第２のトラフィックタイプの両方に対する高い優先順位を示す値、（ｉｉｉ）第１のトラフィックタイプに対する低い優先順位および第２のトラフィックタイプに対する高い優先順位を示す値、ならびに（ｉｖ）第１のトラフィックタイプに対する高い優先順位および第２のトラフィックタイプに対する低い優先順位を示す値。

言い換えると、ｅＭＢＢおよびｅＵＲＬＬＣトラフィックの区別は、ＨＡＲＱ有効化を有するデータとＨＡＲＱ無効化を有するデータとの区別について上述したものと同じやり方で示されてもよい。よって、ＵＣＩにおいて有効化ＨＡＲＱを有するデータおよび無効化ＨＡＲＱを有するデータの両方を含む混合データの表示を提供する代わりに（またはそれに加えて）、ＵＣＩは第１のタイプのトラフィックおよび第２のタイプのトラフィックの両方を含む混合データの表示を含んでもよい。ここで第１のタイプのトラフィックはｅＭＢＢであり、第２のタイプのトラフィックはｅＵＲＬＬＣである。しかし、本開示はこれらのトラフィックタイプに限定されない。第１のタイプのトラフィックは、第２のタイプのトラフィックの遅延要件よりも厳しい遅延要件を有するトラフィックであってもよいし、その逆であってもよい。加えて、たとえば異なるＱｏＳ要件などによって互いに異なる、３つ以上の異なる種類のトラフィックが存在してもよい。一般的に、応答確認有効化を有するデータは第１のタイプのトラフィックともみなされてもよく、応答確認無効化を有するデータは第２のタイプのトラフィックとみなされてもよい。よって、上述のとおりの本開示は、任意の複数のタイプのトラフィックに応じて一般的に適用されてもよい。

たとえば、以下の表６は例示的なＵＣＩフォーマットを示し、ここで３ビットの第１のフィールドは遅延要件および信頼性を示す。なお一般的に、本開示はより高い信頼性および低い遅延要件の両方に限定されない。それらのうちの一方のみがシグナリングされるか、またはその両方が互いに独立にシグナリングされる実施形態が存在してもよい。

たとえば、値「０００」は、（第３のフィールドに示される）総データボリュームの１００％が、高い遅延要件すなわち低い遅延と、高い信頼性要件とを有することを示す。なお、これはいくつかの実施形態においてＨＡＲＱ無効化を有するデータに対応してもよく、一方で低い遅延要件を有するトラフィックはＨＡＲＱ有効化データに対応してもよい。この例において、値「００１」は、（第３のフィールドに示される）総データボリュームの９０％が高い遅延／信頼性要件を有するのに対し、総データの１０％が低い遅延／信頼性要件を有する（例、高い遅延／信頼性要件を有するトラフィックよりも高い遅延でもＱｏＳを満たす）ことを示す。第１のフィールドの３ビットに対応する表のさらなる行は対応する意味を有し、高い遅延／信頼性要件および低い遅延／信頼性要件を有するトラフィックの間の異なる比率を示す。

第２のフィールドは２ビットの長さを有し、（第３のフィールドに示される）総データボリュームがｅＵＲＬＬＣ（「００」値）、ｅＭＢＢ（「０１」値）、または両方（「１０」値）を含むことを示す。さらに、第３のフィールドはＵＥにおける送信のために利用可能なデータの総量を示す。

別の例が表７に示されており、ここでは３ビット（第１のフィールド）がトラフィックタイプ占有率を示し、５ビット（第２のフィールド）がすべてのトラフィックタイプに対する総データボリュームを示す。言い換えると、この３ビットは８つの異なるトラフィック占有率のシグナリングを可能にする。たとえば、１つの値（ここでは「０００」）は総データボリュームが１００％ｅＭＢＢトラフィックを含むことを示す。別の値（ここでは「０１１」）は、総データボリュームのうちのｅＭＢＢおよびｅＵＲＬＬＣの特定の占有率を示してもよい（たとえば５０％ｅＭＢＢおよび５０％ｅＵＲＬＬＣなど）。さらなる値（ここでは「１１１」）は、１００％のｅＵＲＬＬＣトラフィックを示してもよい。第２のフィールド（ここでは例示的に５ビットを有する）は、端末において送信のために利用可能なデータの総量を示す。

さらなる例が表９に示される。表９において、第１のフィールドは表７の第１のフィールドと同様に、ｅＭＢＢトラフィックとｅＵＲＬＬＣトラフィックとのトラフィック占有率（または一般的に、第１のタイプのトラフィックと第２のタイプのトラフィックとの占有率）を示す。なお一般的には、３つ以上のタイプのトラフィックが定義されてもよく、したがって３つ以上のタイプのトラフィック間の占有率がアップリンク制御情報内に示されてもよい。第２のフィールドは総データボリューム、すなわちＵＥにおいて送信するために利用可能なデータの量を示す。ここで第２のフィールドは、表７に関して上述された５ビットではなく、３ビットの長さを有する。しかし一般的に、本開示はいずれかの特定のビット数に限定されない。たとえばＮＲコンテキストでのアプリケーションなどに対して、８ビットを有するＵＣＩを保つことは有利かもしれないが、一般的にはより少量またはより大量のビットが使用されてもよい。表９は、それぞれのトラフィックタイプの優先順位を示す第３のフィールドも示す。高い優先順位と低い優先順位との区別が存在する。この例においては２つの可能なトラフィックタイプが存在するため、優先順位は２ビットで示される。一般的に、もっと多くの優先順位レベルおよび／またはもっと多くのトラフィックタイプが使用されてもよい。ここで分かるとおり、１つのレベル（ここでは「００」）は、第１および第２のレベルの両方が高い優先順位を有することを示す。別のレベル（ここでは「０１」）は、第１のタイプのトラフィック（ｅＭＢＢ）が高い優先順位を有するのに対し、第２のタイプのトラフィック（ｅＵＲＬＬＣ）は低い優先順位を有することを示す。別のレベル（ここでは「１０」）は、第２のタイプのトラフィック（ｅＵＲＬＬＣ）が高い優先順位を有するのに対し、第１のタイプのトラフィックは低い（ｅＭＢＢ）優先順位を有することを示す。最後に、別のレベル（ここでは「１１」）は、第１および第２のレベルの両方が低い優先順位を有することを示す。ここでの高低は、これら２つの可能な状態の間の「高い」および「低い」を意味し、すなわち「高い」とは「低い」よりも高いことを意味する。

ＵＣＩの送信に続き、ＵＥ（のトランシーバ）は動作中に、ＵＥにおける前記送信のために利用可能なデータに対する少なくとも１つのグラントを受信する。上述のとおり、スケジューリングエンティティは両方のタイプのトラフィックに対して１つの共通のグラントを送信してもよいし、第１のタイプのトラフィックおよび第２のタイプのトラフィックに対する別個のフィールドを有する１つのグラントを送信してもよい。

代替的に、前記少なくとも１つのグラントは、応答確認が有効化されたデータに対する第１のグラントと、応答確認が無効化されたデータに対する第２のグラントとを含み、この第１のグラントおよび第２のグラントは、別々のダウンリンク制御情報メッセージによって伝達される。言い換えると、複数のトラフィックタイプのそれぞれに対して複数の異なるグラントが存在する。

図１５は、基地局において実行される方法と、ユーザデバイスにおいて実行される方法と、基地局および移動デバイスの間の通信とを示す、組み合わされた流れ図およびメッセージチャートである。

右手側に通信方法が示される。この方法は、ユーザ機器（ＵＥ）によって（すなわちユーザデバイス側で）実行される以下のステップを含む。アップリンク制御情報１５８０を生成するステップ１５１０、および生成されたアップリンク制御情報１５８０を送信するステップ１５２０。上述のとおり、アップリンク制御情報１５８０はＵＥにおいて送信のために利用可能なデータを示し、かつ前記送信のために利用可能なデータが応答確認が有効化されたデータおよび応答確認が無効化されたデータの両方を含むこと（含むかどうか）を示す。

ＵＣＩ１５８０を生成するステップ１５１０に先行して、送信のために利用可能なデータの量を決定することが行われてもよい。これらのデータは、１つ以上の論理チャネルを含む論理チャネルグループを通じた送信のために利用可能なデータであってもよい。この決定は、送信バッファ内のデータ量を取得することによって行われてもよい。

生成するステップ１５１０は特に、ＵＣＩ１５８０を示すシグナリングメッセージを生成することを含んでもよい。このシグナリングメッセージは、たとえばバッファ状態報告メッセージなどのＭＡＣメッセージなどであってもよく、特に８ビットの長さを有し得るショートバッファ状態報告であってもよい。生成するステップ１５１０においてメッセージは、（メッセージにどのフィールドがどの順序で配置されているかを定義する）メッセージの構文に基づいて生成される。構文は、ユーザデバイスおよびネットワーク側（例、基地局）の両方が理解している標準または任意の慣例によって定義されてもよい。

送信するステップ１５２０は、たとえば符号化および／もしくは変調の実行、信号の成形、ならびに／または電力の調整などの送信処理を含んでもよく、それをユーザデバイスの１つ以上のアンテナから送信する。ＵＥ側の送信するステップ１５２０から基地局側の受信するステップ１５３０への、上部にＵＣＩ１５８０を有する矢印は、生成するステップ１５１０において生成されたメッセージ内でＵＣＩ１５８０がＵＥから基地局に伝達されることを示す。

この方法は、グラント１５９０の受信のステップ１５６０をさらに含んでもよい。グラント１５９０の受信のステップ１５６０は、グラントを復調および／または復号することと、グラントによって伝達された情報を抽出することとを含んでもよい。たとえば、グラントはリソースの識別を含み、これはＵＥによって送信のために利用可能なデータを送信するために使用されてもよい。さらにグラントは、そのグラントが発行されたＬＣＧの表示ならびに／または、たとえば適用されるべき変調および符号化スキームもしくはその他の送信パラメータなどのさらなる設定を含んでもよい。

図１５の左手側に、基地局によって実行される通信方法が示される。この方法は、アップリンク制御情報１５８０を受信するステップ１５３０と、アップリンク制御情報に従ってＵＥにおける前記送信のために利用可能なデータに対する少なくとも１つのグラントを提供するステップ１５４０と、受信したアップリンク制御情報をもたらしたＵＥにその提供された少なくとも１つのグラント１５９０を送信するステップ１５５０とを含む。上述と同様に、ＵＣＩ１５８０は、ユーザ機器（ＵＥ）における送信のために利用可能なデータと、前記送信のために利用可能なデータが応答確認が有効化されたデータおよび応答確認が無効化されたデータの両方を含むこととを示す。基地局側の送信するステップ１５５０からＵＥ側の受信するステップ１５６０への、上部にグラント１５９０を有する矢印は、グラント１５９０が基地局からＵＥに伝達されることを示す。

ここでのグラントの提供は、リソース割当ておよびスケジューリングによって行われてもよい。さらに、アップリンク制御情報のフォーマットに対しては、この開示に記載される任意の実施形態が適用される。

図１６はさらに詳細な流れ図を示し、これはユーザデバイス側で実行され得る方法を示す。ステップ１６１０において、ＵＥは（例、アップリンクに）送信のために利用可能なデータが存在すること、すなわちＵＥの送信バッファ内にデータが存在することを判定する。送信のためのデータが存在しないとき（ステップ１６１０におけるｎｏ）、ＵＥは送信のためのデータが存在するかどうかをチェックし続ける。ＵＥにおける送信のためのデータが存在するとき（ステップ１６１０におけるｙｅｓ）、ステップ１６２０において、ＵＥは応答確認有効化／無効化に関するデータのタイプを決定する。たとえばステップ１６２０において、ＵＥは、送信のためのデータが有効化および無効化された応答確認を有する混合データを含むか否かを決定する。ここでの送信のための（利用可能な）データとは、それに対する単一のバッファ状態がネットワークに提供されるデータである。たとえば、ＮＲシステムのコンテキストにおいて、このデータは同じ論理チャネルグループの論理チャネルに関連するデータであってもよい。しかし、本開示はこうした（論理チャネルおよび論理チャネルのグループによる）送信組織化に限定されない。ステップ１６２０において混合データ（すなわち、データの一部が応答確認有効化を有する一方で、残りの部分が応答確認無効化を有するデータ）が存在するとき、この方法はステップ１６４０に進む。混合データが存在しないとき、この方法はステップ１６３０に進む。

ステップ１６４０において、ＵＥは混合データの量を示すアップリンク制御情報を提供する。上述のとおり、いくつかの実施形態において、ＵＥはデータが混合されているという表示を提供する。いくつかの例示的な実装において、これはＵＥがＨＡＲＱ有効化（暗黙的にＨＡＲＱ無効化を有するデータの割合も示す）またはＨＡＲＱ無効化（暗黙的にＨＡＲＱ無効化を有するデータの割合も示す）を有するデータの割合（占有率）を示すことで実現される。代替的に、ＵＥは混合データの各部分（ＨＡＲＱ有効化、ＨＡＲＱ無効化）に対するデータ量の表示を提供してもよい。こうしたシグナリングは、送信のために利用可能な総データのうちのＨＡＲＱ有効化有／無のデータの占有率も効果的に示す。

ステップ１６３０において、ＵＥは、送信のために利用可能なデータ全体が応答確認有効化または無効化を有するかどうかを決定することを進める。送信のために利用可能なデータが応答確認有効化を有するとき、ステップ１６５０においてＵＥは総データ量の表示を有するアップリンク制御情報を提供する。加えてＵＥは、そのデータが応答確認有効化を有することを示す表示も提供してもよい。しかし、ネットワークが異なるやり方でそれを取得できるときには、こうした表示は必要なくてもよい。たとえば、ネットワークが論理チャネルを構成していて、ＵＥおよびＨＡＲＱ有効化／無効化に対するグループが論理チャネルごとに設定される場合、特定の論理チャネルグループにはＨＡＲＱ有効化を有する論理チャネルのみが存在するか、またはＨＡＲＱ無効化を有する論理チャネルのみが存在することをネットワークは知っている。こうした場合にはアップリンク制御情報に追加の表示は必要なく、送信のために利用可能なデータの総量を示せば十分である。

他方で、送信のために利用可能なデータが応答確認無効化を有するとき、ステップ１６６０においてＵＥは総データ量の表示を有するアップリンク制御情報を提供する。これはステップ１６５０と同様である。

よって、ステップ１６５０および１６６０においては、たとえばＮＲシステムによって公知のショートＢＳＲなどの通常のＢＳＲが送信されてもよい。ステップ１６４０の場合は、追加の情報が提供される。本開示は、ＮＲシステムによって公知のＢＳＲに限定されない。むしろ上述のとおり、アップリンク制御情報は任意の他のやり方でアップリンクに送信されてもよい。一般的に、アップリンク制御情報は、物理レイヤにおけるスケジューリング要求と共に送信されても、それとは分離されて送信されもよいし、バッファ状態またはＭＡＣレイヤもしくは別のレイヤにおける別のメッセージと共に送信されてもよい。上記の説明はネットワーク、特に基地局によって行われるアップリンクスケジューリングに注目しているが、本開示はそれに限定されることはなく、サイドリンクを介した送信のために利用可能なデータに対してもアップリンク制御情報が提供されてもよいことを注記する。サイドリンクスケジューリングは、上述のとおりに基地局／ネットワークによって調整されてもよいし、別のユーザデバイスによって少なくとも部分的に行われてもよい。

図１７は、スケジューリングエンティティによって実行される方法を例示する流れ図である。スケジューリングエンティティは、基地局、別のネットワークエンティティ、または別の通信（ユーザ）デバイスであってもよい。ステップ１７１０において、（この特定の例における）ｇＮＢは、ＵＥからアップリンク制御情報を受信したかどうかを判定する。肯定的であるとき（ステップ１７１０におけるｙｅｓ）、この方法はステップ１７２０に進む。そうでないとき（ステップ１７１０におけるｎｏ）、その判定が繰り返し行われる。ステップ１７２０において、アップリンク制御情報が受信されたとき、ｇＮＢは、アップリンク制御情報に示されるデータ量がＨＡＲＱ有効化を有するデータおよびＨＡＲＱ無効化を有するデータの両方に関連するかどうかを判定する。アップリンク制御情報に示されるデータ量が両方に関連するとき（ステップ１７２０におけるｙｅｓ）、この方法はステップ１７４０に進み、ここでｇＮＢは２つのグラントを提供し、１つのグラントはＨＡＲＱ有効化を有するデータに対するものであり、１つのグラントはＨＡＲＱ無効化を有するデータに対するものである。ＮＲの場合、グラントは、物理ダウンリンク制御チャネル（ＰＤＣＣＨ：ｐｈｙｓｉｃａｌ ｄｏｗｎｌｉｎｋ ｃｏｎｔｒｏｌ ｃｈａｎｎｅｌ）において提供され得るダウンリンク制御情報（ＤＣＩ：ｄｏｗｎｌｉｎｋ ｃｏｎｔｒｏｌ ｉｎｆｏｒｍａｔｉｏｎ）内で送信されてもよい。よって、ステップ１７４０で提供される２つのグラントは、２つの別個のＤＣＩメッセージ内に提供されてもよい。これは、ショートＤＣＩフォーマットを維持することを促進してもよい。

２つの別個のグラントは、特に有効化ＨＡＲＱおよび無効化ＨＡＲＱを有するデータに対して異なる優先順位が示される場合に、利点を提供してもよい。たとえば、より優先順位が高いデータに対するグラントは、より優先順位が低いデータに対するグラントよりも早く発行されてもよい。しかし、本出願は２つの別個のグラントを提供することに限定されない。一般的に、いくつかの実装においては、共通のグラントが提供されてもよいし、単一のメッセージ内に２つのグラントが提供されてもよい。

アップリンク制御情報に示されるデータ量が両方の種類のデータに関連しないとき（ステップ１７２０におけるｎｏ）、この方法はステップ１７３０に進む。ステップ１７３０において、ｇＮＢは、アップリンク制御情報に示されるデータ量が応答確認有効化または無効化を有するかどうかを判定する。データが応答確認有効化を有するとき（ステップ１７３０におけるｙｅｓ）、ステップ１７５０においてこうしたデータに対するグラントが発行される。データが応答確認無効化を有するとき（ステップ１７３０におけるｎｏ）、ステップ１７６０においてこうしたデータに対するグラントが発行される。

言い換えると、図１６および図１７において、ＵＣＩは一般的に、端末（スケジューリングされたエンティティ）から基地局（スケジューリングエンティティ）への送信のために利用可能なデータの量を示す。この量は、混合データ（ＨＡＲＱ有効化を有するデータおよびＨＡＲＱ無効化を有するデータの両方を含む）か、またはＨＡＲＱ有効化もしくはＨＡＲＱ無効化のいずれかを有するデータに対して示されてもよい。その量が混合データに対するものであるとき、上述のとおり、もしＨＡＲＱ有効化を有するデータおよび有さないデータの占有率に関する表示が提供されれば、それは有益である。

＜ＢＳＲを送信するためのリソースの選択＞
ランダムアクセス手順を用いたグラントフリーアクセスの可能性とは別に、いわゆる設定グラント（ＣＧ：ｃｏｎｆｉｇｕｒｅｄ ｇｒａｎｔ）の可能性が存在する。

したがって、ＵＥはＰＤＣＣＨにおける個別のリソース割当てを受信する必要なく、ＰＵＳＣＨにおけるアップリンク送信を可能にするように構成され得る。このやり方で構成されたＵＥは、任意の時間に任意のリソースブロックにおいて自由に送信することはできないが、リソースブロックの特定のセットにおける定期的な送信を可能にするように構成される。

動的グラントを伴わないこうした送信には次の２タイプがある。
－ 設定グラントタイプ１、ここではアップリンクグラントがＲＲＣによって（完全に）提供され、設定アップリンクグラントとして記憶される。よって、ＰＤＣＣＨにおけるＬ１シグナリングは必要ない。さらなるＲＲＣシグナリングがＵＥを再構成するまで、設定グラントは利用可能であり続ける。
－ 設定グラントタイプ２、ここではアップリンクグラントがＰＤＣＣＨによって提供され、設定アップリンクグラントのアクティブ化または非アクティブ化を示すＬ１シグナリングに基づいて、設定アップリンクグラントとして記憶またはクリアされる。リソース割当てのサブセットはＲＲＣによって提供される。残りの情報は、アクティブ化トリガまたは非アクティブ化トリガとして動作するＰＤＣＣＨにおいて提供される。

タイプ１およびタイプ２は、ＲＲＣによってサービングセルごとおよび帯域幅部分ごとに構成される。ＵＥは、送信すべきデータを有するときのみＰＵＳＣＨにおいて送信を行い、すなわちアップリンクバッファが空のときは、ＵＥは何も送信しない。

設定グラントリソース割当ての欠点は、ＵＥが特定の時間および周波数領域リソース、ならびに特定のＭＣＳを使用するように構成されることである。さらにＮＴＮの場合、ＣＧリソースがわずかである（地上系通信リソースよりもわずかである）ことがある。これは、ＮＴＮの限られたリソースを特に効率的に使用するという一般的なインセンティブのためである。

設定グラントおよび２ステップＲＡＣＨの両方がＢＳＲ送信に使用され得る。よってＵＥは、ＣＧおよび２ステップＲＡＣＨ手順の両方をＮＴＮの際に同時に進行（pending）させ得る。タイプ１およびタイプ２設定グラントの両方が実行可能であり、地上系使用の場合と類似のやり方でＮＴＮにおいてサポートされてもよい。

ＵＥは、設定グラントだけでなく２ステップＲＡＣＨ手順も介してＢＳＲを送信する可能性を有するだろう。結果として、もしＣＧおよび２ステップＲＡＣＨリソースの両方をＵＥが利用可能であれば、どちらのリソースを使用すべきかを指定するための戦略があることが望ましい。図１８は、時間によるリソースの例示的な位置を示す。白丸はランダムアクセス（ＲＡ）オケージョンを表す。斜線付きの丸はＣＧリソースの位置を表す。ＮＴＮの特定の場合には、典型的にＣＧリソースは時間領域においてＲＡオケージョンよりも頻度が低いだろう。図面において、ＢＳＲは時間Ｔ１にトリガされる。なお、ＢＳＲをトリガするとは、送信すべきデータが存在するためにＢＳＲが生成されて送信されようとすることを意味する。この場合の次に生じ得るＲＡオケージョン１８１０は、次に生じ得るＣＧ１８２０よりも近い。

この場合に、ＵＥはＢＳＲがＲＡＣＨを介して送信されるか、設定グラントを介して送信されるかを決定すべきである。設定グラントを使用するときと、２ステップＲＡＣＨリソースを使用するときとを制御するために、タイマが使用されてもよい。タイマの実行中に設定グラントが到着するとき、ＵＥはＣＧリソースを通じてＢＳＲを送信するだろう。タイマの実行中に設定グラントが到着しないとき、ＵＥは２ステップＲＡを用いてＢＳＲを送信するだろう。このコンテキストにおいて、「ＣＧが到着する」という用語は、ＣＧによって指定されるリソース（ＣＧに基づくデータを提出する機会ともみなされてもよい）が存在することを意味する。

図１９は、ＣＧリソースの周期性がＲＡオケージョンの周期性よりも低い（周期１９１０の方が長い）典型的なＮＴＮのシナリオを示す。これは図１８に示されるシナリオと類似している。時間Ｔ１にＢＳＲがトリガされる。ＢＳＲトリガと同時に、タイマ１９２０が開始される。図１９が示す実例においては、タイマの終了より前にＣＧリソースは存在しない。次のＣＧリソース１９３０は、タイマの終了後に位置する。ＣＧリソースの周期性は既知であるため、ＵＥはタイマ終了時間と、次の最も近いＣＧリソースの時間とを比較できる。この場合、ＢＳＲを送信するために次のＲＡオケージョン１９４０においてＲＡ手順１９５０が開始される。

図２０は代替的な実例を示し、ここでは上述のとおり、タイマ２０３０の動作中にＣＧリソース２６００が構成され、ＵＥはＣＧリソースを通じてＢＳＲを送信することとなる。ここでのＣＧ「を通じて」という用語は、ＣＧによって指定されるリソース（単数または複数）においてという意味である。図面にみられるとおり、ＣＧリソース周期２０１０は、タイマ２０３０が終了する前に終了する。

上記の図１８～２０および図２１に示されるとおり、ＲＡＣＨ手順が進行中であり、かつＣＧリソースが利用可能であるときに、ＵＥの挙動を指定することが望ましくてもよい。本明細書において、進行中のＲＡとは、たとえばＵＥがすでにＭｓｇＡ（プリアンブル）を送信しており、かつＵＥが（ＲＡＣＨ応答を含む）ＭｓｇＢを待っていることを意味する。図２１は、上述のタイマベースのアプローチのもたらし得る欠点および問題点を示す。特に、ＣＧ周期２１１０が２つのＲＡオケージョン間の周期よりも大きい。時間Ｔ１にＢＳＲがトリガされ、かつタイマ２１２０が開始される（トリガされる）。タイマ２１２０の実行中にＣＧが提供されないため、ＲＡ手順がトリガされる２１５０。しかし、ＲＡ手順はいくらか時間を取り、それはこの場合には期間２１７０である。ＲＡ手順の持続時間は競合解消の成功に依存しており、すなわちＭｓｇＢ（ランダムアクセス応答）はさまざまな時間に到着することがある。図２１に示されるとおり、ＲＡ手順の間（および場合によってはタイマ終了後）に、ＣＧリソース（単数または複数）が構成され得ることが起こるかもしれない。こうした場合には、ＣＧを使用する方が効率的であり得る。しかし、ＲＡをキャンセルすることは効率を低減させることがある。

なお、現在のＮＲに関する発展を鑑みて、上記の例は２ステップＲＡアプローチを示す。しかし、ＣＧが構成される（タイプ１またはタイプ２）間に４ステップのアプローチまたは任意のランダムアクセスアプローチも行うことも考えられる。さらに、ＲＡ手順に言及するときは、一般的なグラントフリーランダムアクセスを意味する。ＲＡＣＨ手順という用語は、ランダムアクセスチャネル手順を示す同じ意味で使用される。

図２１に示される状況においてＵＥの挙動を指定するために、たとえば図１９～２１に示されるタイマベースのアプローチなどにおいて、以下に説明される３つのオプションのいずれかが使用されてもよい。これらのオプションすべてにおいて、ＵＥは接続モード（ＲＲＣ＿ＣＯＮＮＥＣＴＥＤ）であってもよく、よってＮＴＮを通じた無線リンクを含むデータ無線ベアラが構成されてもよい。しかし、本開示はＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態に限定されない。当業者に認識されるとおり、ＣＧおよびＲＡ手順は、たとえばＲＲＣ＿ＩＮＡＣＴＩＶＥなどの他の状態に対しても同等に適用可能であってもよい。

オプション１によると、ＵＥは成功するまで、すなわちＢＳＲを送信するまでＲＡ手順を続ける。ＵＥは進行中のＲＡ手順をキャンセルすることができない。

こうしたアプローチの利点の１つは、リソース利用の効率である。不利であり得る点は、ＲＡＣＨ手順が競合ベースであるためにＢＳＲ送信を遅延させることがあり、よっていくらかの遅延をもたらし得ることである。

特にオプション１によると、通信デバイス（たとえばＵＥなど）はトランシーバおよび回路（上述の実施形態と同様）を含み、この回路は動作中に、通信デバイスにおける送信のために利用可能なデータを示すアップリンク制御情報を生成する。こうしたアップリンク制御情報はＢＳＲを含んでもよい。さらに、この回路は、時間領域における次のＲＡオケージョン（ＲＡリソース）の位置と、次のＣＧリソースの位置とを決定する。この通信デバイスは（例、たとえば基地局またはその他のネットワークエンティティなどのネットワークによって）設定グラントによって構成されており、すなわちたとえばＲＲＣまたはＰＤＣＣＨのいずれかなどを通じて過去にＣＧ構成を受信していることが想定される。設定グラントとは、通信デバイスがアップリンクでデータを送信するために使用できる周期的（または定期的）なリソースを意味する。設定グラントは、事前設定されたアップリンク制御情報送信の機会（オケージョン）として理解されてもよい。

時間領域における決定された次のＲＡオケージョン（ＲＡリソース）の位置と、次のＣＧリソースの位置との比較に基づいて、処理回路は、生成された制御情報を次のＲＡオケージョンにおいて送信するか、または次のＣＧリソースにおいて送信するかを選択する。この選択をどのように行うかはさまざまな可能性が存在し、本発明はそれらのうちのいずれか特定のものには限定されない。たとえば上述のとおり、（上述のＢＳＲトリガに対応する、アップリンク制御情報を生成した）現行時間に近い方のものが選択されてもよい。代替的に、もしＣＧが現行時間からの（例、タイマによって与えられる）特定の時間内に位置していれば、たとえより近いＲＡオケージョン（ＣＧリソースよりも近い）が存在しても、ＲＡオケージョンよりもＣＧの方が優先される（選択される）だろう。

ＲＡオケージョンが選択される場合、処理回路は、選択されたＲＡオケージョンにおいてＲＡを開始するように構成される。本開示はいずれかの特定のＲＡ手順に限定されず、いくつかの例示的実施形態においては上述の２ステップアプローチが使用されてもよい。しかし、他の手順が代替的に使用されてもよい。

オプション１において、一旦ＲＡオケージョンが選択されると、たとえＲＡ手順が（例、コリジョンのために）次のＣＧリソースよりも長くかかる場合であっても、アップリンク制御情報を送信するためにＲＡ手順が行われる。言い換えると、一旦ＲＡオケージョンが選択されると、選択されたＲＡオケージョンにおいて開始された手順によってアップリンク制御情報が送信される。ＲＡ手順は、通信デバイスの側からキャンセルすることができない。

したがって、スケジューリングデバイス（たとえばｇＮＢなど）はトランシーバを含み、このトランシーバは動作中に、ユーザ機器（ＵＥ）における送信のために利用可能なデータを示すアップリンク制御情報を受信し、このアップリンク制御情報はＲＡ手順内で受信される。スケジューリングデバイスは、（ＲＲＣまたはＰＤＣＣＨを介して）ＵＥに設定グラント構成を送信するようにさらに構成されてもよく、ここでトランシーバは動作中に、処理回路によって制御されるグラントを送信する。

オプション２によると、進行中のＲＡＣＨ手順の間にＣＧリソースが存在する場合、ＵＥは進行中のＲＡＣＨをキャンセルして、ＣＧリソースを通じてＢＳＲ送信を送る。

こうしたアプローチの利点の１つは、ＣＧリソースがそのＵＥ専用であるため、オプション１のようにＢＳＲ送信遅延が増加しないことである。しかし、オプション２のアプローチは、たとえば多数のＵＥが進行中の２ステップＲＡＣＨを途中でキャンセルしたときなどに、効率が低下するという欠点を有し得る。

特にオプション２によると、オプション１と同様に、通信デバイス（たとえばＵＥなど）はトランシーバおよび回路（上述の実施形態と同様）を含み、この回路は動作中に、通信デバイスにおける送信のために利用可能なデータを示すアップリンク制御情報を生成する。さらに、これもオプション１と同様に、この回路は、時間領域における次のＲＡオケージョンの位置と、次のＣＧリソースの位置とを決定する。さらにオプション１と同様に、時間領域における決定された次のＲＡオケージョン（ＲＡリソース）の位置と、次のＣＧリソースの位置との比較に基づいて、処理回路は、生成された制御情報を次のＲＡオケージョンにおいて送信するか、または次のＣＧリソースにおいて送信するかを選択する。

ＲＡオケージョンが選択される場合、処理回路は、選択されたＲＡオケージョンにおいてＲＡを開始するように構成される。

オプション１において、一旦ＲＡオケージョンが選択されると、ＲＡ手順はキャンセルされることなくアップリンク制御情報を送信するために実行される。これはオプション２に当てはまらない。代わりにオプション２において、処理回路は動作中に、進行中のＲＡ手順の間の時間領域にＣＧリソースが位置するか否かを決定する。ＣＧリソースが存在する場合、処理回路は動作中に、ＲＡ手順をキャンセルしてＣＧリソースを介してアップリンク制御情報を送信する。ＲＡ手順をキャンセルすることは、たとえば対応するプロトコルに従って行われる予定だったであろうＲＡ手順における上述のＭｓｇＡ送信またはその他の送信をキャンセルすることなどを含んでもよい。別の可能性は、ＵＥが、たとえばＲＡ手順の一部としてネットワーク（例、ｇＮＢ）から受信するＭｓｇＢまたはその他のメッセージのモニタリングなどのランダムアクセス応答のモニタリングを停止することである。言い換えると、ＵＥはＲＡ手順における任意のアクティビティを中止する。

したがって、スケジューリングデバイス（たとえばｇＮＢなど）はトランシーバを含み、このトランシーバは動作中に、ユーザ機器（ＵＥ）における送信のために利用可能なデータを示すアップリンク制御情報を受信し、このアップリンク制御情報はＲＡ手順内で受信されるか、または進行中のＲＡ手順の間の時間領域にＣＧリソースが位置する場合には、ＲＡ手順が進行中であるにもかかわらずＣＧリソース内で受信される。オプション１と同様に、スケジューリングデバイスは、ＵＥに設定グラント構成を送信するようにさらに構成されてもよく、ここでトランシーバは動作中に、処理回路によって制御されるグラントを送信する。

オプション３によると、ＵＥはネットワーク（例、ｇＮＢまたはその他のネットワークエンティティ）によって、ＲＡ手順（例、ＮＲの例における２ステップＲＡＣＨ手順）をキャンセルできるか否かを構成され得る。たとえば、ネットワークはＵＥのサービス要件に基づいて、ＵＥがＲＡ手順をキャンセルできるようにするか否かを決定できる。たとえば、遅延に敏感な（delay sensitive）サービスに対して、ネットワークは進行中の２ステップＲＡＣＨ手順のキャンセルを有効にできる。他方で、遅延に敏感でないサービスに対して、ネットワークは進行中の２ステップＲＡＣＨ手順のキャンセルを無効にできる。

オプション３の利点の１つは、ＵＥが自身のサービス要件に依存して進行中のＲＡＣＨ手順をキャンセルしてもよいことである。

オプション３の例示的な実装によると、ＲＡ手順のキャンセルの有効化／無効化の構成は、以下に示されるとおりのＲＲＣシグナリングによって行われる。

＜ＬｏｇｉｃａｌＣｈａｎｎｅｌＣｏｎｆｉｇ＞
論理チャネルパラメータを構成するためにＩＥ ＬｏｇｉｃａｌＣｈａｎｎｅｌＣｏｎｆｉｇが使用される。

上記のＲＲＣプロトコルのＡＳＮ．１構文は論理チャネル構成情報エレメントLogicalChannelConfigを示し、これはアップリンク固有パラメータul-SpecificParametersの中にインジケータAllowed2stepRACH-cancelled（上記の下線部）を含み、これはブールであってもよい。インジケータ（キャンセル有効化インジケータ）は、２つの値の一方を取ってもよい。たとえば、キャンセル有効化インジケータはキャンセルを無効化するために第１の値（たとえば０または偽）を取り、キャンセルを有効化するために第２の値（たとえば１または真）を取る。このＡＳＮ．１構文はさらに、上述のtraffic-type-differentiationを含んでもよい。一般的に、ＲＡおよびＣＧ送信機会の対処に関する本実施形態は、上述のトラフィックタイプの表示に関する実施形態および実施例と組み合わされてもよい。さらに、ここでの構文はＣＧ構成allowedCG-List-r16を含む。

上述のとおり、設定グラントを構成するために、ＲＲＣにこの情報エレメントまたはその他の情報エレメントまたはさらなる情報エレメントが含まれてもよい。

さらにこの例において、または一般的に、キャンセル有効化インジケータは論理チャネルごとに構成される。もしこのパラメータが真（上記の例における１）に設定されていれば、ＵＥは２ステップＲＡＣＨをキャンセルできる。こうした構成はネットワーク実装次第である。上述のとおり、ネットワークはＱｏＳ要件に基づいてこうした構成を決定できる。

たとえば、論理チャネルが遅延に敏感な要件を有するとき、ネットワークはこのパラメータを「真」に設定できる。同様に、論理チャネルが遅延耐性の要件を有するとき、ネットワークはこのパラメータを「偽」に設定できる。なお、オプション３はオプション１とオプション２との組み合わせに相当する。よってオプション３は適合の可能性を提供し、ＮＴＮ送信のために特に好適であり得る遅延とリソース効率とのトレードオフを達成してもよい。

特にオプション３によると、通信デバイス（たとえばＵＥなど）は、オプション１および２について上述したとおりのトランシーバおよび回路を含む。したがって、この回路は動作中に、通信デバイスにおいて送信のために利用可能なデータを示すアップリンク制御情報を生成する。さらに、この回路は、時間領域における次のＲＡオケージョンの位置と、次のＣＧリソースの位置とを決定する。

時間領域における決定された次のＲＡオケージョンの位置と、次のＣＧリソースの位置との比較に基づいて、処理回路は、生成された制御情報を次のＲＡオケージョンにおいて送信するか、または次のＣＧリソースにおいて送信するかを選択する。

ＲＡオケージョンが選択される場合、処理回路は、選択されたＲＡオケージョンにおいてＲＡを開始するように構成される。

オプション３において特定的に、この回路は、ネットワークノード（スケジューリングノード）からの構成メッセージをトランシーバを通じて受信するように構成される。構成メッセージは、ＲＡ手順の間にＣＧの機会が生じた場合に通信デバイスが進行中のＲＡ手順をキャンセルできるか否かを示すキャンセル有効化インジケータを含む。

キャンセル有効化インジケータが、通信デバイスは進行中のＲＡ手順をキャンセルできないことを示す場合、通信デバイスはオプション１と同様に挙動する。特に、一旦ＲＡオケージョンが選択されると、たとえＲＡ手順が次のＣＧリソースよりも長くかかる場合であっても、アップリンク制御情報を送信するためにＲＡ手順が行われる。

キャンセル有効化インジケータが、通信デバイスは進行中のＲＡ手順をキャンセルできないことを示す場合、通信デバイスはオプション１と同様に挙動する。特に、処理回路は動作中に、進行中のＲＡ手順の間の時間領域にＣＧリソースが位置するか否かを決定する。ＣＧリソースが存在する場合、処理回路は動作中に、ＲＡ手順をキャンセルしてＣＧリソースを介してアップリンク制御情報を送信する。

したがって、オプション１および２に記載されるとおり、オプション３のスケジューリングデバイス（たとえばｇＮＢなど）はトランシーバを含み、このトランシーバは動作中に、ユーザ機器（ＵＥ）における送信のために利用可能なデータを示すアップリンク制御情報を受信し、このアップリンク制御情報はＲＡ手順内で受信されるか、またはＣＧ手順内で受信される。スケジューリングデバイスは、（ＲＲＣまたはＰＤＣＣＨを介して）ＵＥに設定グラント構成を送信するようにさらに構成されてもよく、ここでトランシーバは動作中に、処理回路によって制御されるグラントを送信する。特定的にオプション３において、スケジューリングデバイス（ネットワークノード）の回路は、通信デバイスに対して、その通信デバイスが進行中のＲＡ手順をキャンセルすることを可能にするか否かを選択するようにさらに構成されてもよい。回路はさらに、通信デバイスに対して、それが進行中のＲＡ手順をキャンセルすることを可能にするか否かを指定するキャンセル有効化インジケータを生成して通信デバイスに送信するように構成されてもよい。

いくつかの例示的な実施形態において、回路は論理チャネルＩＤに基づいて選択を行い、キャンセル有効化インジケータは論理チャネルＩＤごとに構成されてスケジューリングノードから通信デバイスに送信される。特に、選択は、インジケータが構成される論理チャネルに関連する品質要件に基づいていてもよい。

＜ハードウェアおよびソフトウェアにおける例示的な実施形態および実装＞
本開示は、ソフトウェア、ハードウェア又はハードウェアと連動するソフトウェアによって実現することができる。上述した各実施例の説明に用いた各機能ブロックは、集積回路（ＩＣ）等のＬＳＩ（Ｌａｒｇｅ Ｓｃａｌｅ Ｉｎｔｅｇｒａｔｉｏｎ）によって部分的又は全体的に実現可能であり、各実施例で説明される各処理は、同一のＬＳＩ又はＬＳＩの組み合わせによって部分的又は全体的に制御されてもよい。ＬＳＩは、個別にチップとして形成されていてもよいし、あるいは、機能ブロックの一部又は全部を含むように１つのチップが形成されていてもよい。ＬＳＩは、それに結合されたデータ入出力を含んでもよい。ここで、ＬＳＩとは、集積度の違いにより、ＩＣ、システムＬＳＩ、スーパーＬＳＩ又はウルトラＬＳＩとして呼ばれうる。しかし、集積回路を実現する技術はＬＳＩに限定されず、専用回路、汎用プロセッサ又は特定用途向けプロセッサを用いて実現されてもよい。さらに、ＬＳＩ内部に配置される回路セルの接続及び設定が再設定可能なＬＳＩ又はリコンフィギュラブルプロセッサの製造後にプログラミング可能なＦＰＧＡ（Ｆｉｅｌｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ）が利用されてもよい。本開示は、デジタル処理又はアナログ処理として実現することができる。半導体技術や他の派生技術の進歩の結果として、将来の集積回路技術がＬＳＩに取って代わる場合、機能ブロックは、将来の集積回路技術を用いて集積化することができる。バイオテクノロジーも適用できる。

本開示は、通信装置と呼ばれる、通信機能を有する何れかのタイプの装置、デバイス又はシステムによって実現することができる。

通信装置は、送受信機及び処理／制御回路を有してもよい。送受信機は、受信機及び送信機を有し、及び／又は機能してもよい。送信機及び受信機としての送受信機は、増幅器、ＲＦ変調器／復調器など及び１つ以上のアンテナを含むＲＦ（Ｒａｄｉｏ Ｆｒｅｑｕｅｎｃｙ）モジュールを含んでもよい。

そのような通信装置のいくつかの非限定的な例は、電話機（例えば、携帯（セル）電話、スマートフォン）、タブレット、パーソナルコンピュータ（ＰＣ）（例えば、ラップトップ、デスクトップ、ネットブック）、カメラ（例えば、デジタルスチル／ビデオカメラ）、デジタルプレーヤ（デジタルオーディオ／ビデオプレーヤ）、ウェアラブルデバイス（例えば、ウェアラブルカメラ、スマートウォッチ、トラッキングデバイス）、ゲームコンソール、デジタルブックリーダ、遠隔ヘルス／遠隔医療（リモートヘルス及びリモート医療）デバイス、及び通信機能を提供する車両（例えば、自動車、飛行機、船舶）、並びにそれらの様々な組み合わせを含む。

通信装置は、携帯型又は可動型であることに限定されず、スマートホームデバイス（例えば、家電、ライティング、スマートメータ、制御パネル）、自動販売機及び“Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ（ＩｏＴ）”のネットワークにおける他の何れかの“物”など、非携帯型又は固定型である何れかのタイプの装置、デバイス又はシステムを含んでもよい。

通信は、例えば、セルラシステム、無線ＬＡＮシステム、衛星システムなど、及びそれらの様々な組み合わせを介してデータを交換することを含んでもよい。

通信装置は、本開示に記載された通信の機能を実行する通信デバイスに結合されたコントローラ又はセンサなどのデバイスを含んでもよい。例えば、通信装置は、通信装置の通信機能を実行する通信デバイスによって使用される制御信号又はデータ信号を生成するコントローラ又はセンサを含んでもよい。

通信装置はまた、基地局、アクセスポイントなどのインフラストラクチャファシリティと、上記の非限定的な例におけるものなどの装置と通信又は制御する他の何れかの装置、デバイス又はシステムを含んでもよい。

さらに、さまざまな実施形態がソフトウェアモジュールによって実現されてもよく、このソフトウェアモジュールはプロセッサによって実行されるか、またはハードウェアにおいて直接実行される。ソフトウェアモジュールとハードウェア実装との組み合わせも可能であってもよい。ソフトウェアモジュールは、たとえばＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、レジスタ、ハードディスク、ＣＤ－ＲＯＭ、ＤＶＤなどの任意の種類のコンピュータ可読記憶媒体に記憶されてもよい。さらに、異なる実施形態の個々の特徴が個別に、または任意の組み合わせで、別の実施形態の主題になり得ることに留意すべきである。

第１の実施形態によると、通信デバイス（装置）が提供され、この通信デバイス（装置）は回路を含み、この回路は動作中に、ユーザ機器（ＵＥ）である通信デバイスにおける送信のために利用可能なデータと、前記送信のために利用可能なデータは応答確認が有効化されたデータおよび応答確認が無効化されたデータの両方を含むこととを示すアップリンク制御情報を生成する。通信デバイスはトランシーバをさらに含み、このトランシーバは動作中に、生成されたアップリンク制御情報を送信する。

第２の実施形態によると、通信デバイス（装置）が提供され、この通信デバイス（装置）はトランシーバを含み、このトランシーバは動作中に、ユーザ機器（ＵＥ）において送信のために利用可能なデータと、前記送信のために利用可能なデータは応答確認が有効化されたデータおよび応答確認が無効化されたデータの両方を含むこととを示すアップリンク制御情報を受信し；この通信デバイス（装置）はさらに回路を含み、この回路は動作中に、アップリンク制御情報に従ってＵＥにおける前記送信のために利用可能なデータに対する少なくとも１つのグラントを提供し；このトランシーバは動作中に、提供された少なくとも１つのグラントを送信する。

第３の実施形態によると、第１または第２の実施形態のいずれかによる通信デバイスが提供され、ここでアップリンク制御情報は、送信のために利用可能なデータのうちの応答確認が有効化されたデータおよび／または応答確認が無効化されたデータの占有率と、送信のために利用可能なデータの総量とを指定する。

第４の実施形態によると、第１～第３の実施形態のいずれかによる通信デバイスが提供され、ここでアップリンク制御情報は、応答確認が有効化されたデータの第１の量と、応答確認が無効化されたデータの第２の量とを含む。

第５の実施形態によると、第１～第４の実施形態のいずれかによる通信デバイスが提供され、ここでアップリンク制御情報は、送信のために利用可能なデータのうちの応答確認が有効化されたデータの第１の優先順位および／または応答確認が無効化されたデータの第２の優先順位をさらに含み、この第１の優先順位は第２の優先順位と異なる。

第６の実施形態によると、第１～第５の実施形態のいずれかによる通信デバイスが提供され、ここでアップリンク制御情報はアップリンク制御情報インデックスを含み、アップリンク制御情報インデックスは送信のために利用可能なデータの量と応答確認有効化状態との組み合わせに関連付けられ、応答確認有効化状態は、送信のために利用可能なデータに対する応答確認が有効化されているか無効化されているか；および前記送信のために利用可能なデータが、応答確認が有効化されたデータおよび応答確認が無効化されたデータの両方を含むか否かのうちの少なくとも１つを示し得る。

第７の実施形態によると、第１～第６の実施形態のいずれかによる通信デバイスが提供され、ここで送信のために利用可能なデータは、論理チャネルグループのすべての論理チャネルに対して利用可能なデータであり；論理チャネルグループの各論理チャネルは、応答確認が有効化されたデータ、応答確認が無効化されたデータ、ならびに応答確認が有効化されたデータおよび応答確認が無効化されたデータのうちのいずれか１つを伝達するように構成可能である。

第８の実施形態によると、第１～第７の実施形態のいずれかによる通信デバイスが提供され、ここでアップリンク制御情報は媒体アクセス制御（ＭＡＣ）レイヤにおけるバッファ状態報告であり、それはＵＥにおいて送信のために利用可能なデータの量を示す。

第９の実施形態によると、第１～第８の実施形態のいずれかによる通信デバイスが提供され、ここでバッファ状態報告は、８ビットのサイズを有するショートバッファ状態報告であり、このショートバッファ状態報告は、前記送信のために利用可能なデータが応答確認が有効化されたデータおよび応答確認が無効化されたデータの両方を含むかどうかをシグナリングするための３ビット、およびＵＥによる送信のために利用可能なデータの量をシグナリングするための５ビット；または前記送信のために利用可能なデータが応答確認が有効化されたデータおよび応答確認が無効化されたデータの両方を含むかどうかをシグナリングするための３ビット、ＵＥによる送信のために利用可能なデータの量をシグナリングするための３ビット、および送信のために利用可能なデータの優先順位をシグナリングするための２ビット；または応答確認が有効化されたデータの量に対する４ビット、および応答確認が無効化されたデータの量に対する４ビットを含む。

第１０の実施形態によると、第１～第６の実施形態のいずれかによる通信デバイスが提供され、ここでアップリンク制御情報は、物理レイヤにおけるスケジューリング要求である。

第１１の実施形態によると、第１～第１０の実施形態のいずれかによる通信デバイスが提供され、ここでアップリンク制御情報は、超高信頼性低遅延通信（ｅＵＲＬＬＣ）および拡張モバイルブロードバンド（ｅＭＢＢ）の少なくとも一方を示し得るトラフィックタイプ表示を含む。

第１２の実施形態によると、第１の実施形態による通信デバイスが提供され、ここでトランシーバは動作中に、ＵＥにおける前記送信のために利用可能なデータに対する少なくとも１つのグラントを受信する。

第１３の実施形態によると、第２または第１２の実施形態による通信デバイスが提供され、ここで前記少なくとも１つのグラントは、応答確認が有効化されたデータに対する第１のグラントと、応答確認が無効化されたデータに対する第２のグラントとを含み、この第１のグラントおよび第２のグラントは、別々のダウンリンク制御情報メッセージによって伝達される。

第１４の実施形態によると、通信方法が提供され、この方法は、ユーザ機器（ＵＥ）によって実行される以下のステップ：ＵＥにおける送信のために利用可能なデータと、前記送信のために利用可能なデータは応答確認が有効化されたデータおよび応答確認が無効化されたデータの両方を含むこととを示すアップリンク制御情報を生成するステップ；および生成されたアップリンク制御情報を送信するステップを含む。

第１５の実施形態によると、通信方法が提供され、この方法は、基地局によって実行される以下のステップ：ユーザ機器（ＵＥ）における送信のために利用可能なデータと、前記送信のために利用可能なデータは応答確認が有効化されたデータおよび応答確認が無効化されたデータの両方を含むこととを示すアップリンク制御情報を受信するステップ；アップリンク制御情報に従ってＵＥにおける前記送信のために利用可能なデータに対する少なくとも１つのグラントを提供するステップ；および提供された少なくとも１つのグラントを送信するステップを含む。

第１６の実施形態によると、コンピュータプログラムが提供され、このコンピュータプログラムは、非一時的媒体に記憶され、処理回路（たとえば１つ以上のプロセッサなど）において実行されるときに第１４または第１５の実施形態のいずれかによる方法のすべてのステップを実行するプログラムコード命令を含む。

第１７の実施形態によると、先行する実施形態（第１～第１３の実施形態）のいずれかによる回路を埋め込んだ集積回路が提供される。

第１８の実施形態によると、上述のいずれかの方法のステップを実行するように構成された回路（集積型または分散型）が提供される。

特定の実施形態において示された本開示に対して多数の変更および／または修正が行われてもよいことを当業者は認識するだろう。したがって本実施形態はすべての点で例示的であり、限定的ではないと考えられるべきである。

Claims (15)

1. 通信デバイスであって、
   動作中に、
   － ユーザ機器（ＵＥ）である前記通信デバイスにおける送信のために利用可能なデータと、
   － 前記送信のために利用可能なデータは応答確認が有効化されたデータおよび応答確認が無効化されたデータの両方を含むことと、
   を示すアップリンク制御情報を生成する回路と、
   動作中に、生成された前記アップリンク制御情報を送信するトランシーバと、
   を含む、
   通信デバイス。
2. 通信デバイスであって、
   動作中に、
   － ユーザ機器（ＵＥ）における送信のために利用可能なデータと、
   － 前記送信のために利用可能なデータは応答確認が有効化されたデータおよび応答確認が無効化されたデータの両方を含むことと、
   を示すアップリンク制御情報を受信するトランシーバと、
   動作中に、前記アップリンク制御情報に従って前記ＵＥにおける前記送信のために利用可能なデータに対する少なくとも１つのグラントを提供する回路と、
   を含み、
   前記トランシーバが動作中に、提供された前記少なくとも１つのグラントを送信する、
   通信デバイス。
3. アップリンク制御情報が、
   前記送信のために利用可能なデータにおける、前記応答確認が有効化されたデータおよび／または前記応答確認が無効化されたデータの占有率と、
   前記送信のために利用可能なデータの総量と、
   を指定する、
   請求項１または２に記載の通信デバイス。
4. アップリンク制御情報が、
   前記応答確認が有効化されたデータの第１の量と、
   前記応答確認が無効化されたデータの第２の量と、
   を含む、
   請求項１または２に記載の通信デバイス。
5. 前記アップリンク制御情報が、前記送信のために利用可能なデータのうちの前記応答確認が有効化されたデータの第１の優先順位および／または前記応答確認が無効化されたデータの第２の優先順位をさらに含み、前記第１の優先順位は前記第２の優先順位と異なる、
   請求項１～４のいずれか一項に記載の通信デバイス。
6. 前記アップリンク制御情報がアップリンク制御情報インデックスを含み、
   前記アップリンク制御情報インデックスが、前記送信のために利用可能なデータの量と、応答確認有効化状態との組み合わせに関連付けられ、
   前記応答確認有効化状態が、
   － 前記送信のために利用可能なデータに対する応答確認が有効化されているか無効化されているか、および
   － 前記送信のために利用可能なデータが、応答確認が有効化されたデータおよび応答確認が無効化されたデータの両方を含むか否か、
   のうちの少なくとも１つを示し得る、
   請求項１～５のいずれか一項に記載の通信デバイス。
7. 前記送信のために利用可能なデータが、論理チャネルグループのすべての論理チャネルに対して利用可能なデータであり、
   前記論理チャネルグループの各論理チャネルが、
   － 応答確認が有効化されたデータと、
   － 応答確認が無効化されたデータと、
   － 応答確認が有効化されたデータおよび応答確認が無効化されたデータと、
   のうちのいずれか１つを伝達するように構成可能である、
   請求項１～６のいずれか一項に記載の通信デバイス。
8. 前記アップリンク制御情報が媒体アクセス制御（ＭＡＣ）レイヤにおけるバッファ状態報告であり、前記ＵＥにおける前記送信のために利用可能なデータの量を示す、
   請求項１～７のいずれか一項に記載の通信デバイス。
9. 前記バッファ状態報告が８ビットのサイズを有するショートバッファ状態報告であり、前記ショートバッファ状態報告が、
   － 前記送信のために利用可能なデータが応答確認が有効化されたデータおよび応答確認が無効化されたデータの両方を含むかどうかをシグナリングするための３ビット、および前記ＵＥによる前記送信のために利用可能なデータの量をシグナリングするための５ビット；または
   － 前記送信のために利用可能なデータが応答確認が有効化されたデータおよび応答確認が無効化されたデータの両方を含むかどうかをシグナリングするための３ビット、前記ＵＥによる前記送信のために利用可能なデータの量をシグナリングするための３ビット、および前記送信のために利用可能なデータの優先順位をシグナリングするための２ビット；または
   － 前記応答確認が有効化されたデータの量に対する４ビット、および前記応答確認が無効化されたデータの量に対する４ビット、
   を含む、
   請求項８に記載の通信デバイス。
10. 前記アップリンク制御情報が、物理レイヤにおけるスケジューリング要求である、
    請求項１～６のいずれか一項に記載の通信デバイス。
11. 前記アップリンク制御情報が、超高信頼性低遅延通信（ｅＵＲＬＬＣ）および拡張モバイルブロードバンド（ｅＭＢＢ）の少なくとも一方を示し得るトラフィックタイプ表示を含む、
    請求項１～１０のいずれか一項に記載の通信デバイス。
12. 前記トランシーバが動作中に、前記ＵＥにおける前記送信のために利用可能なデータに対する少なくとも１つのグラントを受信する、
    請求項１に記載の通信デバイス。
13. 前記少なくとも１つのグラントが、前記応答確認が有効化されたデータに対する第１のグラントと、前記応答確認が無効化されたデータに対する第２のグラントとを含み、
    前記第１のグラントおよび前記第２のグラントが別々のダウンリンク制御情報メッセージによって伝達される、
    請求項２または請求項１２に記載の通信デバイス。
14. ユーザ機器（ＵＥ）によって実行される以下のステップ：
    － 前記ＵＥにおける送信のために利用可能なデータと、
    － 前記送信のために利用可能なデータが応答確認が有効化されたデータおよび応答確認が無効化されたデータの両方を含むことと、
    を示すアップリンク制御情報を生成するステップと、
    生成された前記アップリンク制御情報を送信するステップと、
    を含む、通信方法。
15. 基地局によって実行される以下のステップ：
    － ユーザ機器（ＵＥ）における送信のために利用可能なデータと、
    － 前記送信のために利用可能なデータは応答確認が有効化されたデータおよび応答確認が無効化されたデータの両方を含むことと、
    を示すアップリンク制御情報を受信するステップと、
    前記アップリンク制御情報に従って前記ＵＥにおける前記送信のために利用可能なデータに対する少なくとも１つのグラントを提供するステップと、
    提供された前記少なくとも１つのグラントを送信するステップと、
    を含む、通信方法。

Images