JP2023514146A - トランスポートブロックサイズの制約を適用した、ランダムアクセス時の小容量データ送信のための通信装置およびネットワークノード - Google Patents

トランスポートブロックサイズの制約を適用した、ランダムアクセス時の小容量データ送信のための通信装置およびネットワークノード Download PDF

Info

Publication number
JP2023514146A
JP2023514146A JP2022547927A JP2022547927A JP2023514146A JP 2023514146 A JP2023514146 A JP 2023514146A JP 2022547927 A JP2022547927 A JP 2022547927A JP 2022547927 A JP2022547927 A JP 2022547927A JP 2023514146 A JP2023514146 A JP 2023514146A
Authority
JP
Japan
Prior art keywords
size
random access
access procedure
logical channel
procedure type
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
Application number
JP2022547927A
Other languages
English (en)
Inventor
リキン シャー
ミン－フン タオ
秀俊 鈴木
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Panasonic Intellectual Property Corp of America
Original Assignee
Panasonic Intellectual Property Corp of America
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Panasonic Intellectual Property Corp of America filed Critical Panasonic Intellectual Property Corp of America
Publication of JP2023514146A publication Critical patent/JP2023514146A/ja
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W74/00—Wireless channel access
    • H04W74/08—Non-scheduled access, e.g. ALOHA
    • H04W74/0833—Random access procedures, e.g. with 4-step access
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/50—Allocation or scheduling criteria for wireless resources
    • H04W72/53—Allocation or scheduling criteria for wireless resources based on regulatory allocation policies
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W74/00—Wireless channel access
    • H04W74/002—Transmission of channel access control information
    • H04W74/006—Transmission of channel access control information in the downlink, i.e. towards the terminal

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (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）の利用シナリオを示す概略図 非ローミングシナリオのための５Ｇシステムアーキテクチャの一例を示すブロック図 ＵＥをＲＲＣ＿ＩＮＡＣＴＩＶＥ状態からＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態に移行させる手順を示す図 上りリンクデータ送信の４段階ランダムアクセス手順を示す図 上りリンクデータ送信の２段階ランダムアクセス手順を示す図 ネットワークノードと通信装置のブロック図 ネットワーク通信装置回路を示すブロック図 通信ネットワークとネットワークノードの通信方法を示すフローチャート 通信装置の通信方法を示すフローチャート 通信装置の通信方法を示すフローチャート 通信装置の通信方法を示すフローチャート ネットワークノードの通信方法を示すフローチャート 通信装置の通信方法を示すフローチャート
＜５Ｇ ＮＲシステムアーキテクチャ及びプロトコルスタック＞
３ＧＰＰは、１００ＧＨｚまでの周波数範囲で動作する新無線アクセス技術（ＮＲ）の開発を含む、第５世代セルラ技術（単純に５Ｇともいう）の次期リリースに取り組んでいる。２０１７年末に５Ｇ規格の初版が完成し、５Ｇ ＮＲ規格に準拠したスマートフォンの試行及び商用展開を進めることができた。
特に、全体的なシステムアーキテクチャは、ｇＮＢ（gNodeB）を備えるＮＧ－ＲＡＮ（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）データレートに対応することが求められる。一方、ＵＲＬＬＣでは、より厳しい要件が超低遅延（ユーザプレーンの遅延はＵＬ、ＤＬともに０．５ｍｓ）と高信頼性（１ｍｓ以内に１－１０－５）について課されている。最後に、ｍＭＴＣには、好ましくは、高い接続密度（都市環境では１平方キロメートルあたり１００万台）、悪環境での広いカバレッジ、低コスト機器の超長寿命バッテリー（１５年）が求められる。
したがって、一つのユースケースに適したＯＦＤＭヌメロロジー（例えば、サブキャリア間隔、ＯＦＤＭシンボル長、巡回プレフィクス（ＣＰ）長、スケジューリング間隔あたりのシンボル数）は、他のユースケースには有効でない場合がある。例えば、低遅延サービスは、好ましくは、ｍＭＴＣサービスよりも短いシンボル長（したがって、より大きなサブキャリア間隔）および／またはスケジューリング区間（換言すると、ＴＴＩ）毎のシンボル数が少ないことが求められうる。さらに、チャネルの遅延スプレッドが大きい展開シナリオでは、好ましくは、遅延スプレッドが短いシナリオよりもＣＰ長が長いことが求められうる。同様のＣＰオーバーヘッドを維持するためには、サブキャリア間隔は適宜最適化される必要がある。ＮＲでは、複数の値のサブキャリア間隔をサポートしてもよい。これに対応して、現時点では１５ｋＨｚ、３０ｋＨｚ、６０ｋＨｚ、…、のサブキャリア間隔が検討されている。シンボル長Ｔｕとサブキャリア間隔Δｆは、式Δｆ＝１／Ｔｕによって直接関係づけられる。ＬＴＥシステムと同様、「リソースエレメント」という用語は、１つのＯＦＤＭ／ＳＣ－ＦＤＭＡシンボルの長さに対する一つのサブキャリアで構成される最小のリソース単位を示すのに使用することができる。
新無線システム５Ｇ－ＮＲでは、ヌメロロジーとキャリアごとに、サブキャリアとＯＦＤＭシンボルのリソースグリッドが、上りリンクと下りリンクそれぞれに対して定義される。リソースグリッドにおける各エレメントは、リソースエレメントと呼ばれ、周波数領域における周波数インデックスと時間領域におけるシンボル位置とに基づいて識別される（３ＧＰＰ ＴＳ ３８．２１１ ｖ１５．６．０参照）。
＜ＮＧ－ＲＡＮと５ＧＣとの間の機能分割＞
図２は、ＮＧ－ＲＡＮと５ＧＣとの間の機能分割を示す。ＮＧ－ＲＡＮ論理ノードは、ｇＮＢ又はｎｇ－ｅＮＢ（next generation eNB）である。５ＧＣには、ＡＭＦ、ＵＰＦ、およびＳＭＦの論理ノードが含まれる。
ｇＮＢ及びｎｇ－ｅＮＢは、具体的に、以下の主要な機能を提供する。
・無線ベアラ制御、無線アドミッション制御、接続モビリティ制御、上りリンクおよび下りリンクの双方におけるＵＥへの動的なリソース割り当て（スケジューリング）等の、無線リソース管理機能
・データのＩＰヘッダ圧縮、暗号化、及び完全性保護
・ＵＥから提供された情報からＡＭＦへのルーティングが決定できない場合のＵＥアタッチ時のＡＭＦ選択
・ＵＰＦに向けたユーザプレーンデータのルーティング
・ＡＭＦに向けた制御プレーン情報のルーティング
・接続の設定と解除
・ページングメッセージのスケジューリングと送信
・（ＡＭＦ又はＯＡＭから発信される）システム報知情報のスケジューリングと送信
・モビリティとスケジューリングのための測定および測定報告設定
・上りリンクにおけるトランスポートレベルのパケットマーキング
・セッション管理
・ネットワークスライシングのサポート
・ＱｏＳフロー管理とデータ無線ベアラへの配置
・ＲＲＣ＿ＩＮＡＣＴＩＶＥ状態のＵＥのサポート
・ＮＡＳメッセージの配信機能
・無線アクセスネットワークシェアリング
・デュアルコネクティビティ
・ＮＲとＥ－ＵＴＲＡとの間の緊密な連携
アクセス・モビリティ管理機能（ＡＭＦ）は、以下の主要な機能を提供する。
・非アクセス層（ＮＡＳ：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）が１Ｅ－５であることである。
物理レイヤの観点から、信頼性を向上させるには様々な方法がある。現在、信頼性を向上させるためには、ＵＲＬＬＣ用の独立したＣＱＩテーブル、よりコンパクトなＤＣＩ（downlink control information）フォーマット、ＰＤＣＣＨの繰り返し等を定義することが考えられる。しかし、ＮＲが（ＮＲ ＵＲＬＣの主要要件に対して）より安定し、かつより発展するにつれて、超高信頼性を達成するために考えられる方法の範囲は広がり得る。リリース１５におけるＮＲ ＵＲＬＬＣ特有のユースケースには、拡張現実／仮想現実（ＡＲ／ＶＲ）、ｅ－ヘルス、ｅ－セーフティ、及びミッションクリティカルアプリケーションが含まれる。
また、ＮＲ ＵＲＬＬＣが目標とする技術強化は、遅延の改善と信頼性の向上である。遅延改善のための技術強化には、設定可能なヌメロロジー、フレキシブルなマッピングによる非スロットベースのスケジューリング、グラントフリーの（設定されたグラントの）上りリンク、データチャネルのスロットレベルの繰り返し、および下りリンクのプリエンプション（pre-emption）が含まれる。プリエンプションとは、すでにリソースが割り当てられている送信を停止し、すでに割り当てられている当該リソースを、後から要求された、より少ない遅延や高い優先度を必要とする別の送信に使用することを意味する。したがって、すでに許可されていた送信は、後の送信によって差し替えられる。プリエンプションは、特定のサービスタイプとは無関係に適用できる。例えば、サービスタイプＡ（ＵＲＬＬＣ）の送信は、サービスタイプＢ（例えばｅＭＢＢ）の送信によってプリエンプトされてよい。信頼性向上に関する技術強化には、目標ＢＬＥＲ １Ｅ－５のための専用ＣＱＩ／ＭＣＳテーブルが含まれる。
ｍＭＴＣ（多数同時接続）のユースケースの特徴は、典型的には遅延の影響を受けにくい比較的少量のデータを送信する接続装置の数が極めて多いことである。デバイスは低コストで、非常に長いバッテリー寿命を持つことが要求される。ＮＲの観点からは、非常に狭い帯域幅部分を利用することが、ＵＥにとっての省電力化と、バッテリーの長寿命化を可能にする一つの策である。
上述のように、ＮＲにおける信頼性向上の範囲はより広くなることが予想される。あらゆるケースに共通する重要な要件の一つであり、特にＵＲＬＬＣとｍＭＴＣに必要な要件は、高信頼性または超高信頼性である。信頼性を向上させるには、無線の観点やネットワークの観点から、いくつかのメカニズムが考えられる。一般的に、信頼性の向上に役立ついくつかの重要な領域がある。これらの領域には、コンパクトな制御チャネル情報、データ／制御チャネルの繰り返し、周波数領域、時間領域、空間領域におけるダイバーシティなどがある。これらの領域は、特定の通信シナリオに関わらず、一般的に、信頼性向上に適用可能である。
ＮＲ ＵＲＬＬＣについては、ファクトリーオートメーション、輸送産業、配電など、より厳しい要件を持つさらなるユースケースが特定されている。より厳しい要件とは、ユースケースに応じた、高い信頼性（最大１０－６レベル）、高いアベイラビリティ、最大２５６バイトのパケットサイズ、数μｓ程度までの時刻同期（周波数範囲および０．５～１ｍｓ程度の短い遅延（例えば、目標とするユーザプレーンでの０．５ｍｓの遅延）に応じて１μｓまたは数μｓとすることができる）である。
さらに、ＮＲ ＵＲＬＬＣでは、物理レイヤの観点からいくつかの技術強化が確認されている。これらの中には、コンパクトなＤＣＩに関するＰＤＣＣＨ（Physical Downlink Control Channel）の強化、ＰＤＣＣＨの繰り返し、ＰＤＣＣＨのモニタリングの増加がある。また、上りリンク制御情報（ＵＣＩ：Uplink Control Information）の強化は、拡張ＨＡＲＱ（Hybrid Automatic Repeat Request）とＣＳＩフィードバックの強化に関係する。また、ミニスロットレベルのホッピングに関連するＰＵＳＣＨの強化や再送／繰り返しの強化も確認されている。「ミニスロット」とは、スロット（１４シンボルで構成されるスロット）よりも少ない数のシンボルを含む送信時間間隔（ＴＴＩ）を表す。
スロットベースのスケジューリングや割り当てでは、スロットはスケジューリング割り当てのタイミングの粒度（ＴＴＩ：transmission time interval）に対応する。一般的に、ＴＴＩはスケジューリング割り当てのタイミングの粒度を決定する。一つのＴＴＩは信号が物理レイヤに配置される時間間隔である。例えば、ＴＴＩ長は従来１４シンボル（スロットベースのスケジューリング）から２シンボル（非スロットベースのスケジューリング）の範囲でよい。下りリンク（ＤＬ：downlink）および上り（ＵＬ：uplink）リンク送信は、１０サブフレーム（持続時間１ｍｓ）からなるフレーム（持続時間１０ｍｓ）に編成されることが規定される。スロットベースの送信では、サブフレームはさらにスロットに分割され、そのスロット数はヌメロロジーやサブキャリア間隔によって規定される。規定される値は、サブキャリア間隔１５ｋＨｚの場合の１フレームあたり１０スロット（１サブフレームあたり１スロット）から、サブキャリア間隔１２０ｋＨｚの場合の１フレームあたり８０スロット（１サブフレームあたり８スロット）に渡る。１スロットあたりのＯＦＤＭシンボル数は、通常の巡回プレフィックスの場合は１４、拡張した巡回プレフィックスの場合は１２である（３ＧＰＰ ＴＳ ３８．２１１ Ｖ１５．３．０，Ｐｈｙｓｉｃａｌ ｃｈａｎｎｅｌｓ ａｎｄ ｍｏｄｕｌａｔｉｏｎ，２０１８－０９のセクション４．１（ｇｅｎｅｒａｌ ｆｒａｍｅ ｓｔｒｕｃｔｕｒｅ），４．２（Ｎｕｍｅｒｏｌｏｇｉｅｓ），４．３．１（ｆｒａｍｅｓ ａｎｄ ｓｕｂｆｒａｍｅｓ）参照）。しかしながら、送信のための時間リソース割り当ては非スロットベースでもよい。特に、非スロットベース割り当てのＴＴＩは、スロットではなくミニスロットに対応する。つまり、一つ以上のミニスロットが要求されたデータ／制御シグナリングの送信に割り当てられる。非スロットベースの割り当てでは、最小のＴＴＩ長は、例えば１または２ＯＦＤＭシンボルでよい。
＜ＱｏＳの制御＞
５ＧのＱｏＳ（Quality of Service）モデルは、ＱｏＳフローに基づいており、保証されたフロービットレートが求められるＱｏＳフロー（ＧＢＲ ＱｏＳフロー）と、保証されたフロービットレートが求められないＱｏＳフロー（非ＧＢＲ ＱｏＳフロー）の両方に対応している。そのため、ＮＡＳレベルでは、ＱｏＳフローはＰＤＵセッションにおける最も微細な粒度のＱｏＳの区分である。ＱｏＳフローは、ＮＧ－Ｕインタフェースを介してカプセル化ヘッダにおいて搬送されるＱｏＳフローＩＤ（ＱＦＩ）によってＰＤＵセッション内で識別される。
各ＵＥに対して、５ＧＣは、１つまたは複数のＰＤＵセッションを確立する。各ＵＥに対して、ＮＧ－ＲＡＮは、ＰＤＵセッションに合わせて少なくとも一つのデータ無線ベアラ（ＤＲＢ）を確立し、そのＰＤＵセッションのＱｏＳフローに対する追加のＤＲＢは、例えば、図３を参照して上述したように、後から設定可能である（いつ設定するかはＮＧ－ＲＡＮ次第である）。ＮＧ－ＲＡＮは、異なるＰＤＵセッションに属するパケットを異なるＤＲＢに配置する。ＵＥと５ＧＣにおけるＮＡＳレベルパケットフィルタは、ＵＬパケットとＤＬのパケットとをＱｏＳフローに関連付けるのに対し、ＵＥとＮＧ－ＲＡＮのＡＳレベルマッピングルールは、ＵＬのＱｏＳフローとＤＬのＱｏＳフローとをＤＲＢに関連付ける。
図５は、５Ｇ ＮＲの非ローミング参照アーキテクチャを示す（ＴＳ ２３．５０１ ｖ１６．１．０、セクション４．２３参照）。図４に例示される、５Ｇサービスをホストする外部アプリケーションサーバなどのアプリケーション機能（ＡＦ）は、サービスを提供するために３ＧＰＰコアネットワークとやり取りを行う。例えば、トラフィックルーティングに影響を与えるアプリケーションをサポートするためにネットワーク公開機能（ＮＥＦ：Network Exposure Function）にアクセスすること、ＱｏＳ制御などのポリシー制御のためにポリシーフレームワークとやり取りすること（ポリシー制御機能（ＰＣＦ）参照）が挙げられる。オペレータによる配備に基づき、オペレータから信頼されているとみなされるアプリケーション機能は、関連するネットワーク機能と直接やり取りすることができる。ネットワーク機能への直接のアクセスをオペレータから許可されていないアプリケーション機能は、ＮＥＦを介して外部に対する開放フレームワークを使用して、関連するネットワーク機能とやり取りする。
図５は、５Ｇアーキテクチャのさらなる機能ユニット、すなわち、ネットワークスライス選択機能（ＮＳＳＦ：Network Slice Selection Function）、ネットワークリポジトリ機能（ＮＲＦ：Network Repository Function）、統合データ管理（ＵＤＭ：Unified Data Management）、認証サーバー機能（ＡＵＳＦ：Authentication Server Function）、アクセス・モビリティ管理機能（ＡＭＦ）、セッション管理機能（ＳＭＦ）、及びデータネットワーク（ＤＮ）（オペレータによるサービス、インターネットアクセス、サードパーティによるサービス等）を示している。すべて又は一部のコアネットワーク機能及びアプリケーションサービスは、クラウドコンピューティング環境上に展開されかつ動作してもよい。
したがって、本開示では、ＱｏＳ要件に応じたｇＮｏｄｅＢとＵＥとの間の無線ベアラを含むＰＤＵセッションを確立するために、動作時に、ＵＲＬＬＣ、ｅＭＢＢ、およびｍＭＴＣサービスのうちの少なくとも一つに対するＱｏＳ要件を含む要求を、５ＧＣの機能（例えば、ＮＥＦ、ＡＭＦ、ＳＭＦ、ＰＣＦ、ＵＰＦ等）の少なくとも一つに送信する送信部と、動作時に、確立されたＰＤＵセッションを使用してサービスを実行する制御回路と、を備えるアプリケーションサーバ（例えば、５ＧアーキテクチャのＡＦ）が提供される。
端末は、ＬＴＥやＮＲでは、ＵＥ（Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ）と呼ばれる。これは、ユーザ機器の機能を有する無線電話機、スマートフォン、タブレット端末、ＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）スティックといったモバイル機器や通信装置であってよい。ただし、モバイル機器という用語はこれに限定されず、一般に、中継器もこのようなモバイル機器の機能を有していてもよく、モバイル機器が中継器として機能してもよい。
基地局は、ネットワークノードまたはスケジューリングノードであり、例えば、端末にサービスを提供するためのネットワークの一部を形成している。基地局は、端末に無線アクセスを提供するネットワークノードである。
＜ＲＲＣの状態＞
ＮＲを含む無線通信システムにおいて、デバイス（例えば、ＵＥ）はトラフィックアクティビティによって異なる状態になり得る。ＮＲにおいて、デバイスはＲＲＣ＿ＩＤＬＥ、ＲＲＣ＿ＡＣＴＩＶＥ、およびＲＲＣ＿ＩＮＡＣＴＩＶＥの三つのＲＲＣ状態のうちの一つになり得る。最初の二つのＲＲＣ状態（ＲＲＣ＿ＩＤＬＥおよびＲＲＣ＿ＡＣＴＩＶＥ）は、ＬＴＥにおいて対応するものと同様であり、ＲＲＣ＿ＩＮＡＣＴＩＶＥはＮＲにおいて新しく導入されたもので元々のＬＴＥの設計においては存在しない。また、ＣＮ＿ＩＤＬＥおよびＣＮ＿ＣＯＮＮＥＣＴＥＤといったコアネットワーク状態もあり、これはデバイスがコアネットワークとの接続を確立したかどうかによる。
ＲＲＣ＿ＩＤＬＥでは、ＲＲＣコンテキスト、すなわち、デバイスとネットワークとの間の通信に必要なパラメータは、無線アクセスネットワークに存在せず、デバイスは、特定のセルに属さない。コアネットワークの観点からは、そのデバイスはＣＮ＿ＩＤＬＥ状態にある。デバイスがバッテリー消費を低減するためにほとんどの時間をスリープするため、データ転送は行われなくてもよい。下りリンクでは、アイドル状態にあるデバイスは、ネットワークからページングメッセージがある場合、それを受信するために周期的にウェイクアップする。モビリティは、セル再選択を通じてデバイスによって処理される。上りリンク同期は維持されず、したがって、行われ得る唯一の上りリンク送信アクティビティは、ランダムアクセスであり、接続状態へ移行する。接続状態への移行の一環として、ＲＲＣコンテキストは、デバイスおよびネットワークの両方において確立される。
ＲＲＣ＿ＣＯＮＮＥＣＴＥＤでは、ＲＲＣコンテキストが確立され、デバイスと無線アクセスネットワークとの間の通信に必要なすべてのパラメータが両方のエンティティにおいて既知である。コアネットワークの観点からは、デバイスはＣＮ＿ＣＯＮＮＥＣＴＥＤ状態にある。デバイスが属するセルは既知であり、デバイスとネットワークとの間のシグナリングのために使用されるデバイスの識別情報（Ｃ－ＲＮＴＩ：Cell Radio-Network Temporary Identifier）が設定されている。接続状態は、デバイスとの間のデータ転送を目的としているが、デバイスの消費電力を低減するために不連続受信（ＤＲＸ：discontinuous reception）を設定することができる。接続状態においてｇＮＢにはＲＲＣコンテキストが確立されているので、ＤＲＸを止めてデータの送受信を開始することは、その関連するシグナリングとの接続設定が必要とされないため、比較的速い。モビリティは、無線アクセスネットワークによって管理される。すなわち、デバイスは、関連する場合にハンドオーバを実行するようデバイスに指令を出すネットワークに、隣接セルの測定値を提供する。上りリンクのタイムアライメントは、存在しても存在しなくてもよいが、データ送信が行われるためにランダムアクセスを使用して確立され、維持される必要がある。
ＬＴＥでは、アイドル状態および接続状態のみがサポートされる。実際には、一般的に、アイドル状態はデバイスの電力消費を低減するための一次スリープ状態として使用される。しかしながら、多くのスマートフォンアプリケーションにおいて小さなパケットの頻繁な送信は一般的であるため、結果として、コアネットワークにおいてアイドルからアクティブへの相当量の移行が生じる。これらの移行は、シグナリング負荷および関連する遅延の点で犠牲を伴う。したがって、シグナリング負荷の低減、および一般的に遅延の低減のため、ＮＲでは第三の状態が定義され、それがＲＲＣ＿ＩＮＡＣＴＩＶＥ状態である。
ＲＲＣ＿ＩＮＡＣＴＩＶＥでは、ＲＲＣコンテキストは、デバイスとｇＮＢの両方で保持される。また、コアネットワーク接続も維持される。つまり、デバイスはコアネットワークの観点からＣＮ＿ＣＯＮＮＥＣＴＥＤにある。したがって、データ転送のための接続状態への移行は高速で行われる。コアネットワークのシグナリングは不要である。ＲＲＣコンテキストは、ネットワーク内にすでに実行されており、アイドルからアクティブへの移行は、無線アクセスネットワーク内で処理することができる。同時に、デバイスは、アイドル状態と同様の方法でスリープすることができ、モビリティは、セル再選択を通じて、すなわち、ネットワークの関与なしに処理される。したがって、通信装置またはデバイスのモビリティは、ネットワーク制御ではなくデバイス制御であり、通信装置は、ランダムアクセスを介してネットワークに接触することができる。したがって、ＲＲＣ＿ＩＮＡＣＴＩＶＥは、アイドル状態と接続状態の混合とみなされることができる（詳細については、Ｅ． Ｄａｈｌｍａｎら、５ＧＮＲ：Ｔｈｅ Ｎｅｘｔ Ｇｅｎｅｒａｔｉｏｎ Ｗｉｒｅｌｅｓｓ Ａｃｃｅｓｓ Ｔｅｃｈｎｏｌｏｇｙ、第一版、セクション６．５．１から６．５．３参照）。
上述のように、ＮＲは、ＲＲＣ＿ＩＮＡＣＴＩＶＥ状態をサポートする。データ送信の頻度が低い（周期的および／または非周期的な）ＵＥは、一般的に、ネットワークによって ＲＲＣ＿ＩＮＡＣＴＩＶＥ状態に維持される。
ＮＲリリース１６まで、ＲＲＣ＿ＩＮＡＣＴＩＶＥ状態は、データ送信をサポートしていない。したがって、どんなＵＬデータ送信でも、ＵＥは、ＲＲＣ＿ＩＮＡＣＴＩＶＥ状態からＲＲＣ＿ＣＯＮＮＲＣＴＥＤ状態に移行しなければならない。ＵＥをＲＲＣ＿ＩＮＡＣＴＩＶＥからＲＲＣ＿ＣＯＮＮＲＣＴＥＤに移行させるためにＵＥとｇＮＢとの間で交換される一連のメッセージは、図６に示されるように、以下のメッセージ１～５を含む。
（１）Ｍｓｇ１：ＰＲＡＣＨ（Ｐｈｙｓｉｃａｌ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｃｈａｎｎｅｌ）
（２）Ｍｓｇ２：ＲＡＲ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｒｅｓｐｏｎｓｅ）
（３）Ｍｓｇ３：ＲＲＣ再開要求
（４）Ｍｓｇ４：ＲＲＣ再開
（５）Ｍｓｇ５：ＵＬデータに使用されてよい
つまり、ＵＬ送信およびＲＲＣ＿ＩＮＡＣＴＩＶＥからＲＲＣ＿ＣＯＮＮＥＣＴＥＤへの要求される移行は、五つ以上のメッセージを必要とするため、余計な電力消費、遅延の増加、およびシグナリングのオーバーヘッドが起こり得る。
したがって、ＵＥがＵＥの状態を変更することなくＵＬの小容量データを送信することが可能な、小容量データ送信の許容が考慮され得る。ＮＲの小容量データ送信におけるオブジェクトは、二段階ＲＡＣＨ（ＲＡＣＨ（random access channel）手順またはランダムアクセス手順）および四段階ＲＡＣＨなどのＲＡＣＨベースの方式のためのＵＬ小容量データ送信を含む。小容量データ送信に関する作業は、ＲＣＣ＿ＩＮＡＣＴＩＶＥ状態（例えば、ＭｓｇＡまたはＭｓｇ３を使用）から小容量データパケットのユーザプレーンデータ送信を可能にするための一般的な手順を提供すること、ならびにＵＬにおけるユーザプレーンデータ送信をサポートし得る、リリース１６のＣＣＣＨ（common control channel）メッセージサイズよりも大きい柔軟なペイロードサイズを可能にすることを含んでよい（実際のペイロードサイズは、ネットワークの構成次第でよい）。小容量データ送信に関する作業は、ＲＡＣＨベースのアプローチのためのＲＲＣ＿ＩＮＡＣＴＩＶＥ状態におけるコンテキストフェッチおよびデータ転送（アンカー再配置を伴うまたは伴わない）をさらに含んでよい。
上述の四段階ランダムアクセス手順（または「四段階ＲＡＣＨ」）および二段階ランダムアクセス手順（または「二段階ＲＡＣＨ」）手順の例を図７および図８に示す。図８から分かるように、二段階ランダムアクセス手順については、データはＭｓｇＡのプリアンブルとともに送信され（ステップ（１）に対応するメッセージＡ）、ＲＡＲはＭｓｇＢのＭｓｇ４（ＲＲＣ再開）で送信される（ステップ（２））。一方、図７に示す四段階ＲＡＣＨ手順では、プリアンブルおよびデータ（ステップ（１）および（３））、並びにＭｓｇ２／ＲＡＲおよびＭｓｇ４（ステップ（２）および（４））が別々のステップで送信される。さらに、異なるランダムアクセス手順の場合、異なるプリアンブルが送信され得る。例えば、ネットワークノードまたはｇＮＢが二段階ＲＡＣＨに関連するプリアンブルを受信するとき、データがＭｓｇＡ中のプリアンブルとともに送信されたことは把握している。
本開示によれば、ＲＡＣＨ手順における小容量データ送信を可能にするために、ネットワークまたはネットワークノードは、ＲＡＣＨプリアンブルにそれぞれ関連付けられた、ＰＵＳＣＨ送信（例えば、小容量データ送信または小容量ユーザデータ送信）のための複数のトランスポートブロック（ＴＢサイズ）を設定することが可能にされ得る。たとえば、表１に示されるように、異なるＴＢサイズのそれぞれが特定のＲＡＣＨプリアンブルに関連付けられるか、または対応する。
Figure 2023514146000002
つまり、ＵＥは、送信するデータのデータ量に基づいてＴＢサイズ（つまり対応するプリアンブル）を選択してよい。例えば、ＵＥが送信するデータ量がＹで、これが表１のＴＢサイズＸ１に適合する場合、ＲＡＣＨプリアンブルＺ１が選択される。さらに、四段階ＲＡＣＨの場合、ネットワークは、Ｍｓｇ３において所望のＴＢサイズを提供してもよい。例えば、Ｘ１＝１００ビット、Ｘ２＝２００ビット、Ｘ３＝３００ビットである。ＲＡＣＨプリアンブルについては、例えば、３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ；Ｔｅｃｈｎｉｃａｌ Ｓｐｅｃｉｆｉｃａｔｉｏｎ Ｇｒｏｕｐ Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ；ＮＲ；Ｐｈｙｓｉｃａｌ ｃｈａｎｎｅｌｓ ａｎｄ ｍｏｄｕｌａｔｉｏｎ （Ｒｅｌｅａｓｅ １５），Ｔａｂｌｅ ６．３．３．２－２：Ｒａｎｄｏｍ ａｃｃｅｓｓ ｃｏｎｆｉｇｕｒａｔｉｏｎｓ ｆｏｒ ＦＲ１ ａｎｄ ｐａｉｒｅｄ ｓｐｅｃｔｒｕｍ／ｓｕｐｐｌｅｍｅｎｔａｒｙ ｕｐｌｉｎｋ ａｎｄ ｓｅｃｔｉｏｎ ６．３．３．２，“Ｍａｐｐｉｎｇ ｔｏ ｐｈｙｓｉｃａｌ ｒｅｓｏｕｒｃｅｓ”を参照されたい。
しかしながら、複数のＵＥ、例えば２つのＵＥ（ＵＥ１およびＵＥ２）が、両方とも、送信するバッファ内に大きなサイズのデータ量を有することが起こり得る。この場合、ＵＥは両方とも、同じＴＢ送信機会において大きなＴＢに関連付けられた同じプリアンブルを選択し得る。その結果、ＵＥ１およびＵＥ２のＴＢ送信が衝突する可能性がある。例えば、ＵＥ１およびＵＥ２のＴＢ送信は、異なる優先度を有し得る（すなわち、高い優先度のＵＥ１と、低い優先度のＵＥ２）。
ＰＵＳＣＨの衝突が、ＲＡＣＨ手順の上述の小容量データ送信において、送信ＵＥ間で発生すると、この衝突は、ＵＥのパフォーマンスに直接影響を及ぼす可能性があり、システム全体のパフォーマンスも低下させる可能性がある。
本開示は、小容量データ送信の処理のための技術を提供する。これらの技法は、例えば、低優先度データへの不適切に大きいＴＢの使用を防ぐために、ネットワークからの制約でＵＥを構成することを含む。したがって、この制約は、優先度レベル、ＴＢサイズ、二段階ＲＡＣＨまたは四段階ＲＡＣＨ等のランダムアクセスの種類のうちの少なくとも１つまたは複数に基づく。
図９に示すように、提供される通信装置９６０は、送受信部９７０と、回路（例えば、処理および／または制御回路９８０）を備える。送受信部９７０（「ＵＥ送受信部」とも呼ばれる）は、動作時に、論理チャンネル（ＬＣＨ）からデータのトランスポートブロック（ＴＢ）サイズの設定を受信する。受信されたＴＢサイズ設定は、ＴＢサイズの制約を含み、特に、論理チャンネルごとのＴＢサイズ制約およびランダムアクセス手順の種類（「ＲＡＣＨタイプ」とも呼ばれる）ごとのＴＢサイズ制約のうちの少なくとも１つを含む。回路（「ＵＥ回路」とも呼ばれる）は、動作時に、受信したＴＢサイズの設定に基づいて、論理チャンネルのデータ送信のためのＴＢサイズおよびランダムアクセスタイプのうちの少なくとも１つを選択する。ＵＥ送受信部９７０は、動作時に、その選択に従って論理チャネルのデータ送信を行う。
通信装置９６０は、無線またはセルラ通信システムにおいて、無線チャネルを介してネットワークノードと通信を行う。例えば、通信装置９６０は、３ＧＰＰ ＮＲにおけるＵＥである。
論理チャネルのデータは、送信のためにバッファ内で利用可能なデータであってよい。例えば、論理チャネルのデータは、送信のためにランダムアクセス（ＲＡＣＨ）手順で処理される前にＲＬＣから論理チャネルを介して通信装置９７０のＭＡＣ層によって受信されるユーザプレーンデータである。
論理チャネルごとのＴＢサイズ制約は、ＵＥが使用するように設定される各論理チャネルの構成にそれぞれ含まれてよい。したがって、ＴＢサイズ制約は、それぞれの論理チャネルに固有であってよい。例えば、システムによって提供される利用可能なＴＢサイズの組の中から、ＴＢサイズ設定は、それぞれの論理チャネルの送信を、ＴＢサイズのサブセットまたは範囲、または特定のＴＢサイズに制約する。例えば、ＴＢサイズ制約設定は、ＲＲＣシグナリングに少なくとも部分的に含まれる。
ランダムアクセス手順当たりのＴＢサイズ制約は、第１のランダムアクセスタイプおよび第２のランダムアクセスタイプを含む１つ以上のランダムアクセスタイプのうちのランダムアクセスタイプ（またはＲＡＣＨタイプ）当たりのＴＢサイズ制約であり、第１のランダムアクセス手順のステップ数は、第２のランダムアクセス手順よりも少ない。１つ以上のランダムアクセスタイプは、例えば、上述の二段階ＲＡＣＨおよび四段階ＲＡＣＨを含んでよい。所定のＴＢサイズおよび／または論理チャンネルの送信は、特定のＲＡＣＨタイプで実行されるように制約され得る。一方、ＲＡＣＨタイプは、利用可能なＴＢサイズのサブセットを使用するように制約され得る。ランダムアクセス手順ごとの両方の種類のＴＢサイズ制約は、場合によっては論理チャネルのＴＢサイズ制約と組み合わせて、同時に設定され得る。
ＵＥ回路９８０は、動作時に、ＴＢサイズおよびランダムアクセス手順のうちの少なくとも１つを選択する。設定されたＴＢサイズ制約が論理チャネルごとのＴＢサイズ制約を含む場合、ＵＥ回路９８０は、論理チャネルのデータ送信のためのＴＢサイズを選択する。設定されたＴＢサイズ制約がランダムアクセス手順の種類ごとのＴＢサイズ制約を含む場合、ＵＥ回路９８０は、例えば、送信されるデータのＴＢサイズに従って、ランダムアクセス手順を選択する。
例えば、ＵＥ回路９８０は、ＴＢサイズ制約回路９８５を備える。ＴＢサイズ制約回路９８５の一例は、図１０に示され、ＴＢサイズ制約決定回路１０８６およびＴＢサイズ選択回路１０８７（またはプリアンブル選択回路、またはＴＢサイズ／プリアンブル選択回路）を備える。
論理チャネルのデータ送信は、ランダムアクセス手順内で実行される。データは、ＴＢサイズ制約に対応するＴＢサイズ（例えば、ＴＢサイズ制約が論理チャンネルの送信に対して適用されるときにも許可されるＴＢサイズ）で送信されるか、または、ＴＢサイズ制約に従ったランダムアクセスタイプを使用して送信される。ＴＢサイズおよびランダムアクセスタイプのいずれか一方または両方が、本開示の実施形態によって提供されるＴＢサイズ制約の種類に応じて、ＴＢサイズ制約に基づいて選択されてよい。例えば、第１のランダムアクセス手順タイプは、二段階ランダムアクセス手順タイプ（または二段階ＲＡＣＨタイプ）であり、第２のランダムアクセス手順は、四段階ランダムアクセス手順タイプ（四段階ＲＡＣＨ）である。
例えば、ランダムアクセス手順は、ＵＥがＲＲＣ＿ＩＮＡＣＴＩＶＥ状態、またはＲＲＣコンテキストおよびコアネットワーク接続が確立されている同様の状態にある間に実行されるが、通信装置またはデバイスのモビリティは、ネットワーク制御ではなく、デバイス制御（例えば、セル再選択による制御）であり、通信装置は、ランダムアクセスを通じてネットワークに接触することが可能である。送信は、上述したＲＲＣ＿ＩＮＡＣＴＩＶＥにおける小容量データ送信であってもよい。
さらに、図９に示されるネットワークノード９１０が提供され、上述したように、無線通信システムにおいて、無線チャネルを介して通信機器９６０と通信を行う。
ネットワークノード９１０は、回路９３０（ＵＥ回路９８０と区別するため「ネットワークノード回路」とも呼ばれる）を備え、これは、動作時に、通信装置の文脈において上記で提供されたＴＢサイズ設定の記載に従って、通信装置によって送信される論理チャネルのデータのためのＴＢサイズ設定を決定する。ネットワークノード９１０は、送受信部９２０をさらに備え、これは、動作時に、論理チャネルのデータのためのＴＢサイズ設定を送信し、論理チャネルのデータを受信する（論理チャネルのデータのＴＢサイズは送信された設定に従う）。
通信装置９６０およびネットワークノード９１０に対応して、通信装置のための方法およびネットワークノードのための方法が提供され、それらのステップを図１１に示す。ネットワークノードは、通信装置９６０の説明において上述した論理チャネルのデータのＴＢサイズの設定に対応するＴＢサイズ設定を決定するステップＳ１１１０を実行する。そして、ネットワークノードは、ステップＳ１１２０において、ＴＢサイズ設定を通信装置に送信し、通信装置は、ステップＳ１１３０において、その設定を受信する。通信装置は、受信した設定に基づいて、ステップＳ１１４０において、論理チャネルのデータ送信のためのＴＢサイズおよびランダムアクセス手順タイプのうちの少なくとも１つの選択を行う。さらに、通信装置は、ステップＳ１１５０において、その選択に従って論理チャネルのデータを送信し、ステップＳ１１６０において、ネットワークノードが受信する。
本開示で説明された実施形態および事例は、明示的な記述または文脈によって別段の指示がない限り、通信機器、ネットワークノード、および対応する方法のそれぞれに適用可能である。
ここで説明する方法および装置の提供によって、本開示は、ランダムアクセス手順における上りリンク送信の衝突の危険性を低減することに資する。例えば、ＴＢサイズ制約は、それぞれの論理チャネルの優先度を考慮して設定されてよい。したがって、大きなＴＢは、優先順位の高いデータおよび／または遅延にクリティカルなデータにのみ使用されるように制約されてよい。その結果、ＵＥが大きなＴＢで送信するとき、衝突の回避が容易になるか、または衝突の確率が低減され得る。
上述したように、上りリンクデータ送信のためのＴＢサイズは、対応するＲＡＣＨプリアンブルに関連付けられてよい。さらに、二段階ＲＡＣＨおよび四段階ＲＡＣＨ等の異なるランダムアクセス手順タイプは、異なるＲＡＣＨプリアンブルに関連付けられてよい。したがって、いくつかの実施形態では、ＵＥ回路９６０は、動作時に、論理チャネルの送信のため、ＴＢサイズおよびＲＡＣＨタイプのうちの少なくとも１つと一対一で対応するプリアンブルを選択する。例えば、それぞれのＲＡＣＨタイプについて、通信装置９６０およびネットワークノード９１０に既知であるそれぞれのプリアンブルがあり、これらは、選択可能な異なるＴＢサイズに対応する。したがって、ネットワークノード９１０は、プリアンブルを受信して処理することによって、どのＲＡＣＨタイプが送信に使用されているかを把握し、さらに、送信されたＴＢのサイズを把握する。
いくつかの実施形態では、ＴＢサイズの設定は、論理チャネルごとのＵＥ固有の設定に含まれる、ＴＢサイズ制約を示す通知を含む。例えば、１つまたは複数の論理チャネルがＵＥに設定され、これらの論理チャネルの設定にはそれぞれインジケータが含まれる。後述するように、論理チャネルの設定におけるインジケータとしては、ブール値、整数値、および閾値や許容ＴＢサイズの制限値等のＴＢサイズの明示的な通知が挙げられる。
いくつかの実施形態では、論理チャネルの設定は、論理チャネルごとのＵＥ固有の設定に加えて、システム情報内に設定される、インジケータによって示されるＴＢサイズ制約の下で選択可能なＴＢサイズまたはＴＢサイズの範囲を含む。したがって、論理チャネル設定におけるインジケータ（例えばブール値または整数）は、システムによって提供された利用可能なＴＢサイズの中で、選択可能なＴＢサイズ、またはＴＢサイズのサブセット（例えば、範囲）を示している。
論理チャネルごとの設定内にインジケータを設けることにより、それぞれの論理チャネルの上りリンク送信の優先度レベルを確立できる。したがって、論理チャネルごとの設定においてそのような通知（例えば、ブール指標または整数指標）を含む実施形態は、「優先度レベルベース」と呼ばれてもよい。
＜ブール値または整数の通知＞
いくつかの実施形態では、ＴＢサイズ制約の通知は、ＴＢサイズ制約が論理チャネルに適用されるかどうかを示すブール値を含む。したがって、各論理チャネルは、例えば、上位レイヤシグナリング（ＲＲＣシグナリング等）を介して、ＴＢサイズ制約またはＴＢ選択を適用するかどうかが設定される。
ブール値は、二つの取り得る値（ＴｒｕｅまたはＦａｌｓｅ）のいずれかを表す。例えば、Ｔｒｕｅは、設定された論理チャネルに対してＴＢサイズ制約（またはＴＢ選択制約）が適用されることを示し、Ｆａｌｓｅは、この論理チャネルに対してＴＢサイズ選択制約が適用されないことを示す。
例えば、上述のように、ネットワークは、ＵＥ、論理チャネル、またはその両方の遅延要件またはデータ優先度に基づいて、そのような制約を設定してよい。例えば、ネットワークは、ＬＣＨがより高い優先度のデータ（例えば、ＵＲＬＬＣデータ）を搬送する場合、ブール値をＦａｌｓｅに設定する。一方、ＬＣＨがより低い優先度のデータ（例えば、ｅＭＢＢデータ）を搬送する場合、ネットワークはＴｒｕｅを設定する。
ＵＥは、システム情報を介して、制約において選択可能である（制約適用時）ＴＢサイズのリストを受信してよい。このＴＢサイズのリストは、上述の、通知によって示されるＴＢサイズ、または、選択可能なＴＢサイズの範囲を含んでよい。
大きいＴＢサイズは高優先度または低遅延のデータといった特定のデータの送信にのみ使用されるため、ＴＢサイズ制約が適用されるかどうかの通知を用いることで、大きいＴＢサイズに対する衝突の低減を容易にし得る。
上記のＴＢサイズ制約の設定の一例を以下の表２～５に示す。
Figure 2023514146000003
Figure 2023514146000004
表２は、複数のＵＥに対する各論理チャネル（この例では、ＬＣＨ１およびＬＣＨ２）に設定されたブール値を示す。表３は、システム情報における制約の詳細を示す。ここで、表２の「ＬＣＨ ＩＤのブール値」の列は、表３の「ＴＢ選択制約の適用」の列を指す。また、想定値の一例（１００ビット、１０００ビット）は、限定する意味ではなく例示的な意味で理解されたい。したがって、論理チャネルにＴＢサイズ制約を適用する場合、論理チャネルのデータの上りリンク送信は、最大Ｘ１ビットのＴＢサイズを有することができ、適用しない場合、最大Ｘ２ビットのＴＢサイズを有することができる。表４は、プリアンブルとＴＢサイズとの間のマッピングを示す。
Figure 2023514146000005
表２～表４の設定から生じ得るデータ送信の例を表５に示す。設定されたＴＢサイズ制約により、ＵＥ２は、送信するデータ量が多くても、両方のチャネルに１００ビットのトランスポートブロックサイズを選択する。
Figure 2023514146000006
制約の下で利用可能なＴＢサイズの設定がシステム情報で提供される場合、ネットワークは、制約ルールを変更しようとするときに、各ＵＥを再度個別に設定する必要はなく、システム情報を通じて変更を通知すればよい。
次に、シグナリングの一例について説明する。論理チャネルの設定は、以下のようにＲＲＣシグナリングに含まれてもよい。
LogicalChannelConfig ::= SEQUENCE {
ul-SpecificParameters SEQUENCE {
priority INTEGER (1..16),
prioritisedBitRate ENUMERATED {kBps0, kBps8, kBps16, kBps32, kBps64, kBps128, kBps256, kBps512,
kBps1024, kBps2048, kBps4096, kBps8192, kBps16384, kBps32768, kBps65536, infinity},
bucketSizeDuration ENUMERATED {ms5, ms10, ms20, ms50, ms100, ms150, ms300, ms500, ms1000,
spare7, spare6, spare5, spare4, spare3,spare2, spare1},
allowedServingCells SEQUENCE (SIZE (1..maxNrofServingCells-1)) OF ServCellIndex
OPTIONAL, -- PDCP-CADuplication
allowedSCS-List SEQUENCE (SIZE (1..maxSCSs)) OF SubcarrierSpacing OPTIONAL, -- Need R
maxPUSCH-Duration ENUMERATED {ms0p02, ms0p04, ms0p0625, ms0p125, ms0p25, ms0p5, spare2, spare1}
OPTIONAL, -- Need R
configuredGrantType1Allowed ENUMERATED {true} OPTIONAL, -- Need R
logicalChannelGroup INTEGER (0..maxLCG-ID) OPTIONAL, -- Need R
schedulingRequestID SchedulingRequestId OPTIONAL, -- Need R
logicalChannelSR-Mask BOOLEAN,
logicalChannelSR-DelayTimerApplied BOOLEAN,
TB_SelectionRestrictionAppliedRACH BOOLEAN,
...,
bitRateQueryProhibitTimer ENUMERATED { s0, s0dot4, s0dot8, s1dot6, s3, s6, s12,s30} OPTIONAL -- Need R
} OPTIONAL, -- Cond UL
...
}
ＬＣＨ設定の上記シグナリングでは、ＬＣＨにおいてＴＢ選択制約が適用される。特に、ブール値は、「ＴＢ＿ＳｅｌｅｃｔｉｏｎＲｅｓｔｒｉｃｔｉｏｎＡｐｐｌｉｅｄＲＡＣＨ」に対応する。
さらに、プリアンブル選択制約は、以下に示されるように、ＲＲＣシグナリング内のシステム情報メッセージにおいて適用される。
PreambleInfo ::= SEQUENCE {
numberOfRA-Preambles
TB-selectionrestrictionAppliedRACH_False INTEGER (1…6)
TB-selectionrestrictionAppliedRACH_True INTEGER (1…4)
TBsize ENUMERATED (b100, b200, b300, b400, b500, b600)
ここで、プリアンブル１は１００ビットのＴＢサイズに関連付けられ、プリアンブル２は２００ビットのＴＢサイズに関連付けられ、以下も同様に関連付けられる。この例では、ＴＢサイズ制約の下で利用可能なＴＢサイズの範囲には１００ビットから４００ビットのＴＢサイズが含まれるが、制約なしでは１００ビットから６００ビットのＴＢサイズが利用可能である。
図１２は、ＴＢサイズ制約に従ったデータサイズをブール値によって決定するためにＵＥによって行われるステップを示すフローチャートである。最初に、ステップＳ１２１０において、ＵＥは、送信すべきデータがバッファ内に存在するかどうか確認する。Ｙｅｓの場合、ＵＥは、送信すべきデータが属するＬＣＨにＴＢ選択制約が適用されるかどうか確認する（Ｓ１２２０）。Ｙｅｓの場合、ＵＥは、ＴＢサイズ選択制約の下で選択可能なＴＢサイズのサブセットまたは範囲に対応するプリアンブルのサブセットから、データ送信を実行するためのプリアンブルを選択する（ステップＳ１２３０）。Ｎｏの場合、ＵＥは、送信するバッファ内のデータのデータサイズに対応するプリアンブルを選択して、送信してよい（ステップＳ１２４０）。
上述のように、いくつかの実施形態では、ＴＢサイズの通知は、複数の整数値のうち一つの整数値を含み、これは、論理チャネルごとの設定におけるインジケータによって示されるＴＢサイズ制約の下で選択可能な複数のＴＢサイズ、ＴＢサイズの範囲を表す。
ブール値の場合および上記の説明と同様に、優先度レベルは、ネットワークから上位レイヤシグナリング（例えば、ＲＲＣシグナリング）を介して論理チャネルごとに通知される。
ＲＲＣシグナリングにおける論理チャネルの設定の一例を以下に示す。
LogicalChannelConfig ::= SEQUENCE {
ul-SpecificParameters SEQUENCE {
priority INTEGER (1..16),
prioritisedBitRate ENUMERATED {kBps0, kBps8, kBps16, kBps32, kBps64, kBps128, kBps256, kBps512,
kBps1024, kBps2048, kBps4096, kBps8192, kBps16384, kBps32768, kBps65536, infinity},
bucketSizeDuration ENUMERATED {ms5, ms10, ms20, ms50, ms100, ms150, ms300, ms500, ms1000,
spare7, spare6, spare5, spare4, spare3,spare2, spare1},
allowedServingCells SEQUENCE (SIZE (1..maxNrofServingCells-1)) OF ServCellIndex
OPTIONAL, -- PDCP-CADuplication
allowedSCS-List SEQUENCE (SIZE (1..maxSCSs)) OF SubcarrierSpacing OPTIONAL, -- Need R
maxPUSCH-Duration ENUMERATED {ms0p02, ms0p04, ms0p0625, ms0p125, ms0p25, ms0p5, spare2, spare1}
OPTIONAL, -- Need R
configuredGrantType1Allowed ENUMERATED {true} OPTIONAL, -- Need R
logicalChannelGroup INTEGER (0..maxLCG-ID) OPTIONAL, -- Need R
schedulingRequestID SchedulingRequestId OPTIONAL, -- Need R
logicalChannelSR-Mask BOOLEAN,
logicalChannelSR-DelayTimerApplied BOOLEAN,
allowPrioritylevelTBrestriction INTEGER (1...3),
...,
bitRateQueryProhibitTimer ENUMERATED { s0, s0dot4, s0dot8, s1dot6, s3, s6, s12,s30} OPTIONAL -- Need R
} OPTIONAL, -- Cond UL
...
}
異なる論理チャネルに異なるＴＢサイズ制約を設けることにより、ネットワークは、異なる論理チャネルの上りリンク送信に異なる優先度を決定し、それは、ＴＢサイズ制約の通知の整数値によって表される。これは、上記のシグナリングの一例における変数名「ａｌｌｏｗＰｒｉｏｒｉｔｙｌｅｖｅｌＴＢｒｅｓｔｒｉｃｔｉｏｎ」によって示される。上記の例では、整数値「１」は、より高い優先度レベルに対応し、「３」は、より低い優先度レベルに対応する。
ここで、上りリンク送信の優先度レベルは、「ａｌｌｏｗＰｒｉｏｒｉｔｙｌｅｖｅｌＴＢｒｅｓｔｒｉｃｔｉｏｎ」に対応し、論理チャネル設定に存在するパラメータ「ｐｒｉｏｒｉｔｙ」とは異なる。「ｐｒｉｏｒｉｔｙ」は、セル内ではなく、ＵＥ内の論理チャネル間の論理チャネル優先度を示す。この可変優先度は、ランダムアクセス手順における上りリンク送信には特に関係しないが、例えば、ｃｏｎｆｉｇｕｒｅｄ ｇｒａｎｔ等のランダムアクセス手順以外の他の種類の送信のために使用され得る論理チャネルの優先度を決定するためにＵＥにシグナリングされる。パラメータ「ｐｒｉｏｒｉｔｙ」は、ＵＥ内の論理チャネルの優先度の順序を定義する。一方、ＴＢサイズの通知は、セル内のＵＥの異なる論理チャネルに異なるＴＢサイズ制約を割り当てることによって、セル内のＵＥ間の絶対的な優先度を確立する。
したがって、ＵＥは、許容ＴＢサイズの整数通知によって暗示されるような優先度レベルに基づいてＴＢサイズを選択してよい。つまり、ＵＥは、ＬＣＨの設定においてより高い優先度レベルが示される場合、より大きいＴＢサイズを選択してよい。一方、ＬＣＨ設定のインジケータ「ａｌｌｏｗＰｒｉｏｒｉｔｙｌｅｖｅｌＴＢｒｅｓｔｒｉｃｔｉｏｎ」によってより低い優先度が示される場合、ＵＥは、ＴＢサイズの選択が制約される。
例えば、整数値が１を示す論理チャネルは、より低い優先度レベル２および３と比較して、より大きいＴＢサイズおよび／またはより大きいＴＢサイズの範囲を使用できる。ブール指示と同様に、ＵＥは、許可されたＴＢサイズまたはＴＢサイズの範囲（および対応するプリアンブル）と、システム情報メッセージ内の許可されたＴＢ範囲に対応する優先度レベルの整数値との関連付けを受信してよい。このようなシステム情報の一例を以下に示す。
PreambleInfo ::= SEQUENCE {
numberOfRA-Preambles
TB-selectionPriortyLevel_1 INTEGER (1…6)
TB-selectionPriortyLevel_2 INTEGER (1…4)
TB-selectionPriortyLevel_3 INTEGER (1…2)
TBsize ENUMERATED (b100, b200, b300, b400, b500, b600)
プリアンブル１は、１００ビット（ｂ１００）に関連付けられ、プリアンブル２は、２００ビットに関連付けられ、以下も同様に関連付けられる。
ランダムアクセス手順における上りリンク送信の優先度レベルを表すＴＢ制約のインジケータをシグナリングするための変形例として、ＵＥは、論理チャネルの優先度に基づいて、優先度レベルを暗黙的に決定してもよい。例えば、優先度レベルと論理チャネル優先度（例えば、一例として整数値１から１６で取得する、上記で設けられた論理チャネル固有の設定例における変数「ｐｒｉｏｒｉｔｙ」によって示される）との間のマッピングは、規格によって定義されてよく、したがって「ハードコーディング」されてよい。さらに、利用可能なＴＢサイズまたはＴＢサイズ範囲は、上記のＲＲＣシグナリングの例と同様、規格において規定されるか、またはシステム情報においてシグナリングされてよい。一例を以下の表６に示す。
Figure 2023514146000007
ハードコーディングされた優先度を有する場合、優先度レベルは、追加のパラメータとしてシグナリングに含まれる必要がなく、したがって、シグナリングオーバーヘッドが低減され得る。しかしながら、ネットワークは、セル内のＵＥ間の相対的な優先度を設定する必要があり（インジケータ「ｐｒｉｏｒｉｔｙ」は、一般に、セル内ではなくＵＥ内の優先度の順序を確立するために使用されるため）、これにより複雑さが増す可能性がある。
＜ＴＢサイズ制限の通知＞
いくつかの実施形態では、論理チャネルごとの設定におけるＴＢサイズ制約の通知は、ＴＢサイズ制約の下で選択可能なＴＢサイズの閾値を含む。例えば、閾値は、ＴＢサイズ制約の下で選択可能なＴＢサイズの上限値などの制限値である。
つまり、ＴＢサイズの上限等の閾値が上位レベルのシグナリング（例えば、ＲＲＣ）を介して、ネットワークから各論理チャンネル（ＬＣＨ）に設定される。この閾値に関して、ネットワークは、例えば、ＵＥの遅延要件および／またはデータ優先度に基づいて、ＴＢサイズを設定する。例えば、ネットワークは、ＬＣＨがより高い優先度のデータを搬送する場合はより大きい許容ＴＢサイズを設定し、ＬＣＨがより低い優先度のデータを搬送する場合はより小さいＴＢサイズを設定する。
このような設定の下で、ＵＥは、最大値または閾値によって与えられる、設定されたＴＢサイズよりも大きいＴＢサイズを選択することができない。例えば、バッファ内で利用可能なデータのデータ量が１０００ビットで、論理チャネルに設定されたＴＢサイズ（またはＴＢサイズの最大値／制限値）が１００ビットである場合、ＵＥは、１００ビットのＴＢサイズを選択してよい（それより大きいＴＢサイズは選択しない）。例えば、ＴＢサイズは、以下のＲＲＣシグナリング例に示されるように、異なるＴＢサイズに対応する値をとることが可能であり例えば「ｍａｘ＿ＴＢｓｉｚｅＦｏｒＲＡＣＨ」と呼ばれ得る、ＬＣＨ設定内の情報エレメントによって、システム情報内のＴＢサイズまたはＴＢサイズの範囲を参照することなく、例えば、「自己完結型」で、または明示的に（例えば、｛ｂ１００、ｂ２００、…｝の中の値として）通知される。
LogicalChannelConfig ::= SEQUENCE {
ul-SpecificParameters SEQUENCE {
priority INTEGER (1..16),
prioritisedBitRate ENUMERATED {kBps0, kBps8, kBps16, kBps32, kBps64, kBps128, kBps256, kBps512,
kBps1024, kBps2048, kBps4096, kBps8192, kBps16384, kBps32768, kBps65536, infinity},
bucketSizeDuration ENUMERATED {ms5, ms10, ms20, ms50, ms100, ms150, ms300, ms500, ms1000,
spare7, spare6, spare5, spare4, spare3,spare2, spare1},
allowedServingCells SEQUENCE (SIZE (1..maxNrofServingCells-1)) OF ServCellIndex
OPTIONAL, -- PDCP-CADuplication
allowedSCS-List SEQUENCE (SIZE (1..maxSCSs)) OF SubcarrierSpacing OPTIONAL, -- Need R
maxPUSCH-Duration ENUMERATED {ms0p02, ms0p04, ms0p0625, ms0p125, ms0p25, ms0p5, spare2, spare1}
OPTIONAL, -- Need R
configuredGrantType1Allowed ENUMERATED {true} OPTIONAL, -- Need R
logicalChannelGroup INTEGER (0..maxLCG-ID) OPTIONAL, -- Need R
schedulingRequestID SchedulingRequestId OPTIONAL, -- Need R
logicalChannelSR-Mask BOOLEAN,
logicalChannelSR-DelayTimerApplied BOOLEAN,
max_TBsizeForRACH ENUMERATED {b100, b200, b500, b800, b1000}
...,
bitRateQueryProhibitTimer ENUMERATED { s0, s0dot4, s0dot8, s1dot6, s3, s6, s12,s30} OPTIONAL -- Need R
} OPTIONAL, -- Cond UL
...
}
上述のように、ブール値または整数の通知を伴う実施形態は、設定変更の通知を容易にでき、各ＵＥに個別に設定する必要がない。一方、ＴＢサイズ制約が明示的に閾値や制限値としてＬＣＨ設定に存在する場合は、上記のような「ＴＢ－ｓｅｌｅｃｔｉｏｎＲｅｓｔｒｉｃｔｉｏｎＡｐｐｌｉｅｄＲＡＣＨ」や「ＴＢ－ｓｅｌｅｃｔｉｏｎＰｒｉｏｒｉｔｙＬｅｖｅｌ」といったパラメータは、システム情報において不要である。これにより、システム情報に関するシグナリングのオーバーヘッドを低減できる。
図１３に、ＵＥのような通信装置９６０によって実行されるステップの一例を示す。ステップＳ１３１０において、ＵＥは、送信すべきデータがバッファ内に存在するかどうか確認する。Ｙｅｓの場合、ＵＥは、送信されるデータのＬＣＨに設定された最大ＴＢサイズ（例えば、閾値）を確認し（Ｓ１３２０）、送信されるデータのデータ量が設定された最大ＴＢサイズより大きいかどうかを確認する（Ｓ１３３０）。データ量が大きい場合、ＵＥは、設定された最大ＴＢサイズに従ってＴＢサイズを選択する（ステップＳ１３４０）。Ｎｏの場合、ＵＥは、送信されるデータ量に従ってＴＢサイズを選択する。
設定された最大ＴＢサイズに応じたＴＢサイズの選択の一例を表７から９に示す。
Figure 2023514146000008
Figure 2023514146000009
Figure 2023514146000010
表７は、ＵＥ１およびＵＥ２にそれぞれ設定される論理チャネルＬＣＨ１およびＬＣＨ２に設定された最大値を示す。表８は、プリアンブルとＴＢサイズとの間のマッピングを示す。表９は、結果として得られる、ＴＢサイズおよび対応するプリアンブルの選択を示す。ＵＥ１は、１０００ビットのデータを送信するためにより大きなＴＢサイズ（１０００ビット）をＬＣＨ１に選択できるが、ＵＥ２は、１０００ビットを送信するにもかかわらず、ＬＣＨ１およびＬＣＨ２に小さなＴＢサイズ（５００ビット）しか選択できない。
＜ランダムアクセスの種類によるＴＢサイズ制約＞
いくつかの実施形態では、ＴＢサイズ制約は、第１のランダムアクセス手順タイプおよび第２のランダムアクセス手順タイプといったランダムアクセス手順タイプ（またはＲＡＣＨタイプ）ごとのＴＢサイズ制約を含み、第１のランダムアクセス手順タイプの送信ステップ数は、第２のランダムアクセス手順タイプよりも少ない。例えば、ＵＥ回路９８０は、動作時に、ＴＢサイズ制約の設定に基づいてランダムアクセス手順タイプを選択し、ＵＥ送受信部９７９は、データの送信のために選択されたランダムアクセス手順タイプを使用する。例えば、ランダムアクセス手順タイプごとのＴＢサイズ制約により、第１のランダムアクセス手順タイプでは、第２のランダムアクセス手順タイプよりも大きなＴＢサイズを送信することができる。そして、ＵＥ回路９８０は、論理チャネルのデータサイズに基づいてランダムアクセス手順タイプを選択してよい。つまり、第１および第２のＲＡＣＨタイプは、それぞれ異なるＴＢサイズに使用されてよく、第１のＲＡＣＨタイプによる送信は、より大きいＴＢサイズに制約されてもよい。
例えば、第１のランダムアクセス手順タイプは、図８の二段階ＲＡＣＨに対応し、第２のランダムアクセス手順タイプは、図７に示される四段階ＲＡＣＨに対応する。ＵＥは、ＴＢサイズに基づいてＲＡＣＨ／ランダムアクセス手順タイプを選択してよく、それによって、ネットワークは、二段階ＲＡＣＨに対してのみより大きいＴＢサイズを設定し、四段階ＲＡＣＨに対してのみより小さいＴＢサイズを設定する。
ＴＢサイズに基づくＲＡＣＨタイプの選択は、ＵＥが二段階ＲＡＣＨを実行するときにセグメント化を回避できる。つまり、二段階ＲＡＣＨは、特に、高優先度のデータ送信（例えば、緊急ＩｏＴ（ＵＲＬＬＣ）パケット）のユーザデータを送信することを容易にし得る。ＴＢサイズがＩｏＴパケットに対して十分でない場合、ＩｏＴパケットのセグメント化が起こり、これは、次の上りリンクの送信機会までパケットの送信が完了するのを遅らせる原因となる。したがって、二段階ＲＡＣＨをより大きいＴＢサイズに制限することで、セグメント化を回避し、遅延要件を満たすことができる。
表１０、表１１、およびさらに下の表１２には、異なるＲＡＣＨタイプに対する許容データサイズの設定に応じたデータ送信の一例が示される。
Figure 2023514146000011
Figure 2023514146000012
表１０は、プリアンブルとＴＢサイズとの間のマッピングを示し、表１１は、二段階ＲＡＣＨおよび四段階ＲＡＣＨのＴＢ設定を示す。この設定によれば、二段階ＲＡＣＨはより大きいＴＢサイズＸ３およびＸ４に制約され、ＵＥは、より小さいＴＢサイズには四段階ＲＡＣＨを選択しなければならない（これ以前のすべての表および例のように、ビットサイズの数値は一例であり、本開示を限定することを意図しない）。表１０と表１１とを組み合わせると、プリアンブルＰ１からＰ４はそれぞれ、ＴＢサイズとＲＡＣＨタイプとの組合せに一対一で対応していることが分かる。表１１で例示されるような設定は、ＲＲＣシグナリングのシステム情報内でシグナリングされてよい。このようなシステム情報の一例を以下に示す。
PreambleInfo ::= SEQUENCE {
numberOfRA-Preambles
TB-selectionfor4-stepRACH INTEGER (1…2)
TB-selectionfor2-StepRACH INTEGER (3…4)
TBsize ENUMERATED (b100, b200, b300, b400)
表１２は、図１０のＴＢサイズとプリアンブルとのマッピング、および表１１の設定に従ったＲＡＣＨタイプの選択を示す。ＵＥは、より大きいサイズ（５００ビット、１０００ビット）のデータ量のデータを二段階ＲＡＣＨで送信し、より小さいサイズのデータは四段階ＲＡＣＨで送信される。
Figure 2023514146000013
図１４は、データサイズに基づいたＲＡＣＨタイプの選択においてＵＥが行うステップを示す。ステップＳ１４１０において、ＵＥは、送信されるデータサイズが表１０のＸ２以下であるかどうか確認する。Ｙｅｓの場合、ＵＥは四段階ＲＡＣＨを実行し（ステップＳ１４２０）、Ｎｏの場合、ＵＥは二段階ＲＡＣＨを実行する（Ｓ１４３０）。
組み合わせ
「ランダムアクセスの種類によるＴＢサイズ制約」のセクションで説明したように、ＵＥは、送信のためのバッファ内で利用可能なデータのサイズに基づいてＲＡＣＨタイプを選択するように構成される。代替または追加として、論理チャネル（またはＵＥに設定された複数の論理チャネル）は、第１のランダムアクセス手順（例えば、二段階ＲＡＣＨ）または第２のランダムアクセス手順タイプ（四段階ＲＡＣＨ）のいずれかを使用するように構成されてよい。
例えば、より高い優先度のチャネル（例えば、ＵＲＬＬＣチャネル）は、（例えば、「ランダムアクセスの種類によるＴＢサイズ制約」で上述したように、送信するデータのサイズに応じて）二段階ＲＡＣＨまたは四段階ＲＡＣＨのいずれかを使用してよく、より低い優先度のデータ（例えば、ｅＭＢＢ論理チャネルのデータ）は、四段階ＲＡＣＨのみを使用できる。
いくつかの実施形態では、ＴＢサイズの設定は、ＵＥ固有の論理チャネルごとの設定内で、第１のランダムアクセス手順タイプが制約されるかどうかを示すブール値を含む。
第１のランダムアクセス手順タイプが制約されるかどうかを示すブール値を含むＲＲＣシグナリングにおける論理チャネル設定の一例を以下に示すが、ここで、ブール値は「２ｓｔｅｐＲＡＣＨｒｅｓｔｒｉｃｔｉｏｎ」に対応する。
LogicalChannelConfig ::= SEQUENCE {
ul-SpecificParameters SEQUENCE {
priority INTEGER (1..16),
prioritisedBitRate ENUMERATED {kBps0, kBps8, kBps16, kBps32, kBps64, kBps128, kBps256, kBps512,
kBps1024, kBps2048, kBps4096, kBps8192, kBps16384, kBps32768, kBps65536, infinity},
bucketSizeDuration ENUMERATED {ms5, ms10, ms20, ms50, ms100, ms150, ms300, ms500, ms1000,
spare7, spare6, spare5, spare4, spare3,spare2, spare1},
allowedServingCells SEQUENCE (SIZE (1..maxNrofServingCells-1)) OF ServCellIndex
OPTIONAL, -- PDCP-CADuplication
allowedSCS-List SEQUENCE (SIZE (1..maxSCSs)) OF SubcarrierSpacing OPTIONAL, -- Need R
maxPUSCH-Duration ENUMERATED {ms0p02, ms0p04, ms0p0625, ms0p125, ms0p25, ms0p5, spare2, spare1}
OPTIONAL, -- Need R
configuredGrantType1Allowed ENUMERATED {true} OPTIONAL, -- Need R
logicalChannelGroup INTEGER (0..maxLCG-ID) OPTIONAL, -- Need R
schedulingRequestID SchedulingRequestId OPTIONAL, -- Need R
logicalChannelSR-Mask BOOLEAN,
logicalChannelSR-DelayTimerApplied BOOLEAN,
2stepRACHrestriction BOOLEAN,
...,
bitRateQueryProhibitTimer ENUMERATED { s0, s0dot4, s0dot8, s1dot6, s3, s6, s12,s30} OPTIONAL -- Need R
} OPTIONAL, -- Cond UL
...
}
このような、論理チャネルごとの制約や、より大きいＴＢサイズを二段階ＲＡＣＨに制約することによって、二段階ＲＡＣＨに対してのみ選択可能であるより大きいＴＢサイズが、論理チャネルごとに制約されることになる。つまり、「ブール値または整数の通知」に記載された論理チャネルごとのＴＢサイズの制約と、「ランダムアクセスの種類によるＴＢサイズ制約」に記載されたＲＡＣＨタイプごとのＴＢサイズの制約との組み合わせが提供される。このＴＢサイズ制約の組み合わせのために、ネットワーク（またはネットワークノード９１０）およびＵＥ（または通信装置９６０）によって実行されるステップが図１５および図１６に示される。
ステップＳ１５１０において、ネットワーク（例えば、ネットワークノード回路９３０）は、二段階ＲＡＣＨ制約（例えば、上記のＲＲＣシグナリング例における「２ｓｔｅｐＲＡＣＨｒｅｓｔｒｉｃｔｉｏｎ」に対応するブール値）を設定する。ネットワークはさらに、四段階ＲＡＣＨにＴＢｓｉｚｅ１およびＴＢｓｉｚｅ２を設定し、二段階ＲＡＣＨにＴＢｓｉｚｅ１からＴＢｓｉｚｅ４を設定する。ここで、ＴＢｓｉｚｅ１＜ＴＢｓｉｚｅ２＜ＴＢｓｉｚｅ３＜ＴＢｓｉｚｅ４である。例えば、ＴＢｓｉｚｅ１からＴＢｓｉｚｅ４は、表１０に示されるＴＢｓｉｚｅＸ１からＸ４に対応する。システム情報は、例えば、「ランダムアクセスの種類によるＴＢサイズ制約」のセクションにおけるシステム情報シグナリングの例のように、または以下のシグナリングの例のように提供されてよい。
PreambleInfo ::= SEQUENCE {
numberOfRA-Preambles
TB-selectionfor4-stepRACH INTEGER (1…2)
TB-selectionfor2-StepRACH INTEGER (1…4)
TBsize ENUMERATED (b100, b200, b300, b400).
ＵＥは、図１５のステップ１５１０に関連して記載された設定を受信すると、論理チャネルのデータが送信用のバッファに到着したかどうか確認する（ステップＳ１６１０）。データが到着すると、ＵＥは、データが到着した論理チャネルに対して２段階ＲＡＣＨ制約が適用されるかどうか確認する（ステップＳ１６２０）。二段階ＲＡＣＨ制約が適用されない場合（ブール値がＦａｌｓｅ、二段階ＲＡＣＨが許可、図１６で「Ｙｅｓ」の場合）、ＵＥは、到着した論理チャネルのデータのデータ量に応じて、ＴＢｓｉｚｅ１からＴＢｓｉｚｅ４のうち一つのＴＢサイズを選択する（Ｓ１２３０）。論理チャネルに対して二段階ＲＡＣＨ制限が適用される場合（例えば、この論理チャネルに対して二段階ＲＡＣＨが許可されず、図１６において「Ｎｏ」であり、制約を示すブール値が「Ｔｒｕｅ」である場合）、ＵＥは、四段階ＲＡＣＨを実行し、ＴＢｓｉｚｅ１またはＴＢｓｉｚｅ２のいずれかを選択する（ステップＳ１６４０）。
選択されたＲＡＣＨ手順に関して、二段階ＲＡＣＨが論理チャネルに対して許可される場合は異なる選択肢が考えられる。ＵＥは、より大きいＴＢサイズ（例えば、ＴＢｓｉｚｅ３およびＴＢｓｉｚｅ４）には二段階ＲＡＣＨを選択し、より小さいＴＢサイズ（ＴＢｓｉｚｅ１およびＴＢｓｉｚｅ２）には四段階ＲＡＣＨを選択してよい。つまり、上述のように、セグメント化を回避するために、より大きいデータ量が優先される。一方、論理チャネルは、データサイズに関係なく優先されてもよい。この場合、ＵＥは、利用可能なＴＢサイズのそれぞれに二段階ランダムアクセス手順を使用してよい。
また、「ブール値または整数の通知」および「ランダムアクセスの種類によるＴＢサイズ制約」のセクションで説明したＴＢサイズ制約が組み合わされた場合、ＵＥは、ブール値をチェックすることによって、二段階ランダムアクセス手順を実行する前に、二段階ＲＡＣＨの論理チャネルのデータ送信のためのＴＢサイズ選択が論理チャネルに適用されるかどうか確認することができる。ブール値がＴｒｕｅを示す場合は制約が適用され、ＵＥは、論理チャネルのデータを送信するために（例えば、制約において許可されるより小さいＴＢサイズを使用して）四段階ＲＡＣＨを実行する。ブール値の値Ｆａｌｓｅは、ＴＢサイズ選択制約が適用されないことを示す。したがって、ＵＥは、この論理チャネルのデータを送るために二段階ＲＡＣＨを実行してよく、または、送信される論理チャネルデータのデータサイズにどのランダムアクセスタイプが設定されるかに応じて、二段階ＲＡＣＨおよび四段階ＲＡＣＨのうちのいずれか１つを実行してよい。例えば、以下の論理チャネルに対する設定のシグナリング例のように、ブール値を示す情報エレメントは「ＴＢ＿ＳｅｌｅｃｔｉｏｎＲｅｓｔｒｉｃｔｉｏｎＡｐｐｌｉｅｄ２ｓｔｅｐＲＡＣＨ」と呼ばれる。
LogicalChannelConfig ::= SEQUENCE {
ul-SpecificParameters SEQUENCE {
priority INTEGER (1..16),
prioritisedBitRate ENUMERATED {kBps0, kBps8, kBps16, kBps32, kBps64, kBps128, kBps256, kBps512,
kBps1024, kBps2048, kBps4096, kBps8192, kBps16384, kBps32768, kBps65536, infinity},
bucketSizeDuration ENUMERATED {ms5, ms10, ms20, ms50, ms100, ms150, ms300, ms500, ms1000,
spare7, spare6, spare5, spare4, spare3,spare2, spare1},
allowedServingCells SEQUENCE (SIZE (1..maxNrofServingCells-1)) OF ServCellIndex
OPTIONAL, -- PDCP-CADuplication
allowedSCS-List SEQUENCE (SIZE (1..maxSCSs)) OF SubcarrierSpacing OPTIONAL, -- Need R
maxPUSCH-Duration ENUMERATED {ms0p02, ms0p04, ms0p0625, ms0p125, ms0p25, ms0p5, spare2, spare1}
OPTIONAL, -- Need R
configuredGrantType1Allowed ENUMERATED {true} OPTIONAL, -- Need R
logicalChannelGroup INTEGER (0..maxLCG-ID) OPTIONAL, -- Need R
schedulingRequestID SchedulingRequestId OPTIONAL, -- Need R
logicalChannelSR-Mask BOOLEAN,
logicalChannelSR-DelayTimerApplied BOOLEAN,
TB_SelectionRestrictionApplied2stepRACH BOOLEAN,
...,
bitRateQueryProhibitTimer ENUMERATED { s0, s0dot4, s0dot8, s1dot6, s3, s6, s12,s30} OPTIONAL -- Need R
} OPTIONAL, -- Cond UL
...
}
さらに、「ＴＢサイズ制限の通知」と「ランダムアクセスの種類による制約」セクションからのＴＢサイズ制約の設定を組み合わせてもよい。例えば、ＵＥは、二段階ＲＡＣＨを実行する前に、送信されるデータ量が設定されたＴＢサイズ以上であるかどうか確認する。ＵＥは、データサイズが設定されたＴＢサイズ以上である場合は二段階ＲＡＣＨ手順を、そうでない場合は四段階ＲＡＣＨ手順を実行する。
例えば、ＵＥが送信するデータが５００ビットで、設定されたＴＢサイズが４００ビットの場合、ＵＥは、二段階ＲＡＣＨでデータを送信できる。ただし、ＵＥが２００ビットのデータを有していながら設定されたＴＢサイズが４００ビットである場合は、四段階ＲＡＣＨでデータを送信する。ここで、設定において提供され得る設定されたＴＢサイズは、二段階ＲＡＣＨ手順を使用するための最小ＴＢサイズである。したがって、本開示では、ＴＢサイズに対する上述の閾値または制限値は、最大ＴＢサイズ（ＴＢサイズ制約の下で許容される最大ＴＢサイズ等）または最小ＴＢサイズ（例えば、二段階ＲＡＣＨが制約されない最小ＴＢサイズ）に対応してよい。ＬＣＨ設定のシグナリング例が以下に示され、二段階ＲＡＣＨタイプの最小ＴＢサイズを規定する情報エレメントを「ｍｉｎｉｍｕｍ＿ＴＢｓｉｚｅＦｏｒ２ｓｔｅｐＲＡＣＨ」と呼ぶ。
LogicalChannelConfig ::= SEQUENCE {
ul-SpecificParameters SEQUENCE {
priority INTEGER (1..16),
prioritisedBitRate ENUMERATED {kBps0, kBps8, kBps16, kBps32, kBps64, kBps128, kBps256, kBps512,
kBps1024, kBps2048, kBps4096, kBps8192, kBps16384, kBps32768, kBps65536, infinity},
bucketSizeDuration ENUMERATED {ms5, ms10, ms20, ms50, ms100, ms150, ms300, ms500, ms1000,
spare7, spare6, spare5, spare4, spare3,spare2, spare1},
allowedServingCells SEQUENCE (SIZE (1..maxNrofServingCells-1)) OF ServCellIndex
OPTIONAL, -- PDCP-CADuplication
allowedSCS-List SEQUENCE (SIZE (1..maxSCSs)) OF SubcarrierSpacing OPTIONAL, -- Need R
maxPUSCH-Duration ENUMERATED {ms0p02, ms0p04, ms0p0625, ms0p125, ms0p25, ms0p5, spare2, spare1}
OPTIONAL, -- Need R
configuredGrantType1Allowed ENUMERATED {true} OPTIONAL, -- Need R
logicalChannelGroup INTEGER (0..maxLCG-ID) OPTIONAL, -- Need R
schedulingRequestID SchedulingRequestId OPTIONAL, -- Need R
logicalChannelSR-Mask BOOLEAN,
logicalChannelSR-DelayTimerApplied BOOLEAN,
minimum_TBsizeFor2stepRACH ENUMERATED {b400, b500, b600, b800, b1000}
...,
bitRateQueryProhibitTimer ENUMERATED { s0, s0dot4, s0dot8, s1dot6, s3, s6, s12,s30} OPTIONAL -- Need R
} OPTIONAL, -- Cond UL
...
}
さらに、「ブール値または整数の通知」で説明されているＴＢサイズ制約のブール値の通知と、「ＴＢサイズ制限の通知」で説明されている閾値等の設定されたＴＢサイズの提供を組み合わせてもよい。したがって、設定は、ＵＥ固有の論理チャネルごとの設定内に、ＴＢサイズ制約が論理チャネルに適用されるかどうかを示すブール値と、ＴＢサイズ制約の下で選択可能なＴＢサイズの閾値とを含むＴＢサイズ制約の通知を含んでよい。
したがって、ＵＥは、論理チャネルのデータ送信のためにＴＢサイズを選択する前に、まず、ブール値の通知をチェックすることによって、ＴＢ選択制約がこの論理チャネルに適用されるかどうか確認してよい。
ＴＢ制約がこの論理チャネルに適用される場合（ブール値が「Ｔｒｕｅ」に設定）、ＵＥは設定されたＴＢサイズ（例えば、閾値、制限値、または最大値）をさらに確認し、設定されたＴＢサイズよりも大きいＴＢサイズは選択できない。
一方、ＴＢサイズ制約がこの論理チャネルに適用されない場合（ブール値が「Ｆａｌｓｅ」に設定）、ＵＥは設定されたＴＢサイズを確認しなくてよい。制約が適用されるかどうかのブール値の通知と、最大ＴＢサイズを規定する通知がともに論理チャネルの設定に含まれる場合、制約の下で許可されるＴＢサイズは、システム情報内でシグナリングされなくてよい。一例は、「ＴＢ＿ＳｅｌｅｃｔｉｏｎＲｅｓｔｒｉｃｔｉｏｎＡｐｐｌｉｅｄＲＡＣＨ」および「ｍａｘ＿ＴＢｓｉｚｅＦｏｒＲＡＣＨ」という通知を伴う、論理チャネルごとの設定の以下のシグナリングに示される。
LogicalChannelConfig ::= SEQUENCE {
ul-SpecificParameters SEQUENCE {
priority INTEGER (1..16),
prioritisedBitRate ENUMERATED {kBps0, kBps8, kBps16, kBps32, kBps64, kBps128, kBps256, kBps512,
kBps1024, kBps2048, kBps4096, kBps8192, kBps16384, kBps32768, kBps65536, infinity},
bucketSizeDuration ENUMERATED {ms5, ms10, ms20, ms50, ms100, ms150, ms300, ms500, ms1000,
spare7, spare6, spare5, spare4, spare3,spare2, spare1},
allowedServingCells SEQUENCE (SIZE (1..maxNrofServingCells-1)) OF ServCellIndex
OPTIONAL, -- PDCP-CADuplication
allowedSCS-List SEQUENCE (SIZE (1..maxSCSs)) OF SubcarrierSpacing OPTIONAL, -- Need R
maxPUSCH-Duration ENUMERATED {ms0p02, ms0p04, ms0p0625, ms0p125, ms0p25, ms0p5, spare2, spare1}
OPTIONAL, -- Need R
configuredGrantType1Allowed ENUMERATED {true} OPTIONAL, -- Need R
logicalChannelGroup INTEGER (0..maxLCG-ID) OPTIONAL, -- Need R
schedulingRequestID SchedulingRequestId OPTIONAL, -- Need R
logicalChannelSR-Mask BOOLEAN,
logicalChannelSR-DelayTimerApplied BOOLEAN,
TB_SelectionRestrictionAppliedRACH BOOLEAN,
max_TBsizeForRACH ENUMERATED {b100, b200, b300, b400}
...,
bitRateQueryProhibitTimer ENUMERATED { s0, s0dot4, s0dot8, s1dot6, s3, s6, s12,s30} OPTIONAL -- Need R
} OPTIONAL, -- Cond UL
...
}
また、上記「ブール値または整数の通知」、「ＴＢサイズ制限の通知」、「ランダムアクセスの種類によるＴＢ制約」のそれぞれにおけるＴＢサイズ制約を組み合わせてもよい。
例えば、ネットワークは、データ送信のために許容される最大ＴＢサイズとともに、二段階ＲＡＣＨタイプと四段階ＲＡＣＨタイプにそれぞれ個別のＴＢサイズ制約を設定する。これは、論理チャネルごとの設定におけるそれぞれのブール値の通知「ＴＢ＿ＳｅｌｅｃｔｉｏｎＲｅｓｔｒｉｃｔｉｏｎＡｐｐｌｉｅｄ２ｓｔｅｐＲＡＣＨ」および「ＴＢ＿ＳｅｌｅｃｔｉｏｎＲｅｓｔｒｉｃｔｉｏｎＡｐｐｌｉｅｄ４ｓｔｅｐＲＡＣＨ」、並びに、対応する情報エレメント「ｍａｘ＿ＴＢｓｉｚｅＦｏｒ２ｓｔｅｐＲＡＣＨ」および「ｍａｘ＿ＴＢｓｉｚｅＦｏｒ４ｓｔｅｐＲＡＣＨ」を含む以下のシグナリング例に示される。
LogicalChannelConfig ::= SEQUENCE {
ul-SpecificParameters SEQUENCE {
priority INTEGER (1..16),
prioritisedBitRate ENUMERATED {kBps0, kBps8, kBps16, kBps32, kBps64, kBps128, kBps256, kBps512,
kBps1024, kBps2048, kBps4096, kBps8192, kBps16384, kBps32768, kBps65536, infinity},
bucketSizeDuration ENUMERATED {ms5, ms10, ms20, ms50, ms100, ms150, ms300, ms500, ms1000,
spare7, spare6, spare5, spare4, spare3,spare2, spare1},
allowedServingCells SEQUENCE (SIZE (1..maxNrofServingCells-1)) OF ServCellIndex
OPTIONAL, -- PDCP-CADuplication
allowedSCS-List SEQUENCE (SIZE (1..maxSCSs)) OF SubcarrierSpacing OPTIONAL, -- Need R
maxPUSCH-Duration ENUMERATED {ms0p02, ms0p04, ms0p0625, ms0p125, ms0p25, ms0p5, spare2, spare1}
OPTIONAL, -- Need R
configuredGrantType1Allowed ENUMERATED {true} OPTIONAL, -- Need R
logicalChannelGroup INTEGER (0..maxLCG-ID) OPTIONAL, -- Need R
schedulingRequestID SchedulingRequestId OPTIONAL, -- Need R
logicalChannelSR-Mask BOOLEAN,
logicalChannelSR-DelayTimerApplied BOOLEAN,
TB_SelectionRestrictionApplied2stepRACH BOOLEAN,
max_TBsizeFor2stepRACH ENUMERATED {b100, b200, b300, b400, b500, b1000}
TB_SelectionRestrictionApplied4stepRACH BOOLEAN,
max_TBsizeFor4stepRACH ENUMERATED {b100, b200, b300, b400, b500, b1000}
...,
bitRateQueryProhibitTimer ENUMERATED { s0, s0dot4, s0dot8, s1dot6, s3, s6, s12,s30} OPTIONAL -- Need R
} OPTIONAL, -- Cond UL
...
}
他の選択肢として、ネットワークは、以下のＲＲＣシグナリングの例に示されるように、論理チャネルごとの設定に、ＲＡＣＨタイプごとにＴＢサイズ制約がそれぞれ適用されるかどうかを示すブール値を含めることによって、ＴＢサイズ制約を設定する。
LogicalChannelConfig ::= SEQUENCE {
ul-SpecificParameters SEQUENCE {
priority INTEGER (1..16),
prioritisedBitRate ENUMERATED {kBps0, kBps8, kBps16, kBps32, kBps64, kBps128, kBps256, kBps512,
kBps1024, kBps2048, kBps4096, kBps8192, kBps16384, kBps32768, kBps65536, infinity},
bucketSizeDuration ENUMERATED {ms5, ms10, ms20, ms50, ms100, ms150, ms300, ms500, ms1000,
spare7, spare6, spare5, spare4, spare3,spare2, spare1},
allowedServingCells SEQUENCE (SIZE (1..maxNrofServingCells-1)) OF ServCellIndex
OPTIONAL, -- PDCP-CADuplication
allowedSCS-List SEQUENCE (SIZE (1..maxSCSs)) OF SubcarrierSpacing OPTIONAL, -- Need R
maxPUSCH-Duration ENUMERATED {ms0p02, ms0p04, ms0p0625, ms0p125, ms0p25, ms0p5, spare2, spare1}
OPTIONAL, -- Need R
configuredGrantType1Allowed ENUMERATED {true} OPTIONAL, -- Need R
logicalChannelGroup INTEGER (0..maxLCG-ID) OPTIONAL, -- Need R
schedulingRequestID SchedulingRequestId OPTIONAL, -- Need R
logicalChannelSR-Mask BOOLEAN,
logicalChannelSR-DelayTimerApplied BOOLEAN,
TB_SelectionRestrictionApplied2stepRACH BOOLEAN,
TB_SelectionRestrictionApplied4stepRACH BOOLEAN, ...,
bitRateQueryProhibitTimer ENUMERATED { s0, s0dot4, s0dot8, s1dot6, s3, s6, s12,s30} OPTIONAL -- Need R
} OPTIONAL, -- Cond UL
...
}
上記のような論理チャネルごとの設定によって通知されるＴＢサイズ制約の下で選択可能なＴＢサイズやＴＢサイズの範囲は、以下の例に示すように、システム情報においてＲＡＣＨタイプごとに設けられてもよい。
PreambleInfo ::= SEQUENCE {
numberOfRA-Preambles
TB-selectionrestrictionApplied2stepRACH_False INTEGER (1…6)
TB-selectionrestrictionApplied2stepRACH_True INTEGER (1…4)
TBsize ENUMERATED (b100, b200, b300, b400, b500, b600)

PreambleInfo ::= SEQUENCE {
numberOfRA-Preambles
TB-selectionrestrictionApplied4stepRACH_False INTEGER (1…6)
TB-selectionrestrictionApplied4stepRACH_True INTEGER (1…4)
...TBsize ENUMERATED (b100, b200, b300, b400, b500, b600)
上述のように、ＴＢサイズ制約の設定の様々な例が示された。ただし、本開示はこれらの実施例に限定されず、他の組み合わせを排除するものではない。
本開示は、ソフトウェア、ハードウェア又はハードウェアと連動するソフトウェアによって実現することができる。上述した各実施例の説明に用いた各機能ブロックは、集積回路（ＩＣ）等のＬＳＩ（Ｌａｒｇｅ Ｓｃａｌｅ Ｉｎｔｅｇｒａｔｉｏｎ）によって部分的又は全体的に実現可能であり、各実施例で説明される各処理は、同一のＬＳＩ又はＬＳＩの組み合わせによって部分的又は全体的に制御されてもよい。ＬＳＩは、個別にチップとして形成されていてもよいし、あるいは、機能ブロックの一部又は全部を含むように１つのチップが形成されていてもよい。ＬＳＩは、それに結合されたデータ入出力を含んでもよい。ここで、ＬＳＩとは、集積度の違いにより、ＩＣ、システムＬＳＩ、スーパーＬＳＩ又はウルトラＬＳＩとして呼ばれうる。しかし、集積回路を実現する技術はＬＳＩに限定されず、専用回路、汎用プロセッサ又は特定用途向けプロセッサを用いて実現されてもよい。さらに、ＬＳＩ内部に配置される回路セルの接続及び設定が再設定可能なＬＳＩ又はリコンフィギュラブルプロセッサの製造後にプログラミング可能なＦＰＧＡ（Ｆｉｅｌｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ）が利用されてもよい。本開示は、デジタル処理又はアナログ処理として実現することができる。半導体技術や他の派生技術の進歩の結果として、将来の集積回路技術がＬＳＩに取って代わる場合、機能ブロックは、将来の集積回路技術を用いて集積化することができる。バイオテクノロジーも適用できる。
本開示は、通信装置と呼ばれる、通信機能を有する何れかのタイプの装置、デバイス又はシステムによって実現することができる。
通信装置は、送受信機及び処理／制御回路を有してもよい。送受信機は、受信機及び送信機を有し、及び／又は機能してもよい。送信機及び受信機としての送受信機は、増幅器、ＲＦ変調器／復調器など及び１つ以上のアンテナを含むＲＦ（Ｒａｄｉｏ Ｆｒｅｑｕｅｎｃｙ）モジュールを含んでもよい。
そのような通信装置のいくつかの非限定的な例は、電話機（例えば、携帯（セル）電話、スマートフォン）、タブレット、パーソナルコンピュータ（ＰＣ）（例えば、ラップトップ、デスクトップ、ネットブック）、カメラ（例えば、デジタルスチル／ビデオカメラ）、デジタルプレーヤ（デジタルオーディオ／ビデオプレーヤ）、ウェアラブルデバイス（例えば、ウェアラブルカメラ、スマートウォッチ、トラッキングデバイス）、ゲームコンソール、デジタルブックリーダ、遠隔ヘルス／遠隔医療（リモートヘルス及びリモート医療）デバイス、及び通信機能を提供する車両（例えば、自動車、飛行機、船舶）、並びにそれらの様々な組み合わせを含む。
通信装置は、携帯型又は可動型であることに限定されず、スマートホームデバイス（例えば、家電、ライティング、スマートメータ、制御パネル）、自動販売機及び“Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ（ＩｏＴ）”のネットワークにおける他の何れかの“物”など、非携帯型又は固定型である何れかのタイプの装置、デバイス又はシステムを含んでもよい。
通信は、例えば、セルラシステム、無線ＬＡＮシステム、衛星システムなど、及びそれらの様々な組み合わせを介してデータを交換することを含んでもよい。通信装置は、本開示に記載された通信の機能を実行する通信デバイスに結合されたコントローラ又はセンサなどのデバイスを含んでもよい。例えば、通信装置は、通信装置の通信機能を実行する通信デバイスによって使用される制御信号又はデータ信号を生成するコントローラ又はセンサを含んでもよい。
通信装置はまた、基地局、アクセスポイントなどのインフラストラクチャファシリティと、上記の非限定的な例におけるものなどの装置と通信又は制御する他の何れかの装置、デバイス又はシステムを含んでもよい。
提供される通信装置は、動作時に、ランダムアクセス手順の間に送信される論理チャネルのデータのための、論理チャネルごとのトランスポートブロック（ＴＢ）サイズ制約と、第１ランダムアクセス手順タイプと、前記第１ランダムアクセス手順タイプよりも送信ステップ数が多い第２ランダムアクセス手順タイプの、ランダムアクセス手順タイプごとのＴＢサイズ制約のうち、少なくとも一方を含むＴＢサイズの設定を受信する送受信部と、動作時に、受信した前記ＴＢサイズの設定に基づいて、前記論理チャネルのデータの送信のための、前記ＴＢサイズと前記ランダムアクセス手順タイプのうち少なくとも一方の選択を行う回路と、を備える通信装置であって、前記送受信部は、動作時に、前記選択に従って前記論理チャネルのデータの前記送信を行う。
例えば、前記回路は、動作時に、前記論理チャネルのための前記ＴＢサイズ制約に基づいて、前記ＴＢサイズと前記ランダムアクセス手順タイプとに一対一で対応するプリアンブルを選択する。
いくつかの実施形態において、前記ＴＢサイズの設定は、ＵＥ固有の、論理チャネルごとの設定内に、前記ＴＢサイズ制約を示す通知を含む。
例えば、前記ＴＢサイズの設定は、システム情報内に、前記通知によって示される前記ＴＢサイズ制約の下で選択可能なＴＢサイズまたはＴＢサイズ範囲を含む。
いくつかの実施形態において、前記ＴＢサイズ制約の前記通知は、前記ＴＢサイズ制約が前記論理チャネルに適用されるか否かを示すブール値を含む。
いくつかの実施形態において、前記ＴＢサイズ制約の前記通知は、前記通知によって示される前記ＴＢサイズ制約の下で選択可能な複数のＴＢサイズ範囲を表す複数の整数値のうち、一つの整数値を含む。
いくつかの実施形態において、前記ＴＢサイズ制約の前記通知は、前記ＴＢサイズ制約の下で選択可能なＴＢサイズの閾値を含む。
いくつかの実施形態において、前記ランダムアクセス手順タイプごとのＴＢサイズ制約は、前記第２ランダムアクセス手順タイプよりも、前記第１ランダムアクセス手順タイプにおいて、より大きなＴＢサイズが送信されることを許容し、前記回路は、動作時に、前記論理チャネルのデータのサイズに基づいて、前記ランダムアクセス手順タイプを選択する。
例えば、前記ＴＢサイズの設定は、ＵＥ固有の、論理チャネルごとの設定内に、前記第１ランダムアクセス手順タイプが制約されるか否かを示すブール値を含む。
例えば、前記第１ランダムアクセス手順タイプは二段階ランダムアクセス手順であり、前記第２ランダムアクセス手順タイプは四段階ランダムアクセス手順である。
例えば、前記ＴＢサイズの設定はＲＲＣ（radio resource control）シグナリングにおいて受信される。
例えば、前記送受信部は、動作時に、前記ＵＥがＲＲＣ＿ＩＮＡＣＴＩＶＥ状態の間に前記論理チャネルの送信を行う。
また、提供されるネットワークノードは、動作時に、ランダムアクセス手順の間に通信装置によって送信される論理チャネルのデータのための、論理チャネルごとのトランスポートブロック（ＴＢ）サイズ制約と、第１ランダムアクセス手順タイプと、前記第１ランダムアクセス手順タイプよりも送信ステップ数が多い第２ランダムアクセス手順タイプの、ランダムアクセス手順タイプごとのＴＢサイズ制約のうち、少なくとも一方を含むＴＢサイズの設定を決定する回路と、動作時に、前記論理チャネルのデータの前記ＴＢサイズの設定を送信し、送信された前記設定に従ったＴＢサイズの前記論理チャネルのデータを受信する送受信部と、を備える。
例えば、前記回路は、動作時に、前記ＴＢサイズと前記ランダムアクセス手順タイプとに一対一で対応するプリアンブルを設定し、前記送受信部は、動作時に、前記論理チャネルのための前記ＴＢサイズ制約に基づいて、前記プリアンブルを受信する。
いくつかの実施形態において、前記ＴＢサイズの設定は、ＵＥ固有の、論理チャネルごとの設定内に、前記ＴＢサイズ制約を示す通知を含む。
例えば、前記ＴＢサイズの設定は、システム情報内に、前記通知によって示される前記ＴＢサイズ制約の下で選択可能なＴＢサイズまたはＴＢサイズ範囲を含む。
いくつかの実施形態において、前記ＴＢサイズ制約の前記通知は、前記通知によって示される前記ＴＢサイズ制約の下で選択可能な複数のＴＢサイズ範囲を表す複数の整数値のうち、一つの整数値を含む。
例えば、前記ＴＢサイズ制約の前記通知は、前記ＴＢサイズ制約の下で選択可能なＴＢサイズの閾値を含む。
いくつかの実施形態において、前記ランダムアクセス手順タイプごとのＴＢサイズ制約は、前記第２ランダムアクセス手順タイプよりも、前記第１ランダムアクセス手順タイプにおいて、より大きなＴＢサイズが送信されることを許容する。
例えば、前記ＴＢサイズの設定は、ＵＥ固有の、論理チャネルごとの設定内に、前記第１ランダムアクセス手順タイプが制約されるか否かを示すブール値を含む。
例えば、前記第１ランダムアクセス手順タイプは二段階ランダムアクセス手順であり、前記第２ランダムアクセス手順タイプは四段階ランダムアクセス手順である。
例えば、前記ＴＢサイズの設定はＲＲＣ（radio resource control）シグナリングにおいて送信される。
例えば、送受信部は、動作時に、ＲＲＣ＿ＩＮＡＣＴＩＶＥ状態のＵＥからの前記送信を受信する。
また、提供される通信方法は、通信装置によって実行される通信方法であって、ランダムアクセス手順の間に送信される論理チャネルのデータのための、論理チャネルごとのトランスポートブロック（ＴＢ）サイズ制約と、第１ランダムアクセス手順タイプと、前記第１ランダムアクセス手順タイプよりも送信ステップ数が多い第２ランダムアクセス手順タイプの、ランダムアクセス手順タイプごとのＴＢサイズ制約のうち、少なくとも一方を含むＴＢサイズの設定を受信することと、受信した前記ＴＢサイズの設定に基づいて、前記論理チャネルのデータの送信のための、前記ＴＢサイズと前記ランダムアクセス手順タイプのうち少なくとも一方の選択を行うことと、前記選択に従って前記論理チャネルのデータの前記送信を行うことと、を含む。
いくつかの実施形態において、前記方法は、前記論理チャネルのための前記ＴＢサイズ制約に基づいて、前記ＴＢサイズと前記ランダムアクセス手順タイプとに一対一で対応するプリアンブルを選択することを含む。
いくつかの実施形態において、前記ＴＢサイズの設定は、ＵＥ固有の、論理チャネルごとの設定内に、前記ＴＢサイズ制約を示す通知を含む。
例えば、前記ＴＢサイズの設定は、システム情報内に、前記通知によって示される前記ＴＢサイズ制約の下で選択可能なＴＢサイズまたはＴＢサイズ範囲を含む。
例えば、前記ＴＢサイズ制約の前記通知は、前記ＴＢサイズ制約が前記論理チャネルに適用されるか否かを示すブール値を含む。
いくつかの実施形態において、前記ＴＢサイズ制約の前記通知は、前記通知によって示される前記ＴＢサイズ制約の下で選択可能な複数のＴＢサイズ範囲を表す複数の整数値のうち、一つの整数値を含む。
例えば、前記ＴＢサイズ制約の前記通知は、前記ＴＢサイズ制約の下で選択可能なＴＢサイズの閾値を含む。
いくつかの実施形態において、前記ランダムアクセス手順タイプごとのＴＢサイズ制約は、前記第２ランダムアクセス手順タイプよりも、前記第１ランダムアクセス手順タイプにおいて、より大きなＴＢサイズが送信されることを許容し、前記方法は、前記論理チャネルのデータのサイズに基づいて、前記ランダムアクセス手順タイプを選択することを含む。
例えば、前記ＴＢサイズの設定は、ＵＥ固有の、論理チャネルごとの設定内に、前記第１ランダムアクセス手順タイプが制約されるか否かを示すブール値を含む。
例えば、前記第１ランダムアクセス手順タイプは二段階ランダムアクセス手順であり、前記第２ランダムアクセス手順タイプは四段階ランダムアクセス手順である。
例えば、前記ＴＢサイズの設定はＲＲＣ（radio resource control）シグナリングにおいて受信される。
例えば、論理チャネルの送信は、ＵＥがＲＲＣ＿ＩＮＡＣＴＩＶＥ状態の間に行われる。
また、提供される通信方法は、ネットワークノードによって実行される通信方法であって、ランダムアクセス手順の間に通信装置によって送信される論理チャネルのデータのための、論理チャネルごとのトランスポートブロック（ＴＢ）サイズ制約と、第１ランダムアクセス手順タイプと、前記第１ランダムアクセス手順タイプよりも送信ステップ数が多い第２ランダムアクセス手順タイプの、ランダムアクセス手順タイプごとのＴＢサイズ制約のうち、少なくとも一方を含むＴＢサイズの設定を決定することと、前記論理チャネルのデータの前記ＴＢサイズの設定を送信することと、送信された前記設定に従ったＴＢサイズの前記論理チャネルのデータを受信することと、を含む。
例えば、前記方法は、前記ＴＢサイズと前記ランダムアクセス手順タイプとに一対一で対応するプリアンブルを設定することを含み、前記送受信部は、動作時に、前記論理チャネルのための前記ＴＢサイズ制約に基づいて、前記プリアンブルを受信する。
いくつかの実施形態において、前記ＴＢサイズの設定は、ＵＥ固有の、論理チャネルごとの設定内に、前記ＴＢサイズ制約を示す通知を含む。
例えば、前記ＴＢサイズの設定は、システム情報内に、前記通知によって示される前記ＴＢサイズ制約の下で選択可能なＴＢサイズまたはＴＢサイズ範囲を含む。
いくつかの実施形態において、前記ＴＢサイズ制約の前記通知は、前記通知によって示される前記ＴＢサイズ制約の下で選択可能な複数のＴＢサイズ範囲を表す複数の整数値のうち、一つの整数値を含む。
例えば、前記ＴＢサイズ制約の前記通知は、前記ＴＢサイズ制約の下で選択可能なＴＢサイズの閾値を含む。
いくつかの実施形態において、前記ランダムアクセス手順タイプごとのＴＢサイズ制約は、前記第２ランダムアクセス手順タイプよりも、前記第１ランダムアクセス手順タイプにおいて、より大きなＴＢサイズが送信されることを許容する。
例えば、前記ＴＢサイズの設定は、ＵＥ固有の、論理チャネルごとの設定内に、前記第１ランダムアクセス手順タイプが制約されるか否かを示すブール値を含む。
例えば、前記第１ランダムアクセス手順タイプは二段階ランダムアクセス手順であり、前記第２ランダムアクセス手順タイプは四段階ランダムアクセス手順である。
例えば、前記ＴＢサイズの設定はＲＲＣ（radio resource control）シグナリングにおいて送信される。
例えば、前記論理チャネルの送信は、ＲＲＣ＿ＩＮＡＣＴＩＶＥ状態のＵＥから受信される。
つまり、通信装置と、ネットワークノードと、対応する方法とが提供される。通信装置は、動作時に、ランダムアクセス手順の間に送信される論理チャネルのデータのための、論理チャネルごとのトランスポートブロック（ＴＢ）サイズ制約と、第１ランダムアクセス手順タイプと、前記第１ランダムアクセス手順タイプよりも送信ステップ数が多い第２ランダムアクセス手順タイプの、ランダムアクセス手順タイプごとのＴＢサイズ制約のうち、少なくとも一方を含むＴＢサイズの設定を受信する送受信部と、動作時に、受信した前記ＴＢサイズの設定に基づいて、前記論理チャネルのデータの送信のための、前記ＴＢサイズと前記ランダムアクセス手順タイプのうち少なくとも一方の選択を行う回路と、を備え、前記送受信部は、動作時に、前記選択に従って前記論理チャネルのデータの前記送信を行う。

Claims (17)

  1. 動作時に、ランダムアクセス手順の間に送信される論理チャネルのデータのための、
    論理チャネルごとのトランスポートブロック（ＴＢ）サイズ制約と、
    第１ランダムアクセス手順タイプと、前記第１ランダムアクセス手順タイプよりも送信ステップ数が多い第２ランダムアクセス手順タイプの、ランダムアクセス手順タイプごとのＴＢサイズ制約のうち、
    少なくとも一方を含むＴＢサイズの設定を受信する送受信部と、
    動作時に、受信した前記ＴＢサイズの設定に基づいて、前記論理チャネルのデータの送信のための、前記ＴＢサイズと前記ランダムアクセス手順タイプのうち少なくとも一方の選択を行う回路と、
    を備える通信装置であって、
    前記送受信部は、動作時に、前記選択に従って前記論理チャネルのデータの前記送信を行う、
    通信装置。
  2. 前記回路は、動作時に、前記論理チャネルのための前記ＴＢサイズ制約に基づいて、前記ＴＢサイズと前記ランダムアクセス手順タイプとに一対一で対応するプリアンブルを選択する、
    請求項１に記載の通信装置。
  3. 前記ＴＢサイズの設定は、ＵＥ固有の、論理チャネルごとの設定内に、前記ＴＢサイズ制約を示す通知を含む、
    請求項１または２に記載の通信装置。
  4. 前記ＴＢサイズの設定は、システム情報内に、前記通知によって示される前記ＴＢサイズ制約の下で選択可能なＴＢサイズまたはＴＢサイズ範囲を含む、
    請求項３に記載の通信装置。
  5. 前記ＴＢサイズ制約の前記通知は、前記ＴＢサイズ制約が前記論理チャネルに適用されるか否かを示すブール値を含む、
    請求項３または４に記載の通信装置。
  6. 前記ＴＢサイズ制約の前記通知は、前記通知によって示される前記ＴＢサイズ制約の下で選択可能な複数のＴＢサイズ範囲を表す複数の整数値のうち、一つの整数値を含む、
    請求項３または４に記載の通信装置。
  7. 前記ＴＢサイズ制約の前記通知は、前記ＴＢサイズ制約の下で選択可能なＴＢサイズの閾値を含む、
    請求項３から６の何れか一項に記載の通信装置。
  8. 前記ランダムアクセス手順タイプごとのＴＢサイズ制約は、前記第２ランダムアクセス手順タイプよりも、前記第１ランダムアクセス手順タイプにおいて、より大きなＴＢサイズが送信されることを許容し、
    前記回路は、動作時に、前記論理チャネルのデータのサイズに基づいて、前記ランダムアクセス手順タイプを選択する、
    請求項１から７の何れか一項に記載の通信装置。
  9. 前記ＴＢサイズの設定は、ＵＥ固有の、論理チャネルごとの設定内に、前記第１ランダムアクセス手順タイプが制約されるか否かを示すブール値を含む、
    請求項８に記載の通信装置。
  10. 前記第１ランダムアクセス手順タイプは二段階ランダムアクセス手順であり、前記第２ランダムアクセス手順タイプは四段階ランダムアクセス手順である、
    請求項１から９の何れか一項に記載の通信装置。
  11. 前記ＴＢサイズの設定はＲＲＣ（radio resource control）シグナリングにおいて受信される、
    請求項１から１０の何れか一項に記載の通信装置。
  12. 前記送受信部は、動作時に、前記ＵＥがＲＲＣ＿ＩＮＡＣＴＩＶＥ状態の間に前記論理チャネルの送信を行う、
    請求項１から１０の何れか一項に記載の通信装置。
  13. 動作時に、ランダムアクセス手順の間に通信装置によって送信される論理チャネルのデータのための、
    論理チャネルごとのトランスポートブロック（ＴＢ）サイズ制約と、
    第１ランダムアクセス手順タイプと、前記第１ランダムアクセス手順タイプよりも送信ステップ数が多い第２ランダムアクセス手順タイプの、ランダムアクセス手順タイプごとのＴＢサイズ制約のうち、
    少なくとも一方を含むＴＢサイズの設定を決定する回路と、
    動作時に、前記論理チャネルのデータの前記ＴＢサイズの設定を送信し、送信された前記設定に従ったＴＢサイズの前記論理チャネルのデータを受信する送受信部と、
    を備えるネットワークノード。
  14. 通信装置によって実行される通信方法であって、
    ランダムアクセス手順の間に送信される論理チャネルのデータのための、
    論理チャネルごとのトランスポートブロック（ＴＢ）サイズ制約と、
    第１ランダムアクセス手順タイプと、前記第１ランダムアクセス手順タイプよりも送信ステップ数が多い第２ランダムアクセス手順タイプの、ランダムアクセス手順タイプごとのＴＢサイズ制約のうち、
    少なくとも一方を含むＴＢサイズの設定を受信することと、
    受信した前記ＴＢサイズの設定に基づいて、前記論理チャネルのデータの送信のための、前記ＴＢサイズと前記ランダムアクセス手順タイプのうち少なくとも一方の選択を行うことと、
    前記選択に従って前記論理チャネルのデータの前記送信を行うことと、
    を含む通信方法。
  15. ネットワークノードによって実行される通信方法であって、
    ランダムアクセス手順の間に通信装置によって送信される論理チャネルのデータのための、
    論理チャネルごとのトランスポートブロック（ＴＢ）サイズ制約と、
    第１ランダムアクセス手順タイプと、前記第１ランダムアクセス手順タイプよりも送信ステップ数が多い第２ランダムアクセス手順タイプの、ランダムアクセス手順タイプごとのＴＢサイズ制約のうち、
    少なくとも一方を含むＴＢサイズの設定を決定することと、
    前記論理チャネルのデータの前記ＴＢサイズの設定を送信することと、
    送信された前記設定に従ったＴＢサイズの前記論理チャネルのデータを受信することと、
    を含む通信方法。
  16. 動作時に、通信装置の処理を制御する集積回路であって、
    前記処理は、
    ランダムアクセス手順の間に送信される論理チャネルのデータのための、
    論理チャネルごとのトランスポートブロック（ＴＢ）サイズ制約と、
    第１ランダムアクセス手順タイプと、前記第１ランダムアクセス手順タイプよりも送信ステップ数が多い第２ランダムアクセス手順タイプの、ランダムアクセス手順タイプごとのＴＢサイズ制約のうち、
    少なくとも一方を含むＴＢサイズの設定を受信することと、
    受信した前記ＴＢサイズの設定に基づいて、前記論理チャネルのデータの送信のための、前記ＴＢサイズと前記ランダムアクセス手順タイプのうち少なくとも一方の選択を行うことと、
    前記選択に従って前記論理チャネルのデータの前記送信を行うことと、を含む
    集積回路。
  17. 動作時に、ネットワークノードの処理を制御する集積回路であって、
    前記処理は、
    ランダムアクセス手順の間に通信装置によって送信される論理チャネルのデータのための、
    論理チャネルごとのトランスポートブロック（ＴＢ）サイズ制約と、
    第１ランダムアクセス手順タイプと、前記第１ランダムアクセス手順タイプよりも送信ステップ数が多い第２ランダムアクセス手順タイプの、ランダムアクセス手順タイプごとのＴＢサイズ制約のうち、
    少なくとも一方を含むＴＢサイズの設定を決定することと、
    前記論理チャネルのデータの前記ＴＢサイズの設定を送信することと、
    送信された前記設定に従ったＴＢサイズの前記論理チャネルのデータを受信することと、を含む
    集積回路。
JP2022547927A 2020-02-21 2020-12-18 トランスポートブロックサイズの制約を適用した、ランダムアクセス時の小容量データ送信のための通信装置およびネットワークノード Pending JP2023514146A (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
EP20158823.3A EP3869901A1 (en) 2020-02-21 2020-02-21 Communication apparatus and network node for small data transmission during random access applying a transport block size restriction
EP20158823.3 2020-02-21
PCT/EP2020/087210 WO2021164928A1 (en) 2020-02-21 2020-12-18 Communication apparatus and network node for small data transmission during random access applying a transport block size restriction

Publications (1)

Publication Number Publication Date
JP2023514146A true JP2023514146A (ja) 2023-04-05

Family

ID=69723873

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2022547927A Pending JP2023514146A (ja) 2020-02-21 2020-12-18 トランスポートブロックサイズの制約を適用した、ランダムアクセス時の小容量データ送信のための通信装置およびネットワークノード

Country Status (4)

Country Link
US (1) US20230084062A1 (ja)
EP (2) EP3869901A1 (ja)
JP (1) JP2023514146A (ja)
WO (1) WO2021164928A1 (ja)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115316024A (zh) * 2022-06-02 2022-11-08 上海移远通信技术股份有限公司 无线通信的方法及装置

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR102397297B1 (ko) * 2016-09-28 2022-05-13 소니그룹주식회사 차세대 무선 시스템들에서의 랜덤 액세스

Also Published As

Publication number Publication date
US20230084062A1 (en) 2023-03-16
EP4108034A1 (en) 2022-12-28
WO2021164928A1 (en) 2021-08-26
EP3869901A1 (en) 2021-08-25

Similar Documents

Publication Publication Date Title
US20220167352A1 (en) User equipment and scheduling node
JP7510962B2 (ja) ユーザ機器および基地局
EP3893422A1 (en) Communication apparatus and base station
US20220287008A1 (en) Communication apparatuses and communication methods for utilization of released resource
EP4038977A1 (en) User equipment and scheduling node
JP2022550879A (ja) クロススロットスケジューリング適応のためのデバイスおよび方法
WO2021066741A1 (en) Communication apparatuses and communication methods for utilisation of sl-rsrp in v2x resource sensing and selection
JP2023514146A (ja) トランスポートブロックサイズの制約を適用した、ランダムアクセス時の小容量データ送信のための通信装置およびネットワークノード
EP3914009A1 (en) Buffer status report enhancement
WO2022086437A1 (en) Enhancing uplink transmission with multiple beams
WO2021167527A1 (en) Communication apparatuses and communication methods for utilization of reserved resource
WO2024034227A1 (ja) 通信装置、及び、通信方法
WO2022030113A1 (ja) 基地局、端末及び通信方法
WO2023203938A1 (ja) 端末、基地局、通信方法及び集積回路
WO2023204060A1 (ja) 通信装置、及び、通信方法
EP4322669A1 (en) User equipment, scheduling node, method for user equipment, and method for scheduling node
WO2023132786A2 (en) Advance indication of resource selection
KR20240041920A (ko) 사이드링크 신호를 위한 하나 이상의 추가 동작 윈도를 할당하는 통신 장치 및 통신 방법
JP2024528082A (ja) 制御チャネルキャリアスイッチングのためのリソース指示に関与するユーザ機器および基地局
WO2024068136A1 (en) User equipment and base station involved in time-division communication
KR20230162608A (ko) 통신 장치 및 통신 방법

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20231214