IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカの特許一覧

特許7478745送受信デバイス及びスケジューリングデバイス
<>
  • 特許-送受信デバイス及びスケジューリングデバイス 図1
  • 特許-送受信デバイス及びスケジューリングデバイス 図2
  • 特許-送受信デバイス及びスケジューリングデバイス 図3
  • 特許-送受信デバイス及びスケジューリングデバイス 図4
  • 特許-送受信デバイス及びスケジューリングデバイス 図5
  • 特許-送受信デバイス及びスケジューリングデバイス 図6
  • 特許-送受信デバイス及びスケジューリングデバイス 図7
  • 特許-送受信デバイス及びスケジューリングデバイス 図8
  • 特許-送受信デバイス及びスケジューリングデバイス 図9
  • 特許-送受信デバイス及びスケジューリングデバイス 図10
  • 特許-送受信デバイス及びスケジューリングデバイス 図11
  • 特許-送受信デバイス及びスケジューリングデバイス 図12
  • 特許-送受信デバイス及びスケジューリングデバイス 図13
  • 特許-送受信デバイス及びスケジューリングデバイス 図14
  • 特許-送受信デバイス及びスケジューリングデバイス 図15
  • 特許-送受信デバイス及びスケジューリングデバイス 図16
  • 特許-送受信デバイス及びスケジューリングデバイス 図17
  • 特許-送受信デバイス及びスケジューリングデバイス 図18
  • 特許-送受信デバイス及びスケジューリングデバイス 図19
  • 特許-送受信デバイス及びスケジューリングデバイス 図20
  • 特許-送受信デバイス及びスケジューリングデバイス 図21
  • 特許-送受信デバイス及びスケジューリングデバイス 図22
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2024-04-24
(45)【発行日】2024-05-07
(54)【発明の名称】送受信デバイス及びスケジューリングデバイス
(51)【国際特許分類】
   H04W 72/1268 20230101AFI20240425BHJP
   H04W 72/21 20230101ALI20240425BHJP
