JP2022521086A - 送受信デバイス及びスケジューリングデバイス - Google Patents

送受信デバイス及びスケジューリングデバイス Download PDF

Info

Publication number
JP2022521086A
JP2022521086A JP2021548627A JP2021548627A JP2022521086A JP 2022521086 A JP2022521086 A JP 2022521086A JP 2021548627 A JP2021548627 A JP 2021548627A JP 2021548627 A JP2021548627 A JP 2021548627A JP 2022521086 A JP2022521086 A JP 2022521086A
Authority
JP
Japan
Prior art keywords
scheduling request
scheduling
request
during operation
transmission
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.)
Granted
Application number
JP2021548627A
Other languages
English (en)
Other versions
JP7478745B2 (ja
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 JP2022521086A publication Critical patent/JP2022521086A/ja
Application granted granted Critical
Publication of JP7478745B2 publication Critical patent/JP7478745B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/12—Wireless traffic scheduling
    • H04W72/1263—Mapping of traffic onto schedule, e.g. scheduled allocation or multiplexing of flows
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/20—Control channels or signalling for resource management
    • H04W72/21—Control channels or signalling for resource management in the uplink direction of a wireless link, i.e. towards the network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/04—Wireless resource allocation
    • H04W72/044—Wireless resource allocation based on the type of the allocated resource
    • H04W72/0446—Resources in time domain, e.g. slots or frames
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/02—Data link layer protocols

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

本開示は、動作中に、ＰＵＣＣＨ（Ｐｈｙｓｉｃａｌ Ｕｐｌｉｎｋ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ）の複数の機会でスケジューリングリクエストを送信するよう送受信機に指示することによって、ＭＡＣ（Ｍｅｄｉｕｍ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）レイヤ上でスケジューリングリクエストを繰り返す回路と、動作中に、ＰＵＣＣＨ上でスケジューリングリクエストを送信する送受信機と、を有する送受信デバイスを提供する。

Description

本開示は、通信システムにおける信号の送信及び受信に関する。特に、本開示は、このような送信及び受信のための方法及び装置に関する。
３ＧＰＰ（３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ）は、サブ１ＧＨｚからミリ波帯までの範囲の周波数で動作する“Ｎｅｗ Ｒａｄｉｏ”（ＮＲ）無線アクセス技術（ＲＡＴ）を含む、第５世代（５Ｇ）とも呼ばれる次世代セルラ技術のための技術仕様に取り組んでいる。ＮＲは、ＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）及びＬＴＥ－Ａ（ＬＴＥ Ａｄｖａｎｃｅｄ）によって表現される技術の後継である。
ＬＴＥ、ＬＴＥ－Ａ及びＮＲなどのシステムについて、更なる改良及び選択肢は、システムに関する特定のデバイスとともに、通信システムの効率的な処理を容易にするものであってもよい。
１つの非限定的で例示的な実施例は、リソース割当てに対する信頼できる低遅延のリクエストを提供することを容易にする。
実施例では、ここに開示される技術は、動作中に、ＰＵＣＣＨ（Ｐｈｙｓｉｃａｌ Ｕｐｌｉｎｋ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ）の複数の機会でスケジューリングリクエストを送信するよう送受信機に指示することによって、ＭＡＣ（Ｍｅｄｉｕｍ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）レイヤ上でスケジューリングリクエストを繰り返す回路と、動作中に、前記ＰＵＣＣＨ上で前記スケジューリングリクエストを送信する前記送受信機と、を有する送受信デバイスを特徴とする。
一般的又は具体的な実施例は、システム、方法、集積回路、コンピュータプログラム、記憶媒体又はそれらの何れかの選択的な組合せとして実現されてもよいことが留意されるべきである。
開示された実施例の追加的な利点及び効果は、明細書及び図面から明らかになるであろう。利点及び／又は効果は、明細書及び図面の各種実施例及び特徴によって個別に取得されてもよく、これらの全てが、そのような利点及び／又は効果のうちの１つ以上を取得するため提供される必要はない。
以下において、例示的な実施例が、添付した図面を参照してより詳細に説明される。
ＬＴＥ ｅＮＢ、ｇＮＢ及びＵＥのための一例となるユーザ及び制御プレーンアーキテクチャを含む３ＧＰＰ ＮＲシステムのための一例となるアーキテクチャを示す。 トランスペアレント衛星による非地上ネットワークシナリオを示す。 ｇＮＢが衛星上に実装される非地上ネットワークシナリオを示す。 ３ＧＰＰ ＴＲ３８．３２１に規定されるようなスケジューリングリクエストの設定のために利用されるスケジューリングリクエストコンフィギュレーション情報要素を示す。 特定の周期で設定されるスケジューリングリクエストの送信を示す。 ＰＵＣＣＨ繰り返しによるスケジューリングリクエストの繰り返しの送信の概略図である。 実施例によるスケジューリングデバイス及び送受信デバイスの機能コンポーネントを示すブロック図である。 実施例によるＭＡＣレイヤ上でトリガされる複数の機会でのスケジューリングリクエストの送信の概略図である。 論理チャネル毎の単一のスケジューリングリクエストコンフィギュレーションのマッピングを概略的に示す。 許容可能なスケジューリングリクエストの送信数の指定を含むＮＲ論理チャネルコンフィギュレーション要素の具体例を示す。 ＳＲの送信数がＳＲの繰り返しが設定されない低優先度論理チャネルと高優先度論理チャネルについて設定されることを示す。 複数の機会でのスケジューリングリクエストの送信後にスケジューリングリクエスト禁止タイマが始動される実施例によるＭＡＣレイヤ上でトリガされる複数の機会でのスケジューリングリクエストの送信の概略図である。 複数回のスケジューリングリクエストの送信後にスケジューリングリクエスト禁止タイマが始動され、２フレーム毎のスロットｎにおける周期が適用される実施例によるＭＡＣレイヤ上でトリガされる複数の機会でのスケジューリングリクエストの送信の概略図である。 実施例による複数の機会でのスケジューリングリクエストの送信を示すフローチャートである。 実施例によるコンフィギュレーションを通知する論理チャネルコンフィギュレーション要素を示す。 論理チャネル毎に２つのスケジューリングリクエストコンフィギュレーションのマッピングを概略的に示す。 高優先度論理チャネルがＳＲコンフィギュレーション１及びＳＲコンフィギュレーション２にマッピングされ、低優先度論理チャネルがＳＲコンフィギュレーション２のみにマッピングされる具体例を示す。 スケジューリングの送信が２つのスケジューリングリクエストコンフィギュレーションによる機会でトリガされる実施例によるＭＡＣレイヤ上でトリガされる複数の機会でのスケジューリングリクエストの送信の概略図である。 実施例による２つのスケジューリングリクエストコンフィギュレーションによる複数の機会でのスケジューリングリクエストの送信を示すフローチャートである。 設定されたＳＲ繰り返し数による２つのＳＲコンフィギュレーションにマッピングされる論理チャネルを示す。 実施例によるコンフィギュレーションを通知する論理チャネルコンフィギュレーション要素を示す。 スケジューリングリクエストの送信が２つのスケジューリングリクエストコンフィギュレーションと設定されたＳＲ送信数とによる機会でトリガされる実施例によるＭＡＣレイヤ上でトリガされる機会でのスケジューリングリクエストの送信の概略図である。
図１は、基地局、端末及びコアネットワークを含む通信ネットワークの一例を示す。このような通信システムは、ＮＲ、ＬＴＥ及び／又はＵＭＴＳなどの３ＧＰＰシステムであってもよい。例えば、図１に示されるように、基地局（ＢＳ）は、ｇＮＢ（ｇＮｏｄｅＢ，例えば、ＮＲ基地局）又はｅＮＢ（ｅＮｏｄｅＢ，例えば、ＬＴＥ基地局）であってもよい。しかしながら、本開示は、これら３ＧＰＰシステム又は他の何れかのシステムに限定されるものでない。実施例及び例示的な実現形態が３ＧＰＰシステムのいくつかの用語を用いて説明されるが、本開示はまた他の何れかの通信システム、特に何れかのセルラ、無線及び／又は移動システムに適用可能である。
ＮＲは、例えば、ｅＭＢＢ（ｅｎｈａｎｃｅｄ Ｍｏｂｉｌｅ Ｂｒｏａｄｂａｎｄ）、ＵＲＬＬＣ（Ｕｌｔｒａ－Ｒｅｌｉａｂｌｅ Ｌｏｗ－Ｌａｔｅｎｃｙ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）、ｍＭＴＣ（ｍａｓｓｉｖｅ Ｍａｃｈｉｎｅ Ｔｙｐｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）などを含む、規定された複数の使用シナリオ、要件及び配備シナリオに対処する単一の技術的枠組みを提供することを容易にするように設計される。例えば、ｅＭＢＢ配備シナリオは、室内ホットスポット、密集した都市、地方、都市マクロ及び高速を含んでもよく、ＵＲＬＬＣ配備シナリオは、産業制御システム、モバイルヘルスケア（遠隔監視、診断及び処置）、車両のリアルタイム制御、スマートグリッドのための広域監視及び制御システムを含んでもよく、ｍＭＴＣは、スマートウェアラブル及びセンサネットワークのような非タイムクリティカルなデータ転送による多数のデバイスを備えるシナリオを含んでもよい。ｅＭＢＢ及びＵＲＬＬＣサービスは、それらの双方が非常に広い帯域幅を要求するという点で類似しているが、ＵＲＬＬＣサービスは超低遅延を要求するという点で異なっている。ＮＲでは、物理レイヤは時間－周波数リソース（ＬＴＥと同様に、ＯＦＤＭ（Ｏｒｔｈｏｇｏｎａｌ Ｆｒｅｑｕｅｎｃｙ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅｘｉｎｇ）など）に基づいており、複数アンテナ動作をサポートしてもよい。
端末は、ＬＴＥ及びＮＲにおいてユーザ装置（ＵＥ）と呼ばれる。これは、ワイヤレスフォン、スマートフォン、タブレットコンピュータ又はユーザ装置の機能を備えたＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）スティックなどの移動デバイスであってもよい。しかしながら、移動デバイスという用語はこれに限定されず、一般的には、中継がまたそのような移動デバイスの機能を有してもよく、移動デバイスはまた、中継として機能しうる。
基地局は、ネットワークノードであり、例えば、サービスを端末に提供するためのネットワークの一部を形成する。基地局は、端末に対する無線アクセスを提供するネットワークノードである。端末と基地局との間の通信は、典型的には標準化されている。ＬＴＥ及びＮＲでは、無線インタフェースプロトコルスタックは、物理レイヤ、媒体アクセスレイヤ（ＭＡＣ）及び上位レイヤを含む。制御プレーンでは、上位レイヤプロトコルであるＲＲＣ（Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ）プロトコルが提供される。ＲＲＣを介し、基地局は端末の設定を制御可能であり、端末は、接続及びベアラ確立、変更などの制御タスク、測定及び他の機能を実行するよう基地局と通信してもよい。
あるレイヤによって上位レイヤに提供されるデータの転送のためのサービスは、通常はチャネルと呼ばれる。例えば、ＬＴＥ及びＮＲは、ＭＡＣレイヤによって上位レイヤに対して提供される論理チャネル、物理レイヤによってＭＡＣレイヤによって提供されるトランスポートチャネル、及び物理リソース上のマッピングを規定する物理チャネルを区別する。
論理チャネルは、ＭＡＣによって提供される各種のデータ転送サービスである。各論理チャネルタイプは、どのタイプの情報が転送されるかによって定義される。論理チャネルは、制御チャネルとトラフィックチャネルの２つのグループに分類される。制御チャネルは、制御プレーン情報の転送のみに使用される。トラフィックチャネルは、ユーザプレーン情報の転送のみに使用される。
そして、論理チャネルは、ＭＡＣレイヤによってトランスポートチャネルにマッピングされる。例えば、論理トラフィックチャネル及びいくつかの論理制御チャネルは、ダウンリンクではＤＬ－ＳＣＨ（Ｄｏｗｎｌｉｎｋ Ｓｈａｒｅｄ Ｃｈａｎｎｅｌ）と呼ばれるトランスポートチャネル上にマッピングされてもよく、アップリンクではＵＬ－ＳＣＨ（Ｕｐｌｉｎｋ Ｓｈａｒｅｄ Ｃｈａｎｎｅｌ）と呼ばれるトランスポートチャネル上にマッピングされてもよい。
非地上ネットワーク
３ＧＰＰでは、非地上ネットワーク（ＮＴＮ）におけるＮＲベースの動作が、検討及び説明される（例えば、３ＧＰＰ ＴＲ ３８．８１１，Ｓｔｕｄｙ ｏｎ Ｎｅｗ Ｒａｄｉｏ（ＮＲ） ｔｏ ｓｕｐｐｏｒｔ ｎｏｎ－ｔｅｒｒｅｓｔｒｉａｌ ｎｅｔｗｏｒｋｓ，ｖｅｒｓｉｏｎ １５．０．０、及び３ＧＰＰ ＴＲ ３８．８２１，Ｓｏｌｕｔｉｏｎｓ ｆｏｒ ＮＲ ｔｏ ｓｕｐｐｏｒｔ ｎｏｎ－ｔｅｒｒｅｓｔｒｉａｌ ｎｅｔｗｏｒｋｓ，ｖｅｒｓｉｏｎ ０．３．０を参照されたい）。
物理的攻撃及び自然災害に対する宇宙／空中ビークルの広範なサービスカバレッジ能力及び低下される脆弱性ため、ＮＴＮは、地上ＮＲネットワークによってカバーできず（例えば、孤立若しくは遠隔エリア、航空機又は船舶）、サービス提供できない（例えば、郊外及び地方エリア）未サービスエリアにおけるＮＲサービスの展開を促進しうる。さらに、ＮＴＮは、移動プラットフォーム上の乗客にサービス継続性を提供することによって、又は、特に重要な通信のために何れの場所でもサービス可用性を保証することによって、ＮＲサービスの信頼性を強化してもよい。
その利点は、非地上ネットワークの単独動作又は統合された地上及び非地上ネットワークの何れかに関連し、カバレッジ、ユーザ帯域幅、システム容量、サービス信頼性又は可用性に影響を与えうる。
非地上ネットワークは、例えば、衛星に搭載されたＲＦリソースを使用するネットワーク又はネットワークの一部を表す。ＮＴＮは、典型的には、以下のシステム要素、すなわち、衛星が３ＧＰＰ ＵＥに直接的にサービス提供しない場合には、３ＧＰＰ ＵＥ又は衛星システムに固有の端末、ユーザ装置と宇宙／空中プラットフォームとの間の無線リンクを表すサービスリンク、ペイロードに搭載する空中プラットフォーム、宇宙／空中プラットフォームをコアネットワークに接続するゲートウェイ、ゲートウェイセンタの宇宙／空中プラットフォーム間の無線リンクを表すフィーダリンク、を特徴とする。
図２は、端末（ＵＥ）間の送信が静止衛星とＮＴＮゲートウェイとを含むリモート無線ユニットを介し実行される非地上ネットワークのシナリオを示す。ｇＮＢは、スケジューリングデバイスとしてゲートウェイに配置される。衛星のペイロードは、アップリンク方向とダウンリンク方向との両方で周波数変換及び無線周波増幅器を実装する。従って、衛星は、（ＮＴＮゲートウェイと衛星との間の）フィーダリンクから（衛星とＵＥとの間の）サービスリンクへ、およびその逆で、ＮＲ無線インタフェースを繰り返す。
図３は、端末（ＵＥ）間の送信がスケジューリングデバイスとしてｇＮＢを含む静止衛星を介し実行される非地上ネットワークのシナリオを示す。
非地上ネットワーク及び往復遅延
電磁波を介することに基づく全ての信号送信は、光速による信号送信遅延を受ける。特に、ソースとデスティネーションとの間の無線信号の一方向の伝搬遅延の２倍は、往復遅延（ＲＴＤ）と呼ばれる。生成されるレスポンス信号の処理ノードにおける処理時間がまた、ＲＴＤに含まれてもよい。
特に、往復遅延は、例えば、端末（ＵＥ）などのソースノードとデスティネーションノードとの間の距離に依存する。信号が衛星等を介して送信されるＮＴＮでは、ＲＴＤの値は、地上ネットワークよりもはるかに大きくなりうる。例えば、静止軌道上、すなわち、高度約３５７８６ｋｍにある衛星を介して送信される信号の場合、図２に示すように、ＮＲにおけるｇＮＢなどのスケジューリングデバイスがゲートウェイに配置される場合には、ＲＴＤは、５４１．１４ｍｓの大きさになりうる。
図２に示されるシナリオは、５４１．１４ｍｓの往復遅延と関連付けされ、図３に示されるシナリオは、２７１．５７ｍｓの往復遅延と関連付けされる。図２及び３に示されるシナリオの往復遅延の値は、テーブル１に要約される。
Figure 2022521086000002
スケジューリング
３ＧＰＰでは、ＮＲベース動作におけるスケジューリングが記載される（例えば、３ＧＰＰ ＴＲ ３８．３２１，ＮＲ，Ｍｅｄｉｕｍ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ（ＭＡＣ） ｐｒｏｔｏｃｏｌ ｓｐｅｃｉｆｉｃａｔｉｏｎ，ｖｅｒｓｉｏｎ １５．４．０を参照されたい）。
スケジューリングは、ＮＲ及び／又はＬＴＥのような通信システムの中心部分である。各時点について、スケジューラは、共有された時間－周波数リソースが何れのＵＥに割り当てるべきかを決定する。アップリンク、ダウンリンク及び／又はサイドリンク送信がスケジューリングされてもよい。
特に、アップリンクスケジューラは、何れの端末がそれらのアップリンク共有チャネル（ＵＬ－ＳＣＨ）上で送信すべきかを動的に制御する責任がありうる。スケジューリングされた各端末には、端末がそれのＵＬ－ＳＣＨを送信すべきリソースのセットを含むスケジューリンググラントが提供される。
言い換えると、アップリンクスケジューリングの機能は、何れのデバイスが何れのアップリンクリソースで送信すべきかを動的に決定することである。動的スケジューリングは、典型的には、Ｐｈｙｓｉｃａｌ Ｄｏｗｎｌｉｎｋ Ｃｏｎｔｒｏｌ ＣＨａｎｎｅｌ（ＰＤＣＣＨ）によって実行される。物理ダウンリンク制御チャネルは、Ｄｏｗｎｌｉｎｋ Ｃｏｎｔｒｏｌ Ｉｎｆｏｒｍａｔｉｏｎ（ＤＣＩ）とも呼ばれうるスケジューリンググラント及び他の制御情報を搬送する。各端末（ＵＥ）は、ＰＤＣＣＨをモニタリングする。これは、ＵＥがサーチスペースと呼ばれる特定のリソースを（ブラインドで）復号することを意味する。ＰＤＣＣＨのサーチスペースは、ＰＤＣＣＨが搬送されうるダウンリンクリソースグリッドにおけるエリアである。ＵＥは、これらのサーチスペースにおいてブラインド復号を実行し、ＰＤＣＣＨデータ（ＤＣＩ）を検出しようとする。ＰＤＣＣＨを復号するため、ＵＥは、自らのＲＮＴＩ(Ｒａｄｉｏ Ｎｅｔｗｏｒｋ Ｔｅｍｐｏｒａｒｙ Ｉｄｅｎｔｉｔｙ)を適用し、Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ Ｅｌｅｍｅｎｔ（ＣＣＥ）と呼ばれるリソースにおいてＰＤＣＣＨを復号しようとする。復号が成功した場合（巡回冗長チェックなどの誤り検出符号によってチェックできる）、ＤＣＩが受信される。ＵＥはまた、いくつかの選択された送信パラメータについて各種パラメータ値をブラインドに試みてもよい。各端末は、２つ以上のＰＤＣＣＨをモニタリングしてもよい。ＰＤＣＣＨは、ＵＥのグループに共通であってもよく（この場合、ＵＥは共通のグループＲＮＴＩを使用している）、又は、特定のＵＥに専用であってもよい。
規格（ＬＴＥ又はＮＲ）は、ＤＣＩのいくつかの異なるフォーマットを規定している。これらのフォーマットは、目的に応じて互いに異なる。例えば、アップリンクグラントを搬送するためのフォーマット（フォーマット０又は４など）は、ダウンリンクグラントを搬送するフォーマット、又はグラントを全く搬送しないフォーマットとは異なる。また、ビームフォーミング、ブロードキャスト／マルチキャストなどの利用に応じて異なるフォーマットが規定される。
これに対応して、アップリンクでは、物理レイヤに関する制御情報がＰｈｙｓｉｃａｌ Ｕｐｌｉｎｋ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌによって搬送される。ＰＵＣＣＨは、ＵＣＩ（Ｕｐｌｉｎｋ Ｃｏｎｔｒｏｌ Ｉｎｆｏｒｍａｔｉｏｎ）と呼ばれるパラメータのセットを搬送する。これは、上述したＤＣＩを搬送するＰＤＣＣＨと同様である。ＰＵＣＣＨにおいてＵＣＩが搬送する情報の種別に応じて、ＰＵＣＣＨはまた、異なるフォーマットで利用可能である。例えば、
－フォーマット１は、スケジューリングリクエストＳＲを搬送する。
－フォーマット４は、チャネル状態情報（ＣＳＩ）と一緒にＳＲを搬送する。
－フォーマット３は、ＨＡＲＱアクノリッジメント（肯定的又は否定的）及びＣＳＩと一緒にＳＲを搬送する。
ＬＴＥ及び／又はＮＲによって規定される更なるフォーマットがある。
アップリンクスケジューリングのための基礎は、ＵＬ－ＳＣＨの送信に使用するリソース及び関連するトランスポートフォーマットに関するデバイス情報を提供することを含むスケジューリンググラントである。言い換えれば、（例えば、規格で規定された）あるフォーマットを有するＤＣＩは、リソースグラントに対応するリソース割当て（ＲＡ）を、変調符号化方式（ＭＣＳ）、ＭＩＭＯ（Ｍｕｌｔｉｐｌｅ Ｉｎｐｕｔ Ｍｕｌｔｉｐｌｅ Ｏｕｔｐｕｔ）送信のための設定などのいくつかの更なる送信パラメータと共に搬送してもよい。
端末が有効なグラントを有する場合、端末は、リソース割当てによって指定されたＰｈｙｓｉｃａｌ Ｕｐｌｉｎｋ Ｓｈａｒｅｄ Ｃｈａｎｎｅｌ(ＰＵＳＣＨ)上にマッピングされたそれの対応するＵＬ－ＳＣＨを送信することが許可される。
すなわち、スケジューラは、送信すべきデータを有する端末に関する知識を必要とし、そのため、アップリンクリソースをスケジューリングする必要がある。許可されたリソースを充填するためのパディングをデバイスに実行させるため、送信すべきデータがないデバイスにアップリンクリソースを提供する必要はない。従って、スケジューラは、デバイスが送信すべきデータを有し、グラントが与えられるべきか否かを知る必要がある。
スケジューリングリクエスト
スケジューリングリクエストは、有効なスケジューリンググラントを有さない端末に対して使用されてもよい。スケジューリングリクエストは、Ｐｙｓｉｃａｌ Ｕｐｌｉｎｋ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ（ＰＵＣＣＨ）上で送信されてもよい。各端末には、ｎサブフレーム毎に発生する専用のスケジューリングリクエストリソースが割り当てられてもよい。スケジューリングリクエストは、アップリンクスケジューラからアップリンクリソースを要求するため、端末によって提起（設定）されるシンプルなフラグであってもよい。専用のスケジューリングリクエスト機構によると、端末の識別情報はリクエストが送信されるリソースから暗黙的に分かるため、要求元の端末の識別情報は、スケジューリングリクエストと一緒に提供される必要はない。これらは、ｇＮＢのようなスケジューリングノードによって、例えば、上位レイヤ制御プロトコルによって設定される。
スケジューリングリクエストを受信すると、スケジューリングデバイスは、端末にスケジューリンググラントを割り当てることができる。端末は、スケジューリンググラントを受信した場合、スケジューリングされたリソースにおいてそれのデータを送信する。ＰＵＳＣＨ上で送信されるデータは、第１のバッファステータスにおいて、ＵＥが送信しなければならないデータ量をスケジューリングノードに通知することを含んでもよい。バッファステータスに基づいて、スケジューリングノードはその後、ＰＵＳＣＨ上の実際のデータリソースをスケジューリングしてもよい。しかしながら、これは単なる１つの選択肢であり、一般に、データリソースはまた直接スケジューリングされてもよい。いくつかのシステムでは、スケジューリングされるように要求された特定のデータ量とスケジューリングリクエストとを関連付けることも可能である。
端末が次の可能な瞬間までにスケジューリンググラントを受信しない場合、スケジューリングリクエストは、繰り返されてもよい。
従って、ＰＵＣＣＨ上のコンテンションフリースケジューリングリクエスト機構が提供され、ここでは、セル内の各端末には、アップリンクリソースに対するリクエストを送信可能な確保されたリソースが与えられる。
ＵＥ ＭＡＣエンティティは、０、１又は複数のＳＲコンフィギュレーションによって設定されてもよい。ＳＲコンフィギュレーションは、異なる帯域幅部分（ＢＷＰ）にわたるスケジューリングリクエストのためのＰＵＣＣＨリソースのセットから構成される。論理チャネル（ＬＣＨ）について、ＳＲのための高々１つのＰＵＣＣＨリソースがＢＷＰ毎に設定される。各ＳＲコンフィギュレーションは、１つ以上の論理チャネルに対応する。論理チャネルとＳＲコンフィギュレーションとの間のマッピングは、ＲＲＣ（Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ）メッセージングによって設定されてもよい。
上述されるように、通常のバッファステータスレポート（ＢＳＲ）がトリガされたが、ＢＳＲを送信するアップリンク無線リソースがＵＥにおいて利用可能でないとき、ＳＲ手順が開始されてもよい。ＳＲ手順の間、ＵＥは、ＳＲについてＰＵＣＣＨリソースが設定されるか否かに応じて、ＰＵＣＣＨを介してＳＲの送信を実行するか、又は、ランダムアクセス（ＲＡ）手順を開始するかの何れかであってもよい。ＲＡ手順は、ＳＲのためのＰＵＣＣＨリソースが設定されていないときに限って開始される。
ＵＥ ＭＡＣエンティティが、設定されたＳＲのための有効なＰＵＣＣＨリソース上でＳＲ送信位置を有するとき、物理レイヤ（ＰＨＹ）は、ＳＲのための１つの有効なＰＵＣＣＨリソース上でＳＲを通知するよう指示される。その後、ＳＲ禁止タイマが開始される（ｓｒ＿ｐｒｏｈｉｂｉｔＴｉｍｅｒ）。連続するＳＲ送信機会の時点において、ＭＡＣは、ＳＲ禁止タイマが動作中である場合、ＳＲを通知するようＰＨＹに指示しない。
ＮＲでは、ＳＲリソースは特定の周期で設定される。ＳＲがＵＥによって送信されると、ＳＲ禁止タイマが始動され、ＳＲ禁止タイマが動作中である限り、ＳＲは既に設定されたリソース上では送信されない。
３ＧＰＰ ＴＳ ３８．３３１（“ＮＲ，Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ（ＲＲＣ），Ｐｒｏｔｏｃｏｌ ｓｐｅｃｉｆｉｃａｔｉｏｎ”，ｖｅｒｓｉｏｎ １５．４．０，ｓｅｃｔｉｏｎ ６．３．２）に規定されるようなスケジューリングリクエストの設定に利用されるスケジューリングリクエストコンフィギュレーション情報要素は、図４と共に以下に示される。
Figure 2022521086000003
特に、スケジューリングリクエスト禁止タイマは、ｓｒ－ＰｒｏｈｉｂｉｔＴｉｍｅｒによって設定され、スケジューリンググラントが受信されていない場合であっても、ＳＲの送信後にスケジューリングリクエストが送信されない期間を示す。スケジューリングリクエストの最大数は、ｓｒ－ＴｒａｎｓＭａｘによって規定される。Ｓｒ－ＰｒｏｈｉｂｉｔＴｉｍｅｒ及びｓｒ－ＴｒａｎｓＭａｘは、例えば、ＲＲＣシグナリングを介して、スケジューリングノードからＵＥに提供される。
図５は、ある周期で設定されたスケジューリングリクエストの送信を示す。この例では、ＳＲの送信の機会は、後続フレームの全てのスロットｎ内で設定され、各フレームはスロットｎ～ｎ＋９を含む。ＳＲ送信がＭＡＣレイヤ上で端末によって指示されるとすぐに、図５において太い矢印で示されるように、ＳＲ禁止タイマが始動される。ＳＲ禁止タイマが動作しているとき、ＳＲ送信のために使用される機会に続く機会において、ＵＥ ＭＡＣによってトリガされるＳＲ送信はない。図５では、ＳＲ送信機会の周期は、連続するフレームの各スロットｎであるが、ＳＲコンフィギュレーション周期はこれに限定されず、他の何れかの周期が設定されてもよい。
スケジューリングリクエスト及び往復遅延
上述したように、ＮＴＮでは、往復遅延が大きく、ＳＲ禁止タイマが満了したとき、ＳＲの受信に応答してスケジューリングデバイス、例えば、ＮＲにおけるｇＮＢによって送信されるスケジューリンググラントが端末によって受信されないことがある。すなわち、ＳＲ禁止タイマは、往復遅延を考慮して設定されるべきである。
しかしながら、ＳＲ禁止タイマが大きな往復遅延を考慮して延長され、送信されたＳＲが失われたとき、ＳＲ禁止タイマが満了した後、ＳＲの再送はＵＥによって実行される。この結果、ＵＥがアップリンクリソースを取得するのに長時間を要し、ＮＴＮにおける送信遅延が大きくなる。
さらに、ＮＴＮと同様に、セルサイズは大きくてもよく、単一のセルが多数のユーザにサービス提供する。この結果、ＮＴＮ上での送信のための無線リソースがタイトになる。すなわち、限定された無線リソースが、例えば、地上ネットワークを介した送信と比較して、多数のデバイスによって使用される。
ＳＲ禁止タイマを増加させ、同時に、送信の低遅延を提供するためにスケジューリングリクエストを繰り返し送信することによって、地上ネットワークと比較してＮＴＮにおける拡大された往復遅延を考慮すると、追加のリソースが、物理レイヤ上での完全なＰＵＣＣＨ再送のために設定されうる。これが、図５に示される。
図６は、ＰＵＣＣＨ繰り返しによるスケジューリングリクエストの繰り返し送信の概略図である。特に、リソースは、物理レイヤ上のＰＵＣＣＨ全体の繰り返しのために確保されてもよい。ＰＵＣＣＨは、ＳＲに加えて、ＨＡＲＱ（Ｈｙｂｒｉｄ Ａｕｔｏｍａｔｉｃ Ｒｅｐｅａｔ Ｒｅｑｕｅｓｔ）及び／又はＣＳＩ（Ｃｈａｎｎｅｌ Ｓｔａｔｅ Ｉｎｆｏｒｍａｔｉｏｎ）などの更なる情報を含んでもよい。すなわち、繰り返しが物理レイヤ上でＰＵＣＣＨ繰り返し全体を介して行われるとき、追加のリソースが必要とされ、有意に高いオーバヘッドを生じさせる。ＮＴＮセルサイズは、通常、サービス提供されるべき多数のＵＥとともに大きくなるため、繰り返しのＳＲ送信を提供するため、大量のリソースが確保される必要がある。
本開示は、繰り返しのための追加のリソースが設定されることを必要とすることなく、ＳＲの繰り返し送信によって信頼性を高めることを容易にしうる技術を提供する。さらに、本開示は、追加のオーバヘッドを必要としない技術を提供する。
このため、以下に説明される通信方法及び通信デバイスの実施例では、送受信デバイスは、ＰＵＣＣＨの複数の機会でのスケジューリンググラントの送信を指示することによって、ＭＡＣ（Ｍｅｄｉｕｍ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）レイヤ上でスケジューリングリクエストを繰り返す。スケジューリングリクエストは、受信機によってＰＵＣＣＨを介し送信される。
本開示は、図７に示される送受信デバイス及びスケジューリングデバイスを提供する。送受信デバイス１１０は、動作中に、ＰＵＣＣＨ（Ｐｈｙｓｉｃａｌ Ｕｐｌｉｎｋ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ）の複数の機会でスケジューリングリクエストを送信するように送受信機に指示することによって、ＭＡＣレイヤ上でスケジューリングリクエストを繰り返す回路１２０（又は処理回路）を備える。さらに、送受信デバイス１１０は、動作中に、ＰＵＣＣＨ上でスケジューリングリクエストを送信する送受信機１３０（１つ以上のアンテナとハードウェアコンポーネントの動作を制御する制御回路などのハードウェアコンポーネントを有する送信機及び／又は受信機）を有する。
例えば、送受信デバイス１１０は、ＮＲ ＮＴＮにおけるＵＥである。従って、送受信機１３０及び回路１２０はまた、“ＵＥ送受信機”及び“ＵＥ回路”として本開示に対して留保する。しかしながら、これらの用語は、回路１２０及び送受信機３０を、スケジューリングデバイス又は基地局のような他のデバイスによって構成される回路及び送受信機と区別するためだけに使用される。送受信デバイス１１０は、同様の通信システムの端末デバイス、中継デバイス又は通信デバイスであってもよい。ＵＥ回路は、“スケジューリングリクエスト繰り返し回路”とみなされてもよいし、あるいは、含んでもよい。
さらに、図７に示すスケジューリングデバイス２１０（又はスケジューリングノード）が提供され、これは、動作中にスケジューリングリクエスト許容数を示す許容リクエストインジケータを決定する回路２３０と、動作中に許容リクエストインジケータを送信する送受信機２２０とを備える。
あるいは、スケジューリングデバイス２１０（又はスケジューリングノード）は、動作中に複数のスケジューリングリクエストコンフィギュレーションを示すスケジューリングリクエストコンフィギュレーションインジケータを決定する回路２３０と、動作中にスケジューリングリクエストコンフィギュレーションインジケータを送信する送受信機２２０とを備えてもよい。
例えば、スケジューリングデバイスは、ＮＲ ＮＴＮシステム（ｇＮＢ）又は同様の無線通信システムにおけるネットワークノード（基地局）である。回路２２０はまた、ＵＥ回路１２０、“ネットワークノード回路”などの他の回路と区別するため、“許容リクエスト判定回路”又は“スケジューリングリクエストコンフィギュレーション判定回路”と呼ばれる。
さらに、ＰＵＣＣＨの複数の機会でのスケジューリングリクエストの送信を指示することによって、ＭＡＣレイヤ上でスケジューリングリクエストを繰り返し、ＰＵＣＣＨ上でスケジューリングリクエストを送信することを含む方法が提供される。
さらに、スケジューリングリクエスト許容数を示す許容リクエストインジケータを決定し、許容リクエストインジケータを送信することを含む方法が提供される。
さらに、複数のスケジューリングリクエストコンフィギュレーションを示すスケジューリングリクエストコンフィギュレーションインジケータを決定し、スケジューリングリクエストコンフィギュレーションインジケータを送信することを含む方法が提供される。
さらなる説明では、明示的な記述又はコンテキストがそうでないことを示さない限り、詳細及び実施例は、送受信デバイス１１０、スケジューリングノード（又はスケジューリングデバイス）２１０及び方法のそれぞれに適用される。
送受信デバイスのＵＥ回路１２０は、ＭＡＣレイヤ上でスケジューリングリクエストの送信を繰り返す。これは、ＳＲの送信のために設定されたＰＵＣＣＨの複数の機会でスケジューリングリクエストを送信するように送受信機１３０に指示することによって実行される。このようにして、繰り返しのＳＲ送信は、送受信デバイスによって実行され、その結果、繰り返しのために追加のリソースを同時に設定することを不要にしながら、信頼性が繰り返しによって増大される。従って、ＰＵＣＣＨ全体の繰り返しに関する追加のオーバヘッドは発生しない。
言い換えれば、スケジューリングの送信のために設定されたリソース上でのスケジューリングリクエストの送信は、ＭＡＣレイヤエンティティによってトリガされる。すなわち、物理レイヤ（ＰＨＹ）は、ＳＲ送信の機会にスケジューリングリクエストを送信するよう指示される。ＭＡＣレイヤエンティティは、例えば、ＲＲＣメッセージングによって、ＳＲ送信用に設定されたリソースでスケジューリングリクエストを送信するようにＰＨＹに指示することを繰り返す。言い換えると、ＳＲの送信のための繰り返しの指示は、例えば、ＵＥの内部シグナリングによって、ＭＡＣレイヤによって物理レイヤに提供される。
ＭＡＣレイヤによるＳＲの繰り返しの特定の利点は、繰り返しが論理チャネル毎に実行可能であり、従って、ＳＲの繰り返しが複数の論理チャネルの１つに対してのみ必要とされることである。ＭＡＣは、それらの全てに対する代わりに、１つに対してのみ繰り返しをトリガしてもよい。しかしながら、ＰＨＹレイヤによるＰＵＣＣＨの繰り返しでは、それらの全てではなく、特定の論理チャネルに対して繰り返しをトリガすることはできない。
例えば、ＮＲでは、ＵＥは、ＰＵＣＣＨフォーマット０又はＰＵＣＣＨフォーマット１の何れかを用いたＰＵＣＣＨ送信において、ＳＲのためのコンフィギュレーションセットによる上位レイヤパラメータによって設定されてもよい。
さらに、ＰＵＣＣＨフォーマット１、３又は４について、ＵＥは、ＰＵＣＣＨ送信の繰り返しのために多数のスロットによって設定できる。
さらに、３ＧＰＰ ＴＳ ３８．３３１（“ＮＲ，Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ（ＲＲＣ）；Ｐｒｏｔｏｃｏｌ ｓｐｅｃｉｆｉｃａｔｉｏｎ”，ｖｅｒｓｉｏｎ １５．４．０）のｓｅｃｔｉｏｎ ６．３．２は、ＰＵＣＣＨリソースの識別子と、ＰＵＣＣＨフォーマットに関するパラメータと、ＳＲ送信のためのスロット数とを記載する。ＰＵＣＣＨフォーマット１がＳＲに設定され、スロット数が１より大きい数に設定される場合、ＵＥは、単一のＳＲコンフィギュレーションに基づいてＳＲの繰り返しを実行する。
いくつかの実施例では、スケジューリングデバイス２１０は、スケジューリングリクエスト許容数を示す許容リクエストインジケータを決定する。すなわち、スケジューリングデバイス２１０は、スケジューリングリクエストの最大繰り返し送信数を送受信デバイスに通知し、送受信デバイス１１０又は、具体的には回路１２０は、ＳＲ送信のために設定された機会でスケジューリングリクエストを送信するよう送受信機１３０に繰り返し指示する。ここで、スケジューリングリクエストは、スケジューリングデバイス２１０によって通知された最大繰り返し送信数に従って送信される。言い換えると、スケジューリングリクエストの送信は、送信されたＳＲの数がＳＲ送信の設定された最大（許容）数に等しくなるまで、ＵＥ ＭＡＣエンティティによってトリガされる。
送信されるスケジューリングリクエストの数は、スケジューリングデバイス２１０から受信されるスケジューリングリクエスト許容数に従って決定されることに限定されず、送受信機の判断であってもよい。
いくつかの実施例では、スケジューリングデバイス２１０は、論理チャネル毎に複数のスケジューリングリクエストコンフィギュレーションを示すスケジューリングリクエストコンフィギュレーションインジケータを決定する。すなわち、論理チャネルは、複数のＳＲコンフィギュレーション上にマッピングされてもよい。送受信デバイス１１０又は、具体的には回路１２０は、複数のＳＲコンフィギュレーションに従ってスケジューリングリクエストを送信するよう送受信機１３０に指示する。
図８は、実施例によるＭＡＣレイヤ上でＵＥ回路１２０によってトリガされる複数の機会でのスケジューリングリクエストの繰り返し送信の概略図である。図示されるように、本例では、ＳＲ送信は、設定された周期でＵＥ ＭＡＣレイヤによって３回トリガされる。特に、ＳＲは、複数の機会でＰＵＣＣＨを介して送信される。当該機会は、ＳＲ送信のために設定されたリソースであり、送受信デバイス１１０は、上述のように、ＵＬ－ＳＣＨを介したアップリンク送信のためのリソースを割り当てることなく、送受信デバイス１１０が送信されるべきデータを有するケースにおいて、リソースリクエストを送信してもよい。
ＬＣＨ毎の単一のＳＲコンフィギュレーションに基づく繰り返し
いくつかの実施例では、スケジューリングデバイス２１０は、論理チャネル毎にＮ回のＳＲの繰り返しを設定してもよく、ここで、各論理チャネルは、図９に示すように、１つのＳＲコンフィギュレーションにマッピングされる。
スケジューリングリクエスト許容数は、図１０とともに以下に示されるように、ＮＲ論理チャネルコンフィギュレーション要素において設定されてもよい。
Figure 2022521086000004
特に、スケジューリングリクエストの送信の繰り返し数は、図１０及び上記に示される例では、“ｎｕｍｂｅｒ ｏｆ ＳＲ ｒｅｐｅｔｉｔｉｏｎｓ”として示される追加的なパラメータを介し設定されてもよい。
各論理チャネルは、ＳＲ送信の繰り返しを可能にしてもよく、ここで、ＳＲの繰り返し数は、例えば、ＲＲＣメッセージを介してｇＮＢなどのスケジューリングデバイスによって設定される（例えば、３ＧＰＰ ３８．３３１，ｖｅｒｓｉｏｎ １５．４．０を参照されたい）。例えば、ＳＲ繰り返し数は、論理チャネルの優先度に基づいて異なって設定されてもよい。例えば、より高い優先度の論理チャネルは、より低い優先度の論理チャネルと比較して、より多くのＳＲの繰り返しを可能にするとして設定されてもよい。
図１１に示されるように、ＳＲ送信数は、高い優先度の論理チャネル（例えば、高い優先度のｅＭＢＢトラフィック）に対して設定されてもよく、一方、低い優先度のチャネル（低い優先度のｅＭＢＢトラフィック）に対しては、ＳＲの繰り返しは設定されなくてもよい。このため、論理チャネルの優先度に応じて、ＳＲ繰り返しの値は異なってもよい。
加えて又は代わりに、許容可能な繰り返し数は、アップリンクチャネル品質に基づいて設定することができる。アップリンクチャネル品質は、例えば、ＳＲＳ（Ｓｏｕｎｄｉｎｇ Ｒｅｆｅｒｅｎｃｅ Ｓｉｇｎａｌ）を利用して評価されてもよい。ＳＲＳは、スケジューリングデバイスがチャネルサウンディングを実行することを可能にするため、例えば、周波数領域のスケジューリングをサポートするため、端末によってスケジューリングデバイスに送信される（例えば、３ＧＰＰ ＴＳ ３６．２１１，“Ｅｖｏｌｖｅｄ Ｕｎｉｖｅｒｓａｌ Ｔｅｒｒｅｓｔｒｉａｌ Ｒａｄｉｏ Ａｃｃｅｓｓ（Ｅ－ＵＴＲＡ）；Ｐｈｙｓｉｃａｌ ｃｈａｎｎｅｌｓ ａｎｄ ｍｏｄｕｌａｔｉｏｎ”，ｖｅｒｓｉｏｎ １５．４．０，ｓｅｃｔｉｏｎ ５．５．３を参照されたい）。
図１２は、実施例によるＭＡＣレイヤ上でトリガされた複数の機会でのスケジューリングリクエストの送信の概略図であり、スケジューリングリクエスト禁止タイマは、スケジューリングリクエストを複数回送信した後に始動される。
特に、スケジューリングデバイスは、論理チャネル毎にＮ回の許容可能なスケジューリングリクエストの送信を設定してもよい。スケジューリングリクエストの送信は、連続する３つのフレームｎ～ｎ＋２の各スロットｎにおけるＵＥ ＭＡＣレイヤエンティティによってトリガされる。３回目のスケジューリングリクエストの送信後、ＳＲ禁止タイマが始動され、ＳＲ禁止タイマが満了しない限り、ＳＲ送信は、ＳＲ送信のために設定された機会ではトリガされない。図１２に示される例では、ＳＲの３回の送信は、ＵＥ ＭＡＣレイヤエンティティによってトリガされる。しかしながら、本開示は、３回の送信に限定されず、スケジューリングデバイスによって設定された何れかの数が、ＳＲ送信繰り返しの最大数として利用されうる。この場合、ＳＲ禁止タイマは、最後のＳＲの送信後に始動される。
加えて又は代わりに、ＵＥは、スケジューリングリクエストの送信について異なる周期を使用してもよい。図１３は、実施例によるＭＡＣレイヤ上でトリガされた複数の機会でのスケジューリングリクエストの送信の概略図であり、ここでは、スケジューリングリクエスト禁止タイマは、複数回のスケジューリングリクエストの送信後に始動され、１つおきのフレームのスロットｎにおける周期が適用される。
特に、スケジューリングデバイスは、論理チャネル毎にＮ回の許容可能なスケジューリングリクエストの送信を設定してもよい。図１３に示される例では、Ｎは２に等しく、スケジューリングリクエストの送信は、２つのフレームｎ及びｎ＋２の各スロットｎにおいてＵＥ ＭＡＣレイヤエンティティによってトリガされる。２回目のスケジューリングリクエストの送信後、ＳＲ禁止タイマが始動され、ＳＲ禁止タイマが満了しない限り、ＳＲ送信のために設定された機会においてＳＲ送信はトリガされない。
ＵＥがスケジューリングデバイスからアップリンクグラントを受信するケースでは、ＳＲ禁止タイマが終了される。また、ＳＲ禁止タイマが満了し、スケジューリングデバイスからアップリンクグラントを受信していないとき、スケジューリングリクエストの送信の処理が再開されてもよい。すなわち、ＵＥ ＭＡＣレイヤエンティティは、ＰＵＣＣＨの複数の機会でのＳＲの送信を再びトリガする。
このアプローチの特に有利な点は、信頼性が向上し、アップリンクデータ送信の遅延が短縮されることである。特に、スケジューリングデバイス、例えば、ｇＮＢがＵＥから１回目のＳＲ送信を受信しない場合、２回目又は３回目のＳＲ送信が、スケジューリングデバイスによって受信されてもよく、リソースグラントは、ＳＲ禁止タイマがまだ満了していなくても、送受信デバイスに送信されてもよい。
図１４は、実施例による複数の機会でのスケジューリングリクエストの送信を示すフローチャートである。ステップＳ１００において、ＵＥ ＭＡＣレイヤエンティティは、Ｎ回のＳＲ繰り返しを実行するよう設定される。これは、スケジューリングリクエストを送信する機会として設定されたリソースの繰り返しパターンを示すＲＲＣコンフィギュレーションを受信することによって実行されてもよい。ステップＳ１１０では、これまで送信されたスケジューリングリクエストの数が設定されたＳＲ送信の繰り返し数Ｎを下回るか否かが判定される。ＳＲ送信数が設定されたＳＲ送信の繰り返し数Ｎを上回る場合（ステップＳ１１０においてＮｏ）、ステップＳ１４０において、ＳＲ禁止タイマが始動される。ＳＲ送信の繰り返し数が設定されたＳＲ送信の繰り返し数Ｎを下回ると判断された場合、ＵＥ ＭＡＣレイヤエンティティは、設定されたＰＵＣＣＨの機会にＳＲを通知するよう物理レイヤ（送受信機）に指示する。また、ステップＳ１３０において、ＳＲ送信の繰り返し数が１だけ増分され、当該手順はステップＳ１１０に戻る。特に、スケジューリンググラントを受信せずに送信されたスケジューリングリクエストの数は、例えば、ＮＲにおける論理チャネルコンフィギュレーションのＳＲ＿ＣＯＵＮＴＥＲなどのカウンタを用いて、ＵＥによって捕捉されてもよい。
ＬＣＨ毎の複数のＳＲコンフィギュレーションに基づく繰り返し
いくつかの実施例では、スケジューリングデバイス２１０は、論理チャネル毎に複数のＳＲコンフィギュレーションを設定してもよく、各論理チャネルは複数のＳＲコンフィギュレーションにマッピングされる。例えば、図１６に示されるように、ＬＣＨは、コンフィギュレーション１及び２として示される２つのＳＲコンフィギュレーションにマッピングされる。言い換えれば、ＳＲ送信のための複数の機会が、論理チャネル毎の複数のＳＲコンフィギュレーションを介し提供され、ＳＲ繰り返しは様々なＳＲコンフィギュレーションに基づく。
図１６では、ＬＣＨは２つのＳＲコンフィギュレーションにマッピングされるが、本発明はこれに限定されず、ＬＣＨは２より多くのＳＲコンフィギュレーションにマッピングされてもよい。
ＬＣＨが２回目のスケジューリングリクエストＩＤ“ｓｃｈｅｄｕｌｉｎｇＲｅｑｕｅｓｔＩＤ２”を介し２つのスケジューリングリクエストコンフィギュレーションにマッピングされる、ＮＲにおける論理チャネルコンフィギュレーションを規定する論理チャネルコンフィギュレーション情報要素が、図１５と共に以下に示される。
Figure 2022521086000005
スケジューリングデバイスは、複数のＳＲコンフィギュレーションがＬＣＨの優先度に基づいてＬＣＨのために設定されているか否かを判定してもよい。例えば、より高い優先度のＬＣＨは、複数のＳＲコンフィギュレーションにマッピングされてもよい。このアプローチによって、高い優先度の論理チャネルのスケジューリングリクエスト手順は、信頼性及び遅延に関して改善される。
図１７は、高い優先度の論理チャネル（例えば、高優先度ｅＭＢＢトラフィック）がＳＲ送信を繰り返すため、ＳＲコンフィギュレーション１及びＳＲコンフィギュレーション２にマッピングされるのに対し、低い優先度の論理チャネル（例えば、低優先度ｅＭＢＢトラフィック）がＳＲコンフィギュレーション２のみにマッピングされる例を示す。
図１８は、実施例によるＵＥ ＭＡＣレイヤ上でトリガされる複数の機会でのスケジューリングリクエストの送信の概略図であり、スケジューリングの送信は、２つのスケジューリングリクエストコンフィギュレーションに従って複数の機会でトリガされる。
特に、スケジューリングリクエストの１回目の送信は、スロットｎにおける関連する第１の周期による第１のＳＲコンフィギュレーションに従ってＵＥ ＭＡＣレイヤ上でトリガされる。当該１回目のＳＲ送信の後、第１のＳＲ禁止タイマが始動され、第１のＳＲ禁止タイマが満了しない限り、ＵＥ ＭＡＣレイヤは、第１のＳＲコンフィギュレーションに従ってＳＲ送信をトリガしない。さらに、スケジューリングリクエストの２回目の送信は、スロットｎ＋１における関連する第２の周期による第２のＳＲコンフィギュレーションに従ってＵＥ ＭＡＣレイヤ上でトリガされる。当該２回目のＳＲ送信の後、第２のＳＲ禁止タイマが始動され、第２のＳＲ禁止タイマが満了しない限り、ＵＥ ＭＡＣレイヤエンティティは、第２のＳＲコンフィギュレーションに従ってＳＲ送信をトリガしない。
図１８に例示される例では、ＳＲの２つの送信は、２つのＳＲ送信コンフィギュレーションに従ってＵＥ ＭＡＣレイヤ上でトリガされる。しかしながら、本開示は、２つの送信に限定されず、任意の数のＳＲ送信コンフィギュレーションがスケジューリングデバイスによって設定されてもよい。この場合、ＳＲ禁止タイマは、それぞれのＳＲコンフィギュレーションに従ってＳＲの送信をトリガした後、全てのＳＲ送信に対して始動されてもよい。
ＵＥがスケジューリングデバイスからアップリンクグラントを受信する場合、ＳＲ禁止タイマは停止／終了される。さらに、ＳＲ禁止タイマの１つが満了し、スケジューリングデバイスからアップリンクグラントが受信されないとき、対応するＳＲコンフィギュレーションに従ったＳＲの繰り返し送信が再開される。すなわち、ＰＵＣＣＨの各機会でのＳＲの送信が、ＵＥ ＭＡＣレイヤ上で再び指示される。
このアプローチの特に有利な点は、信頼性が向上し、アップリンクデータ送信の遅延が短縮されることである。特に、スケジューリングデバイス、例えば、ｇＮＢがＵＥから１回目のＳＲ送信を受信しない場合、２回目のＳＲ送信がスケジューリングデバイスによって受信されてもよく、リソースグラントが、ＳＲ禁止タイマがまだ満了していなくても、送受信デバイスに送信されてもよい。
さらに、例えば、ＵＥなどの送受信デバイスと、ｇＮＢなどのスケジューリングデバイスとの間の１つのコンフィギュレーションが整合しない場合、第２のＳＲコンフィギュレーションが依然として使用されてもよい。
他の利点は、遅延に関するものである。例えば、ｋスロット毎の後のＳＲ周期による単一のＳＲコンフィギュレーションの場合、繰り返しはｋスロット毎に最先に実行される。複数のＳＲコンフィギュレーションの場合、複数のコンフィギュレーションのためのＳＲのリソースは独立している。コンフィギュレーション１がスロットｋで設定され、コンフィギュレーション２がスロットｋ＋１で設定される場合、１回目のＳＲ送信はスロットｋで実行され、ＳＲの繰り返しはスロットｋ＋１のコンフィギュレーション２で実行されてもよい。従って、遅延全体がさらに低減されうる。
加えて又は代わりに、ＳＲ送信のための追加のＳＲコンフィギュレーション及び／又は追加のリソースが設定される必要はないが、例えば、高い優先度の論理チャネルは、繰り返しのために、より低い優先度の論理チャネルのＳＲコンフィギュレーション／リソースを利用してもよい。
図１９は、実施例による複数の機会でスケジューリングリクエストを送信するよう送受信機に指示することによって、ＭＡＣレイヤ上でのスケジューリングリクエストの繰り返し送信を示すフローチャートである。ＵＥ ＭＡＣレイヤエンティティは、例えば、ＲＲＣメッセージを介し２つのＳＲコンフィギュレーションに従ってＳＲの繰り返しを実行するよう設定されてもよい。ステップＳ２００において、第１のＳＲコンフィギュレーションによる１回目のＳＲ送信が、ＵＥ ＭＡＣレイヤ上でトリガされる。さらに、ステップＳ２１０において、第１のＳＲ禁止タイマが始動される。次に、ステップＳ２２０において、ＭＡＣレイヤは、第２のＳＲコンフィギュレーションに従って２回目のＳＲ送信をトリガする。続いて、ステップＳ２３０において、第２のＳＲ禁止タイマが始動される。ＳＲ禁止タイマが満了しない限り、ＵＥ ＭＡＣレイヤエンティティは、それぞれのＳＲコンフィギュレーションに従ってＳＲ送信をトリガしない。ＳＲ禁止タイマが満了し、スケジューリングデバイスからアップリンクグラントが受信されなかったとき、ＵＥ ＭＡＣレイヤは、それぞれのＳＲコンフィギュレーションに従ってＳＲ送信を再度トリガする。
遅延した禁止タイマの始動によるＬＣＨ毎の複数のＳＲコンフィギュレーションに基づく繰り返し
いくつかの実施例では、スケジューリングデバイス２１０は、論理チャネル毎にＳＲ送信の許容（最大）数Ｎを設定してもよく、各論理チャネルは複数のＳＲコンフィギュレーションにマッピングされる。
例えば、図２０に示されるように、ＬＣＨは、コンフィギュレーション１及び２として示される２つのＳＲコンフィギュレーションにマッピングされる。言い換えれば、ＳＲ送信のための複数の機会が、論理チャネル毎に複数のＳＲコンフィギュレーションを介して提供され、ＳＲの繰り返しは、異なるＳＲコンフィギュレーション及びＳＲ送信数Ｎに基づく。
本実施例によるＬＣＨコンフィギュレーションを示す論理チャネルコンフィギュレーション要素が、図２１と共に以下で示される。
Figure 2022521086000006
示されるように、論理チャネルコンフィギュレーションは、スケジューリングリクエスト許容数（“ｎｕｍｂｅｒ ｏｆ ＳＲ ｒｅｐｅｔｉｔｉｏｎ”）と共に、複数のスケジューリングリクエストコンフィギュレーション（“ｓｃｈｅｄｕｌｉｎｇＲｅｑｕｅｓｔＩＤ１”，“ｓｃｈｅｄｕｌｉｎｇＲｅｑｕｅｓｔＩＤ２”）を含んでもよい。ＬＣＨ毎の許容可能なＳＲ繰り返し数及び２つ以上のＳＲコンフィギュレーションへのマッピングは、例えば、ＲＲＣにおけるｇＮＢなどのスケジューリングデバイスによって設定されてもよい。
図２２は、実施例によるＵＥ ＭＡＣレイヤ上でトリガされる複数の機会でのスケジューリングリクエストの送信の概略図であり、スケジューリングリクエストの送信は、２つのスケジューリングリクエストコンフィギュレーション及び設定されたＳＲ送信数に従って複数の機会で指示される。ＳＲ送信の総数は、ＲＲＣメッセージを介しスケジューリングデバイスによって設定されてもよい。
特に、スケジューリングリクエストの１回目の送信は、スロットｎにおける関連する第１の周期による第１のＳＲコンフィギュレーションに従ってＵＥ ＭＡＣレイヤ上でトリガされる。さらに、スケジューリングリクエストの２回目の送信は、スロットｎ＋１における関連する第２の周期による第２のＳＲコンフィギュレーションに従ってＵＥ ＭＡＣレイヤ上でトリガされる。さらに、スケジューリングリクエストの３回目の送信は、第１のＳＲコンフィギュレーションに従ってＵＥ ＭＡＣレイヤ上でトリガされる。さらに、スケジューリングリクエストの４回目の送信は、第２のＳＲコンフィギュレーションに対してＵＥ ＭＡＣレイヤエンティティでトリガされる。
図２２に示される例では、ＳＲ送信（繰り返し）の許容数は４であり、ＬＣＨ毎のＳＲコンフィギュレーションの数は２である。
２つのＳＲコンフィギュレーションによる複数の機会に送信されるＳＲ数の後、第１及び第２のＳＲ禁止タイマが始動（スタート）される。すなわち、双方のＳＲ禁止タイマは、４つ全てのＳＲ送信が送信された後に一緒にスタートされる。ＳＲ禁止タイマが満了していない限り、それぞれのＳＲ送信コンフィギュレーションによるＳＲ送信は、ＵＥ ＭＡＣレイヤ上で指示されない。
あるいは、ＳＲ禁止タイマは、論理チャネル毎に実行されてもよい。全てのＳＲの繰り返しが送信されると、ＵＥは、ＳＲ禁止タイマを始動してもよい。
図１４に示す例では、スケジューリングデバイスによって設定されるＳＲ送信数Ｎは４である。しかしながら、本実施例は、４に限定されず、何れかのＳＲ送信数がスケジューリングデバイスによって設定されてもよい。
本開示は、ソフトウエア、ハードウエア、ハードウエアと連携するソフトウエアによって実現することができる。上述した各実施例の記載に用いられる各機能ブロックは、集積回路などのＬＳＩ（Ｌａｒｇｅ Ｓｃａｌｅ Ｉｎｔｅｇｒａｔｉｏｎ）によって部分的又は全体的に実現することができ、各実施例において説明した各処理は、同一のＬＳＩ又はＬＳＩの組合せによって部分的又は全体的に制御されてもよい。ＬＳＩは、チップとして個別に形成されてもよいし、あるいは、１つのチップが、機能ブロックの一部又は全てを含むように形成されてもよい。ＬＳＩは、それに結合されたデータ入出力を含んでもよい。ここで、ＬＳＩとは、集積度の相違に依存して、ＩＣ、システムＬＳＩ、スーパＬＳＩ、ウルトラＬＳＩとして参照されてもよい。しかしながら、集積回路を実現する技術はＬＳＩに限定されず、専用回路、汎用プロセッサ又は専用プロセッサを用いて実現されてもよい。さらに、ＬＳＩの製造後にプログラム可能なＦＰＧＡ（Ｆｉｅｌｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ）、又はＬＳＩ内部に配置された回路セルの接続及び設定が再構成可能なリコンフィギュラブルプロセッサが利用されてもよい。本開示は、デジタル処理又はアナログ処理として実現することができる。半導体技術や他の派生技術の進歩の結果、将来の集積回路技術がＬＳＩに取って代わる場合、将来の集積回路技術を用いて機能ブロックを集積化することができる。バイオテクノロジーも適用できる。
本開示は、通信装置として参照される、通信機能を有する任意の種別の装置、デバイス又はシステムによって実現することができる。
そのような通信装置のいくつかの非限定的な具体例は、電話機（例えば、セルラ（セル）電話、スマートフォン）、タブレット、パーソナルコンピュータ(ＰＣ)(例えば、ラップトップ、デスクトップ、ネットブック）、カメラ（例えば、デジタルスチル／ビデオカメラ）、デジタルプレーヤ（デジタルオーディオ／ビデオプレーヤ）、ウェアラブルデバイス（例えば、ウェアラブルカメラ、スマートウォッチ、トラッキングデバイス）、ゲームコンソール、デジタルブックリーダ、遠隔ヘルス／遠隔医療（リモートヘルス及び医療）デバイス及び通信機能を提供する車両（例えば、自動車、飛行機、船舶）並びにそれらの各種組み合わせを含む。
通信装置は、携帯型又は可動型であることに限定されず、スマートホームデバイス（例えば、家電、ライティング、スマートメータ、コントロールパネル）、自動販売機及び「Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ（ＩｏＴ）」のネットワークにおける他の任意の「物」など、非携帯型又は固定型である任意の種別の装置、デバイス又はシステムを含んでもよい。
通信は、例えば、セルラシステム、無線ＬＡＮシステム、衛星システムなどとそれらの各種組合せを介しデータを交換することを含んでもよい。
通信装置は、本開示に記載された通信の機能を実行する通信デバイスに結合された制御装置又はセンサなどのデバイスを備えてもよい。例えば、通信装置は、通信装置の通信機能を実行する通信デバイスによって使用される制御信号又はデータ信号を生成する制御装置又はセンサを備えてもよい。
通信装置はまた、基地局、アクセスポイントなどのインフラストラクチャ設備と、上記の非限定的な具体例におけるものなどの装置と通信又は制御する他の任意の装置、デバイス又はシステムとを含んでもよい。
上述されるように、非地上ネットワーク（又は同様の無線通信システム）における有意に高いオーバヘッドを生じさせることなく、スケジューリングリクエストのロバストな送信を可能にするデバイス及び方法が提供される。
動作中に、ＰＵＣＣＨ（Ｐｈｙｓｉｃａｌ Ｕｐｌｉｎｋ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ）の複数の機会でスケジューリングリクエストを送信するよう送受信機に指示することによって、ＭＡＣ（Ｍｅｄｉｕｍ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）レイヤ上でスケジューリングリクエストを繰り返す回路と、動作中に、ＰＵＣＣＨ上でスケジューリングリクエストを送信する送受信機と、を有する送受信デバイスが提供される。
いくつかの実施例では、回路は、動作中に、スケジューリングリクエスト禁止タイマを始動し、スケジューリングリクエスト禁止タイマが動作中である場合には、スケジューリングリクエストを送信するよう送受信機に指示しない。
いくつかの実施例では、送受信機は、動作中に、スケジューリングリクエストの許容数を示す許容リクエストインジケータを受信し、回路は、動作中に、スケジューリングリクエストが許容リクエストインジケータによって通知されたスケジューリングリクエスト許容数に等しい数の機会で送信された後、スケジューリングリクエスト禁止タイマを始動する。
いくつかの実施例では、許容リクエストインジケータは、論理チャネル毎のスケジューリングリクエスト許容数を示す。
いくつかの実施例では、送受信機は、動作中に、ＰＤＣＣＨ（Ｐｈｙｓｉｃａｌ Ｄｏｗｎｌｉｎｋ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ）を介し送信のため送受信デバイスに割り当てられたリソースを示すリソース割当てインジケータを受信し、回路は、動作中に、リソース割当てインジケータに従って、割り当てられたリソースを決定し、スケジューリングリクエスト禁止タイマを停止する。
いくつかの実施例では、送受信機は、動作中に、複数のスケジューリングリクエストコンフィギュレーションを示すスケジューリングリクエストコンフィギュレーションインジケータを受信し、回路は、動作中に、複数のスケジューリングリクエストコンフィギュレーションによる複数の機会でスケジューリングリクエストを送信するよう送受信機に指示する。
いくつかの実施例では、回路は、動作中に、各スケジューリングリクエスト禁止タイマが複数のスケジューリングリクエストコンフィギュレーションの１つと関連付けされる、複数のスケジューリングリクエスト禁止タイマを始動し、複数のスケジューリングリクエストコンフィギュレーションの１つに関連付けされるスケジューリングリクエスト禁止タイマが動作中である場合、前記複数のスケジューリングリクエストコンフィギュレーションの１つによる機会でスケジューリングリクエストを送信するよう送受信機に指示しない。
いくつかの実施例では、回路は、動作中に、各スケジューリングリクエスト禁止タイマを、スケジューリングリクエスト禁止タイマに関連付けされる複数のスケジューリングリクエストの１つによるスケジューリングリクエストが送信されると、始動する。
いくつかの実施例では、送受信機は、動作中に、論理チャネル毎のスケジューリングリクエスト許容数を示す許容リクエストインジケータを受信し、回路は、動作中に、各スケジューリングリクエスト禁止タイマを、スケジューリングリクエストが許容リクエストインジケータによって示されるスケジューリングリクエスト許容数による数の機会で送信された後、始動する。
いくつかの実施例では、送受信機は、動作中に、ＰＤＣＣＨ（Ｐｈｙｓｉｃａｌ Ｄｏｗｎｌｉｎｋ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ）を介し送信のため送受信デバイスに割り当てられるリソースを示すリソース割当てインジケータを受信し、回路は、動作中に、リソース割当てインジケータに従って、割り当てられたリソースを決定し、複数のスケジューリングリクエスト禁止タイマを停止する。
更に、動作中に、スケジューリングリクエスト許容数を示す許容リクエストインジケータを決定する回路と、動作中に、許容リクエストインジケータを送信する送受信機と、を有するスケジューリングデバイスが提供される。
いくつかの実施例では、スケジューリングリクエスト許容数が、論理チャネル毎に決定される。
いくつかの実施例では、論理チャネル毎のスケジューリングリクエスト許容数が、論理チャネルの優先度に従って決定されてもよい。
例えば、高い優先度の論理チャネルのスケジューリングリクエスト許容数は、より低い優先度の論理チャネルのスケジューリングリクエスト許容数より大きく決定されてもよい。すなわち、論理チャネル毎のスケジューリングリクエスト許容数は、論理チャネルの優先度に従って決定されてもよい。
いくつかの実施例では、許容リクエストインジケータは、論理チャネル毎のスケジューリングリクエスト許容数を示す。
いくつかの実施例では、送受信機は、動作中に、ＰＵＣＣＨ（Ｐｈｙｓｉｃａｌ Ｕｐｌｉｎｋ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ）の機会でスケジューリングリクエストを受信し、送信のため送受信デバイスに割り当てられたリソースを示すリソース割当てインジケータをＰＤＣＣＨ（Ｐｈｙｓｉｃａｌ Ｄｏｗｎｌｉｎｋ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ）を介し送信する。
更に、動作中に、複数のスケジューリングリクエストコンフィギュレーションを示すスケジューリングリクエストコンフィギュレーションインジケータを決定する回路と、動作中に、スケジューリングリクエストコンフィギュレーションインジケータを送信する送受信機と、を有するスケジューリングデバイスが提供される。
いくつかの実施例では、スケジューリングリクエストコンフィギュレーションの数は、論理チャネル毎に決定される。
いくつかの実施例では、スケジューリングリクエストコンフィギュレーションの総数は、論理チャネルの優先度に従って決定されてもよい。
例えば、高い優先度の論理チャネルのスケジューリングリクエストコンフィギュレーション数は、より低い優先度の論理チャネルのスケジューリングリクエストコンフィギュレーション数より大きく決定されてもよい。すなわち、スケジューリングリクエストコンフィギュレーション数は、論理チャネルの優先度に従って決定されてもよい。
いくつかの実施例では、送受信機は、動作中に、ＰＵＣＣＨ（Ｐｈｙｓｉｃａｌ Ｕｐｌｉｎｋ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ）の機会でスケジューリングリクエストを受信し、送信のため送受信デバイスに割り当てられたリソースを示すリソース割当てインジケータをＰＤＣＣＨ（Ｐｈｙｓｉｃａｌ Ｄｏｗｎｌｉｎｋ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ）を介し送信する。
更に、ＰＵＣＣＨ（Ｐｈｙｓｉｃａｌ Ｕｐｌｉｎｋ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ）の複数の機会でスケジューリングリクエストの送信を指示することによって、スケジューリングリクエストをＭＡＣ（Ｍｅｄｉｕｍ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）レイヤ上で繰り返すステップと、ＰＵＣＣＨ上でスケジューリングリクエストを送信するステップと、を有する方法が提供される。
いくつかの実施例では、当該方法は、スケジューリングリクエスト禁止タイマを始動するステップと、スケジューリングリクエスト禁止タイマが動作中である場合、スケジューリングリクエストの送信を指示しないステップとを有する。
いくつかの実施例では、当該方法は、スケジューリングリクエスト許容数を示す許容リクエストインジケータを受信するステップと、スケジューリングリクエストが許容リクエストインジケータによって示されるスケジューリングリクエスト許容数に等しい数の機会で送信された後、スケジューリングリクエスト禁止タイマを始動するステップとを有する。
いくつかの実施例では、許容リクエストインジケータは、論理チャネル毎のスケジューリングリクエスト許容数を示す。
いくつかの実施例では、当該方法は、送信のため送受信デバイスに割り当てられたリソースを示すリソース割当てインジケータをＰＤＣＣＨ（Ｐｈｙｓｉｃａｌ Ｄｏｗｎｌｉｎｋ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ）を介し受信するステップと、リソース割当てインジケータに従って、割り当てられたリソースを決定するステップと、スケジューリングリクエスト禁止タイマを停止するステップとを有する。
いくつかの実施例では、当該方法は、複数のスケジューリングリクエストコンフィギュレーションを示すスケジューリングリクエストコンフィギュレーションインジケータを受信するステップと、複数のスケジューリングリクエストコンフィギュレーションによる複数の機会でスケジューリングリクエストの送信を指示するステップとを有する。
いくつかの実施例では、当該方法は、各スケジューリングリクエスト禁止タイマが複数のスケジューリングリクエストコンフィギュレーションの１つに関連付けされる、複数のスケジューリングリクエスト禁止タイマを始動するステップと、複数のスケジューリングリクエストコンフィギュレーションの１つに関連付けされるスケジューリングリクエスト禁止タイマが動作中である場合、複数のスケジューリングリクエストコンフィギュレーションの１つによる機会でスケジューリングリクエストの送信を指示しないステップとを有する。
いくつかの実施例では、当該方法は、各スケジューリングリクエスト禁止タイマを、当該スケジューリングリクエスト禁止タイマに関連付けされる複数のスケジューリングリクエストコンフィギュレーションの１つによるスケジューリングリクエストが送信されると、始動するステップを有する。
いくつかの実施例では、当該方法は、論理チャネル毎のスケジューリングリクエスト許容数を示す許容リクエストインジケータを受信するステップと、各スケジューリングリクエスト禁止タイマを、スケジューリングリクエストが許容リクエストインジケータによって示されるスケジューリングリクエスト許容数による数の機会で送信された後、始動するステップとを有する。
いくつかの実施例では、当該方法は、送信のため送受信デバイスに割り当てられたリソースを示すリソース割当てインジケータをＰＤＣＣＨ（Ｐｈｙｓｉｃａｌ Ｄｏｗｎｌｉｎｋ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ）を介し受信するステップと、リソース割当てインジケータに従って、割り当てられたリソースを決定するステップと、複数のスケジューリングリクエスト禁止タイマを停止するステップとを有する。
更に、スケジューリングリクエスト許容数を示す許容リクエストインジケータを決定するステップと、許容リクエストインジケータを送信するステップと、を有する方法が提供される。
いくつかの実施例では、スケジューリングリクエスト許容数は、論理チャネル毎に決定される。
いくつかの実施例では、論理チャネル毎のスケジューリングリクエスト許容数は、論理チャネルの優先度に従って決定されてもよい。
例えば、高い優先度の論理チャネルのスケジューリングリクエスト許容数は、より低い優先度の論理チャネルのスケジューリングリクエスト許容数より大きく決定されてもよい。すなわち、論理チャネル毎のスケジューリングリクエスト許容数は、論理チャネルの優先度に従って決定されてもよい。
いくつかの実施例では、許容リクエストインジケータは、論理チャネル毎のスケジューリングリクエスト許容数を示す。
いくつかの実施例では、当該方法は、ＰＵＣＣＨ（Ｐｈｙｓｉｃａｌ Ｕｐｌｉｎｋ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ）の機会でスケジューリングリクエストを受信するステップと、送信のため送受信デバイスに割り当てられたリソースを示すリソース割当てインジケータをＰＤＣＣＨ（Ｐｈｙｓｉｃａｌ Ｄｏｗｎｌｉｎｋ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ）を介し送信するステップとを有する。
更に、複数のスケジューリングリクエストコンフィギュレーションを示すスケジューリングリクエストコンフィギュレーションインジケータを決定するステップと、スケジューリングリクエストコンフィギュレーションインジケータを送信するステップと、を有する方法が提供される。
いくつかの実施例では、スケジューリングリクエストコンフィギュレーション数は、論理チャネル毎に決定される。
いくつかの実施例では、スケジューリングリクエストコンフィギュレーションの総数は、論理チャネルの優先度に従って決定されてもよい。
例えば、高い優先度の論理チャネルのスケジューリングリクエストコンフィギュレーション数は、より低い優先度の論理チャネルのスケジューリングリクエストコンフィギュレーション数より大きく決定されてもよい。すなわち、スケジューリングリクエストコンフィギュレーション数は、論理チャネルの優先度に従って決定されてもよい。
いくつかの実施例では、当該方法は、ＰＵＣＣＨ（Ｐｈｙｓｉｃａｌ Ｕｐｌｉｎｋ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ）の機会でスケジューリングリクエストを受信するステップと、送信のため送受信デバイスに割り当てられたリソースを示すリソース割当てインジケータをＰＤＣＣＨ（Ｐｈｙｓｉｃａｌ Ｄｏｗｎｌｉｎｋ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ）を介し送信するステップとを有する。

Claims (15)

  1. 動作中に、ＰＵＣＣＨ（Ｐｈｙｓｉｃａｌ Ｕｐｌｉｎｋ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ）の複数の機会でスケジューリングリクエストを送信するよう送受信機に指示することによって、ＭＡＣ（Ｍｅｄｉｕｍ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）レイヤ上でスケジューリングリクエストを繰り返す回路と、
    動作中に、前記ＰＵＣＣＨ上で前記スケジューリングリクエストを送信する前記送受信機と、
    を有する送受信デバイス。
  2. 前記回路は、動作中に、
    スケジューリングリクエスト禁止タイマを始動し、
    前記スケジューリングリクエスト禁止タイマが動作中である場合には、前記スケジューリングリクエストを送信するよう前記送受信機に指示しない、
    請求項１に記載の送受信デバイス。
  3. 前記送受信機は、動作中に、スケジューリングリクエスト許容数を示す許容リクエストインジケータを受信し、
    前記回路は、動作中に、前記スケジューリングリクエストが前記許容リクエストインジケータによって通知された前記スケジューリングリクエスト許容数に等しい数の機会で送信された後、前記スケジューリングリクエスト禁止タイマを始動する、
    請求項２に記載の送受信デバイス。
  4. 前記許容リクエストインジケータは、論理チャネル毎のスケジューリングリクエスト許容数を示す、
    請求項３に記載の送受信デバイス。
  5. 前記送受信機は、動作中に、ＰＤＣＣＨ（Ｐｈｙｓｉｃａｌ Ｄｏｗｎｌｉｎｋ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ）を介し前記送信のため前記送受信デバイスに割り当てられたリソースを示すリソース割当てインジケータを受信し、
    前記回路は、動作中に、
    前記リソース割当てインジケータに従って、前記割り当てられたリソースを決定し、
    前記スケジューリングリクエスト禁止タイマを停止する、
    請求項２から４の何れか一項に記載の送受信デバイス。
  6. 前記送受信機は、動作中に、複数のスケジューリングリクエストコンフィギュレーションを示すスケジューリングリクエストコンフィギュレーションインジケータを受信し、
    前記回路は、動作中に、前記複数のスケジューリングリクエストコンフィギュレーションによる前記複数の機会で前記スケジューリングリクエストを送信するよう前記送受信機に指示する、
    請求項１に記載の送受信デバイス。
  7. 前記回路は、動作中に、
    各スケジューリングリクエスト禁止タイマが前記複数のスケジューリングリクエストコンフィギュレーションの１つと関連付けされる、複数のスケジューリングリクエスト禁止タイマを始動し、
    前記複数のスケジューリングリクエストコンフィギュレーションの１つに関連付けされる前記スケジューリングリクエスト禁止タイマが動作中である場合、前記複数のスケジューリングリクエストコンフィギュレーションの１つによる機会で前記スケジューリングリクエストを送信するよう前記送受信機に指示しない、
    請求項６に記載の送受信デバイス。
  8. 前記回路は、動作中に、各スケジューリングリクエスト禁止タイマを、前記スケジューリングリクエスト禁止タイマに関連付けされる前記複数のスケジューリングリクエストの１つによる前記スケジューリングリクエストが送信されると、始動する、
    請求項７に記載の送受信デバイス。
  9. 前記送受信機は、動作中に、論理チャネル毎のスケジューリングリクエスト許容数を示す許容リクエストインジケータを受信し、
    前記回路は、動作中に、各スケジューリングリクエスト禁止タイマを、前記スケジューリングリクエストが前記許容リクエストインジケータによって示される前記スケジューリングリクエスト許容数による数の機会で送信された後、始動する、
    請求項７に記載の送受信デバイス。
  10. 前記送受信機は、動作中に、ＰＤＣＣＨ（Ｐｈｙｓｉｃａｌ Ｄｏｗｎｌｉｎｋ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ）を介し前記送信のため前記送受信デバイスに割り当てられるリソースを示すリソース割当てインジケータを受信し、
    前記回路は、動作中に、
    前記リソース割当てインジケータに従って、前記割り当てられたリソースを決定し、
    前記複数のスケジューリングリクエスト禁止タイマを停止する、
    請求項６から９の何れか一項に記載の送受信デバイス。
  11. 動作中に、スケジューリングリクエスト許容数を示す許容リクエストインジケータを決定する回路と、
    動作中に、前記許容リクエストインジケータを送信する送受信機と、
    を有するスケジューリングデバイス。
  12. 動作中に、複数のスケジューリングリクエストコンフィギュレーションを示すスケジューリングリクエストコンフィギュレーションインジケータを決定する回路と、
    動作中に、前記スケジューリングリクエストコンフィギュレーションインジケータを送信する送受信機と、
    を有するスケジューリングデバイス。
  13. ＰＵＣＣＨ（Ｐｈｙｓｉｃａｌ Ｕｐｌｉｎｋ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ）の複数の機会でスケジューリングリクエストの送信を指示することによって、前記スケジューリングリクエストをＭＡＣ（Ｍｅｄｉｕｍ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）レイヤ上で繰り返すステップと、
    前記ＰＵＣＣＨ上で前記スケジューリングリクエストを送信するステップと、
    を有する方法。
  14. スケジューリングリクエスト許容数を示す許容リクエストインジケータを決定するステップと、
    前記許容リクエストインジケータを送信するステップと、
    を有する方法。
  15. 複数のスケジューリングリクエストコンフィギュレーションを示すスケジューリングリクエストコンフィギュレーションインジケータを決定するステップと、
    前記スケジューリングリクエストコンフィギュレーションインジケータを送信するステップと、
    を有する方法。
JP2021548627A 2019-02-22 2020-01-30 送受信デバイス及びスケジューリングデバイス Active JP7478745B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
EP19158896.1 2019-02-22
EP19158896.1A EP3700283A1 (en) 2019-02-22 2019-02-22 Transceiver device and scheduling device
PCT/EP2020/052243 WO2020169314A1 (en) 2019-02-22 2020-01-30 Transceiver device and scheduling device

Publications (2)

Publication Number Publication Date
JP2022521086A true JP2022521086A (ja) 2022-04-05
JP7478745B2 JP7478745B2 (ja) 2024-05-07

Family

ID=65529566

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2021548627A Active JP7478745B2 (ja) 2019-02-22 2020-01-30 送受信デバイス及びスケジューリングデバイス

Country Status (5)

Country Link
US (1) US12004147B2 (ja)
EP (2) EP3700283A1 (ja)
JP (1) JP7478745B2 (ja)
CN (1) CN113330803A (ja)
WO (1) WO2020169314A1 (ja)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2022261925A1 (en) * 2021-06-18 2022-12-22 Lenovo (Beijing) Limited Method and apparatus for enhanceing a buffer status report reporting mechanism in a large propagation delay scenario

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9065545B2 (en) * 2012-03-12 2015-06-23 Blackberry Limited Handling scheduling request collisions with an ACK/NACK repetition signal
WO2016056971A1 (en) * 2014-10-09 2016-04-14 Telefonaktiebolaget L M Ericsson (Publ) Methods of operating wireless terminals and related wireless terminals
WO2017026324A1 (ja) 2015-08-07 2017-02-16 シャープ株式会社 端末装置、通信方法、および、集積回路
KR102326651B1 (ko) * 2015-08-13 2021-11-16 삼성전자 주식회사 무선 통신 시스템에서 복수 개의 자원 요청을 처리하는 장치 및 방법
GB2542172A (en) * 2015-09-10 2017-03-15 Nec Corp Communication system
EP3342236B1 (en) * 2015-11-16 2020-05-27 Samsung Electronics Co., Ltd. Transmission and reception of repeated scheduling requests
WO2017179814A1 (en) * 2016-04-15 2017-10-19 Lg Electronics Inc. Method for performing transmission of a sr bundle in a wireless communication system and a device therefor
WO2018131895A1 (en) * 2017-01-10 2018-07-19 Samsung Electronics Co., Ltd. Method and system for supporting wide-band and multiple numerologies in wireless communication system
CN116437465A (zh) * 2017-03-24 2023-07-14 北京三星通信技术研究有限公司 窄带物联网系统中调度请求上报的方法和装置
US10524294B2 (en) * 2017-05-04 2019-12-31 Ofinno, Llc Scheduling request transmission
EP4033845B1 (en) 2017-05-04 2024-06-26 ResMed, Inc. Scheduling request in a wireless device
KR102055061B1 (ko) * 2017-06-08 2019-12-11 아서스테크 컴퓨터 인코포레이션 무선 통신 시스템에서의 다중 sr (scheduling request) 구성의 방법 및 장치

Also Published As

Publication number Publication date
CN113330803A (zh) 2021-08-31
EP3700283A1 (en) 2020-08-26
WO2020169314A1 (en) 2020-08-27
US12004147B2 (en) 2024-06-04
EP3928579B1 (en) 2024-03-06
US20210385833A1 (en) 2021-12-09
JP7478745B2 (ja) 2024-05-07
EP3928579A1 (en) 2021-12-29

Similar Documents

Publication Publication Date Title
EP3780839A1 (en) User equipment and scheduling node
US11877320B2 (en) Method and apparatus for enhancing resource allocation in NR V2X
CN113287282A (zh) 冲突处置
US11350308B2 (en) Method and apparatus for transmitting buffer status report in wireless communication system
US20220132530A1 (en) User equipment and base station
US20220104124A1 (en) Transceiver device and scheduling device
US20220264616A1 (en) Transceiver device and scheduling device
CN114556832A (zh) 基于服务的上行链路重传
CN109963340B (zh) 用于降低信令开销和数据延迟的方法、设备及计算机可读介质
US12004147B2 (en) Transceiver device and scheduling device
EP4014569A1 (en) Transceiver device and base station
US20230189272A1 (en) Buffer status report enhancement
CN116192337A (zh) 无线通信的方法及装置
CN116830697A (zh) 一种cg资源处理方法、终端设备及网络设备
WO2022237629A1 (zh) 一种信息传输的方法与装置
EP4376480A1 (en) Method and device for controlling traffic flow through sidelink relay in wireless communication system
WO2021155574A1 (zh) 信道处理方法、装置、设备及存储介质
CN116830500A (zh) 具有上行链路消息重复的在上行链路消息中复用的上行链路控制信息（uci）
CN116471680A (zh) Harq-ack信息反馈方法和装置
CN116996172A (zh) 定时提前量报告发送方法及装置
CN117501783A (zh) 在nr v2x中基于sci执行sl drx操作的方法和设备
CN116896795A (zh) 用于侧信息协助的蜂窝通信的随机接入过程的装置和方法
CN116326015A (zh) 传输方法和终端设备
CN115997439A (zh) 无线通信的方法和终端设备
CN116391411A (zh) 传输方法和终端设备

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20211014

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20230124

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20231121

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20240215

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20240326

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20240422

R150 Certificate of patent or registration of utility model

Ref document number: 7478745

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150