JP2022542341A - V2x通信装置のためのdciの通信装置及び通信方法 - Google Patents

V2x通信装置のためのdciの通信装置及び通信方法 Download PDF

Info

Publication number
JP2022542341A
JP2022542341A JP2021576760A JP2021576760A JP2022542341A JP 2022542341 A JP2022542341 A JP 2022542341A JP 2021576760 A JP2021576760 A JP 2021576760A JP 2021576760 A JP2021576760 A JP 2021576760A JP 2022542341 A JP2022542341 A JP 2022542341A
Authority
JP
Japan
Prior art keywords
dci
communication device
message
receive
base station
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
JP2021576760A
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 JP2022542341A publication Critical patent/JP2022542341A/ja
Pending legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W72/00Local resource management
    • H04W72/12Wireless traffic scheduling
    • H04W72/121Wireless traffic scheduling for groups of terminals or users
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/12Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/60Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W72/00Local resource management
    • H04W72/02Selection of wireless resources by user or terminal
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W72/00Local resource management
    • H04W72/12Wireless traffic scheduling
    • H04W72/1263Mapping of traffic onto schedule, e.g. scheduled allocation or multiplexing of flows
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W72/00Local resource management
    • H04W72/20Control channels or signalling for resource management
    • H04W72/23Control channels or signalling for resource management in the downlink direction of a wireless link, i.e. towards a terminal
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W4/00Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30Services specially adapted for particular environments, situations or purposes
    • H04W4/40Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Health & Medical Sciences (AREA)
  • Computing Systems (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

本開示は、V2X通信装置のためのDCIの通信装置及び通信方法を提供する。通信装置は、動作中に通信装置が受信モードにあるか否かを示すメッセージを生成する回路と、動作中にメッセージを通信装置に送信する送信機とを有する基地局を含む。

Description

以下の開示は、NR(New Radio)通信のための通信装置及び通信方法に関し、より詳細には、V2X通信装置のためのDCI(Downlink Control Information)の通信装置及び通信方法に関する。
V2X通信は、車両が公道及び他の道路の利用者と相互作用することを可能にし、従って、自律車両を現実のものにする上で重要な要素と考えられている。
このプロセスを加速するため、5G NRベースのV2X通信(互換的にNR V2X通信と呼ばれる)が、高度なV2Xサービスのための技術的解決策を特定するため3GPP(3rd Generation Partnership Project)によって議論され、これを介して車両(すなわち、V2Xアプリケーションをサポートする通信装置又はユーザ装置(UE)と互換的に呼ばれる)は、サイドリンク(SL)を介して他の近くの車両、インフラストラクチャノード及び/又は歩行者と自らの状態情報をやりとりすることができる。状態情報は、位置、速度、方位等の情報を含む。
そのようなV2X通信では、少なくとも2つのSLリソース割当モードが3GPPによって議論されている。リソース割当モード1では、SL送信のために端末によって使用されるSLリソースは、基地局(BS)によってスケジューリングされる。リソース割当モード2では、UEは、BS/ネットワークによって設定されたSLリソース又は事前に設定されたSLリソース内でSL送信リソースを決定し、すなわち、BSはスケジューリングしない。リソース割当てに関する3GPPスタディはまた、リソースが異なる送信ブロック(TB)の複数の送信に対して選択されるセミパーシステント方式と、リソースが各TB送信に対して選択されるダイナミック方式とのコンテクストにおいて、モード2(a)のためのセンシング及びリソース選択手順を検討する。
3GPP TSG RAN Meeting #83のドキュメントRP-190766において議論されるように、NRサイドリンクによる5G V2Xに関するWID(Work Item Description)では、以下の項目が検討される。
-ネットワーク内カバレッジ、ネットワーク外カバレッジ及び部分的なネットワークカバレッジを考慮して、V2Xサービスに対するサイドリンクユニキャスト、サイドリンクグループキャスト及びサイドリンクブロードキャストをサポートするのに必要なNRサイドリンク解決策の指定
-モード1:UuがUEと基地局との間の論理インタフェースを参照する検討結果によるNR UuとLTE UuとによってスケジューリングされるNRサイドリンク
-モード2:検討結果によるNR UuとLTE Uuとによる設定及びサイドリンク事前設定に基づくセンシング及びリソース選択手順
-UEのモード1及びモード2の同時設定のサポート
・当該設定における送信機UEの動作は、モード1のみ及びモード2のみの設計後に議論されるべきである。
・受信機UEは、送信機UEによって利用されるリソース割当モードを知ることなく送信を受信できる。
しかしながら、V2X通信装置のためのDCIの通信装置及び方法に関する議論はされていない。
従って、V2X通信装置のためのDCIの実現可能な技術的解決策を提供する通信装置及び方法が必要とされる。さらに、他の望ましい特徴及び特性が、添付の図面及び本開示の背景と共に、以下の詳細な説明及び添付の請求項から明らかになるであろう。
非限定的及び例示的な実施例は、V2X通信装置のためのDCIの通信装置及び方法を提供することを容易にする。
本開示の第1の実施例によると、通信装置であって、動作中に前記通信装置が受信モードにあるか否かを示すメッセージを受信する受信機と、動作中に前記通信装置が前記受信モードにないとき、信号を送信する送信機と、を有する通信装置が提供される。
本開示の第2の実施例によると、基地局であって、動作中に通信装置が受信モードにあるか否かを示すメッセージを生成する回路と、動作中に前記メッセージを前記通信装置に送信する送信機と、を有する基地局が提供される。
本開示の第3の実施例によると、通信方法であって、通信装置が受信モードであるか否かを示すメッセージを生成することと、前記メッセージを前記通信装置に送信することと、を有する通信方法が提供される。
全体的又は特定の実施例は、システム、方法、集積回路、コンピュータプログラム、記憶媒体又はそれらの何れか選択的な組み合わせとして実現されてもよいことが留意されるべきである。
開示された実施例の更なる利益及び利点は、明細書及び図面から明らかになるであろう。利益及び/又は利点は、明細書及び図面の様々な実施例及び特徴によって個別に取得されてもよく、これらは、そのような利益及び/又は利点の1つ以上を得るために全てが提供される必要はない。
本開示の実施例は、単なる例示として図面と共に以下に記載される説明から当業者により良好に理解され、容易に明らかになるであろう。
3GPP NRシステムの例示的なアーキテクチャを示す。 NG-RANと5GCとの間の機能分割を示す概略図である。 RRC接続設定/再設定手順のためのシーケンス図である。 eMBB(enhanced Mobile Broadband)、mMTC(massive Machine Type Communications)及びURLLC(Ultra Reliable and Low Latency Communications)の利用シナリオを示す概略図である。 非ローミングシナリオのための例示的な5Gシステムアーキテクチャを示すブロック図である。 gNodeB(gNB)又は基地局が、典型的にV2X通信においてDCI(すなわち、DCI_X)をどのように利用するかを示す概略図を示す。 各種実施例によるgNB又は基地局がV2X通信においてDCI_Yをどのように利用するかを示す概略図を示す。 各種実施例によるgNB又は基地局がV2X通信においてDCI_Yをどのように利用するかを示す概略図を示す。 各種実施例によるgNB又は基地局がV2X通信においてグループキャストのためのDCI_Yをどのように利用するかを示す概略図を示す。 各種実施例によるgNB又は基地局がV2X通信においてDCI_YとしてDCI_Xをどのように利用するかを示す概略図を示す。 各種実施例によるgNB又は基地局がV2X通信においてブロードキャストのためのDCI_Yをどのように利用するかを示す概略図を示す。 各種実施例によるgNB又は基地局がV2X通信においてDCI_Yをどのように利用するかの他の具体例を示す概略図を示す。 各種実施例による典型的なDCI_Xメッセージのフォーマットを示す。 各種実施例によるDCI_Yメッセージのフォーマットを示す。 各種実施例による受信ウィンドウがDCI_Yメッセージにおいてどのように通知されるかの具体例を示す。 各種実施例による受信ウィンドウがDCI_Yメッセージにおいてどのように通知されるかの具体例を示す。 各種実施例による受信ウィンドウがDCI_Yメッセージにおいてどのように通知されるかの具体例を示す。 各種実施例による受信ウィンドウがDCI_Yメッセージにおいてどのように通知されるかの具体例を示す。 各種実施例による受信ウィンドウがDCI_Yメッセージにおいてどのように通知されるかの具体例を示す。 各種実施例による通信方法を示すフロー図を示す。 各種実施例による通信装置の概略的な具体例を示す。通信装置は、本開示の各種実施例によるUE又はgNB/基地局として実現されてもよく、V2X通信のためのDCIに対して設定されてもよい。
当業者は、図における要素が簡単化及び明確化のため示され、必ずしも縮尺通りに示されているとは限らないことを理解するであろう。例えば、図、ブロック図又はフローチャートにおける要素の一部のサイズは、本実施例の理解を向上させるのに役立つように他の要素に関して誇張されうる。
本開示のいくつかの実施例が、図面を参照して例示のみのために説明される。図面における同様の参照番号及び文字は、同様の要素又は等価なものを指す。
[5G NRシステムアーキテクチャ及びプロトコルスタック]
3GPPは、100GHzまで範囲の周波数で動作するNR(New Radio Access Technology)の開発を含む、単に5Gと呼ばれる第5世代セルラ技術の次のリリースに取り組んできた。2017年末に第1版の5G規格が完成し、5G NR規格に準拠したスマートフォンの試行及び実用化の進展が可能になる。
特に、全体的なシステムアーキテクチャは、gNBを含むNG-RAN(Next Generation-Radio Access Network)を想定し、UEに対するNG無線アクセスユーザプレーン(SDAP/PDCP/RLC/MAC/PHY)及び制御プレーン(RRC)プロトコルターミネーションを提供する。gNBは、Xnインタフェースによって互いに相互接続される。gNBはまた、NG(Next Generation)インタフェースによってNGC(Next Generation Core)に、より具体的には、NG-CインタフェースによってAMF(Access and Mobility Management Function)(例えば、AMFを実行する特定のコアエンティティ)に、また、NG-UインタフェースによってUPF(User Plane Function)(例えば、UPFを実行する特定のコアエンティティ)に接続される。NG-RANアーキテクチャは、図1に示される(例えば、3GPP TS 38.300 v15.6.0,section 4を参照されたい)。
NRのためのユーザプレーンプロトコルスタック(例えば、3GPP TS 38.300,section 4.4.1を参照されたい)は、PDCP(Packet Data Convergence Protocol,TS 38.300のsection 6.4を参照されたい)、RLC(Radio Link Control,TS 38.300のsection 6.3を参照されたい)、及びMAC(Medium Access Control,TS 38.300のsection 6.2を参照されたい)サブレイヤを含み、これらはネットワーク側のgNBにおいて終端される。さらに、新しいAS(Access Stratum)サブレイヤ(SDAP,Service Data Adaptation Protocol)が、PDCPの上位に導入される(例えば、3GPP TS 38.300のsub-clause 6.5を参照されたい)。制御プレーンプロトコルスタックがまた、NRについて定義される(例えば、TS 38.300,section 4.4.2を参照されたい)。レイヤ2機能の概略は、TS 38.300のsub-clause 6に与えられる。PDCP、RLC及びMACサブレイヤの機能は、TS 38.300のsection 6.4、6.3及び6.2においてそれぞれリストされている。RRCレイヤの機能は、TS 38.300のsub-clause 7にリストされている。
例えば、MACレイヤは、論理チャネル多重化と、異なるニューメロロジのハンドリングを含むスケジューリング及びスケジューリング関連機能とを処理する。
物理レイヤ(PHY)は、例えば、符号化、PHY HARQ処理、変調、マルチアンテナ処理、及び信号の適切な物理時間周波数リソースへのマッピングを担当する。また、それは、トランスポートチャネルの物理チャネルへのマッピングを処理する。物理レイヤは、トランスポートチャネルの形式でMACレイヤにサービスを提供する。物理チャネルは、特定のトランスポートチャネルの送信に使用される時間周波数リソースのセットに対応し、各トランスポートチャネルは、対応する物理チャネルにマッピングされる。例えば、物理チャネルは、アップリンク用のPRACH(Physical Random Access Channel)、PUSCH(Physical Uplink Shared Channel)及びPUCCH(Physical Uplink Control Channel)と、ダウンリンク用のPDSCH(Physical Downlink Shared Channel)、PDCCH(Physical Downlink Control Channel)及びPBCH(Physical Broadcast Channel)とである。
NRのためのユースケース/展開シナリオは、データレート、遅延及びカバレッジに関して多様な要求を有するeMBB(enhanced Mobile Broadband)、URLLC(Ultra-Reliable Low-Latency Communications)、mMTC(massive Machine Type Communication)を含みうる。例えば、eMBBは、IMT-Advancedによって提供されるものの3倍のオーダのピークデータレート(ダウンリンクでは20Gbps、アップリンクでは10Gbps)及びユーザ経験データレートをサポートすることが期待される。他方、URLLCの場合では、よりタイトな要求が、超低遅延(ユーザプレーン遅延に対してそれぞれUL及びDLに対して0.5ms)と高信頼性(1ms以内に1~10~5)とに対して課される。最後に、mMTCは、好ましくは、高接続密度(都市環境では、1,000,000デバイス/km)、厳しい環境での大きなカバレッジ、及び低コストデバイスのための極めて長寿命のバッテリ(15年間)を必要としてもよい。
従って、1つのユースケースに適したOFDMニューメロロジ(例えば、サブキャリア間隔、OFDMシンボル持続時間、サイクリックプリフィックス(CP)持続時間、スケジューリングインターバルあたりのシンボル数など)は、別のユースケースでは良好には機能しない場合がある。例えば、低遅延サービスは、好ましくは、mMTCサービスよりも短いシンボル持続時間(及びより大きなサブキャリア間隔)及び/又はより少数のスケジューリングインターバル(別名、TTI)当たりのシンボルを必要としうる。さらに、大きなチャネル遅延スプレッドを有する展開シナリオは、好ましくは、短い遅延スプレッドを有するシナリオよりも長いCP持続時間を必要としうる。サブキャリア間隔は、同様のCPオーバヘッドを維持するように、それに応じて最適化されるべきである。NRは、サブキャリア間隔の複数の値をサポートしてもよい。これに対応して、現在、15kHz,30kHz,60kHz・・・のサブキャリア間隔が検討されている。シンボル持続時間Tuとサブキャリア間隔Δfとは、Δf=1/Tuの式を通して直接的に関連している。LTEシステムと同様に、“リソースエレメント”という用語は、1つのOFDM/SC-FDMAシンボルの長さに対して1つのサブキャリアで構成される最小のリソース単位を示すのに利用可能である。
各ニューメロロジ及びキャリアの新たな無線システム5G-NRにおいて、サブキャリアとOFDMシンボルとのリソースグリッドが、アップリンクとダウンリンクとのそれぞれに対して規定される。リソースグリッドにおける各要素は、リソースエレメントと呼ばれ、周波数領域における周波数インデックスと時間領域におけるシンボル位置とに基づいて特定される(3GPP TS 38.211 v15.6.0を参照されたい)。
[NG-RANと5GCとの間の5G NR機能分割]
図2は、NG-RANと5GCとの間の機能分割を示す。NG-RAN論理ノードは、gNB又はng-eNBである。5GCは、論理ノードAMF,UPF及びSMFを有する。
特に、gNB及びng-eNBは、以下の主要な機能を提供する。
-無線ベアラ制御、無線アドミッション制御、接続モビリティ制御、アップリンク及びダウンリンク双方におけるUEへの動的なリソース割当て(スケジューリング)など、無線リソース管理の機能
-データのIPヘッダ圧縮、暗号化及び整合性プロテクション
-UEによって提供される情報からAMFへのルーティングが決定できないときのUEアタッチメントでのAMFの選択
-UPFへのユーザプレーンデータのルーティング
-AMFへの制御プレーン情報のルーティング
-接続セットアップ及びリリース
-ページングメッセージのスケジューリング及び送信
-(AMF又はOAMから発信される)システムブロードキャスト情報のスケジューリング及び送信
-モビリティ及びスケジューリングのためのメジャメント及びメジャメントレポート設定
-アップリンクにおけるトランスポートレベルパケットマーキング
-セッション管理
-ネットワークスライシングのサポート
-QoSフロー管理及びデータ無線ベアラへのマッピング
-RRC_INACTIVE状態のUEのサポート
-NASメッセージの配信機能
-無線アクセスネットワークシェアリング
-デュアルコネクティビティ
-NRとE-UTRAとの間の緊密な連携
AMF(Access and Mobility Management Function)は、以下の主要な機能を提供する。
-NAS(Non-Access Stratum)シグナリングの終端
-NASシグナリングのセキュリティ
-AS(Access Stratum)セキュリティ制御
-3GPPアクセスネットワーク間のモビリティのためのコアネットワーク(CN:Core Network)ノード間シグナリング
-アイドルモードUEの到達可能性(ページング再送の制御及び実行を含む)
-レジストレーションエリア管理
-システム内モビリティ及びシステム間モビリティのサポート
-アクセス認証
-ローミング権のチェックを含むアクセス認証
-モビリティ管理制御(サブスクリプション及びポリシー)
-ネットワークスライシングのサポート
-SMF(Session Management Function)選択
さらに、UPF(User Plane Function)は、以下の主要な機能を提供する。
-RAT内/RAT間モビリティのためのアンカーポイント(適用可能時)
-データネットワークとの相互接続の外部PDUセッションポイント
-パケットルーティング及び転送
-パケット検査及びポリシールール施行のユーザプレーン部分
-トラフィック使用報告
-データネットワークへのトラフィックフローのルーティングをサポートするためのアップリンク分類器
-マルチホームPDUセッションをサポートするためのブランチングポイント
-パケットフィルタリング、ゲーティング、UL/DLレート強制などのユーザプレーンのQoSハンドリング
-アップリンクトラフィック検証(SDFからQoSフローへのマッピング)
-ダウンリンクパケットバッファリング及びダウンリンクデータ通知トリガリング
最後に、SMF(Session Management Function)は、以下の主要な機能を提供する。
-セッション管理
-UE IPアドレス割当て及び管理
-UP機能の選択及び制御
-トラフィックを正しい宛先にルーティングするためのUPF(User Plane Function)におけるトラフィックステアリングの設定
-ポリシー施行及びQoSの制御部分
-ダウンリンクデータ通知
[RRC接続設定及び再設定手順]
図3は、NASパートのためのRRC_IDLEからRRC_CONNECTEDへのUEの移行のコンテクストにおけるUE、gNB及びAMF(5GCエンティティ)の間のいくつかの相互作用を示す(TS 38.300 v15.6.0を参照されたい)。
RRCは、UE及びgNBの設定に使用される上位レイヤシグナリング(プロトコル)である。特に、当該移行は、AMFがUEコンテクストデータ(例えば、PDUセッションコンテクスト、セキュリティキー、UE無線能力、UEセキュリティ能力などを含む)を準備し、それをINITIAL CONTEXT SETUP REQUESTによってgNBに送信することに関する。次に、gNBは、UEとのASセキュリティをアクティブ化し、これは、gNBがSecurityModeCommandメッセージをUEに送信し、UEがSecurityModeCompleteメッセージでgNBに応答することによって実行される。その後、gNBは、RRCReconfigurationメッセージをUEに送信し、これに応答してUEからRRCReconfigurationCompleteをgNBが受信することによって、シグナリング無線ベアラ2(SRB2)及びデータ無線ベアラ(DRB)を設定するために再設定を実行する。シグナリングのみの接続について、SRB2及びDRBが設定されていないため、RRCReconfigurationに関連するステップは、省略される。最後に、gNBは、設定手順が完了したことをINITIAL CONTEXT SETUP RESPONSEによってAMFに通知する。
従って、本開示では、第5世代コア(5GC)のエンティティ(例えば、AMF、SMFなど)が提供され、このエンティティは、動作中にgNodeBとのNG(Next Generation)接続を確立する制御回路と、動作中にgNodeBとユーザ装置(UE)との間のシグナリング無線ベアラ設定を生じさせるイニシャルコンテクストセットアップメッセージをNG接続を介しgNodeBに送信する送信機とを有する。特に、gNodeBは、シグナリング無線ベアラを介しUEにリソース割当設定情報要素を含むRRC(Radio Resource Control)シグナリングを送信する。その後、UEは、リソース割当設定に基づいてアップリンク送信又はダウンリンク受信を実行する。
[2020年以降のIMTの利用シナリオ]
図4は、5G NRのユースケースのいくつかを示す。3GPP NR(3rd Generation Partnership Project New Radio)では、IMT-2020によって広範なサービス及びアプリケーションをサポートすることが想定される3つのユースケースが検討されている。eMBBのフェーズ1の仕様が確定された。eMBBのサポートをさらに拡張することに加えて、現在及び将来の作業は、URLLC及びmMTCの標準化を伴う。図4は、2020年以降のIMTの想定される理想シナリオのいくつかの具体例を示す(例えば、ITU-R M.2083のFIG.2を参照されたい)。
URLLCのユースケースは、スループット、遅延、可用性などの能力に対する厳しい要求を有し、産業製造や生産プロセスの無線制御、リモート医療手術、スマートグリッドにおける配電自動化、輸送の安全性など、将来の垂直的なアプリケーションを実現する手段の1つとして想定されている。URLLCの超高信頼性は、TR 38.913によって設定される要求を満たすための技術を特定することによってサポートされる。Release 15におけるNR URLLCについて、キーとなる要求は、UL(アップリンク)について0.5msとDL(ダウンリンク)について0.5msとのターゲットのユーザプレーンの遅延を含む。パケットの1回の送信に対する全体的なURLLC要求は、1msのユーザプレーンの遅延による32バイトのパケットサイズの1E-5のBLER(Block Error Rate)である。
物理レイヤの観点から、信頼性がいくつかの可能な方法において改善可能である。信頼性を向上させる現在の範囲は、URLLCのための別々のCQIテーブル、よりコンパクトなDCIフォーマット、PDCCHの繰り返しなどを規定することに関する。しかしながら、当該範囲は、NRがより安定的になり、また開発されると共に(NR URLLCのキーとなる要求に対して)、超信頼性を実現するため拡がりうる。Rel.15におけるNR URLLCの特定のユースケースは、AR/VR(Augmented Reality/Virtual Reality)、e-health、e-safety及びミッションクリティカルなアプリケーションを含む。
さらに、NR URLLCによって対象とされる技術エンハンスメントは、遅延の改善及び信頼性の向上を目標としている。遅延の改善のための技術エンハンスメントは、設定可能なニューメロロジ、フレキシブルマッピングによる非スロットベースのスケジューリング、グラントフリー(設定されたグラント)のアップリンク、データチャネルのスロットレベルの繰り返し、及びダウンリンクプリエンプションを含む。プリエンプションとは、リソースがすでに割り当てられている送信が中止され、すでに割り当てられているリソースが、以降に要求されたが、より低い遅延/より高い優先度要求を有する別の送信に使用されることを意味する。従って、すでに許可された送信が、以降の送信によってプリエンプトされる。プリエンプションは、特定のサービスタイプに関係なく適用可能である。例えば、サービスタイプA(URLLC)の送信が、サービスタイプB(eMBBなど)の送信によってプリエンプトされてもよい。信頼性向上に関する技術エンハンスメントは、1E-5のターゲットBLERのための専用のCQI/MCSテーブルを含む。
mMTCのユースケースは、非常に多数の接続されたデバイスが、典型的には遅延の影響が小さい比較的少量のデータを送信することによって特徴付けされる。デバイスは、低コストであり、かつ、極めて長いバッテリ寿命を有することが必要とされる。NRの観点から、非常に狭い帯域幅部分を利用することが、UEの観点からの省電力を有し、長いバッテリ寿命を可能にするための1つの可能な解決策である。
上述したように、NRにおける信頼性の範囲がより広くなることが期待される。全てのケース、特にURLLC及びmMTCに必要な1つのキーとなる要求は、高信頼性又は超高信頼性である。無線の観点及びネットワークの観点から信頼性を向上させるためのいくつかの機構が検討可能である。一般には、信頼性の向上に役立つ可能性のあるいくつかのキーとなるエリアが存在する。これらのエリアのうち、コンパクトな制御チャネル情報、データチャネル/制御チャネルの繰り返し、周波数、時間及び/又は空間領域に関するダイバーシチが挙げられる。これらのエリアは、特定の通信シナリオには関係なく、一般的に信頼性に適用可能である。
NR URLLCについては、ファクトリオートメーション、輸送産業、及びファクトリオートメーション、輸送産業、電力配電を含む電力配電など、より厳しい要求を有するさらなるユースケースが特定されている。より厳しい要求は、より高い信頼性(10-6レベルまで)、より高い可用性、256バイトまでのパケットサイズ、数μsのオーダまでの時間同期であり、その値は、特にユースケースに応じて0.5msのターゲットユーザプレーン遅延において、0.5~1msのオーダで周波数レンジと短い遅延に依存して1又は数μsのオーダとなりうる。
さらに、NR URLLCについて、物理レイヤの観点からのいくつかの技術エンハンスメントが特定されている。これらのうち、コンパクトDCIに関連するPDCCH(Physical Downlink Control Channel)エンハンスメント、PDCCH繰り返し、増加したPDCCHモニタリングがある。また、UCI(Uplink Control Information)エンハンスメントは、エンハンストHARQ(Hybrid Automatic Repeat Request)及びCSIフィードバックエンハンスメントに関連している。また、ミニスロットレベルホッピング及び再送/繰り返しエンハンスメントに関連するPUSCHエンハンスメントが特定される。“ミニスロット”という用語は、スロット(14シンボルからなるスロット)よりも少ないシンボルを含む送信時間間隔(TTI)を指す。
[QoSの制御]
5G QoS(Quality of Service)モデルは、QoSフローに基づき、保証されるフロービットレートを必要とするQoSフロー(GBR QoSフロー)と、保証されるフロービットレートを必要としないQoSフロー(非GBR QoSフロー)との双方をサポートする。従って、NASレベルでは、QoSフローは、PDUセッションにおけるQoS差別化の最も細かい粒度である。QoSフローは、PDUセッション内において、NG-Uインタフェースを通じてカプセル化ヘッダ内で搬送されるQoSフローID(QFI)によって識別される。
各UEについて、5GCは、1つ以上のPDUセッションを確立する。各UEについて、NG-RANは、PDUセッションと一緒に少なくとも1つのデータ無線ベアラ(DRB)を確立し、当該PDUセッションのQoSフローのための追加的なDRBが、例えば、図3を参照して上述されるように、以降に設定することができる(いつ設定するかはNG-RAN次第である)。NG-RANは、異なるPDUセッションに属するパケットを異なるDRBにマッピングする。UE及び5GCにおけるNASレベルのパケットフィルタが、UL及びDLパケットをQoSフローに関連付け、UE及びNG-RANにおけるASレベルマッピングルールが、UL及びDLのQoSフローをDRBに関連付ける。
図5は、5G NRの非ローミング基準アーキテクチャ(TS 23.501 v16.1.1,section 4.23を参照されたい)を示す。例えば、図4に例示的に記載される5Gサービスを提供する外部アプリケーションサーバなど、アプリケーション機能(AF)は、サービスを提供するため、例えば、トラフィックのルーティング、NEF(Network Exposure Function)へのアクセス、又はQoS制御などのポリシー制御(PCF(Policy Control Function)を参照されたい)との相互作用に対するアプリケーションの影響をサポートするため、3GPPコアネットワークと相互作用する。事業者の配備に基づいて、事業者によって信頼されるものとみなされるアプリケーション機能が、関連するネットワーク機能と直接相互作用することが可能とすることができる。ネットワーク機能に直接アクセスすることが事業者によって許可されていないアプリケーション機能は、NEFを介して外部のエクスポージャフレームワークを利用して、関連するネットワーク機能と相互作用する。
図5はさらに、5Gアーキテクチャの機能ユニット、すなわち、NSSF(Network Slice Selection Function)、NRF(Network Repository Function)、UDM(Unified Data Management)、AUSF(Authentication Sever Function)、AMF(Access and Mobility Management Function)、SMF(Session Management Function)及び事業者サービス、インターネットアクセス又はサードパーティサービスなどのDN(Data Network)を示す。コアネットワーク機能及びアプリケーションサービスの全て又は一部が展開され、クラウド計算環境上で実行されてもよい。
本開示では、従って、動作中にURLLC、eMMB及びmMTCサービスの少なくとも1つに対するQoS要求を含むリクエストを5GCの機能(例えば、NEF、AMF、SMF、PCF、UPFなど)の少なくとも1つに送信し、QoS要求に従ってgNodeBとUEとの間の無線ベアラを含むPDUセッションを確立する送信機と、動作中に確立されたPDUセッションを利用してサービスを実行する制御回路とを含むアプリケーションサーバ(例えば、5GアーキテクチャのAF)が提供される。
SLを送信する(Tx)UEとSLを受信する(Rx)UEとの双方がgNB/基地局のカバレッジ下でRRC_CONNECTEDモードにあるリソース割当モード1に対して、Rx UEは、Tx UEが送信しているときと同時に送信してもよい。これは、Rx UEがTx UEから送信を受信することができない可能性がある半二重問題を生じさせ、従って、無線オーバヘッド及び送信電力の浪費をもたらす。
図6は、gNB又は基地局が、典型的にはV2X通信においてDCI(すなわち、DCI_X)をどのように利用するかを示す概略図600を示す。基地局602は、Uuを介してリソース割当てに関するDCI(すなわち、DCI_X608)をTx UE604に送信してもよい。DCI_X608は、Tx UE604がSL TB610をRx UE606に送信するのに利用しうるリソース割当て情報を有してもよい。SL TB610の送信は、PSSCH(Physical Sidelink Shared Channel)を介するものであってもよく、それに対応する制御情報は、PSCCH(Physical Sidelink Control Channel)を介して送信されてもよい。Tx UE604及びRx UE606は、例えば、1つ以上の通信/PLMNオペレータの通信サービスに加入している車両に統合又は設置された通信モジュールを含んでもよい。
概略図600において、Tx UE604及びRx UE606は、通信/PLMNオペレータ(図示せず)に加入してもよく、通信オペレータの基地局602と通信する。本例では、基地局602は、次世代NodeB(gNB)602であってもよい。基地局602は、ng-eNBであってもよく、NGインタフェースを介し5Gコアネットワークに接続されてもよいことが、当業者によって理解されうる。
上述されるように、Tx UE604がSL TB610をRx UE606に送信しているときと同時にRx UE606が送信している場合、Rx UE606は、Tx UE604からSL TB610を受信することができない。
従って、本発明は、Rx UEがTx UEから送信を受信するようにスケジューリングされるよう改良された通信手順を提案する。
以下の段落では、特定の例示的な実施例が、1つ以上の通信装置がTx UEからの送信の欠落を回避することを効果的に可能にするgNB/基地局と1つ以上のターゲット通信装置との間のV2X通信機構を参照して説明される。
サイドリンクモード-1で送信される特定のTBについて、gNB又は基地局によってリソース割当てのためTx UEに送信されるDCI_X(LTE V2XにおけるDCI_5Aとして)に加えて、gNBはまた、当該TBのための独立したDCIを用いてRx UEをスケジューリングする。
図7は、各種実施例によるV2X通信においてgNB又は基地局がどのようにDCI_Yを利用するかを示す概略図700を示す。Tx UE704がRx UE706にSL TB710を送信するのに利用しうるリソース割り当て情報を提供するためにDCI_X708をTx UE704に送信することに加えて、基地局702はまた、Rx UE706にメッセージ(すなわち、DCI_Y712)を送信する。DCI_Y712は、Rx UE706が予想されるSL TB710のための受信モードにあることを示すよう規定される新たなDCIフォーマットであってもよい。効果的には、Rx UE706は、DCI_Y712を受信することによってSL TB710の送信を予想するようスケジューリングされるため、SL TB710の受信を失う可能性が少ない。
DCI_X及びDCI_Yのコンテンツについて、最小の要求は以下のように規定されてもよい。
-DCI_X:SL TBを送信するためgNB又は基地局によって許可される時間周波数リソース及び(明示的又は暗黙的)Tx UE識別(ID)情報
-DCI_Y:許可された時間周波数リソースの“受信ウィンドウ”及び(明示的又は暗黙的)Rx UE ID情報
-“受信ウィンドウ”は、許可された時間周波数リソースのタイミング情報を少なくとも含んでもよい。
さらに、Rx UEは、Tx UEと同じgNB又は基地局(同一又は異なるセル)とRRC_CONNECTEDであるべきである。
図8は、各種実施例によるV2X通信においてgNB又は基地局がどのようにDCI_Yを利用するかを示すメッセージフロー800を示す。SL TB810が、例えば、ユニキャストによってTx UE804によってRx UE806に送信されるシナリオについて、Tx UE804はまず、図8のステップ1に示されるように、サービングgNB802にスケジューリング情報814を送信してもよい。スケジューリング情報814は、スケジューリングリクエストと、少なくともRx UE806の宛先ID(例えば、RNTI(Radio Network Temporary Identifier)、L1/L2宛先IDなど)を含むレポートとを有してもよい。そして、gNB802は、図8のステップ2に示されるように、SL TB810のリソース割当てに関する専用のDCI_X808をTx UE804に送信してもよい。gNB802はまた、図8のステップ3に示されるように、SL TB810のための受信ウィンドウを示す専用のDCI_Y812をRx UE806に送信してもよい。DCI_X808において通知されるような許可されたリソースを使用して、Tx UE804は、図8のステップ4に示されるように、PSCCH上で送信されるSL TB810のための制御情報と共に、PSSCH上でSL TB810をRx UE806に送信する。Rx UE806は、SL TB810の送信を受信するため、DCI_Y812に示される受信ウィンドウ内で受信専用モードにある。効果的には、Rx UE806は、SL TB810が予想されるときには送信せず、従って、半二重問題が回避される。
DCI_Y812は、gNB802からTx UE804へのDCI_X808の送信前、送信後又は送信と同時にRx UE806に送信されてもよいことが理解されるであろう。Tx UE804は、DCI_X810及びDCI_Y812に対してUEの復号化が完了した後、PSCCH上で送信されるSL TB810に対する制御情報と共に、PSSCH上でTB810をRx UE806に送信してもよい。
各種実施例において、SL TBは、グループキャストによってRx UEのグループへの送信のためにスケジューリングされてもよい。図9は、各種実施例によるV2X通信におけるグループキャストのためgNB又は基地局がどのようにDCI_Yを利用するかを示す概略図900を示す。図7及び図8に示されるような具体例と同様に、Tx UE904はまずgNB902にスケジューリング情報を送信してもよい。スケジューリング情報は、スケジューリングリクエストと、送信されるべきSL TB910がグループキャストのためのものであることを示す宛先グループIDを少なくとも含むレポートとを有してもよい。この情報に基づいて、gNB902は、SL TB910の送信のためのリソーススケジューリングのためにUuを介してDCI_X908をTx UE904に送信すると共に、SL TB910の送信を受信するための受信ウィンドウを示すため、宛先グループIDによって識別されるように、Uuを介してRx UE906のグループにメッセージ(すなわち、DCI_Y912)を送信してもよい。Rx UE906のグループは、複数のUEであってもよい。DCI_Y912は、Rx UE906のグループに向けられる単一のメッセージとして受信されてもよい。一実施例では、gNB902はまた複数のDCI_Yメッセージを送信してもよく、各DCI_Y912は、SL TB410の受信ウィンドウを通知するため、グループ内の複数のRx UE906のそれぞれに送信される。従って、SL TB910は、その後にDCI_X908に示され、DCI_Y912に示される受信ウィンドウ内において割り当てられたリソースを利用して、PSCCH及びPSSCH上でTx UE904からRx UE906のグループに送信される。
各種実施例において、DCI_Xメッセージは、DCI_Yメッセージとして送信されてもよい。図10は、各種実施例によるV2X通信においてgNB又は基地局がどのようにDCI_XをDCI_Yとして利用しうるかを示す概略図1000を示す。図8及び図9に示す具体例と同様に、UE1004はまずgNB1002にスケジューリング情報を送信してもよい。スケジューリング情報は、スケジューリングリクエストと、送信されるべきSL TB1010がグループキャスト又はブロードキャストのためのものであることを示す宛先IDを少なくとも含むレポートとを有してもよい。宛先IDは、グループID、L1/L2宛先ID、セッションID、サービスインデックスなどを含んでもよい。この情報に基づいて、gNB1002は、SL TB1010の送信のためのリソーススケジューリングのために、DCI_X1008をUuを介しTx UE1004に送信してもよい。同じDCI_X1008がまた、SL TB1010の送信を受信するための受信ウィンドウを示すため、宛先IDによって識別されるRx UE1006のグループにUuを介しDCI_Y1012メッセージとして送信されてもよい。Rx UE1006のグループは、複数のUEであってもよい。DCI_Y1012は、Rx UE1006のグループに向けられた単一のメッセージとして受信されてもよい。一実施例では、gNB502はまた、複数のDCI_Y1012メッセージを送信してもよく、ここで、各DCI_Y1012は、SL TB1010の受信ウィンドウを通知するため、グループ内の複数のRx UE1006のそれぞれに送信される。従って、SL TB1010は、その後にDCI_X1008に示され、DCI_Y1012に示されるような受信ウィンドウ内において割り当てられたリソースを利用して、PSCCH及びPSSCH上でTx UE1004からRx UE1006のグループに送信される。本実施例においてDCI_X1008がまたDCI_Y1012として使用されるとき、DCI_X1008は、Tx UE ID及びRx UEグループIDの両方を含みうる。
各種実施例において、SL TBは、意図されたRx UEへのブロードキャスト送信としてスケジューリングされてもよい。図11は、各種実施例によるV2X通信におけるブロードキャストのためgNB又は基地局がどのようにDCI_Yを利用するかを示す概略図1100を示す。図8及び図10に示される具体例と同様に、Tx UE604はまず、gNB1102にスケジューリング情報を送信してもよい。スケジューリング情報は、スケジューリングリクエストと、送信されるべきSL TB1110が1つ以上のQoS(Quality of Service)パラメータ/インジケータと共にブロードキャストするためのものであることを示す宛先IDを少なくとも含むレポートとを有してもよい。1つ以上のQoSパラメータ/インジケータは、5G QoS識別子(5QI)、V2X 5QI(VQI)、遅延、プライオリティ及び他の同様のインジケータを含んでもよい。宛先IDは、グループID、L1/L2宛先ID、セッションID、サービスインデックスなどを含んでもよい。この情報に基づいて、gNB1102は、SL TB1110の送信のためのリソーススケジューリングのためにUuを介してDCI_X1108をTx UE1104に送信すると共に、SL TB1110の送信を受信するための受信ウィンドウを少なくとも通知するため宛先IDによって識別されるRx UE1106のグループへのブロードキャストとしてメッセージ(すなわち、DCI_Y1112)を送信してもよい。Rx UE1106のグループは、複数のUEであってもよい。従って、SL TB1110は、DCI_X1108に示され、DCI_Y1112に示されるような受信ウィンドウ内の割り当てられたリソースを利用して、PSCCH上で送信されるSL TB1110に対する制御情報と共に、Tx UE1104からRx UE1106のグループにPSSCH上でブロードキャストとして送信される。
各種実施例において、SL TBは、PSSCHのみでの送信のためにスケジューリングされてもよい。図12は、各種実施例によるgNB又は基地局がPSSCH上でのみSL TB送信のためにどのようにDCI_Yを利用するかを示す概略図1200を示す。図7及び図8に示す具体例と同様に、Tx UE1204はまず、gNB1202にスケジューリング情報を送信する。スケジューリング情報は、スケジューリングリクエストと、1つ以上のRx UEを識別する宛先IDを少なくとも含むレポート1206とを有してもよい。この情報に基づいて、gNB1202は、SL TB1210の送信を受信するための受信ウィンドウを通知するため、宛先IDによって識別されるような1つ以上のRx UE1206にUuを介しメッセージ(すなわち、DCI_Y1212)を送信してもよい。DCI_Y1212は更に、SL TB1210の送信のリソース割当て、変調符号化方式などに関する完全な情報を含んでもよい。gNB1202はまた、SL TB1210の送信のためのリソーススケジューリングのためにUuを介しDCI_X1208をTx UE1204に送信してもよく、ここで、DCI_X1208は更に、DCI_Y(すなわち、DCI_Y1212)がRx UE1206に送信されることを示す情報を含む。DCI_Y1212は、DCI_X1208のTx UE1202への送信前、送信後又は送信と同時にRx UEに送信されてもよいことが理解されるであろう。
従って、DCI_Y1212がRx UE1206にリソース割当てのための完全な情報をすでに提供しているとき、SL TB1210は、DCI_X1208に示され、DCI_Y1212に示されるような受信ウィンドウ内において割り当てられたリソースを利用して、Tx UE1204からRx UE1206にPSSCH上でのみ送信されてもよい。効果的には、SL TB1210のためのPSCCH上でのSCI(Sidelink Control Information)の送信は、サイドリンクオーバヘッド及び送信電力を低減するため放棄されてもよい。本実施例は、SL TBのユニキャスト、グループキャスト及びブロードキャスト送信に適用可能であってもよいことが理解されるであろう。
図13は、各種実施例による典型的なDCI_X1300のフォーマットを示す。DCI_X1300は、例えば、図8のステップ1及び2に示されるように、Tx UEからのスケジューリング情報の受信に応答して、gNB又は基地局からTx UEに送信されてもよい。DCI_X1300は、周波数領域リソースを示すフィールド、時間領域リソースを示すフィールド、他の用途のためのビットのフィールド、リザーブドビットのフィールド、及びRNTIによってスクランブリングされるCRC(Cyclic Redundancy Check)のフィールドを含んでもよい。
周波数領域リソースを示すフィールドは、例えば、1つ以上のサブチャネル(すなわち、周波数時間リソーステーブル1302に示されるようなSubCH_0及びSubCH_1)を示す情報を有してもよい。周波数領域の粒度は、リソースブロック(RB)又はサブチャネルの形式であってもよい。周波数領域において、3GPPはサブチャネルをいくつかの連続したRBとして定義してもよく、1RBは12個の連続したサブキャリアを含んでもよい。各サブキャリア間隔は、2μ*15kHzであってもよく、ここで、μはニューメロロジを表す整数である。
時間領域リソースを示すフィールドは、例えば、1つ以上のタイムスロット(すなわち、周波数時間リソーステーブル1302に示されるようなSlotSL )を示す情報を含んでもよい。時間領域の粒度は、サブフレーム、スロット又は直交周波数分割多重(OFDM)シンボルの形式であってもよい。時間領域では、3GPPは、1フレームを10ms、1サブフレームを1msと規定し、1サブフレームに2μ個のスロットがあってもよい。また、ノーマルサイクリックプリフィックス(CP)について1スロットあたり14OFDMシンボルあり、拡張CPについて12OFDMシンボルがあってもよい。周波数又は時間領域におけるリソース割当ては、連続的(すなわち、開始位置+持続時間を含む)又は非連続的(すなわち、ビットマップの形式)であってもよい。
周波数領域リソースを示すフィールド及び時間領域リソースを示すフィールドからの情報は、SL TB送信のためのリソース割当てに利用されてもよく、周波数領域リソースを示すフィールド及び周波数領域リソースを示すフィールドによって示される時間周波数リソース(すなわち、周波数時間リソーステーブル1302の斜線部分)は、図6~12に示されるように、Tx UEからRx UEへのSL TBの送信など、サイドリンク送信のために利用されてもよい。さらに、CRCによりスクランブリングされたRNTIのためのフィールドは、例えば、Tx UEのIDなどのUEを識別する情報を含んでもよい。図6~12に示すような上述した具体例におけるDCI_Xは、DCI_X1300のものと同一又は同様のフォーマットであってもよいことが理解されるであろう。
図14は、各種実施例によるDCI_Y1400のフォーマットを示す。DCI_Y1400は、図のステップ1及び2に示されるように、Tx UEからのスケジューリング情報の受信に応答して、gNB又は基地局から1つ以上のRx UEに送信されてもよい。DCI_Y1400は、受信ウィンドウを示すフィールド、他の目的のためのビットのフィールド、リザーブドビットのフィールド、及びRNTIによってスクランブリングされるCRCのフィールドを含んでもよい。受信ウィンドウを示すフィールドは、Rx UEがSL受信専用モードであるべき1つ以上のタイムスロット(すなわち、周波数時間リソーステーブル1402に示されるようなSlotSL )を示すタイミング情報を含んでもよく、これにより、Rx UEはSlotSL の期間中にTx UEから送信されるであろうSL TBを受信することができる。さらに、CRCによりスクランブリングされるRNTIフィールドは、例えば、Rx UEのIDのようなUEを識別する情報を含んでもよい。図6~12に示されるような上述した具体例におけるDCI_Yは、DCI_Y1400のものと同一又は同様のフォーマットであってもよいことが理解されるであろう。
図15は、各種実施例によるDCI_Yメッセージにおいて受信ウィンドウがどのように通知されるかの具体例を示す図である。本具体例では、DCI_X1500及びDCI_Y1502は、周波数領域リソースを示すフィールド、時間領域リソースを示すフィールド、他の目的のためのビットのフィールド、SLフラグを示すフィールド、リザーブドビットのフィールド、及びRNTIによってスクランブリングされるCRCのフィールドを含んでもよい。DCI_Yは、DCI_X1500としてリソース割当ての完全な情報(すなわち、周波数領域リソースフィールド及び時間領域リソースフィールドから)を含んでもよく、受信モードインジケータが規定されてもよい。受信モードインジケータは、受信モードを示す1ビットフラグ(すなわち、SL_Flag)であってもよい。例えば、“0”の値を有するフラグは受信専用モードを示す一方、“1”の値を有するフラグは非受信専用モード(又はその逆)を示してもよい。さらに、このフラグフィールドは、DCI_X1500においてエンプティであってもよい。フラグフィールドは、周波数領域リソースを示すフィールド及び時間領域リソースを示すフィールドからのリソース割当ての完全な情報と共に、Rx UEが受信モードにあるか否かを示すと共に、Rx UEが対応するTx UEからSL TB送信を受信する受信ウィンドウを示す。図6~12に示すような上述した具体例におけるDCI_X及びDCI_Yは、DCI_X1500及びDCI_Y1502のものと同一又は同様のフォーマットであってもよいことが理解されるであろう。
図16は、各種実施例によるDCI_Yメッセージにおいて受信ウィンドウがどのように通知されるかの他の具体例を示す。本具体例では、DCI_X1600は、周波数領域リソースを示すフィールド、時間領域リソースを示すフィールド、他の目的のためのビットのフィールド、リザーブドビットのフィールド、及びRNTIによってスクランブリングされるCRCのフィールドを含んでもよい(又は構成されてもよい)。一方、対応するDCI_Y1602は、DCI_Y1602において周波数領域リソースを示すフィールドが省略されるように、時間領域リソースを示すフィールド、他の用途のためのビットのフィールド、リザーブドビットのフィールド、及びRNTIによってスクランブリングされるCRCのフィールドを含んでもよい(又は構成されてもよい)。従って、DCI_X1600は、SL RBの送信のためのリソース割当ての完全な時間周波数情報(すなわち、DCI_X1600における周波数領域リソースを示すフィールド及び時間領域リソースを示すフィールド)を有してもよいが、DCI_Y1602は、リソース割当てのタイミング情報(すなわち、DCI_Y1602における時間領域リソースを示すフィールドから)のみを含んでもよい。さらに、受信モードインジケータは、例えば、DCI_X1500及びDCI_Y15502におけるSLフラグフィールドに類似しうる1ビットフラグとして規定されてもよい。あるいは、受信モードインジケータは、DCI_Y1502における周波数領域リソースを示すフィールドの欠落が受信専用モードを暗黙的に示すように、暗黙的であってもよい。図6~12に示すような上述した具体例におけるDCI_X及びDCI_Yは、DCI_X1600及びDCI_Y1602のものと同一又は同様のフォーマットであってもよいことが理解されるであろう。
図17は、各種実施例によるDCI_Yメッセージにおいて受信ウィンドウがどのように通知されるかの他の具体例を示す。DCI_Yメッセージは、Rx UEがTx UEからSL TBの送信を受信する受信モードにある間に受信ウィンドウを示すためのインデックス1700を含んでもよい。インデックス1700は、RCC設定又は事前設定されてもよいインデックステーブル1702を参照してもよい。例えば、DCI_Yは値“2”のインデックスを示してもよい。インデックステーブル1702を参照すると、インデックス値“2”の下、受信ウィンドウは、少なくとも“1”のスロットオフセット、“3”のスタートシンボル及び“4”のシンボル長によって決定されてもよい。従って、SL TBを受信する受信ウィンドウは、斜線部1704によって示されるように、次のスロットのシンボル“3”から始まり、4シンボルの長さにわたって続き、次のスロットのシンボル“6”で終了する次のスロット(すなわち、“1”のスロットオフセットの後)においてスケジューリングされる。インデックステーブル1702は、時間領域のみを示してもよい。しかしながら、それは、DCI及びSLが同じキャリア上にあることを意味しない。むしろ、Rx UEは、何れかのキャリアからのSL TBの送信を予想する受信ウィンドウの間に受信モードにありうる。図6~12に示されるような上述した具体例におけるDCI_Yは、図17のインデックス1700と同じフォーマットの受信ウィンドウを示しうることが理解される。
図18は、各種実施例によるDCI_Yメッセージにおいて受信ウィンドウがどのように通知されるかの他の具体例を示す。DCI_Yメッセージは、Rx UEがTx UEからSL TBの送信を受信する受信モードにある受信ウィンドウを示すためのインデックス1800を含んでもよい。インデックス1800は、RCC設定又は事前設定されうるインデックス/ビットマップテーブル1802を参照してもよい。例えば、DCI_Yは、値“2”のインデックスを示してもよい。インデックス/ビットマップテーブル1802を参照すると、インデックス値“2”の下、受信ウィンドウは、対応するハーフスロットフォーマット、すなわち、DDXXXXXに基づいて決定されてもよい。従って、SL TBを受信するための受信ウィンドウは、斜線領域1804及び1806によって示されるように、各スロットの7シンボル毎の第1及び第2シンボルにおいてスケジューリングされる(“DDXXXXX”におけるシンボル“DD”によって表される)。異なる文字/数字/ビットが、受信ウィンドウ又はインデックス/ビットマップテーブル1802における他のリソースの使用を表すのに使用されてもよいことが理解されるであろう。インデックス/ビットマップテーブル1802は、時間領域のみを示してもよい。しかしながら、それは、DCI及びSLが同じキャリア上にあることを意味しない。むしろ、Rx UEは、何れかのキャリアからのSL TBの送信を予想する受信ウィンドウの間に受信モードにあってもよい。また、図6~12に示すような上述した具体例におけるDCI_X及びDCI_Yは、図18のインデックス1800と同じフォーマットで受信ウィンドウを通知してもよいことが理解されるであろう。
図19は、各種実施例によるDCI_Yメッセージにおいて受信ウィンドウがどのように通知されるかの他の具体例を示す。Rx UEがTx UEからSL TB送信を受信する受信ウィンドウは、Tx UEの送信プール1902とRx UEの送信プール1904との間のタイミング差を考慮することによって、例えば、Rx UEの受信プール1900の形式のリソースプール設定を介しDCI_Yメッセージにおいて通知されてもよい。一般に、Rx UEは、Tx UEが送信中であって、Rx UEが送信中でない受信モードにあるべきである。従って、適切な受信ウィンドウは、長さ1906に沿ったRxプールのエリアに存在してもよい。リソースプール設定は、事前設定又はRRC設定されてもよい。図6~12に示されるような上述された具体例におけるDCI_Yは、図19に示されるのと同じフォーマットでリソースプール設定を介して受信ウィンドウを通知しうることが理解されるであろう。
各種実施例において、制御シグナリングを受信していないときの関連するUEの挙動が指定されてもよい。一実施例では、Rx UEがDCI_Yの送信を失った場合、PSCCH送信が受信されたか否かにかかわらず、Rx UE及びTx UEの挙動は従来のUE挙動に従ってもよく、SL TBをどのように進めるかを決定することは、Tx UE次第である。他の実施例では、Rx UEがPSCCH送信を失ったが、DCI_Yを正しく受信した場合、Rx UEは、予想されるSL TBが失われたことをgNBに報告してもよく、gNBは、失ったSL TBの再送のためTx UEをスケジューリングしてもよい。代替的な応答では、Rx UEがDCI_Y又はPDSCH(Physical Downlink Shared Channel)、MAC制御エレメント(MAC CE)、RRCなどの他の何らかのソースを介し関連するTx UE情報を有する場合に限って、Rx UEは、PSFCH(Physical Sidelink Feedback Channel)上で非アクノリッジメント(NACK)をTx UEにフィードバックしてもよい。他の代替的な応答では、Rx UEはDCI_Yを破棄してもよく、SL TBをどのように進めるか、すなわち、PSFCH設計に応じて決定することは、Tx UE次第であってもよい。他の実施例では、Rx UEがPSCCH及びDCI_Yの双方を失った場合、Rx UE及びTx UEの挙動は、従来のUE挙動に従ってもよく、SL TBをどのように進めるかを決定するのはTx UE次第である。
各種実施例において、ブラインド再送は、モード1通信のために放棄されてもよい。各種実施例において、本解決策は、ライセンスバンド及びITS(Intelligent Transportation System)帯域の双方に適用可能であってもよい。各種実施例において、本解決策は、モード1のみを有するか、又はモード1及び2を同時に有するUEに適用可能であってもよい。各種実施例において、Rx UEへのDCI_Yの送信は、Tx UEへのDCI_Xの送信が周期的(又はセミパーシステント)であるとき、周期的(又はセミパーシステント)であってもよい。各種実施例において、Tx UEは、DCI_YがRx UEに送信される必要があるか否かをgNBに要求してもよい。各種実施例において、DCI_Yが必要か否かは、トラヒックのタイプ、サービスのタイプ、又はVQI、5QI、遅延、プライオリティなどのQoSパラメータ/インジケータに関連付けされてもよい。
図20は、各種実施例による通信方法を示すフロー図2000を示す。ステップ2002において、通信装置が受信モードにあるか否かを示すメッセージが生成されてもよい。ステップ2004において、メッセージが通信装置に送信されてもよい。
図21は、図6~20に示されるような各種実施例によるV2X通信を確立するため実現可能な通信装置2100の概略的な部分断面図を示す。通信装置1600は、各種実施例によるUE又は基地局として実現されてもよい。
通信装置1600の各種機能及び処理が階層的モデルによるレイヤに構成される。モデルでは、下位レイヤは、3GPP 5G NR仕様に従って上位レイヤに報告し、そこから命令を受信する。簡単化のため、階層的モデルの詳細は本開示では説明されない。
図21に示されるように、通信装置2100は、回路2114、少なくとも1つの無線送信機2102、少なくとも1つの無線受信機1604及び少なくとも1つのアンテナ2112(簡単化のため、1つのアンテナのみが例示のため図21に示される)を含んでもよい。回路2114は、無線ネットワークにおける1つ以上の他の通信装置との通信の制御を含む、少なくとも1つのコントローラ2106が実行するよう設計されるタスクのソフトウェア及びハードウェアにより支援される実行において利用される少なくとも1つのコントローラ2106を含んでもよい。回路2114は更に、少なくとも1つの送信信号生成器1608と、少なくとも1つの受信信号プロセッサ2110とを含んでもよい。少なくとも1つのコントローラ2106は、1つ以上の他の通信装置に少なくとも1つの無線送信機2102を介し送信される信号を生成する少なくとも1つの送信信号生成器2108(例えば、通信装置2100が基地局である場合には、DCI_X及びDCI_Yであり、通信装置2100がUEである場合には、信号)と、少なくとも1つのコントローラ2106の制御の下で1つ以上の他の通信装置から少なくとも1つの無線受信機2104を介し受信した信号を処理するための少なくとも1つの受信信号プロセッサ2110(例えば、通信装置2100がUEである場合には、DCI_X及びDCI_Yであり、通信装置2100が基地局である場合には、スケジューリング情報)とを制御してもよい。少なくとも1つの送信信号生成器2108及び少なくとも1つの受信信号プロセッサ2110は、図21に示されるように、上述した機能に対して少なくとも1つのコントローラ2106と通信する通信装置2100のスタンドアローンモジュールであってもよい。あるいは、少なくとも1つの送信信号生成器2108及び少なくとも1つの受信信号プロセッサ2110は、少なくとも1つのコントローラ2106に含まれてもよい。これらの機能モジュールの構成はフレキシブルであって、実際のニーズ及び/又は要求に応じて変更されてもよいことが当業者に理解されるであろう。データ処理、格納及び他の関連する制御装置は、適切な回路ボード及び/又はチップセット上に備えることが可能である。各種実施例では、動作中に、少なくとも1つの無線送信機2102、少なくとも1つの無線受信機2104及び少なくとも1つのアンテナ2112は、少なくとも1つのコントローラ2106によって制御されてもよい。
通信装置2100は、動作中にV2X通信においてDCIを実現するのに必要とされる機能を提供する。例えば、通信装置2100はUEであってもよく、無線受信機2104は、動作中に通信装置が受信モードにあるか否かを示すメッセージを受信してもよい。送信機2102は、動作中に通信装置が受信モードにないとき、信号を送信してもよい。
メッセージは、通信装置2100が受信モードにある受信ウィンドウを示してもよく、無線受信機2104は、通信装置1600が受信モードにあるとき、送信ブロック(TB)を受信するよう構成される。メッセージは、DCI(Downlink Control Information)のフォーマットであってもよい。
例えば、通信装置2100は、基地局であってもよく、回路2114は、動作中に通信装置が受信モードにあるか否かを示すメッセージを送信してもよい。送信機2102は、動作中にメッセージを通信装置に送信してもよい。メッセージは、DCIのフォーマットであってもよい。
無線受信機2104は、動作中に送信側の通信装置からスケジューリング情報を受信してもよく、スケジューリング情報は通信装置を識別する。スケジューリング情報は、複数の通信装置を識別してもよく、メッセージは、通信装置がグループキャストのための受信モードにあるか否かを示してもよく、送信機2102は、メッセージを複数の通信装置に送信してもよい。
無線受信機2104は、動作中に送信側の通信装置からスケジューリング情報を受信してもよく、スケジューリング情報は通信装置を識別する。スケジューリング情報は、複数の通信装置を識別してもよく、メッセージは、通信装置がブロードキャストのための受信モードにあるか否かを示してもよく、送信機2102は、メッセージを複数の通信装置に送信してもよい。
送信機2102は更に、送信側の通信装置にDCIを送信するよう構成されてもよく、DCIは、メッセージが通信装置に送信されたことを示す。
メッセージは、通信装置が受信モードにある受信ウィンドウを通知してもよく、通信装置は、受信ウィンドウの間に送信ブロック(TB)を受信するよう構成される。受信ウィンドウは、TBを受信するためのリソース割当ての周波数及びタイミング情報を含んでもよい。受信ウィンドウは、TBを受信するためのリソースプール設定を含んでもよい。受信ウィンドウは、TBを受信するためのリソース割当て及び変調符号化方式(MCS)に関する完全な情報を含んでもよく、TBのためのPSCCH(Physical Sidelink Control Channel)上のSCI(Sidelink Control Information)メッセージの送信は放棄される。
上述したように、本開示の実施例は、SL TB送信の欠落の軽減又は回避を効果的に可能にするV2X通信装置のためのDCIを実現する先進的な通信システム、通信方法及び通信装置を提供する。
本開示は、ソフトウェア、ハードウェア又はハードウェアと連動するソフトウェアによって実現することができる。上述した各実施例の説明に用いた各機能ブロックは、集積回路等のLSIによって部分的又は全体的に実現可能であり、各実施例で説明される各処理は、同一のLSI又はLSIの組み合わせによって部分的又は全体的に制御されてもよい。LSIは、個別にチップとして形成されていてもよいし、あるいは、機能ブロックの一部又は全部を含むように1つのチップが形成されていてもよい。LSIは、それに結合されたデータ入出力を含んでもよい。ここで、LSIとは、集積度の違いにより、IC、システムLSI、スーパーLSI又はウルトラLSIとして呼ばれうる。しかし、集積回路を実現する技術はLSIに限定されず、専用回路、汎用プロセッサ又は特定用途向けプロセッサを用いて実現されてもよい。さらに、LSI内部に配置される回路セルの接続及び設定が再設定可能なLSI又はリコンフィギュラブルプロセッサの製造後にプログラミング可能なFPGA(Field Programmable Gate Array)が利用されてもよい。本開示は、デジタル処理又はアナログ処理として実現することができる。半導体技術や他の派生技術の進歩の結果として、将来の集積回路技術がLSIに取って代わる場合、機能ブロックは、将来の集積回路技術を用いて集積化することができる。バイオテクノロジーも適用できる。
本開示は、通信装置と呼ばれる、通信機能を有する何れかのタイプの装置、デバイス又はシステムによって実現することができる。
通信装置は、送受信機及び処理/制御回路を有してもよい。送受信機は、受信機及び送信機を含み、及び/又は機能してもよい。送受信機は、送信機及び受信機として、アンプ、RF変調器/復調器などを含むRF(Radio Frequency)モジュールと、1つ以上のアンテナとを含んでもよい。
そのような通信装置のいくつかの非限定的な例は、電話機(例えば、携帯(セル)電話、スマートフォン)、タブレット、パーソナルコンピュータ(PC)(例えば、ラップトップ、デスクトップ、ネットブック)、カメラ(例えば、デジタルスチル/ビデオカメラ)、デジタルプレーヤ(デジタルオーディオ/ビデオプレーヤ)、ウェアラブルデバイス(例えば、ウェアラブルカメラ、スマートウォッチ、トラッキングデバイス)、ゲームコンソール、デジタルブックリーダ、遠隔ヘルス/遠隔医療(リモートヘルス及びリモート医療)デバイス、及び通信機能を提供する車両(例えば、自動車、飛行機、船舶)、並びにそれらの様々な組み合わせを含む。
通信装置は、携帯型又は可動型であることに限定されず、スマートホームデバイス(例えば、家電、ライティング、スマートメータ、制御パネル)、自動販売機及び“Internet of Things(IoT)”のネットワークにおける他の何れかの“物”など、非携帯型又は固定型である何れかのタイプの装置、デバイス又はシステムを含んでもよい。
通信は、例えば、セルラシステム、無線LANシステム、衛星システムなど、及びそれらの様々な組み合わせを介してデータを交換することを含んでもよい。
通信装置は、本開示に記載された通信の機能を実行する通信デバイスに結合されたコントローラ又はセンサなどのデバイスを含んでもよい。例えば、通信装置は、通信装置の通信機能を実行する通信デバイスによって使用される制御信号又はデータ信号を生成するコントローラ又はセンサを含んでもよい。
通信装置はまた、基地局、アクセスポイントなどのインフラストラクチャファシリティと、上記の非限定的な例におけるものなどの装置と通信又は制御する他の何れかの装置、デバイス又はシステムを含んでもよい。
各種実施例のいくつかの性質がデバイスを参照して説明されたが、対応する方法はまた各種実施例の方法に適用され、その逆もあることが理解されるであろう。
多数の変形及び/又は修正が広範に説明されるような本開示の趣旨又は範囲から逸脱することなく特定の実施例に示されるような本開示に対して行われてもよいことは、当業者に理解されるであろう。従って、本実施例は、全てに関して限定でなく例示的であるとみなされるべきである。

Claims (15)

  1. 通信装置であって、
    動作中に前記通信装置が受信モードにあるか否かを示すメッセージを受信する受信機と、
    動作中に前記通信装置が前記受信モードにないとき、信号を送信する送信機と、
    を有する通信装置。
  2. 前記メッセージは、前記通信装置が前記受信モードにある受信ウィンドウを示し、前記受信機は、前記通信装置が前記受信モードにあるとき、送信ブロック(TB)を受信するよう構成される、
    請求項1に記載の通信装置。
  3. 前記メッセージは、DCI(Downlink Control Information)のフォーマットである、
    請求項1に記載の通信装置。
  4. 基地局であって、
    動作中に通信装置が受信モードにあるか否かを示すメッセージを生成する回路と、
    動作中に前記メッセージを前記通信装置に送信する送信機と、
    を有する基地局。
  5. 動作中に送信側の通信装置からスケジューリング情報を受信する受信機を更に有し、
    前記スケジューリング情報は、前記通信装置を識別する、
    請求項4に記載の基地局。
  6. 前記スケジューリング情報は、複数の通信装置を識別し、
    前記メッセージは、前記複数の通信装置がグループキャストの受信モードにあるか否かを示し、
    前記送信機は、前記メッセージを前記複数の通信装置に送信する、
    請求項5に記載の基地局。
  7. 前記スケジューリング情報は、複数の通信装置を識別し、
    前記メッセージは、前記複数の通信装置がブロードキャストの受信モードにあるか否かを示し、
    前記送信機は、前記メッセージを前記複数の通信装置に送信する、
    請求項5に記載の基地局。
  8. 前記送信機は更に、前記送信側の通信装置にDCIを送信するよう構成され、
    前記DCIは、前記メッセージが前記通信装置に送信されたことを示す、
    請求項5に記載の基地局。
  9. 前記メッセージは、前記通信装置が前記受信モードにある受信ウィンドウを示し、
    前記通信装置は、前記受信ウィンドウの間に送信ブロック(TB)を受信するよう構成される、
    請求項4に記載の基地局。
  10. 前記受信ウィンドウは、前記TBを受信するためのリソース割当ての周波数及びタイミング情報を含む、
    請求項9に記載の基地局。
  11. 前記受信ウィンドウは、前記TBを受信するためのインデックスを含む、
    請求項9に記載の基地局。
  12. 前記受信ウィンドウは、前記TBを受信するためのリソースプール設定を含む、
    請求項9に記載の基地局。
  13. 前記受信ウィンドウは、前記TBを受信するためのリソース割当て及び変調符号化方式(MCS)に関する完全な情報を含み、
    前記TBのためのPSCCH(Physical Sidelink Control Channel)上のSCI(Sidelink Control Information)メッセージの送信は放棄される、
    請求項9に記載の基地局。
  14. 前記メッセージは、DCIのフォーマットである、
    請求項4に記載の基地局。
  15. 通信装置の通信方法であって、
    通信装置が受信モードであるか否かを示すメッセージを生成することと、
    前記メッセージを前記通信装置に送信することと、
    を有する通信方法。
JP2021576760A 2019-07-31 2020-06-25 V2x通信装置のためのdciの通信装置及び通信方法 Pending JP2022542341A (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
SG10201907070S 2019-07-31
SG10201907070SA SG10201907070SA (en) 2019-07-31 2019-07-31 Communication apparatuses and communication methods for dci for v2x communication apparatuses
PCT/SG2020/050358 WO2021021015A1 (en) 2019-07-31 2020-06-25 Communication apparatuses and communication methods for dci for v2x communication apparatuses

Publications (1)

Publication Number Publication Date
JP2022542341A true JP2022542341A (ja) 2022-10-03

Family

ID=74230863

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2021576760A Pending JP2022542341A (ja) 2019-07-31 2020-06-25 V2x通信装置のためのdciの通信装置及び通信方法

Country Status (4)

Country Link
US (1) US20220256557A1 (ja)
JP (1) JP2022542341A (ja)
SG (1) SG10201907070SA (ja)
WO (1) WO2021021015A1 (ja)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
SG10201907070SA (en) * 2019-07-31 2021-02-25 Panasonic Ip Corp America Communication apparatuses and communication methods for dci for v2x communication apparatuses
US11570807B2 (en) * 2021-04-27 2023-01-31 Qualcomm Incorporated Configured grant for multi-hop in sidelink
US20230239883A1 (en) * 2022-01-27 2023-07-27 Qualcomm Incorporated Techniques for granting resources for network coding procedures

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2014014183A1 (ko) * 2012-07-18 2014-01-23 엘지전자 주식회사 무선 접속 시스템에서 단말 탐색 방법 및 이를 위한 단말
CN106998575B (zh) * 2016-01-22 2020-09-29 株式会社Kt 用于执行v2x通信的用户设备的移动性的控制方法及其装置
RU2690195C1 (ru) * 2016-01-29 2019-05-31 Панасоник Интеллекчуал Проперти Корпорэйшн оф Америка Enodeb, оборудование пользователя и способ беспроводной связи
US10505618B2 (en) * 2016-08-10 2019-12-10 Samsung Electronics Co., Ltd. Method and apparatus for beam measurement and management in wireless systems
KR20180036476A (ko) * 2016-09-30 2018-04-09 주식회사 아이티엘 V2x를 위한 자원 풀 결정 방법 및 장치
US20190320358A1 (en) * 2018-04-17 2019-10-17 Qualcomm Incorporated User equipment power optimization in millimeter wave access networks
US20200037343A1 (en) * 2018-07-24 2020-01-30 Samsung Electronics Co., Ltd. Method and apparatus for network controlled resource allocation in nr v2x
JP7543257B2 (ja) * 2018-09-27 2024-09-02 インターデイジタル パテント ホールディングス インコーポレイテッド Nr V2x用Uuベースサイドリンク制御
CN111182592B (zh) * 2018-12-28 2021-09-14 维沃移动通信有限公司 接收模式切换的方法及终端
WO2020142903A1 (en) * 2019-01-08 2020-07-16 Lenovo (Beijing) Limited Method and apparatus for a sidelink transmission
SG10201907070SA (en) * 2019-07-31 2021-02-25 Panasonic Ip Corp America Communication apparatuses and communication methods for dci for v2x communication apparatuses

Also Published As

Publication number Publication date
WO2021021015A1 (en) 2021-02-04
US20220256557A1 (en) 2022-08-11
SG10201907070SA (en) 2021-02-25

Similar Documents

Publication Publication Date Title
CN114041314A (zh) 用户设备和调度节点
JP2024073619A (ja) 端末、通信方法及び集積回路
JP2022542341A (ja) V2x通信装置のためのdciの通信装置及び通信方法
US20230171802A1 (en) Terminal, and communication method
JP2022544258A (ja) ユーザ装置及びスケジューリングデバイス
US20220287008A1 (en) Communication apparatuses and communication methods for utilization of released resource
CN115428558A (zh) 移动台、基站、接收方法及发送方法
JP2024109710A (ja) 端末装置、通信方法及び集積回路
AU2020360357A1 (en) User equipment and scheduling node
WO2021066741A1 (en) Communication apparatuses and communication methods for utilisation of sl-rsrp in v2x resource sensing and selection
US20230300859A1 (en) Terminal and sidelink communication control method
US20230057436A1 (en) Communication apparatuses and communication methods for utilization of reserved resource
WO2023188912A1 (ja) 基地局、端末及び通信方法
WO2022239289A1 (ja) 通信装置、及び、通信方法
WO2024034198A1 (ja) 端末、基地局及び通信方法
WO2023203938A1 (ja) 端末、基地局、通信方法及び集積回路
WO2024171521A1 (ja) 基地局、端末及び通信方法
WO2024219190A1 (ja) 端末、基地局、及び、通信方法
WO2024100924A1 (ja) 端末、基地局、及び、通信方法
WO2023100471A1 (ja) 基地局、端末及び通信方法
WO2022209097A1 (ja) 通信装置および通信方法
WO2022215299A1 (ja) 基地局、端末、及び、通信方法
WO2023139852A1 (ja) 端末、基地局、及び、通信方法
WO2023013217A1 (ja) 基地局、端末及び通信方法
WO2024171677A1 (ja) 通信装置、通信方法、及び、集積回路

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20230404

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20240702

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20240925

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20241008