【FI】
H04W72/1268
H04W72/21
【請求項の数】 14
(21)【出願番号】P 2021548627
(86)(22)【出願日】2020-01-30
(65)【公表番号】
(43)【公表日】2022-04-05
(86)【国際出願番号】 EP2020052243
(87)【国際公開番号】W WO2020169314
(87)【国際公開日】2020-08-27
【審査請求日】2023-01-24
(31)【優先権主張番号】19158896.1
(32)【優先日】2019-02-22
(33)【優先権主張国・地域又は機関】EP
(73)【特許権者】
【識別番号】514136668
【氏名又は名称】パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ
【氏名又は名称原語表記】Panasonic Intellectual Property Corporation of America
(74)【代理人】
【識別番号】110002952
【氏名又は名称】弁理士法人鷲田国際特許事務所
(72)【発明者】
【氏名】シャー リキン
(72)【発明者】
【氏名】タオ ミン-フン
(72)【発明者】
【氏名】バムリ アンキット
(72)【発明者】
【氏名】西尾 昭彦
【審査官】米倉 明日香
(56)【参考文献】
【文献】米国特許出願公開第2017/0142749(US,A1)
【文献】国際公開第2017/026324(WO,A1)
【文献】国際公開第2018/204770(WO,A1)
【文献】InterDigital Inc.,SR Resource Configuration in NR,3GPP TSG RAN WG2 #99 R2-1708726,2017年08月11日
【文献】Samsung,SR handling in Rel-13 Ehanced Coverage MTC,3GPP TSG-RAN WG2 #92 R2-156815,2015年11月07日
【文献】ITRI,Discussion on SR configuration mapping,3GPP TSG RAN WG2 #99b R2-1711764,2017年09月29日
(58)【調査した分野】(Int.Cl.,DB名)
H04B 7/24- 7/26
H04W 4/00-99/00
3GPP TSG RAN WG1-4
SA WG1-4
CT WG1、4
(57)【特許請求の範囲】
【請求項1】
動作中に、PUCCH(Physical Uplink Control Channel)の複数の機会でスケジューリングリクエストを送信するよう送受信機に指示することによって、MAC(Medium Access Control)レイヤ上でスケジューリングリクエストを繰り返す回路と、
動作中に、前記PUCCH上で前記スケジューリングリクエストを送信する前記送受信機と、
を有し、
前記送受信機は、論理チャネル毎の動作中に、複数のスケジューリングリクエストコンフィギュレーションによって設定された、スケジューリングリクエストの許容される総数を示す許容リクエストインジケータを受信する、
送受信デバイス。
【請求項2】
前記回路は、動作中に、
スケジューリングリクエスト禁止タイマを始動し、
前記スケジューリングリクエスト禁止タイマが動作中である場合には、前記スケジューリングリクエストを送信するよう前記送受信機に指示しない、
請求項1に記載の送受信デバイス。
【請求項3】
記回路は、動作中に、前記スケジューリングリクエストが前記許容リクエストインジケータによって通知されたスケジューリングリクエスト許容数に等しい数の機会で送信された後、前記スケジューリングリクエスト禁止タイマを始動する、
請求項2に記載の送受信デバイス。
【請求項4】
前記送受信機は、動作中に、PDCCH(Physical Downlink Control Channel)を介し前記送信のため前記送受信デバイスに割り当てられたリソースを示すリソース割当てインジケータを受信し、
前記回路は、動作中に、
前記リソース割当てインジケータに従って、前記割り当てられたリソースを決定し、
前記スケジューリングリクエスト禁止タイマを停止する、
請求項2又は3に記載の送受信デバイス。
【請求項5】
前記送受信機は、動作中に、前記複数のスケジューリングリクエストコンフィギュレーションを示すスケジューリングリクエストコンフィギュレーションインジケータを受信し、
前記回路は、動作中に、前記複数のスケジューリングリクエストコンフィギュレーションによる前記複数の機会で前記スケジューリングリクエストを送信するよう前記送受信機に指示する、
請求項1に記載の送受信デバイス。
【請求項6】
前記回路は、動作中に、
各スケジューリングリクエスト禁止タイマが前記複数のスケジューリングリクエストコンフィギュレーションの1つと関連付けされる、複数のスケジューリングリクエスト禁止タイマを始動し、
前記複数のスケジューリングリクエストコンフィギュレーションの1つに関連付けされる前記スケジューリングリクエスト禁止タイマが動作中である場合、前記複数のスケジューリングリクエストコンフィギュレーションの1つによる機会で前記スケジューリングリクエストを送信するよう前記送受信機に指示しない、
請求項に記載の送受信デバイス。
【請求項7】
前記回路は、動作中に、各スケジューリングリクエスト禁止タイマを、前記スケジューリングリクエスト禁止タイマに関連付けされる前記複数のスケジューリングリクエストコンフィギュレーションの1つによる前記スケジューリングリクエストが送信されると、始動する、
請求項に記載の送受信デバイス。
【請求項8】
前記送受信機は、動作中に、論理チャネル毎のスケジューリングリクエスト許容数を示す許容リクエストインジケータを受信し、
前記回路は、動作中に、各スケジューリングリクエスト禁止タイマを、前記スケジューリングリクエストが前記許容リクエストインジケータによって示されるスケジューリングリクエスト許容数による数の機会で送信された後、始動する、
請求項に記載の送受信デバイス。
【請求項9】
前記送受信機は、動作中に、PDCCH(Physical Downlink Control Channel)を介し前記送信のため前記送受信デバイスに割り当てられるリソースを示すリソース割当てインジケータを受信し、
前記回路は、動作中に、
前記リソース割当てインジケータに従って、前記割り当てられたリソースを決定し、
前記複数のスケジューリングリクエスト禁止タイマを停止する、
請求項に記載の送受信デバイス。
【請求項10】
動作中に、スケジューリングリクエスト許容数を示す許容リクエストインジケータを決定する回路と、
動作中に、前記許容リクエストインジケータを送信する送受信機と、
を有し、
前記許容リクエストインジケータは、論理チャネル毎の動作中に、複数のスケジューリングリクエストコンフィギュレーションによって設定された、スケジューリングリクエストの許容される総数を示す、
スケジューリングデバイス。
【請求項11】
PUCCH(Physical Uplink Control Channel)の複数の機会でスケジューリングリクエストの送信を指示することによって、前記スケジューリングリクエストをMAC(Medium Access Control)レイヤ上で繰り返すステップと、
前記PUCCH上で前記スケジューリングリクエストを送信するステップと、
を有し、
論理チャネル毎の動作中に、複数のスケジューリングリクエストコンフィギュレーションによって設定された、スケジューリングリクエストの許容される総数を示す許容リクエストインジケータを受信する、
方法。
【請求項12】
スケジューリングリクエスト許容数を示す許容リクエストインジケータを決定するステップと、
前記許容リクエストインジケータを送信するステップと、
を有し、
前記許容リクエストインジケータは、論理チャネル毎の動作中に、複数のスケジューリングリクエストコンフィギュレーションによって設定された、スケジューリングリクエストの許容される総数を示す、
方法。
【請求項13】
送受信デバイスの処理を制御する集積回路であって、前記処理は、
PUCCH(Physical Uplink Control Channel)の複数の機会でスケジューリングリクエストの送信を指示することによって、前記スケジューリングリクエストをMAC(Medium Access Control)レイヤ上で繰り返す処理と、
前記PUCCH上で前記スケジューリングリクエストを送信する処理と、
論理チャネル毎の動作中に、複数のスケジューリングリクエストコンフィギュレーションによって設定された、スケジューリングリクエストの許容される総数を示す許容リクエストインジケータを受信する処理と、
を含む、集積回路。
【請求項14】
スケジューリングデバイスの処理を制御する集積回路であって、前記処理は、
スケジューリングリクエスト許容数を示す許容リクエストインジケータを決定する処理と、
前記許容リクエストインジケータを送信する処理と、
を含み、
前記許容リクエストインジケータは、論理チャネル毎の動作中に、複数のスケジューリングリクエストコンフィギュレーションによって設定された、スケジューリングリクエストの許容される総数を示す、
集積回路。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、通信システムにおける信号の送信及び受信に関する。特に、本開示は、このような送信及び受信のための方法及び装置に関する。
【背景技術】
【0002】
3GPP(3rd Generation Partnership Project)は、サブ1GHzからミリ波帯までの範囲の周波数で動作する“New Radio”(NR)無線アクセス技術(RAT)を含む、第5世代(5G)とも呼ばれる次世代セルラ技術のための技術仕様に取り組んでいる。NRは、LTE(Long Term Evolution)及びLTE-A(LTE Advanced)によって表現される技術の後継である。
【0003】
LTE、LTE-A及びNRなどのシステムについて、更なる改良及び選択肢は、システムに関する特定のデバイスとともに、通信システムの効率的な処理を容易にするものであってもよい。
【発明の概要】
【0004】
1つの非限定的で例示的な実施例は、リソース割当てに対する信頼できる低遅延のリクエストを提供することを容易にする。
【0005】
実施例では、ここに開示される技術は、動作中に、PUCCH(Physical Uplink Control Channel)の複数の機会でスケジューリングリクエストを送信するよう送受信機に指示することによって、MAC(Medium Access Control)レイヤ上でスケジューリングリクエストを繰り返す回路と、動作中に、前記PUCCH上で前記スケジューリングリクエストを送信する前記送受信機と、を有する送受信デバイスを特徴とする。
【0006】
一般的又は具体的な実施例は、システム、方法、集積回路、コンピュータプログラム、記憶媒体又はそれらの何れかの選択的な組合せとして実現されてもよいことが留意されるべきである。
【0007】
開示された実施例の追加的な利点及び効果は、明細書及び図面から明らかになるであろう。利点及び/又は効果は、明細書及び図面の各種実施例及び特徴によって個別に取得されてもよく、これらの全てが、そのような利点及び/又は効果のうちの1つ以上を取得するため提供される必要はない。
【図面の簡単な説明】
【0008】
以下において、例示的な実施例が、添付した図面を参照してより詳細に説明される。
図1】LTE eNB、gNB及びUEのための一例となるユーザ及び制御プレーンアーキテクチャを含む3GPP NRシステムのための一例となるアーキテクチャを示す。
図2】トランスペアレント衛星による非地上ネットワークシナリオを示す。
図3】gNBが衛星上に実装される非地上ネットワークシナリオを示す。
図4】3GPP TR38.321に規定されるようなスケジューリングリクエストの設定のために利用されるスケジューリングリクエストコンフィギュレーション情報要素を示す。
図5】特定の周期で設定されるスケジューリングリクエストの送信を示す。
図6】PUCCH繰り返しによるスケジューリングリクエストの繰り返しの送信の概略図である。
図7】実施例によるスケジューリングデバイス及び送受信デバイスの機能コンポーネントを示すブロック図である。
図8】実施例によるMACレイヤ上でトリガされる複数の機会でのスケジューリングリクエストの送信の概略図である。
図9】論理チャネル毎の単一のスケジューリングリクエストコンフィギュレーションのマッピングを概略的に示す。
図10】許容可能なスケジューリングリクエストの送信数の指定を含むNR論理チャネルコンフィギュレーション要素の具体例を示す。
図11】SRの送信数がSRの繰り返しが設定されない低優先度論理チャネルと高優先度論理チャネルについて設定されることを示す。
図12】複数の機会でのスケジューリングリクエストの送信後にスケジューリングリクエスト禁止タイマが始動される実施例によるMACレイヤ上でトリガされる複数の機会でのスケジューリングリクエストの送信の概略図である。
図13】複数回のスケジューリングリクエストの送信後にスケジューリングリクエスト禁止タイマが始動され、2フレーム毎のスロットnにおける周期が適用される実施例によるMACレイヤ上でトリガされる複数の機会でのスケジューリングリクエストの送信の概略図である。
図14】実施例による複数の機会でのスケジューリングリクエストの送信を示すフローチャートである。
図15】実施例によるコンフィギュレーションを通知する論理チャネルコンフィギュレーション要素を示す。
図16】論理チャネル毎に2つのスケジューリングリクエストコンフィギュレーションのマッピングを概略的に示す。
図17】高優先度論理チャネルがSRコンフィギュレーション1及びSRコンフィギュレーション2にマッピングされ、低優先度論理チャネルがSRコンフィギュレーション2のみにマッピングされる具体例を示す。
図18】スケジューリングの送信が2つのスケジューリングリクエストコンフィギュレーションによる機会でトリガされる実施例によるMACレイヤ上でトリガされる複数の機会でのスケジューリングリクエストの送信の概略図である。
図19】実施例による2つのスケジューリングリクエストコンフィギュレーションによる複数の機会でのスケジューリングリクエストの送信を示すフローチャートである。
図20】設定されたSR繰り返し数による2つのSRコンフィギュレーションにマッピングされる論理チャネルを示す。
図21】実施例によるコンフィギュレーションを通知する論理チャネルコンフィギュレーション要素を示す。
図22】スケジューリングリクエストの送信が2つのスケジューリングリクエストコンフィギュレーションと設定されたSR送信数とによる機会でトリガされる実施例によるMACレイヤ上でトリガされる機会でのスケジューリングリクエストの送信の概略図である。
【発明を実施するための形態】
【0009】
図1は、基地局、端末及びコアネットワークを含む通信ネットワークの一例を示す。このような通信システムは、NR、LTE及び/又はUMTSなどの3GPPシステムであってもよい。例えば、図1に示されるように、基地局(BS)は、gNB(gNodeB,例えば、NR基地局)又はeNB(eNodeB,例えば、LTE基地局)であってもよい。しかしながら、本開示は、これら3GPPシステム又は他の何れかのシステムに限定されるものでない。実施例及び例示的な実現形態が3GPPシステムのいくつかの用語を用いて説明されるが、本開示はまた他の何れかの通信システム、特に何れかのセルラ、無線及び/又は移動システムに適用可能である。
【0010】
NRは、例えば、eMBB(enhanced Mobile Broadband)、URLLC(Ultra-Reliable Low-Latency Communication)、mMTC(massive Machine Type Communication)などを含む、規定された複数の使用シナリオ、要件及び配備シナリオに対処する単一の技術的枠組みを提供することを容易にするように設計される。例えば、eMBB配備シナリオは、室内ホットスポット、密集した都市、地方、都市マクロ及び高速を含んでもよく、URLLC配備シナリオは、産業制御システム、モバイルヘルスケア(遠隔監視、診断及び処置)、車両のリアルタイム制御、スマートグリッドのための広域監視及び制御システムを含んでもよく、mMTCは、スマートウェアラブル及びセンサネットワークのような非タイムクリティカルなデータ転送による多数のデバイスを備えるシナリオを含んでもよい。eMBB及びURLLCサービスは、それらの双方が非常に広い帯域幅を要求するという点で類似しているが、URLLCサービスは超低遅延を要求するという点で異なっている。NRでは、物理レイヤは時間-周波数リソース(LTEと同様に、OFDM(Orthogonal Frequency Division Multiplexing)など)に基づいており、複数アンテナ動作をサポートしてもよい。
【0011】
端末は、LTE及びNRにおいてユーザ装置(UE)と呼ばれる。これは、ワイヤレスフォン、スマートフォン、タブレットコンピュータ又はユーザ装置の機能を備えたUSB(Universal Serial Bus)スティックなどの移動デバイスであってもよい。しかしながら、移動デバイスという用語はこれに限定されず、一般的には、中継がまたそのような移動デバイスの機能を有してもよく、移動デバイスはまた、中継として機能しうる。
【0012】
基地局は、ネットワークノードであり、例えば、サービスを端末に提供するためのネットワークの一部を形成する。基地局は、端末に対する無線アクセスを提供するネットワークノードである。端末と基地局との間の通信は、典型的には標準化されている。LTE及びNRでは、無線インタフェースプロトコルスタックは、物理レイヤ、媒体アクセスレイヤ(MAC)及び上位レイヤを含む。制御プレーンでは、上位レイヤプロトコルであるRRC(Radio Resource Control)プロトコルが提供される。RRCを介し、基地局は端末の設定を制御可能であり、端末は、接続及びベアラ確立、変更などの制御タスク、測定及び他の機能を実行するよう基地局と通信してもよい。
【0013】
あるレイヤによって上位レイヤに提供されるデータの転送のためのサービスは、通常はチャネルと呼ばれる。例えば、LTE及びNRは、MACレイヤによって上位レイヤに対して提供される論理チャネル、物理レイヤによってMACレイヤによって提供されるトランスポートチャネル、及び物理リソース上のマッピングを規定する物理チャネルを区別する。
【0014】
論理チャネルは、MACによって提供される各種のデータ転送サービスである。各論理チャネルタイプは、どのタイプの情報が転送されるかによって定義される。論理チャネルは、制御チャネルとトラフィックチャネルの2つのグループに分類される。制御チャネルは、制御プレーン情報の転送のみに使用される。トラフィックチャネルは、ユーザプレーン情報の転送のみに使用される。
【0015】
そして、論理チャネルは、MACレイヤによってトランスポートチャネルにマッピングされる。例えば、論理トラフィックチャネル及びいくつかの論理制御チャネルは、ダウンリンクではDLSCH(Downlink Shared Channel)と呼ばれるトランスポートチャネル上にマッピングされてもよく、アップリンクではULSCH(Uplink Shared Channel)と呼ばれるトランスポートチャネル上にマッピングされてもよい。
【0016】
非地上ネットワーク
3GPPでは、非地上ネットワーク(NTN)におけるNRベースの動作が、検討及び説明される(例えば、3GPP TR 38.811,Study on New Radio(NR) to support non-terrestrial networks,version 15.0.0、及び3GPP TR 38.821,Solutions for NR to support non-terrestrial networks,version 0.3.0を参照されたい)。
【0017】
物理的攻撃及び自然災害に対する宇宙/空中ビークルの広範なサービスカバレッジ能力及び低下される脆弱性ため、NTNは、地上NRネットワークによってカバーできず(例えば、孤立若しくは遠隔エリア、航空機又は船舶)、サービス提供できない(例えば、郊外及び地方エリア)未サービスエリアにおけるNRサービスの展開を促進しうる。さらに、NTNは、移動プラットフォーム上の乗客にサービス継続性を提供することによって、又は、特に重要な通信のために何れの場所でもサービス可用性を保証することによって、NRサービスの信頼性を強化してもよい。
【0018】
その利点は、非地上ネットワークの単独動作又は統合された地上及び非地上ネットワークの何れかに関連し、カバレッジ、ユーザ帯域幅、システム容量、サービス信頼性又は可用性に影響を与えうる。
【0019】
非地上ネットワークは、例えば、衛星に搭載されたRFリソースを使用するネットワーク又はネットワークの一部を表す。NTNは、典型的には、以下のシステム要素、すなわち、衛星が3GPP UEに直接的にサービス提供しない場合には、3GPP UE又は衛星システムに固有の端末、ユーザ装置と宇宙/空中プラットフォームとの間の無線リンクを表すサービスリンク、ペイロードに搭載する空中プラットフォーム、宇宙/空中プラットフォームをコアネットワークに接続するゲートウェイ、ゲートウェイセンタの宇宙/空中プラットフォーム間の無線リンクを表すフィーダリンク、を特徴とする。
【0020】
図2は、端末(UE)間の送信が静止衛星とNTNゲートウェイとを含むリモート無線ユニットを介し実行される非地上ネットワークのシナリオを示す。gNBは、スケジューリングデバイスとしてゲートウェイに配置される。衛星のペイロードは、アップリンク方向とダウンリンク方向との両方で周波数変換及び無線周波増幅器を実装する。従って、衛星は、(NTNゲートウェイと衛星との間の)フィーダリンクから(衛星とUEとの間の)サービスリンクへ、およびその逆で、NR無線インタフェースを繰り返す。
【0021】
図3は、端末(UE)間の送信がスケジューリングデバイスとしてgNBを含む静止衛星を介し実行される非地上ネットワークのシナリオを示す。
【0022】
非地上ネットワーク及び往復遅延
電磁波を介することに基づく全ての信号送信は、光速による信号送信遅延を受ける。特に、ソースとデスティネーションとの間の無線信号の一方向の伝搬遅延の2倍は、往復遅延(RTD)と呼ばれる。生成されるレスポンス信号の処理ノードにおける処理時間がまた、RTDに含まれてもよい。
【0023】
特に、往復遅延は、例えば、端末(UE)などのソースノードとデスティネーションノードとの間の距離に依存する。信号が衛星等を介して送信されるNTNでは、RTDの値は、地上ネットワークよりもはるかに大きくなりうる。例えば、静止軌道上、すなわち、高度約35786kmにある衛星を介して送信される信号の場合、図2に示すように、NRにおけるgNBなどのスケジューリングデバイスがゲートウェイに配置される場合には、RTDは、541.14msの大きさになりうる。
【0024】
図2に示されるシナリオは、541.14msの往復遅延と関連付けされ、図3に示されるシナリオは、271.57msの往復遅延と関連付けされる。図2及び3に示されるシナリオの往復遅延の値は、テーブル1に要約される。
【0025】
【表1】
【0026】
スケジューリング
3GPPでは、NRベース動作におけるスケジューリングが記載される(例えば、3GPP TR 38.321,NR,Medium Access Control(MAC) protocol specification,version 15.4.0を参照されたい)。
【0027】
スケジューリングは、NR及び/又はLTEのような通信システムの中心部分である。各時点について、スケジューラは、共有された時間-周波数リソースが何れのUEに割り当てるべきかを決定する。アップリンク、ダウンリンク及び/又はサイドリンク送信がスケジューリングされてもよい。
【0028】
特に、アップリンクスケジューラは、何れの端末がそれらのアップリンク共有チャネル(ULSCH)上で送信すべきかを動的に制御する責任がありうる。スケジューリングされた各端末には、端末がそれのULSCHを送信すべきリソースのセットを含むスケジューリンググラントが提供される。
【0029】
言い換えると、アップリンクスケジューリングの機能は、何れのデバイスが何れのアップリンクリソースで送信すべきかを動的に決定することである。動的スケジューリングは、典型的には、Physical Downlink Control CHannel(PDCCH)によって実行される。物理ダウンリンク制御チャネルは、Downlink Control Information(DCI)とも呼ばれうるスケジューリンググラント及び他の制御情報を搬送する。各端末(UE)は、PDCCHをモニタリングする。これは、UEがサーチスペースと呼ばれる特定のリソースを(ブラインドで)復号することを意味する。PDCCHのサーチスペースは、PDCCHが搬送されうるダウンリンクリソースグリッドにおけるエリアである。UEは、これらのサーチスペースにおいてブラインド復号を実行し、PDCCHデータ(DCI)を検出しようとする。PDCCHを復号するため、UEは、自らのRNTI(Radio Network Temporary Identity)を適用し、Control Channel Element(CCE)と呼ばれるリソースにおいてPDCCHを復号しようとする。復号が成功した場合(巡回冗長チェックなどの誤り検出符号によってチェックできる)、DCIが受信される。UEはまた、いくつかの選択された送信パラメータについて各種パラメータ値をブラインドに試みてもよい。各端末は、2つ以上のPDCCHをモニタリングしてもよい。PDCCHは、UEのグループに共通であってもよく(この場合、UEは共通のグループRNTIを使用している)、又は、特定のUEに専用であってもよい。
【0030】
規格(LTE又はNR)は、DCIのいくつかの異なるフォーマットを規定している。これらのフォーマットは、目的に応じて互いに異なる。例えば、アップリンクグラントを搬送するためのフォーマット(フォーマット0又は4など)は、ダウンリンクグラントを搬送するフォーマット、又はグラントを全く搬送しないフォーマットとは異なる。また、ビームフォーミング、ブロードキャスト/マルチキャストなどの利用に応じて異なるフォーマットが規定される。
【0031】
これに対応して、アップリンクでは、物理レイヤに関する制御情報がPhysical Uplink Control Channelによって搬送される。PUCCHは、UCI(Uplink Control Information)と呼ばれるパラメータのセットを搬送する。これは、上述したDCIを搬送するPDCCHと同様である。PUCCHにおいてUCIが搬送する情報の種別に応じて、PUCCHはまた、異なるフォーマットで利用可能である。例えば、
-フォーマット1は、スケジューリングリクエストSRを搬送する。
-フォーマット4は、チャネル状態情報(CSI)と一緒にSRを搬送する。
-フォーマット3は、HARQアクノリッジメント(肯定的又は否定的)及びCSIと一緒にSRを搬送する。
【0032】
LTE及び/又はNRによって規定される更なるフォーマットがある。
【0033】
アップリンクスケジューリングのための基礎は、ULSCHの送信に使用するリソース及び関連するトランスポートフォーマットに関するデバイス情報を提供することを含むスケジューリンググラントである。言い換えれば、(例えば、規格で規定された)あるフォーマットを有するDCIは、リソースグラントに対応するリソース割当て(RA)を、変調符号化方式(MCS)、MIMO(Multiple Input Multiple Output)送信のための設定などのいくつかの更なる送信パラメータと共に搬送してもよい。
【0034】
端末が有効なグラントを有する場合、端末は、リソース割当てによって指定されたPhysical Uplink Shared Channel(PUSCH)上にマッピングされたそれの対応するULSCHを送信することが許可される。
【0035】
すなわち、スケジューラは、送信すべきデータを有する端末に関する知識を必要とし、そのため、アップリンクリソースをスケジューリングする必要がある。許可されたリソースを充填するためのパディングをデバイスに実行させるため、送信すべきデータがないデバイスにアップリンクリソースを提供する必要はない。従って、スケジューラは、デバイスが送信すべきデータを有し、グラントが与えられるべきか否かを知る必要がある。
【0036】
スケジューリングリクエスト
スケジューリングリクエストは、有効なスケジューリンググラントを有さない端末に対して使用されてもよい。スケジューリングリクエストは、Pysical Uplink Control Channel(PUCCH)上で送信されてもよい。各端末には、nサブフレーム毎に発生する専用のスケジューリングリクエストリソースが割り当てられてもよい。スケジューリングリクエストは、アップリンクスケジューラからアップリンクリソースを要求するため、端末によって提起(設定)されるシンプルなフラグであってもよい。専用のスケジューリングリクエスト機構によると、端末の識別情報はリクエストが送信されるリソースから暗黙的に分かるため、要求元の端末の識別情報は、スケジューリングリクエストと一緒に提供される必要はない。これらは、gNBのようなスケジューリングノードによって、例えば、上位レイヤ制御プロトコルによって設定される。
【0037】
スケジューリングリクエストを受信すると、スケジューリングデバイスは、端末にスケジューリンググラントを割り当てることができる。端末は、スケジューリンググラントを受信した場合、スケジューリングされたリソースにおいてそれのデータを送信する。PUSCH上で送信されるデータは、第1のバッファステータスにおいて、UEが送信しなければならないデータ量をスケジューリングノードに通知することを含んでもよい。バッファステータスに基づいて、スケジューリングノードはその後、PUSCH上の実際のデータリソースをスケジューリングしてもよい。しかしながら、これは単なる1つの選択肢であり、一般に、データリソースはまた直接スケジューリングされてもよい。いくつかのシステムでは、スケジューリングされるように要求された特定のデータ量とスケジューリングリクエストとを関連付けることも可能である。
【0038】
端末が次の可能な瞬間までにスケジューリンググラントを受信しない場合、スケジューリングリクエストは、繰り返されてもよい。
【0039】
従って、PUCCH上のコンテンションフリースケジューリングリクエスト機構が提供され、ここでは、セル内の各端末には、アップリンクリソースに対するリクエストを送信可能な確保されたリソースが与えられる。
【0040】
UE MACエンティティは、0、1又は複数のSRコンフィギュレーションによって設定されてもよい。SRコンフィギュレーションは、異なる帯域幅部分(BWP)にわたるスケジューリングリクエストのためのPUCCHリソースのセットから構成される。論理チャネル(LCH)について、SRのための高々1つのPUCCHリソースがBWP毎に設定される。各SRコンフィギュレーションは、1つ以上の論理チャネルに対応する。論理チャネルとSRコンフィギュレーションとの間のマッピングは、RRC(Radio Resource Control)メッセージングによって設定されてもよい。
【0041】
上述されるように、通常のバッファステータスレポート(BSR)がトリガされたが、BSRを送信するアップリンク無線リソースがUEにおいて利用可能でないとき、SR手順が開始されてもよい。SR手順の間、UEは、SRについてPUCCHリソースが設定されるか否かに応じて、PUCCHを介してSRの送信を実行するか、又は、ランダムアクセス(RA)手順を開始するかの何れかであってもよい。RA手順は、SRのためのPUCCHリソースが設定されていないときに限って開始される。
【0042】
UE MACエンティティが、設定されたSRのための有効なPUCCHリソース上でSR送信位置を有するとき、物理レイヤ(PHY)は、SRのための1つの有効なPUCCHリソース上でSRを通知するよう指示される。その後、SR禁止タイマが開始される(sr_prohibitTimer)。連続するSR送信機会の時点において、MACは、SR禁止タイマが動作中である場合、SRを通知するようPHYに指示しない。
【0043】
NRでは、SRリソースは特定の周期で設定される。SRがUEによって送信されると、SR禁止タイマが始動され、SR禁止タイマが動作中である限り、SRは既に設定されたリソース上では送信されない。
【0044】
3GPP TS 38.331(“NR,Radio Resource Control(RRC),Protocol specification”,version 15.4.0,section 6.3.2)に規定されるようなスケジューリングリクエストの設定に利用されるスケジューリングリクエストコンフィギュレーション情報要素は、図4と共に以下に示される。
【0045】
【表2】
【0046】
特に、スケジューリングリクエスト禁止タイマは、srProhibitTimerによって設定され、スケジューリンググラントが受信されていない場合であっても、SRの送信後にスケジューリングリクエストが送信されない期間を示す。スケジューリングリクエストの最大数は、srTransMaxによって規定される。SrProhibitTimer及びsrTransMaxは、例えば、RRCシグナリングを介して、スケジューリングノードからUEに提供される。
【0047】
図5は、ある周期で設定されたスケジューリングリクエストの送信を示す。この例では、SRの送信の機会は、後続フレームの全てのスロットn内で設定され、各フレームはスロットn~n+9を含む。SR送信がMACレイヤ上で端末によって指示されるとすぐに、図5において太い矢印で示されるように、SR禁止タイマが始動される。SR禁止タイマが動作しているとき、SR送信のために使用される機会に続く機会において、UE MACによってトリガされるSR送信はない。図5では、SR送信機会の周期は、連続するフレームの各スロットnであるが、SRコンフィギュレーション周期はこれに限定されず、他の何れかの周期が設定されてもよい。
【0048】
スケジューリングリクエスト及び往復遅延
上述したように、NTNでは、往復遅延が大きく、SR禁止タイマが満了したとき、SRの受信に応答してスケジューリングデバイス、例えば、NRにおけるgNBによって送信されるスケジューリンググラントが端末によって受信されないことがある。すなわち、SR禁止タイマは、往復遅延を考慮して設定されるべきである。
【0049】
しかしながら、SR禁止タイマが大きな往復遅延を考慮して延長され、送信されたSRが失われたとき、SR禁止タイマが満了した後、SRの再送はUEによって実行される。この結果、UEがアップリンクリソースを取得するのに長時間を要し、NTNにおける送信遅延が大きくなる。
【0050】
さらに、NTNと同様に、セルサイズは大きくてもよく、単一のセルが多数のユーザにサービス提供する。この結果、NTN上での送信のための無線リソースがタイトになる。すなわち、限定された無線リソースが、例えば、地上ネットワークを介した送信と比較して、多数のデバイスによって使用される。
【0051】
SR禁止タイマを増加させ、同時に、送信の低遅延を提供するためにスケジューリングリクエストを繰り返し送信することによって、地上ネットワークと比較してNTNにおける拡大された往復遅延を考慮すると、追加のリソースが、物理レイヤ上での完全なPUCCH再送のために設定されうる。これが、図5に示される。
【0052】
図6は、PUCCH繰り返しによるスケジューリングリクエストの繰り返し送信の概略図である。特に、リソースは、物理レイヤ上のPUCCH全体の繰り返しのために確保されてもよい。PUCCHは、SRに加えて、HARQ(Hybrid Automatic Repeat Request)及び/又はCSI(Channel State Information)などの更なる情報を含んでもよい。すなわち、繰り返しが物理レイヤ上でPUCCH繰り返し全体を介して行われるとき、追加のリソースが必要とされ、有意に高いオーバヘッドを生じさせる。NTNセルサイズは、通常、サービス提供されるべき多数のUEとともに大きくなるため、繰り返しのSR送信を提供するため、大量のリソースが確保される必要がある。
【0053】
本開示は、繰り返しのための追加のリソースが設定されることを必要とすることなく、SRの繰り返し送信によって信頼性を高めることを容易にしうる技術を提供する。さらに、本開示は、追加のオーバヘッドを必要としない技術を提供する。
【0054】
このため、以下に説明される通信方法及び通信デバイスの実施例では、送受信デバイスは、PUCCHの複数の機会でのスケジューリンググラントの送信を指示することによって、MAC(Medium Access Control)レイヤ上でスケジューリングリクエストを繰り返す。スケジューリングリクエストは、受信機によってPUCCHを介し送信される。
【0055】
本開示は、図7に示される送受信デバイス及びスケジューリングデバイスを提供する。送受信デバイス110は、動作中に、PUCCH(Physical Uplink Control Channel)の複数の機会でスケジューリングリクエストを送信するように送受信機に指示することによって、MACレイヤ上でスケジューリングリクエストを繰り返す回路120(又は処理回路)を備える。さらに、送受信デバイス110は、動作中に、PUCCH上でスケジューリングリクエストを送信する送受信機130(1つ以上のアンテナとハードウェアコンポーネントの動作を制御する制御回路などのハードウェアコンポーネントを有する送信機及び/又は受信機)を有する。
【0056】
例えば、送受信デバイス110は、NR NTNにおけるUEである。従って、送受信機130及び回路120はまた、“UE送受信機”及び“UE回路”として本開示に対して留保する。しかしながら、これらの用語は、回路120及び送受信機30を、スケジューリングデバイス又は基地局のような他のデバイスによって構成される回路及び送受信機と区別するためだけに使用される。送受信デバイス110は、同様の通信システムの端末デバイス、中継デバイス又は通信デバイスであってもよい。UE回路は、“スケジューリングリクエスト繰り返し回路”とみなされてもよいし、あるいは、含んでもよい。
【0057】
さらに、図7に示すスケジューリングデバイス210(又はスケジューリングノード)が提供され、これは、動作中にスケジューリングリクエスト許容数を示す許容リクエストインジケータを決定する回路230と、動作中に許容リクエストインジケータを送信する送受信機220とを備える。
【0058】
あるいは、スケジューリングデバイス210(又はスケジューリングノード)は、動作中に複数のスケジューリングリクエストコンフィギュレーションを示すスケジューリングリクエストコンフィギュレーションインジケータを決定する回路230と、動作中にスケジューリングリクエストコンフィギュレーションインジケータを送信する送受信機220とを備えてもよい。
【0059】
例えば、スケジューリングデバイスは、NR NTNシステム(gNB)又は同様の無線通信システムにおけるネットワークノード(基地局)である。回路220はまた、UE回路120、“ネットワークノード回路”などの他の回路と区別するため、“許容リクエスト判定回路”又は“スケジューリングリクエストコンフィギュレーション判定回路”と呼ばれる。
【0060】
さらに、PUCCHの複数の機会でのスケジューリングリクエストの送信を指示することによって、MACレイヤ上でスケジューリングリクエストを繰り返し、PUCCH上でスケジューリングリクエストを送信することを含む方法が提供される。
【0061】
さらに、スケジューリングリクエスト許容数を示す許容リクエストインジケータを決定し、許容リクエストインジケータを送信することを含む方法が提供される。
【0062】
さらに、複数のスケジューリングリクエストコンフィギュレーションを示すスケジューリングリクエストコンフィギュレーションインジケータを決定し、スケジューリングリクエストコンフィギュレーションインジケータを送信することを含む方法が提供される。
【0063】
さらなる説明では、明示的な記述又はコンテキストがそうでないことを示さない限り、詳細及び実施例は、送受信デバイス110、スケジューリングノード(又はスケジューリングデバイス)210及び方法のそれぞれに適用される。
【0064】
送受信デバイスのUE回路120は、MACレイヤ上でスケジューリングリクエストの送信を繰り返す。これは、SRの送信のために設定されたPUCCHの複数の機会でスケジューリングリクエストを送信するように送受信機130に指示することによって実行される。このようにして、繰り返しのSR送信は、送受信デバイスによって実行され、その結果、繰り返しのために追加のリソースを同時に設定することを不要にしながら、信頼性が繰り返しによって増大される。従って、PUCCH全体の繰り返しに関する追加のオーバヘッドは発生しない。
【0065】
言い換えれば、スケジューリングの送信のために設定されたリソース上でのスケジューリングリクエストの送信は、MACレイヤエンティティによってトリガされる。すなわち、物理レイヤ(PHY)は、SR送信の機会にスケジューリングリクエストを送信するよう指示される。MACレイヤエンティティは、例えば、RRCメッセージングによって、SR送信用に設定されたリソースでスケジューリングリクエストを送信するようにPHYに指示することを繰り返す。言い換えると、SRの送信のための繰り返しの指示は、例えば、UEの内部シグナリングによって、MACレイヤによって物理レイヤに提供される。
【0066】
MACレイヤによるSRの繰り返しの特定の利点は、繰り返しが論理チャネル毎に実行可能であり、従って、SRの繰り返しが複数の論理チャネルの1つに対してのみ必要とされることである。MACは、それらの全てに対する代わりに、1つに対してのみ繰り返しをトリガしてもよい。しかしながら、PHYレイヤによるPUCCHの繰り返しでは、それらの全てではなく、特定の論理チャネルに対して繰り返しをトリガすることはできない。
【0067】
例えば、NRでは、UEは、PUCCHフォーマット0又はPUCCHフォーマット1の何れかを用いたPUCCH送信において、SRのためのコンフィギュレーションセットによる上位レイヤパラメータによって設定されてもよい。
【0068】
さらに、PUCCHフォーマット1、3又は4について、UEは、PUCCH送信の繰り返しのために多数のスロットによって設定できる。
【0069】
さらに、3GPP TS 38.331(“NR,Radio Resource Control(RRC);Protocol specification”,version 15.4.0)のsection 6.3.2は、PUCCHリソースの識別子と、PUCCHフォーマットに関するパラメータと、SR送信のためのスロット数とを記載する。PUCCHフォーマット1がSRに設定され、スロット数が1より大きい数に設定される場合、UEは、単一のSRコンフィギュレーションに基づいてSRの繰り返しを実行する。
【0070】
いくつかの実施例では、スケジューリングデバイス210は、スケジューリングリクエスト許容数を示す許容リクエストインジケータを決定する。すなわち、スケジューリングデバイス210は、スケジューリングリクエストの最大繰り返し送信数を送受信デバイスに通知し、送受信デバイス110又は、具体的には回路120は、SR送信のために設定された機会でスケジューリングリクエストを送信するよう送受信機130に繰り返し指示する。ここで、スケジューリングリクエストは、スケジューリングデバイス210によって通知された最大繰り返し送信数に従って送信される。言い換えると、スケジューリングリクエストの送信は、送信されたSRの数がSR送信の設定された最大(許容)数に等しくなるまで、UE MACエンティティによってトリガされる。
【0071】
送信されるスケジューリングリクエストの数は、スケジューリングデバイス210から受信されるスケジューリングリクエスト許容数に従って決定されることに限定されず、送受信機の判断であってもよい。
【0072】
いくつかの実施例では、スケジューリングデバイス210は、論理チャネル毎に複数のスケジューリングリクエストコンフィギュレーションを示すスケジューリングリクエストコンフィギュレーションインジケータを決定する。すなわち、論理チャネルは、複数のSRコンフィギュレーション上にマッピングされてもよい。送受信デバイス110又は、具体的には回路120は、複数のSRコンフィギュレーションに従ってスケジューリングリクエストを送信するよう送受信機130に指示する。
【0073】
図8は、実施例によるMACレイヤ上でUE回路120によってトリガされる複数の機会でのスケジューリングリクエストの繰り返し送信の概略図である。図示されるように、本例では、SR送信は、設定された周期でUE MACレイヤによって3回トリガされる。特に、SRは、複数の機会でPUCCHを介して送信される。当該機会は、SR送信のために設定されたリソースであり、送受信デバイス110は、上述のように、ULSCHを介したアップリンク送信のためのリソースを割り当てることなく、送受信デバイス110が送信されるべきデータを有するケースにおいて、リソースリクエストを送信してもよい。
【0074】
LCH毎の単一のSRコンフィギュレーションに基づく繰り返し
いくつかの実施例では、スケジューリングデバイス210は、論理チャネル毎にN回のSRの繰り返しを設定してもよく、ここで、各論理チャネルは、図9に示すように、1つのSRコンフィギュレーションにマッピングされる。
【0075】
スケジューリングリクエスト許容数は、図10とともに以下に示されるように、NR論理チャネルコンフィギュレーション要素において設定されてもよい。
【0076】
【表3】
【0077】
特に、スケジューリングリクエストの送信の繰り返し数は、図10及び上記に示される例では、“number of SR repetitions”として示される追加的なパラメータを介し設定されてもよい。
【0078】
各論理チャネルは、SR送信の繰り返しを可能にしてもよく、ここで、SRの繰り返し数は、例えば、RRCメッセージを介してgNBなどのスケジューリングデバイスによって設定される(例えば、3GPP 38.331,version 15.4.0を参照されたい)。例えば、SR繰り返し数は、論理チャネルの優先度に基づいて異なって設定されてもよい。例えば、より高い優先度の論理チャネルは、より低い優先度の論理チャネルと比較して、より多くのSRの繰り返しを可能にするとして設定されてもよい。
【0079】
図11に示されるように、SR送信数は、高い優先度の論理チャネル(例えば、高い優先度のeMBBトラフィック)に対して設定されてもよく、一方、低い優先度のチャネル(低い優先度のeMBBトラフィック)に対しては、SRの繰り返しは設定されなくてもよい。このため、論理チャネルの優先度に応じて、SR繰り返しの値は異なってもよい。
【0080】
加えて又は代わりに、許容可能な繰り返し数は、アップリンクチャネル品質に基づいて設定することができる。アップリンクチャネル品質は、例えば、SRS(Sounding Reference Signal)を利用して評価されてもよい。SRSは、スケジューリングデバイスがチャネルサウンディングを実行することを可能にするため、例えば、周波数領域のスケジューリングをサポートするため、端末によってスケジューリングデバイスに送信される(例えば、3GPP TS 36.211,“Evolved Universal Terrestrial Radio Access(E-UTRA);Physical channels and modulation”,version 15.4.0,section 5.5.3を参照されたい)。
【0081】
図12は、実施例によるMACレイヤ上でトリガされた複数の機会でのスケジューリングリクエストの送信の概略図であり、スケジューリングリクエスト禁止タイマは、スケジューリングリクエストを複数回送信した後に始動される。
【0082】
特に、スケジューリングデバイスは、論理チャネル毎にN回の許容可能なスケジューリングリクエストの送信を設定してもよい。スケジューリングリクエストの送信は、連続する3つのフレームn~n+2の各スロットnにおけるUE MACレイヤエンティティによってトリガされる。3回目のスケジューリングリクエストの送信後、SR禁止タイマが始動され、SR禁止タイマが満了しない限り、SR送信は、SR送信のために設定された機会ではトリガされない。図12に示される例では、SRの3回の送信は、UE MACレイヤエンティティによってトリガされる。しかしながら、本開示は、3回の送信に限定されず、スケジューリングデバイスによって設定された何れかの数が、SR送信繰り返しの最大数として利用されうる。この場合、SR禁止タイマは、最後のSRの送信後に始動される。
【0083】
加えて又は代わりに、UEは、スケジューリングリクエストの送信について異なる周期を使用してもよい。図13は、実施例によるMACレイヤ上でトリガされた複数の機会でのスケジューリングリクエストの送信の概略図であり、ここでは、スケジューリングリクエスト禁止タイマは、複数回のスケジューリングリクエストの送信後に始動され、1つおきのフレームのスロットnにおける周期が適用される。
【0084】
特に、スケジューリングデバイスは、論理チャネル毎にN回の許容可能なスケジューリングリクエストの送信を設定してもよい。図13に示される例では、Nは2に等しく、スケジューリングリクエストの送信は、2つのフレームn及びn+2の各スロットnにおいてUE MACレイヤエンティティによってトリガされる。2回目のスケジューリングリクエストの送信後、SR禁止タイマが始動され、SR禁止タイマが満了しない限り、SR送信のために設定された機会においてSR送信はトリガされない。
【0085】
UEがスケジューリングデバイスからアップリンクグラントを受信するケースでは、SR禁止タイマが終了される。また、SR禁止タイマが満了し、スケジューリングデバイスからアップリンクグラントを受信していないとき、スケジューリングリクエストの送信の処理が再開されてもよい。すなわち、UE MACレイヤエンティティは、PUCCHの複数の機会でのSRの送信を再びトリガする。
【0086】
このアプローチの特に有利な点は、信頼性が向上し、アップリンクデータ送信の遅延が短縮されることである。特に、スケジューリングデバイス、例えば、gNBがUEから1回目のSR送信を受信しない場合、2回目又は3回目のSR送信が、スケジューリングデバイスによって受信されてもよく、リソースグラントは、SR禁止タイマがまだ満了していなくても、送受信デバイスに送信されてもよい。
【0087】
図14は、実施例による複数の機会でのスケジューリングリクエストの送信を示すフローチャートである。ステップS100において、UE MACレイヤエンティティは、N回のSR繰り返しを実行するよう設定される。これは、スケジューリングリクエストを送信する機会として設定されたリソースの繰り返しパターンを示すRRCコンフィギュレーションを受信することによって実行されてもよい。ステップS110では、これまで送信されたスケジューリングリクエストの数が設定されたSR送信の繰り返し数Nを下回るか否かが判定される。SR送信数が設定されたSR送信の繰り返し数Nを上回る場合(ステップS110においてNo)、ステップS140において、SR禁止タイマが始動される。SR送信の繰り返し数が設定されたSR送信の繰り返し数Nを下回ると判断された場合、UE MACレイヤエンティティは、設定されたPUCCHの機会にSRを通知するよう物理レイヤ(送受信機)に指示する。また、ステップS130において、SR送信の繰り返し数が1だけ増分され、当該手順はステップS110に戻る。特に、スケジューリンググラントを受信せずに送信されたスケジューリングリクエストの数は、例えば、NRにおける論理チャネルコンフィギュレーションのSR_COUNTERなどのカウンタを用いて、UEによって捕捉されてもよい。
【0088】
LCH毎の複数のSRコンフィギュレーションに基づく繰り返し
いくつかの実施例では、スケジューリングデバイス210は、論理チャネル毎に複数のSRコンフィギュレーションを設定してもよく、各論理チャネルは複数のSRコンフィギュレーションにマッピングされる。例えば、図16に示されるように、LCHは、コンフィギュレーション1及び2として示される2つのSRコンフィギュレーションにマッピングされる。言い換えれば、SR送信のための複数の機会が、論理チャネル毎の複数のSRコンフィギュレーションを介し提供され、SR繰り返しは様々なSRコンフィギュレーションに基づく。
【0089】
図16では、LCHは2つのSRコンフィギュレーションにマッピングされるが、本発明はこれに限定されず、LCHは2より多くのSRコンフィギュレーションにマッピングされてもよい。
【0090】
LCHが2回目のスケジューリングリクエストID“schedulingRequestID2”を介し2つのスケジューリングリクエストコンフィギュレーションにマッピングされる、NRにおける論理チャネルコンフィギュレーションを規定する論理チャネルコンフィギュレーション情報要素が、図15と共に以下に示される。
【0091】
【表4】
【0092】
スケジューリングデバイスは、複数のSRコンフィギュレーションがLCHの優先度に基づいてLCHのために設定されているか否かを判定してもよい。例えば、より高い優先度のLCHは、複数のSRコンフィギュレーションにマッピングされてもよい。このアプローチによって、高い優先度の論理チャネルのスケジューリングリクエスト手順は、信頼性及び遅延に関して改善される。
【0093】
図17は、高い優先度の論理チャネル(例えば、高優先度eMBBトラフィック)がSR送信を繰り返すため、SRコンフィギュレーション1及びSRコンフィギュレーション2にマッピングされるのに対し、低い優先度の論理チャネル(例えば、低優先度eMBBトラフィック)がSRコンフィギュレーション2のみにマッピングされる例を示す。
【0094】
図18は、実施例によるUE MACレイヤ上でトリガされる複数の機会でのスケジューリングリクエストの送信の概略図であり、スケジューリングの送信は、2つのスケジューリングリクエストコンフィギュレーションに従って複数の機会でトリガされる。
【0095】
特に、スケジューリングリクエストの1回目の送信は、スロットnにおける関連する第1の周期による第1のSRコンフィギュレーションに従ってUE MACレイヤ上でトリガされる。当該1回目のSR送信の後、第1のSR禁止タイマが始動され、第1のSR禁止タイマが満了しない限り、UE MACレイヤは、第1のSRコンフィギュレーションに従ってSR送信をトリガしない。さらに、スケジューリングリクエストの2回目の送信は、スロットn+1における関連する第2の周期による第2のSRコンフィギュレーションに従ってUE MACレイヤ上でトリガされる。当該2回目のSR送信の後、第2のSR禁止タイマが始動され、第2のSR禁止タイマが満了しない限り、UE MACレイヤエンティティは、第2のSRコンフィギュレーションに従ってSR送信をトリガしない。
【0096】
図18に例示される例では、SRの2つの送信は、2つのSR送信コンフィギュレーションに従ってUE MACレイヤ上でトリガされる。しかしながら、本開示は、2つの送信に限定されず、任意の数のSR送信コンフィギュレーションがスケジューリングデバイスによって設定されてもよい。この場合、SR禁止タイマは、それぞれのSRコンフィギュレーションに従ってSRの送信をトリガした後、全てのSR送信に対して始動されてもよい。
【0097】
UEがスケジューリングデバイスからアップリンクグラントを受信する場合、SR禁止タイマは停止/終了される。さらに、SR禁止タイマの1つが満了し、スケジューリングデバイスからアップリンクグラントが受信されないとき、対応するSRコンフィギュレーションに従ったSRの繰り返し送信が再開される。すなわち、PUCCHの各機会でのSRの送信が、UE MACレイヤ上で再び指示される。
【0098】
このアプローチの特に有利な点は、信頼性が向上し、アップリンクデータ送信の遅延が短縮されることである。特に、スケジューリングデバイス、例えば、gNBがUEから1回目のSR送信を受信しない場合、2回目のSR送信がスケジューリングデバイスによって受信されてもよく、リソースグラントが、SR禁止タイマがまだ満了していなくても、送受信デバイスに送信されてもよい。
【0099】
さらに、例えば、UEなどの送受信デバイスと、gNBなどのスケジューリングデバイスとの間の1つのコンフィギュレーションが整合しない場合、第2のSRコンフィギュレーションが依然として使用されてもよい。
【0100】
他の利点は、遅延に関するものである。例えば、kスロット毎の後のSR周期による単一のSRコンフィギュレーションの場合、繰り返しはkスロット毎に最先に実行される。複数のSRコンフィギュレーションの場合、複数のコンフィギュレーションのためのSRのリソースは独立している。コンフィギュレーション1がスロットkで設定され、コンフィギュレーション2がスロットk+1で設定される場合、1回目のSR送信はスロットkで実行され、SRの繰り返しはスロットk+1のコンフィギュレーション2で実行されてもよい。従って、遅延全体がさらに低減されうる。
【0101】
加えて又は代わりに、SR送信のための追加のSRコンフィギュレーション及び/又は追加のリソースが設定される必要はないが、例えば、高い優先度の論理チャネルは、繰り返しのために、より低い優先度の論理チャネルのSRコンフィギュレーション/リソースを利用してもよい。
【0102】
図19は、実施例による複数の機会でスケジューリングリクエストを送信するよう送受信機に指示することによって、MACレイヤ上でのスケジューリングリクエストの繰り返し送信を示すフローチャートである。UE MACレイヤエンティティは、例えば、RRCメッセージを介し2つのSRコンフィギュレーションに従ってSRの繰り返しを実行するよう設定されてもよい。ステップS200において、第1のSRコンフィギュレーションによる1回目のSR送信が、UE MACレイヤ上でトリガされる。さらに、ステップS210において、第1のSR禁止タイマが始動される。次に、ステップS220において、MACレイヤは、第2のSRコンフィギュレーションに従って2回目のSR送信をトリガする。続いて、ステップS230において、第2のSR禁止タイマが始動される。SR禁止タイマが満了しない限り、UE MACレイヤエンティティは、それぞれのSRコンフィギュレーションに従ってSR送信をトリガしない。SR禁止タイマが満了し、スケジューリングデバイスからアップリンクグラントが受信されなかったとき、UE MACレイヤは、それぞれのSRコンフィギュレーションに従ってSR送信を再度トリガする。
【0103】
遅延した禁止タイマの始動によるLCH毎の複数のSRコンフィギュレーションに基づく繰り返し
いくつかの実施例では、スケジューリングデバイス210は、論理チャネル毎にSR送信の許容(最大)数Nを設定してもよく、各論理チャネルは複数のSRコンフィギュレーションにマッピングされる。
【0104】
例えば、図20に示されるように、LCHは、コンフィギュレーション1及び2として示される2つのSRコンフィギュレーションにマッピングされる。言い換えれば、SR送信のための複数の機会が、論理チャネル毎に複数のSRコンフィギュレーションを介して提供され、SRの繰り返しは、異なるSRコンフィギュレーション及びSR送信数Nに基づく。
【0105】
本実施例によるLCHコンフィギュレーションを示す論理チャネルコンフィギュレーション要素が、図21と共に以下で示される。
【0106】
【表5】
【0107】
示されるように、論理チャネルコンフィギュレーションは、スケジューリングリクエスト許容数(“number of SR repetition”)と共に、複数のスケジューリングリクエストコンフィギュレーション(“schedulingRequestID1”,“schedulingRequestID2”)を含んでもよい。LCH毎の許容可能なSR繰り返し数及び2つ以上のSRコンフィギュレーションへのマッピングは、例えば、RRCにおけるgNBなどのスケジューリングデバイスによって設定されてもよい。
【0108】
図22は、実施例によるUE MACレイヤ上でトリガされる複数の機会でのスケジューリングリクエストの送信の概略図であり、スケジューリングリクエストの送信は、2つのスケジューリングリクエストコンフィギュレーション及び設定されたSR送信数に従って複数の機会で指示される。SR送信の総数は、RRCメッセージを介しスケジューリングデバイスによって設定されてもよい。
【0109】
特に、スケジューリングリクエストの1回目の送信は、スロットnにおける関連する第1の周期による第1のSRコンフィギュレーションに従ってUE MACレイヤ上でトリガされる。さらに、スケジューリングリクエストの2回目の送信は、スロットn+1における関連する第2の周期による第2のSRコンフィギュレーションに従ってUE MACレイヤ上でトリガされる。さらに、スケジューリングリクエストの3回目の送信は、第1のSRコンフィギュレーションに従ってUE MACレイヤ上でトリガされる。さらに、スケジューリングリクエストの4回目の送信は、第2のSRコンフィギュレーションに対してUE MACレイヤエンティティでトリガされる。
【0110】
図22に示される例では、SR送信(繰り返し)の許容数は4であり、LCH毎のSRコンフィギュレーションの数は2である。
【0111】
2つのSRコンフィギュレーションによる複数の機会に送信されるSR数の後、第1及び第2のSR禁止タイマが始動(スタート)される。すなわち、双方のSR禁止タイマは、4つ全てのSR送信が送信された後に一緒にスタートされる。SR禁止タイマが満了していない限り、それぞれのSR送信コンフィギュレーションによるSR送信は、UE MACレイヤ上で指示されない。
【0112】
あるいは、SR禁止タイマは、論理チャネル毎に実行されてもよい。全てのSRの繰り返しが送信されると、UEは、SR禁止タイマを始動してもよい。
【0113】
図14に示す例では、スケジューリングデバイスによって設定されるSR送信数Nは4である。しかしながら、本実施例は、4に限定されず、何れかのSR送信数がスケジューリングデバイスによって設定されてもよい。
【0114】
本開示は、ソフトウエア、ハードウエア、ハードウエアと連携するソフトウエアによって実現することができる。上述した各実施例の記載に用いられる各機能ブロックは、集積回路などのLSI(Large Scale Integration)によって部分的又は全体的に実現することができ、各実施例において説明した各処理は、同一のLSI又はLSIの組合せによって部分的又は全体的に制御されてもよい。LSIは、チップとして個別に形成されてもよいし、あるいは、1つのチップが、機能ブロックの一部又は全てを含むように形成されてもよい。LSIは、それに結合されたデータ入出力を含んでもよい。ここで、LSIとは、集積度の相違に依存して、IC、システムLSI、スーパLSI、ウルトラLSIとして参照されてもよい。しかしながら、集積回路を実現する技術はLSIに限定されず、専用回路、汎用プロセッサ又は専用プロセッサを用いて実現されてもよい。さらに、LSIの製造後にプログラム可能なFPGA(Field Programmable Gate Array)、又はLSI内部に配置された回路セルの接続及び設定が再構成可能なリコンフィギュラブルプロセッサが利用されてもよい。本開示は、デジタル処理又はアナログ処理として実現することができる。半導体技術や他の派生技術の進歩の結果、将来の集積回路技術がLSIに取って代わる場合、将来の集積回路技術を用いて機能ブロックを集積化することができる。バイオテクノロジーも適用できる。
【0115】
本開示は、通信装置として参照される、通信機能を有する任意の種別の装置、デバイス又はシステムによって実現することができる。
【0116】
そのような通信装置のいくつかの非限定的な具体例は、電話機(例えば、セルラ(セル)電話、スマートフォン)、タブレット、パーソナルコンピュータ(PC)(例えば、ラップトップ、デスクトップ、ネットブック)、カメラ(例えば、デジタルスチル/ビデオカメラ)、デジタルプレーヤ(デジタルオーディオ/ビデオプレーヤ)、ウェアラブルデバイス(例えば、ウェアラブルカメラ、スマートウォッチ、トラッキングデバイス)、ゲームコンソール、デジタルブックリーダ、遠隔ヘルス/遠隔医療(リモートヘルス及び医療)デバイス及び通信機能を提供する車両(例えば、自動車、飛行機、船舶)並びにそれらの各種組み合わせを含む。
【0117】
通信装置は、携帯型又は可動型であることに限定されず、スマートホームデバイス(例えば、家電、ライティング、スマートメータ、コントロールパネル)、自動販売機及び「Internet of Things(IoT)」のネットワークにおける他の任意の「物」など、非携帯型又は固定型である任意の種別の装置、デバイス又はシステムを含んでもよい。
【0118】
通信は、例えば、セルラシステム、無線LANシステム、衛星システムなどとそれらの各種組合せを介しデータを交換することを含んでもよい。
【0119】
通信装置は、本開示に記載された通信の機能を実行する通信デバイスに結合された制御装置又はセンサなどのデバイスを備えてもよい。例えば、通信装置は、通信装置の通信機能を実行する通信デバイスによって使用される制御信号又はデータ信号を生成する制御装置又はセンサを備えてもよい。
【0120】
通信装置はまた、基地局、アクセスポイントなどのインフラストラクチャ設備と、上記の非限定的な具体例におけるものなどの装置と通信又は制御する他の任意の装置、デバイス又はシステムとを含んでもよい。
【0121】
上述されるように、非地上ネットワーク(又は同様の無線通信システム)における有意に高いオーバヘッドを生じさせることなく、スケジューリングリクエストのロバストな送信を可能にするデバイス及び方法が提供される。
【0122】
動作中に、PUCCH(Physical Uplink Control Channel)の複数の機会でスケジューリングリクエストを送信するよう送受信機に指示することによって、MAC(Medium Access Control)レイヤ上でスケジューリングリクエストを繰り返す回路と、動作中に、PUCCH上でスケジューリングリクエストを送信する送受信機と、を有する送受信デバイスが提供される。
【0123】
いくつかの実施例では、回路は、動作中に、スケジューリングリクエスト禁止タイマを始動し、スケジューリングリクエスト禁止タイマが動作中である場合には、スケジューリングリクエストを送信するよう送受信機に指示しない。
【0124】
いくつかの実施例では、送受信機は、動作中に、スケジューリングリクエストの許容数を示す許容リクエストインジケータを受信し、回路は、動作中に、スケジューリングリクエストが許容リクエストインジケータによって通知されたスケジューリングリクエスト許容数に等しい数の機会で送信された後、スケジューリングリクエスト禁止タイマを始動する。
【0125】
いくつかの実施例では、許容リクエストインジケータは、論理チャネル毎のスケジューリングリクエスト許容数を示す。
【0126】
いくつかの実施例では、送受信機は、動作中に、PDCCH(Physical Downlink Control Channel)を介し送信のため送受信デバイスに割り当てられたリソースを示すリソース割当てインジケータを受信し、回路は、動作中に、リソース割当てインジケータに従って、割り当てられたリソースを決定し、スケジューリングリクエスト禁止タイマを停止する。
【0127】
いくつかの実施例では、送受信機は、動作中に、複数のスケジューリングリクエストコンフィギュレーションを示すスケジューリングリクエストコンフィギュレーションインジケータを受信し、回路は、動作中に、複数のスケジューリングリクエストコンフィギュレーションによる複数の機会でスケジューリングリクエストを送信するよう送受信機に指示する。
【0128】
いくつかの実施例では、回路は、動作中に、各スケジューリングリクエスト禁止タイマが複数のスケジューリングリクエストコンフィギュレーションの1つと関連付けされる、複数のスケジューリングリクエスト禁止タイマを始動し、複数のスケジューリングリクエストコンフィギュレーションの1つに関連付けされるスケジューリングリクエスト禁止タイマが動作中である場合、前記複数のスケジューリングリクエストコンフィギュレーションの1つによる機会でスケジューリングリクエストを送信するよう送受信機に指示しない。
【0129】
いくつかの実施例では、回路は、動作中に、各スケジューリングリクエスト禁止タイマを、スケジューリングリクエスト禁止タイマに関連付けされる複数のスケジューリングリクエストの1つによるスケジューリングリクエストが送信されると、始動する。
【0130】
いくつかの実施例では、送受信機は、動作中に、論理チャネル毎のスケジューリングリクエスト許容数を示す許容リクエストインジケータを受信し、回路は、動作中に、各スケジューリングリクエスト禁止タイマを、スケジューリングリクエストが許容リクエストインジケータによって示されるスケジューリングリクエスト許容数による数の機会で送信された後、始動する。
【0131】
いくつかの実施例では、送受信機は、動作中に、PDCCH(Physical Downlink Control Channel)を介し送信のため送受信デバイスに割り当てられるリソースを示すリソース割当てインジケータを受信し、回路は、動作中に、リソース割当てインジケータに従って、割り当てられたリソースを決定し、複数のスケジューリングリクエスト禁止タイマを停止する。
【0132】
更に、動作中に、スケジューリングリクエスト許容数を示す許容リクエストインジケータを決定する回路と、動作中に、許容リクエストインジケータを送信する送受信機と、を有するスケジューリングデバイスが提供される。
【0133】
いくつかの実施例では、スケジューリングリクエスト許容数が、論理チャネル毎に決定される。
【0134】
いくつかの実施例では、論理チャネル毎のスケジューリングリクエスト許容数が、論理チャネルの優先度に従って決定されてもよい。
【0135】
例えば、高い優先度の論理チャネルのスケジューリングリクエスト許容数は、より低い優先度の論理チャネルのスケジューリングリクエスト許容数より大きく決定されてもよい。すなわち、論理チャネル毎のスケジューリングリクエスト許容数は、論理チャネルの優先度に従って決定されてもよい。
【0136】
いくつかの実施例では、許容リクエストインジケータは、論理チャネル毎のスケジューリングリクエスト許容数を示す。
【0137】
いくつかの実施例では、送受信機は、動作中に、PUCCH(Physical Uplink Control Channel)の機会でスケジューリングリクエストを受信し、送信のため送受信デバイスに割り当てられたリソースを示すリソース割当てインジケータをPDCCH(Physical Downlink Control Channel)を介し送信する。
【0138】
更に、動作中に、複数のスケジューリングリクエストコンフィギュレーションを示すスケジューリングリクエストコンフィギュレーションインジケータを決定する回路と、動作中に、スケジューリングリクエストコンフィギュレーションインジケータを送信する送受信機と、を有するスケジューリングデバイスが提供される。
【0139】
いくつかの実施例では、スケジューリングリクエストコンフィギュレーションの数は、論理チャネル毎に決定される。
【0140】
いくつかの実施例では、スケジューリングリクエストコンフィギュレーションの総数は、論理チャネルの優先度に従って決定されてもよい。
【0141】
例えば、高い優先度の論理チャネルのスケジューリングリクエストコンフィギュレーション数は、より低い優先度の論理チャネルのスケジューリングリクエストコンフィギュレーション数より大きく決定されてもよい。すなわち、スケジューリングリクエストコンフィギュレーション数は、論理チャネルの優先度に従って決定されてもよい。
【0142】
いくつかの実施例では、送受信機は、動作中に、PUCCH(Physical Uplink Control Channel)の機会でスケジューリングリクエストを受信し、送信のため送受信デバイスに割り当てられたリソースを示すリソース割当てインジケータをPDCCH(Physical Downlink Control Channel)を介し送信する。
【0143】
更に、PUCCH(Physical Uplink Control Channel)の複数の機会でスケジューリングリクエストの送信を指示することによって、スケジューリングリクエストをMAC(Medium Access Control)レイヤ上で繰り返すステップと、PUCCH上でスケジューリングリクエストを送信するステップと、を有する方法が提供される。
【0144】
いくつかの実施例では、当該方法は、スケジューリングリクエスト禁止タイマを始動するステップと、スケジューリングリクエスト禁止タイマが動作中である場合、スケジューリングリクエストの送信を指示しないステップとを有する。
【0145】
いくつかの実施例では、当該方法は、スケジューリングリクエスト許容数を示す許容リクエストインジケータを受信するステップと、スケジューリングリクエストが許容リクエストインジケータによって示されるスケジューリングリクエスト許容数に等しい数の機会で送信された後、スケジューリングリクエスト禁止タイマを始動するステップとを有する。
【0146】
いくつかの実施例では、許容リクエストインジケータは、論理チャネル毎のスケジューリングリクエスト許容数を示す。
【0147】
いくつかの実施例では、当該方法は、送信のため送受信デバイスに割り当てられたリソースを示すリソース割当てインジケータをPDCCH(Physical Downlink Control Channel)を介し受信するステップと、リソース割当てインジケータに従って、割り当てられたリソースを決定するステップと、スケジューリングリクエスト禁止タイマを停止するステップとを有する。
【0148】
いくつかの実施例では、当該方法は、複数のスケジューリングリクエストコンフィギュレーションを示すスケジューリングリクエストコンフィギュレーションインジケータを受信するステップと、複数のスケジューリングリクエストコンフィギュレーションによる複数の機会でスケジューリングリクエストの送信を指示するステップとを有する。
【0149】
いくつかの実施例では、当該方法は、各スケジューリングリクエスト禁止タイマが複数のスケジューリングリクエストコンフィギュレーションの1つに関連付けされる、複数のスケジューリングリクエスト禁止タイマを始動するステップと、複数のスケジューリングリクエストコンフィギュレーションの1つに関連付けされるスケジューリングリクエスト禁止タイマが動作中である場合、複数のスケジューリングリクエストコンフィギュレーションの1つによる機会でスケジューリングリクエストの送信を指示しないステップとを有する。
【0150】
いくつかの実施例では、当該方法は、各スケジューリングリクエスト禁止タイマを、当該スケジューリングリクエスト禁止タイマに関連付けされる複数のスケジューリングリクエストコンフィギュレーションの1つによるスケジューリングリクエストが送信されると、始動するステップを有する。
【0151】
いくつかの実施例では、当該方法は、論理チャネル毎のスケジューリングリクエスト許容数を示す許容リクエストインジケータを受信するステップと、各スケジューリングリクエスト禁止タイマを、スケジューリングリクエストが許容リクエストインジケータによって示されるスケジューリングリクエスト許容数による数の機会で送信された後、始動するステップとを有する。
【0152】
いくつかの実施例では、当該方法は、送信のため送受信デバイスに割り当てられたリソースを示すリソース割当てインジケータをPDCCH(Physical Downlink Control Channel)を介し受信するステップと、リソース割当てインジケータに従って、割り当てられたリソースを決定するステップと、複数のスケジューリングリクエスト禁止タイマを停止するステップとを有する。
【0153】
更に、スケジューリングリクエスト許容数を示す許容リクエストインジケータを決定するステップと、許容リクエストインジケータを送信するステップと、を有する方法が提供される。
【0154】
いくつかの実施例では、スケジューリングリクエスト許容数は、論理チャネル毎に決定される。
【0155】
いくつかの実施例では、論理チャネル毎のスケジューリングリクエスト許容数は、論理チャネルの優先度に従って決定されてもよい。
【0156】
例えば、高い優先度の論理チャネルのスケジューリングリクエスト許容数は、より低い優先度の論理チャネルのスケジューリングリクエスト許容数より大きく決定されてもよい。すなわち、論理チャネル毎のスケジューリングリクエスト許容数は、論理チャネルの優先度に従って決定されてもよい。
【0157】
いくつかの実施例では、許容リクエストインジケータは、論理チャネル毎のスケジューリングリクエスト許容数を示す。
【0158】
いくつかの実施例では、当該方法は、PUCCH(Physical Uplink Control Channel)の機会でスケジューリングリクエストを受信するステップと、送信のため送受信デバイスに割り当てられたリソースを示すリソース割当てインジケータをPDCCH(Physical Downlink Control Channel)を介し送信するステップとを有する。
【0159】
更に、複数のスケジューリングリクエストコンフィギュレーションを示すスケジューリングリクエストコンフィギュレーションインジケータを決定するステップと、スケジューリングリクエストコンフィギュレーションインジケータを送信するステップと、を有する方法が提供される。
【0160】
いくつかの実施例では、スケジューリングリクエストコンフィギュレーション数は、論理チャネル毎に決定される。
【0161】
いくつかの実施例では、スケジューリングリクエストコンフィギュレーションの総数は、論理チャネルの優先度に従って決定されてもよい。
【0162】
例えば、高い優先度の論理チャネルのスケジューリングリクエストコンフィギュレーション数は、より低い優先度の論理チャネルのスケジューリングリクエストコンフィギュレーション数より大きく決定されてもよい。すなわち、スケジューリングリクエストコンフィギュレーション数は、論理チャネルの優先度に従って決定されてもよい。
【0163】
いくつかの実施例では、当該方法は、PUCCH(Physical Uplink Control Channel)の機会でスケジューリングリクエストを受信するステップと、送信のため送受信デバイスに割り当てられたリソースを示すリソース割当てインジケータをPDCCH(Physical Downlink Control Channel)を介し送信するステップとを有する。
図1
図2
図3
図4
図5
図6
図7
図8
図9
図10
図11
図12
図13
図14
図15
図16
図17
図18
図19
図20
図21
図22